Re: [rtcweb] Stephan Wenger's choices

[Stephan Wenger <[e-mail]>]

Interestingly enough, H.261 *never* had a set of picture parameters that
bear a relationship with source formats dominant in the market.
CIF has 288 lines, QCIF 144, both distinctly non NTSC world.  OTOH, the
frame rate is 1/29.97 Hz fractions thereof, definitely not PAL/SECAM.
This is the result of a standardization compromise of the worst sort.
Note that this hasn¹t hindered the adoption of H.261 much.  Perhaps
because, at the time, there were literally no alternatives.  Today there
are.
Stephan
  

On 12/28/13, 1:50 PM, "Gunnar Hellstrom" <[e-mail]>
wrote:

>On 2013-12-28 22:24, Ron wrote:
>> On Sat, Dec 28, 2013 at 11:20:28AM -0800, Eric Rescorla wrote:
>>> Even if we mandate H.261, there is a reasonable chance of their
>>> expectations being thwarted, since they might well expect that
>>> the quality of video would be comparable, yet it will not.
>> You don't get much more thwarted than "no video for you", the only
>> direction from there is up.  Given a device with a ~4 inch screen,
>> viewed from a foot or two away, possibly in open daylight, maybe
>> even while bouncing around on a bus or train or while walking,
>> maybe with a bunch of scratches on the screen or a plastic cover,
>> there's a fair bet that a significant percentage of viewers wouldn't
>> be able to pick the difference between it and a perfectly lossless
>> image stream anyway.
>>
>> Is it going to be worse than NTSC television?  How many people were
>> happy enough to keep buying and watching those?  How many still
>> would if it was all that they could get?
>H.261 has only CIF and QCIF formats defined. Modern cameras tend to not
>support these formats anymore, more often delivering formats like QVGA ,
>VGA and various wide screen formats. And applications adapt to these
>modern cameras.
>Using H.261 sometimes and modern codec sometimes will create situations
>when you will get unpleasant compromises in video formats, such as
>cropped pictures, or pictures with unused margins, or processing-costly
>remapping that also reduces quality.
>
>That together with the low quality makes it not desirable.
>
>Gunnar
>>
>>
>> Sure it might not look optimal on your studio monitor, or your floor
>> to ceiling boardroom conference screen, or to eyes that have spent
>> years picking out visual artifacts from lossy codecs.  But we're not
>> ruling out those people being able to use state of the art codecs
>> that have no hope at all of running on minimal devices.  We're looking
>> for a baseline that poses the minimal challenge to everything being
>> able to support it, for the broadest scope of interoperability.
>>
>> Things that can will always negotiate up from that.  What is the
>> technical reason for setting the lowest bar so high that many of the
>> supposed target devices will never be able to reach it?  There would
>> seem to be few real barriers to making a more inclusive choice here,
>> so why don't we just do that and move on?
>>
>>    Ron
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
>_______________________________________________
>rtcweb mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rtcweb