[mythtv-users] Really washed out picture since upgrade to 0.24.0

[Andre]

On 21 Nov 2010, at 13:08, Mark Kendall wrote:

> On 21 November 2010 16:30, Andre <mythtv-list at dinkum.org.uk> wrote:
>> Also if a suitably knowledgable developer is passing by it would be good to know how the internal player handles these issues, eg is vdpaustudio a flag passed to the vdpau api or does it trigger different myth code? Is vdpau just a "magic black box" into which video is passed and pictures appear on the display or is there significant myth player code interacting with the API, if so how does the whole yuv/rgb/limited or full issue get handled?
> 
> I guess the suitably knowledable developer would be me:)
> 
> The VDPAU video rendering and colourspace handling is pretty much
> unchanged in 0.24 versus 0.23 - so I'm pretty sure the root cause of
> the problems reported lie somewhere in the drivers (which is not
> entirely surprising given a range of other issues being reported).
> I'm also not aware of any change in the VDPAU API - though I haven't
> actually checked in a while.
> 
> VDPAU uses a colourspace conversion matrix for colourspace handling
> (unsurprisingly!). It provides a convenience function to calculate
> this matrix for you for a small selection of colourspace standards in
> conjunction with brightness, contrast, colour and hue adjustments. We
> use this convenience function for 'PC level' rendering.
> 
> There is no setting or convenience function available for studio
> levels so when enabled, we manually calculate the matrix. If anyone is
> interested, it's the VDPAUCSCMatrix in
> llibs/libmythui/mythrender_vdpau.cpp.
> 
>> At the risk of significant developer ire I'd suggest maybe a "setting" to render the theme and software rendered video as full or limited range would be beneficial ;-) Just for those few not using vdpau and nvidia 260 drivers, both of you.... :-)
> 
> Entirely coincidentally, I'm 50% through a re-write of how we handle
> the colourspace conversion for video. This will manually calculate a
> conversion matrix for all scenarios (studio levels, colourspace
> standard, adjustments etc) that can be used across VDPAU, OpenGL and
> Direct3D and will have some sort of 'legacy' support for xvideo
> (depending on the XVideo functionality available).

Thanks for the explanation, makes much more sense now.

There is currently significant variation between video decoders and renderers, I've stuck with vdpau as being the one that looks most correct but it will be great to have consistent mappings, looking forward to that. 

As an aside, many commercial receivers still don't get this right, I've seen some horrors when pressing even high end domestic boxes into commercial service.

> I have no current plans to add a software based version or indeed
> extend it to drawing the UI.

Fair enough, any fussy types can always go buy an Nvidia card that v260 driver supports, oh, they probably have one already.

Thanks

Andre