[FFmpeg-devel] [PATCH] QCELP decoder

[Reynaldo H. Verdejo Pinochet]

Hello

Baptiste Coudurier wrote:
> 
> Frame_s_ ? Or a single frame ?
> 

Right now, frame, but I'm unsure about the correct answer
to your question here because the decoder obviously decodes
a huge number of codec frames per file.

>>> packets/chunks like it is told to, there is no more cruft to add to
>>> mov demuxer.
>> As this seems to be a MOV specific 'feature' I guess adding the 
>> needed code there makes some sense. I don't see why the demuxer would
>> be passing junk to the decoder. Please correct me if I'm just wrong.
> 
> I didn't follow the whole thread, are we talking about junk or multiple
> frames per packet ?

Summing it up there is one little change to account for padding junk at
the end of frames, This is not something you would find in the QCELP
spec but it was empirically discovered while decoding some of our
mov samples. That's the current issue under discussion. The rtp bundled
data frame stuff (http://www.rfc-editor.org/rfc/rfc2658.txt) hasn't been
accounted for yet, I'd expect that to follow a similar crossroad though,
either adding those changes to the rtp code or have a parser written.
The .qcp (QCELP in RIFF) I haven't investigated recently but is a good
example of QCELP in non MOV containers if in need for parsing I guess
the same question would arise: Where to account for the oddities..,

There is code (little drafty though) for a parser in the SoC repo but
is not in Kenan patchset. We are trying to figure out if its worth
adding it. As things are now, it seems the MOV changes could be better
handled on the MOV demuxer, Specially now that Michael said, if I
understood correctly, that data discarding is no parser's job. Whether 
future changes would justify the parser is still to be decided.

Bests
--
Reynaldo