<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2013/12/2 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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im">On Sun, Dec 1, 2013 at 7:52 PM, Andoni Morales <span dir="ltr"><<a href="mailto:ylatuya@gmail.com" target="_blank">ylatuya@gmail.com</a>></span> wrote:</div>
<div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div>2013/11/29 Arnaud Vrac <span dir="ltr"><<a href="mailto:rawoul@gmail.com" target="_blank">rawoul@gmail.com</a>></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<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></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.</div>
</div></div></div></blockquote><div><br></div></div><div>I think it would be confusing to mix renditions of multiple streams. Normally the currently playing stream is _only_ determined by the demuxer, based on the available bandwidth. The multiple streams should not be exposed to the user, he should only be able to force the available bandwidth (which is already possible with the connection-speed property). So if the demuxer decided to play the low bitrate stream with audio only, downstream shoudn't see any video pad. You wouldn't be able to play it properly anyway because of bandwidth limitations.<br>
</div><div><br></div><div>With that in mind, all renditions of the currently playing stream can be exposed as pads. The problem is that you only want to download the data of the renditions that are currently playing, which is not possible with the current decodebin.</div>
<div><br></div><div>Does it make sense ?</div></div></div></div></blockquote><div><br></div><div>Language is also selected automatically and could not be exposed to the user either :) You can disable the automatic bitrate switching and let the user decide which bitrate to play. It's a bit awkward to play with connection-speed for the stream bitrate selection and the current API should probably be changed for this purpose. If you look at the latest changes, the list of streams is flatten and bitrates are grouped by stream ID, which we use in our player to group the available bitrates for each stream.<br>
</div><div class="gmail_quote">You have to note that other protocols like DASH do not only offer different bitrates for the same video stream, but also different encoding types and different views, that's why I think exposing all pads is not a good idea and their should be only one pad for video and a stream selection API supporting groupings for streams with different configurations.<br>
<br><br></div><div class="gmail_quote">Cheers,<br>Andoni<br></div><div class="gmail_quote"><span class="HOEnZb"><font color="#888888"><br><div>-- </div><div>Arnaud</div></font></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>_______________________________________________<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>
<br></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>