Re: [whatwg] MPEG-1 subset proposal for HTML5 video codec
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 den.mo...@gmail.com wrote: From: Den.Molib den.mo...@gmail.com 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.
Re: [whatwg] MPEG-1 subset proposal for HTML5 video codec
2009/5/31 jjcogliati-wha...@yahoo.com: 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. Despite the blatant FUD from Apple and Nokia on the topic, Ogg Theora looks like (a) going into the browsers (Firefox, Chrome) and the websites (Wikimedia, Dailymotion), leaving them to play catchup. At that point the standard could be updated to reflect actual practice. - d.
Re: [whatwg] MPEG-1 subset proposal for HTML5 video codec
--- On Sat, 5/30/09, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: From: Silvia Pfeiffer silviapfeiff...@gmail.com 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, jjcogliati-wha...@yahoo.com 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 also like to know what kind of patent review has already been done on Ogg Theora and Vorbis
Re: [whatwg] MPEG-1 subset proposal for HTML5 video codec
Thank you for a very informative reply. Inline comments follow. --- On Sun, 5/31/09, Gregory Maxwell gmaxw...@gmail.com wrote: From: Gregory Maxwell gmaxw...@gmail.com 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 jjcogliati-whatwg 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 with the video tag. Josh Cogliati
Re: [whatwg] MPEG-1 subset proposal for HTML5 video codec
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.
Re: [whatwg] MPEG-1 subset proposal for HTML5 video codec
On Sat, May 30, 2009 at 4:20 AM, Den.Molib den.mo...@gmail.com wrote: 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. This is why mozilla have chosen not to include h.264 support in Firefox 3.5 where we're adding support for the video element. I think it's unfortunate that google didn't make the same decision. / Jonas
[whatwg] MPEG-1 subset proposal for HTML5 video codec
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 have
Re: [whatwg] MPEG-1 subset proposal for HTML5 video codec
MPEG-1 is not exactly a popular codec on the web if you look at the breakdown of video files on the web. The most popular formats are H.264 and FLV. H.264 currently offers the best performance in terms of image quality and compression (and is already the de-facto choice in a large, and increasing, set of cameras / editing software / ...). I don't think we would be interested in supporting something like MPEG-1 which is, at this point in time, far behind the curve. We have chosen to support H.264 + AAC as well as Ogg (Theora + Vorbis) for video in Google Chrome, mainly because H.264 is what we see as the best performing option and Ogg is (currently) the most viable open alternative. Encouraging everyone to use MPEG-1 would just result in a lesser user experience and more bandwidth consumption, neither of which really interest us. 2009/5/29 jjcogliati-wha...@yahoo.com 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
Re: [whatwg] MPEG-1 subset proposal for HTML5 video codec
Ian Fette (イアンフェッティ) wrote: We have chosen to support H.264 + AAC as well as Ogg (Theora + Vorbis) for video in Google Chrome H.264 is heavily patented, and H.264 implementors typically acquire patent licenses from MPEG LA. However, as noted in [1], Chrome's use of ffmpeg for codec support subjects it to the LGPL, which requires that any such licenses be fully transferable and unrestricted. How does Google intend to meet its legal obligations in reference to H.264 (and AAC)? --Ben [1] http://annevankesteren.nl/2009/05/web-video signature.asc Description: OpenPGP digital signature
Re: [whatwg] MPEG-1 subset proposal for HTML5 video codec
preface: IANAL. This post is meant to briefly describe what we are doing, not to give any legal guidance or opinions. It is not meant to be authoritative, please look at the source code if you want to verify these things yourself. We are using H.264 in Google Chrome, not in Chromium. We do not have the ffmpeg / h.264 related code in chromium (only the header files for ffmpeg), ffmpeg and h.264 related stuff is a complete external dependency loaded at run time. Chromium is the open source project, Google Chrome is the product we build by taking that open source code [chromium] and adding a few things that we don't make available in chromium (e.g. our artwork, and in this case a binary for ffmpeg / h.264 related stuff that is loaded at run time). 2009/5/29 Benjamin M. Schwartz bmsch...@fas.harvard.edu Ian Fette (イアンフェッティ) wrote: We have chosen to support H.264 + AAC as well as Ogg (Theora + Vorbis) for video in Google Chrome H.264 is heavily patented, and H.264 implementors typically acquire patent licenses from MPEG LA. However, as noted in [1], Chrome's use of ffmpeg for codec support subjects it to the LGPL, which requires that any such licenses be fully transferable and unrestricted. How does Google intend to meet its legal obligations in reference to H.264 (and AAC)? --Ben [1] http://annevankesteren.nl/2009/05/web-video
Re: [whatwg] MPEG-1 subset proposal for HTML5 video codec
Ian Fette (イアンフェッティ) wrote: We are using H.264 in Google Chrome, not in Chromium. We do not have the ffmpeg / h.264 related code in chromium (only the header files for ffmpeg), ffmpeg and h.264 related stuff is a complete external dependency loaded at run time. Chromium is the open source project, Google Chrome is the product we build by taking that open source code [chromium] and adding a few things that we don't make available in chromium (e.g. our artwork, and in this case a binary for ffmpeg / h.264 related stuff that is loaded at run time). Thank you for this clear and detailed explanation. I have downloaded a recent Chrome release, and indeed, the package includes a binary of libavcodec (avcodec-52.dll), and the binary contains h.264 support. This binary is distributed under the LGPLv2.1, which is the license of ffmpeg and libavcodec. [1] I am not a lawyer, a legal expert, or a licensing expert. However, according to my understanding of Section 11 of LGPLv2.1, an entity such as Google is prohibited from distributing an LGPL-licensed work if they have made any patent agreements pertinent to the work, unless those patent agreements are also available to all humans for any purpose whatsoever. From the license: [2] For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. I have no specific knowledge of Google's licensing agreements regarding h.264. However, it seems very likely to me that Google has negotiated a license that allows it to distribute h.264 decoders, but that this license is non-transferable. If that is the case, then the LGPL prohibits Google from distributing ffmpeg/libavcodec at all. Note that this has nothing whatsoever to do with Chrome. Google would be prohibited from distributing ffmpeg even if the Chrome project had never been initiated, if it holds a typical h.264 patent license. I hope that you will consult internal legal counsel on this matter, and make sure that they are fully aware of the implications of the LGPL in this case. They will certainly be able to make better informed recommendations than I can. I also think this is a good example of the sort of legal complexity that inevitably results from proprietary codecs and software patents. --Ben Schwartz [1] http://www.ffmpeg.org/legal.html [2] http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html signature.asc Description: OpenPGP digital signature
