[MPlayer-dev-eng] [PATCH]VO_VDPAU, round 5

[Stephen Warren]

Reimar Döffinger wrote:
> Stephen Warren wrote:
> > There are two paths overall through vo_vdpau; HW accelerated
> > decoding using VDPAU, and SW decoding, just using vo_vdpau as the
> > display path, just like e.g. vo_xv/vo_x11.
> 
> I understand that, and I do not really want to remove it, I only
> meant this as another option to avoid reviewing/cleaning it up right
> now. An additional point was, that it seems a rather pointless
> feature right now, we have enough vos to display software decoding,
> so conceptually it might make more sense to implement this once
> support for post- processing features is added.

One potential advantage that vo_vdpau could have over other vo's is
the VDPAU presentation queue's HW-based timestamp feature. That is,
an arbitrary number of output surfaces can be queued into the
presentation queue, each associated with a display timestamp, and
the HW will take care of presenting the frames at the correct time.
There's also a feedback mechanism so that applications can determine
if the presentation occurred early (should never happen) or late
(some lateness will occur due to VSYNC alignment, or alternatively
due to the application queuing a frame late.)

Now, we certainly didn't implement this in our current MPlayer
patches; mainly we didn't know how to fit this into MPlayer's
architecture. However, it'd be interesting to see this added in the
future, and could make vo_vdpau quite compelling.

> > > > +    if (!num_video_surfaces) { // RGB surface formats
> > > > +        switch (image_format) {
> > > > +            case IMGFMT_BGRA:
> > >
> > > There is a comparison against the num_video_surfaces variable
> > > and one direct after for IMGFMT_BGRA, and the former one
> > > carries the comment "// RGB surface formats". To me that is
> > > always an indication that the code makes no sense and you are
> > > checking for the wrong thing,
> >
> > Given the "!num_video_surfaces" check, I think the comment should
> > really be "SW decoding" or "Non-HW-accelerated decoding" or
> > "Non VDPAU surface formats".
> 
> Hm, does this mean that post-processing features will not be
> possible to use on RGBA?

Yes, all the de-interlacing/post-processing only operates on video
surfaces. Video surfaces are always YCbCr/YUV.

> If so, would it in theory be possible to add post-processing support
> for it...

It seems highly unlikely VDPAU will support those operations on RGB
data.

-- 
nvpublic