Subject: Re: [MMUSIC] Maximum non-scaled image size

From: Randell Jesup <[email-masked]>
Date: 21 Mar 2005 16:25:18 -0500

>>>Based on the following Sentence:
>>>"Do any video payload formats specify, as SDP format attributes or
>>>otherwise, the maximum image size supported natively (i.e., without
>>>downscaling)?"

>>It talks about native support of image size, which I interpreted to mean
>>actual screen size. As the actual amount of macroblock, size of frame
>>buffer, that a receiver is capable of decoding is different from what it
>>natively can display. Thus I think there is clear reasons to separate the
>>capability for decoding from that of displaying. However I don't
>>necessarily think that it is appropriate to consider display resolution
>>capabilities in SDP, and definitely not in any overlapping
>>parameter. There are good reasons to differentiate the two capabilities.

>Fully agreed. Among other differences, the display size is likely a "soft"
>limit, i.e., something that the sender can exceed if you don't care about
>wasting bits. The frame buffer size seems more of a hard limit.

        With small/embedded devices (cellphones, etc), you can't always
just go over a natural limit and have things be usable (even if the
programmer wanted to).  Scalers are not cheap if there isn't dedicated
hardware; going over the display resolution may well not scale but instead
may crop (and the crop may be upper, left, middle, who knows?).  It may not
work at all (even if the decode HW has the capability to decode the number
of macroblocks per second you're sending) due to buffer sizes or other hard
or soft limits in the codec implementation.

        Similar things exist with going under preferred resolutions; a
device may not have a scaler, or if it doesn it may well not be arbitrary.

        As you say, there may be frame buffer or decoder limits (and not
just in bytes, but in pixels in each direction) due to memory and other
hardware. 

        The H.264 RTP SDP model includes (in some cases) receiver
capabilities in the fmtp (and sometimes sender capabilities).  They do
include a buffer size in max-dpb, but not the other items we're talking
about.

>>>Once this is clearer, we can then decide whether this is one parameter
>>>or possibly more. So far, all variations, whether motivated by frame
>>>buffer size or display size, seem to have the same effect: limit what
>>>the receiver is willing to receive or indicate what the sender will
>>>send, where the former seems somewhat more important.

>>I think one needs to make clear separation between frame-rate and
>>frame-size. However I do not think that this is sufficient at all. There
>>are so many other parameters in relation to decoding capabilities that
>>are to be considered. A few of these are: number of reference frames,
>>bit-rate according to the buffer model, number of macro blocks possible
>>to decode in a certain time interval, codec features.

>I'm trying to find a common, useful subset that has high impact on either
>interoperability or efficiency. Clearly, there will always be
>codec-specific parameters, such as the ones you mention. Maximum display
>size and maximum frame buffer size, however, seem pretty universal.

Display refresh speed is a pretty universal one too - it tells you updates
faster than that probably aren't useful (even if decodable), and also
probably tells you that this is a preferred speed.  I'll admit this one
might require a little thought compared to sizes, but it is important.  If
I have an LCD that updates at most 20 times per second, 60 frame per second
video is a pretty big waste of bandwidth.

-- 
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team
[email-masked]

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic