[FFmpeg-devel] Contract offer for implementing decoding functionality for interlaced AVCHD (5000 Euro + optional 1000 Euro Bonus)
Mon Jul 21 20:20:23 CEST 2008
On Mon, Jul 21, 2008 at 04:00:23PM +0000, Carl Eugen Hoyos wrote:
> 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 -
> 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
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel