Re: [rtcweb] Video resolution SHOULDs (Re: resolutions in draft-cbran-rtcweb-codec-01)

["Roni Even" <[e-mail]>]

HI,

I am not familiar with VP8 but for H.264 the specification says that a
complaint decoder must receive any stream from the encoder and crop/scale
for rendering.

In order to get over this limitation there are parameters  for the codec
that can limit the size starting from the level parameter. In the mobile
case since the BW is limited you will use a lower level that does not
support the HD resolution. For example level 1 is limited to 64 kbit/sec
with maximum resolution of 176x144, for the must support you need to have
192 kbit/sec level 1.1.

You can override the maximum resolution by lowering the maximum frame rate
and this are parameters specified in the H.264 payload specification.

There is also the SDP image attribute that allow the receiver to ask for
specific resolution and aspect ratio.

 

As for your suggested text, I am not sure why you need it since these are
requirement that the codec should support and not for using for send or
receive. It says that a candidate codec should have an HD mode, some older
codecs like H.261 did not have this mode.

 

 

 

 

Roni Even

 

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of
Harald Alvestrand
Sent: Thursday, November 17, 2011 12:10 PM
To: Stephan Wenger
Cc: [e-mail]
Subject: Re: [rtcweb] Video resolution SHOULDs (Re: resolutions in
draft-cbran-rtcweb-codec-01)

 

On 11/17/2011 05:54 PM, Stephan Wenger wrote: 

The highlighted part of Harald's suggestion below

 

   SHOULD support resolutions of 1920x1080, 1280x720, 720x480, 1024x768, 

      800x600, 640x480, 640 x 360 , 320x240 *if these resolutions can be
displayed on the target device*

 

seems sensible.  However, I have another issue.  I don't believe that naming
specific resolutions is advisable.  In a system where the rendering side has
almost undefined picture properties because they are typically rendered in
"windows", it IMO does not make much sense to limit yourself to certain
aspect ratios, picture sizes etc., even if those correspond to today's
preferred sensor resolutions (or integer fractions thereof).  Resampling an
input signal is cheap nowadays (at least compared to the encoding itself),
and cropping is even cheaper.

I would instead recommend naming one single MUST resolution (as the draft
does) to ensure minimum interoperability, and otherwise negotiate a
processing rate in macro blocks per second (or equivalent), with fixed
constraints around the aspect ratio.

For requirements, I prefer to list specifics, because they're testable.

One of my colleagues had a failing test the other day because he'd specified
a picture height of 94 pixels - he did not know that his encoders only
supported pixel counts that were multiples of 8.

Of course a device will not fail to interoperate just because it supports
decoding more resolutions than those that are required.

BTW, I believe 640x360 is a 16:9 aspect ratio, so handling both 16:9 and 4:3
seems to be a SHOULD based on this resolution list. I assume that's
intentional.