[FFmpeg-devel] [PATCH] QCELP decoder
Wed Nov 26 03:22:45 CET 2008
On Tue, Nov 25, 2008 at 11:06:48PM -0300, Reynaldo H. Verdejo Pinochet wrote:
> Kenan Gillet wrote:
> > On Nov 25, 2008, at 4:54 PM, Reynaldo H. Verdejo Pinochet wrote:
> >> You are already adding the code. I'm not asking you to add anything
> >> more, Or to take care about debundling tied-up RTSP transported codec
> >> frames -- no. Just move YOUR parsing code to the correct place.
> > I give up. If Michael is OK with the parser, I'll move the code into a
> > parser.
> Thanks, I really think thats the way to go. Lets see what
> Michael has to say.
i wouldnt consider extra trash at the end of frames the parsers job
besides if the parser did split the trash off, the decoder would have
to deal with these seperate trash pieces, i mean its not really the
parsers job to discard parts of the stream, rather just to split them
also running a parser over some stuff takes a few cpu cycles, the code
in the decoder is likely cheaper ...
but in the end, you are (or will be) the qcelp maintainer so if you
want to do it in the parser iam not against this, i just think it might
not work out as nice as you seem to think it would ...
One point in favor of the parser though is copying the packets into another
container, in that case the trash should be discarded somewhere along the
way. This though could be done with a bitstream filter or maybe the trash
could even be discarded by the mov demuxer (if its only a problem of mov
so in the end i really dont know what would be best ...
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel