Porting the hlsdemux work in issue 698155 to 1.x

Mon Dec 2 03:51:22 PST 2013

2013/12/1 Andoni Morales <ylatuya at gmail.com>

>
>
>
> 2013/11/29 Duncan Palmer <dpalmer at digisoft.tv>
>
>> 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?
>>
> Hi Duncan,
>
> The latest work is in the following branch:
> https://github.com/fluendo/gst-plugins-bad/tree/sdk-0.10.23-hls, which is
> just a rebase of the patches submitted submitted in the bug report on top
> of the sdk branch plus more patches fixing issues we have found on the way.
>
>
>>
>> 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.
>>
>
> You are missing here the most important point which is allowing to filter
> out the audio stream from the main muxed video/audio and use the audio from
> the alternative rendition when  it's being activated.
>
> Honestly, I don't think you can try to rebase this branch on top of the
> current master, it has diverged so much that it would be impossible to
> apply those patches separately. Also, the design of the element is
> completely different and even though it's an element in -bad where you can
> change its API there should probably be an hlsemux2. This would make things
> much simpler, as you could  directly port this element to 1.x instead of
> trying to rebase the patches, which I think it's not currently a viable
> option.
>
> If I had to port everything to 1.x I would also change a few things too
> that were more hard to handle in 0.10. There is one thing specially  that
> complicates the design *a lot*, which is the fact that you have to create a
> new decoding chain for decodebin when the stream topology changes (when you
> go from Vidieo/Audio to Audio only or when you activate the subtitles
> track). This means that each time a pad is deactivated or activated you
> have to flush everything, remove all the pads, create new pads and signal
> no-more-pads so that decodebin knows about the new decoding chain with the
> new topology. An that's specially complicated with this element because you
> have cached fragments, which means that when you activate the subtitles
> pad  or you move to an audio-only stream, the topology does not change
> straight away, but when downstream has consumed the cached fragments and it
> starts processing the one that changes everything. This also forces you to
> treat fragments sequentially, and right now the streaming has to create up
> to 3 more threads to push the audio/video fragment, the alternative audio
> if present and the subtitles fragment if present.
>
> I think 1.x can help a lot in improving this situation with the support
> for sparse streams.
>

Sebastian, do you think we could use the support for sparse streams in 1.x
to make all of that easier to handle?
I was thinking that it could be possible to expose all the pads for the
streams after parsing the playlist (Video, Audio, Subtitles, if any) and
than use stream-start stream-stop instead of recreating the decoding chain
when the topology changes. Would that work?

Andoni

>
> Cheers,
> Andoni
>
>>
>> Any comments much appreciated.
>>
>
>
>
>> Regards,
>> Dunk.
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>
>
>
> --
> Andoni Morales Alastruey
>
> LongoMatch:The Digital Coach
> http://www.longomatch.ylatuya.es
>

-- 
Andoni Morales Alastruey

LongoMatch:The Digital Coach
http://www.longomatch.ylatuya.es
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20131202/cb221ab8/attachment-0001.html>