[gst-devel] qtdemux source caps bad on .MP4 file with MP3 audio payload?

[Edward Averill]

Ooops! Ok, I'm using gStreamer version 0.10.14, gst-plugins-base vesion 0.10.14 , gst-plugins-good version 0.10.6, no bad plugins.

I'll have to check to see if I can dump the errant file out somewhere on my website, I need to check with the creator to get permission first (gotta do the Right Thing).  Let me see what I can do.. might take a bit.

..ed..

> Subject: Re: [gst-devel] qtdemux source caps bad on .MP4 file with MP3 audio payload?
> From: t.i.m at zen.co.uk
> To: gstreamer-devel at lists.sourceforge.net
> CC: edaverill at hotmail.com
> Date: Thu, 6 Dec 2007 19:23:18 +0000
>
> On Thu, 2007-12-06 at 10:15 -0800, Edward Averill wrote:
>
>> Ok, I'm seeing some really odd qtdemux behavior in my development
>> here.
>
> You're not saying which versions of things (core/base/good/bad) you're
> using.
>
>> I have a .MP4 file that contains MP3 audio only. It plays fine in
>> VLC, which figures out it's MP3 audio.
>>
>> HOWEVER, when I run gst-launch using decodebin, it picks up qtdemux to
>> to the parsing (which is the Right Thing), but the caps it sets for
>> it's source pad say "mpegversion=(int)4" - which causes decodebin to
>> load up an AAC decoder! Things then go to heck in a handbasket,
>> because the AAC decoder has no clue what it's being fed and errors
>> out.
>>
>> This seems strange me.. I'd sure like to know why VLC understands that
>> it's an MP3 audio payload but qtdemux seems to guess wrong.
>>
>> Anyone have any ideas what's going on here? Could our MP3 decoder not
>> be setting its typefind properly?
>>
>> All help appreciated!
>
> The easiest thing would be to make a sample file available to us
> somewhere and then file a bug against gst-plugins-good; then we can
> check whether we can reproduce the problem with CVS of things or not
> (see http://gstreamer.freedesktop.org/bugs/ ).
>
> Cheers
> -Tim
>
>
>