On Mon, 17 Sep 2012 18:24:27 Antoine Martin wrote: > > No, sorry, x264 is the way forward, I'd rather fix the remaining latency > and quality issues than use a slow and outdated encoding.
No worries but please-please keep PNG encoding for high-speed connections. :) Just thinking: how about choosing the encoding dynamically on attaching? Something like when attaching, if bandwidth is high, choose PNG from very beginning but if connection is slow choose x264? I think it could be measured as number of KiB per sec for first 2-10 seconds after attaching.... I would try PNG first (because it's for highest quality) and see how fast we can pull the data. After few seconds xpra may decide to change encoding if data is coming too slow. Obviously we will need to calibrate but that's not difficult. Also in configuration file instead of "encoding = png" we could put something like "encoding = png,x264,jpg" to specify list of allowed encodings in the order of preference. Important thing would be to choose encoding only in the beginning but then allow user to switch while adjusting chosen encoding parameters dynamically as it is now. > > Downloaded and installed iceweasel, cannot reproduce... > Interesting... I was trying it too and now I took away https://www.xpra.org/trac/changeset/1543 and found that it has no effect whatsoever. I couldn't crash new sessions and one of the old ones which was not affected anyway. I still can crash one session where I initially fount the problem. I'll find out how to reproduce and will let you know. Cheers, Dmitry. _______________________________________________ shifter-users mailing list [email protected] http://lists.devloop.org.uk/mailman/listinfo/shifter-users
