[MPlayer-dev-eng] mp-g2 pre14

[Arpi]

Hi,

> > ok pre15 is out, with the brand new libvo2 API design (and xv driver as
> > sample) by me, .so and iive
> > 
> > it would be great if vo driver developers/maintainers could check it
> > (video_out.h) and tell me the possible problems, missing calls/features
> > they see ASAP.
> 
> I dunno how this should be done, but there MUST be some way for the
> player to 'hook in' between the filter chain and libvo2, in order to
> control the rate at which frames are displayed. Otherwise, filters
> that alter framerate (e.g. showing interlaced video at 60 fields per
> second, inverse telecine, etc) cannot work properly! This was one of
> the big deficiencies in the old design, so I hope G2's architecture
> will fix it.

I want to fix it, but can't imagine how to fix it yet.
Maybe i can't avoid moving the video timing/delaying code to vf_vo2, maybe
with a callback to the player (to be able to use idle time for something
more useful).

Handling PTSs is tricky. Actually there is 2 layer of timestamps.
The raw ones (coming from demuxers, usually inaccurate, with discontinuities
(not only DVD is such thing, some other formats is even worse), and the
'smoothed' ones, currently in sh_audio->timer & sh_video->delay.

My current (not final) plan for g2:

Demuxers will retrieve the raw timestamps. Let decoders to modify
timestamps, if they want (because of frame reordering, in-codecs timestamps
(realvideo, mpeg4, h263)). I'll do the pts smoothing in dec_video.c
(interface between codecs and filters). Maybe i have to add a demuxer hook
for that purpose, because smoothing algo depends on demuxer/container format.

Then the smoothed, linear timestamp will be passed to the filters along with
the video frames. They can alter it, or just pass to the next filter.
At the end, either the vo driver or vf_vo2 will delay and then show the
frame, or the ve driver writes it out with timestamp, or drop/duplicate for
fixed-fps formats.


> BTW, I think for G200's broken "YV12" mode, it's best to export the
> real Y buffer, and allocate fake U/V buffers in system mem, then
> interleave them into real video mem at page-flip time. Or better yet,
> maybe vf_vo2 could have some way of notifying the vo driver that a
> slice is finished, so that it could be done along the way to improve
> cache utilization...

already doable with libvo2 :)


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu