[FFmpeg-devel] [PATCH] CrystalHD decoder support v6
Wed Mar 9 06:25:32 CET 2011
On Tue, 8 Mar 2011 19:21:19 +0100
Michael Niedermayer <michaelni at gmx.at> wrote:
> > Yeah, but doing that will require introducing a lot more knowledge
> > of the bitstream, which I desperately want to avoid - hence why I'm
> > hoping I can get firmware fixes out of Broadcom so that it reports
> > picture characteristics correctly.
> why not just open the parser for the current codec and parse the
But what if one packet != one frame (as I understand it, mpeg ps/ts
can do this) - then I've got to worry about accumulating bytes and
maintaining a lot of state. Certainly I see the h264 decoder has logic
for this. The hardware is supposed to do the heavy lifting :-)
> reget_buffer() is expensive (memcpy of whole frame) in many cases
Ok. I'll change it to use get/release (actually how it was originally).
As a side effect of being stateful, the issue of field order becomes
> a fix of the waiting will need changes to the client too i guess
Yes. I experimented with returning 0 for bytes consumed and mplayer
completely fell over - it can't comprehend a decode() call returning
no frame and no bytes consumed without being an error. So I have to
use a blocking delay in the absence of client changes.
Assuming I make the get/release change, and we ignore interlaced h.264
for now, how do you feel about merging this?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: not available
More information about the ffmpeg-devel