Porting the hlsdemux work in issue 698155 to 1.x

[Sebastian Dröge]

On Mo, 2013-12-02 at 09:48 +0000, Duncan Palmer wrote:
> 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.

hlsdemux is in gst-plugins-bad, so that can be changed as necessary. No
need to create a hlsdemux2, and changing it to a bin is really not a
problem :)

However there was some disagreement of putting demuxers into hlsdemux,
which IIRC Andoni's changes do. That's something that needs to be solved
first.

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

We should IMHO support both, and let configure decide which one to use.
OpenSSL has license problems (namely its license is GPL incompatible)
but is FIPS 140-2 certified (which is required in some environments),
while GnuTLS has an unproblematic license (LGPL) but is not certified.

Another alternative would be the nss from Mozilla, which is MPL/GPL
licensed and is certified.

-- 
Sebastian Dröge <sebastian at centricular.com>
Centricular Ltd - http://www.centricular.com
Expertise, Straight from the Source
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20131202/1169df9a/attachment.pgp>