<html>

  <head>

    <meta content="text/html; charset=ISO-8859-1"

      http-equiv="Content-Type">

  </head>

  <body bgcolor="#FFFFFF" text="#000000">

    Damnit, that was the wrong version of the patch (I split it into the

    proper one, attached, and the housekeeping patch I just sent).<br>

    <br>

    C<br>

    <blockquote cite="mid:4FC79F92.4060307@cam.ac.uk" type="cite">Hi,

      <br>

      <br>

      Here's the last patch in my list of HLS features I need, and which

      might be useful in general. This one is aimed at timeshifting

      scenarios: when a programme is being broadcast live, but

      nontheless a viewer arriving some minutes into the programme wants

      to start at the beginning, not the present moment. This matches

      with VLC's HLS output filter running with --keep-segments, which

      gradually assembles a VOD feed, which looks 'live' whilst the

      broadcast is in progress.

      <br>

      <br>

      I simply add a flag, --hls-start-beginning, which forces it to

      start at the first available segment regardless of whether the

      stream is live or not. Whilst I'm at it, I clean up ChooseSegment,

      since it did a bunch of pointless work for VOD streams before

      inevitably returning zero.

      <br>

      <br>

      The simplest form of this patch broke the download thread,

      however: this was because the DL thread was always greedy when

      running against a "live" stream, with potentially huge memory

      consumption for this kind of stream. It was probably that way

      because its wait condition was broken: it tried to wait for the

      playlist to get longer if appropriate, but it didn't re-check the

      list length, nor did the list-update thread signal it when the

      list changed. Instead it broke out of its wait loop and tried to

      download again whenever the playback pointer advanced.

      <br>

      <br>

      I fix this by correcting its wait condition: it now checks the

      playlist length under the correct lock, and uses a semaphore

      ("hls_download_t::check_stream") guarded by the download lock to

      learn when it should re-check the playlist length. The playlist

      update thread simply sets this flag whenever it refreshes the list

      (ideally this would be whenever it *changes*). In this way the

      download thread can obey its buffer cap of 6 segments even when

      dealing with live streams.

      <br>

      <br>

      Chris

      <br>

      <br>

      <fieldset class="mimeAttachmentHeader"></fieldset>

      <br>

      <pre wrap="">_______________________________________________

vlc-devel mailing list

To unsubscribe or modify your subscription options:

<a class="moz-txt-link-freetext" href="http://mailman.videolan.org/listinfo/vlc-devel">http://mailman.videolan.org/listinfo/vlc-devel</a>

</pre>

    </blockquote>

    <br>

  </body>

</html>