Re: [whatwg] Codecs for and

[jjcogliati-whatwg]

--- On Mon, 6/29/09, Ian Hickson  wrote:

>  2. The remaining H.264 baseline patents owned by companies
> who are not 
>     willing to license them royalty-free expire,
> leading to H.264 support 
>     being available without license fees. =>
> H.264 becomes the de facto 
>     codec for the Web.

This could be awhile.  I took the US patents listed on at:
http://www.mpegla.com/avc/avc-patentlist.cfm
in
http://www.mpegla.com/avc/avc-att1.pdf
and checked their expiration dates.
The last ones expires in 2028.  There maybe other patents that are not listed, 
and some that are listed may not actually be essential to the real date for 
H.264 being royalty free could be different.   

Here is the complete list:

Patent:  7,292,636 
Filed:  02 mar 2004  Granted:  06 nov 2007  Expiration:  02 mar 2024  Summary:  
Using order value for processing a video picture  Notes:   
http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,292,636 

Patent:  RE35,093 
Filed:  03 dec 1990  Granted:  09 mar 1993  Expiration:  03 dec 2010  Summary:  
Systems and methods for coding even fields of interlaced video sequences  
Notes:  Reissue of 05193004 filed 09 dec 1994 granted 21 nov 1995 
http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=RE35,093 

Patent:  7,388,916 
Filed:  07 jul 2001  Granted:  17 jun 2008  Expiration:  07 jul 2021  Summary:  
Water ring scanning apparatus and method, and apparatus and method for 
encoding/decoding video sequences using the same  Notes:   
http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,388,916 

Patent:  4,796,087 
Filed:  01 jun 1987  Granted:  03 jan 1989  Expiration:  01 jun 2007  Summary:  
Process for coding by transformation for the transmission of picture signals  
Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=4,796,087 

Patent:  6,894,628 
Filed:  17 jul 2003  Granted:  17 may 2005  Expiration:  17 jul 2023  Summary:  
Apparatus and methods for entropy-encoding or entropy-decoding using an 
initialization of context variables  Notes:   
http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6,894,628 

Patent:  6,900,748 
Filed:  17 jul 2003  Granted:  31 may 2005  Expiration:  17 jul 2023  Summary:  
Method and apparatus for binarization and arithmetic coding of a data value  
Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6,900,748 

Patent:  7,088,271 
Filed:  03 may 2005  Granted:  08 aug 2006  Expiration:  03 may 2025  Summary:  
Method and apparatus for binarization and arithmetic coding of a data value  
Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,088,271 

Patent:  6,943,710 
Filed:  04 dec 2003  Granted:  13 sep 2005  Expiration:  04 dec 2023  Summary:  
Method and arrangement for arithmetic encoding and decoding binary states and a 
corresponding computer program and a corresponding computer-readable storage 
medium  Notes:   
http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6,943,710 

Patent:  7,286,710 
Filed:  01 oct 2003  Granted:  23 oct 2007  Expiration:  01 oct 2023  Summary:  
Coding of a syntax element contained in a pre-coded video signal  Notes:   
http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,286,710 

Patent:  7,379,608 
Filed:  04 dec 2003  Granted:  27 may 2008  Expiration:  04 dec 2023  Summary:  
Arithmetic coding for transforming video and picture data units  Notes:   
http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,379,608 

Patent:  7,496,143 
Filed:  27 dec 2004  Granted:  24 feb 2009  Expiration:  27 dec 2024  Summary:  
Method and arrangement for coding transform coefficients in picture and/or 
video coders and decoders and a corresponding computer program and a 
corresponding computer-readable storage medium  Notes:   
http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,496,143 

Patent:  5,235,618 
Filed:  06 nov 1990  Granted:  10 aug 1993  Expiration:  06 nov 2010  Summary:  
Video signal coding apparatus, coding method used in the video signal coding 
apparatus and video signal coding transmission system having the video signal 
coding apparatus  Notes:   
http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=5,235,618 

Patent:  4,849,812 
Filed:  24 feb 1988  Granted:  18 jul 1989  Expiration:  24 feb 2008  Summary:  
Television system in which digitized picture signals subjected to a transform 
coding are transmitted from an encoding station to a decoding station  Notes:   
http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=4,849,812 

