[MPlayer-users] segfault while trying to telecine

[D Richard Felker III]

On Sat, Mar 01, 2003 at 11:26:54PM -0500, mplayer at interlinx.bc.ca wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]

> On Sat, Mar 01, 2003 at 08:32:53PM -0500, D Richard Felker III wrote:
> > 
> > Right. If you had RTFM'd, you would have seen that you also have to
> > use -fps 29.97.
> 
> Wow.  You are right.  I should have RTFM'd.  I guess I am just always
> so used to documentation being so behind development in other
> projects, especially the bleeding edge, that I just assumed it would
> not be documented yet.

:)

> > However, I'm not sure if this is even possible with
> > variable-fps formats like quicktime...
> 
> Seems to work alright, as far as A/V sync goes.  I still have the
> problem where only the left half of the picture is getting telecined.
> The right half seems to be remaining progressive albeit with a
> duplicate frame being added due to the 20% framerate increase.

Hmm, sounds like -vop telecine doesn't properly support the output
colorspace the codec is giving it. Would you send output of mplayer
with -v so I can see what's causing the problem? In the mean time,
using -vop telecine,format=yv12 should force YV12 and fix the problem.

> Understood.  Would be nice to get that working.  I would so much
> prefer to telecine on the run rather than decreasing quality bandwidth
> by 20% (or increasing filesize for the 20%) just to get it up to NTSC
> rate.

Agree. If you have mga_vid, this *might* already work, since the vsync
in the hardware might ensure that the extra frame gets displayed for
at least one refresh period. I'm not sure about that, though.

> I would imagine during initialization of the vo and each of the vf's
> the fps needs to be passed down during config/init to allow each
> component to make it's adjustments to it before it's passed back up to
> the main processing block.  So vf_telecine would gross it up 20% and
> then the main block would know to process at 29.97fps rather than the
> 24 specified in the file.  I am sure it's more complicated in the
> details than I make it out however.  :-)

Well a simple approach like that would probably work, but it would be
better if the filters could just adjust the timestamps on each frame,
for variable framerate adjustment. For example, imagine the case where
you have a DVD that's a mix of 24fps/progressive and 30fps segments,
and you want to output pure 30fps (with the 24fps parts telecined) for
making an SVCD.

There's of course also the opposite example where you want to apply
inverse telecine to material that's part-telecine and part-real-30fps,
and you want to adjust the timestamps on the telecined part when
reversing the telecine so that all frames are shown for equal duration
(rather than every 4th frame still being shown twice as long).

Rich