<div dir="ltr"><div>Here is my select-tracks-for-object handler: <a href="https://pastebin.com/jTW1ZCgF">https://pastebin.com/jTW1ZCgF</a></div><div><br></div><div>The main idea is that I know the integer index of the audio stream I want (clip_data->target_stream), so I loop through the audio streams to find the stream_id based on the index. Once I know that stream_id, the timeline's track will only be returned if the stream_id of the track element matches.</div><div><br></div><div>--Chris<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 3, 2020 at 11:32 AM Chris Wine <<a href="mailto:chriswine@gmail.com">chriswine@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Thibault,</div><div><br></div><div>I am using 1.18.1 on Windows, the x64 mingw version. That code does look like it should be doing the correct thing; however all the audio pads on the uridecodebin are still being created in my case. Here's a piece of the graph that shows the uridecode bin in the GESAudioURISource connecting to the volume adjustment bin: <a href="https://imgur.com/a/JpBDBV9" target="_blank">https://imgur.com/a/JpBDBV9</a></div><div><br></div><div>--Chris<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 3, 2020 at 10:20 AM Thibault Saunier <<a href="mailto:tsaunier@gnome.org" target="_blank">tsaunier@gnome.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>Hello,</div><div><br></div><div>What you are doing is correct, and it used to be broken but should work just fine in 1.18 thanks to:</div><div><br></div><div><a href="https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/commit/09cc8dde0036420932704631f59531a1d84de018" target="_blank">https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/commit/09cc8dde0036420932704631f59531a1d84de018</a></div><div><br></div><div>What version of GStreamer are you using?</div><div><br></div><div>Regards,</div><div><br></div><div>- Thibault<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 2, 2020 at 9:40 PM Chris Wine <<a href="mailto:chriswine@gmail.com" target="_blank">chriswine@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi, I'm having a problem with selecting the correct audio stream from an input file that I'm using with GES. The input file has 1 video stream and 4 identical (as far as the CAPS are concerned) audio streams. I am currently using GStreamer/GES mingw x64 1.18.1 on the Windows platform.<br></div><div><br></div><div>As the documentation suggested, I wrote a signal handler for the GESTimeline's "select-tracks-for-object" signal, and I've verified that it is working as expected with returning a NULL for GESTrackElements that are not the audio stream I want, while returning a GPtrArray with the timeline's audio track when it is the audio stream I want.</div><div><br></div><div>The problem though is that only the 1st audio stream of the input file is ever chosen for the output. I've been looking through the GES source code, and it appears that when 
<code><span>ges_source_create_topbin</span> <span></span></code> in GESSource is called for the audio, it will always just look for the first pad created when the "pad-added" signal is on uridecodebin is called; this made me wonder if something in the creation of uridecodebin itself was supposed to be responsible for selecting the correct audio stream. However, the only thing I can find there is the "caps" property which does restrict the streams, but since my 4 audio streams all have identical CAPS, this doesn't end up being a restriction.</div><div><br></div><div>My question is first, am I missing something obvious that would make this work as expected? If not, aside from code changes to GESSource/UriSource/AudioUriSource, is there something tricky I can do like finding the uridecodebin, intercepting the pad-added signal before it gets to the GESSource, and only letting it through when getting to the pad that I want to be connected?</div><div><br></div><div>Thank you, responses are much appreciated.</div><div>--Chris<br></div></div>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr"><div dir="ltr"><font color="#888888">Thibault Saunier, Igalia - <a href="http://www.igalia.com" target="_blank">www.igalia.com</a><a href="http://www.centricular.com" rel="noreferrer" target="_blank"><span></span></a></font></div></div></div>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</blockquote></div>
</blockquote></div>