Patent:  5,021,879 
Filed:  24 sep 1990  Granted:  04 jun 1991  Expiration:  24 sep 2010  Summary:  
System for transmitting video pictures  Notes:   
http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=5,021,879 

Patent:  5,128,758 
Filed:  02 jun 1989  Granted:  07 jul 1992  Expiration:  02 jun 2009  Summary:  
Method and apparatus for digitally processing a high definition television 
augmentation signal  Notes:   
http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=5,128,75

Re: [whatwg] Codecs for and

[jjcogliati-whatwg]

--- On Wed, 7/1/09, Gregory Maxwell  wrote:

> 
> It was suggested here that MJPEG be added as a
> baseline.  I considered
> this as an option for Wikipedia video support some years
> ago before we
> had the Theora in Java playback working. I quickly
> determined that it
> was unworkable for over-the-web use because of the bitrate:
> we're
> talking about on the order of >10x the required bitrate
> over Theora
> before considering the audio (which would also be >10x
> the bitrate of
> Vorbis).

Mozilla already supports Motion JPEG for the image tag (but not for video tag 
so far as I know).  Basically, right now if you want a video file that
will play on Quicktime, Media Player and Gstreamer's good set of plugins, the 
best option is Motion JPEG.  I have mailed CDs with MJPEG video and PCM audio, 
and you can fit ~15 minutes of this in ~TV quality.  

For ~TV quality video and audio (240 x 320 pixels  30 fps) we are talking 
something like (If you have better numbers, point them out to me):
5 MBit/s MJPEG video with PCM audio
1-2 MBit/s MPEG-1 
0.5 MBit/s Ogg Vorbis 

My suggestion (and I am not particularly serious) was:
[(H.264 OR Theora) AND Motion JPEG] 
If you care about bandwidth more than licensing fees, you provide both H.264 
and Theora.  If you care more about licensing costs, you can provide Theora and 
Motion JPEG.  I don't think that enshrining this in the spec is a very good 
idea however since it is a somewhat poor compromise.  

I can envision a future where a year from now Apple still has not added Theora 
support, but Mozilla has added gstreamer support, and suddenly Motion JPEG is 
the 'best' baseline codec, and the defacto video support is
[(H.264 OR Theora) AND Motion JPEG] 

> As far as I'm concerned spec might as well recommend a
> lossless codec
> as MJPEG— at least lossless has advantages for the set of
> applications
> which are completely insensitive to bitrate.

What lossless codecs might be available without patent problems?

Re: [whatwg] Codecs for and

[jjcogliati-whatwg]

--- On Tue, 6/30/09, Mikko Rantalainen  wrote:

> (2) Specify {Theora or H.264} as the baseline. That way all
> vendors that
> have displayed any interest for  could
> implement the spec.
> Authors would be required to provide the video in both
> formats to be
> sure that any spec compliant user agent is able to display
> the content,
> but at least there would be some real target set by the
> spec. However, I
> think that this just moves the H.264 patent licensing issue
> from browser
> vendors to content authors: if you believe that you cannot
> decode H.264
> without proper patent license there's no way you could
> encode H.264
> content without the very same license. As a result, many
> authors will
> not be able to provide H.264 variant -- and as a result the
> Theora would
> become de facto standard in the future.
> 
> -- 
> Mikko
> 
Specify {Theora or H.264} AND {Motion JPEG}  That way there is a fallback 
mechanism when you care more about compatibility than bandwidth and don't want 
to deal with the hassle of the H.264 patents.  Sometimes compatibility is more 
important than bandwidth. (HTML is a common method of putting content on 
CD-ROMs.)

Josh Cogliati

Re: [whatwg] HTML 5 video tag questions

[jjcogliati-whatwg]

Okay.  Thanks. 

Maybe to make this more clear section 4.8.7.1 should add a sentence somewhere 
like:

Authors may provide multiple source elements to provide different codecs for 
different user agents.  

Thank you.  

--- On Mon, 6/15/09, Tab Atkins Jr.  wrote:

