<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2013/11/29 Arnaud Vrac <span dir="ltr"><<a href="mailto:rawoul@gmail.com" target="_blank">rawoul@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="HOEnZb"><div class="h5">On 29 nov. 2013, at 10:57, Duncan Palmer <<a href="mailto:dpalmer@digisoft.tv">dpalmer@digisoft.tv</a>> wrote:<br> <br> > Hi all,<br> ><br> > I'd like to make use of the hlsdemux work described in<br> > <a href="https://bugzilla.gnome.org/show_bug.cgi?id=698155" target="_blank">https://bugzilla.gnome.org/show_bug.cgi?id=698155</a> , and I'm running<br> > gstreamer 1.x. So, I've spent some time nosing around the changes<br> > introduced by 698155 with a view to figuring out what would be<br> > required to get this stuff rebased onto the 1.x HEAD. I'm hoping<br> > Andoni (the author), and maybe a few other people who may be familiar<br> > with this can comment on what I think needs to be done, as I'd say<br> > there's a good chance I may have missed a few things.<br> ><br> > From what I can see, the hlsdemux work was branched from the<br> > sdk-0.10.23-hls branch in Andoni's github repository about a year ago.<br> > After work on the hlsdemux branch finished, it was rebased onto some<br> > other branch. Since this time, much (but not all) of the hlsdemux work<br> > has been merged into the sdk-0.10.23-hls branch, and there have been<br> > additional bug fixes applied to this branch.<br> ><br> > Andoni, could you tell me what the story with the sdk-0.10.23-hls<br> > branch is, and whether it would be sensible to pull any bug fixes from<br> > this branch?<br> ><br> > I think as a starting point, Andoni's hlsdemux branch would need to be ported<br> > to 1.x, and all 1.x changes then merged in (if they still make sense), perhaps<br> > along with bug fixes from Andoni's sdk-0.10.23-hls branch. This would be quite<br> > a manual process. There are some complications;<br> > - Andoni's hlsdemux branch and the 1.x hlsdemux implementation both support<br> > decryption, but the implementations are conflicting. Also, the 1.x<br> > implementation relies on gnutls whilst the hlsdemux branch relies on openssl.<br> > I'd probably be inclined to stick with gnutls, to avoid the openssl license<br> > complications.<br> > - I think there are conflicting changes in m3u8.c<br> > - Refactoring of uridownloader into it's own library on 1.x. Should be<br> > straightforward to deal with.<br> ><br> > The hlsdemux branch creates hlsdemux as a bin, encapsulating a<br> > typefind element and a tsdemux, plus some elements for subtitle<br> > handling (haven't looked into it). I gather from the bug report that<br> > there is some disagreement over whether this is the right way to go.<br> > Could anyone enlighten me on the details?<br> ><br> > From what I can see, these are the reasons for the hlsdemux being a bin. Have I<br> > missed any?<br> > - To fiddle with the timestamps on SEGMENT events after a 'catch-up' seek to<br> > the head of a live window.<br> > - To ensure that no SEGMENT events produced by tsdemux make it downstream (does<br> > tsdemux actually produce it's own SEGMENT events - I haven't looked<br> > properly).<br> > - To facilitate the implementation of gst_hls_demux_drain_streams(); on a<br> > discontinuity, hlsdemux waits for the tsdemux to drain (and filters out the<br> > EOS event it sends), before sending a SEGMENT event.<br> ><br> <br> </div></div>Hi Duncan,<br> <br> 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.<br> </blockquote><div><br></div><div>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.<br> <br>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.<br> </div><div><br></div><div><br></div><div>Andoni<br></div><div><br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I have a proof of concept to illustrate this. I'll post it later today on github.<br> <span class="HOEnZb"><font color="#888888"><br> --<br> Arnaud<br> </font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br> gstreamer-devel mailing list<br> <a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br> <a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br> </div></div></blockquote></div><br><br clear="all"><br>-- <br>Andoni Morales Alastruey<br><br>LongoMatch:The Digital Coach<br><a href="http://www.longomatch.ylatuya.es">http://www.longomatch.ylatuya.es</a> </div></div>