New, also help on dealing with multiple audio streams using gstreamer-rs

[Michael Johnson]

Regardless, if you want to press a button to change audio stream surely you
emit when the button is pressed, which then causes the callback to run

Without that it only emits on startup and close. And that's not helpful

Thank you for all your help so far, it's been highly appreciated

On Thu, 17 Dec 2020, 13:50 Michael Johnson, <liquidmikerrs at gmail.com> wrote:

> Oh wait I see what you mean about the first point. My eyes can't see a
> minus sign apparently :P
>
>
>
> On Thu, 17 Dec 2020, 13:49 Michael Johnson, <liquidmikerrs at gmail.com>
> wrote:
>
>> All those warnings are related to not handling the None type, I didn't
>> think that would have any bearing.
>>
>> Wait. You're not supposed to use emit? Then why does it exist? Surely you
>> emit a signal to then be caught by the connect. By the logic of setting the
>> value of 2 every them then current audio should go -1,-1,2 not -1,-1,-1. It
>> yields 2 on exit. Which was my point
>>
>> What is the alternative to using emit then, and why does the alternative
>> still relate to connect?
>>
>> On Thu, 17 Dec 2020, 13:36 Sebastian Dröge, <sebastian at centricular.com>
>> wrote:
>>
>>> On Thu, 2020-12-17 at 12:28 +0000, Michael Johnson wrote:
>>>
>>> As requested a toy example,
>>> Here we see that the audio-changed emit never activates the connect,
>>> maybe because it emits before the video has began playing?
>>>
>>> I'm probably doing something very wrong
>>>
>>>
>>> Yeah, you're ignoring compiler warnings here that tell you that you're
>>> ignoring potential errors :)
>>>
>>> Make sure to at least `unwrap()` `Result`s instead of ignoring them,
>>> then you immediately know if you did something wrong there.
>>> In this case the emitting of the "audio-changed" signal fails because of
>>> the wrong number of arguments.
>>>
>>> But that also doesn't matter here: that signal is supposed to be emitted
>>> by playbin whenever something changes, not by you.
>>>
>>> After removing that line what I get is
>>>
>>> current audio track is -1
>>> number of audio tracks is 1
>>> current audio track is -1
>>> number of audio tracks is 2
>>> current audio track is -1
>>> number of audio tracks is 3
>>>
>>> That looks as expected. Every signal emission you're setting the current
>>> audio track to 2, but only the last time there actually is a 3rd (0, 1, 2)
>>> audio track available.
>>> So in the end it should use the 3rd audio track.
>>>
>>> If you change it for example to set it to 1 then you'll see that during
>>> the last signal emission the current audio track is 1.
>>>
>>>
>>> For getting state into the signal handler closure, take a look at the
>>> overlay-composition.rs example and what it does with the DrawingContext
>>> inside the Arc<Mutex<_>> there.
>>>
>>> --
>>>
>>> Sebastian Dröge, Centricular Ltd · https://www.centricular.com
>>> <http://www.centricular.com>
>>>
>>> _______________________________________________
>>> gstreamer-devel mailing list
>>> gstreamer-devel at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20201217/a0c96602/attachment-0001.htm>