[gstreamer-bugs] [Bug 149158] [qtdemux/faad] MP4 file encoded Nero AAC Codec 2.6.2.0 is not played

[bugzilla-daemon at bugzilla.gnome.org]

Please DO NOT reply to this by email. All additional comments should be made in
the comments box of this bug report.

 http://bugzilla.gnome.org/show_bug.cgi?id=149158
 GStreamer | gst-plugins | Ver: 0.8.4





------- Additional Comments From Maciej Katafiasz  2005-02-15 21:30 -------
If I'm not mistaken, I have found the cause of this bug, and it's gonna get
ugly. The reason is as follows: sometimes, there will be something like 210
bytes of data in muxed stream, but only 209 of this will get consumed by faad.
Now here's the problem: we will save that byte (in fact, we won't even know
about it, it'll look like the rest of buffer) and pass it to faad, while in fact
it's spurious NULL[0] value, which will distort real data and cause faad to
barf. We have no way to know about that, as all we get is single contigous 4K
buffer, not series of 200-something byte chunks. 

MPlayer gets around this because they're tangled mess, and explicitly call
demuxer from inside decoder, which is supposed to know about every possible
codec, and then return *packetised* (as it's inside container) AAC data in nice
chunks. So, they also pass 210 bytes of which 209 is consumed and spurious NULL
appended, but they don't even notice that because next decode will operate on
next pulled chunk, which again starts with real data and so NULLs are simply
skipped. It's cheap for them to get chunk-by-chunk, as it's only 3 or 4 nested
simple funcalls.

However, we don't operate this way. Our decoders don't call directly into
demuxers, so getting data exactly when needed is not that easy. So the solution
would be to either somehow know beforehand which bytes in buffer are "fake",
which I don't think is possible for demuxer, as it's, uh, the decoder's job to
interpret the data, and demuxer only passes what *is* in stream[1]; or to pass
around ridiculously small buffers, sized of single 200 bytes chunk, but that's
going to generate insane amounts of context switches. Dunno what's be good way
out here.

[0] In fact I don't know if it's necessarily NULL, I only worked on that mkv I
linked above, where it is NULL indeed.

[1] I'd like to know why the hell it's there, the spurious NULL. If it's
supposed to be some padding, then it doesn't work so hot... Maybe there is some
info about those bytes which would allow us to strip them off before inserting
into outbuffer, that would be perfect.

------- You are receiving this mail because: -------
You are the assignee for the bug.
You are the QA contact for the bug.