[FFmpeg-devel] [PATCH] QCELP decoder

[Reynaldo H. Verdejo Pinochet]

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.

> 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 ;)

> 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?

>> 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.

Keep up the good work!

Bests
--

Reynaldo