[vlc-devel] Patch to add support for HTTP Live Streaming w/requested changes

Keary Griffin keary.griffin at unwiredappeal.com
Sat Mar 27 04:26:21 CET 2010

I have tried to make the requested changes, please find find the new 
patch attached.

The formatting has been cleaned up.  I have adjusted the Author to 
myself and added a copyright line/date for myself, along with leaving 
the previous copyright that was in access_out/file.c which is what this 
module was built off of. (I hope this is the correct procedure, I really 
wasn't sure...)  I also cleaned up some error checking, and added a 
msg_Info output every time the index is updated in case someone wants to 
use that information to script an FTP/SCP solution for moving the 
segments and/or index to another server.

I ran the Win32 tests I mentioned yesterday and it works as designed--  
If the index file is currently not able to be overwritten with the new 
index (as would be the case if the HTTP server has it open) it is 
retried up to 10 times with a 1/10th of a second delay in between each 
try.  If after 10 tries it is still unable to rename the file, it moves 
on.  The next time the index is updated this procedure will be tried again.

The above is Win32 specific--  renaming a file over an existing (even in 
use) file on Linux (and I believe most other) OS's is not an issue, so 
retry mechanism mentioned above is not used.

I wish I could think of a better solution for Win32, so I am open to 
suggestions.  I'm thinking the best solution for windows users is to 
forgo the use of the index file completely, and build a PHP/.NET script 
that scans the directory for existing segments and dynamically builds 
the index...

One other question that came up that I'd like to hear other peoples 
input on is the question of whether to add an "exec" option to the 
module.  This would be something like exec="/usr/bin/scp %1 
ubuntu at webserver.ec2:www/streams" which would use vlc_execve to execute 
a command/script to copy the generated segments/index file to a remote 
server.  %1 would be the file name, %2 would be "index" or "segment".

I have the instructions and examples posted here: 
but for completeness I'll include them in this thread also:

The name of the module is livehttp, and is specified by specifying 

splitanywhere= (default: false)
Tells livehttp to split the stream anywhere, not just on video 
keyframes.  Currently required to be set to true for audio-only streams 
and not recommended (probably won't work) for video streams.

seglen= (default: 10) 
How many seconds of audio/video each segment should contain.  Apple 
recommends 10, I have been using 5.

numsegs=(default: 0)
  The number of segments to keep in the index file.  The default of 0 
keeps all segments in the index (which you would want for non-live 
streaming).  For live streaming the specification require at least 3.

delsegs= (default: true)
Delete segments as they are no longer needed.   If numsegs=0 this 
parameter is ignored (as all segments are assumed to be needed)

This is actually an option to the access std module.  The path of the 
segment files to write.  The # characters get replaced with the segment 
number.  So a path of "seg-###.ts" will end up with files called 
"seg-001.ts, seg-002.ts, seg-003.ts" etc.

The path of the index file to write, which will contain the "playlist" 
of video/audio segments to stream.  Recommended to end in .m3u8 by 
specifications.  This is the file the <video> tag should be pointed to.

This is the URL that corresponds to the dst above (how a browser would 
access the dst file).  The # characters get replaced same as in the dst 
parameter.  Note:  The filename portion of this URL will most likely 
need to be in the exact same format as the dst parameter.  So for 
example if dst=/www/seg-##.ts then the index-url should be something 
like index-url=http://mydomain.com/streams/seg-##.ts  (Note the same 
number of # characters)

rate-control=(default: false)
If set to false the there is no rate control (the muxer sends the data 
as fast/slow as it can to the streamer).  If set to true the muxer 
should do rate-control to control the speed to muxed audio/video is sent 
to the streamer.  I'm a little unsure what the "best" setting for this 
parameter is when re-streaming an existing video stream.  I've been 
leaving it at false...

All examples assume the following:

    * The Web Server root directory is /var/www
    * The domain name of the web server is mydomain.com
    * The stream segments & index files will be written into 
/var/www/streaming/ and will be accessed via 
    * The destination stream name index file will be called "mystream.m3u8"

The following HTML will allow you to view the video based on the above 
on an iPhone:

    <title>Video Test</title>
    <meta name="viewport" content="width=320; initial-scale=1.0; 
maximum-scale=1.0; user-scalable=0;"/>
  <body style="background-color:#FFFFFF; ">
    Audio/Video Stream:<br/>
      <video width='150' height='150' 
src="http://mydomain.com/streaming/mystream.m3u8" />

Re-stream a live video feed:
vlc -I dummy --mms-caching 0 
http://www.nasa.gov/55644main_NASATV_Windows.asx vlc://quit 
Create a VOD stream:
(Non-live.  When this command finishes, all the segments should have 
been created and the index file contain pointers to all of them)
vlc -I dummy /var/myvideos/video.mpg vlc://quit 
Re-stream a live audio feed:
vlc -I dummy --mms-caching 0 
http://www.nasa.gov/55644main_NASATV_Windows.asx vlc://quit 

 Possible improvements:

    * Have the module auto-detect audio only streams, so the 
splitanywhere option is not required.  I'm not sure how to do this.
    * Break the dst= and index= parameter into seperate 
filename/directory entries, so you only need to specify the filename 
format once. (instead of once for the dst= parameter, and once for the 
index-url= parameter)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: vlc-livehttp.patch
Type: text/x-patch
Size: 21126 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20100326/0d62386d/attachment.bin>

More information about the vlc-devel mailing list