[FFmpeg-devel] [PATCH] QCELP decoder

[Baptiste Coudurier]

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.

[...]

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no