[FFmpeg-devel] Contract offer for implementing decoding functionality for interlaced AVCHD (5000 Euro + optional 1000 Euro Bonus)

Carl Eugen Hoyos cehoyos
Mon Jul 21 18:00:23 CEST 2008


Hi!

Reimar D?ffinger <Reimar.Doeffinger <at> stud.uni-karlsruhe.de> writes:

> Wow, this is really messed up: when both fields are one packet, the
> H.264 decoder will not decode at all. When each field is in a different
> packet it decodes, but at least the ffmpeg.c timestamp calculation
> messes up completely. Or at least something like that.
> AFAICT there is no problem in the H.264 decoder itself though, at least not
> in this case.

In case somebody is interested in the problem that ffmpeg can't correctly
transcode PAFF encoded H264 files:
Since r14310, I know of one file from the H264 conformance suite that
contains PAFF and decodes (nearly) correctly: HCAFF1_HHI_B.zip
ffmpeg -i HCAFF1_HHI.264 -f framecrc -
and
ffmpeg -s 352x288 -i HCAFF1_HHI.yuv -f framecrc -
show the same crc's for all frames (before r14310, they were all different),
but while the yuv file contains 10 frames, ffmpeg claims that the 264 encoded
file contains 14 frames: One frame is repeated three times, one twice:
0, 0, 152064, 0xb055a9bd
0, 3600, 152064, 0x9e1eadb6
0, 7200, 152064, 0x9e1eadb6
0, 10800, 152064, 0x9e1eadb6
0, 14400, 152064, 0x9e1eadb6
0, 18000, 152064, 0x48f117d2
0, 21600, 152064, 0x3e3ff049
0, 25200, 152064, 0x2ff80943
0, 28800, 152064, 0xc5ee16a6
0, 32400, 152064, 0xc5ee16a6
0, 36000, 152064, 0x38c33f28
0, 39600, 152064, 0x3e8444c7
0, 43200, 152064, 0x14ca4ab2
0, 46800, 152064, 0xe20e78f7

(PAFF + spatial messages cut).

Carl Eugen

PS: Another "good" sample would be Sharp_MP_PAFF_1r2.zip, but two of the
15/23 frames have different crc's. cabac_mot_picaff0_full.zip still shows heavy
artifacts.





More information about the ffmpeg-devel mailing list