I don't agree. If I tell you that you can use my software, but only under the condition that you distribute the source code, or make code that utilizes my code open source as well, then that is obviously stipulating "what terms they can give out the software or derived works to other people."
We can argue symantecs till the end of time but isn't a patented, open-source piece of software an oxymoron? I mean I am not exactly jumping for joy and screaming yay that I can use it because I might have the patent trolls jump all over me.
No, it's not even remotely an "oxymoron"; open source isn't about giving up your property rights. It's about _respecting_ property rights. This is why open source projects _include a license_, and that license stipulates how people may use the project in detail.
How is me requiring people open source projects that use my property any different than me requesting they pay me to use my property? In either scenario, I am putting forth the stipulations for use. If you're against paying to use property, so be it, but don't make the mistake of thinking open source code is devoid of property rights.
First of all, H264 is not a "closed-source..codec"--this is complete nonsense. The standard itself is completely published and documented, and there is nothing stopping open source projects from creating H264 encoder and decoders.
And have they ever--hands down, the best H264 encoder implementation today is x264, which is licensed under the GPL.
The patent issue is totally separate, but let's not conflate "patented" with "open source." The real issue with H264 is who will pay royalties for the patents. For Windows 7 and OSX, MSFT and APPL pay those royalties. In the case of Ubuntu, it makes it easier for commercial entities to distribute Ubuntu if they know royalties and licensing fees are already being handled. So to be honest, this just makes Ubuntu an easier sell to PC manufacturers because they aren't liable for royalty costs or hidden "gotchas"
....wouldn't it just be easier to use a wire rather than construct a building in such a manner? Or use a powerline network instead?
Nobody worth their tin-foil hat would ever think such a drastic measure was worthwhile.
Any computer can be hacked if you have physical access to it, so your point is a non-starter. We're talking about hacking things over the Internet.
Like the article said, Macs are secure only because they don't have enough market penetration to make exploiting them worthwhile (i.e.: they are the small-potatoe).
So, if your argument is that a mac is more secure because Internet predators are less likely to target your platform, great--I agree with you. If your argument is that the programmers Mac hires are somehow leaps and bounds more perfect than the ones Microsoft hires, then I'm calling BS. FF, and now OSX, are both clearly illustrating the principle that security exploits arrive as a given piece of software has greater market penetration.
Note: I do not represent the opinions of MSFT, nor do I speak on their behalf. The below is my opinion.
The author of the article concludes with this ridiculous statement:
In short, Microsoft needs to seriously clean up this mess. Video codecs need to hook into a common framework, one that the graphics cards manufacturers can target for acceleration without needing to work with every individual codec maker on the planet.
A few observations, as someone who has done extensive programmatic work for digital video in windows:
Video codecs in windows do hook into a common framework--that framework is called DirectShow. It's specifically designed to process audio and video, and includes highly advanced features that until several years ago were not even present in *nix (see GStreamer for the *nix equivalent to DirectShow), and many features that currently are not (to the best of my knowledge) available in *nix. This framework is completely free, has a substantial portion of open source code (see the baseclasses), is used in almost every media application MSFT makes and the majority of many custom players, and has been available for in excess of a decade. So, anybody not using it is A) stupid and/or B) technically inept.
This framework *does* allow acceleration, to a limited degree, but the problem has nothing to do with Microsoft. In order to provide acceleration, Microsoft has to work with NVidia and ATI (which I assure you, they are) closely--it cannot be a singular endeavor. I had to remove DXVA from the product I'm currently working on because the drivers being provided by NVidia and ATI were too unstable for us to realistically release the program into the wild. How and why should I "blame Microsoft" for that?
By no means is Microsoft saintly or innocent (far from it), but it seems to me that they just can't win no matter how they play the game. The statement above is just looking for a quick target rather than addressing the real problem: people who are too dumb to make codecs that leverage a standards based playback architecture (it doesn't even have to be DirectShow--there are other architectures out there). DirectShow is a very developed, very extensive framework for processing audio and video, and it is solely the fault of people proliferating the market with excessive, buggy, redundant code that there are conflicting third-party applications.
Were MSFT to do anything to "fix" this problem, they'd have to further restrict restrict codecs in DirectShow, in which case the above author would proceed to whine about how MSFT doesn't allow third parties enough integration. Having your cake and eating it too? I think so.
You should *easily* be able to stream D1 video in far less than 10 mb/sec--100 MBit ethernet is easily capable of streaming WMV HD (1080p) with no trouble at all. Heck, you could stream multiple WMV HD streams over a decent 100 mb connection, with relative ease.
I work for a company that manufactures and creates IP based security cameras. Right now, we encode and stream WMV9 in VGA resolution (pretty close to D1, although not quite) at 300 kb/sec, and it looks really good and works just fine on networks running at much less than 1 mb/sec.
...out of a mac mini. I'm skeptical, anyways. I doubt that you can encode 720p H.264/MPEG4 in real time on a mac mini.
That, and the biggest problem with video conferencing in HD has more to do with the network transmission and upload speed. It's all fine and dandy to produce a product that'll work with a reliable megabit of upload speed, but most consumers don't have that much upload bandwidth.
Add that to the fact that most of these codecs you're dealing with are heinously intolerant to loss, combined with trying to stream them over a big, lossy, latent network (i.e. the Internet), and people will begin to get the picture.
Slashdot Mirror
I don't agree. If I tell you that you can use my software, but only under the condition that you distribute the source code, or make code that utilizes my code open source as well, then that is obviously stipulating "what terms they can give out the software or derived works to other people."
Are you serious? http://x264dev.multimedia.cx/?p=102 In particular, http://x264dev.multimedia.cx/wp-content/uploads/2009/08/quality_chart1.png No contest, Theora gets whooped. So do most h264 implementations, compared to x264 for that matter, which is probably why most companies these days are moving towards that encoder implementation.
We can argue symantecs till the end of time but isn't a patented, open-source piece of software an oxymoron? I mean I am not exactly jumping for joy and screaming yay that I can use it because I might have the patent trolls jump all over me.
No, it's not even remotely an "oxymoron"; open source isn't about giving up your property rights. It's about _respecting_ property rights. This is why open source projects _include a license_, and that license stipulates how people may use the project in detail. How is me requiring people open source projects that use my property any different than me requesting they pay me to use my property? In either scenario, I am putting forth the stipulations for use. If you're against paying to use property, so be it, but don't make the mistake of thinking open source code is devoid of property rights.
First of all, H264 is not a "closed-source..codec"--this is complete nonsense. The standard itself is completely published and documented, and there is nothing stopping open source projects from creating H264 encoder and decoders. And have they ever--hands down, the best H264 encoder implementation today is x264, which is licensed under the GPL. The patent issue is totally separate, but let's not conflate "patented" with "open source." The real issue with H264 is who will pay royalties for the patents. For Windows 7 and OSX, MSFT and APPL pay those royalties. In the case of Ubuntu, it makes it easier for commercial entities to distribute Ubuntu if they know royalties and licensing fees are already being handled. So to be honest, this just makes Ubuntu an easier sell to PC manufacturers because they aren't liable for royalty costs or hidden "gotchas"
....wouldn't it just be easier to use a wire rather than construct a building in such a manner? Or use a powerline network instead? Nobody worth their tin-foil hat would ever think such a drastic measure was worthwhile.
Any computer can be hacked if you have physical access to it, so your point is a non-starter. We're talking about hacking things over the Internet.
Like the article said, Macs are secure only because they don't have enough market penetration to make exploiting them worthwhile (i.e.: they are the small-potatoe).
So, if your argument is that a mac is more secure because Internet predators are less likely to target your platform, great--I agree with you. If your argument is that the programmers Mac hires are somehow leaps and bounds more perfect than the ones Microsoft hires, then I'm calling BS. FF, and now OSX, are both clearly illustrating the principle that security exploits arrive as a given piece of software has greater market penetration.
...consider disconnecting your Internet connection. Duh.
The only trend to security is that there isn't any financial motivation to hack small-potatoes.
The author of the article concludes with this ridiculous statement:
In short, Microsoft needs to seriously clean up this mess. Video codecs need to hook into a common framework, one that the graphics cards manufacturers can target for acceleration without needing to work with every individual codec maker on the planet.
A few observations, as someone who has done extensive programmatic work for digital video in windows:
By no means is Microsoft saintly or innocent (far from it), but it seems to me that they just can't win no matter how they play the game. The statement above is just looking for a quick target rather than addressing the real problem: people who are too dumb to make codecs that leverage a standards based playback architecture (it doesn't even have to be DirectShow--there are other architectures out there). DirectShow is a very developed, very extensive framework for processing audio and video, and it is solely the fault of people proliferating the market with excessive, buggy, redundant code that there are conflicting third-party applications.
Were MSFT to do anything to "fix" this problem, they'd have to further restrict restrict codecs in DirectShow, in which case the above author would proceed to whine about how MSFT doesn't allow third parties enough integration. Having your cake and eating it too? I think so.
On a well-tuned 100 mb/sec network, a hundred cameras (in theory) would be no problem at all.
On a gigabit network, definetely no problem.
You should *easily* be able to stream D1 video in far less than 10 mb/sec--100 MBit ethernet is easily capable of streaming WMV HD (1080p) with no trouble at all. Heck, you could stream multiple WMV HD streams over a decent 100 mb connection, with relative ease.
I work for a company that manufactures and creates IP based security cameras. Right now, we encode and stream WMV9 in VGA resolution (pretty close to D1, although not quite) at 300 kb/sec, and it looks really good and works just fine on networks running at much less than 1 mb/sec.
...out of a mac mini. I'm skeptical, anyways. I doubt that you can encode 720p H.264/MPEG4 in real time on a mac mini.
That, and the biggest problem with video conferencing in HD has more to do with the network transmission and upload speed. It's all fine and dandy to produce a product that'll work with a reliable megabit of upload speed, but most consumers don't have that much upload bandwidth.
Add that to the fact that most of these codecs you're dealing with are heinously intolerant to loss, combined with trying to stream them over a big, lossy, latent network (i.e. the Internet), and people will begin to get the picture.