On Mon, 17 Sep 2012 23:21:07 Antoine Martin wrote: > This was originally planned, but x264 does all that and better: at high > quality it is indistinguishable from lossless encodings (png or rgb24), > at lower quality settings it is an order of magnitude more efficient > than jpeg (and still with much better quality) > All that's needed is to properly tune the quality based on bandwidth > availability. Sounds simple, but it isn't. > Bandwidth availability varies widely, and so does our "framerate" - > which isn't necessarily a full-frame rate (from 0fps when idle to up to > 200 updates per second). Then there are latency issues, etc.. I know how tricky it could be to do that kind of fine tuning. Maybe it's all not as important as to give user a way to choose quality like it is done for JPEG encoding.
Since it is all about perception, there is no way to satisfy all situations automatically. I can always switch to a different encoding if necessary but the choice will depend on traffic conditions which are varies widely, as you've said. Personally at the moment I'm worried about current situation when new default to x264 is totally unusable in the ideal situation (low-latency gigabit ethernet with server several meters away from client connected to the same switch). We can't/shouldn't optimise to slow connection only by default. Especially because this wasn't the case for previous versions. I'm sure you know what you're doing but let's try to be a bit more conservative please. All the best, Dmitry. _______________________________________________ shifter-users mailing list [email protected] http://lists.devloop.org.uk/mailman/listinfo/shifter-users
