hi,
On Wed, 07 Jul 2004 18:00:44 -0500, Ryan Tadlock
<pholan-xine-users@...> wrote:
> > tvtime: progressive_frame=1 tff=0 rff=1 duration=4504
> >
> > ok, our libmpeg2 decoder is marking it with +50% duration, which is
> > correct since one field is repeated. however, sometimes this very same
> > flags combination show a 3003 duration. this seems a bit odd from a
> > first sight, even though i remember some other flags (like
> > progressive_sequence) may affect the number of fields repeated.
>
> It seems very odd. I can't see where it could come from. The
> progressive_sequence flag in combination with RFF should cause the
> frame to either be displayed for 2 or three times the normal duration.
> Also from checking google the DVD standard evidently doesn't allow the
> progressive_sequence flag to be set.
right. so i'm not the only one who thinks that a frame with PF and RFF
must always have duration 4504 (since PS is always zero). something
seems to be going wrong, do you want to try debugging this? i guess
some printfs at libmpeg2 should help.
> > another interesting bit: why bother setting tff=1 or ttf=0 for
> > progressive frames?
>
> I believe it is to allow for interlaced output. Even if you know
> the frame in progressive you still need to know which field to
> output first and later repeat.
ok, sounds reasonable.
> > in fact, one problem is that we only use the field order from the
> > current, not from the past, frames. so it might be possible that the
> > deinterlacing methods using multiple frames get confuse about it
> > (merging fields very apart in time).
>
> I see a few frames with significant combing but nothing much. Also
> whenever it enters a progressive sequence via the soft telecine I see
> some unevenness.
i'm happy this event is not that much annoying because fixing it would
require quite some changes to the tvtime code... (and a lot of careful
thinking)
> That is probably from the same thing the clip you are looking at
> shows. Until libmpeg2 has seen the rff flag 4 times alternating with a
> normal frame it doesn't recognize that it is seeing a telecine
> pattern.
right.
> Once recognizes the telecine it changes the output duration
> to 3753. Also tvtime is watching for the same sequence of flags and
> stops doing anything to the frames at that point. But until that point
> is reached tvtime should be seeing frames with the progressive and rff
> flags set with duration 4504 alternating with interlaced frames with
> duration 3003.
correct. allow me to note that displaying frames with 4504/3003
alternated is perfectly valid from standard point of view. the 3753 is
just a measure to display these frames more evenly in computer
monitors, the total duration doesn't change.
> I believe my example clip's odd sequences were caused
> when the encoder found a telecined sequence but lost it two cycles. If
> so then the same thing should be seen whenever when a files encoding
> starts to shift from interlaced to progressive with a soft telecine.
i'm not sure i completely understood this. if encoder detected a
telecined sequence it would probably output a mpeg2 stream with the
alternating RFF flag and progressive frames. however your stream is
mostly interlaced.
> 103 RFF,progressive,duration=3753
> 104 tff,duration=3753
> 105 RFF,progressive,tff,duration=3753
> 106 duration=3753 (This frame may or may not be progressive but
> it is always treated as progressive.)
> 107 duration=3003 (The flag pattern has been broken so
> from here on libmpeg2 starts outputting
> normal durations and tvtime starts
> deinterlacing the frames again.)
this is indeed a possible case, but your stream doesn't apply. it
seems libmpeg2 rff pattern code does never match for your stream.
> One last thing. Looking through the source of xine_plugin.c I see that
> the duration of the frame to be output is cut in half at line 750
> which is what you need for the 60fps output. But, looking further down
> the file though it seems to be halved again at line 858. Since I don't
> see anything that would have touched frame->duration between the two
> changes won't this result in outputting a frame of length 1501 followed
> by one of length 750 instead of two frames of length 1501 when
> deinterlacing?
no, this is 'deinterlaced_frame->duration = frame->duration/2'.
frame->duration is not updated, and the second code you saw below is
the second field (that is, deinterlaced_frame was just drawn, freed
and reallocated).
i just commited a patch removing some duplicated code. i think it is a
bit easier to read now, so you might want to checkout cvs.
regards,
Miguel
|