Re: [rtcweb] Proposal for H.263 baseline codec

[Stephan Wenger <[e-mail]>]

Hi,

A few random data points about H.263.

I write this as someone who sat through the meetings which defined H.263+ and H.263++ and with a vague recollection who proposed what.  I'm leaning myself fairly far out of the window here, so let me emphasize that this is not a formal risk analysis, no legal advice, and that it is instead today's snapshot of what I would think is a sensible position for a risk-averse implementer, which may be very different tomorrow.  As usual, you and your legal folks will have to perform your own risk analysis.  For those unfamiliar with the ITU tool set, the ITU patent database can be found here http://www.itu.int/ipr/IPRSearch.aspx?iprtype=PS and can be searched for Recommendation H.263.  The content of this database probably needs to be interpreted in the context of the then valid policies, disclosure and declaration requirements, and practices in the ITU, which were IMO and at the time, considerably less strict than the disclosure requirements observed in the IETF today.

H.263 is not "profiled" in the sense the MPEG video codecs are.  There is an Annex X defining profiles and levels, but this Annex was added several years after the first revision of H.263, almost as an afterthought.  The profiles defined therein are not necessarily the mode combinations that are (or have been) in practical use.

Compared to modern video codecs, H.263 is trivial to implement.  I would suggest that the availability or non-availability of certain modes and options in today's software base (be it open source or proprietary) should not the key driver in profiling H.263.  Compared to the implementation effort of the rest of the rtcweb stack, an H.263 implementation is cheap to have.

The reference implementation for H.263+ was maintained by the University of British Columbia and later by UB Video, and access to it for the public was removed around 1999.  UB Video also sold a close-to-real-time (on the machines of the time) H.263+ encoder and decoder library.  On today's machines, I would expect this software, after some optimization reflecting "modern" instructions sets, to handle 720p encoding and decoding on most machines.  UB Video was acquired by Scientific Atlanta, which in turn was acquired by Cisco.  AFAIK, today, Cisco owns the rights to all this software.  I could likely establish contacts to those people inside Cisco who may still have a copy of the software, if I were approached by Cisco folks not so fortunate.

Personally, I would not expect an IPR risk to go up significantly (compared to H.263 baseline 1996) when using the PLUSPTYPE header, which would (among other things) allow for flexible picture sizes.  The same is IMHO true for some of the optional modes of H.263+ that are "bug fixes" to the 1996 version of the spec, for example Annexes I (advanced intra), J (deblocking filter), K (slices), and S (VLC bug fix) , as well as 1996 Annex D (unrestricted motion).  Annex I helps for Intra pictures, J is good for subjective quality and not such a computational complexity bear as Annex F (overlapped block motion compensation), you want slices for MTU size matching if your picture size goes beyond CIF, and S is a bug fix.

The majority of the above coding tools do not require tricky encoder mode decision steps; the are simply alternate or additional syntax for baseline tools and functionalities.

Regards,
Stephan



From: Piers O'Hanlon <[e-mail]<mailto:[e-mail]>>
Date: Thu, 29 Mar 2012 14:48:35 +0200
To: <[e-mail]<mailto:[e-mail]>>
Cc: <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>
Subject: Re: [rtcweb] Proposal for H.263 baseline codec


On 29 Mar 2012, at 14:30, <[e-mail]<mailto:[e-mail]>> wrote:

Hi,

I support Dean’s proposal to make H.263 as the mandatory-to-implement codec. I’m not expert on profiles, but someone mentioned H.263 profile 0 as something suitable for our needs (smallest IPR risk).

I also believe that even making H.261 as the mandatory-to-implement would be better than going for the forced pseudo-random selection between H.264 or VP8.

One of the key limitations with H.261 is it's small range of available supported resolutions (QCIF, Max:CIF(352x288)) - so if there is a low IPR risk for an H.263(+?) configuration then it would be preferable.

The whole issue of which Profile and levels one might support for these codecs is another issue as I think they lead to differing IPR dependencies.

Piers.

Markus


From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of ext Dean Willis
Sent: 29 March, 2012 15:16
To: [e-mail]<mailto:[e-mail]>
Subject: [rtcweb] Proposal for H.263 baseline codec

In today's meeting I made a plea for a mandatory baseline codec that is approachable to the small developer without the cost and IPR risks of either H.264 or VP8.

I believe that some sort of baseline codec is required to jump start the protocol. It's OK if this isn't the best possible codec. Market forces will assure that commercial implementations converge on a higher quality when the market requires it.

While I proposed today that H.261 could serve as a baseline, we know this would be "extremely basic". In other words, it might not pass the "good enough to use" test required for a successful launch.

Stephane and several others suggested H.263 as an alternative during the after-meeting chat. While it is not as IPR-safe a choice as H.261, it is relatively mature and the known challenges have generally failed. Implementations are reasonably available and should make it possible for smaller implementers, students, and hobbyists to play ball. It's not all that network efficient and is outright piggy at higher resolutions, but it probably works "well enough to use."

So I propose we set H.263 as the baseline ( I expect a bit of profiling may be necessary to further qualify the baseline) and run with that for now. If the situation changes, we can always replace it before final publication.
--
Dean
_______________________________________________
rtcweb mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________ rtcweb mailing list [e-mail]<mailto:[e-mail]> https://www.ietf.org/mailman/listinfo/rtcweb