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.

Dick Applebaum on whether the iPad is a personal computer: "BTW, I am posting this from my iPad pc while sitting on the throne... personal enough for you?"

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!

.

"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -

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.

Dick Applebaum on whether the iPad is a personal computer: "BTW, I am posting this from my iPad pc while sitting on the throne... personal enough for you?"

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.

.

"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -

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.

.

"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -

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?

.

"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -

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.

Dick Applebaum on whether the iPad is a personal computer: "BTW, I am posting this from my iPad pc while sitting on the throne... personal enough for you?"

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?

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.

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.

This is what seems to stain (a little bit) Apple's Safari TEchnology demos (HTML5 "triumphant" page — for instance, the "VR" demo doesn't work on Leopard's Safari 4.0.5
The Tron trailer on the video demo page works great, though.

I understand there are technical differences between Leopard and Snow Leopard that might have something to do with this, but... Snow Leopard was released not even a year ago and Safari for Leopard doesn't support all these demos?
I know that the upgrade price to Snow Leopard is low, but some people still cannot upgrade because they rely professionally on software that still isn't Snow Leopard ready. (Yes, I understand Apple is not responsible for 3rd-party apps.)

Maybe it's more a question of coherence (or lack of) that bugs me a bit in this case.

1. Apple doesn't care about those people that use 10 year old browsers. Remember, this is the company that dropped the floppy before anyone else did.

2. Apple isn't targeting slow to upgrade businesses.

3. That isn't correct at all. Both Chrome and Firefox on Windows support most of these demos.

4. That number has been decreasing pretty rapidly. That is why the IE team is starting to move towards more standards. We'll see how far they take it.

The fact of the matter is that web developers have always had to target multiple browsers with different capabilities. Apple is trying to force browser developers to adopt some of the more advanced features in the current spec as well as introduce some new features to the spec. We are in a time of change and change is rough sometimes. They are also trying to enlighten their iPhone OS user base that Flash isn't the only answer and that an alternative is available right now. The only users that Apple cares about is their users.

Regarding 1 and 2 - While Apple is not targeting these people, lots of companies on the web are and Apple is limiting the reach to those people if they make up your demographic. For instance, we develop for a lot of companies that use IE and until HTML5 is usable on our client's browsers we will not code for it (and then like IE 6 v IE 7 we will code for both if HTML 5 takes off). I am hoping that Adobe will expand Flash to be able to compile to either Flash or HTML 5 so that this will not be a real issue in the future.

Its not unusual in any way. Snow Leopard has a lot of new API's that Leopard will never have.
If its an OS level API issue, then no it will never change. Leopard will never get SL API's.

Safari 5 will have nothing to do with Mac OS X APIs. It's an application. A separate entity.

There's no way Apple will leave millions of Leopard refugees... users stuck with PPC Macs... in the dark. They'll certainly release a Leopard version of Safari 5, if that's what will really happen.

Apple DOES have a history of releasing compatibility and bug fixes for prior OS releases for quite awhile after an OS is no longer officially shipping. Just take a look at simultaneous 10.5 and 10.6 Security updates and such.

We probably won't see an end to, at least minor, support of Leopard until well after Mac OS X 10.7 is released.

On February 2, 2010 MPEG LA announced that H.264-encoded Internet Video that is free to end users would continue to be exempt from royalty fees until at least December 31, 2015.[11] However, other fees remain in place.

H.264 is open to anyone who has something of value to contribute to it.

That's fine, but how much will it cost you to use what you contributed?

h.264 is neither free nor open source. It is a proprietary, patented technology that requires fees for its use.

Currently the fees required are not called specifically "royalty" fees, but those will be added to the expense of using it in just a few years. The royalty fees are being waived now in an attempt to build market support for lock-in to those fees down the road. Call it "bait and switch", call it "shrewd", or call it whatever you like, just don't call it "free".

Awesome! Next time try conprehending why you read, then reply. My comment was clearly about Handbeake's stated use of the x264 decoder, not about the H.264 codec.

You would do well to heed your own advice. Review the posts in the chain you replied to.

A brief summary to help you out:

I wrote: "How much does the DEcoder cost?" (#295)
To which TenoBell replied: "Are you planning to go into the media playback business?" (#298)
Quoting that, you wrote: "What part of free and open-source does he keep missing." (#299)

You do that often, switching topics and then claiming someone else switched topics. Not at all clever, and not lost on the readers here.

The h.264 decoder is neither free nor open source. What part of "proprietary and requires fees" do you keep missing?

Please understand that I'm not the one telling web publishers that they need to spend thousands of dollars recoding their sites just to make my browser look good, and for video pay my consortium fees for the privilege. If the irrational business proposition that represents that makes you uncomfortable don't shoot the messenger, take it to the source. Steve Jobs can be reached at his widely-published email address at apple.com.

That's fine, but how much will it cost you to use what you contributed? h.264 is neither free nor open source. It is a proprietary, patented technology that requires fees for its use.

What you don't seem to understand is that something that is proprietary is owned and controlled by one entity. No one owns H.264, the MPEG-LA manages the licensing of it. No one owns it.

The cost depends on the type of business you run. If you distribute free content to use H.264 is free, if you distribute content for sale you have to pay based on the size of your business.

Quote:

Currently the fees required are not called specifically "royalty" fees, but those will be added to the expense of using it in just a few years. The royalty fees are being waived now in an attempt to build market support for lock-in to those fees down the road. Call it "bait and switch", call it "shrewd", or call it whatever you like, just don't call it "free".

This is all your assumption. The MPEG-LA has detailed no plans to do this.