[FFmpeg-devel] [PATCH] CrystalHD decoder support v6

[Philip Langdale]

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

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

Thanks,

--phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20110308/a3916c0d/attachment.pgp>