----- Mensaje original ----- > Hi, > > On 02/26/2013 01:40 PM, Marc-André Lureau wrote: > > Hi > > > > ----- Mensaje original ----- > >> The adaptive video streaming is implemented by the following > >> heuristic: > >> Given a bit rate, we calculate the best combination of mjpeg > >> quality > >> and frame rate (henceforth, the stream parameters) for this > >> bit rate. In order to decide this combination, we evaluate the > >> encoding size for different jpeg > >> qualities by applying them on successive frames. > > > > But no downscaling? > Good point. However, the default libjpeg sampling factors values are > already 2 for luminance components and 1 for chrominance components > (both horizontal and vertical), while 4 is the highest value, and > larger > factor means higher resolution. It is worth trying decreasing the > luminance to 1. According to wikipedia, the jpeg YUV downscaling is: "The ratios at which the downsampling is ordinarily done for JPEG images are 4:4:4 (no downsampling), 4:2:2 (reduction by a factor of 2 in the horizontal direction), or (most commonly) 4:2:0" So luminance is not downsampled. Is that what you said? According to my experience with video codecs (not so much with jpeg itself), downsampling really makes a difference to most codecs, both in term of overally quality and cpu usage. > > How is this going to work with multiple client? > Each client have a separate rate-controller and a different stream. > Ages > ago, we (alon an I) talked about clustering clients according to > their > network setup, and encode each message only once per cluster. I think > that when we have such mechanism, we can use one rate controller per > cluster, and then we can base our estimations on the "weakest" client > in > the cluster. Ah good, just wanted to make sure this was covered somehow. > >> - Add vp8 encoding > > > > Video codec is really bad, it will really take a lot of CPU, unless > > it can be done on GPU? > > > I haven't tried it yet, is it even worse than the libjpeg-turbo > performance? For high resolution videos, the cpu usage for > libjpeg-turbo > is very high. > About hardware acceleration (at least for decoding): > http://en.wikipedia.org/wiki/WebM#Hardware For high resolution video (>720p) the videos codecs are _real_ hogs. I use to run cpu/qos quality of video codecs, and libvp8 at that time wasn't able to do real time 1080p even on our fastest hardware (using 8 xeon cores iirc). It wasnt't very good at running on multiple threads. I can imagine it may have improved for the past 2 years. (x264 with realtime quality level was ~4x faster iirc). _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel