[MPlayer-users] will mplayer do a 3:2 pulldown on 24 fps video when ofps=29.97?

[mplayer at interlinx.bc.ca]

On Thu, Feb 20, 2003 at 03:02:29PM -0800, Brian Craft wrote:
> 
> Yeah, this really is an on-going problem. The xp fork is too far behind to be
> useful.

I was thinking about taking a look at it again due to this problem,
but maybe not.

> It's unfortunate that threading wasn't maintained as a patch -- like
> other notable oss projects that were too intrusive or controversial (low
> latency patches, uml, etc.), it could have remained relevant that way.

I guess the problem was that it was so intrusive that keeping up with
the mplayer moving target was difficult.  But indeed, there are gains
to threading to be sure.

Like the case of dfbmga.  It's possible to sync mplayer's processing
of frames to the clock of the output device simply by having the vo
driver wait for the vsync from the television/video card.  But having
it wait and having mplayer decode frames all in the same thread does
not work on machines it should work on because too much of the
needed decoding time is spend sleeping for the vsync interrupt.

> I'm considering a digital projector for this purpose. Prices are comparable to
> hdtvs,

That means well out of my spending range then.

> they take up less room, they're easier to transport, and they're
> multisync.

All very good reasons to buy one, if you have the budget for it.

> I don't really understand the appeal of televisions right now.

They are ubiquitous and cheaper than projectors.  Or are they?  I
dunno.  I have not looked at the price of a decent projector lately.

> It
> seems like the industry is lagging behind what you can do with a pc and a
> digital display.

True.  But at a cost.  Most of us already have TVs, hence 0 cost.


On Thu, Feb 20, 2003 at 06:04:17PM -0500, D Richard Felker III wrote:
> 
> True 3:2 pulldown.

Excellent!  I can't wait to inverse-telesync some recorded (mjpeg) 3:2 pulldown
material and play it back to my television with the 3:2 pulldown
filter.  :-)

> Duplication would be totally pointless since you'd
> get that effect automatically with mplayer using no special options.

Right.

> Telecine (3:2 pulldown) is total nonsense unless the display device is
> interlaced!

Of course it is.  But as I said in my original message at the start of
this thread my output device was NTSC television.  OK, I guess it
could have been a progressive scan television, but I certainly would
be in the minority based on that assumption.

> And even then it's ugly, IMO.

Right.  This is that subjective part I was talking about.  Even if you
think it's ugly, and that is your right, by all means, it's the
established industry standard for playing 24 frames/s at 59.94
fields/s.

> Most people aren't doing that.

Actually for certain values of "most people", yes most people are
watching 3:2 pulldown where the source is 24 frames/s.  Your
definition of most people is MPlayer users in front of their computer
monitors.

My definition of most people is the entire North American home
consumer market watching 24 frames/s material on their DVD players and
televisions.

> They're displaying 24 fps progressive
> movies on progressive monitors. If mplayer automatically did some
> telecine/interlacing crap to movies, it would be VERY annoying!

For computer geeks, yes.  But as I said, my target is (a) television
watching consumer(s).  The latter sample of most people is much larger
than the former.

> It has nothing to do with threads. Switching page at vblank is the
> responsibility of the video driver; however, most of them suck too
> much to do this.

DirectFB with the G400 and Ville's CRTC2 work certainly does not.  In
fact I know of no other TV-Out solution (other than DVB) that works as
well.

> :( mga_vid will do it, and there's an api in the
> linux fbdev layer for "wait to apply these changes until vblank", but
> none of the fb drivers implement it. :(

Take another look at the matrox driver with DirectFB.

But I do see your point about the vo driver not having to wait for the
actual vsync.  This may have been an intermediate step in dfbmga's
driver, to maintain field parity.  I will check with Ville again on
it.  His latest changes to DirectFB move the vsync waiting/field
parity waiting stuff into DirectFB, so it may no longer be an issue.

> Video filters can't tell what the framerate is, and anyway, it's
> possible someone might want to use 3:2 pulldown for any 20% framerate
> increase, not just 23.976->29.97.

Right.  And somebody that does want to do that can specify -vop
telecine.  But what I am proposing is that mplayer see that -ofps was
set to "ntsc" and then examine the input rate of the video.  If it's
29.97 fps, do nothing, if it's 23.976, automatically insert the
telecine filter.

> For a PVR, you really should run mplayer -info or whatever in advance
> to get the stream parameters, then use these to configure the second
> run.

That is an idea, indeed.  But having mplayer be more intuitive on it's
own is a good thing.

BTW:  I couldn't seem to find (at first glance) an option to just get
a stream's parameters.  I will look deeper in a bit.

> There are plenty of other things like size/scaling you need to
> handle already I'm sure...

Actually, I target the recording/encoding process to do as much of
that work as possible.  But again, you have a point.

b.

-- 
Brian J. Murrell
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-users/attachments/20030220/d1d7fdb5/attachment.pgp>