On 5/6/11 11:25 AM, Arthur Huillet wrote: > My use case is that the bandwidth is constrained by the network (I'm running > VNC over the Internet). The idea was to tell > vncviewer what is the throughput your connectivity allows you, and it would > tune the quality so that you consume exactly this > bandwidth, raising the quality when possible. (As for the relationship > between bandwidth and quality, I have done a few > measurements that make me think this relationship is linear on a large part > of the image quality range. Fine tuning is more > difficult between 75 and 95.)
I assure you the relationship isn't deterministic. The compression ratio varies wildly for different types of application workloads, and when you speak about compression ratios vs. JPEG qualities, you can only speak about averages. Thus, dynamic fine tuning would have to be an iterative process. The viewer could, for instance, keep monitoring and re-adjust down or up until it converged on the right setting. As to the right algorithm for that, I haven't really thought that far. I don't envision it being particularly easy. > Obviously, the user doesn't really care about a target bandwidth, so I admit > this isn't a great idea because it doesn't reflect > what the user might expect. The way I see it, the user expects a minimal > number of frames per second, with a minimal image > quality (this is what HP RGS, a proprietary remote desktop tool, provides). > > I am unclear about the pixel throughput - it's a value that doesn't represent > anything to the user nor to the network (it's not > kilobytes, and it's not frames per second). > > I think it's fair to define the (my) users' expectation as "more than X FPS, > with a quality greater than Y, and a better > quality when the image does not move". This is the use case I am interested > in and this is what I would like to work on, > naturally with the objective that everything is generic enough to be > integrated into TurboVNC and used by as many people as > possible. > > The FPS part seems to be difficult to handle due to the VNC architecture, > I'll read more doc and see if I can come up with > something. My first idea, as I explain above, was to link that to bandwidth. > > Ideas and advice about how to behave according to the expectation I described > above are appreciated. The fundamental crux of the issue is that we don't know when the application is attempting to send us a frame or which framebuffer updates correspond to that frame. We also don't know whether a delay between framebuffer updates is due to network latency or bandwidth constraints or whether the application is simply rendering slowly. When I had thought about this problem before, the only thing I came up with in my head was for the client to embed a sequence number in the framebuffer update request, and the server would send back the corresponding sequence number in the framebuffer updates generated in response to that request. This would allow the client to measure how long it took for the request and corresponding update to transit the network. Problem: How do you know whether this transit time is latency-bound or bandwidth-bound? You would have to periodically send a ping to measure the latency so you would know for sure. Problem: TurboVNC 1.1 introduces a "continuous updates" feature, which essentially pushes updates from the server directly to the client, in order to eliminate some of the latency-dependence of the RFB protocol. The sequence number mechanism proposed above would not work with continuous updates. It would also require extending the RFB protocol, which is not something I'm keen on doing. I have to admit that I really don't see a clean solution to the dynamic quality adjustment problem at the moment. That doesn't mean that we can't implement a crude mechanism based on setting a pre-defined JPEG quality corresponding to a particular range of updates/second, but such a mechanism wouldn't really correspond to application frames/second in most cases. ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ VirtualGL-Devel mailing list VirtualGL-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