> From: Tab Atkins Jr. 
> Subject: Re: [whatwg] HTML 5 video tag questions
> To: "Chris Double" 
> Cc: whatwg@lists.whatwg.org, jjcogliati-wha...@yahoo.com
> Date: Monday, June 15, 2009, 6:55 AM
> On Mon, Jun 15, 2009 at 4:49 AM,
> Chris Double
> wrote:
> > On Mon, Jun 15, 2009 at 5:27 PM, Tab Atkins Jr.
> wrote:
> >>
> >> (That said, I don't think there's anything wrong
> with nesting
> >> s, it's just unnecessary.)
> >
> > This won't work since fallback content is not
> displayed unless 
> > is not supported.
> 
> Dang, I was wrong.  I know I remembered some
> conversations about
> nested , but I guess I was just remembering
> people *asking*
> about it.
> 
> Regardless, as noted by others, my 
> suggestion was correct.
> Provide multiple s if you're not sure about
> what format your
> users can view.
> 
> ~TJ
>

[whatwg] HTML 5 video tag questions

[jjcogliati-whatwg]

I read section 4.8.7 The video element and I have some questions:
1.  What happens if the user agent supports the video tag but does not support 
the particular video codec that the video file has?  Should it display the 
fallback content in that case, and if so, can a video tag be put inside another 
video tag?
2.  What is the recommended way for website authors to determine what video and 
audio codecs and containers are supported by a user agent? 

Joshua Cogliati
http://jjc.freeshell.org/

Re: [whatwg] Codec mess with and tags

[jjcogliati-whatwg]

--- On Sun, 6/7/09, David Gerard  wrote:

> From: David Gerard 
> Subject: Re: [whatwg] Codec mess with  and  tags
> To: whatwg@lists.whatwg.org
> Date: Sunday, June 7, 2009, 9:30 AM
> 2009/6/7  :
> 
> > There are concerns or issues with all of these:
> > a) a number of large companies are concerned about the
> possible
> > unintended entanglements of the open-source codecs; a
> 'deep pockets'
> > company deploying them may be subject to risk here.
>  Google and other companies have announced plans to ship
> > Ogg Vorbis and Theora or are shipping Ogg Vorbis and Theora,
> so this may not be considered a problem in the future.
> 
> 
> Indeed. There are no *credible* claims of submarine patent
> problems
> with the Ogg codecs that would not apply precisely as much
> to *any
> other codec whatsoever*.

I fully agree that any codec can have the possibility that there may
be unknown patents that read on them.  

> In fact, there are less, because the Ogg codecs have in
> fact been
> thoroughly researched.

I have looked for evidence of that there has been any patent research on 
the Ogg codecs.  I assume that Google, Redhat and others have at least 
done some research, but I have yet to find any public research
information.  I probably am just missing the pointers to this, so could
you please tell me where I can find results of this research? 

Thank you.

> This claimed objection to Ogg is purest odious FUD, and
> should be
> described as such at every mention of it. It is not
> credible, it is a
> blatant and knowing lie.

Re: [whatwg] Codec mess with and tags

[jjcogliati-whatwg]

Here is my update of Dave Singer's 2007 summary of the previous discussion.
Old summary:
http://www.w3.org/html/wg/tracker/issues/7
Wikia Page where this summary is (feel free to make changes there):
http://scratchpad.wikia.com/wiki/HTML5_summary_of_video_and_audio_codec_discussion

Summary:
==Preamble==

The HTML5 specification contains new elements to allow the embedding 
of audio and video, similar to the way that images have historically 
been embedded in HTML.  In contrast to today's behavior, using 
object, where the behavior can vary based on both the type of the 
object and the browser, this allows for consistent attributes, DOM 
behavior, accessibility management, and so on.  It also can handle 
the time-based nature of audio and video in a consistent way.

However, interoperability at the markup level does not ensure 
interoperability for the user, unless there are commonly supported 
formats for the video and audio encodings, and the file format 
wrapper.  For images there is no mandated format, but the widely 
deployed solutions (PNG, JPEG/JFIF, GIF) mean that interoperability 
is, in fact, achieved.

==Licensing==

