[FFmpeg-devel] [PATCH] QCELP decoder

[Kenan Gillet]

Hi,
On Nov 28, 2008, at 2:26 PM, Baptiste Coudurier wrote:

> Hi Reynaldo,
>
> Reynaldo H. Verdejo Pinochet wrote:
>> 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.
>
> 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  
>> 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..,
>
> Until you have figured out what is needed to decode .qcp correctly,  
> any
> modification to mov demuxer will be rejected.
>
> [...]

We agreed on IRC with Reynaldo to live the decoder as it is for now.


Kenan