> So with telecine you get: > 1T 1B 1T 2B 2T 3B ... > > and what mplayer does is: > 1 2 3 ... > > So you get 23.976 frames per second but it takes just as long as the 59.94 > fields in the telecine case. >
That doesn't sound right. Telecine should generate 1T/1B 2T/2B 2T/3B 3T/4B 4T/4B If mplayer is merely delaying frames then the 2T/3B and 3T/4B constructs would never occur. This could be happening, except the film material looks awfully clean on my TV for this to be the case. Also, mplayer says that "inverse telecine" is active. Why would that be? ----- demux_mpg: 3:2 TELECINE detected, enabling inverse telecine fx. FPS changed to 23.976! ------ If the material is really 23.976, then it should be doing telecine, not inverse-telecine. But perhaps again this is just a text error. Then later it says ----- demux_mpg: Progressive seq detected, leaving 3:2 TELECINE mode Warning! FPS changed 23.976 -> 29.970 (-5.994000) [4] ----- Which is fine except that we have interlaced frames not progressive frames. > Basically doing that on an interlaced output device does maintain the > timing but getting the fields to match correctly is a matter of luck. If > we had access to the repeat_first_field and top_field_first flags in > vo_dfbmga we could guarantee the correct sequence by using > SetFieldParity(). Yes except when I change the parity it just goes from bad to worse. > Maybe the problem is in fact the inverse telecine stuff it tries to do. > But why does it still look jerky after it leaves the telecine mode? I'm > getting very confused... > Yeah me to. I don't suppose there's someone out there who actually knows what mplayer is doing internally in this case that we could bring into the conversation? Neil -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-users" as subject.
