xpra icon
Bug tracker and wiki

Opened 5 years ago

Closed 5 years ago

#645 closed defect (fixed)

please show actual encoding in "Session Info/Connection"

Reported by: onlyjob Owned by: onlyjob
Priority: minor Milestone:
Component: client Version: 0.14.x
Keywords: Cc:

Description

I upgraded session 0.13.9 --> 0.14.0 using command xpra upgrade :44. Then I repeated upgrade command few more times. After that I've noticed that when I change encoding in client (0.14.0) some encodings appears to be chosen but actually they're not -- for example I selected PNG/greyscale but still could see colours; with RGB encoding there were some visual artefacts still visible as it appears that H.264 were actually used... While perhaps it were a glitch that I can't reproduce after restarting session on server I'd like to suggest showing actual encoding in use under "Session Info --> Connection" where I can see "rencode + lz4 (level 1)" but not the codec from "Encoding" menu. Thanks.

Change History (6)

comment:1 Changed 5 years ago by onlyjob

Something is wrong with encoding selection on 0.14.0. Even when I attach with "--encoding=png/L" Libreoffice Calc show colour background in spradsheet as well as low-quality regions so encoding used is definitely not PNG... (RGB is also affected). Seems to be regression from 0.13.9...

comment:2 Changed 5 years ago by Antoine Martin

Owner: changed from Antoine Martin to Antoine Martin
Status: newassigned
Summary: 0.14.0: please show actual encoding in "Session Info/Connection"please show actual encoding in "Session Info/Connection"
Version: trunk0.14.x

What does this have to do with upgrading?

FWIW: the "actual encoding" has been meaningless for some time, we choose the best encoding for the pixels we need to encode. The encoding selected in the tray is the "current encoding". For more info see #419

That said, there are some constraints: we should not be sending anything but png/L when it is selected (because it would look awful otherwise), rgb is also sticky, we try to stick to png / jpeg / webp when those are selected, but we may still use rgb instead when the compressed (or even uncompressed) raw data is smaller than wrapped in the container, etc..

I've seen the problem with png/L - will investigate.

Last edited 5 years ago by Antoine Martin (previous) (diff)

comment:3 in reply to:  2 Changed 5 years ago by onlyjob

Replying to totaam:

What does this have to do with upgrading?


Probably nothing -- I was merely describing what was happening when I got this problem... When reported I had too little experience with 0.14 to say if it (not) related to upgrade... Will try to report less noise in the future...
Thanks.

comment:4 Changed 5 years ago by Antoine Martin

Owner: changed from Antoine Martin to onlyjob
Status: assignednew

Does r7360 fix all the problems? (will backport)

comment:5 Changed 5 years ago by onlyjob

Yes, definitely fixes, thank you.

I still think it might be nice to show actual combination of primary/secondary codecs but it's up to you to decide whether it's worth implementing...

comment:6 Changed 5 years ago by Antoine Martin

Resolution: fixed
Status: newclosed

Backport in r7362 - thanks! Closing.


I still think it might be nice to show actual combination of primary/secondary codecs


The session info dialog already shows all the codecs supported by either end (in the "Features" tab), then when using a video mode you can end up using up to 6 different encodings at the same time.. Which ones get used will vary a lot. I really can't think of way of presenting this sanely.

Note: See TracTickets for help on using tickets.