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: 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
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>