[vlc-devel] Live HTTP Streaming (iPhone) for VLC

[Keary Griffin]

Jean-Baptiste Kempf wrote:
> Hello,
>
> On Thu, Mar 25, 2010 at 10:46:00AM -0400, Keary Griffin wrote :
>   
>> I've put together a patch that adds an access_out module (as well as a  
>> small change in the ts muxer) to add support for the HTTP Live Streaming  
>> protocol to VLC.  This is the protocol the iPhone uses for live  
>> streaming and and is also supported by Quicktime X and Safari on OSX.   
>>     
>
> This is cool stuff!
>
> Is the small change in the ts muxer independent?
>
>   
Yes, this is the only change to the ts muxer:

diff --git a/modules/mux/mpeg/ts.c b/modules/mux/mpeg/ts.c
index 34e4e3e..893140e 100644
--- a/modules/mux/mpeg/ts.c
+++ b/modules/mux/mpeg/ts.c
@@ -2019,6 +2019,12 @@ static block_t *TSNew( sout_mux_t *p_mux, 
ts_stream_t *p_stream,
     }
 
     p_ts = block_New( p_mux, 188 );
+
+    if (b_new_pes && !(p_pes->i_flags & BLOCK_FLAG_NO_KEYFRAME) && 
p_pes->i_flags & BLOCK_FLAG_TYPE_I)
+    {
+        p_ts->i_flags |= BLOCK_FLAG_TYPE_I;
+    }
+
     p_ts->i_dts = p_pes->i_dts;
 
     p_ts->p_buffer[0] = 0x47;

Someone who understands the muxer better than me (which may be just 
about anyone...) should double check it, but the intent is simply to 
pass on to the access_out module information about key frames.  The 
livehttp module needs to know when key frames occur so it can segment 
the file on a keyframe boundary.  The muxer didn't seem to include this 
information in block->i_flags.  From testing with the files I was 
transcoding, adding the code above seems to work, but since I wasn't 
exactly sure how the muxer worked I couldn't be 100% sure.
>> This is my first time working with the VLC code, so please let me know  
>> if there are any major issues anyone sees as to either the code itself  
>> or the way I am doing something.
>>     
> Patch is here:
> http://www.unwiredappeal.com/blogfiles/techblog/vlc-livehttp.patch
> You should attach it here if you want review.
>
>  Copyright, years and authors are wrong.
>  sout_access_out_sys_t might need reordering for mem alignment.
>  Braces for if are inconsistent. Please use K&R or FFmpeg or VLC codestyle,
>  but pick one and keep it the same within the file :D
>
>   
Sorry, I tried to be good ;-)  I'll go through line by line and clean up 
after myself.

Not sure what I need to do about alignment-- If I simply move all the 
bool's to the end should that be safe?

I'll make the changes and attach.
> Was the patch tested on Win32, btw?
>
>
>   
A qualified yes--  I compiled and tested on win32 to make sure the 
renaming of the index was working (it wasn't when I first tried it).  I 
made what seemed to be the necessary changes to make it work.  For 
whatever reason _wrename didn't seem to be returning an error even when 
the rename failed (which it should in most cases because it is trying to 
overwrite an existing file which I don't believe _wrename allows).  
However _wrename was failing (i.e. not renaming) but not returning an 
error, so I switched to using MoveFileExW for win32 in all cases.

The qualified part comes in with what happens in the case that the index 
file is open for reading (by the web server for instance) when the 
renaming is trying to take place.  I'll have to write up a test harness 
to test this out.  Even if it passes the test the way I handle it (by 
sleeping for 1/10th of a second an trying again...) may not be the best 
solution, but it was the only one I could come up with.  I'll try to 
write the test code tomorrow and post my results.
>> As an aside I also put together a small patch for the mmsh code to  
>> (hopefully) add support for honoring the Content-Length header sent by  
>> some servers.   I believe this is the problem referenced in:   
>> http://trac.videolan.org/vlc/ticket/2533 where I also posted a comment.
>> You can find more details here:
>> http://techblog.unwiredappeal.com/2010/03/vlc-mms-start-delay-keep-alive-patch.html
>>     
>
> Please, do another thread and attach the patch:
> http://www.unwiredappeal.com/blogfiles/techblog/vlcmms.patch
> but if this fixes 2533, it should be applied ASAP.
>
>   
Will do-- I'll go through this patch again to make sure I didn't get 
lazy with coding style and post a new thread with patch attached tomorrow.
>> Thanks
>>     
> Thanks for your work.
>
> Best Regards,
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20100325/97406a0d/attachment.html>