zador.blood.stained Posted September 27, 2016 Share Posted September 27, 2016 I will look into that anyway, because a +100 sat value in MPV should get an 10.00 value in vdpau which should result in the maximum (100) for the display driver. Therefore, 0 in MPV should mean "no change" (1.00) in vdpau and 50 in display. Hm. Maybe you can adjust all the values in realtime (with number keys iirc) and see what is going on in the logs... Anyway, glad to here we got it working I tried this, changing saturation in mpv from -100 to 100 results in changing mix-> saturation from 0 to 1 (with 0.5 being the default value) Link to comment Share on other sites More sharing options...
rellla Posted September 28, 2016 Share Posted September 28, 2016 Thanks for testing. I'll have to look into mpv code.And no, it should not break anything on H3, because display2.0 is not using the equalizer... EDIT: Looking into mpv player code, it seems, that they don't scale their contrast and saturation value from 0.00-1.00-10.00 like vdpau spec likes it to have, but only map their -100~+100 to 0.00~1.00 So default is 0, which gets 0.50 in vdpau. According to ftp://download.nvidia.com/XFree86/vdpau/doxygen/html/struct_vdp_procamp.html#a96fd21f127e9b5ba24024f60ae42851dthis is wrong because it should be 1.00 Conclusion: Imho no libvdpau-sunxi issue but sth. mpv related 1 Link to comment Share on other sites More sharing options...
zador.blood.stained Posted September 29, 2016 Share Posted September 29, 2016 EDIT: Looking into mpv player code, it seems, that they don't scale their contrast and saturation value from 0.00-1.00-10.00 like vdpau spec likes it to have, but only map their -100~+100 to 0.00~1.00 So default is 0, which gets 0.50 in vdpau. According to ftp://download.nvidia.com/XFree86/vdpau/doxygen/html/struct_vdp_procamp.html#a96fd21f127e9b5ba24024f60ae42851dthis is wrong because it should be 1.00 I tried looking at mpv code too and noticed that they don't actually provide brightness, contrast, hue and saturation values directly to VDPAU, but instead calculate their own color conversion matrix here and then pass it to VdpVideoMixerSetAttributeValues with VdpVideoMixerAttribute == VDP_VIDEO_MIXER_ATTRIBUTE_CSC_MATRIX, where in vdp_video_mixer_set_attribute_values (in libvdpau-sunxi) brightness, contrast, hue and saturation are "reverse engineered" back from the csc matrix. So it's a good question where and what is the error, since mpv's mp_get_csp_matrix() is used by other code too and has some interesting comments about "full range" mentioned by you before. Link to comment Share on other sites More sharing options...
rellla Posted September 29, 2016 Share Posted September 29, 2016 Yeah, i talked with MPV people in irc in the meantime and concluded the same. Either the backwards calculation has some bug, the matrix is wrong or we miss some other bit... I have to check the first one with doing some tests with https://github.com/rellla/snippets/tree/master/sunxi_csc I'd like to see, that the calculation is right. But first we have to look into the matrices itself. Maybe I'll add a function in vdpau code to print them and see what's different ... Kind of strange that whole CSC thing... Edit: The function you linked should be definitely the one we have to compare with vdpau calculation routines. 1 Link to comment Share on other sites More sharing options...
rellla Posted September 30, 2016 Share Posted September 30, 2016 I think i found the problem: The vdpau in-built color space conversion uses a YCbCr->RGB conversion matrix depending on the Color Space (BT601 ...) as the base. This matrix can be processed with procamp values, that creates the new csc matrix. We cannot push that matrix directly into the sunxi display engine, but only the single values. So we have to calculate backwards using the resulting matrix (incl. procamp) and the original one. And here comes the issue... MPV uses his own base matrix, processes it themselves with some procamp values and gives it to vdpau. To calculate backwards, we need the base matrix, which is currently unknown within vdpau. And sadly it's different from ours, because it uses one for YUV->RGB conversion. What now seems to happen is the following: MPV creates a csc-matrix (YUV->RGB), vdpau calculates backwards using the standard BT.601 matrix (YCbCr->RGB) and gets single values, that are not intended to be set by mpv... The only thing we can do is, either to live with this issue or find a workaround to indicate, when the YUV->RGB matrix values have to be used for the backwards calculation. Doing that should not be the most ugly hack and should of course not break the rest. Any hints are welcome Reference: http://www.equasys.de/colorconversion.html rellla Link to comment Share on other sites More sharing options...
zador.blood.stained Posted September 30, 2016 Share Posted September 30, 2016 The only thing we can do is, either to live with this issue or find a workaround to indicate, when the YUV->RGB matrix values have to be used for the backwards calculation. Doing that should not be the most ugly hack and should of course not break the rest. Any hints are welcome I feel like the best workaround is disabling IOCTLs to display engine or hardcoding brightness, hue and saturation as 0. This breaks only video equalizer on A10/A20 boards and playing video with default values should be fine in all cases. I tested VDPAU playback on a laptop with mpv and vlc, and compared it side-by-side with xv output (I played this video). Video equalizer in mpv works fine with driver that I have (VDPAU_DRIVER=r600) and there is no visible difference in video image compared to xv output, so at least other vdpau drivers use different methods for setting brightness. Link to comment Share on other sites More sharing options...
Recommended Posts