W3C home > Mailing lists > Public > public-media-capture@w3.org > May 2012

Digression: Ref frames (Re: Syntax options for constraints structure)

From: Harald Alvestrand <harald@alvestrand.no>
Date: Sun, 13 May 2012 08:37:26 +0200
Message-ID: <4FAF56A6.6000709@alvestrand.no>
To: public-media-capture@w3.org
On 05/11/2012 09:46 PM, Anant Narayanan wrote:
> On 5/11/12 10:51 AM, Dan Burnett wrote:
>> On May 10, 2012, at 3:17 PM, Anant Narayanan wrote:
>>> We could certainly make the optimization of grouping each "set" of 
>>> constraints in one object instead of making a new object for each 
>>> constraint, and I think Dan did have something like this in his 
>>> original proposal in the form of a "Constraint Set", IIRC.
>> Anant, this was for the mandatory structure, where ordering was not 
>> significant, and for the getCapabilities return value, where ordering 
>> is also not significant.
> I'm having trouble understanding the ordering requirement then. Why do 
> we need to support the case where there are two conflicting 
> constraints to begin with? Do we have a concrete example for this (as 
> you mentioned, minFrameRate and minTimeBetweenRefFrames don't really 
> make sense).

Just a digression:

{mandatory:[{videoMinHeight:600}, {videoMaxBandwidth:500}],

I interpreted this as saying that one wants 30 frames per second - most of those would be P frames, which are pretty small but require a reference to a complete frame elsewhere in the stream to be interpreted.
Reference frames (I-frames in H.264 parlance) can be interpreted without reference to any other frame, which makes them very desirable when recovering from errors, but comparatively speaking, they are *huge*.

A constraint on how often one sends reference frames might be a good idea - both in "max" and "min" variants - but the likely unit of that constraint is seconds, not milliseconds - so this spec would say that ref frames are to be sent no more frequently than every 20 seconds.

In interactive media, I think it's quite ordinary to send ref frames *only* when the recipient asks for one because a packet loss rendered the current P-frame stream incomprehensible.

Received on Sunday, 13 May 2012 06:37:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:35 UTC