[FFmpeg-devel] [PATCH] QCELP decoder
Sat Nov 29 18:29:29 CET 2008
On Nov 28, 2008, at 2:26 PM, Baptiste Coudurier wrote:
> Hi Reynaldo,
> Reynaldo H. Verdejo Pinochet wrote:
>> 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
>>>>> 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
>>>> be passing junk to the decoder. Please correct me if I'm just
>>> I didn't follow the whole thread, are we talking about junk or
>>> 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
>> data frame stuff (http://www.rfc-editor.org/rfc/rfc2658.txt) hasn't
>> accounted for yet, I'd expect that to follow a similar crossroad
>> either adding those changes to the rtp code or have a parser written.
> Are you saying that packets contain rtp specific data ? This is weird.
>> The .qcp (QCELP in RIFF) I haven't investigated recently but is a
>> 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..,
> Until you have figured out what is needed to decode .qcp correctly,
> modification to mov demuxer will be rejected.
We agreed on IRC with Reynaldo to live the decoder as it is for now.
More information about the ffmpeg-devel