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

[Michael Niedermayer]

On Sun, Jun 01, 2008 at 05:19:29PM +0200, Reimar D?ffinger wrote:
> On Sun, Jun 01, 2008 at 02:59:06PM +0000, Carl Eugen Hoyos wrote:
> > Hi!
> > 
> > Reimar D?ffinger <Reimar.Doeffinger <at> stud.uni-karlsruhe.de> writes:
> > 
> > > Hm... I did not yet test FFmpeg, but
> > > mplayer sony-hdr-cx-6-avchd-1080i-9-seconds.mts -speed 0.5 -demuxer lavf
> > > plays it in-sync for me (the -speed 0.5 is only because my PC is too
> > > slow to play at full speed).
> > > Could someone possibly verify that this is true and not just because my
> > > MPlayer is full of half-finished hacks?
> > 
> > It is true due to -correct-pts being the standard for demuxer lavf.
> > I reported the problem occasionally on irc and at least once to Michael, and
> > posted a very useful patch to fix it for MPlayers demuxer;-)
> > http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2007-October/054452.html
> 
> 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.

I really doubt that its ffmpeg.c ...
its rather that mplayer is more forgiving when it comes to random timestamps
than ffmpeg.c is.

What is needed to fix this is likely what robert marstons SOC2008 attempted
as qualification task.
See the ML, H.222 and H.264

making ffmpeg.c more robust against nonsensical timestamps is surely welcome
as well but its not truly a fix for the problem

And if someone wonders why the timestamps are random and not just missing,
thats likely because th h.264 parser makes no attempt at setting various
fields correctly. (something about which packets are fields instead of
frames comes to mind ...)

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct awnser.
-------------- 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/20080603/60c14b9d/attachment.pgp>