[FFmpeg-devel] [PATCH] QCELP decoder
Fri Nov 28 23:26:36 CET 2008
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 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
More information about the ffmpeg-devel