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.
I suppose since I have seen some custom controllers on Apple's site. I guess you have to figure out how to actually control the video with an external controller. It doesn't sound fast or easy but nothing is impossible. It is just that the show controller attribute is going to give your THE controller, no options.
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 and it looks fantastic. At that point I use Flash to create flv.
The container is the wrapper for the content usually represented by the file extension.
Within that container lies the content that has been encoded using a specifically codec (coder/decoder) which then gets decoded.
Containers only support certain codecs and each container has pros and cons, but as quoted above from Handbrake's site, the AVI container and DivX codec is quite limiting and old. Also, usually you'll find the familiar mp3 audio codec in AVIs
You can open a video and choose Info to see the container, video codec and audio codec being used.
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.
I don't disagree in general however I have made some really nice presentations with Flash that have video that at certain points, might shrink down to a corner on the stage and allow for white board type side bars, additional voice overs and links. The whole generic <video> philosophy seems so limiting to me.
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.
That's a very interesting post-- compelling reasons to abandon legacy systems to be better able to meet future challenges!
I suspect that the industry (computers, communications, movies, TVs, etc.) needs to go through a [somewhat] uncomfortable renaissance to prepare for the future. Oddly, the consumer seems to be the one most welcome to change!
They are independent. It could be as easy as agreeing to some terms. Note that x264 is ONLY an encoder for H.264 video.
Quote:
Originally Posted by mstone
I suppose since I have seen some custom controllers on Apple's site. I guess you have to figure out how to actually control the video with an external controller. It doesn't sound fast or easy but nothing is impossible. It is just that the show controller attribute is going to give your THE controller, no options.
Besides Google's efforts with HTML5 on YouTube which look just like the Flash player. There are several demo sites like Sublime and Video for Everybody which have been showing for many months how you can make a great player with webcode. These all have a fallback for Flash if the browser isn't supported.
The only drawback has been the inability to easily make the video fullscreen. Chrome 5 added the Full Screen option and it appears Safari 5 will be so as well. These are to the app itself which is not as ideal or simple as Flash can do as a plug-in. Sublime figured out a way to do this with the WebKit engine in the more modern WebKit nightlies by pressing a keyboard key and hitting the fullscreen button. This is better, but not great. There needs to be a way to code for a button allowing fullscreen without any other input or pulling from the app's Menu Bar to make it happen.
I don't disagree in general however I have made some really nice presentations with Flash that have video that at certain points, might shrink down to a corner on the stage and allow for white board type side bars, additional voice overs and links. The whole generic <video> philosophy seems so limiting to me.
Long ago, and far away, I worked on an experimental web site that navigated, then displayed a video of, say, a recipe for cooking chicken cordon Bleu, You could manipulate the video (start/stop, fade to the BG) display the recipe, cooking instructions, shop for cooking utensils, etc. It was difficult (programming) but very rewarding from the consumer perspective. AIR, I used both Flash and SMIL to interact the videos and textual content.
Unfortunately, the browser wars were in full bloom and there was no way to "deliver" the experience across platforms.
This is one place that I have to admit that Flash (with all its problems) is a superior vehicle for this type of UX.
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.
Sorry, should have added the qualification of "until recently"! You had One-size-fits-all Flash video, at what 640x480. With the advent of the iPhone, YT and others began offering high(er) quality [Flash and non-Flash] video presentation to compete with the superior results of other presentation vehicles... QT on the Mac platform, for example.
I don't understand what you feel is limited. The video tag simply allows video playback within the browser without a media framework plug in. What do you feel that limits?
Here is an example of what can be done within HTML5 video
Quote:
Originally Posted by mstone
The whole generic <video> philosophy seems so limiting to me.
They are independent. It could be as easy as agreeing to some terms. Note that x264 is ONLY an encoder for H.264 video.
Besides Google's efforts with HTML5 on YouTube which look just like the Flash player. There are several demo sites like Sublime and Video for Everybody which have been showing for many months how you can make a great player with webcode. These all have a fallback for Flash if the browser isn't supported.
The only drawback has been the inability to easily make the video fullscreen. Chrome 5 added the Full Screen option and it appears Safari 5 will be so as well. These are to the app itself which is not as ideal or simple as Flash can do as a plug-in. Sublime figured out a way to do this with the WebKit engine in the more modern WebKit nightlies by pressing a keyboard key and hitting the fullscreen button. This is better, but not great. There needs to be a way to code for a button allowing fullscreen without any other input or pulling from the app's Menu Bar to make it happen.
I suspect that the problem (for Safari) is that its video engine (QuickTime) is temporarily in limbo-- somewhere between QT7 and QTX (32 bit and 64 bit). I expect this situation to be resolved this year.
Also, QT is a key component (maybe THE key component) of Apple's Pro apps. Once the QTX issue is resolved, I expect Apple's pro apps to Wow! us with their capability,,,
Then there is the iPhone/iPad platform... resolution of this [video] issue will open the platform to, what: Mobile Semi-Power apps-- as Steve Jobs has suggested?
I suspect that the problem (for Safari) is that its video engine (QuickTime) is temporarily in limbo-- somewhere between QT7 and QTX (32 bit and 64 bit). I expect this situation to be resolved this year.
There was a post yesterday on this forum stating how the latest Safari 4 in Leopard doesn't work with these demos. That is likely due to QTX only being supported in Snow Leopard. Thanks, I was wondering about Apple's angel there.
See, Apple isn't just ignoring Firefox and Chrome, but also Leopard, in these demos.
Transparency is the killer for HTML 5 and Flash. Because transparency is such an easy thing to do in Flash and the results are visually pleasing, you see it everywhere. The power required to add the shadowBlur and render the underlying objects while animating the top layer is where the whole thing goes south.
Hmm, where is transparency causing problems?
And you do realize that all browsers will have hardware acceleration from this year and on?
Are you planning to go into the media playback business?
That kid is so annoying. What part of free and open-source does he keep missing. I don't mind disagreeing with posters, but I can't stand when they constantly fail to read.
Quote:
Chrome just received a major upgrade.
I'm not sure what version of Safari he used to get 70/160, but Mobile Safari get 133/160 and Safari 4.0.5 on Mac OS X gets 113/160.
Again, all of this is irrelevant to the Demos designed to show Safari in action, not its competition. They heavily used 3D Transforms, which only WebKit supports? If others designed Demos that required SVG Filters, MathML, Ogg A/V, etc. then Safari obviously wouldn't work.
Here is some more robust pages detailing the state of support for future web standards.
Comments
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.
I suppose since I have seen some custom controllers on Apple's site. I guess you have to figure out how to actually control the video with an external controller. It doesn't sound fast or easy but nothing is impossible. It is just that the show controller attribute is going to give your THE controller, no options.
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 and it looks fantastic. At that point I use Flash to create flv.
The container is the wrapper for the content usually represented by the file extension.
Within that container lies the content that has been encoded using a specifically codec (coder/decoder) which then gets decoded.
Containers only support certain codecs and each container has pros and cons, but as quoted above from Handbrake's site, the AVI container and DivX codec is quite limiting and old. Also, usually you'll find the familiar mp3 audio codec in AVIs
You can open a video and choose Info to see the container, video codec and audio codec being used.
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.
I don't disagree in general however I have made some really nice presentations with Flash that have video that at certain points, might shrink down to a corner on the stage and allow for white board type side bars, additional voice overs and links. The whole generic <video> philosophy seems so limiting to me.
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.
That's a very interesting post-- compelling reasons to abandon legacy systems to be better able to meet future challenges!
I suspect that the industry (computers, communications, movies, TVs, etc.) needs to go through a [somewhat] uncomfortable renaissance to prepare for the future. Oddly, the consumer seems to be the one most welcome to change!
.
Free still has to be licensed doesn't it?
They are independent. It could be as easy as agreeing to some terms. Note that x264 is ONLY an encoder for H.264 video.
I suppose since I have seen some custom controllers on Apple's site. I guess you have to figure out how to actually control the video with an external controller. It doesn't sound fast or easy but nothing is impossible. It is just that the show controller attribute is going to give your THE controller, no options.
Besides Google's efforts with HTML5 on YouTube which look just like the Flash player. There are several demo sites like Sublime and Video for Everybody which have been showing for many months how you can make a great player with webcode. These all have a fallback for Flash if the browser isn't supported.
The only drawback has been the inability to easily make the video fullscreen. Chrome 5 added the Full Screen option and it appears Safari 5 will be so as well. These are to the app itself which is not as ideal or simple as Flash can do as a plug-in. Sublime figured out a way to do this with the WebKit engine in the more modern WebKit nightlies by pressing a keyboard key and hitting the fullscreen button. This is better, but not great. There needs to be a way to code for a button allowing fullscreen without any other input or pulling from the app's Menu Bar to make it happen.
I don't disagree in general however I have made some really nice presentations with Flash that have video that at certain points, might shrink down to a corner on the stage and allow for white board type side bars, additional voice overs and links. The whole generic <video> philosophy seems so limiting to me.
Long ago, and far away, I worked on an experimental web site that navigated, then displayed a video of, say, a recipe for cooking chicken cordon Bleu, You could manipulate the video (start/stop, fade to the BG) display the recipe, cooking instructions, shop for cooking utensils, etc. It was difficult (programming) but very rewarding from the consumer perspective. AIR, I used both Flash and SMIL to interact the videos and textual content.
Unfortunately, the browser wars were in full bloom and there was no way to "deliver" the experience across platforms.
This is one place that I have to admit that Flash (with all its problems) is a superior vehicle for this type of UX.
.
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.
Sorry, should have added the qualification of "until recently"! You had One-size-fits-all Flash video, at what 640x480. With the advent of the iPhone, YT and others began offering high(er) quality [Flash and non-Flash] video presentation to compete with the superior results of other presentation vehicles... QT on the Mac platform, for example.
.
Here is an example of what can be done within HTML5 video
The whole generic <video> philosophy seems so limiting to me.
The only drawback has been the inability to easily make the video fullscreen.
Although full screen is a worthy feature to have I am much more interested in being able to script the keyframes.
Signing off for today.
They are independent. It could be as easy as agreeing to some terms. Note that x264 is ONLY an encoder for H.264 video.
Besides Google's efforts with HTML5 on YouTube which look just like the Flash player. There are several demo sites like Sublime and Video for Everybody which have been showing for many months how you can make a great player with webcode. These all have a fallback for Flash if the browser isn't supported.
The only drawback has been the inability to easily make the video fullscreen. Chrome 5 added the Full Screen option and it appears Safari 5 will be so as well. These are to the app itself which is not as ideal or simple as Flash can do as a plug-in. Sublime figured out a way to do this with the WebKit engine in the more modern WebKit nightlies by pressing a keyboard key and hitting the fullscreen button. This is better, but not great. There needs to be a way to code for a button allowing fullscreen without any other input or pulling from the app's Menu Bar to make it happen.
I suspect that the problem (for Safari) is that its video engine (QuickTime) is temporarily in limbo-- somewhere between QT7 and QTX (32 bit and 64 bit). I expect this situation to be resolved this year.
Also, QT is a key component (maybe THE key component) of Apple's Pro apps. Once the QTX issue is resolved, I expect Apple's pro apps to Wow! us with their capability,,,
Then there is the iPhone/iPad platform... resolution of this [video] issue will open the platform to, what: Mobile Semi-Power apps-- as Steve Jobs has suggested?
.
I suspect that the problem (for Safari) is that its video engine (QuickTime) is temporarily in limbo-- somewhere between QT7 and QTX (32 bit and 64 bit). I expect this situation to be resolved this year.
There was a post yesterday on this forum stating how the latest Safari 4 in Leopard doesn't work with these demos. That is likely due to QTX only being supported in Snow Leopard. Thanks, I was wondering about Apple's angel there.
See, Apple isn't just ignoring Firefox and Chrome, but also Leopard, in these demos.
Although full screen is a worthy feature to have I am much more interested in being able to script the keyframes.
Signing off for today.
Thanks... enjoyed the discussion and learned some thing!
.
Here is an example of what can be done within HTML5 video
Ha ha real interesting
As soon as you scroll down to the bottom of the page you see a link to "you should check out this artist" it is all Flash.
They are independent. It could be as easy as agreeing to some terms. Note that x264 is ONLY an encoder for H.264 video.
How much does the DEcoder cost?
Transparency is the killer for HTML 5 and Flash. Because transparency is such an easy thing to do in Flash and the results are visually pleasing, you see it everywhere. The power required to add the shadowBlur and render the underlying objects while animating the top layer is where the whole thing goes south.
Hmm, where is transparency causing problems?
And you do realize that all browsers will have hardware acceleration from this year and on?
How much does the DEcoder cost?
Are you planning to go into the media playback business?
http://i.imgur.com/cT08B.png
Chrome just received a major upgrade.
Are you planning to go into the media playback business?
That kid is so annoying. What part of free and open-source does he keep missing. I don't mind disagreeing with posters, but I can't stand when they constantly fail to read.
Chrome just received a major upgrade.
I'm not sure what version of Safari he used to get 70/160, but Mobile Safari get 133/160 and Safari 4.0.5 on Mac OS X gets 113/160.
Again, all of this is irrelevant to the Demos designed to show Safari in action, not its competition. They heavily used 3D Transforms, which only WebKit supports? If others designed Demos that required SVG Filters, MathML, Ogg A/V, etc. then Safari obviously wouldn't work.
Here is some more robust pages detailing the state of support for future web standards.I find it interesting that Safari doesn't yet support AAC in audio tag.
Here is some more robust pages detailing the state of support for future web standards.I find it interesting that Safari doesn't yet support AAC in audio tag.
Ha! That is nor of the few pages where i reduce the text size (Safari) to make it more readable...
Also control-option-command-8 to make it dark text with a light background.
It also appears that Safari is concentrating on "presentation" rather than data entry (Forms).
.
It also appears that Safari is concentrating on "presentation" rather than data entry (Forms).
Yeah, they are dropping the ball with Forms, but not as bad as Mozilla or MS. I hope Safari 5 will wok to trump Chrome on that level of completion.