Porting the hlsdemux work in issue 698155 to 1.x

[Arnaud Vrac]

On 29 nov. 2013, at 10:57, Duncan Palmer <dpalmer at digisoft.tv> wrote:

> Hi all,
> 
> I'd like to make use of the hlsdemux work described in
> https://bugzilla.gnome.org/show_bug.cgi?id=698155 , and I'm running
> gstreamer 1.x. So, I've spent some time nosing around the changes
> introduced by 698155 with a view to figuring out what would be
> required to get this stuff rebased onto the 1.x HEAD. I'm hoping
> Andoni (the author), and maybe a few other people who may be familiar
> with this can comment on what I think needs to be done, as I'd say
> there's a good chance I may have missed a few things.
> 
> From what I can see, the hlsdemux work was branched from the
> sdk-0.10.23-hls branch in Andoni's github repository about a year ago.
> After work on the hlsdemux branch finished, it was rebased onto some
> other branch. Since this time, much (but not all) of the hlsdemux work
> has been merged into the sdk-0.10.23-hls branch, and there have been
> additional bug fixes applied to this branch.
> 
> Andoni, could you tell me what the story with the sdk-0.10.23-hls
> branch is, and whether it would be sensible to pull any bug fixes from
> this branch?
> 
> I think as a starting point, Andoni's hlsdemux branch would need to be ported
> to 1.x, and all 1.x changes then merged in (if they still make sense), perhaps
> along with bug fixes from Andoni's sdk-0.10.23-hls branch. This would be quite
> a manual process. There are some complications;
> - Andoni's hlsdemux branch and the 1.x hlsdemux implementation both support
>  decryption, but the implementations are conflicting. Also, the 1.x
>  implementation relies on gnutls whilst the hlsdemux branch relies on openssl.
>  I'd probably be inclined to stick with gnutls, to avoid the openssl license
>  complications.
> - I think there are conflicting changes in m3u8.c
> - Refactoring of uridownloader into it's own library on 1.x. Should be
>  straightforward to deal with.
> 
> The hlsdemux branch creates hlsdemux as a bin, encapsulating a
> typefind element and a tsdemux, plus some elements for subtitle
> handling (haven't looked into it). I gather from the bug report that
> there is some disagreement over whether this is the right way to go.
> Could anyone enlighten me on the details?
> 
> From what I can see, these are the reasons for the hlsdemux being a bin. Have I
> missed any?
> - To fiddle with the timestamps on SEGMENT events after a 'catch-up' seek to
>  the head of a live window.
> - To ensure that no SEGMENT events produced by tsdemux make it downstream (does
>  tsdemux actually produce it's own SEGMENT events - I haven't looked
>  properly).
> - To facilitate the implementation of gst_hls_demux_drain_streams(); on a
>  discontinuity, hlsdemux waits for the tsdemux to drain (and filters out the
>  EOS event it sends), before sending a SEGMENT event.
> 

Hi Duncan,

While some of the patches would be welcome to be ported to gstreamer 1.x, I think the choices Andoni made to support multiple renditions are not best suited to the gstreamer architecture. Ideally I think all the possible tracks should exposed as pads, instead of having to change a demux property to switch audio or subtitle tracks. The issue with the proper design is that you need a stream selection API, which has been talked about some time before. Without this API, all streams would be downloaded at the same time when used in a decodebin environment.

I have a proof of concept to illustrate this. I'll post it later today on github.

-- 
Arnaud