README:

This is a video toolkit it publishes and plays live video in a segmented stream
that also seeks from buffer in CCNx repo.

more detailed readme to come; meanwhile this should help the early adopters.

ignore /sandbox, this readme applies to just /videostreaming folder

installing:

	see 'BUILD'

usage:

playing remote stream:

make sure ccnd is running, and has a route to a testbed node.

./play.py /ndn/ucla.edu/apps/video

if that doesn't work, see 'troubleshooting', below. 

(For fine tuning performance based on transport, see 'command line arguments' below)

publishing local video:

make sure CCNR_DIRECTORY is set and sourced (we recommend to define it in ~/.profile)
make sure ccnd & ccnr (your local repo) are running, and are routed (for others to access)

note:  you may need to manually create CCNR_DIRECTORY/import/ directory

if you don't have a working video URI, there are a few options:

1) python video_sink.py [desired URI]

then you have a URI you can play via above. It auto-selects first video device.

another option is 
2) the more featured 'publish' script:

python ./publish.py [URI] m

as of writing, this uses /dev/video0.

yet another option is to use a file instead of a capture device:
3) ./ccn_launch.py filesrc location=[filename.mp4] ! typefind ! qtdemux name=mux \
mux.video_00 ! queue ! VideoSink location=/repo/test/mainvideo/video \
mux.audio_00 ! queue ! AudioSink location=/repo/test/mainvideo/audio


Command Line Arguments (play.py):

-r <int> - how many times resend interest before giving up (default 1)
	     0 means to not retry.
-a/-v <int> - how large the pipeline should be for audio and video.
              Defaults are 18 and 3 (for video and audio
              respectively).
-d  disables video pausing when one of the stream pipelines gets low


While -r probably is self explanatory, -a and -v might need more
explanation. 

Those variables basically control the number of interests
issued that did not get response yet. So for value 18 it means the
code issues 18 interests and stops, once it gets let say 5 responses
it will issue next 5 interests trying to maintain 18 pending. It might
have some negative effect on latency.

18 and 3 was picked by authors empirically and it worked fine in TCP or UDP over multiple 'hops'. 
With TCP it is not enough (because TCP increases latency). I really
did not experiment with it but having it set to 36 and 6 (doubling the
values) resulted in normal playback. Values larger than that are not recommended. 

-d  makes the player continue to play even when there is
no data in one stream or both. So if one stream gets behind, it will
had to catch up. There's no logic to skip the data. This probably
might not work too bad when you have more bandwidth than is necessary
for the playback.

Troubleshooting:

make sure gstreamer works independently of ndnvideo.

for instance, sudo apt-get install gstreamer-tools
 then 

ie - try

gst-launch -v -m autovideosrc ! xvimagesink

if this doesn't work, try 
xvinfo
if you don't have any adapters… you can likely use ximagesink.

however you may need to videoscale to specific supported size listed by: 

gst-inspect ximagesink

note we expect xvimagesink - but if you're in a VM or otherwise have no acceleration, change line 16 in utils.py from merely xvimagesink to:

video_sink = "ffmpegcolorspace ! videoscale ! ximagesink window-width=704 window-height=480"

can also try:

./ccn_launch.py VideoSrc location=/ndn/ucla.edu/apps/video/hydra/ ! \
   ffdec_h264 ! aasink

(this will render video using ascii :)