Re: [rtcweb] Changing video size (Re: use case:)

Applications requiring (or making desirable) adequate response of the video
codec to changes of rendering window sizes are a perfect scenario for the
use of spatial scalability.  One avoids the waste of sending bits for a high
resolution picture that cannot be rendered at high resolution, but has
freedom to start sending high resolution, without the delay involved in
sending an I frame, at any time.

Scalable video is also a useful tool to combat losses and to adapt
seamlessly to changes in the channel bandwidth (to combat congestion, for
example).

Stephan

From:  Harald Alvestrand <harald@alvestrand.no>
Date:  Mon, 20 Jun 2011 10:30:34 +0200
To:  Aron Rosenberg <arosenberg@logitech.com>
Cc:  <rtcweb@ietf.org>
Subject:  [rtcweb] Changing video size (Re:  use case:)

 On 06/17/11 21:38, Aron Rosenberg wrote:
>  
> On Fri, Jun 17, 2011 at 11:09 AM, Cullen Jennings <fluffy@cisco.com> wrote:
>  
>>  
>>  Video Size Change.
>>  
>>  Alice and Bob are in a video call in their browsers and have negotiate a
>> high resolution video. Bob decides to change the size of the windows his
>> browser is displaying video to a small size.  Bob's browser should be able to
>> regenerate the video codec parameters with Alice's browser to change the
>> resolution of video Alice sends to match the smaller size.
>>  
>>  
>>  
>  
> Changing compression due to a user change in window size is usually not done
> since it has a bad long term effect on video quality. In almost all the major
> video calling systems, video resolution is a function of current bandwidth
> (which changes as the rate control system detects differences) and/or
> constrained by the physical device, but not a function of a user dragging the
> window size. At an equivalent bitrate, it is better to compress a larger
> resolution and display it smaller (higher PSNR), then compress a smaller
> resolution if you are within the codec's effective bitrate for that larger
> resolution.
>  
>  
>  
 Interesting info, but I don't know if it's true in all cases.

 If the overall constraint on a conferencing system is bandwidth, the system
might find the saving in average bandwidth saving of encoding from a base
image of 140x200 for "small" windows rather than "HD" (720x1024?) worth
considering, even though the sending of a complete I-frame to reinitialize
the video stream might take some effort.

 I like having the use case of "change recipient video window size, and as a
result change sender bandwidth usage"; we might argue about the exact
phrasing of the use case.

                    Harald

_______________________________________________ rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb