Custom Codec Having Trouble Negotiating Caps with Corrupted MP3

johnwesting john.blank.westing at gmail.com
Wed Feb 6 10:59:59 PST 2013


I have a custom codec and I'm having trouble negotiating capabilities
sometimes when linking to the flump3dec element. Executing the command: 



fails with:



However, when I run:



the song plays fine. 

I tested with other MP3s and my codec works fine. I placed the mp3parse
element before flump3dec and repeatedly get the error:



so it looks like it's a corrupted MP3. But why can alsasink handle the
corrupted file but my codec can't?

I am using GstBaseTransform as the base of my codec. I have implemented the
3 following caps-negotiation related functions:

1. transform_caps()
2. set_caps()
3. fixate_caps()

For transform_caps() I return the possible capabilities, not the negotiated
capabilities. In my case the possible capabilities is my opposite pad's
template, but take the intersect of the sample rate and the intersect of the
number of channels, and set those intersects in the other caps.

The error occurs before set_caps() and fixate_caps() are ever called. 

When using a non-corrupted MP3 the next call to my get_caps() function after
playback begins passes in a sink pad fixated capability. When using the
corrupted MP3 the next call to get_caps() after playback begins is not only
un-fixated, it's my source pad's capabilities. No more information is given
on the sink pad's capabilities after playback begins.

Please help. I want to support as many file formats as possible.




--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Custom-Codec-Having-Trouble-Negotiating-Caps-with-Corrupted-MP3-tp4658403.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.


More information about the gstreamer-devel mailing list