The problem is complicated by the IPR situation around audio and 
video coding, combined with the W3C patent policy 
. "W3C seeks to 
issue Recommendations that can be implemented on a Royalty-Free (RF) 
basis."  Note that much of the rest of the policy may not apply (as 
it concerns the specifications developed at the W3C, not those that 
are normatively referenced).  However, it's clear that at least 
RF-decode is needed.

==Candidates==

There are, of course, a number of codecs and formats that can be 
considered.  A non-exhaustive list might include a variety of 
'public' codecs, as well, of course, as proprietary ones:

a) open-source projects:  the ogg family (vorbis, theora), and the 
BBC Dirac video codec project

b) Current ISO/IEC (MPEG) standard codecs, notably the MPEG-4 family: 
AVC (14496-10, jointly published with the ITU as H.264), AAC (part of 
14496-3)

c) Older MPEG codecs, notably MPEG-2 layer 3 (aka MP3), MPEG-2 layer 
1 and 2 audio, and maybe MPEG-4 part 2 video (14496-2)

d) Current standard codecs from other bodies;  SMPTE VC-1, for example

e) Older standards from other bodies:  ITU recommendations H.263 
(with or without its many enhancement annexes) or even H.261

f) Very old standard codecs, formats, or industry practices;  notably 
the common format for video from digital still cameras (Motion JPEG 
with uncompressed audio in an AVI wrapper)

g) Proprietary codecs, such as Dolby AC-3 audio

==Candidate concerns==

There are concerns or issues with all of these:

a) a number of large companies are concerned about the possible 
unintended entanglements of the open-source codecs; a 'deep pockets' 
company deploying them may be subject to risk here.  Google and other companies 
have announced plans to ship Ogg Vorbis and Theora or are shipping Ogg Vorbis 
and Theora, so this may not be considered a problem in the future.   

b) the current MPEG codecs are currently licensed on a royalty-bearing basis.

c) this is also true of the older MPEG codecs;  though their age 
suggests examining the lifetime of the patents;   MPEG-1 without 
MPEG-1 Audio Layer 3 might be royalty free right now.  Three problems were 
mentioned with using a subset of MPEG-1.  First, by using a subset some people 
might use the full MPEG-1 and not realize that this would not work on browsers 
only implementing a subset. Second, even clearing MPEG-1 subset as royalty free 
might be expensive, and third MPEG-1 has a lower quality than other codecs. 
MPEG-1 352 pixels x 240 lines at 30 frames a second with audio is about 1.9 
Mbit/sec.

d) and also SMPTE VC-1

e) H.263 and H.261 both have patent declarations at the ITU. 
However, it is probably worth examining the non-assert status of 
these, which parts of the specifications they apply to (e.g. H.263 
baseline or its enhancement annexes), and the age of the patents and 
their potential expiry.  H.261's patent declarations either are expired, 
only applications, or seem to be a mistake.  H.261 however only allows two 
video sizes, so it is unsuitable.  Sun's OMS project is trying to make a video 
codec based on H.261, which might be worth considering when it is finished.  

f) This probably doesn't have significant IPR risk, as its wide 
deployment in systems should have exposed any risk by now;  but it 
hardly represents competitive compression.  Motion JPEG 320 x 240 pixels at 30 
frames a second with 8 bit PCM audio is about 5 Mbit/sec.  

g) Most proprietary codecs are licensed for payment, as that is the 
business of the companies who develop them.

==Other licensing concerns==

It's also possible that there are other issues around licensing:

a) variations in licensing depending on filed patents in various geographies

b) restrictions on usage, or fees on usage, other than the fee

Re: [whatwg] MPEG-1 subset proposal for HTML5 video codec

[jjcogliati-whatwg]

Thank you for a very informative reply.  Inline comments follow.

--- On Sun, 5/31/09, Gregory Maxwell  wrote:

