Re: [rtcweb] VP8 vs H.264 - the core issue

[Ted Hardie <[e-mail]>]

On Thu, Oct 24, 2013 at 8:40 AM, Bo Burman <[e-mail]> wrote:

>   **
>
> *What “logically extended” intends to achieve is to specify a set of
> parameter values applied to the encoding process, starting from the set
> called “level 1.3” and increasing a few parameter values *
>

Is this meant to be level 1.2?  The draft says:

H.264 Constrained Baseline Profile Level 1.2 MUST be supported as
      Mandatory To Implement video codec.

I assume that this means shifting from 1.2 to 1.3 with the parameter set
for CHB?




> *beyond “level 1.3”. The word “extended” for this operation is fully in
> line with existing text in RFC 6184 specifying how to signal H.264 codec
> capability. “Logically extended” is not a term of art but was chosen due to
> a comment that an H.264 level cannot formally be “extended” in ISO/ITU-T
> terms even though the term is used in RFC 6184, but you will have to
> restrict a higher level instead. The result is however the same; a set of
> specified parameter values applied to the encoding process. *****
>
> * *
>
>
>
> I also note that the discussion here is about a Mandatory to Implement
> codec
> (that is, something at a MUST level that avoids negotiation failure).  Your
> document appears to assign that to Constrained Baseline Profile Level 1.2.
> ****
>
> *[BoB] Yes, and still do.*
>
>
>
> The discussion of Constrained High seems to me about an optimization and
> is at most an aside, and not part of the core issue to be decided.
> If you have changed your view and  believe that Constrained High Profile
> Level 1.3 should be mandatory to implement, then it would be useful to say
> so more forcefully than above. If you have not, then I believe it is not,
> strictly speaking, relevant.****
>
> *[BoB] I did not change my mind on MTI; it is Constrained Baseline.*
>
> * *
>
> *I do believe the discussion on Constrained High is relevant; it is part
> of the overall argumentation for H.264 and relates to the important aspect
> of potential for improvement beyond MTI. *
>

I described this an optimization, and I think your comments actual support
that.  Our overall approach allows negotiating among multiple codes; the MTI
is not a restriction.  Having part of that negotiated set be related may
make
is simpler to support, but it is entirely possible to do it across codec
families
as well.



> *H.264 Profiles and Levels are essentially parameter restrictions on a
> single codec specification. If you have H.264 CBP as MTI but want access to
> even better performance, you don’t have to implement or license yet another
> codec but can still make use of H.264, only with another parameter setting
> (given that the specific implementation supports both CBP and CHP). Given
> that there are many other possible ways to set parameters to “H.264”,
> pointing to a specific “good” one beyond MTI seemed reasonable. This is
> arguably an optimization, but not only that.*
>
> **
>

I'm not sure I understand what makes it more than an optimization.

regards,

Ted Hardie




> **
>
> My personal view,
>
> regards,
>
> Ted Hardie****
>
> ** **
>