Indeed..divx is NOT a MPEG-4 compatible file format. It is MPEG-4 video and MP3 audio in a.AVI file. Now, QuickTIme knows how to play MPEG-4 video, and MP3 audio, and AVI files, so it might work, but it won't work because of QuickTime's.mp4 compatibility.
QuickTime's MPEG-4 playback doesn't do B-frames (so that only every other frame of a B-frame encoded file will be shown). Folks targeing QT playback with.divx shouldn't use those (GMC and quarter pel motion estimation are just fine, and quarter pel especially has a good quality boost).
Interesting link. However, he says that he hasn't looked at the file format since 1996! Lots of useful additions since then. Perhaps the most relevant to this discussion was the addition of the hint track, which provides a way to turn existing files into real-time streamable files via RTP/RTSP. Ideally, you'll have a native packetizer for loss recovery, but it'll even work on older files.
Since we already have the open-source Darwin Streaming Server that can use hint tracks, this could make real time streaming an almost free win for this format.
And, of course, full VBR support for both audio and video are included in the current version.
From reading the announcement, I don't have much idea what file format this is going to use..ogg as I understand it is really designed as an audio codec/format; I'm not sure how easy it would be to add video samples to it, usefully.
If they're looking to still pick a format, I hope they do QuickTime. QuickTime's file format itself is open and documented, and there are a number of open source projects to implement it. As of QT6, QuickTime itself now has native support for VBR audio encoding, which makes it easier to do an Ogg encoder inside QT (VBR decode has been in there since 4.1).
http://developer.apple.com/techpubs/quicktime/qt de vdocs/PDF/QTFileFormat.pdf
With QuickTime support, one immediately inherits a wide installed base of players, and lots of functionality. For example, real time streaming support is availble via the open source Darwin Streaming Server. The codecs just need to have a native packetizer added.
The nice thing about implementing Theora as a QuickTime file would mean folks would have the option of using high-end QuickTime encoding apps like Cleaner for encoding, and generally letting the files work well in both the closed and open source universes.
VP3 is of course already implemented in QuickTime so doing this would mainly be a matter of finishing the Ogg port as a QuickTime codec:
There was no MPEG-3. That was the working name for the original high definition MPEG format. However, they decided that they could implement HD with extensions to MPEG-2. Thus, MPEG-2 is used in HDTV, and there is no MPEG-3.
MPEG-4 is the new video/audio/streaming/etcetera standard.
MPEG-7 is a forthcoming media metadata format. It doesn't include video compression technology. You'd still use MPEG-4 codecs within MPEG-7, or even use non MPEG codecs.
(The official link is broken right now)
No MPEG-8 through MPEG-20, at least not yet.
MPEG-21 is a multimedia authoring and delivery format. It's in very early stages, but think more like a competitor to Flash MX, writ large. We're some years from seeing products based on it.
Windows Media Player on both MacOS X and PocketPC lacks the ACELP.net speech codec. Microsoft licenses it from a third party, who hasn't ported it to those.
To make a WMV file that works on those platforms, it needs to be encoded with the Windows Media Audio codec, which is available in all versions of the player.
The lack of the middleware media layer that applications rely on is certainly a substantial issue with doing a lot of authoring on Linux. QuickTime is a great example of this, and DirectShow does similar but more limited things under Windows.
While QuickTime is mainly discussed as a compression technology, it is important in a lot of other ways in the authoring industry. Many major video applications use QuickTime as an API for video capture, editing, compositing, etcetera. Avid, Media 100, After Effects, Premiere, CineStream, Cleaner, Squeeze, HipFlics, and many others all use QuickTime. Probably 80% of everything you see on TV was a QuickTime file at at least one point in the authoring processs. And QuickTime's depth is hugely underestimated for those who look at it merely as a player technology.
One great example of QuickTime is the reference movie. This is a movie that is made up of references to media in other files, potentially with transforms attached to it. Think of it like a frameserver, but with all the information needed to serve living in a media file itself, without any requirement for another application.
Describing Apple's attitude as "refuses to port" is erroneous. Apple's response to a number of UNIX vendors over the years has been "We're happy to port QuickTime to UNIX, but you'll have to pay for it." It'd be at least $20M for Apple to do, and probably many times that. And then there is the ongoing testing. Apple does regression
There is a huge amount of low-level things that QuickTime relies on, like low latency access to sound cards, Y'CrCb native blitting to video cards, etcetera. Even if they did port it, it would probably only work on distributions it specifically targeted which had the stuff in the kernel it needed. And there is a TON of machine-specific optimization in there - this isn't a GCC and Go kind of thing.
I started Fallout on a consulting trip to LEGO* in Billund, Denmark. I stayed in the mildly trippy Legoland hotel, but it was February and the park itself wasn't open, so there wasn't much else to do at night with jet-lag induced insomnia.
On my then-beefy G3 300 PowerBook, Fallout had the most remarkable save and load times, like 2 whole minutes. It was so bad that I wouldn't save for hours, and when I died, I minded the load time from my previous save even more than the fact I had to redo so much stuff.
The other thing I remember vividly about the game is when I was skilled enough to have 95% of hitting someone in the eye with the Plasma Rifle at a pretty long range. Plasma sniping!
If they get the save times down to something reasonable, I'd love to check it out again.
*(I was there desiging the video compression workflow for the original MindStorms CD-ROM cut scenes and tutorial videos. LEGO was an amazing place back then. One guy I knew told his boss he wanted to learn animation, and he had a dual-processor Octane with the full PowerAnimator a week later).
Well, yes, Panasonic's DVCPRO-HD uses a Y'CrCb 4:2:0 DCT compression. It's a pretty light compression, so real-world content shouldn't so any artifacts.
I just finished writing an article for DV Magazine about FireWire yesterday, so I've got this on the brain.
While USB2 does have a theoretical maximum data rate of 480 Mbps compared to 400 Mpbs with FireWire, FireWire does a much better job of time-critical streaming with its isochronous mode. Thus you can actually use a much higher percentage of the theoretical bandwidth with FireWire.
Of course, we're talking 400 freaking Mbps here. A real-time stream of DV is only 25. Maxed out MP3 files are 0.32 Mbps. Heck, Panasonic is going to have 1280x720 HD decks that use FireWire later this year, and THAT is only 100 Mbps.
USB2 also has less bus power than FireWire, so it can't charge bus-charged devices like the iPod as quickly.
Also, while 1394b is coming, the name Gigawire is purely theoretical.
1394b includes faster speeds over copper and optical connections (800 Mbps initially, with 1600 and 3200 coming), with run lengths up to 100 meters. It'll also do 100 Mbps over CAT-5, so you can route real-time video over existing wiring.
There will be two new connector types. Bilingual cables will hook up to both legacy 1394 devices and 1394b. This means you can mix and match 1394 and 1394a devices and computers. There will also be the beta connector for 1394b only applications (not beta for "non-quite-done" but for the b in 1394b). There won't be any more of the 4-pin v 6-pin confusion in 1394b, thankfully. As long as you don't have any beta-only stuff, you can just use normal 6-pin FireWire cables for all your stuff.
Of course, QuickTime 6 only implements the ISMA Profile 0 and 1 of MPEG-4, which doesn't include any compositing features. Layering and such is mainly seen in Main profile. Envivio does make a Main Profile MPEG-4 plug-in for QuickTime for Windows.
Support for non-ISMA profiles, or later ISMA profiles, might be coming in QT7, eventually.
QuickTime 2 was the first version for Windows. It was playback only - authoring required a Mac. It wasn't really a port, just a player library that could do QT files.
QuickTime 3 for Windows was a ground-up new version that supported Authoring. Since QuickTime for Mac had huge dependcies on the underlying MacOS "Toolbox" for QT3 for Windows they actually ported over a huge portion of the MacOS APIs so it could run. It was complete enough that Apple had to specifically request software vendors not use QuickTime as a Mac to Windows porting library. And some still did, like Media Cleaner Pro 4.
QuickTime is a whole media architecture. It does compression, sure, but lots of other stuff. It is a major enabling technology for video editing, and also does panoramas, audio playback, etcetera. Its complexity is on the same order of magnitude as the Linux kernel.
Apple doesn't get any money from QuickTime licenseing. While you need to license the installer from them, it is free as in beer. You just need to send them two copies of your disc for regression testing against new versions of QT.
QuickTime for MacOS X is Carbon, which means it uses the port of the Mac toolbox for MacOS X (in the same way it uses is own internal port on Windows). Porting it to Linux would require porting this as well. This is far from trivial - QuickTime needs to talk directly to low level hardware like sound cards, clocks, video cards, etcetera. This aren't things that are well unified under Linux. QuickTime is extremely heavily tested by a large testing team. So even if they did it, they'd have to pick a few Linux flavors to test against. The kinds of things QuickTime does are the kinds of things that break on random distributions.
I've heard that the Windows port took something over 100 engineer years, and I imagine Linux would take at least as many. That's, VERY rough ballpark, $20M.
Think Apple could see an additional $20M in net revenue from having a Linux port?
A.Divx file made by Divx 5.xis structurally an AVI file, with MPEG-4 Simple or Advanced Simple video and normally MP3 audio.
QuickTime 6 knows how to read AVI files, MPEG-4 video, and MP3 audio, so hopefully it could play the file. I'll check once it's downloaded and installed.
Note earlier versions of Divx were based on proprietary Microsoft binaries, so those wouldn't ever run under QuickTime.
Divx 5.0.2 does have a command-line option to make a.mp4 file. However, I don't think it knows how to make MPEG-4 audio (either AAC or CELP).
AAC is Advanced Audio Coding. it was actually created by Dolby Labs, with help from Sony, AT&T, and Fraunhofer.
And yes, it is really quite excellent. I'd say a 64 Kbps AAC is typically comparable to a 128 Kbps MP3, although it is somewhat dependent on content. I really, really hope that a future version of the iPod and other mobile devices support it.
I have have plenty of.mp2 files lying around, downloaded from the paleolithic music web site Addicted to Noise, back before MP3 took off..mp2 files are normally MPEG-1 Layer II audio, like used in most MPEG-1 files.
I've also seen some MPEG-2 video files using that extension as well.
Three characters really aren't enough for meaningful extensions, eh?
MPEG-4 uses a Profile@Level structure, which strictly defines what codecs and parameters a given file can use. For example, QuickTime can export a compliant ISMA Profile 1 MPEG-1 file. This mandates the MPEG-4 Advanced Simple Video codec, either ACELP or AAC audio, maximum 352x288 resolution, and certain data rate limits.
ANY MPEG-4 player which claims to be ISMA compliant needs to be able to play this file, and QuickTime needs to be able to play an ISMA compatible MPEG-4 file created by a different vendor.
The whole point of MPEG-4 is interoperability - if that doesn't work, than the technology won't either.
For the Linux crowd, this means a MPEG-4 file will be as easy to play as a MPEG-1 is today, but with much, much improved quality at a given data rate, and support for real-time streaming. You can stop yelling at Apple about porting QuickTime, since you'll just use someone else's MPEG-4 player with their content, and it'll just work.
The risk is that support for Profile@Level combinations will vary. Certainly, a lot of cell phones use ISMA Profile 0, which means 176x144 maximum resolution, the Simple instead of Advanced Simple codec, etcetera. And there are more advanced codecs coming down the pike that improve quality, but won't work with today's ISMA profiles.
But hey, nothing that folks who deal with RPMs all day don't know about.
Actually, MP3 is MPEG-1 Layer III. Ironically, MP3 was never used for MPEG-1 files because of the licensing issues that later affected MP3.
I expect the big reason for ".mp4" instead of ".mpeg4" is for compatibility with 8.3 filename filesystems. Bear in mind that the MPEG-4 process was started BEFORE Windows 95 shipped.
Fast start is actually a result of better managing the buffer between the streaming server and the client. What it does is tell the player to start playing as soon as the first frame has been transmitted, instead of waiting for the usual few seconds of buffering. This only works if you have significantly more bandwidth available than the stream requires, so it won't help with modem stuff much. It works with any codec, not just MPEG-4.
Also, RealONE already supports the Envivio plug-in for MPEG-4 playback. PacketVideo and Philips also have MPEG-4 players available.
QuickTime 6 does represents the first mass-market MPEG-4 authoring, distribution, and playback system. This is a Good Thing.
G4s are wicked fast for MP3 encoding, due to AltiVec. My ancient G4 400 CD jukebox can rip at 10x without breaking a sweat, and it might even be disc-speed bound at that point.
And games can use a LOT of vector processing as well, if properly optimized. id software once said that the G4 was the fastest computer they had seen for 3D performance w/o hardware T&L or geometry (like the Rage 128 era).
Kernel compiles aren't helped much, although SIMD can do some fast string manipulation stuff as well.
Given how everyone always trumpets how fast their extreme gaming systems are, it's sad we don't here more about extreme slow gaming.
Sure, playing through Quake at 180 fps is cool, but winning Quake at 5 fps, ah, now that's a challenge.
My greatest act of low-powered gaming was winning Unreal on a PowerBook G3 300. This was MacOS 8.6 or so, with manual memory management and everything. I had to create a custom Extensions set boot mode to even get enough free memory to launch Unreal.
The two most challenging aspect were graphics and controls. The Rage Pro was very aenemic, and I was lucky to get 15 fps out of it. And I had to use hardware scaling, since the LCD was 1024x768, and the card could barely do 3D at 640x480. Also, it had to run in 16-bit mode, which those old ATI card had huge dithering problems in. So it was kind of like watching a blocky yet blurred filmstrip in a snowstorm.
Controls? Well, of course, the keyboard and, wait for it, the trackpad! No mouse for me! If you haven't played through a first person shooter using a trackpad for aim, you haven't lived, at least not lived badly.
The nice thing about this is that you can play in bed when your girlfriend is asleep. The startling thing was she actually married me even after that.
Is the question really whether life begins, or HUMAN life beings at conception? I don't see too many vegetarian abortion protesters.
We make, appropriately, a distinction between the kind of life we protect (human life), and that we don't. The distinction between them is enormously difficult to parse, without any obvious way to discriminate. PETA certainly hold that most animals deserve protection similar to humans. Others don't.
It has been argued that the capacity to suffer is the defining test, which means, say, protecting a dog is more important than a human in a persistent (irreversible) vegetative state. By that measure, an early stage embryo certainly doesn't qualify.
Now, if it's the POTENTIAL for sentience that matters, then you can claim that the human embryo is more important than, say, the adult chimp. However, does that mean that every unnoticed miscarrage of a 4-week old embryo is as tragic as an adult death? However about every unfertilized egg that goes to waste every 28 days?
The reasons why we don't have any consensus on these issues is that there aren't obvious answers. In the end, they'll be decided like most bioethical questions: by finding pragmatic answers to specific questions.
The questions that actually get answered aren't going to be "Cloning: good or bad." But "this particular model of stem cell treatment for Parkinsons: good or bad."
In the course of medicine, even in the lifetimes of our grandparents, many questions that seemed deeply philosophical turned out to have relatively simple answers. It wasn't long ago that we thought:
Death was synonymous with the heart stopping beating.
Hardly. The only thing open about the codec is the decoder, and that's only as open as Flash in general. No one charges for decoders for web formats - nothing new here.
The Spark Pro encoder is only available with Sorenson's Squeeze for Flash MX product, which they sell. It's a good piece of software, and worth the money for those doing professional Flash creation. The free Spark encoder built into Flash MX can work for simple projects, but doesn't come close to Spark Pro for mission critical quality.
Apple is actually backing MPEG-4 hard, which is much closer to an open standard than Sorenson's codecs.
Actually, the current Windows Media Player 7.1 for MacOS X is pretty darn sweet. it doesn't support the ACELP.net speech codec, but it does a fine job with any file using Windows Media Video and Windows Media Audio.
Real has stated that the forthcoming RealONE Player for MacOS will be MacOS X native. Maybe summer?
Hopefully it'll have better performance than RealPlayer 8 does under MacOS 9.x. Real has blamed the classic MacOS memory model for this, which obviously isn't a problem under X.
Slashdot Mirror
Indeed. .divx is NOT a MPEG-4 compatible file format. It is MPEG-4 video and MP3 audio in a .AVI file. Now, QuickTIme knows how to play MPEG-4 video, and MP3 audio, and AVI files, so it might work, but it won't work because of QuickTime's .mp4 compatibility.
.divx shouldn't use those (GMC and quarter pel motion estimation are just fine, and quarter pel especially has a good quality boost).
QuickTime's MPEG-4 playback doesn't do B-frames (so that only every other frame of a B-frame encoded file will be shown). Folks targeing QT playback with
Interesting link. However, he says that he hasn't looked at the file format since 1996! Lots of useful additions since then. Perhaps the most relevant to this discussion was the addition of the hint track, which provides a way to turn existing files into real-time streamable files via RTP/RTSP. Ideally, you'll have a native packetizer for loss recovery, but it'll even work on older files.
Since we already have the open-source Darwin Streaming Server that can use hint tracks, this could make real time streaming an almost free win for this format.
And, of course, full VBR support for both audio and video are included in the current version.
From reading the announcement, I don't have much idea what file format this is going to use. .ogg as I understand it is really designed as an audio codec/format; I'm not sure how easy it would be to add video samples to it, usefully.
t de vdocs/PDF/QTFileFormat.pdf
If they're looking to still pick a format, I hope they do QuickTime. QuickTime's file format itself is open and documented, and there are a number of open source projects to implement it. As of QT6, QuickTime itself now has native support for VBR audio encoding, which makes it easier to do an Ogg encoder inside QT (VBR decode has been in there since 4.1).
http://developer.apple.com/techpubs/quicktime/q
With QuickTime support, one immediately inherits a wide installed base of players, and lots of functionality. For example, real time streaming support is availble via the open source Darwin Streaming Server. The codecs just need to have a native packetizer added.
The nice thing about implementing Theora as a QuickTime file would mean folks would have the option of using high-end QuickTime encoding apps like Cleaner for encoding, and generally letting the files work well in both the closed and open source universes.
VP3 is of course already implemented in QuickTime so doing this would mainly be a matter of finishing the Ogg port as a QuickTime codec:
http://qtcomponents.sourceforge.net/
Not entirely true.
VP4 was a set top box codec. It was never released in any form for computer-based playback.
VP5 hasn't yet been released. I don't know what On2's plans are with it.
There was no MPEG-3. That was the working name for the original high definition MPEG format. However, they decided that they could implement HD with extensions to MPEG-2. Thus, MPEG-2 is used in HDTV, and there is no MPEG-3.
- 4/ mpeg-4.htm
- 21 / peg-21.htm
MPEG-4 is the new video/audio/streaming/etcetera standard.
http://mpeg.telecomitalialab.com/standards/mpeg
There are no MPEG-5 or MPEG-6
MPEG-7 is a forthcoming media metadata format. It doesn't include video compression technology. You'd still use MPEG-4 codecs within MPEG-7, or even use non MPEG codecs.
(The official link is broken right now)
No MPEG-8 through MPEG-20, at least not yet.
MPEG-21 is a multimedia authoring and delivery format. It's in very early stages, but think more like a competitor to Flash MX, writ large. We're some years from seeing products based on it.
http://mpeg.telecomitalialab.com/standards/mpeg
Windows Media Player on both MacOS X and PocketPC lacks the ACELP.net speech codec. Microsoft licenses it from a third party, who hasn't ported it to those.
To make a WMV file that works on those platforms, it needs to be encoded with the Windows Media Audio codec, which is available in all versions of the player.
The lack of the middleware media layer that applications rely on is certainly a substantial issue with doing a lot of authoring on Linux. QuickTime is a great example of this, and DirectShow does similar but more limited things under Windows.
While QuickTime is mainly discussed as a compression technology, it is important in a lot of other ways in the authoring industry. Many major video applications use QuickTime as an API for video capture, editing, compositing, etcetera. Avid, Media 100, After Effects, Premiere, CineStream, Cleaner, Squeeze, HipFlics, and many others all use QuickTime. Probably 80% of everything you see on TV was a QuickTime file at at least one point in the authoring processs. And QuickTime's depth is hugely underestimated for those who look at it merely as a player technology.
One great example of QuickTime is the reference movie. This is a movie that is made up of references to media in other files, potentially with transforms attached to it. Think of it like a frameserver, but with all the information needed to serve living in a media file itself, without any requirement for another application.
Describing Apple's attitude as "refuses to port" is erroneous. Apple's response to a number of UNIX vendors over the years has been "We're happy to port QuickTime to UNIX, but you'll have to pay for it." It'd be at least $20M for Apple to do, and probably many times that. And then there is the ongoing testing. Apple does regression
There is a huge amount of low-level things that QuickTime relies on, like low latency access to sound cards, Y'CrCb native blitting to video cards, etcetera. Even if they did port it, it would probably only work on distributions it specifically targeted which had the stuff in the kernel it needed. And there is a TON of machine-specific optimization in there - this isn't a GCC and Go kind of thing.
I started Fallout on a consulting trip to LEGO* in Billund, Denmark. I stayed in the mildly trippy Legoland hotel, but it was February and the park itself wasn't open, so there wasn't much else to do at night with jet-lag induced insomnia.
On my then-beefy G3 300 PowerBook, Fallout had the most remarkable save and load times, like 2 whole minutes. It was so bad that I wouldn't save for hours, and when I died, I minded the load time from my previous save even more than the fact I had to redo so much stuff.
The other thing I remember vividly about the game is when I was skilled enough to have 95% of hitting someone in the eye with the Plasma Rifle at a pretty long range. Plasma sniping!
If they get the save times down to something reasonable, I'd love to check it out again.
*(I was there desiging the video compression workflow for the original MindStorms CD-ROM cut scenes and tutorial videos. LEGO was an amazing place back then. One guy I knew told his boss he wanted to learn animation, and he had a dual-processor Octane with the full PowerAnimator a week later).
Well, yes, Panasonic's DVCPRO-HD uses a Y'CrCb 4:2:0 DCT compression. It's a pretty light compression, so real-world content shouldn't so any artifacts.
I just finished writing an article for DV Magazine about FireWire yesterday, so I've got this on the brain.
While USB2 does have a theoretical maximum data rate of 480 Mbps compared to 400 Mpbs with FireWire, FireWire does a much better job of time-critical streaming with its isochronous mode. Thus you can actually use a much higher percentage of the theoretical bandwidth with FireWire.
Of course, we're talking 400 freaking Mbps here. A real-time stream of DV is only 25. Maxed out MP3 files are 0.32 Mbps. Heck, Panasonic is going to have 1280x720 HD decks that use FireWire later this year, and THAT is only 100 Mbps.
USB2 also has less bus power than FireWire, so it can't charge bus-charged devices like the iPod as quickly.
Also, while 1394b is coming, the name Gigawire is purely theoretical.
1394b includes faster speeds over copper and optical connections (800 Mbps initially, with 1600 and 3200 coming), with run lengths up to 100 meters. It'll also do 100 Mbps over CAT-5, so you can route real-time video over existing wiring.
There will be two new connector types. Bilingual cables will hook up to both legacy 1394 devices and 1394b. This means you can mix and match 1394 and 1394a devices and computers. There will also be the beta connector for 1394b only applications (not beta for "non-quite-done" but for the b in 1394b). There won't be any more of the 4-pin v 6-pin confusion in 1394b, thankfully. As long as you don't have any beta-only stuff, you can just use normal 6-pin FireWire cables for all your stuff.
Of course, QuickTime 6 only implements the ISMA Profile 0 and 1 of MPEG-4, which doesn't include any compositing features. Layering and such is mainly seen in Main profile. Envivio does make a Main Profile MPEG-4 plug-in for QuickTime for Windows.
Support for non-ISMA profiles, or later ISMA profiles, might be coming in QT7, eventually.
Everything you said is wrong :).
QuickTime 2 was the first version for Windows. It was playback only - authoring required a Mac. It wasn't really a port, just a player library that could do QT files.
QuickTime 3 for Windows was a ground-up new version that supported Authoring. Since QuickTime for Mac had huge dependcies on the underlying MacOS "Toolbox" for QT3 for Windows they actually ported over a huge portion of the MacOS APIs so it could run. It was complete enough that Apple had to specifically request software vendors not use QuickTime as a Mac to Windows porting library. And some still did, like Media Cleaner Pro 4.
QuickTime is a whole media architecture. It does compression, sure, but lots of other stuff. It is a major enabling technology for video editing, and also does panoramas, audio playback, etcetera. Its complexity is on the same order of magnitude as the Linux kernel.
Apple doesn't get any money from QuickTime licenseing. While you need to license the installer from them, it is free as in beer. You just need to send them two copies of your disc for regression testing against new versions of QT.
QuickTime for MacOS X is Carbon, which means it uses the port of the Mac toolbox for MacOS X (in the same way it uses is own internal port on Windows). Porting it to Linux would require porting this as well. This is far from trivial - QuickTime needs to talk directly to low level hardware like sound cards, clocks, video cards, etcetera. This aren't things that are well unified under Linux. QuickTime is extremely heavily tested by a large testing team. So even if they did it, they'd have to pick a few Linux flavors to test against. The kinds of things QuickTime does are the kinds of things that break on random distributions.
I've heard that the Windows port took something over 100 engineer years, and I imagine Linux would take at least as many. That's, VERY rough ballpark, $20M.
Think Apple could see an additional $20M in net revenue from having a Linux port?
Being a Big Fat Geek, 5 MHz immediately popped into my head. My long-retired Palm Pro put it to shame.
Y'know, we need a term, measuring the time between when a personal computer comes out, and an equally powerful handheld comes out.
Y'know
Apple IIc -> Some HP calculator
Mac SE -> Palm Pro
AMD K6 -> iPaq
The gap is getting smaller. Wonder when my phone will have a 500 MHz G4.
A .Divx file made by Divx 5.xis structurally an AVI file, with MPEG-4 Simple or Advanced Simple video and normally MP3 audio.
.mp4 file. However, I don't think it knows how to make MPEG-4 audio (either AAC or CELP).
QuickTime 6 knows how to read AVI files, MPEG-4 video, and MP3 audio, so hopefully it could play the file. I'll check once it's downloaded and installed.
Note earlier versions of Divx were based on proprietary Microsoft binaries, so those wouldn't ever run under QuickTime.
Divx 5.0.2 does have a command-line option to make a
AAC is Advanced Audio Coding. it was actually created by Dolby Labs, with help from Sony, AT&T, and Fraunhofer.
And yes, it is really quite excellent. I'd say a 64 Kbps AAC is typically comparable to a 128 Kbps MP3, although it is somewhat dependent on content. I really, really hope that a future version of the iPod and other mobile devices support it.
I have have plenty of .mp2 files lying around, downloaded from the paleolithic music web site Addicted to Noise, back before MP3 took off. .mp2 files are normally MPEG-1 Layer II audio, like used in most MPEG-1 files.
I've also seen some MPEG-2 video files using that extension as well.
Three characters really aren't enough for meaningful extensions, eh?
Er? Not even close.
MPEG-4 uses a Profile@Level structure, which strictly defines what codecs and parameters a given file can use. For example, QuickTime can export a compliant ISMA Profile 1 MPEG-1 file. This mandates the MPEG-4 Advanced Simple Video codec, either ACELP or AAC audio, maximum 352x288 resolution, and certain data rate limits.
ANY MPEG-4 player which claims to be ISMA compliant needs to be able to play this file, and QuickTime needs to be able to play an ISMA compatible MPEG-4 file created by a different vendor.
The whole point of MPEG-4 is interoperability - if that doesn't work, than the technology won't either.
For the Linux crowd, this means a MPEG-4 file will be as easy to play as a MPEG-1 is today, but with much, much improved quality at a given data rate, and support for real-time streaming. You can stop yelling at Apple about porting QuickTime, since you'll just use someone else's MPEG-4 player with their content, and it'll just work.
The risk is that support for Profile@Level combinations will vary. Certainly, a lot of cell phones use ISMA Profile 0, which means 176x144 maximum resolution, the Simple instead of Advanced Simple codec, etcetera. And there are more advanced codecs coming down the pike that improve quality, but won't work with today's ISMA profiles.
But hey, nothing that folks who deal with RPMs all day don't know about.
Actually, MP3 is MPEG-1 Layer III. Ironically, MP3 was never used for MPEG-1 files because of the licensing issues that later affected MP3.
I expect the big reason for ".mp4" instead of ".mpeg4" is for compatibility with 8.3 filename filesystems. Bear in mind that the MPEG-4 process was started BEFORE Windows 95 shipped.
Fast start is actually a result of better managing the buffer between the streaming server and the client. What it does is tell the player to start playing as soon as the first frame has been transmitted, instead of waiting for the usual few seconds of buffering. This only works if you have significantly more bandwidth available than the stream requires, so it won't help with modem stuff much. It works with any codec, not just MPEG-4.
Also, RealONE already supports the Envivio plug-in for MPEG-4 playback. PacketVideo and Philips also have MPEG-4 players available.
QuickTime 6 does represents the first mass-market MPEG-4 authoring, distribution, and playback system. This is a Good Thing.
G4s are wicked fast for MP3 encoding, due to AltiVec. My ancient G4 400 CD jukebox can rip at 10x without breaking a sweat, and it might even be disc-speed bound at that point.
And games can use a LOT of vector processing as well, if properly optimized. id software once said that the G4 was the fastest computer they had seen for 3D performance w/o hardware T&L or geometry (like the Rage 128 era).
Kernel compiles aren't helped much, although SIMD can do some fast string manipulation stuff as well.
Given how everyone always trumpets how fast their extreme gaming systems are, it's sad we don't here more about extreme slow gaming.
Sure, playing through Quake at 180 fps is cool, but winning Quake at 5 fps, ah, now that's a challenge.
My greatest act of low-powered gaming was winning Unreal on a PowerBook G3 300. This was MacOS 8.6 or so, with manual memory management and everything. I had to create a custom Extensions set boot mode to even get enough free memory to launch Unreal.
The two most challenging aspect were graphics and controls. The Rage Pro was very aenemic, and I was lucky to get 15 fps out of it. And I had to use hardware scaling, since the LCD was 1024x768, and the card could barely do 3D at 640x480. Also, it had to run in 16-bit mode, which those old ATI card had huge dithering problems in. So it was kind of like watching a blocky yet blurred filmstrip in a snowstorm.
Controls? Well, of course, the keyboard and, wait for it, the trackpad! No mouse for me! If you haven't played through a first person shooter using a trackpad for aim, you haven't lived, at least not lived badly.
The nice thing about this is that you can play in bed when your girlfriend is asleep. The startling thing was she actually married me even after that.
Is the question really whether life begins, or HUMAN life beings at conception? I don't see too many vegetarian abortion protesters.
We make, appropriately, a distinction between the kind of life we protect (human life), and that we don't. The distinction between them is enormously difficult to parse, without any obvious way to discriminate. PETA certainly hold that most animals deserve protection similar to humans. Others don't.
It has been argued that the capacity to suffer is the defining test, which means, say, protecting a dog is more important than a human in a persistent (irreversible) vegetative state. By that measure, an early stage embryo certainly doesn't qualify.
Now, if it's the POTENTIAL for sentience that matters, then you can claim that the human embryo is more important than, say, the adult chimp. However, does that mean that every unnoticed miscarrage of a 4-week old embryo is as tragic as an adult death? However about every unfertilized egg that goes to waste every 28 days?
The reasons why we don't have any consensus on these issues is that there aren't obvious answers. In the end, they'll be decided like most bioethical questions: by finding pragmatic answers to specific questions.
The questions that actually get answered aren't going to be "Cloning: good or bad." But "this particular model of stem cell treatment for Parkinsons: good or bad."
In the course of medicine, even in the lifetimes of our grandparents, many questions that seemed deeply philosophical turned out to have relatively simple answers. It wasn't long ago that we thought:
Death was synonymous with the heart stopping beating.
Cancer was an inevitable death sentence.
Blood transfusions are horribly unnatural.
Autopsies are horribly unnatural.
Alan,
Yes, the proper digital terminology is Y'CrCb. YUV strictly only applies to NTSC analog video.
I used YUV in this context because it is what most software engineers use, and thought the post had sufficient terminology pedantry already.
Hardly. The only thing open about the codec is the decoder, and that's only as open as Flash in general. No one charges for decoders for web formats - nothing new here.
The Spark Pro encoder is only available with Sorenson's Squeeze for Flash MX product, which they sell. It's a good piece of software, and worth the money for those doing professional Flash creation. The free Spark encoder built into Flash MX can work for simple projects, but doesn't come close to Spark Pro for mission critical quality.
Apple is actually backing MPEG-4 hard, which is much closer to an open standard than Sorenson's codecs.
Actually, the current Windows Media Player 7.1 for MacOS X is pretty darn sweet. it doesn't support the ACELP.net speech codec, but it does a fine job with any file using Windows Media Video and Windows Media Audio.
Real has stated that the forthcoming RealONE Player for MacOS will be MacOS X native. Maybe summer?
Hopefully it'll have better performance than RealPlayer 8 does under MacOS 9.x. Real has blamed the classic MacOS memory model for this, which obviously isn't a problem under X.