About HTML5 video support in modern browsers
What many expected was accomplished - the largest video services (YouTube, Vimeo) provided in beta testing mode the ability to play videos using HTML5. It would seem that everything is fine, and Flash-it's time to go on a well-deserved rest. But no - it turned out not so smooth.
And there is only one solution - codecs. Browser developers and content providers did not agree on which codec to use for video. In fact, this problem has been discussed before, and there is no consensus on it. As a result, references to a specific codec have been removed from the HTML5 draft specification.
The codec for HTML5 video is currently claimed by two codecs - Ogg Theora and H.264 .
Ogg Theora is based on VP3 codec developed by On2 Technologies. In 2002, On2 Technologies transferred the VP3 code under a free BSD-like license into the hands of the Xiph.org Foundation, and also refused patents for the codec (technically, they did not refuse, but simply transferred the right to use them to everyone, but this is essentially the same ). Since then, Xiph.org has continued the development of this codec.
')
You can use Ogg Theora anywhere, always, without license or patent deductions.
H.264 is a licensed video compression standard. Its use requires payment in countries where patents are valid for it (first of all, it is the United States). However, today, this is one of the best ways to compress video. H.264 is the de facto standard for HD video compression, for example. H.264 is noticeably more efficient than Ogg Theora in terms of quality / bitrate.
In short, H.264 is better, but even its open-source implementations cannot be used freely in countries with patents on it.
Here I mention only those browsers in which HTML5 video is already working now.
The implementation uses the liboggplay library, which means that only Ogg Theora for video and Ogg Vorbis for audio can be used. Those. the codec is fixed, and to do support for something else, you need to essentially rewrite the implementation.
The implementation uses statically bound ffmpeg . ffmpeg supports a bunch of different codecs, including Ogg Theora, and H.264, and in general, almost everything that is actually used now.
By the way, ffmpeg is currently used almost everywhere - for example, in CCCP and K-Lite Codec Pack , as well as in mplayer and VLC , ffmpeg is used.
It would seem that everything is great. But! ffmpeg, although open source, cannot be free in the United States. To distribute a program that uses ffmpeg, you need to pay deductions. Google can afford it, and has the right to release builds with built-in ffmpeg. But this is not the case with Linux distributions. Those of them that are released in the United States will not be able to include ffmpeg with Chrome support in their repositories, as this will require a deduction fee. First of all it concerns such well-known distribution kit as Fedora.
It uses the QuickTime framework, which allows you to play anything if the appropriate QuickTime codec is installed.
Probably from modern implementations this is the most correct, since has a modular architecture initially. But this is all heavily tied to Mac OS, so it is not applicable to other systems and browsers.
Now let's talk about content providers. Freedom, equality, fraternity - it's all good in theory, but in practice the issue is resolved by small greenish papers with portraits of American presidents. Google is somehow easier to pay for a license for a more efficient codec than to pay more for traffic and server space. Moreover, considering that they already have all the video stored in H.264, it would be especially stupid (from a business point of view, of course) to re-encode it all into Ogg Theora. So the decision to use H.264 is an absolute, economically justified, vital necessity. YouTube will not use Ogg Theora. Not profitable. Point.
And besides, the use of H.264 is more profitable for us, the end users. We do not pay royalties, but, nevertheless, we get better video quality with less data uploaded (hello to residents of non-capitals with frail channels on the Internet).
Now yes. But! There is a way out. To decode video in a browser, you need to use a modular approach, without being tied to a specific codec. Moreover, each operating system already has a modular codec infrastructure. On Windows, this is DirectShow, on Mac OS X, this is QuickTime, on Linux, this is gstreamer . And gstreamer is also cross-platform, by the way, and is already used in cross-platform programs, for example, Songbird uses exactly gstreamer on all platforms to play music.
Using gstreamer will solve all problems with codecs in browsers once and for all. In particular, there will be no problems with patents, since the browser will be distributed without codecs protected by patents, but on the user's system he will be able to find the installed plugin for this codec and use it.
Moreover, gstreamer provides the ability to use codecs installed in the framework native to this system (for Windows - DirectShow, for Mac OS - QuickTime).
Actually, here . But judging by the comments there, now such integration is planned only for Fennec. Frankly, I sincerely perplexed about this. H.264 support for Firefox is needed, and quickly, otherwise there is a big risk of being left out.
I don’t know how to bring to Firefox developers the idea that a modular architecture is needed right now. All that came to mind was to vote for this bug, and leave feedback about the non-working website (Help - Report Broken Web Site ...) at youtube.com/html5 with a link to this bug.
Trouble I tried to understand the reason for the refusal, but it seemed to me not too weighty. In principle, there is nothing to add. You can read the discussion, it is quite hot. You can also vote for this bug (mark with an asterisk). You never know ...
Suddenly, a small, but very persistent, Norwegian company shows itself from a very good side. We read, rejoice .
Floppy giants can easily be behind small, almost not used in the broad masses of browsers, such as Epiphany, Midori, Aurora. They all use WebKit. Epiphany and Midori use GtkWebKit, it is planned (or has already done) support for HTML5 video through gstreamer. Aurora uses QtWebKit, it plans (or partially already done) to use Phonon for HTML5, which, in turn, can use different backends, including gstreamer.
However, at the moment, there is no working support for HTML5 in any of them. It remains to believe in their soon bright future, because it is quite real.
I sincerely hope that exactly 2010 will be the year of the death of Flash, and the triumph of HTML5.
And there is only one solution - codecs. Browser developers and content providers did not agree on which codec to use for video. In fact, this problem has been discussed before, and there is no consensus on it. As a result, references to a specific codec have been removed from the HTML5 draft specification.
Codecs
The codec for HTML5 video is currently claimed by two codecs - Ogg Theora and H.264 .
Ogg theora
Ogg Theora is based on VP3 codec developed by On2 Technologies. In 2002, On2 Technologies transferred the VP3 code under a free BSD-like license into the hands of the Xiph.org Foundation, and also refused patents for the codec (technically, they did not refuse, but simply transferred the right to use them to everyone, but this is essentially the same ). Since then, Xiph.org has continued the development of this codec.
')
You can use Ogg Theora anywhere, always, without license or patent deductions.
H.264
H.264 is a licensed video compression standard. Its use requires payment in countries where patents are valid for it (first of all, it is the United States). However, today, this is one of the best ways to compress video. H.264 is the de facto standard for HD video compression, for example. H.264 is noticeably more efficient than Ogg Theora in terms of quality / bitrate.
In short, H.264 is better, but even its open-source implementations cannot be used freely in countries with patents on it.
Implementations in modern browsers
Here I mention only those browsers in which HTML5 video is already working now.
Mozilla firefox
The implementation uses the liboggplay library, which means that only Ogg Theora for video and Ogg Vorbis for audio can be used. Those. the codec is fixed, and to do support for something else, you need to essentially rewrite the implementation.
Google chrome
The implementation uses statically bound ffmpeg . ffmpeg supports a bunch of different codecs, including Ogg Theora, and H.264, and in general, almost everything that is actually used now.
By the way, ffmpeg is currently used almost everywhere - for example, in CCCP and K-Lite Codec Pack , as well as in mplayer and VLC , ffmpeg is used.
It would seem that everything is great. But! ffmpeg, although open source, cannot be free in the United States. To distribute a program that uses ffmpeg, you need to pay deductions. Google can afford it, and has the right to release builds with built-in ffmpeg. But this is not the case with Linux distributions. Those of them that are released in the United States will not be able to include ffmpeg with Chrome support in their repositories, as this will require a deduction fee. First of all it concerns such well-known distribution kit as Fedora.
Safari
It uses the QuickTime framework, which allows you to play anything if the appropriate QuickTime codec is installed.
Probably from modern implementations this is the most correct, since has a modular architecture initially. But this is all heavily tied to Mac OS, so it is not applicable to other systems and browsers.
Harsh reality
Now let's talk about content providers. Freedom
And besides, the use of H.264 is more profitable for us, the end users. We do not pay royalties, but, nevertheless, we get better video quality with less data uploaded (hello to residents of non-capitals with frail channels on the Internet).
Everything is bad?
Now yes. But! There is a way out. To decode video in a browser, you need to use a modular approach, without being tied to a specific codec. Moreover, each operating system already has a modular codec infrastructure. On Windows, this is DirectShow, on Mac OS X, this is QuickTime, on Linux, this is gstreamer . And gstreamer is also cross-platform, by the way, and is already used in cross-platform programs, for example, Songbird uses exactly gstreamer on all platforms to play music.
Using gstreamer will solve all problems with codecs in browsers once and for all. In particular, there will be no problems with patents, since the browser will be distributed without codecs protected by patents, but on the user's system he will be able to find the installed plugin for this codec and use it.
Moreover, gstreamer provides the ability to use codecs installed in the framework native to this system (for Windows - DirectShow, for Mac OS - QuickTime).
A bright future, will it come?
Mozilla firefox
Actually, here . But judging by the comments there, now such integration is planned only for Fennec. Frankly, I sincerely perplexed about this. H.264 support for Firefox is needed, and quickly, otherwise there is a big risk of being left out.
I don’t know how to bring to Firefox developers the idea that a modular architecture is needed right now. All that came to mind was to vote for this bug, and leave feedback about the non-working website (Help - Report Broken Web Site ...) at youtube.com/html5 with a link to this bug.
Google chrome
Trouble I tried to understand the reason for the refusal, but it seemed to me not too weighty. In principle, there is nothing to add. You can read the discussion, it is quite hot. You can also vote for this bug (mark with an asterisk). You never know ...
Opera
Suddenly, a small, but very persistent, Norwegian company shows itself from a very good side. We read, rejoice .
Other browsers
Floppy giants can easily be behind small, almost not used in the broad masses of browsers, such as Epiphany, Midori, Aurora. They all use WebKit. Epiphany and Midori use GtkWebKit, it is planned (or has already done) support for HTML5 video through gstreamer. Aurora uses QtWebKit, it plans (or partially already done) to use Phonon for HTML5, which, in turn, can use different backends, including gstreamer.
However, at the moment, there is no working support for HTML5 in any of them. It remains to believe in their soon bright future, because it is quite real.
Instead of epilogue
I sincerely hope that exactly 2010 will be the year of the death of Flash, and the triumph of HTML5.
Source: https://habr.com/ru/post/82061/
All Articles