GNOME Bugzilla – Bug 770469
aacparse converts mpeg2 aac to mpeg4 aac unconditionally
Last modified: 2018-11-03 15:11:11 UTC
Created attachment 334261 [details] TS file with mpeg2 aac audio aacparse element always converts mpeg2 aac to mpeg4 aac though it should support mpeg2aac parsing as per the src & sink caps. I have attahced the file. Following gst-launch pipeline demonstrates it on 1.9.1 on windows e:\gstreamer\1.0\x86\bin>gst-launch-1.0.exe filesrc location=c:/temp/out.ts ! tsdemux ! aacparse ! fakesink -v Setting pipeline to PAUSED ... Pipeline is PREROLLING ... /GstPipeline:pipeline0/GstAacParse:aacparse0.GstPad:sink: caps = audio/mpeg, mpegversion=(int)2, stream-format=(string)adts /GstPipeline:pipeline0/GstAacParse:aacparse0.GstPad:src: caps = audio/mpeg, framed=(boolean)true, mpegversion=(int)4, level=(string)2, base-profile=(string)lc, profile=(s tring)lc, rate=(int)48000, channels=(int)2, stream-format=(string)adts /GstPipeline:pipeline0/GstFakeSink:fakesink0.GstPad:sink: caps = audio/mpeg, framed=(boolean)true, mpegversion=(int)4, level=(string)2, base-profile=(string)lc, profile=( string)lc, rate=(int)48000, channels=(int)2, stream-format=(string)adts Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Got EOS from element "pipeline0". Execution ended after 0:00:00.013933636 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ...
This is very confusing. Discoverer says: container: MPEG-2 Transport Stream audio: MPEG-2 AAC audio: MPEG-4 AAC video: H.264 Properties: Duration: 0:00:12.589853592 Seekable: yes Tags: audio codec: MPEG-2 AAC video codec: H.264 So it's MPEG-4 AAC inside MPEG-2. https://wiki.multimedia.cx/index.php?title=ADTS says bit 0x8 in the second byte should be 1 for MPEG-2 AAC, and 0 for MPEG-4 AAC. It happens to be 0 here, pointing to MPEG-4. This is also what the discoverer uses to detect 2 and 4. Now, the caps saying mpegversion=2 are set by tsdemux, not by aacparse nor the discoverer. tsdemux.c:1575 sets it to 2 unconditionally, without caring for that 0x8 bit. So I think it's tsdemux that's wrong here, and the audio really is MPEG-4, despite being in MPEG-2. There doesn't seem to be obvious access to the data to check bit 0x8 where this is done in tsdemux, I'll have to investigate how to get at it.
https://en.wikipedia.org/wiki/Program-specific_information points to 0x0f being AAC/ADTS MPEG-2, and that's what we seem to get here. It looks like something put MPEG4 AAC in, tagged as MPEG2. However, that list does not include any MPEG-4 AAC, so this may be some backward compatibility shoehorning, hard to tell.
Also, mediainfo reports version 4 as well: Format : AAC Format/Info : Advanced Audio Codec Format version : Version 4 Format profile : LC Muxing mode : ADTS Codec ID : 15
Well, that probably means that tsdemux reports it wrong... or it's written wrong into that stream.
The issue is with the stream itself. But I have found an interesting thing while debugging https://bugzilla.gnome.org/show_bug.cgi?id=770704 Whenever there is codec_data(the stream-format be raw or adts), aacparse converts mpeg2 aac and mpg4aac. If not, it retains the mpeg version
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/294.