Tearing - possible solution for D3D video output

[inches]

This is about a possible solution for the tearing problem in full screen on Windows XP with "DirectX 3D video output" selected. It applies only to Direct3D output.

The test video can be downloaded from the link below, it's been transcoded and cut from a DVD. Tearing starts to appear on my computer at second 28, when the camera starts panning.

http://www.4shared.com/file/110658515/b ... nline.html

The only way I can play this test video (and others) without tearing in fullscreen on my computer is with VLC 0.9.9a compiled with the changes described below, or with Media Player Classic Home Cinema with "Lock back-buffer" checked.

My comp: XP SP3, E8400 3.6GHz, 2GB, ATI Radeon HD 3870, Catalyst 9.4 (VSync enabled or not, no difference), 24 inch LCD, 1920 x 1200, 60Hz


I have tearing on this video with all official releases of VLC on my computer (0.9.9a, 1.0.0rc1 to rc3). Other players, based on DirectShow like GOM Player also show some tearing, although it seems to be less.
I've cross compiled VLC (0.9.9a sources) on Ubuntu with the changes described below. Only the direct3d.c file is changed, so only the libdirect3d_plugin.dll is changed.

If anyone else experiences tearing on Direct3D output and can make a build with the changes below, please post here if these changes helped or made anything worse. If anyone wants to try the custom build I've made, you can download it here:

http://www.4shared.com/file/111190410/7 ... uffer.html

It's a self extracting archive made with 7zip, scanned with AVG 8.5, perhaps you should scan it too after downloading. It's not a good "production" build, some features were stripped from the makefiles, the goal of this build is only to test the tearing with D3D video output.


Below are the changes I've made in the direct3d.c file.

The structure for creating the D3DDevice, in the Direct3DFillPresentationParameters function:

Code: Select all

ZeroMemory( d3dpp, sizeof(D3DPRESENT_PARAMETERS) ); d3dpp->Flags = D3DPRESENTFLAG_VIDEO | D3DPRESENTFLAG_LOCKABLE_BACKBUFFER; //needed for locking/unlocking the backbuffer at the end of Direct3DVoutRenderScene d3dpp->Windowed = TRUE; //always windowed, it's never really a D3D fullscreen app d3dpp->hDeviceWindow = p_vout->p_sys->hvideownd; d3dpp->BackBufferWidth = d3ddm.Width; //the backbuffer will always be the size of the screen if set like this (any problems?) d3dpp->BackBufferHeight = d3ddm.Height; //the backbuffer will always be the size of the screen if set like this (any problems?) d3dpp->SwapEffect = D3DSWAPEFFECT_COPY; //always copy, never flip, since the device is always in windowed mode d3dpp->PresentationInterval = D3DPRESENT_INTERVAL_ONE;

In Direct3DVoutRenderScene, before this line:

Code: Select all

hr = IDirect3DTexture9_GetSurfaceLevel(p_d3dtex, 0, &p_d3ddest);

add the following lines:

Code: Select all

//set the back buffer surface to be the current render target LPDIRECT3DSURFACE9 p_back_buffer; IDirect3DDevice9_GetBackBuffer(p_d3ddev, 0, 0, D3DBACKBUFFER_TYPE_MONO, &p_back_buffer); IDirect3DDevice9_SetRenderTarget(p_d3ddev, 0, p_back_buffer);

This means that before obtaining the destination surface to paint the frame to (the p_d3ddest pointer), first make the backbuffer to be the render target. There should be only one backbuffer if the above settings were used in Direct3DFillPresentationParameters. I haven't yet tested with more backbuffers and I don't really know if more of them would do anything better (for 24 - 30 fps video, one backbuffer should be enough I suppose...)

At the end of the Direct3DVoutRenderScene function, right after the EndScene block, add:

Code: Select all

D3DLOCKED_RECT locked_rect; if(SUCCEEDED(IDirect3DSurface9_LockRect(p_back_buffer, &locked_rect, NULL, 0))) IDirect3DSurface9_UnlockRect(p_back_buffer);

(Not sure about memory leaks in this code, msdn says p_back_buffer obtained as above should be released at some point... Also, both GetBackBuffer and SetRenderTarget should be result-checked.)


All that these changes are doing are the same thing that Media Player Classic Home Cinema does on VMR9 renderless output, with 3D surfaces selected and the "Lock back-buffer" option checked. This applies to MPC-HC version 1.2.908.
I'd like to know if anyone else has the same tearing problem and if this solution solved it.

[Jean-Baptiste Kempf]

Can you send us a patch?

[random]

Without applying your patch, there's zero tearing effect when playing 2.avi the sample you provided on my machine it's running Vista. Should you test it again with Vista? and is your XP installation tweaked the visual effects to best performance or appearance (which would turn off all the video / animation effects leaves with bear minimum and will therefore likely to cause much tearing). If you want vlc to display proper video you better turn on all visual effects as well as update your DirectX Redist. to the latest.
Also just checked that the latest DD from AMD for your graphics card is "ATI Catalyst™ 9.5 Display Driver for Windows XP Professional/Home Edition" you should install that as well to see if any different.
I will try your idea later about the d3d patch and see if any differences it make.

[random]

Tested on a Windows XP machine without your idea also I see no tearing effect from 2.avi.
Also having read what MSDN says about D3DPRESENTFLAG_LOCKABLE_BACKBUFFER, http://msdn.microsoft.com/en-us/library ... S.85).aspx
It appears to me that using this flag will cause more problems and severe performance degradation, overall, I don't think its a good idea to make this modification.

[random]

