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

Hi Cullen, all,

<cite>
Consider two different video flows using the same codec ...

Stream A is 640 x 480 at 1mbps which is this scaled to 320x240 and displayed

Stream B is 320 x 240 at 1mbps which is displayed at 320x240. 

My experience has been with modern video codecs that stream B will look better than stream A. As well as looking better, it will typically also have a better PSNR. There's a bunch of reasons why which are probably not worth going into here but give it a try and you will see what I mean. The key point is both streams where 1mbps. If stream B was sent at 256 kbps, then A would look better.
</cite>

Can I ask what you mean with "both streams where 1mbps"? Do you refer to the capacity of the channel (i.e. how much data the channel can transport), or to the actually codec bitrate (i.e. how much data is sent from the streaming server).

In the first case, assuming that the size of stream B is considerably less than the size of stream A, the quality of Stream B can be expected to be higher than the quality of Stream A, since a higher capacity of the channel results in less packet loss. 

In the second case, assuming both streams are coded at the same bitrate, the quality of Stream B can also be expected to be higher than the quality of Stream A, due to the availability of more bits per pixel (though similar packet loss).

However, if we reduce the capacity of the channel, it becomes more complicated. I think this highly depends on which codec is being used. For example, I am not sure whether  Stream B with 25% channel capacity would look better than Stream A (after scaling) with 100% channel capacity. I think this highly depends on the codec and scaling algorithm, and saturation of the channel.

To come to the question on whether negotiation of the video size is needed: I feel that it could be a useful feature. Even if the channel allows streaming the 640x480 version without congestion problems now, where is the guarantee that it will not happen later? Probably there will be multiple video streams (at least partially) using the same path. If congestion happens later, the codec bitrate of multiple streams may need to be reduced. How to know from which streams the bitrate needs to be reduced? It seems to be better to prevent this and use a reduced codec bitrate from the start for those streams that are known not to require a higher bitrate.

However, whether we can cater for this also depends on the actual technical solution for negotiation and which codec to use. If adding video size negotiation will not increase complexity too much, I see no reason not to do it. However, if it adds much complexity to the solution, we might need to consider whether it is worth it. Therefore, maybe it should not be a requirement, but something weaker; i.e. it could be phrased as a SHOULD rather than a MUST.

Best regards,
Bert

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen Jennings
Sent: 22 June 2011 00:11
To: Aron Rosenberg
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Changing video size (Re: use case:)

On Jun 20, 2011, at 1:30 , Harald Alvestrand wrote:

> 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.

Consider two different video flows using the same codec ...

Stream A is 640 x 480 at 1mbps which is this scaled to 320x240 and displayed

Stream B is 320 x 240 at 1mbps which is displayed at 320x240. 

My experience has been with modern video codecs that stream B will look better than stream A. As well as looking better, it will typically also have a better PSNR. There's a bunch of reasons why which are probably not worth going into here but give it a try and you will see what I mean. The key point is both streams where 1mbps. If stream B was sent at 256 kbps, then A would look better. 

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