Post a Comment
Very interesting. The article gives a good introduction about what "video in a web page" really is. It's worth knowing about containers and codec formats. For web designers, knowing about how the upcoming HTML 5 will work in real life, is an excellent goal for further education. Finally, the article is written well.
Isn't it funny that the things we learned stealing movies are now marketable skills? ...uh, I mean "the things we learned making backups of our legally-purchased DVSs," of course
Isn't it funny that the things we learned stealing movies are now marketable skills? ...uh, I mean "the things we learned making backups of our legally-purchased DVSs," of course
" Primarily, I wanted to be understood in a way that I do welcome every step to make the web (in particular) accessible in a more standardized way, especially regarding things like media content in general. I wasn't thinking about it as a means to distribute the pirated copies of movie DVDs, erm... initializing decentralized backups of them. :-)
This text illustrates very well which concepts and mechanisms apply when we talk about "watching a video", and how HTML 5 may really be a way out of proprietary stuff that pollutes the web. But finally, it's up to the web browser developers and the content designers if they adopt to these methods or keep using their old-fashioned stuff. :-)
Isn't it funny that the things we learned stealing movies are now marketable skills? ...uh, I mean "the things we learned making backups of our legally-purchased DVSs," of course
" Primarily, I wanted to be understood in a way that I do welcome every step to make the web (in particular) accessible in a more standardized way, especially regarding things like media content in general. I wasn't thinking about it as a means to distribute the pirated copies of movie DVDs, erm... initializing decentralized backups of them. :-) [/q]
Sorry, my thought process was probably a bit opaque there. Your comment reminded me that the only reason I know about those things (codecs, container formats, etc) is thanks to hours and hours spent reading through doom9 guides on video conversion & encoding.
Totally agreed. Sadly, I doubt it will be possible get Microsoft or Apple to cooperate when they're both more concerned about pushing their own formats (even if they're just shooting themselves in the fett in a battle they've both already largely lost to Adobe).
Fortunately, they won't have to cooperate. Plug-ins to their browsers solve the problem easily. If Youtube, for instance, switches to an HTML5 video format, is Microsoft or Apple really going to be able to ignore that for long? It wouldn't even have to start with a big player like Youtube, it just has to start somewhere and the ball will keep rolling, so to speak.
It is not a matter of "if", it is a matter of "when".
Fortunately, they won't have to cooperate. Plug-ins to their browsers solve the problem easily. If Youtube, for instance, switches to an HTML5 video format, is Microsoft or Apple really going to be able to ignore that for long? "
Being a cynic, I would personally expect them both (or at least Apple) to write a custom youTube client, as with the iPhone, before they would add full-blown support for Theora.
But yeah, it's going to be interesting to see what happens when the h.264 licensing fees kick in.
It is not a matter of "if", it is a matter of "when".
I hope so - my suspicion is that the adoption will be driven mainly by the increasing popularity of handheld devices that can't hanlde the extra overhead of Flash just for video. I do still think that Flash is currently the best option for web video (assuming a non-technical audience), but only as a lesser evil than WMV/Real/Quicktime.
Edited 2009-10-20 18:28 UTC
I don't think that the HTML 5 methods for embedding video will ever get widespread use. What many people forget is that one reason to use Flash etc is that in a way it helps to prevent the low-brow user from saving the content (e.g. videos) to disk.
This is exactly because Flash etc is not part of the web browser, thus the browser doesn't know how to "save" the video.
With HTML 5, implemented properly, there's no such pseudo-protection.
Nope, because you can already save Flash videos to disk easily already. There are any number of sites, apps and extensions to do this. The answer is but a Google away.
What HTML5 video might do is wake up content providers to the idea that jumping through DRM hoops not only doesn't work, but is actually a detriment to them, their brand, and their product. Just giving people the video straight will do them many favours.
Yea, but it still takes somewhat more effort than just a simple "Save as...". Not every site is as easy as YouTube to get the files from (where you can even find them in the browser cache). Some sites keep switching streaming methods, and new tricks to mislead the video saving tools are certainly still invented. What's more, there is (AFAICT) not one free, well known video saving app and/or extension that works perfectly for all sites, so while it's not impossible to save the content to disk, it sometimes requires some effort on part of the user, so the pseudo-protection probably achieves its goals.
I also guess that e.g. TV stations are under the pressure to do their best to protect third parties' contents, e.g. if MTV.com shows music videos, the record labels would not want to see their DVD sales decrease because everyone watches them in good quality on MTV.com and saves them to disk. Also, the ad partners of MTV.com (who show their ads directly before the actual music videos) certainly want to be sure that it's not ridiculously easy to by-pass their ads by saving the video permanently to disk. Similar requirements might also apply from the part of performance rights organisations, such as GEMA in Germany.
So however crappy and useless such protection measures might be, I believe the content providers often have no choice but to apply them.
But it doesn't prevent. In fact, there are several programs that allow one to save "Flash" videos to disk. Basically it's just a matter of complexity how to save data that arrived at the client can be stored permanently in a file, because the data does arive.
I've often heared that "Flash" is the preferred means for interactive content. In reality, it is used where animated GIFs have been used in the past: To gain attention by moving, jumping and dancing banners, but with "Flash" you can make them singing, peeping and screaming, too. This method seems to be used very often by "professional web designers". In the result, it's use makes websites sometimes even inaccessible. Without the proper plugin (requires a narrow range of operating systems and a specific program version), you see nothing on the page, which is "ideal" for blind users who don't even know if they are on the correct web page. Let me emphasize this: I don't have problems with "Flash" as long as it is used properly (embedded in valid HTML) and doesn't bring down a web page's usability to zero because of no reason.
That's correct. Any "postprocessing" is done by a separate plugin. But imagine: Can "Flash" be considered any standard if it forcedly requires a proprietary plugin? Can you imagine to download plugins for your browser in order to see PNG images, to see text formatted in paragraph mode, or to follow a link? Of course not, because such things are considered standards today - they come with the browser. If "Flash" would be part of the browser - platform independant, free, open - and if you furthermore would be able to switch it off (just like you can switch off CSS formatting or the displaying of images in a web page), the web would be a bit more usable.
And an extra amount of bloat and slowlyness would have the change to go aaway.
I realize you are just taking a pragmatic view on this, and there is no doubt there is truth to your statement. But while you may consider this a barrier to adoption, I see it as a feature and a _benefit_ - it is just a matter of time before the majority of users see it that way as well. And users are what matter, not content producers...
The video tag is useful for many different reasons, one _specific_ reason is that it does _not_ support any method of DRM or other such nonsense. It doesn't hide things. In fact any implementation that included any form of DRM or source masking would be by definition non-conforming.
It has been said thousands of times by many different people, but I will again state the boringly obvious: Any programmatic endeavor to keep people from using data that you have given them in any way they see fit is futile. If you give someone something there is simply no credible way to keep them from doing what they want with it - no matter how much you obfusticate things in the end they still have it, and as long as they have it it is just a matter of time. This has been demonstrated over and over and over and over again. You simply cannot give people access to a video on the internet without in reality giving them the video.
The point is as soon as all these low-brow users you speak of realize how utterly simple it is to just download the video by right clicking and hitting save-as, they will actually want to take the videos with them and will _demand_ things to work that way. If you are a content distributer, and you want use the internet to do so, you need to accept the fact that this will happen. If you don't like it don't distribute your content. My hope is that there is enough content available this way that one day in the not too distant future when some Everyday Joe right-clicks on his video and sees "About Adobe Flash Player x.0" instead of "Save As..." he will just go somewhere else.
Sure. They can decide to distribute their content as collection of colored dots painted on the backs of turtles if they want to... see how they works out for them. The point is they can do whatever they want, but the only thing that will in the end make them _money_ is to do what makes customers want to pay for it. DRM does NOT make customers happy, nor does any other method of limiting what can be done with paid for data.
The studios like to think of it as selling media - but people don't buy media, they buy content. That disconnect has always existed, but until recently the studios have managed to hide it well enough that most people didn't notice the difference enough to care - that is changing rapidly.
It only "takes two to tango" if both parties actually want to. If you dance partner decides your an a**hole and leaves your kinda screwed...
I agree, sadly - but for different reasons (the lack of standardization on a single format/codec).
I don't think that's the chief reason people have for using Flash video, however. It may not be trivially-easy to save Flash video, but it's still easier than it was with WMV/ASX, MOV, and Real Video (or at least with some of the methods used to embed those formats in webpages). Yet most still switched to Flash and away from those formats.
Maybe it's just too early in the day, but that was way too much text for me.
By all means, discuss bits of software that do encoding. Put it on a subsidiary page though will you?
The first sign of a real video tag example in that page was 4/5ths the way through it. Given the length of the article, that's so far from "diving in" it's not funny. Frankly it had lost my attention after the first few pages, even though I was only skimming.
It's also slightly inaccurate/misleading. They have a table showing codec support, indicating that Chromium 3.0 only supports Ogg... Google Chrome supports both Ogg and H264.
Why?
Why should one no-cost software product (Chrome) be allowed to include a bianry blob plugin codec, but not another (Chromium)?
That makes no sense.
Edited 2009-10-18 09:43 UTC
To begin with, H.264 isn't a proprietary codec. It's an ISO and ITU standard.
What is the problem is that you need to pay license fees to actually use it. If you provide it in source-only form then the consensus is that you don't need to pay any fees but if you provide binaries, you need to pay fees. To address this, Google pays the license for Chrome even though they don't charge their users whereas Chromium, the open source project, doesn't pay any fees and isn't allowed to distribute the AVC codec in binary form and apparently doesn't provide it in source form either.
Non-issue: Chromium-codecs-ffmpeg-nonfree.
"This package contains the multi-threaded ffmpeg codecs needed for the HTML5 audio and video tags. In addition to the free ogg, vorbis and theora codecs, H.264, MP3 and AAC are also included. See chromium-codecs-ffmpeg if you prefer only the free codecs"
An interesting article on HTML 5 video.
With that (and other goodies like "datatables" and the "content-editable" attribute), HTML 5 seems to be making very good progress.
It's a shame that (as usual) Microsoft refuses to get with the program and goes its own way, not supporting HTML 5 with IE.
IE users can nevertheless still see the "compliant web" if they install Google Chrome Frame plugin.
Everyone gets to participate.
As a web developer, I'd be tempted to use HTML5 and SVG etc, and add the Chrome Frame tag to the page, and also provide a link to the Chrome Frame plugin in case of IE users who still couldn't see the content.
This is IMO both simpler, and far more inclusive of all end users, than presenting a page that required Silverlight.
Does the HTML5 system support delivery of live video?
I am interested in finding out if the container supports MPEG-TS and the architecture for live video.
I have no expertise in OGG, so does anyone have an opinion on that format's ability for live delivery? Any kind of special conditioning. MPEG-TS has been used for quite a while now for this purpose.




