Subject: Re: [AVT] RFC 3984bis - level-idc

From: Ye-Kui Wang <[email-masked]>
Date: Fri, 12 Feb 2010 17:33:07 -0500

Venkat,

I have tried to make the representation of level-idc identical for existing
H.264/AVC profiles, but once bit 4 of the profile-iop byte of
profile-level-idc is specified for a different purpose for any future
H.264/AVC profiles, then there will be inconsistence between the draft and
the H.264/AVC spec. Therefore, I would keep the text unchanged herein. 

BR, YK

> -----Original Message-----
> From: Arunachalam Venkatraman (arunvenk) [mailto:[email-masked]] 
> Sent: Friday, February 12, 2010 5:08 PM
> To: Ye-Kui Wang; Tom Kristensen
> Cc: [email-masked]; [email-masked]
> Subject: RE: RFC 3984bis - level-idc
> 
> Ye-Kui
> While the semantics of the two fields are different, the 
> representation of the level-idc is identical. This is what I 
> was referring to in my original email. So, I urge you to 
> examine this keeping this point in mind.
> Thanks
> Venkat
> 
> The
> value  is a base16 (hexadecimal)
> representation of the two bytes after the syntax element 
> profile_idc in the sequence parameter set NAL unit specified 
> in [1]: profile-iop (as defined above) and level_idc.  If 
> (the level_idc byte of max-recv-level is equal to
> 11 and bit
> 4 of the profile-iop byte of max-recv-level is equal to 1) or 
> (the level_idc byte of max-recv-level is equal to
> 9 and bit 4
> of the profile-iop byte of max-recv-level is equal to 0), the 
> highest level the receiver supports is level 1b.  
> Otherwise,
> the highest level the receiver supports is equal to the 
> level_idc byte of max-recv-level divided by 10.
> 
> 
> -----Original Message-----
> From: Ye-Kui Wang [mailto:[email-masked]]
> Sent: Friday, February 12, 2010 3:51 PM
> To: 'Tom Kristensen'; Arunachalam Venkatraman (arunvenk)
> Cc: [email-masked]; [email-masked]
> Subject: RE: RFC 3984bis - level-idc
> 
> 
> Venkat, Tom,
> 
> I am updating the draft, in order it can progress to IETF LC. 
> 
> For the issue below pointed out by Venkat, and agreed by Tom 
> and myself,
> actually we should not make the change. The reason is as follows. For
> signaling of the max-recv-level, the text applies independent of the
> profile. How exactly level is signalled for profile-level-id 
> is clearly
> specified in the H.264/AVC coding specification, and is profile
> dependent, and there may be future extensions to the coding
> specification that would not comply to the text we have now for
> signaling of max-recv-level. 
> 
> Therefore, I will not integrate the change proposed below. 
> 
> BR, YK
>  
> 
> > -----Original Message-----
> > From: Ye-Kui Wang [mailto:[email-masked]]
> > Sent: Wednesday, October 07, 2009 10:18 AM
> > To: 'Tom Kristensen'; 'Arunachalam Venkatraman (arunvenk)'
> > Cc: [email-masked]'; [email-masked]'
> > Subject: RE: RFC 3984bis - level-idc
> > 
> > 
> > OK. The draft has now passed the 2nd WGLC, and I guess our chair is 
> > preparing to send the draft for publication. Once I got a chance to 
> > make some edits, I will integrate this change.
> > 
> > Thanks Venkat for pointing this out. 
> > 
> > BR, YK
> > 
> > > -----Original Message-----
> > > From: Tom Kristensen [mailto:[email-masked]]
> > > Sent: Tuesday, October 06, 2009 11:59 AM
> > > To: Arunachalam Venkatraman (arunvenk)
> > > Cc: [email-masked]; [email-masked]; [email-masked]
> > > Subject: Re: RFC 3984bis - level-idc
> > > 
> > > Venkat,
> > > 
> > > That's true. The explanation of profile-level-id is more or
> > less the
> > > same as in RFC3984, but for the new max-recv-level a thorough 
> > > explanation of how to interpret the level-idc to find the 
> level "in 
> > > action" included.
> > > 
> > > YK; maybe the best option is to move this explanation to 
> the first 
> > > parameter in the list of the optional parameters (which is 
> > > profile-level-id), and refer to the explanation if necessary for 
> > > max-recv-level?
> > > 
> > > -- Tom
> > > 
> > > On Tue, 2009-10-06 at 08:44 -0700, Arunachalam Venkatraman
> > (arunvenk)
> > > wrote:
> > > > Dear Authors,
> > > > In the RFC 3984-bis specification, the interpretation of
> > > level-idc is
> > > > not discussed in the profile-level-id paragraph.
> > > > In the section on max-recv-level, this is clearly
> > explained (copied
> > > > below). Should the discussion of the mapping of level-idc
> > > to the H.264
> > > > level values apply to both of these
> > > parameters(profile-level-id  and
> > > > max-recv-level)?
> > > > Regards
> > > > Venkat
> > > > max-recv-level:
> > > >           This parameter MAY be used to indicate the
> > highest level a
> > > >           receiver supports when the highest level is
> > > higher than the
> > > >           default level (the level indicated by
> > > profile-level-id).  The
> > > >           value of max-recv-level is a base16 (hexadecimal)
> > > >           representation of the two bytes after the 
> syntax element
> > > >           profile_idc in the sequence parameter set NAL
> > > unit specified
> > > >           in [1]: profile-iop (as defined above) and
> > level_idc.  If
> > > >           (the level_idc byte of max-recv-level is equal to
> > > 11 and bit
> > > >           4 of the profile-iop byte of max-recv-level is
> > > equal to 1) or
> > > >           (the level_idc byte of max-recv-level is equal to
> > > 9 and bit 4
> > > >           of the profile-iop byte of max-recv-level is
> > > equal to 0), the
> > > >           highest level the receiver supports is level 1b.  
> > > Otherwise,
> > > >           the highest level the receiver supports is 
> equal to the
> > > >           level_idc byte of max-recv-level divided by 10.
> > > 
> 
> 
>