> From: Gregory Maxwell 
> Subject: Re: [whatwg] MPEG-1 subset proposal for HTML5 video codec
> To: whatwg@lists.whatwg.org
> Date: Sunday, May 31, 2009, 2:17 PM
> 2009/5/31   at yahoo.com>:
> > Since the near complete MPEG-1 committee draft was
> publicly available in December 1991,
> [snip]
> 
> You keep repeating this particular piece of misinformation,
> so I'm
> worried that people are going to take your word for it and
> get into
> trouble.
> 
> What you are claiming with respect to the inventors
> disclosure and
> patent duration is correct for patents filed and granted
> today but it
> not true for patents from the mid-1990s.
> 
> Prior to mid-1995 was possible to use application
> extensions to defer
> the grant date of a patent indefinitely.  You could
> begin an
> application in 1988, publicly expose your invention in
> 1991, all the
> while filing extensions only to have the patent granted in
> 1995.
> 
> I am somewhat surprised that you are unaware of this
> issue,
> considering that you mentioned it specifically by name
> (submarine
> patent).

Yes, I agree and I was not making this clear in my reply posts.  The first 
email I sent I did detail this.  

> I'm more familiar with the area of audio coding than video,
> so I don't
> have a ready list of patents that read on mpeg1 video.
> However, There
> are mid-90s patents which read on both layer-2 (e.g.
> 5,214,678) and
> layer-3 audio which followed the 'submarine patent' style
> of prolonged
> application and late disclosure times.

That is interesting that 5,214,678 is considered to read on Layer-2 since
AudioMPEG says that they are not doing licensing for Video-CD, which uses
MPEG-1 Layer 2 audio.  It was granted in May 25, 1993 and filed on May 31, 
1990, so it barely made it in three years (and will not expire till 
May 31, 2010).  

http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=5,214,678
http://www.audiompeg.com/

> Additionally, Theora avoids some techniques used in MPEG1
> which have
> been believed to be patented.  For example, the
> differential coding of
> motion vectors. While I don't have the knowledge needed to
> provide a
> detailed analysis, even I know enough to point out at least
> a few
> engineering reasons why Theora has less patent exposure
> surface than
> MPEG1.

I can certainly believe that MPEG-1 Video might be non-royalty free and 
Theora might be.  I haven't really looked at the exact coding of Theora motion 
vectors.  That is an interesting thing to look at. 

> Without the benefit of mpeg layer-3 audio MPEG1 is left
> enormously
> handicapped compared to Theora+Vorbis. 16kHz 16bit stereo
> PCM is
> 512kbit/sec on it own, which is comparable to the total
> bitrate 'high
> quality' option delivered by sites like Youtube. And 16kHz
> audio is
> pretty poor for anything that needs to carry music. 

Layer-2 audio can certainly beat PCM for compression, since it can reduce
the bit rate for coding the quieter frequency bands.  Typical stereo bit 
rates for stereo Layer 2 audio are probably more on the order of 256 
kbit/s.  Vorbis and MPEG-1 Audio Layer 3 certainly can beat this rate.

> While you could
> argue for using MPEG1+Vorbis, none of the few parties who
> indicated
> that they would not ship Theora have stated they would (or
> are
> already) shipping Vorbis. (For example, Nokia does not ship
> Vorbis on
> their Linux tables)  Everyone shipping Vorbis already
> seems to have no
> issue with Theora.

I am not going to argue for MPEG-1 video plus Vorbis audio.  

> Even if you pay fairly low prices for transit the cost of
> sending PCM
> audio vs Vorbis is likely enough to pay for the H.264+AAC
> licensing no
> matter what it turns out to be in 2010.  A 'free'
> format which has an
> effective price much higher than the 'non-free' stuff would
> be
> something of a hollow victory.

Interesting point.  I think that transit costs will decrease 
faster than H.264+AAC licensing costs, (unless Theora and Vorbis 
start causing serious competion.)

> And really, now that we see multiple large companies with
> experienced
> legal teams and non-trivial exposure committed to shipping
> Theora I
> think we're kidding ourselves when we attempt to analyze
> this as a
> legal issue. It's not. It's a business/political decision.
> The market
> is now going to battle it out.  Enjoy the show.

I agree.  I was not aware that Google planned on shipping Theora support when I 
made the first email last week (Wikipedia article since updated). 
If Ogg Theora and Vorbis become the defacto standard, that is 
fine with me.  

