Re: [rtcweb] H.263 Baseline vs. H.261? (Was: H.263 licensing situation)

[Leon Geyser <[e-mail]>]

>>3.) People can live with the IPR risk. (I don't think we can conduct a
comprehensive study within the WG, but people need to >>draw their own
conclusions.)
H.263 sounds risky to me since it is only 17 years old. I would feel more
comfortable with H.261.
Even Theora feels less risky than H.263.


On 25 November 2013 22:14, <[e-mail]> wrote:

> Hi Stephan, all,
>
> Stephan Wenger wrote:
> >
> > H.263 baseline is insufficient for rtcweb¹s purposes, as it does not
> allow
> > arbitrary picture sizes.  You want to have at least the PLUSPTYPE picture
> > header extension which allows arbitrary picture sizes.  You also probably
> > want a few of the optional modes, especially the bug-fixes (improved VLC)
> > and the deblocking filter.  Patents related to this technologies are not
> > covered under the MPEG-LA MPEG-4 part 2 license.
> >
>
> How would you compare H.263 Baseline to H.261? Or H.263 Baseline with
> PLUSTYPE extension to H.261? Based on the list discussion it seems quite
> clear that none of the main browser vendors is really interested in
> including H.261, even if it was IPR-free. Would H.263 Baseline suck more or
> less? I have gotten an(other) educated opinion that the H.263 Baseline IPR
> risk was "virtually non-existent" already a few years back.
>
> In any case we need to define what "H.263" actually means within the
> alternatives. Does it stand for the H.263 Baseline, or do we want to add
> some of the features listed in Stephan's mail to make it usable?
>
> I'm currently thinking that "MUST implement any two of {VP8, H.264 CBP,
> H.263}" is the only sensible outcome for the WG apart from the "MUST
> implement either one of {VP8, H.264 CBP}, that I assume everyone will
> anyway be compliant with. But that would require:
> 1.) Define what exactly "H.263" is in this context: Baseline or Baseline
> plus a set of extensions
> 2.) People consider it better than H.261, and actually usable for WebRTC
> 3.) People can live with the IPR risk. (I don't think we can conduct a
> comprehensive study within the WG, but people need to draw their own
> conclusions.)
>
> Markus
>
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of ext Stephan Wenger
> > Sent: 18 November, 2013 18:36
> > To: [e-mail]
> > Subject: [rtcweb] H.263 licensing situation
> >
> > Hi,
> >
> > Here is what I know or suspect regarding H.263 licensing:
> >
> > Know:
> >
> > Leon is correct, there are type 2 patent declarations in the ITU against
> H.263.
> >
> > Maik is also correct, H.263 baseline is a subset of MPEG-4 part 2.
>  MPEG-4
> > part 2 is generally considered royalty bearing and the license has been
> > enforced.  However, very few (no one?) is using strict H.263 baseline,
> and
> > even for an only slightly more advanced use of H.263 (no need to go to
> > H.263+, for example), the MPEG-4 portfolio license would not apply.
> >
> > H.263 has been the predominant codec in the video conferencing industry
> > for close to a decade (ca. 1996 through ca. 2005).  In all this time, I
> have heard
> > of one single instance of patent assertion by a non-troll against
> several of the
> > large video conferencing vendors.  However, since those vendors all used
> a
> > chip produced by the non-troll, they had enough commercial leverage to
> > fend off those assertions without the dispute ever going to trial and,
> so I
> > hear, without paying any premium for the use of
> > the patent.   The patent in question has now expired.
> >
> > H.263 baseline is insufficient for rtcweb¹s purposes, as it does not
> allow
> > arbitrary picture sizes.  You want to have at least the PLUSPTYPE picture
> > header extension which allows arbitrary picture sizes.  You also probably
> > want a few of the optional modes, especially the bug-fixes (improved VLC)
> > and the deblocking filter.  Patents related to this technologies are not
> > covered under the MPEG-LA MPEG-4 part 2 license.
> >
> > Suspect:
> >
> > Since we would most likely not use strict H.263 baseline, the war-chest
> of the
> > MPEG-LA pool cannot be used to enforce a patent against our hypothetical
> > H.263 implementation because it is not MPEG-4 part 2 compliant.  Which,
> in
> > turn, means that the MPEG-4 part 2 rightholders would be on their own in
> > asserting their patents.  Which, in turn, means that there is no
> difference
> > between H.263 and other non-pooled video codecs from an MPEG-LA
> > related risk assessment.
> >
> >
> > There have been patent assertions by trolls allegedly related to video
> > compression in general and H.263 in particular, but those happen all the
> time
> > and there is not much one can do about them.  Once you are a juicy enough
> > target (based on the troll¹s perception of relationship between your
> legal
> > competence versus your size) the troll will find you.
> > Technicalities such as whether the patent is actually infringed or
> related to
> > standards are secondary at best in the eye of a troll.  Their business,
> at least
> > when going against smaller companies, is to settle for a few hundreds of
> > thousands--an amount the alleged infringer can pay without excessive
> hurt--
> > thereby filling their war chest and then go to the next ³customer².  When
> > they meet determined opposition (based on a combination of legal and
> > technical competence), they often move on to greener pastures.
> >
> > As H.263 is fairly widely deployed, and I have not heard about patent
> > assertions except the cases mentioned above, the risk of a successful
> patent
> > assertion is probably manageable for almost everyone with sufficient
> legal
> > resources.  At least in countries that allow equitable defenses (implied
> > license, laches, estoppel).
> >
> > So is it worth evaluating H.263 further?  IMO, probably not.  It¹s
> doubtless
> > technically better than H.261, but the risk is inproportionally higher.
>  And the
> > whole idea of this substandard baseline codec has been to be essentially
> > without risk.
> >
> > Stephan
> >
> >
> > >
> >
> > _______________________________________________
> > rtcweb mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>