Porting the hlsdemux work in issue 698155 to 1.x

[Duncan Palmer]

On 1 December 2013 11:57, Andoni Morales <ylatuya at gmail.com> wrote:

> 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.

Thanks Andoni.

>
> 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.

I agree that it looks like any patches which have gone into the mainline won't
apply to a rebased version of the new hsldemux work. However, I was guessing
that there would be value in manually applying the fixes in some of
these patches.

Because of the changes in the behaviour of the hlsdemux element
(particularly the
fact that it's a bin now), it makes sense to create a hlsdemux2 so
users of hlsdemux
aren't surprised.

Have you any opinion in the choice of openssl vs. gnutls?

>
> 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.

ok. I didn't fully understand what was going on there - this makes
more sense now.