Right now, the best video codec/audio codec that works with Gstreamer good 
plugins (i.e. Linux), Quicktime and Media Player is Motion JPEG with PCM 
audio, which I have used for shipping videos on CDs and USB drives, but is 
impractical for online transfers.  I am hoping for a better outcome 

Re: [whatwg] MPEG-1 subset proposal for HTML5 video codec

[jjcogliati-whatwg]

--- On Sat, 5/30/09, Silvia Pfeiffer  wrote:

> From: Silvia Pfeiffer 
> Subject: Re: [whatwg] MPEG-1 subset proposal for HTML5 video codec
> To: jjcogliati-wha...@yahoo.com
> Cc: whatwg@lists.whatwg.org
> Date: Saturday, May 30, 2009, 6:45 AM
> On Fri, May 29, 2009 at 10:03
> PM,  
> wrote:
> >
> > I propose that a MPEG-1 subset should be considered as
> the required
> > codec for the HTML-5 video tag.
> >
> > == MPEG-1 Background ==
> 
> <...>
> 
> > == Brief comparison to other video codecs ==
> >
> 
> <...>
> 
> > Ogg Theora and Ogg Vorbis are newer standards than
> MPEG-1.  My guess
> > is that they can do substantially better at
> compression than MPEG-1.
> > Assuming there are no submarine patents, I think the
> OGG codecs would
> > be a better choice than MPEG-1.
> 
> That's good to know.
> 
> <...>
> 
> > == Remaining Work ==
> >
> > I am not a lawyer.  In order to use MPEG-1 PRF,
> patent lawyers will
> > have to investigate the patent issue and publicly
> report on the
> > patent status.  Unless there is a report sitting
> around that can be
> > published, this will likely be expensive.
> 
> The reason that current browser vendors put forward for not
> supporting
> Ogg Theora/Vorbis is that there is no thorough report
> available on
> their patent status which also convincingly shows that the
> risk of
> submarine patents is minimal.
> 
> If you would also prefer Ogg Theora/Vorbis over MPEG-1 PRF,
> then I
> don't understand why such a report should not rather be
> created about
> these codecs than on MPEG-1 PRF.
> 
> > As well, the prior art review is not complete.  The
> biggest missing
> > piece is synthesis window for the audio layer.
> 
> Same argument here for Ogg Theora/Vorbis.
> 
> <...>
> 
> > == Satisfaction of requirements ==
> >
> > >From 4.8.7.1 HTML 5 draft:
> > 1. does not require per-unit or per-distributor
> licensing
> > Probably.  There does not seem to be anyone
> requesting this kind of
> > licensing right now.
> >
> > 2. Must be compatible with the open source development
> model.
> > Probably.  There does not seem to be any identified
> patents for MPEG-1 PRF.
> >
> > 3. Is of sufficient quality as to be usable
> > Yes.  Much better than the next best option of Motion
> JPEG.  Probably
> > worse than Ogg Theora or H.264.
> 
> These three are better satisfied by Ogg Theora/Vorbis.
> 
> > 4. Is not an additional submarine patent risk for
> large companies.
> > Probably.  It has been widely implemented (in DVD
> players, in Apple
> > Quicktime and Microsoft Media Player) Note that these
> example uses
> > have either a license for MPEG-2 or MPEG-4 however.
> 
> Wide implementation does not save you from submarine
> patents. Nothing
> really does. Wide implementation only spreads the risk
> across more
> bodies. An existing lawsuit that has been resolved reduces
> the risk.
> But there will always be the risk of another unknown patent
> that could
> be interpreted to be infringed.
> 
> > == Conclusion ==
> >
> > The MPEG-1 PRF subset defined here seems to fit all
> the requirements
> > of a codec for video for HTML5.  It seems to be
> patent free.  A final
> > conclusion will depend on whether or not patent
> lawyers can sign off
> > on this proposal and if the quality of MPEG-1 PRF is
> deemed
> > sufficient.
> 
> Honestly, I'd rather suggest spending the money on Ogg
> Theora if you
> are really suggesting spending money on lawyers and patent
> research.
> Ogg Theora/Vorbis is miles ahead of MPEG-1 in Quality and
> in
> increasingly wider spread use on the Web.


