[FFmpeg-devel] [PATCH] QCELP decoder
Reynaldo H. Verdejo Pinochet
Tue Nov 25 21:03:36 CET 2008
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!
More information about the ffmpeg-devel