[FFmpeg-devel] [PATCH] QCELP decoder

[Kenan Gillet]

On Nov 25, 2008, at 12:03 PM, Reynaldo H. Verdejo Pinochet wrote:

> Hello, sorry for the delayed answer.
>
> Kenan Gillet wrote:
>> On Nov 23, 2008, at 7:20 AM, Reynaldo H. Verdejo Pinochet wrote:
>>>
>>>> In order to read the two samples h263.mov and blue_earth.mov,
>>>> we need to look at the rate byte in the frame (as the spec  
>>>> describes)
>>>> and not just rely on the buffer_size
>>>> since for those files, the buffer_size is always 35 but they  
>>>> contains
>>>> RATE_FULL, RATE_HALF, RATE_QUARTER and RATE_OCTAVE.
>>>>
>>> You sure this is from the spec and not from
>>> http://www.rfc-editor.org/rfc/rfc2658.txt ?
>>> I don't recall from the top of my head.
>>
>> it is not from the specs but from looking into the 2 samples with an
>> hex editor...
>
> Yes. See, a similar approach to separate bundled codec frames is
> outlined there. Thats why it rang a bell.

Currently, the only demuxer that handles QCELP is the MOV
demuxer.
All the samples we have, are in different flavors of MOV files (mov,  
3g2, k3g)
In all those files, 1 MOV frame corresponds to 1 QCELP frame:
there is no bundling.


>
>
>> The RFC 2658 is only for RTP transport, and it will probably need
>
> Oh, I certainly know that much. I even did read past the tittle ;)

so you should know that this RFC is ONLY for RTP transport, not MOV.
not AVI or any other container.

>
>
>> a parser. But right now, I think the focus is on making the QCELP
>> decoder works on the different flavor of MOV files, and it does not
>> need any parser.
>
> No, I think you are wrong here.
>
> The focus is still to have a QCELP decoder, I don't care about
> MOVs any more than other formats which you can mux QCELP into.
> Having custom packet parsing code (not talking about codec frame
> parsing) in the decoder is not a clean solution, this should be
> handled with a parser. Even more if this is just to handle a subset
> of files. There is an skeleton parser on the SoC repo. Maybe you
> could add to it?

Ok, let me rephrase it:
Making QCELP decoding available in every possible/existing format
is definitely a long term goal


But my CURRENT focus is to merge the QCELP decoder, so that it
can correctly decode all the samples we have and be as specs
compliant as possible.

Furthermore, I am not comfortable to add code that has not been
tested on real world samples; it is just my philosophy...

Concerning the "custom packet parsing code", I would like to know
what it refers to, because I am not sure to understand your comment.

>
>
>>> In either case I think this should rather
>>> be handled in the parser.
>>
>> QCELP on RTP will probably need a parser, QCELP in MOV
>> does not at the moment.
>
> The code we are commenting clearly shows the need from a
> parser by itself.

As I said, QCELP on RTP will probably need a parser, but at the moment
we have no way of testing it, and it is my understanding that any
untested code would not be merged into the HEAD trunk.



>
>
> Keep up the good work!

you too :)

Kenan