Next time, please use a git patch format patch and sign up with vlc-devel mailing list http://mailman.videolan.org/listinfo/vlc-devel then send the patch in for review.

[random]

Code: Select all

D3DLOCKED_RECT locked_rect; if(SUCCEEDED(IDirect3DSurface9_LockRect(p_back_buffer, &locked_rect, NULL, 0))) IDirect3DSurface9_UnlockRect(p_back_buffer);

The above you mentioned is a duplicated call to lock d3d surface which is already implemented in the function

Code: Select all

static int Direct3DVoutLockSurface( vout_thread_t *p_vout, picture_t *p_pic )

It simply doesn't make any sense to me, ie. your patch is wrong, maybe one of the vlc-dev is a msw/vout guru and have more to say.

[inches]

I'm reading the docs about submitting a patch.
I will also install the 9.5 drivers after I write this post and let you know if it helped.

Fact is that if you search the web, you'll see there are others with this tearing problem, including here on videolan forum.
I was already convinced that not every computer shows this problem. Smaller screens might not, different video-adapter/monitor frequencies also might not have this problem, some people say that using Reclock elliminated tearing, others say that the option in MPC-HC didn't help them, or only helped them partially. Look at this quote: "I enabled Vistas Aero desktop and behold - the tearing is gone! Can anyone explain to me why? I hate the Aero." ) (http://www.avsforum.com/avs-vb/showthread.php?t=1140660).
There are lots of wierd tearing complaints on avsforum and doom9.

It's all about timing, how often does RenderScene get called, how often the adapter refreshes, how often the monitor does. It might be so that on slower computers it doesn't happen, just as it might only happen if you're using a projector as your display.
With some renderers (it strongly depends on how the player and the renderer were written), tearing can be just like a race condition bug: shows up only on some computers, or on the same computer with different displays, hard to reproduce. That's why I'm posting here, to see if others have it and can solve it with this patch.

I'm also thinking that this code could help by accident. I'm not sure about this, but maybe it just delays the RenderScene enough for the renderer to get in synch with the display. If so, that's where this thread gets useful: see how many people said it's working or not.

As I said, MPC-HC has a configuration option that is exactly about this and I've seen postings on other forums saying that checking the "Lock back-buffer" option elliminated the tearing for them, just as it did for me. Google it.
I'm also convinced that this code should only be enabled by a checkbox in configs. Performance-wise, as I said, it really can't be a problem for video. It could be a problem for games, and games use this locking all the time.

[random]

Well you said performance doesn't matter I say it does for VLC because due to during intensive processing times for decoding AVC1 / h.264 720p or 1080p @59.94fps materials indeed that it does matter. However I think in my opinion it is just an issue when people wrongfully turning off all visual features which supports the O/S whether it is XP or Vista or Windows 7 for that matter it is user's fault for turning them off when shouldn't.
Anyways VLC's msw vout direct3d module does work properly as it is and works quite well IMO. And as you have called up this matter/issue due right in the middle of a vlc-1.0.0-release soon to be made is rather a bit late don't you think?
If there indeed is issue probably the user mis-configured or over tweaked their system otherwise proof it really is a bug with default Windows options on multiple machines.

[inches]

Too late? lol.
It's never too late for anything. I'm hoping VLC reaches version 5.3.7.
1.0.0 doesn't have to be perfect and it most likely won't be. I never said this is a VLC bug, in fact I don't think it is. But I am trying to see if it is an improvement. If it proves to be an improvement, it can be included anytime. Next year. If not, never. This is a forum where people discuss about possible software improvements, isn't it?
Nobody's forcing anybodys hands here, I'm bringing the issue up when I see it. If you think I should have waited, then perhaps you should give me a timeframe for bringing issues up.

Regarding those "visual features which supports the O/S" I have to admit I have no idea what you mean. Please be more specific, what OS features are you referring to, so we can discuss it and see if I really missed something obvious.

Performance-wise: they're on different threads and they'll always be on different threads, if VLC is going the right way. In fact the video-output thread will always wait for the decoder thread, especially when the decoder is doing so much as a h264 video. There's such a huge difference in the processing power that these two threads (decoder and renderer) actually need that you can add 5 more locks-unlocks in the renderer, especially since it's D3D and most, if not all of these functions in this specific renderer are done by the GPU. This thread will never take too much CPU time needed by the decoder thread, if you have a decent GPU in your computer. Ideally the renderer is a thread that waits most of the time, and when it wakes up just calls a bunch of GPU functions and goes back to sleep so it can leave all the CPU to the decoder. Which this particular renderer actually does.

[Jean-Baptiste Kempf]

Waouw, people CALM down.

Indeed, some people complain about tearing on some chromas and some graphic drivers. I was unable to reproduce, but that doesn't mean anything.

Moreover there is a HIGHLY big issue on VLC on Win7 with very bad quality, and this could be a solution.
Moreover, a configuration for this is probably the best way to go, if it solves thing for some people.

But, without a patch, this is not something we can work on.
If it is too late for 1.0.0, it could enter in 1.0.1 or 1.1.0, if it solves issues.

[VLC_help]

Moreover there is a HIGHLY big issue on VLC on Win7 with very bad quality, and this could be a solution.

I doubt it. Tearing and big pixels are two completely different things.

[rogerdpack]

I presume this wasn't applied (for my notes to myself)?

[Jean-Baptiste Kempf]

I presume this wasn't applied (for my notes to myself)?

Saying 'this' over a 3 year old thread with clear trolling is a bit dubious. Some work for tearing has been done on D3D for 2.0.0