Dynamic Format Change with EVR / Contrast Issues with EVR and VMR9 RRS feed

  • Question




    I've writen a custom transform filter that connects to the EVR. I want it to perform dynamic format changes at any time. When the grpah is running, it works fine, however, when the graph is paused, it deadlocks in ReceiveConnection. I've tried to decommit the allocators before I call ReceiveConnection - same problem. Tried to send BeginFlush - same problem. I didn't notice the problem with othert renderers (I tested the VMR7). I'm calling ReceiveConnection before InitializeMediaSample on the thread that also delivers the samples. Can somebody explain why the EVR deadlocks and how to avoid it?


    I noticed another problem with the EVR that it has in common with the VMR9. The contrast is not great, black is dark-grey and white is light-grey. Obviously, both filters do not take into account that the brightness pixel value 16 is black, not 0 when using YUV video formats. The VMR7 doesn't have this problem when it uses a hardware overlay. Imho, the contrast issue is caused by graphic driver bugs, they don't convert YUV surfaces to RGB properly. I had the same problem when I wrote my own rendering filter. Is there a better solution than writing a custom renderer and replacing the graphics drivers internal YUV-RGB conversion with a shader? Btw, there are graphics cards which work properly, e.g. my very old Matrox G400 did everthing right...


    Best regards,


    Tuesday, September 2, 2008 6:38 PM


All replies

  • Hi Peter,

    I know a solution of the first issue.  KB951685 resolves the issue.

    Best Regards,

    Wednesday, September 3, 2008 4:55 PM
  • Peter,

    I found a solution for your second (indeed very annoying) problem on http://thegreenbutton.com/forums/3/274893/ShowThread.aspx

    With my ATI card on an plasma TV (with HDMI) the problem disappeared with only the "UseBT601CSC=1" register-change.


    Gr Budje


    Friday, September 5, 2008 1:49 PM
  • Thanks, KB951685 solved the problem indeed!

    Friday, September 5, 2008 3:18 PM
  • Why doesn't Microsoft fix the annoying contrast problem by specifying how the grpahics driver must interpret YUV data? The YUY2, UYVY,  YV12, ... and other DirextX surface formats should always be interpreted as 16..235 because they are used for video applications only and the 16..235 range is used for all video standards (there are small differences in the color coefficients when converting from YUV to RGB between SD and HD standards, but these differences are by far less important than 16..235 vs 0..255).


    Imho, the Microsoft Hardware Quality Labs failed to make sure that YUV format is handled consistently and properly across drivers.



    Friday, September 5, 2008 3:29 PM