[mythtv-users] Problem with VDPAU after broadcaster changes it encoder

[Mark Kendall]

2009/6/6 David Wong <david.wong at marvel.com.hk>:
>  I still having problem on HD source with trunk and vdpau. I've tried 185.18.14, still the same. In my
> environment, mplayer svn could play it with "-mc 2" option, using vdpau acceleration, so I think there
> is nothing wrong with vdpau itself.
> see http://www.nvnews.net/vbulletin/showthread.php?t=133915
> People could play it on xine-vdpau too. I checked 'wait for seq start header' too, it should be already on.
>
>  I've filed a mythtv ticket #6603, http://svn.mythtv.org/trac/ticket/6603
>
>  Please suggest how should I help and debug. I've compared libavcodec of mythtv trunk and mplayer svn.
> There are quite some differences on H264 and vdpau, at least about MBAFF.

David

I'm not sure there's much else you can do at this point.

Mythtv's VDPAU code is currently getting a bit of a re-work which will
involve some regression testing - hence I don't want to touch ffmpeg
code at this point and throw another (sizeable) variable into the mix.
For reference, my current plan of attack is:-

1. Break out VDPAU code from Xv/XvMC (almost done).
2. Refactor X11 display code to minimise code duplication and fix some
xlib/xcb crashes people are seeing.
3. Change the way we create/handle the VideoMixerRender (add support
for blur, denoise etc, reduce memory consumption for progressive
streams, remove annoying vdpau interlacing error message).
4. Finally commit some more video buffer memory optimisations (for 256Mb cards).

If that means nothing to you, the key message is that it's going to be
2-3 weeks before I seriously think about testing some ffmpeg updates.

If, in the meantime, someone wants to produce a test patch that
updates the ffmpeg elements of the code, then that may speed
everything up at some point and would be much appreciated.

regards

Mark