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

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}],
   optional:[
     {videoMaxAspectratio:1.333333333333},
     {videoMinTimebetweenrefframes:20},
     {videoMinFramerate:30},
     {videoEnumAutowhitebalance:on}]}

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.

                     Harald

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