Porting the hlsdemux work in issue 698155 to 1.x

Mon Dec 2 01:21:50 PST 2013

On 30 nov. 2013, at 17:33, Arnaud Vrac <rawoul at gmail.com> wrote:

> On 29 nov. 2013, at 21:30, Duncan Palmer <dpalmer at digisoft.tv> wrote:
>
>> 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.
>
> Hi Duncan,
>
> I had already ported the most important patches to master, I've posted them here:
> https://github.com/rawoul/gst-plugins-bad/commits/hls

Thanks Arnaud, I'll take a look at that.

On 2 December 2013 08:59, Sebastian Dröge <sebastian at centricular.com> wrote:
> On So, 2013-12-01 at 19:52 +0100, Andoni Morales wrote:
>> 2013/11/29 Arnaud Vrac <rawoul at gmail.com>
>>
>> > 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 see it in a completely different way, having to expose all the pads is a
>> hack to workaround the lack of a proper stream selection API. If a stream
>> has Video,  Audio and Text, the element should only expose 3 pads and the
>> stream selection API should provide a way to select which alternative
>> stream you want to activate (like a different bitrate or a different
>> language) , similar to what decodebin does with properties and what the
>> element does right now, making it easier to port it to this future API.
>>
>> Exposing all pads for the audio alternatives, means you also have to expose
>> pads for each video bitrate (or for each encoding type like it might happen
>> in DASH when you have not only several languages, but also several encoding
>> options like AAC or AC3). The other issue with exposing one pad for each
>> stream configuration is that you could potentially connect to any of the
>> pads and expect to get data, which is not the case as you have cached
>> content, and  you could also try to download the same video stream for
>> different bitrates and audio languages at the same time,  making it quite
>> hard to manage internally, which is by the way a use case that's not
>> described in the spec and shouldn't even be considered for this element.
>
> Yes, we should really implement a proper stream selection interface
> instead of such solutions. This will also be needed for other adaptive
> streaming solutions like DASH and Smooth Streaming, but is also useful
> for e.g. DVD playback.
>
> The idea would then be that playbin/uridecodebin/decodebin can proxy
> their properties (e.g. current-audio) and other parts of the interface
> to the demuxers and sources that implement this new interface, and also
> aggregate all the streams that these elements provide in their own
> interface.
>
> There should be a bug about this already in Bugzilla.
>
> --
> Sebastian Dröge <sebastian at centricular.com>
> Centricular Ltd - http://www.centricular.com
> Expertise, Straight from the Source
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>