In ticket:2056#comment:12 Antoine suggested implementing an X-window property called _XPRA_QUALITY for setting the encoder quality on a per-window basis.
This ticket which I am opening is to request that enhancement. I have already implemented support for setting this property in some OpenGL software (from my employer). To do this I used the XA_INTEGER type. I am ready to test _XPRA_QUALITY as soon as it is added.
Please try r21238 or later.
With the attached patch it works. I haven't look through XPRA to figure out what the difference between "get" and "get_property" is.
I don't really understand why you needed that patch (what did you see?) - in fact, I don't understand how it could possibly work with that patch and without r21244. In any case, r21243 merges that change and also tidies up the code.
How I tested:
XPRA_WINDOW_PROPERTIES_DEBUG=quality python2 /usr/bin/xpra --start=xterm --no-daemon -d compress
(note: it may take up to a second for the new quality setting to take effect)
Verified the value is set correctly with:
$ xpra info | grep quality-hint client.window.1.property.quality-hint=-1
With just "get" it always returned a "-1". With "get_property" everything worked fine. I'll try your updated one though.
It still works. Now the value "0" doesn't work. That's not a big deal though, I'll let our UI people know that the slider should range from 1 to 100.
Thanks!
Replying to Nathan Hallquist:
With just "get" it always returned a "-1". With "get_property" everything worked fine. I'll try your updated one though.
It seems to register changes in the slider more rapidly than before, but it's hard for me to be certain.
Replying to Nathan Hallquist:
It still works. Now the value "0" doesn't work. That's not a big deal though, I'll let our UI people know that the slider should range from 1 to 100.
Thanks!
Replying to Nathan Hallquist:
With just "get" it always returned a "-1". With "get_property" everything worked fine. I'll try your updated one though.
Now I have one other small problem. Even with _XPRA_QUALITY set to "99" the menus always jump in blurry (so blurry as to be useless) and then they settle to lossless. Is there a setting/way to fix this.
We *can* pass in the relatively coordinates of the video region if that helps. I have both quality set to auto and encoder set to auto and I've not disabled scroll encoding.
Here's a compress log of me triggering a menu:
2018-12-19 09:40:17,622 compress: 0.3ms for 226x174 pixels at 0,0 for wid=64 using jpeg with ratio 1.1% ( 153KB to 1KB), sequence 1, client_options={u'quality': 0} 2018-12-19 09:40:17,634 compress: 0.2ms for 72x26 pixels at 127,0 for wid=3 using rgb24 with ratio 15.7% ( 7KB to 1KB), sequence 186, client_options={'bucket': 2, 'lz4': 1, 'store': 373, 'rgb_format': 'BGRX'} 2018-12-19 09:40:17,777 compress: 2.8ms for 226x174 pixels at 0,0 for wid=64 using webp with ratio 7.7% ( 153KB to 11KB), sequence 2, client_options={u'quality': 100, u'rgb_format': 'BGRX'} 2018-12-19 09:40:18,383 compress: 0.1ms for 72x26 pixels at 127,0 for wid=3 using rgb24 with ratio 14.4% ( 7KB to 1KB), sequence 187, client_options={'delta': 373, 'bucket': 2, 'lz4': 1, 'store': 375, 'rgb_format': 'BGRX'} 2018-12-19 09:40:18,754 compress: 0.5ms for 221x446 pixels at 0,0 for wid=65 using jpeg with ratio 0.9% ( 385KB to 3KB), sequence 1, client_options={u'quality': 0} 2018-12-19 09:40:18,779 compress: 0.1ms for 82x26 pixels at 240,0 for wid=3 using rgb24 with ratio 0.6% ( 8KB to 0KB), sequence 188, client_options={'delta': 343, 'bucket': 3, 'lz4': 1, 'store': 377, 'rgb_format': 'BGRX'}
Now I have one other small problem. Even with _XPRA_QUALITY set to "99" the menus always jump in blurry (so blurry as to be useless) and then they settle to lossless. Is there a setting/way to fix this.
Yes, that's a bug. I saw it, I'll try to find the time for it today.
We *can* pass in the relatively coordinates of the video region if that helps.
That always helps, there's a dbus api for that: #1401, #1060, #1295
We could also support a _XPRA_VIDEO_REGION
window property if that helps.
I have both quality set to auto and encoder set to auto and I've not disabled scroll encoding.
Good.
I would prefer to use x window properties because people here already know how to do that.
That said, we could probably use dbus if necessary. Practically, using dbus would mean I would have to learn how to use dbus myself and then show the UI people; a display property would certainly be simpler for me. (I already did this process for display properties; I learned how to program them from the documentation and then I showed the UI team).
I would prefer to use x window properties because people here already know how to do that.
Then please create a new ticket for this feature request.
Even with _XPRA_QUALITY set to "99" the menus always jump in blurry (so blurry as to be useless) and then they settle to lossless. Is there a setting/way to fix this.
This is fixed in r21250, see commit message for details. You should now also be able to use the full range, from 0 to 100 for quality and speed settings.
Replying to Antoine Martin:
Even with _XPRA_QUALITY set to "99" the menus always jump in blurry (so blurry as to be useless) and then they settle to lossless. Is there a setting/way to fix this.
This is fixed in r21250, see commit message for details. You should now also be able to use the full range, from 0 to 100 for quality and speed settings.
Thanks for fixing this!
When you said, "that is a bug" I may have misunderstood you. I thought you were talking about the blurry menu issue. Are the blurry menus caused by a overly-large video region, perhaps?
I thought you were talking about the blurry menu issue. Are the blurry menus caused by a overly-large video region, perhaps?
I'm pretty sure the blurry menus were caused by the quality being set to zero due to the invalid clamping which is fixed in r21250. Menus have their own windows so they should not be affected by video regions. Is it not fixed?
I thought you meant this was in response to my comment that we were going to have to change our sliders so that they go from 1 to 99. This is what happens when I think I understand things.
Anyway, you are right. That fixed it! Thank you.
When I adjust the _XPRA_QUALITY attribute it does not seem to take effect until I let my program sit idle for a while. I suspect XPRA is not updating the quality in the nvenc encoder until it recycles the context. (I haven't dug into this too deeply yet, but I can if requested)
When I adjust the _XPRA_QUALITY attribute it does not seem to take effect until I let my program sit idle for a while.
Fixed in r21259, see ticket:2022#comment:47.
Feel free to re-open if you still have issues.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2077