Re: AAC trouble, was Re: [xine-devel] xine CVS core-dumps playing QT movie

[James S. <jst...@us...>]

Hi Mike,

On Tue, 1 Jun 2004 19:30:01 -0600 (MDT), "Mike Melanson"
<mel...@pc...> said:
> 	Certain QT files have WAVEFORMATEX headers, usually when the data
> is supposed to be handled by a MS-style Win32 codec. Atom type is 'wave'.
> Audio fourcc is usually something like ('m','s', 0x00, 0x55) which
> denotes MS audio format 0x0055 (MP3 audio).

The qt demuxer always sends a waveformatex header. Btw the other James
has pointed out a bug in the code:

    /* FIXME from jcdutton: Shouldn't this be a memcpy ? */
    /* I don't know enough about this Quicktime demuxer to be sure */
    buf->content = (void *)&audio_trak->properties->audio.wave;
    buf->size = sizeof(audio_trak->properties->audio.wave);
    this->audio_fifo->put (this->audio_fifo, buf);
 
> 	Well, there was already a convention for conveying this
> information from a demuxer to libfaad:
[...]
> The QT demuxer adheres to it, as does the Real demuxer. Using the same
> API in the AVI demuxer might not have resulted in such a large rewrite in 
> the libfaad glue code, if any at all. 

The rewrite was largely independent of supporting the data coming as part
of the waveformatex header. As I said before the code was a mess, it's
now cleaner and simpler, where's the harm in that?

Besides, I think it's best to avoid codec specific code in the demuxers
where possible.

> BTW, does AAC-in-Real still work?

Yes, it doesn't send a broken header.

James.