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

[Stefan Håkansson LK <[e-mail]>]

All,

this RFC could perhaps be useful for this purpose of signaling display size: http://www.rfc-editor.org/rfc/rfc6236.txt

Stefan

________________________________
From: [e-mail] [mailto:[e-mail]] On Behalf Of Bert Greevenbosch
Sent: den 22 juni 2011 07:56
To: Justin Uberti
Cc: [e-mail]
Subject: Re: [rtcweb] Changing video size (Re: use case:)

Hi Justin, all,

Yes, that is a second issue. Even if the receiving end can signal its current display size, the streaming source might not be able to provide it. Therefore flexibility would be needed for the source on how to handle the display size information.

Best regards,
Bert


From: Justin Uberti [mailto:[e-mail]]
Sent: 22 June 2011 11:59
To: Bert Greevenbosch
Cc: Cullen Jennings; Aron Rosenberg; [e-mail]
Subject: Re: [rtcweb] Changing video size (Re: use case:)

Given the fact that this request for a video size change is an optimization (either of resources or user experience), I think that SHOULD is probably the strongest label we can put on it. Consider the case of a middlebox; if it has no capacity to scale the stream, due to compute or codec restrictions, there's not much it can do with this request.


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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Cullen Jennings
Sent: 22 June 2011 00:11
To: Aron Rosenberg
Cc: [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtcweb