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

[Michael Niedermayer]

On Mon, Jul 21, 2008 at 04:00:23PM +0000, Carl Eugen Hoyos wrote:
> 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:

Thats due to the lack of a h264 parser that fills in half sane timestamps.
Nonsense timestamos -> ffmpeg nonsensically drops and duplicates frames.

To test the h264 decoder against reference files, use -vsync 0 -strict 1
until someone fixes the parser ...

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

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080721/80330e90/attachment.pgp>