[FFmpeg-devel] [PATCH 6/6] CrystalHD: Improve detection of h.264 content.

[Michael Niedermayer]

On Mon, Apr 04, 2011 at 08:51:51PM -0700, Philip Langdale wrote:
> As previously discussed, the CrystalHD hardware returns exceptionally
> useless information about interlaced h.264 content - to the extent
> that it's not possible to distinguish most MBAFF and PAFF content until
> it's too late.
> 
> In an attempt to compensate for this, I'm introducing two mechanisms:
> 
> 1) Peeking at the picture number of the next picture
> 
> The hardware provides a capability to peek the next picture number. If
> it is the same as the current picture number, then we are clearly dealing
> with two fields and not a frame or fieldpair.
> 
> If this always worked, it would be all we need, but it's not guaranteed
> to work. Sometimes, the next picture may not be decoded sufficiently
> for the number to be known; alternately, a corruption in the stream may
> cause the hardware to refuse to return the number even if the next
> intact frame is decoded. In either case, the query will return 0.
> 
> If we are unable to peek the next picture number, we assume that the
> picture is a frame/fieldpair and return it accordingly. If that turns
> out to be incorrect, we discard the second field, and the user has
> to live with the glitch. In testing, false detection can occur for
> the first couple of seconds, and then the pipeline stabalizes and
> we get correct detection.
> 
> 2) Use the h264_parser to detect when individual input fields have
> been combined into an output fieldpair.
> 
> I have multiple PAFF samples where this behaviour is detected. The
> peeking mechanism described above will correctly detect that the
> output is a fieldpair, but we need to know what the input type was
> to ensure pipeline stability (only return one output frame per input
> frame).
> 
> If we find ourselves with an output fieldpair, yet the input picture
> type was a field, as reported by the parser, then we are dealing with
> this case, and can make sure not to return anything on the next
> decode() call.
> 
> Taken together, these allow us to remove the hard-coded hacks for
> different h.264 types, and we can clearly describe the conditions
> under which we can trust the hardware's claim that content is
> interlaced.
> 
> Signed-off-by: Philip Langdale <philipl at overt.org>
> ---
>  libavcodec/crystalhd.c |   97 +++++++++++++++++++++++++++++-------------------
>  1 files changed, 59 insertions(+), 38 deletions(-)

LGTM

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20110408/684d7a0c/attachment.asc>