Porting the hlsdemux work in issue 698155 to 1.x

[Duncan Palmer]

Thanks Arnaud. I'd be interested in looking at your proof of concept.
I would prefer any work I do to be suitable for inclusion in the
mainline.

On 29 November 2013 11:48, Arnaud Vrac <rawoul at gmail.com> wrote:
> 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
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel