[EricV]

On my atom 330 + nvidia ion HTPC, when watching recorded HD mpeg2ts files using vdapau + (temporal spatial deinterlacing) on the pvr-testing2 branch, sometime for a small amount of time video play slowly and then fast. Sound remain correct.

Anssi Hannula did some fixes on the trunk and I backported them sucessfully one by one on pvr-testing2 seeing things gradually improving up to changeset 33512 that adds temporal bit when requesting temporal/spatial deinterlacing.

This fix completely breaks on nvidia ion (9400). Video keeps playing at incorrect speed, skipping images. Adding 33513 on top of it does not help.

As I backported only changeset that involved VDPAU.cpp and VDAPU.h by viewing the changelog history, I may have skipped one patch not directly related to VDPAU but that changeset 33512 indirectly requires.

Could someone building trunk past 33513 on nvidia test and report?

Thanks.

[Anssi]

I noticed similar issues when testing on a NVIDIA 9400 system after r33512. As far as I can see, this is a card performance problem; that said, our VDPAU decoding code could probably be optimized somehow, as the deinterlacer works better in other programs with this card.

Note that before r33512 the temporal/spatial deinterlacer simply was the same as the bob deinterlacer, therefore you now see a perfomance degradation as the temporal-spatial deinterlacer actually works. You can restore the previous mode by selecting the Bob deinterlacer manually.

Feel free to contradict me if you think I'm mistaken above

[EricV]

I noticed similar issues when testing on a NVIDIA 9400 system after r33512. As far as I can see, this is a card performance problem; that said, our VDPAU decoding code could probably be optimized somehow, as the deinterlacer works better in other programs with this card.

Note that before r33512 the temporal/spatial deinterlacer simply was the same as the bob deinterlacer, therefore you now see a perfomance degradation as the temporal-spatial deinterlacer actually works. You can restore the previous mode by selecting the Bob deinterlacer manually.

Feel free to contradict me if you think I'm mistaken above

Well, reading several thread I kinda figured out that full temporal/spatial for this card may not work for HD. I will try the suggestion for bob. What is temporal/spatial (demi)? On the other hand, mplayer with deint=4 works on the same content which mkaes me wonder even more.

Thanks for the quick answer. Will try Bob, temporal only (should work for HD).

[Anssi]

What is temporal/spatial (demi)?

It is temporal/spatial deinterlacing with half the result framerate (e.g. 25fps instead of 50fps in case of PAL) to reduce gpu usage.

On the other hand, mplayer with deint=4 works on the same content which mkaes me wonder even more.

Yep, this is why I suspect there is something suboptimal in our implementation.
(alternatively, though I do not believe so right now, it could be the fact that we are using OpenGL while other players are not)

[bobo1on1]

Mplayer doesn't have to render vdpau to opengl

[EricV]

Well, reading several thread I kinda figured out that full temporal/spatial for this card may not work for HD. I will try the suggestion for bob. What is temporal/spatial (demi)? On the other hand, mplayer with deint=4 works on the same content which mkaes me wonder even more.

Thanks for the quick answer. Will try Bob, temporal only (should work for HD).

So I tested the following:
1) Bob okay but rendering is not top
2) Temporal OK
3) Temporal-spacial demi OK (from your comments I understand it drops fps to 25)

Worse I still have some video acceleration problem but I'm not sure its software or hardware (I have tested on many different hardware without noticing the pb I have at home but maybe it is because I watch TV longer).

[EricV]

Mplayer doesn't have to render vdpau to opengl

So room for future improvements? or shall I unconditionally set mplayer as external renderer (I now use it only for IPTV as rtp protocol support is broken).

Anyway thanks for the good work and you help is appreciated.

[bobo1on1]

Well when we add support for GL_NV_vdpau_interop we can deinterlace in a shader, whether that's actually better/faster remains to be seen.

The big performance issue with vdpau in xbmc is, vdpau renders to a pixmap first, then xbmc renders that pixmap in opengl, that double copy uses valuable resources, especially on 1080i/p.

[EricV]

Mplayer doesn't have to render vdpau to opengl

FYI : Seen in 260.19.06 nvidia chnagelog Fixed a bug in VDPAU that prevented temporal-spatial de-interlacing from operating when temporal de-interlacing was not also enabled.

[Anssi]

FYI : Seen in 260.19.06 nvidia chnagelog Fixed a bug in VDPAU that prevented temporal-spatial de-interlacing from operating when temporal de-interlacing was not also enabled.

Yes, I notified NVIDIA of this, thus this fix. I workarounded this in xbmc by enabling them both when temporal-spatial is enabled (mplayer, xine, mythtv do the same).

[EricV]

Yes, I notified NVIDIA of this, thus this fix. I workarounded this in xbmc by enabling them both when temporal-spatial is enabled (mplayer, xine, mythtv do the same).

Just wonder if it still needed if driver version is superior or equal to that value?

[Anssi]

Just wonder if it still needed if driver version is superior or equal to that value?

Nope, but there is no need to add additional logic there as the workaround doesn't really have downsides.