Yet you are a guy who bought up a codec, that both HTML5 and Flash can use, among other codecs, despite it not being relevant to my comment. It must be hard to be rational when you reading comprehension is such an issue for you.
How does HTML5 play video without paying fees to Apple?
Your screen name appears to have been well chosen.
Sure, Steve likes to point out that it currently has no *royalty* fees, and when spoken exactly like that he's technically correct.
Remember, Steve is a very clever man and with so many billions at stake cannot afford to get that wrong. So he doesn't. His words are carefully chosen by an army of lawyers, worded just catchy enough that other parrot them in web forums.
But as a patent holder of h264, Apple expects vendors writing h264 codecs to pay them other fees which are not called "royalty" fees.
Further, in less than five years they start adding in royalty fees too -- classic bait-n-switch -- so there's a cost now and no way to know how much dependency on h264 is going to cost us in the future.
Correct these pages if you have any evidence to the contrary:
And like the last time you changed the subject and didn't like the way that turned out for you, here in this thread you're the one who brought up HTML5 video. I'm just pointing out to you that Steve Jobs hasn't been entirely forthcoming about all of the relevant facts, so it really does pay to double-check the details on things like that.
Sure, Steve likes to point out that it currently has no *royalty* fees, and when spoken exactly like that he's technically correct.
Remember, Steve is a very clever man and with so many billions at stake cannot afford to get that wrong. So he doesn't. His words are carefully chosen by an army of lawyers, worded just catchy enough that other parrot them in web forums.
But as a patent holder of h264, Apple expects vendors writing h264 codecs to pay them other fees which are not called "royalty" fees.
Further, in less than five years they start adding in royalty fees too -- classic bait-n-switch -- so there's a cost now and no way to know how much dependency on h264 is going to cost us in the future.
Correct these pages if you have any evidence to the contrary:
And like the last time you changed the subject and didn't like the way that turned out for you, here in this thread you're the one who brought up HTML5 video. I'm just pointing out to you that Steve Jobs hasn't been entirely forthcoming about all of the relevant facts, so it really does pay to double-check the details on things like that.
Er... I reviewed those 2 links! Please enlighten me to what specifically you find so unsavory!
Specific quotes would be appreciated over generalized links.
And like the last time you changed the subject and didn't like the way that turned out for you, here in this thread you're the one who brought up HTML5 video. I'm just pointing out to you that Steve Jobs hasn't been entirely forthcoming about all of the relevant facts, so it really does pay to double-check the details on things like that.
HTML5 video tag ≠ H.264 codec
Why is this concept so hard for you to understand?! I never mentioned a particular codec, you did. Seriously, no one here has a problem with you disagreeing with them, but when you switch the subject with each reply you come across as either and idiot or a troll, the latter often applied as the kinder of the two.
That's good. There would be something wrong if they forced codec use to use that aspect of HTML5.
Quote:
So do you think IE will support .mov or Safari .avi or either to support .ogg?
AVI is a poor, outdated container, just like the DiVX codecs are.
I don't expect MS or anyone else to support Apple's MOV container.
MS, Apple, Google, Adobe from OSes to plug-ins to browsers; x86, ARM, Nvidia, ATI and Blu-ray all support H.264, as well as every relevant site support H.264 at various levels so it's here to stay. The only caveat and what was expected when Google bought VP8, was that they were going to make it open source (√), they are going to spend several years developing it into a rival for H.264, but their primary goal is to get MPEG-LA to make H.264 completely royalty free, not to completely usurp it's current dominate position as the best and most used modern codec and cause the industry to completely change again. It's a good move by Google. Either way, they win, so long as they can make VP8 a rel player and make sure they have cut off every viable legal avenue one might take against it.
It adds a new perspective to the Flash vs HTML5 skirmish.
Here's a little tease, emphasis mine (with the full link below);
Quote:
Very early into Mr. Underkoffler's presentation he uses the Mac OS as the core of his initial point, as follows: The early Macintosh team in '82, '83 ?'84 had to write an entire new operating system from the ground up. Now this is an interesting little message and it's a lesson that I think has since been forgotten or lost or something ? and that is namely ? that the OS is the interface. The interface is the OS. It's like the land and king in Arthur, they're inseparable, they're one. And to write a new operating system wasn't a capricious matter. It wasn't a matter of tuning up some graphics routine - there were no graphic routines. There were no mouse drivers."
He makes a case for why other browser makers are angry about Apple's HTML5 demo. And how he feels Apple is being disingenuous. Some of the features Apple shows are not officially apart of HTML5 and that is the reason why they are not supported by all browsers. From his perspective I can understand much of his point.
At the same time from Apple's perspective Apple would like for these features to officially be apart of HTML5 and widely adopted by all browsers. That is the point of the demonstration.
The other browser makers feel that Apple is undermining the abilities and importance of their browsers. I think Apple is doing that but not quite in the way that they are taking it.
I believe what Apple most wants to show in these demo's is the potential of features and technologies of what they hope HTML5 to become. It does undermine what other browsers are able to do because they don't all support the features that Apple presents.
The over all point is that Apple wants all of these features to be incorporated into HTML5 and for all browsers to support these features.
He makes a case for why other browser makers are angry about apple's html5 demo. And how he feels apple is being disingenuous. Some of the features apple shows are not officially apart of html5 and that is the reason why they are not supported by all browsers. From his perspective i can understand much of his point.
At the same time from apple's perspective apple would like for these features to officially be apart of html5 and widely adopted by all browsers. That is the point of the demonstration.
The other browser makers feel that apple is undermining the abilities and importance of their browsers. I think apple is doing that but not quite in the way that they are taking it.
I believe what apple most wants to show in these demo's is the potential of features and technologies of what they hope html5 to become. It does undermine what other browsers are able to do because they don't all support the features that apple presents.
The over all point is that apple wants all of these features to be incorporated into html5 and for all browsers to support these features.
AVI may have been around for awhile but the quality is still very good. My point is what is going to be the preferred file extension? .m4v, mp4, mpg, mpeg, m4a, h264 etc.? Within that group they each have the ability to be encoded with various codecs. I don't see how we are going to be any better off with the <video> tag than we were with flv. At least everyone supported Flash video.
Now each browser maker has a dog in the race again as far as video is concerned. That was the original problem that caused Flash to win out before.
AVI may have been around for awhile but the quality is still very good. My point is what is going to be the preferred file extension? .m4v, mp4, mpg, mpeg, m4a, h264 etc.? Within that group they each have the ability to be encoded with various codecs. I don't see how we are going to be any better off with the <video> tag than we were with flv. At least everyone supported Flash video.
Now each browser maker has a dog in the race again as far as video is concerned. That was the original problem that caused Flash to win out before.
1) Supporting various containers isn't an issue. The issue is getting the codec support. If you have that then the rest is gravy. If a site is oddly using a wonky container with a standard codec that the browser can't understand then it's their fault for going that route.
2) What is "quality" about the AVI container? I hope you aren't confusing the common video codec used with AVIs with the container.
3) Here is what Handbrake, the "open-source, GPL-licensed, multiplatform, multithreaded video transcoder, available for MacOS X, Linux and Windows" has to say about dropping support for AVI and DivX.
As we've had on our roadmap for quite awhile now, one of our goals for version 0.9.4 was to refocus on HandBrake's key strengths and to remove dead weight. As part of this process, several containers and a codec have been removed from HandBrake.
AVI: AVI is a rough beast. It is obsolete. It does not support modern container features like chapters, muxed-in subtitles, variable framerate video, or out of order frame display. Furthermore, HandBrake's AVI muxer is vanilla AVI 1.0 that doesn't even support large files. The code has not been actively maintained since 2005. Keeping it in the library while implementing new features means a very convoluted data pipeline, full of conditionals that make the code more difficult to read and maintain, and make output harder to predict. As such, it is now gone. It is not coming back, and good riddance.
XviD: HandBrake, these days, is almost entirely about H.264 video, aka MPEG-4 Part 10. This makes it rather...superfluous to include two different encoders for an older codec, MPEG-4 Part 2. When choosing between FFmpeg's and XviD's, it came down to a matter of necessity. We need to include libavcodec (FFmpeg) for a bunch of other parts of its API, like decoding. Meanwhile, XviD's build system causes grief (it's the most common support query we get about compiling, after x264's requirement of yasm). Since we mainly use MPEG-4 Part 2 for testing/debugging, and recommend only H.264 for high quality encodes, Xvid's undisputed quality edge over FFmpeg's encoder is inconsequential, while FFmpeg's speed edge over XviD is important to us.
AVI may have been around for awhile but the quality is still very good. My point is what is going to be the preferred file extension? .m4v, mp4, mpg, mpeg, m4a, h264 etc.? Within that group they each have the ability to be encoded with various codecs. I don't see how we are going to be any better off with the <video> tag than we were with flv. At least everyone supported Flash video.
Now each browser maker has a dog in the race again as far as video is concerned. That was the original problem that caused Flash to win out before.
What you say is true!
But the problem is that Flash changed everyvideo flavor to vanilla-- a workable, but uninspiring video player... with a few good features and a lot of bad ones.
IMHO, users have seen the light and will not be bothered with a non-standard UI and be satisfied with: ""you can have any flavor you want-- as long as it's vanilla!"
The browser makers that understand this, and adapt will win the day!
3) Here is what Handbrake, the "open-source, GPL-licensed, multiplatform, multithreaded video transcoder, available for MacOS X, Linux and Windows" has to say about dropping support for AVI and DivX.
Good info. Quick question: Do you know if Handbrake is licensed to export to h.264? Reason I ask is that they kind of have the reputation as a cracker type DVD ripper.
But the problem is that Flash changed everyvideo flavor to vanilla-- a workable, but uninspiring video player... with a few good features and a lot of bad ones.
IMHO, users have seen the light and will not be bothered with a non-standard UI and be satisfied with: ""you can have any flavor you want-- as long as it's vanilla!"
The browser makers that understand this, and adapt will win the day!
.
Sorry Dick, this makes no sense to me. I can make any kind of video UI I want with Flash. I can even provide a button to make the video play backwards. With <video> you only get the default controller.
Good info. Quick question: Do you know if Handbrake is licensed to export to h.264? Reason I ask is that they kind of have the reputation as a cracker type DVD ripper.
They use x264 specifically because it's free to use. Whether that would be an issue outside of France, if they ever tried to sell the app, or even in the future as is remains to be seen, but so far it's all free.
x264
A large portion of these speed, size, and quality improvements come to us for free, from the x264 project.
Note: From my previous post, Apple does use the QuickTime MOV container with the Tron video demo, which further shows this is about marketing Safari over other browsers, not marketing HTML5, CSS3 and JS over Flash. I tested it in Chrome v5 and the apge would load with a static image, but no video. You could option to DL the video, though.
2) What is "quality" about the AVI container? I hope you aren't confusing the common video codec used with AVIs with the container.
I don't know that much about codecs. I just use the tools. FCP on Mac and Premiere on Windows. On Windows I always render the movie as AVI at the highest quality I think it says Video for Windows and it looks fantastic. At that point I use Flash to create flv.
Sorry Dick, this makes no sense to me. I can make any kind of video UI I want with Flash. I can even provide a button to make the video play backwards. With <video> you only get the default controller.
Thats not true. With CSS3 and JS you can do anything you want with the embedded video. But none of that is the point of the inclusion of this brilliant tag. The point is to make it faster and smoother with less overhead. Regardless of what Adobe has told you playing video is considerably less resource intensive than playing it webcode. Plugins are the not the answer for this simple task, especially on mobiles.
Comments
Yet you are a guy who bought up a codec, that both HTML5 and Flash can use, among other codecs, despite it not being relevant to my comment. It must be hard to be rational when you reading comprehension is such an issue for you.
How does HTML5 play video without paying fees to Apple?
Your screen name appears to have been well chosen.
How does HTML5 play video without paying fees to Apple?
You're implying that by including the HTML5 video tag Apple gets money from MPEG-LA.
You're implying that by including the HTML5 video tag and playing Ogg or VP8 Apple gets money from MPEG-LA.
You're ignoring that Flash, Silverlight and others also use H.264.
You're ignoring H.264 is royalty free until 2016.
Everything you stated that you are now trying to backpedal out of from your initial issue with reading comprehension.
You're ignoring H.264 is royalty free until 2016.
Sure, Steve likes to point out that it currently has no *royalty* fees, and when spoken exactly like that he's technically correct.
Remember, Steve is a very clever man and with so many billions at stake cannot afford to get that wrong. So he doesn't. His words are carefully chosen by an army of lawyers, worded just catchy enough that other parrot them in web forums.
But as a patent holder of h264, Apple expects vendors writing h264 codecs to pay them other fees which are not called "royalty" fees.
Further, in less than five years they start adding in royalty fees too -- classic bait-n-switch -- so there's a cost now and no way to know how much dependency on h264 is going to cost us in the future.
Correct these pages if you have any evidence to the contrary:
http://en.wikipedia.org/wiki/H.264#Patent_licensing
http://en.wikipedia.org/wiki/MPEG_LA
And like the last time you changed the subject and didn't like the way that turned out for you, here in this thread you're the one who brought up HTML5 video. I'm just pointing out to you that Steve Jobs hasn't been entirely forthcoming about all of the relevant facts, so it really does pay to double-check the details on things like that.
Sure, Steve likes to point out that it currently has no *royalty* fees, and when spoken exactly like that he's technically correct.
Remember, Steve is a very clever man and with so many billions at stake cannot afford to get that wrong. So he doesn't. His words are carefully chosen by an army of lawyers, worded just catchy enough that other parrot them in web forums.
But as a patent holder of h264, Apple expects vendors writing h264 codecs to pay them other fees which are not called "royalty" fees.
Further, in less than five years they start adding in royalty fees too -- classic bait-n-switch -- so there's a cost now and no way to know how much dependency on h264 is going to cost us in the future.
Correct these pages if you have any evidence to the contrary:
http://en.wikipedia.org/wiki/H.264#Patent_licensing
http://en.wikipedia.org/wiki/MPEG_LA
And like the last time you changed the subject and didn't like the way that turned out for you, here in this thread you're the one who brought up HTML5 video. I'm just pointing out to you that Steve Jobs hasn't been entirely forthcoming about all of the relevant facts, so it really does pay to double-check the details on things like that.
Er... I reviewed those 2 links! Please enlighten me to what specifically you find so unsavory!
Specific quotes would be appreciated over generalized links.
.
And like the last time you changed the subject and didn't like the way that turned out for you, here in this thread you're the one who brought up HTML5 video. I'm just pointing out to you that Steve Jobs hasn't been entirely forthcoming about all of the relevant facts, so it really does pay to double-check the details on things like that.
HTML5 video tag ≠ H.264 codec
Why is this concept so hard for you to understand?! I never mentioned a particular codec, you did. Seriously, no one here has a problem with you disagreeing with them, but when you switch the subject with each reply you come across as either and idiot or a troll, the latter often applied as the kinder of the two.
HTML5 video tag ≠ H.264 codec
And because the <video> tag has no relationship to codec the video wars continue.
HTML 5 spec only provides these attribute to <video>
autoplay, controls, height, loop, preload, src, width
So do you think IE will support .mov or Safari .avi or either to support .ogg?
And because the <video> tag has no relationship to codec the video wars continue.
HTML 5 spec only provides these attribute to <video>
autoplay, controls, height, loop, preload, src, width
That's good. There would be something wrong if they forced codec use to use that aspect of HTML5.
So do you think IE will support .mov or Safari .avi or either to support .ogg?
AVI is a poor, outdated container, just like the DiVX codecs are.
I don't expect MS or anyone else to support Apple's MOV container.
MS, Apple, Google, Adobe from OSes to plug-ins to browsers; x86, ARM, Nvidia, ATI and Blu-ray all support H.264, as well as every relevant site support H.264 at various levels so it's here to stay. The only caveat and what was expected when Google bought VP8, was that they were going to make it open source (√), they are going to spend several years developing it into a rival for H.264, but their primary goal is to get MPEG-LA to make H.264 completely royalty free, not to completely usurp it's current dominate position as the best and most used modern codec and cause the industry to completely change again. It's a good move by Google. Either way, they win, so long as they can make VP8 a rel player and make sure they have cut off every viable legal avenue one might take against it.
Here is an article worth reading and watching!
It adds a new perspective to the Flash vs HTML5 skirmish.
Here's a little tease, emphasis mine (with the full link below);
Very early into Mr. Underkoffler's presentation he uses the Mac OS as the core of his initial point, as follows: The early Macintosh team in '82, '83 ?'84 had to write an entire new operating system from the ground up. Now this is an interesting little message and it's a lesson that I think has since been forgotten or lost or something ? and that is namely ? that the OS is the interface. The interface is the OS. It's like the land and king in Arthur, they're inseparable, they're one. And to write a new operating system wasn't a capricious matter. It wasn't a matter of tuning up some graphics routine - there were no graphic routines. There were no mouse drivers."
http://www.patentlyapple.com/patentl...gins.html#more
.
He makes a case for why other browser makers are angry about Apple's HTML5 demo. And how he feels Apple is being disingenuous. Some of the features Apple shows are not officially apart of HTML5 and that is the reason why they are not supported by all browsers. From his perspective I can understand much of his point.
At the same time from Apple's perspective Apple would like for these features to officially be apart of HTML5 and widely adopted by all browsers. That is the point of the demonstration.
The other browser makers feel that Apple is undermining the abilities and importance of their browsers. I think Apple is doing that but not quite in the way that they are taking it.
I believe what Apple most wants to show in these demo's is the potential of features and technologies of what they hope HTML5 to become. It does undermine what other browsers are able to do because they don't all support the features that Apple presents.
The over all point is that Apple wants all of these features to be incorporated into HTML5 and for all browsers to support these features.
an interesting post by chris blizzard of mozilla .
He makes a case for why other browser makers are angry about apple's html5 demo. And how he feels apple is being disingenuous. Some of the features apple shows are not officially apart of html5 and that is the reason why they are not supported by all browsers. From his perspective i can understand much of his point.
At the same time from apple's perspective apple would like for these features to officially be apart of html5 and widely adopted by all browsers. That is the point of the demonstration.
The other browser makers feel that apple is undermining the abilities and importance of their browsers. I think apple is doing that but not quite in the way that they are taking it.
I believe what apple most wants to show in these demo's is the potential of features and technologies of what they hope html5 to become. It does undermine what other browsers are able to do because they don't all support the features that apple presents.
The over all point is that apple wants all of these features to be incorporated into html5 and for all browsers to support these features.
+++ qft
.
I think your synopsis is dead on.
AVI is a poor, outdated container,
AVI may have been around for awhile but the quality is still very good. My point is what is going to be the preferred file extension? .m4v, mp4, mpg, mpeg, m4a, h264 etc.? Within that group they each have the ability to be encoded with various codecs. I don't see how we are going to be any better off with the <video> tag than we were with flv. At least everyone supported Flash video.
Now each browser maker has a dog in the race again as far as video is concerned. That was the original problem that caused Flash to win out before.
AVI may have been around for awhile but the quality is still very good. My point is what is going to be the preferred file extension? .m4v, mp4, mpg, mpeg, m4a, h264 etc.? Within that group they each have the ability to be encoded with various codecs. I don't see how we are going to be any better off with the <video> tag than we were with flv. At least everyone supported Flash video.
Now each browser maker has a dog in the race again as far as video is concerned. That was the original problem that caused Flash to win out before.
1) Supporting various containers isn't an issue. The issue is getting the codec support. If you have that then the rest is gravy. If a site is oddly using a wonky container with a standard codec that the browser can't understand then it's their fault for going that route.
2) What is "quality" about the AVI container? I hope you aren't confusing the common video codec used with AVIs with the container.
3) Here is what Handbrake, the "open-source, GPL-licensed, multiplatform, multithreaded video transcoder, available for MacOS X, Linux and Windows" has to say about dropping support for AVI and DivX.
AVI may have been around for awhile but the quality is still very good. My point is what is going to be the preferred file extension? .m4v, mp4, mpg, mpeg, m4a, h264 etc.? Within that group they each have the ability to be encoded with various codecs. I don't see how we are going to be any better off with the <video> tag than we were with flv. At least everyone supported Flash video.
Now each browser maker has a dog in the race again as far as video is concerned. That was the original problem that caused Flash to win out before.
What you say is true!
But the problem is that Flash changed every video flavor to vanilla-- a workable, but uninspiring video player... with a few good features and a lot of bad ones.
IMHO, users have seen the light and will not be bothered with a non-standard UI and be satisfied with: ""you can have any flavor you want-- as long as it's vanilla!"
The browser makers that understand this, and adapt will win the day!
.
3) Here is what Handbrake, the "open-source, GPL-licensed, multiplatform, multithreaded video transcoder, available for MacOS X, Linux and Windows" has to say about dropping support for AVI and DivX.
Good info. Quick question: Do you know if Handbrake is licensed to export to h.264? Reason I ask is that they kind of have the reputation as a cracker type DVD ripper.
What you say is true!
But the problem is that Flash changed every video flavor to vanilla-- a workable, but uninspiring video player... with a few good features and a lot of bad ones.
IMHO, users have seen the light and will not be bothered with a non-standard UI and be satisfied with: ""you can have any flavor you want-- as long as it's vanilla!"
The browser makers that understand this, and adapt will win the day!
.
Sorry Dick, this makes no sense to me. I can make any kind of video UI I want with Flash. I can even provide a button to make the video play backwards. With <video> you only get the default controller.
Good info. Quick question: Do you know if Handbrake is licensed to export to h.264? Reason I ask is that they kind of have the reputation as a cracker type DVD ripper.
They use x264 specifically because it's free to use. Whether that would be an issue outside of France, if they ever tried to sell the app, or even in the future as is remains to be seen, but so far it's all free.
Note: From my previous post, Apple does use the QuickTime MOV container with the Tron video demo, which further shows this is about marketing Safari over other browsers, not marketing HTML5, CSS3 and JS over Flash. I tested it in Chrome v5 and the apge would load with a static image, but no video. You could option to DL the video, though.
2) What is "quality" about the AVI container? I hope you aren't confusing the common video codec used with AVIs with the container.
I don't know that much about codecs. I just use the tools. FCP on Mac and Premiere on Windows. On Windows I always render the movie as AVI at the highest quality I think it says Video for Windows and it looks fantastic. At that point I use Flash to create flv.
Sorry Dick, this makes no sense to me. I can make any kind of video UI I want with Flash. I can even provide a button to make the video play backwards. With <video> you only get the default controller.
Thats not true. With CSS3 and JS you can do anything you want with the embedded video. But none of that is the point of the inclusion of this brilliant tag. The point is to make it faster and smoother with less overhead. Regardless of what Adobe has told you playing video is considerably less resource intensive than playing it webcode. Plugins are the not the answer for this simple task, especially on mobiles.
They use x264 specifically because it's free to use.
Free still has to be licensed doesn't it?