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

[Harald Alvestrand <[e-mail]>]

On 06/22/11 05:59, Justin Uberti wrote:
> 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.
There might be some things it can do, even if it can neither recode nor 
do SVC-style tricks.
For instance, if it's a distribution point (one incoming video stream, 
many outgoing copies), it can keep track of the maximal video size 
requested by any of its downstreams, and signal the upstream to send a 
resolution that is no higher than the largest resolution requested.

I agree that we can't demand that the sender send exactly the resolution 
requested; in *many* cases, it's reasonable to send both higher and 
lower resolutions than the requested ones.

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