[Gambas-user] gb.media : receiving GStreamer element messages

[Adrien Prokopowicz]

Le Thu, 14 May 2015 00:07:48 +0200, Benoît Minisini  
<gambas at ...1...> a écrit:

> Le 11/05/2015 02:52, Adrien Prokopowicz a écrit :
>> Hello everyone,
>>
>> So I wanted to play a bit with the "spectrum" GStreamer element.
>> After reading the documentation, I noticed that it used "element  
>> messages"
>> to send the spectrum data to the application, but gb.media does not have
>> an interface to catch these.
>>
>> I made a quick and dirty patch at first, but I think that after some
>> cleanup
>> it would be nice to share. So here it is (see the attached patch).
>> (I named the data class MediaData here, but I think there might be
>> a better name for it.)
>>
>> In order to see it in action, I made a small application that shows
>> the spectrum of an audio file while playing it.
>> It also tweaks the data to look nicer on the visualizer (basically
>> changing the frequency scale to a logarithmic one, and smoothing the
>> result),
>> but you can disable it in the configuration menu if you want.
>>
>> The app itself is completely useless, but I find it quite fun to watch.
>> However, processing and rendering the data takes a significant amount of
>> power, so it might lag if you have a small CPU.
>> If it lags too much for you, you can lower some rates in the
>> SpectrumPlayer class.
>>
>> What do you think ?
>>
>> Regards,
>>
>>
>
> Cool. Can you change a bit your implementation so that is it more  
> generic?
>
> The idea is replacing the Data event and the MediaData object by a
> Message event and a MediaMessage object.
>
> Instead of testing GST_MESSAGE_ELEMENT, you check before the switch that
> the Message event is implemented (with GB.CanRaise), and then you send
> the event handler a newly create MediaMessage object.
>
> The MediaMessage object is exactly like your MediaData object, except
> that you can add the Type property for the message type, and constants
> in the MediaMessage class (or in the Media class) for each message type.
> And in the future we'll be able to add other methods if needed.
>
> If can you do the change, just commit it directly. Easier for me to
> check that way!
>
> Regards,
>

I like the idea, the only problem is that there already is a message event
that handles error/warning/info messages, so we'll have to find another
name, I guess.

If I don't stumble upon any other incompatibility problem, I should be able
to commit that tomorrow.

Regards,

-- 
Adrien Prokopowicz