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

Agree with folks on this thread about this being a way for the receiver to tell the send it's preferences - Perhaps the receiver might indicate that it would like 1080P video but the best the sender can do is 720P because that is the size of camera they have.  In this case the sender does what the sender wants ignoring the receiver. There are other cases where say the receiver can not decode a bitstream above 768 kbps but the sender would typically send a stream at a much higher rate than this. In this case the sender needs to do what the receiver wants. You might have an old browser that support vp8 and newer version of the browser that does both vp8 and vp9 and you use vp8 when that is all you have but prefer vp9 if both sides support it. I'm not sure exactly how to phrase all this but roughly speaking we need a way for the sender and receiver to agree on a format that meets the constraints of both and somewhat optimizes the desiree format within these constraints. 

On Jun 22, 2011, at 12:06 AM, Stefan Håkansson LK wrote:

> All,
>  
> this RFC could perhaps be useful for this purpose of signaling display size: http://www.rfc-editor.org/rfc/rfc6236.txt
>  
> Stefan
> 
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bert Greevenbosch
> Sent: den 22 juni 2011 07:56
> To: Justin Uberti
> Cc: rtcweb@ietf.org
> 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:juberti@google.com] 
> Sent: 22 June 2011 11:59
> To: Bert Greevenbosch
> Cc: Cullen Jennings; Aron Rosenberg; rtcweb@ietf.org
> 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: 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
>  
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb