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

["Bran, Cary" <[e-mail]>]

Hi,

I have made changes to the 02 version that reflect this thread and a
couple of other threads ­ the new text is as follows:

"The following feature list applies to all required video codecs.

   Required video codecs:
   o  MUST support at least 10 frames per second (fps) and SHOULD
      support 30 fps

   o  If VP8, then MUST support a the bilinear and none reconstruction
      filters

   o  OPTIONALLY offer support for additional color spaces

   o  MUST support a minimum resolution of 320X240

   WebRTC client implementations will span across a variety of devices.
   Some of the these devices have fixed formats due to hardware
   constraints, others like a desktop browser are quite flexible.
   Instead of placing implementation constraints on the supported
   resolutions, below is a list of suggested common resolutions for
   WebRTC client implementations.  The suggested resolutions should be
   considered only if they can be displayed on the target device.

   WebRTC client implementations SHOULD support:

   o  Resolutions of 1920X1080, 1280x720, 720x480,
      1024x768, 800x600, 640x480, 640 x 360

   o  A PAL resolution of 576 lines."





On 11/17/11 8:20 AM, "James M. Polk" <[e-mail]> wrote:

>At 04:10 AM 11/17/2011, Harald Alvestrand wrote:
>>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*
>
>I think Harald's suggestion included "Must support 320 x 240" too,
>which is listed as a MUST and SHOULD throughout this thread (which I
>believe is in error). If this resolution is specified, it needs to be
>either MUST or SHOULD, not both.
>
>Roni has a good suggestion about the ability of a receiver to request
>a resolution in SDP, but I think we still should have a given
>resolution defined here, and understanding that each device could
>have wildly different capabilities, Harald's suggestion above covers
>the most cases IMO but only with the text between the * ... * included as
>well.
>
>James
>
>
>>>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.
>>
>>
>>_______________________________________________
>>rtcweb mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/rtcweb
>
>_______________________________________________
>rtcweb mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rtcweb