Dolby Digital Plus decoder / QuickTime MP4 demuxer
Dolby Digital Plus decoder / QuickTime MP4 demuxer
- Subject: Dolby Digital Plus decoder / QuickTime MP4 demuxer
- From: Chris McGrath <email@hidden>
- Date: Fri, 17 Dec 2010 10:09:18 +1100
Hi all,
I'm writing an AudioCodec component to decode Dolby Digital Plus, based on ACSimpleCodec.cpp and its parent classes.
I'm having trouble getting QuickTime to play files using the mp4 container (generally .m4v) which include ec-3 audio streams. DDPlus is a superset of Dolby Digital, so I have been able to test first using Dolby Digital (ac-3) files.
Using the more basic Dolby Digital format,
#define COMP_SUBTYPE 'ac-3'
my decoder works (albeit with workarounds because I have to guess which channel layout quicktime is expecting me to return. QuickTime communicates
channel layout information with the wrong instance of the decoder, not one that actually does any decoding, but luckily my use-case is only mp4
files so I can hard-code in the channel layout that QuickTime's mp4 demuxer reports), however when I switch over to the subtype 'ec-3', things stop working.
I've examined the process of how my decoder gets loaded and used by stepping through gdb while attached to the QTKitServer process. My understanding is (roughly) as follows:
a) QuickTime creates an instance of the decoder, querying it using GetProperty to find out various bits of information, including
- name of the format (AC3 / EAC3)
- supported output formats
- max packet byte size
- output format the decoder is set to
- input format the decoder is expecting
- and so on
b) QuickTime initializes the decoder, calling the Initialize method
c) QuickTime calls the AppendInputData method, giving the decoder packet(s) of data which get thrown into my ring buffer
d) QuickTime calls the ProduceOutputPackets method, and the decoder does its magic, giving the decoded audio as LPCM back to its caller
When using the 'ac-3' format, my decoder works as described above. With the 'ec-3' format, it carries out steps a) and b) but "gives up" afterwards - it proceeds
exactly as expected but then it is never given any data to work with.
QuickTime seems to have some basic 'ac-3' capabilities - when I remove my decoder from the system, the Movie Inspector still reports information on the file
(format, channel layout, sample rate, data rate). Without an 'ec-3' decoding component, QuickTime throws an error message, not attempting to open a file. With one,
the file is opened and the Movie Inspector displays E-AC3 (after querying my component for the name of the format) however it falls back on the default number of channels
listed in the MP4 container (listed as 2, for backwards compatibility. Presumably, if the mp4 demuxer understood 'ec-3' it would be able to decode the header and find
the file actually contains 6 channels).
Does QuickTime "give up" on an AudioCodec component if it queries it with GetProperty and gets information it doesn't like? (This hypothesis seems unlikely to me,
as the two components behave the same [with the exception of the reported number of channels] all the way up until before AppendInputData is called).
Is my 'ac-3' decoder working only because of QuickTime's inherent support for the format? (Although QuickTime doesn't include a decoder, it seems to include a .ac3 importer).
Is it possible that I may need to write a MovieImport component to support the format? (I didn't think this was necessary as I'm not using 'ec-3' elemental
streams, only streams inside the MP4 container).
Is there something I am missing / misunderstand in this whole process?
I can confirm that my tests files play in correctly VLC, as well as with the DirectShow filter I've written to do the same task under Windows.
Thanks very much,
Chris.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden