<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Jean-Baptiste Kempf wrote:
<blockquote cite="mid:20100325231149.GA15150@videolan.org" type="cite">
  <pre wrap="">Hello,

On Thu, Mar 25, 2010 at 10:46:00AM -0400, Keary Griffin wrote :
  </pre>
  <blockquote type="cite">
    <pre wrap="">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.   
    </pre>
  </blockquote>
  <pre wrap=""><!---->
This is cool stuff!

Is the small change in the ts muxer independent?

  </pre>
</blockquote>
Yes, this is the only change to the ts muxer:<br>
<br>
diff --git a/modules/mux/mpeg/ts.c b/modules/mux/mpeg/ts.c<br>
index 34e4e3e..893140e 100644<br>
--- a/modules/mux/mpeg/ts.c<br>
+++ b/modules/mux/mpeg/ts.c<br>
@@ -2019,6 +2019,12 @@ static block_t *TSNew( sout_mux_t *p_mux,
ts_stream_t *p_stream,<br>
     }<br>
 <br>
     p_ts = block_New( p_mux, 188 );<br>
+<br>
+    if (b_new_pes && !(p_pes->i_flags &
BLOCK_FLAG_NO_KEYFRAME) && p_pes->i_flags &
BLOCK_FLAG_TYPE_I)<br>
+    {<br>
+        p_ts->i_flags |= BLOCK_FLAG_TYPE_I;<br>
+    }<br>
+<br>
     p_ts->i_dts = p_pes->i_dts;<br>
 <br>
     p_ts->p_buffer[0] = 0x47;<br>
<br>
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.<br>
<blockquote cite="mid:20100325231149.GA15150@videolan.org" type="cite">
  <pre wrap=""></pre>
  <blockquote type="cite">
    <pre wrap="">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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->Patch is here:
<a class="moz-txt-link-freetext" href="http://www.unwiredappeal.com/blogfiles/techblog/vlc-livehttp.patch">http://www.unwiredappeal.com/blogfiles/techblog/vlc-livehttp.patch</a>
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

  </pre>
</blockquote>
Sorry, I tried to be good ;-)  I'll go through line by line and clean
up after myself.<br>
<br>
Not sure what I need to do about alignment-- If I simply move all the
bool's to the end should that be safe?<br>
<br>
I'll make the changes and attach.<br>
<blockquote cite="mid:20100325231149.GA15150@videolan.org" type="cite">
  <pre wrap="">Was the patch tested on Win32, btw?


  </pre>
</blockquote>
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.<br>
<br>
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.<br>
<blockquote cite="mid:20100325231149.GA15150@videolan.org" type="cite">
  <pre wrap=""></pre>
  <blockquote type="cite">
    <pre wrap="">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:   
<a class="moz-txt-link-freetext" href="http://trac.videolan.org/vlc/ticket/2533">http://trac.videolan.org/vlc/ticket/2533</a> where I also posted a comment.
You can find more details here:
<a class="moz-txt-link-freetext" href="http://techblog.unwiredappeal.com/2010/03/vlc-mms-start-delay-keep-alive-patch.html">http://techblog.unwiredappeal.com/2010/03/vlc-mms-start-delay-keep-alive-patch.html</a>
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Please, do another thread and attach the patch:
<a class="moz-txt-link-freetext" href="http://www.unwiredappeal.com/blogfiles/techblog/vlcmms.patch">http://www.unwiredappeal.com/blogfiles/techblog/vlcmms.patch</a>
but if this fixes 2533, it should be applied ASAP.

  </pre>
</blockquote>
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.<br>
<blockquote cite="mid:20100325231149.GA15150@videolan.org" type="cite">
  <blockquote type="cite">
    <pre wrap="">Thanks
    </pre>
  </blockquote>
  <pre wrap=""><!---->Thanks for your work.

Best Regards,

  </pre>
</blockquote>
</body>
</html>