Of course, in 2-3 years Tarkin will be competing against formats like H.26L, which is designed to be a use-fee-free international standard.
The target for H.26L is transparent compression of film content (read DVD) at 800 Kbps.
And of course, H.26L has been in development for several years, and has working code. It's much further along. Tarkin isn't even close to the point where we can start to guess what a real-world version's performance would even look like.
A nitpicky point - VP3 as implemented in AVI and QuickTime files is designed for progressive download, not true, real-time streaming. Thus, you get the classic movie trailer wait-awhile-and-play experience, but without the ability to do random access over long files and that kind of groovy stuff.
Good support for real-time streaming would require a native packetizer to build a hint track that the (open source) Darwin Streaming Server uses to determine packetization of the stream, and which helps loss recovery and other good stuff.
Adding a native packetizer for VP3 would be an excellent open source project for the codec.
VP5 is a very different beast than VP3 - there was a whole VP4 version between there. I doubt On2 is getting much in the way of benefit to VP5 from VP3 being open source. It's probably mainly a brand recognition thing to keep their name in the codec community while they prepare VP5 for launch.
Actually, the requirement in the old VP3 license was that you needed to maintain the ability to decode standard VP3 encoded files. It was perfectly kosher to add support for a new, enhanced/incompatible version, as long as the codec could still decode standard files.
Of course, there are network effects on the manufacturing side, as mentioned in the articles. Motherboard chipsets being a good example. The higher volume of Intel solutions has meant that the motherboards can be cheaper at a given complexity. Fortunately, a CPU is a lot more expensive than the motherboard, and other components are the same (drives, cards, etcetera).
There is also some potential network effect in optimization for processor specific optimizations, like SSE v. 3DNow, since it makes sense to optimize more for the higher volume chip. I gather Hammer will have SSE2, so that'll simplify things on the SIMD side at least.
Actually, there never was a MPEG-3. That was the working name for the high definition version, but HD was added by extending MPEG-2 intstead.
There also isn't MPEG-5 or MPEG-6, or anything between MPEG-8 and MPEG-20, although MPEG-7 and MPEG-21 are both in development. Neither are directly video technologies, though. MPEG-7 is mainly an indexing and metadata structure, and MPEG-21 is a rich media architecture.
VP5 is hardly a shipping technology - they have a few (very impressive) movie trailers to look at, but the encoders aren't even supposed to be in beta before summer.
Also, codecs in QuickTime needs to support native packetization, to make hint tracks that the server needs to know how to optimially stream the file. Without a native packetizer, the codec won't be able to intelligently recover from a dropped packet.
There are only a handful of codec in QuickTime that support this today: Sorenson Video 2, Sorenson Video 3, H.261, H.263, PureVoice, and QDesign Music 2. The current On2 VP3 doesn't do this, nor does MP3 or Ogg (yet). Any competing new codec for Darwin Streaming Server will need to support those.
While there were Sorenson + Cleaner bundles when Cleaner was owned by Terran, I don't think Discreet has ever offered any bundles since they bought Cleaner from Media 100.
The new Spark codec (lite version in Flash MX, high quality version integrated into the Sorenson Squeeze compression tool) is going to be really important for Sorenson, certainly.
Do be a pedantic git, I'm compelled to point out that QuickTime is not a codec - it supports many, many codec, some open-source, some freely avaible, and some unique and propritary. Kind of like the difference between Linux and GNU.
For example a QuickTime movie encoded with MP3 and H.263 will play just fine inside of the Java Media Framework.
Codecs generally contain a lot of platform specific optimizations, and heavily leverage SIMD (AltiVec, SSE). They're also almost entirely CPU bound, and thus are a lot less sensitive to memory bandwidth and oher issues that high-end server machines have advantages with.
Not only is it a lot cheaper to encode on a G4, P4, or Athlon, one would expect it to be a heck of a lot faster as well.
The fractal codec was ClearVideo from Interated Systems. It was deprecated as of QuickTime 3.0, which included the Vector Quantization based Sorenson Video. That in turn was replaced by the all-new, much much improved Sorenson Video 3 as of QuickTime 5.0.2 last summer.
There is still a lot of lingering pre-SV3 content out there, but stuff made with the current versions is of enormously higher quality.
Well, the Darwin Streaming Server is certainly Open Source. Tarballs and everything. Check out http://www.darwin.org for it and Apple's other open source software.
Winodows Media has Intelligent Streaming, which can dynamically change the video data rate during a stream (but not the audio).
Darwin Streaming Server can also do some bandwidth thinning. For example, as data rate drops, a Sorenson stream can first drop B-frame (cutting frame rate in half and data rate by 25%), and then drop down to just keyframes.
Still, in terms of bandwidth negotiation, RealVideo is the leader, with Windows Media following closly, and QuickTime at the rear.
Apple has repeatedly expressed a willingness to port QuickTime to other platforms, if the vendor pays for it. Doing a QuickTime port of a quality of the MacOS or Windows product would require on the order of a hundred engineer-years. Remember, the port of QuickTime 3 to Windodws required reimplementing a huge portion of the MacOS toolbox on Windows, tying it into DirectX.
While it would be nice to have a Linux client, it certainly wouldn't make Apple any money. There are a lot of stuff QuickTime needs that I'd rather have the engineers work on (native B-frame support and multichannel audio are two big examples).
Plus, a Linux/UNIX port is a moving target. Framebuffers? X11? Different window managers? RPM? How many different target processors to optimize.
Remmber, QuickTime is on the order of complexity of the Linux kernel.
Re:I hope MPEG-4 fails
on
More on MPEG4
·
· Score: 1
Methinks you saw that troll in the mirror!
I haven't been with Media 100 for a year. I am Interframe Media, as courteously provided in the link next to my name above, and listed in the sig below.
I'm not sure what's with the citation above - I didn't write that Que Book. I am a contributing editor for DV Magazine, and am writing a book about video compression.
Re:I hope MPEG-4 fails
on
More on MPEG4
·
· Score: 1
Mixing video and film source at their native frame rates is very useful if you're dealing with content that is mixed film and video source. Like a "making of" documentary. It also isn't hard to do: you let each frame have its own duration, instead of having a global frame rate for the file. QuickTime had this working fine in 1991, on 20 MHz computers.
It's wrong to think of MPEG-4 as "a single standard" in the sense that any implementation needs to handle all of the spec. A given implementation only needs to handle the Profile@Level it targets, which vary wildly in complexity. ISMA Profile 0, targeting mobile devices, is very lightweight. Main Profile Level 5 isn't.
As for open source providing a those codecs, they probably will happen, eventually. If that's all you need, then you don't need MPEG-4.
But is that open-source codec going to work with new mobile phones from different vendors, over lossy networks?
Re:I hope MPEG-4 fails
on
More on MPEG4
·
· Score: 1
Sure, if all you want is to be able to make MPEG-1 files, but with better compression, MPEG-4 is far more of a solution than you need. DivX and similar tools do a nice job there, and if you don't need anything more, you don't need anything more.
MPEG-4 is meant to solve much more complex problems. You might want to read through the "MPEG-4 Applications" document, which describes what the design goals of MPEG-4, and sample ways to use it.
Take for example end-to-end video authoring and transmission (from editing, to compression, to satellite, to set top box, to your TV). MPEG-4 offers better compression than the existing MPEG-2 systems. Plus they can potentialy offer BIFS or Java to create interactive program guides and advertising as part of the real-time MPEG-4 stream. This is hard stuff - you need to be able to embed an applet in a potentially lossy transmission system. You need to have a sufficiently well defined standard that no one vendor controls compatibility specs, so that a new tool built on the standard, and tested with the standard test suite, has a good shot at 100% interoperability.
As for the toolbox metaphor, don't discount the importance of having a default file format, server, codec, etcetera to work with. Designing a good multimedia video format is hard, and even very smart people make all kinds of small mistakes with massive long-term ramifications. E.g., AVI and ASF can't mix sections of 29.97 and 24 fps content in a single file. Might not sound like a big deal, but it is a huge deal for some kinds of content.
In other markets, you want to be able to transmit wireless video to very low power devices over very lossy connections. And if you want to be able to do video conferencing, you need to be able to do it will very low overall latency, with a simple enough codec that you can do real-time encodng and decoding. And have synchronized audio.
So, no MPEG-4 is not a competitor to DivX in any way. DivX is an implementation of a small part of the standard.
Saying that MPEG-4 is overly complex is like saying the international phone system is overly complex because all you want to do is store compressed speech in a file on your computer. It may be overly complex for what you personally want to do, but not for the people who created it.
Also, remember the Profile@Level Structure. A simple ISMA Profile 1 encoder and decoder isn't that complex at all. There are going to be lots of lightweight applications for MPEG-4, and lots of heavyweight applications.
Re:Pay Per Minute for Non-Streaming Data
on
More on MPEG4
·
· Score: 2, Informative
Rememer, USERS aren't going to be paying the use fee. It's the folks providing the commerical streams that pay it. It's up to them to figure out how to get paid for it. If they can make the money via advertising, it'd still be free content to you.
Re:And how are they supposed to measure this?
on
More on MPEG4
·
· Score: 1
Two BIG points.
It's $0.02/hour, not per minute. That's a rounding error for most visual entertainment.
And you won't be charged directly. The fee is charged to folks doing streaming where they get money for it (either for you paying them, or running ads or something). If it's non-commericial, or doesn't have revenue attached, there isn't a fee.
So, what's likely to happen, is that you might pay $1 to watch an hour show ala PPV. And then the company you paid the $1 to sends two cents to MPEG-LA.
Transparent to the customer. This is NOT about micropayments.
Re:Who is buying this?
on
More on MPEG4
·
· Score: 1
Bear in mind that there are a LOT of different "MPEG-4 people" with different agenda. And there are a lot of different organizations.
The most important are the ISMA, the M4IF, and MPEG-LA. Licensing terms are from the MPEG-LA, which handles licensing. The head of the M4IF (MPEG-4 Industry Forum) has been leading a polite but effective discussion process outlining the issues with the proposed licensing. Apple, as one of the big movers behind the ISMA (Internet Streaming Media Alliance), is definitely fighting hard against the license fee.
And that isn't even counting the wireless folks.
"MPEG-4" is about as monolithic as "The Government," in that it's made out of a lot of different parties, at different levels, with different agendas that sometimes are aligned and sometimes not.
To to extent you must believe that corporate elites are trying to screw somebody, this is really about different corporate elites trying to screw each other.
But that isn't what's happening either.
Re:MPEG4 and Quicktime 5.x
on
More on MPEG4
·
· Score: 1
The actual announcement from Apple was that they were delaying the Preview release of QuickTime. This is equivalent to a public beta, and in the past has preceeded the release of the GM version of QuickTime by some months.
So, it's not like they're holding up their complete technology, just a public preview of it. If it were done, I'd assume Apple would just release QuickTime 6 without the MPEG-4 components.
They way they described it provides better leverage against MPEG-LA, of course, and bully for them.
Re:Standards and the great bandwagon
on
More on MPEG4
·
· Score: 2, Informative
I think you're speaking of just the initial Simple Visual Profile. MPEG-4 is extremely extensible, and we can expect new profiles to be added with new video codecs.
Today, MPEG-4 also includes Advanced Simple, with global motion compensation and some other features.
Also, H.26L is around the corner, and should be in some new MPEG-4 profiles in 2003. This codec includes a whole smorgasboard of new compression techniques, very competitive with the best propritary codecs.
Remember, MPEG-4 isn't a codec, any more than Linux is a web server.
Re:I hope MPEG-4 fails
on
More on MPEG4
·
· Score: 5, Informative
I'm the Ben Waggoner who was quoted in the article.
Actually, I wasn't saying it was TOO complex. While the entire standard certainly is complex, particular implementations only use a subset of those, based on a combination of Profiles and Levels.
The stuff most folks have been talking about, like the Simple Visual and Advanced Simple Visual used in the forthcoming QuickTime 6 and DivX 5.0 are only a really, really small part of the standard.
MPEG-4 is a big toolbox of features that can be used to build many different solutions, potentially competing or enhancing things like Flash, Shockwave, JPEG, streaming servers, movie projectors, video cameras, etcetera.
I view this as a real strength. Going forward anyone who needs to develop a new media tool can start with MPEG-4, instead of starting with scratch.
A good analogy would be how GNU and Linux are now a default port to all kinds of new and strange devices and tasks, because the building blocks are all there.
It's important that the open source community understand that building a real competitior to MPEG-4 is a task on the order of magnitude of building an OS from scratch.
Just being able to play a rectangular movie with audio isn't even scratching the surface.
Slashdot Mirror
Of course, in 2-3 years Tarkin will be competing against formats like H.26L, which is designed to be a use-fee-free international standard.
The target for H.26L is transparent compression of film content (read DVD) at 800 Kbps.
And of course, H.26L has been in development for several years, and has working code. It's much further along. Tarkin isn't even close to the point where we can start to guess what a real-world version's performance would even look like.
A nitpicky point - VP3 as implemented in AVI and QuickTime files is designed for progressive download, not true, real-time streaming. Thus, you get the classic movie trailer wait-awhile-and-play experience, but without the ability to do random access over long files and that kind of groovy stuff.
Good support for real-time streaming would require a native packetizer to build a hint track that the (open source) Darwin Streaming Server uses to determine packetization of the stream, and which helps loss recovery and other good stuff.
Adding a native packetizer for VP3 would be an excellent open source project for the codec.
VP5 is a very different beast than VP3 - there was a whole VP4 version between there. I doubt On2 is getting much in the way of benefit to VP5 from VP3 being open source. It's probably mainly a brand recognition thing to keep their name in the codec community while they prepare VP5 for launch.
Actually, the requirement in the old VP3 license was that you needed to maintain the ability to decode standard VP3 encoded files. It was perfectly kosher to add support for a new, enhanced/incompatible version, as long as the codec could still decode standard files.
Not really a big deal.
Of course, there are network effects on the manufacturing side, as mentioned in the articles. Motherboard chipsets being a good example. The higher volume of Intel solutions has meant that the motherboards can be cheaper at a given complexity. Fortunately, a CPU is a lot more expensive than the motherboard, and other components are the same (drives, cards, etcetera).
There is also some potential network effect in optimization for processor specific optimizations, like SSE v. 3DNow, since it makes sense to optimize more for the higher volume chip. I gather Hammer will have SSE2, so that'll simplify things on the SIMD side at least.
RealServer can in fact stream a hinted QuickTime movie via RTSP, with any codec.
What overunderunderdone meant to say is "more file format support."
Actually, there never was a MPEG-3. That was the working name for the high definition version, but HD was added by extending MPEG-2 intstead.
There also isn't MPEG-5 or MPEG-6, or anything between MPEG-8 and MPEG-20, although MPEG-7 and MPEG-21 are both in development. Neither are directly video technologies, though. MPEG-7 is mainly an indexing and metadata structure, and MPEG-21 is a rich media architecture.
VP5 is hardly a shipping technology - they have a few (very impressive) movie trailers to look at, but the encoders aren't even supposed to be in beta before summer.
Also, codecs in QuickTime needs to support native packetization, to make hint tracks that the server needs to know how to optimially stream the file. Without a native packetizer, the codec won't be able to intelligently recover from a dropped packet.
There are only a handful of codec in QuickTime that support this today: Sorenson Video 2, Sorenson Video 3, H.261, H.263, PureVoice, and QDesign Music 2. The current On2 VP3 doesn't do this, nor does MP3 or Ogg (yet). Any competing new codec for Darwin Streaming Server will need to support those.
Actually, the RealONE installer is smaller than RealPlayer 8 was, by about 2MB
It's a lot more visually bloated, though.
While there were Sorenson + Cleaner bundles when Cleaner was owned by Terran, I don't think Discreet has ever offered any bundles since they bought Cleaner from Media 100.
The new Spark codec (lite version in Flash MX, high quality version integrated into the Sorenson Squeeze compression tool) is going to be really important for Sorenson, certainly.
Do be a pedantic git, I'm compelled to point out that QuickTime is not a codec - it supports many, many codec, some open-source, some freely avaible, and some unique and propritary. Kind of like the difference between Linux and GNU.
For example a QuickTime movie encoded with MP3 and H.263 will play just fine inside of the Java Media Framework.
Codecs generally contain a lot of platform specific optimizations, and heavily leverage SIMD (AltiVec, SSE). They're also almost entirely CPU bound, and thus are a lot less sensitive to memory bandwidth and oher issues that high-end server machines have advantages with.
Not only is it a lot cheaper to encode on a G4, P4, or Athlon, one would expect it to be a heck of a lot faster as well.
The fractal codec was ClearVideo from Interated Systems. It was deprecated as of QuickTime 3.0, which included the Vector Quantization based Sorenson Video. That in turn was replaced by the all-new, much much improved Sorenson Video 3 as of QuickTime 5.0.2 last summer.
There is still a lot of lingering pre-SV3 content out there, but stuff made with the current versions is of enormously higher quality.
Well, the Darwin Streaming Server is certainly Open Source. Tarballs and everything. Check out http://www.darwin.org for it and Apple's other open source software.
Not entirely true.
Winodows Media has Intelligent Streaming, which can dynamically change the video data rate during a stream (but not the audio).
Darwin Streaming Server can also do some bandwidth thinning. For example, as data rate drops, a Sorenson stream can first drop B-frame (cutting frame rate in half and data rate by 25%), and then drop down to just keyframes.
Still, in terms of bandwidth negotiation, RealVideo is the leader, with Windows Media following closly, and QuickTime at the rear.
Apple has repeatedly expressed a willingness to port QuickTime to other platforms, if the vendor pays for it. Doing a QuickTime port of a quality of the MacOS or Windows product would require on the order of a hundred engineer-years. Remember, the port of QuickTime 3 to Windodws required reimplementing a huge portion of the MacOS toolbox on Windows, tying it into DirectX.
While it would be nice to have a Linux client, it certainly wouldn't make Apple any money. There are a lot of stuff QuickTime needs that I'd rather have the engineers work on (native B-frame support and multichannel audio are two big examples).
Plus, a Linux/UNIX port is a moving target. Framebuffers? X11? Different window managers? RPM? How many different target processors to optimize.
Remmber, QuickTime is on the order of complexity of the Linux kernel.
Methinks you saw that troll in the mirror!
I haven't been with Media 100 for a year. I am Interframe Media, as courteously provided in the link next to my name above, and listed in the sig below.
I'm not sure what's with the citation above - I didn't write that Que Book. I am a contributing editor for DV Magazine, and am writing a book about video compression.
Mixing video and film source at their native frame rates is very useful if you're dealing with content that is mixed film and video source. Like a "making of" documentary. It also isn't hard to do: you let each frame have its own duration, instead of having a global frame rate for the file. QuickTime had this working fine in 1991, on 20 MHz computers.
It's wrong to think of MPEG-4 as "a single standard" in the sense that any implementation needs to handle all of the spec. A given implementation only needs to handle the Profile@Level it targets, which vary wildly in complexity. ISMA Profile 0, targeting mobile devices, is very lightweight. Main Profile Level 5 isn't.
As for open source providing a those codecs, they probably will happen, eventually. If that's all you need, then you don't need MPEG-4.
But is that open-source codec going to work with new mobile phones from different vendors, over lossy networks?
Sure, if all you want is to be able to make MPEG-1 files, but with better compression, MPEG-4 is far more of a solution than you need. DivX and similar tools do a nice job there, and if you don't need anything more, you don't need anything more.
MPEG-4 is meant to solve much more complex problems. You might want to read through the "MPEG-4 Applications" document, which describes what the design goals of MPEG-4, and sample ways to use it.
Take for example end-to-end video authoring and transmission (from editing, to compression, to satellite, to set top box, to your TV). MPEG-4 offers better compression than the existing MPEG-2 systems. Plus they can potentialy offer BIFS or Java to create interactive program guides and advertising as part of the real-time MPEG-4 stream. This is hard stuff - you need to be able to embed an applet in a potentially lossy transmission system. You need to have a sufficiently well defined standard that no one vendor controls compatibility specs, so that a new tool built on the standard, and tested with the standard test suite, has a good shot at 100% interoperability.
As for the toolbox metaphor, don't discount the importance of having a default file format, server, codec, etcetera to work with. Designing a good multimedia video format is hard, and even very smart people make all kinds of small mistakes with massive long-term ramifications. E.g., AVI and ASF can't mix sections of 29.97 and 24 fps content in a single file. Might not sound like a big deal, but it is a huge deal for some kinds of content.
In other markets, you want to be able to transmit wireless video to very low power devices over very lossy connections. And if you want to be able to do video conferencing, you need to be able to do it will very low overall latency, with a simple enough codec that you can do real-time encodng and decoding. And have synchronized audio.
So, no MPEG-4 is not a competitor to DivX in any way. DivX is an implementation of a small part of the standard.
Saying that MPEG-4 is overly complex is like saying the international phone system is overly complex because all you want to do is store compressed speech in a file on your computer. It may be overly complex for what you personally want to do, but not for the people who created it.
Also, remember the Profile@Level Structure. A simple ISMA Profile 1 encoder and decoder isn't that complex at all. There are going to be lots of lightweight applications for MPEG-4, and lots of heavyweight applications.
Rememer, USERS aren't going to be paying the use fee. It's the folks providing the commerical streams that pay it. It's up to them to figure out how to get paid for it. If they can make the money via advertising, it'd still be free content to you.
Two BIG points.
It's $0.02/hour, not per minute. That's a rounding error for most visual entertainment.
And you won't be charged directly. The fee is charged to folks doing streaming where they get money for it (either for you paying them, or running ads or something). If it's non-commericial, or doesn't have revenue attached, there isn't a fee.
So, what's likely to happen, is that you might pay $1 to watch an hour show ala PPV. And then the company you paid the $1 to sends two cents to MPEG-LA.
Transparent to the customer. This is NOT about micropayments.
Bear in mind that there are a LOT of different "MPEG-4 people" with different agenda. And there are a lot of different organizations.
The most important are the ISMA, the M4IF, and MPEG-LA. Licensing terms are from the MPEG-LA, which handles licensing. The head of the M4IF (MPEG-4 Industry Forum) has been leading a polite but effective discussion process outlining the issues with the proposed licensing. Apple, as one of the big movers behind the ISMA (Internet Streaming Media Alliance), is definitely fighting hard against the license fee.
And that isn't even counting the wireless folks.
"MPEG-4" is about as monolithic as "The Government," in that it's made out of a lot of different parties, at different levels, with different agendas that sometimes are aligned and sometimes not.
To to extent you must believe that corporate elites are trying to screw somebody, this is really about different corporate elites trying to screw each other.
But that isn't what's happening either.
The actual announcement from Apple was that they were delaying the Preview release of QuickTime. This is equivalent to a public beta, and in the past has preceeded the release of the GM version of QuickTime by some months.
So, it's not like they're holding up their complete technology, just a public preview of it. If it were done, I'd assume Apple would just release QuickTime 6 without the MPEG-4 components.
They way they described it provides better leverage against MPEG-LA, of course, and bully for them.
I think you're speaking of just the initial Simple Visual Profile. MPEG-4 is extremely extensible, and we can expect new profiles to be added with new video codecs.
Today, MPEG-4 also includes Advanced Simple, with global motion compensation and some other features.
Also, H.26L is around the corner, and should be in some new MPEG-4 profiles in 2003. This codec includes a whole smorgasboard of new compression techniques, very competitive with the best propritary codecs.
Remember, MPEG-4 isn't a codec, any more than Linux is a web server.
I'm the Ben Waggoner who was quoted in the article.
Actually, I wasn't saying it was TOO complex. While the entire standard certainly is complex, particular implementations only use a subset of those, based on a combination of Profiles and Levels.
The stuff most folks have been talking about, like the Simple Visual and Advanced Simple Visual used in the forthcoming QuickTime 6 and DivX 5.0 are only a really, really small part of the standard.
MPEG-4 is a big toolbox of features that can be used to build many different solutions, potentially competing or enhancing things like Flash, Shockwave, JPEG, streaming servers, movie projectors, video cameras, etcetera.
I view this as a real strength. Going forward anyone who needs to develop a new media tool can start with MPEG-4, instead of starting with scratch.
A good analogy would be how GNU and Linux are now a default port to all kinds of new and strange devices and tasks, because the building blocks are all there.
It's important that the open source community understand that building a real competitior to MPEG-4 is a task on the order of magnitude of building an OS from scratch.
Just being able to play a rectangular movie with audio isn't even scratching the surface.