If the cost for patent clearing MPEG-1 PRF and Ogg Theora and Vorbis were the 
same, then I would completely agree with you.  I think that the cost for patent 
clearing MPEG-1 PRF would be cheaper for the following reasons:

1.  Age of Standard.  MPEG-1 final standard (parts 1,2,3) came out in August 
1993.  Ogg Theora standard came out in about 2004.  Basically, for all but the 
oldest unexpired patents, the MPEG-1 standard can be considered prior art, but 
for Theora, there is another decade of time where outside prior art needs to be 
found. 

2.  Simplicity.  MPEG-1 PRF is quite a bit simpler than Ogg Theora and Vorbis.  
Ogg Theora contains much of what is in MPEG-1 Video (such as Motion vectors) 
and much that is newer than MPEG-1.  

3.  Existing use.  MPEG-1 has been in use by major media players such as Apple 
Quicktime and Microsoft Media Player, so there probably are internal patent 
reviews that have been done.  (These are probably considered very proprietary, 
so this reason is very weak.)


So I think that a MPEG-1 PRF patent review would be cheaper than a Ogg Vorbis 
and Theora review.  

The questions I don't have a good answer to are how much better Ogg Theora and 
Vorbis are than MPEG-1 PRF, and how much more expensive patent reviewing Ogg 
Theora and Vorbis is compared to MPEG-1 PRF.  

I would like to see a comparison that shows Ogg Theora/Vorbis is miles ahead of 
MPEG-1 in Quality.  I would 

Re: [whatwg] MPEG-1 subset proposal for HTML5 video codec

[jjcogliati-whatwg]

That is a potential problem, but for MPEG-1 it is less of a problem than with 
newer codecs.  Since the near complete MPEG-1 committee draft was publicly 
available in December 1991, remaining patents for decoding of the full MPEG-1 
spec should be expiring in the 2012 timeframe or before. 

The next question is why not just wait until the complete MPEG-1 can be 
decoded? If there is still no decision on a suitable codec for HTML5 when 
MPEG-1 becomes royalty free and MPEG-1 decoding starts showing up in things 
like gstreamer's good set of plugins then the full MPEG-1 might be worth 
considering then.  

--- On Sat, 5/30/09, Den.Molib  wrote:

> From: Den.Molib 
> Subject: Re: [whatwg] MPEG-1 subset proposal for HTML5 video codec
> To: jjcogliati-wha...@yahoo.com, whatwg@lists.whatwg.org
> Date: Saturday, May 30, 2009, 5:20 AM
> I'm afraid that if using a subset of
> a bigger, patented, standard. 
> Some browsers will include the full codec. Web authors see
> their videos 
> reproduce correctly, and put them in the web thinking
> they're 'standard',
> while the user agents including only the license-free
> version won't be 
> able to view them.
> Thus de facto requiring the full support for the web, in
> what could be 
> considered a variant of 'embrace and extend' issues, even
> if not 
> intentional.
> 
> 
> 
> 

[whatwg] MPEG-1 subset proposal for HTML5 video codec

[jjcogliati-whatwg]

I propose that a MPEG-1 subset should be considered as the required
codec for the HTML-5 video tag.

== MPEG-1 Background ==

MPEG-1 was published as the ISO standard ISO 11172 in August 1993.  It
is a widely used standard for audio and video compression.  Both
Windows Media and Apple Quicktime support playing MPEG-1 videos using
Audio Layer 2.  MPEG-1 provides three different audio layers.  The
simplest is Audio Layer 1 and the most complicated is Audio Layer 3,
usually known as MP3. Since MPEG-1 includes MP3, a full implementation
of a MPEG-1 decoder would not be royalty free until either all the
essential MP3 patents expire, or a royalty free license is granted for
all the essential MP3 patents.

== MPEG-1 PRF ==

I propose the following subset of MPEG-1 as the MPEG-1 Potentially
royalty free subset (MPEG-1 PRF):

MPEG-1 Video without:
forward and backward prediction frames (B-frames)
dc-pictures (D-frames)

