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

[Harald Alvestrand <[e-mail]>]

On 11/29/2011 07:30 PM, Bran, Cary wrote:
> 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
Can you get rid of this one?
The VP8 people explicitly want to discourage anything that looks like 
we're blessing partial implementation - we want all implementations to 
support everything defined in the RFC.
>     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."
This looks good to me. Is there a defined answer to "what's the 
horizontal resolution when the vertical resolution is 576 lines", or is 
it "it depends"?
>
>
>
>
> 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
>
>