diff options
| author | Philip Langdale <philipl@overt.org> | 2011-03-14 21:47:35 -0700 |
|---|---|---|
| committer | Philip Langdale <philipl@overt.org> | 2011-03-26 15:55:47 -0700 |
| commit | e44073ca5e7143934ffa79d317dc65150db1637c (patch) | |
| tree | b9634e0f378098cc43028cf0d1cd1ac2b34b1349 /configure | |
| parent | 907783f221ad9594a528681e30777705f11bf0b5 (diff) | |
| download | ffmpeg-e44073ca5e7143934ffa79d317dc65150db1637c.tar.gz | |
CrystalHD: Improve interlaced h.264 support.
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 MBAFF and PAFF content until
it's too late.
This change introduces use of the h264_parser to help bridge the
gap; it can indicate if the input data is PAFF fields or not.
With this clarity, some of heuristics can be removed from the code,
making this less convoluted.
Finally, I found an MBAFF clip that acts like non h.264 content so
I had to make allowances for that.
Note that I still cannot distinguish between two forms of PAFF,
where the hardware either returns individual fields or a field-pair.
It's not clear that there's even a spec relevant difference between
the two forms, as opposed to hardware ideosyncracies.
Diffstat (limited to 'configure')
| -rwxr-xr-x | configure | 2 |
1 files changed, 1 insertions, 1 deletions
@@ -1276,7 +1276,7 @@ h263_vaapi_hwaccel_select="vaapi h263_decoder" h263i_decoder_select="h263_decoder" h263p_encoder_select="h263_encoder" h264_decoder_select="golomb h264dsp h264pred" -h264_crystalhd_decoder_select="crystalhd h264_mp4toannexb_bsf" +h264_crystalhd_decoder_select="crystalhd h264_mp4toannexb_bsf h264_parser" h264_dxva2_hwaccel_deps="dxva2api_h" h264_dxva2_hwaccel_select="dxva2 h264_decoder" h264_vaapi_hwaccel_select="vaapi" |