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

[Reimar Döffinger]

Hello,
On Tue, Jun 03, 2008 at 05:15:18AM +0200, Michael Niedermayer wrote:
> 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:
> > > 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.

Well, ffplay does behave very differently (it does not play completely
right either though), so at least behaviour is not consistent withing
FFmpeg...

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

I'll see if I can find time for it (I have not even looked at it yet)...

Greetings,
Reimar D?ffinger