GNOME Bugzilla – Bug 308980
gst-typefind incorrectly identifies m4a files encoded with faac
Last modified: 2005-07-01 17:42:07 UTC
Please describe the problem: Files encoded using faac version 1.24 or 1.24+ fail to be recognized as audio/x-m4a. Instead, the files are shown to be video/quicktime. The file plays fine using totem-gstreamer, but does not load into rhythmbox. Steps to reproduce: 1. encode the wav file using the faac encoder with the options -w -o file.m4a file.wav -q 130 --mpeg-vers 4 --no-midside --artist artist --album album --title title --track track --genre genre --year 1999 2. run gst-typefind file.m4a 3. Actual results: file.m4a - video/quicktime Expected results: should output file.m4a - audio/x-m4a Does this happen every time? Yes Other information: Here's the output when using the following command: gst-launch-0.8 -v filesrc location=file.m4a ! spider ! osssink RUNNING pipeline ... /pipeline0/filesrc0.src: caps = application/octet-stream /pipeline0/spider0/sink_ident.sink: caps = application/octet-stream /pipeline0/filesrc0.src: active = TRUE /pipeline0/spider0/sink_ident.sink: active = TRUE /pipeline0/spider0/sink_ident.src: active = TRUE /pipeline0/spider0/src_0.sink: active = TRUE /pipeline0/spider0/src_0.src: active = TRUE /pipeline0/osssink0.sink: active = TRUE /pipeline0/filesrc0.src: caps = video/quicktime /pipeline0/spider0/sink_ident.sink: caps = video/quicktime /pipeline0/spider0/sink_ident.src: caps = video/quicktime /pipeline0/spider0/qtdemux0.sink: caps = video/quicktime /pipeline0/spider0/qtdemux0.sink: active = TRUE /pipeline0/spider0/qtdemux0.audio_00: active = TRUE /pipeline0/spider0/qtdemux0.audio_00: caps = audio/mpeg, mpegversion=(int)4, rate=(int)44100, channels=(int)2 /pipeline0/spider0/faad0.sink: caps = audio/mpeg, mpegversion=(int)4, rate=(int)44100, channels=(int)2 /pipeline0/spider0/faad0.sink: active = TRUE /pipeline0/spider0/faad0.src: active = TRUE /pipeline0/spider0/src_0.src: caps = audio/x-raw-int, signed=(boolean)true, width=(int)16, depth=(int)16, rate=(int)44100, channels=(int)2, channel-positions=(GstAudioChannelPosition)< GST_AUDIO_CHANNEL_POSITION_FRONT_LEFT, GST_AUDIO_CHANNEL_POSITION_FRONT_RIGHT >, endianness=(int)1234 /pipeline0/osssink0.sink: caps = audio/x-raw-int, signed=(boolean)true, width=(int)16, depth=(int)16, rate=(int)44100, channels=(int)2, channel-positions=(GstAudioChannelPosition)< GST_AUDIO_CHANNEL_POSITION_FRONT_LEFT, GST_AUDIO_CHANNEL_POSITION_FRONT_RIGHT >, endianness=(int)1234 /pipeline0/spider0/faad0.src: caps = audio/x-raw-int, signed=(boolean)true, width=(int)16, depth=(int)16, rate=(int)44100, channels=(int)2, channel-positions=(GstAudioChannelPosition)< GST_AUDIO_CHANNEL_POSITION_FRONT_LEFT, GST_AUDIO_CHANNEL_POSITION_FRONT_RIGHT >, endianness=(int)1234 /pipeline0/spider0/src_0.sink: caps = audio/x-raw-int, signed=(boolean)true, width=(int)16, depth=(int)16, rate=(int)44100, channels=(int)2, channel-positions=(GstAudioChannelPosition)< GST_AUDIO_CHANNEL_POSITION_FRONT_LEFT, GST_AUDIO_CHANNEL_POSITION_FRONT_RIGHT >, endianness=(int)1234
Correction, running Gstreamer 0.8.9
Please attach the file.
Figured it out. Apparently the file type ID header file for faac encoded files wrapped within the mp4 header is "ftypmp42". Don't know if this is the correct way to edit it, but I added the following patch. (probably not in correct patch format) --- gsttypefindfunctions.c 2005-06-25 00:37:04.825190208 -0500 +++ gsttypefindfunctions.c 2005-06-25 01:36:13.128766072 -0500 @@ -964,6 +964,9 @@ if (data && memcmp (data, "ftypM4A ", 8) == 0) { gst_type_find_suggest (tf, GST_TYPE_FIND_MAXIMUM, M4A_CAPS); } + if (data && memcmp (data, "ftypmp42", 8) == 0) { + gst_type_find_suggest (tf, GST_TYPE_FIND_MAXIMUM, M4A_CAPS); + } } /*** application/x-3gp *********************************************/
Created attachment 48309 [details] mp4 file Here's the m4a file created with faac using the options mentioned above, especially the -w option which wraps the raw aac in a mp4 header.
Opps, its not a Gstreamer core bug, but rather a bug in gst-plugins in /gst/typefind/. Sorry for the initial confusion it may have caused.
Applied differently, thanks.