MPEG-1 Audio Layers 1 and 2 only (no Layer 3 audio)

This subset eliminates the currently patented MP3 portion of the
MPEG-1 Audio.  It also eliminates the non-needed B-frames and D-frames
because there is less prior art for them and this has the side effect
of simplifying MPEG-1 PRF decoding. 

== Patents ==

To the best of my knowledge, there are no essential patents on this
MPEG-1 PRF subset.  I have discussed this on a kuro5hin article, a
post on the gstreamer mailing list and the MPEG-1 discussion page at
Wikipedia, and no-one has been able to definitively list any patents on
this subset.

http://www.kuro5hin.org/story/2008/7/18/232618/312
http://sourceforge.net/mailarchive/message.php?msg_id=257198.16969.qm%40web62405.mail.re1.yahoo.com
http://en.wikipedia.org/wiki/Talk:MPEG-1#Can_MPEG-1_be_used_without_Licensing_Fees.3F

That said, "absence of evidence is not evidence of absence".  There
still may certainly be patents on MPEG-1 PRF.  Next I will discuss
some prior art that exists for this subset.

== Prior Art for MPEG-1 PRF == 

The H.261 (12/90) specification contains most of the elements that
appear in MPEG-1 video with the exception of the B-Frames and
D-frames.  H.261 however only allows 352 x 288 and 176 x 144 sized
video.  H.261 is generally considered to be royalty free (such as by
the OMS video project).  There are no unexpired US patents listed for it on
the ITU patent database.

http://www.itu.int/rec/T-REC-H.261
http://www.itu.int/ipr/IPRSearch.aspx?iprtype=PS
http://blogs.sun.com/openmediacommons/entry/oms_video_a_project_of

As for MPEG-1 Audio Layer 2, it is very close to MASCAM, which was
described in "Low bit-rate coding of high-quality audio signals. An
introduction to the MASCAM system" by G. Thiele, G. Stoll and M. Link,
published in EBU Technical Review, no. 230, pp. 158-181, August 1988

The Pseudo-QMF filter bank used by Layer 2 is similar to that
described in H. J. Nussbaumer. "Pseudo-QMF Filter Bank", IBM technical
disclosure bulletin., Vol 24. pp 3081-3087, November 1981.

The MPEG-1 committee draft was publicly available as ISO CD 11172 by
December 6, 1991.  There is only a few year window for patents to have
been filed before this counts as prior art, and not have expired.

This list of prior art is by no means complete, in that there
certainly could be patents that are essential for a MPEG-1 PRF
implementation, but can not be invalided by this list of prior art.

In the US, patents filed before 1995 last the longer of 20 years after
they are filed or 17 years after they are granted.  They also have to
be filed within a year of the first publication of the method. This
means that for US patents, most (that is all that took less than three
years to be granted) patents that could apply to MPEG-1 will be
expired by December 2012 (21 years after the committee draft was
published.). 


== Brief comparison to other video codecs ==

Motion JPEG with PCM audio is the only codec that I know of that can
be played in a stock Windows, Linux and Mac OS X setup.  On the other
hand, since it is basically a series of JPEG images and a 'WAV' file,
the compression is much poorer than MPEG-1 PRF.

Ogg Theora and Ogg Vorbis are newer standards than MPEG-1.  My guess
is that they can do substantially better at compression than MPEG-1.
Assuming there are no submarine patents, I think the OGG codecs would
be a better choice than MPEG-1.  If you think that MPEG-1 PRF is not
royalty free, but Ogg Theora and Ogg Vorbis are, you may find that
comparing Theora to H.261 or Theora and Vorbis to MPEG-1 PRF is an
enlightening exercise.  Much of what is in MPEG-1 PRF is also in Ogg
Theora and Ogg Vorbis.

MPEG-2 is the next MPEG standard.  It mainly adds error correction and
interlacing.  Neither of these features is particularly important for
streaming video to computer monitors using a reliable data transport.
MPEG-2 definitely is patented, and will be until at least the 2018
time-frame. I don't think that this buys much over MPEG-1 PRF, and it
definitely adds more patent issues.

MPEG-4, H.264