For serious? Their leading feature is the ability to run even less efficiency than before? Extra speed at expense of power is great for desktops - too bad people hardly buy those anymore. Some of us actually want to run these things ON A BATTERY - can you imagine? Then again, being in Minnesota, I welcome the added heat.
By continuing to use h264, you support the developers who support intellectual property and DRM protected hardware. Do you really want to do that? I don't want to support developers who stand behind "intellectual property" and "Digital Rights Management" software and hardware.
Excuse me, but what does H.264 have to do with DRM?
It stifles innovation and widens the disparity between the rich and the poor because the poor will have less opportunity to learn how all of this hardware works in order to create and innovate similar products.
Hmm? Patents are freely viewable online, as is the H.264 spec. "create and innovate similar products"... similar products? I thought innovation generally resulted in original products? I digress.
Don't let all those intellectual assholes "smoke and mirrors" confuse you and and distract you by saying there are other codecs "technically superior" to Theora.
So you can magically make facts not important by enclosing them with double quotes?
I've been witness to all this video intellectual property crapola since the mid 1990's. All these different audio/video formats to obfuscate, divide and conquer the open-source world: mpeg, mp4, aac, nmr-nb, nmr-wb, 3gp, 3gp2. dirac, matroska, wav, mp3, flac.
Great job listing off open formats like dirac, matroska, wav, and flac, I see you really did your homework there. Also, mp4, 3gp, and 3gp2 are containers for the MPEG-4 format, of which aac is a component. I don't see a lot of division there - just different containers for certain specific applications with specific needs.
Not to mention the price to purchase the hardware had been quite exclusive for the longest time for the cameras and the encoder cards.
Man, if that $200 MPEG-4 encoding video camera was only $0.20 cheaper...
The phone makers and the MID makers should be supporting the open-source route because it makes their hardware less expensive to buy in the long-run.
Uhh, that's the whole point of selling or licensing things. To delegate production or R&D to other parties, so you don't have to reinvent the wheel.
Why is it they are still selling stuff with mp4/mpeg chipsets? Why are they supporting these intellectual property guys?
Consumers have buying power. They will vote for open-source with their money if well-informed.
Let's see... a well-informed customer would know that the Theora product would offer two advantages over the H.264 product... $0.20 cheaper and significantly worse video quality. This is assuming, of course, that Theora encoders and decoders are manufactured in great enough volumes to make the cost equal to H.264.
I know the real point of your post is promoting ideals, and I'm a bit of a practical type... but seriously, isn't there something better for you to campaign about?
I hate to say this, but I don't really consider video patents "landmines" - most of the things patented aren't things that you would accidentally design yourself, rather I think video formats are hard to develop and a lot of people would rather just rip off other peoples' ideas.
Hey guys, before assuming MPEG LA has patents and is therefore evil, have you actually checked the license terms?
The licensing is really quite cheap. At low quantities, the licensing per codec is only $0.20. You really only should need one of these per computer, and there is no particular reason why every piece of video software get for free should need to have its dedicated codec.
Pay per view is the lower of 2% and $0.02 per view.
Based on what the x264 developer diary says, VP8 is a blatant ripoff of H.264 anyway, so I'm a bit dissapointed that Google was tricked into supporting this for WebM. I would have much rather supported an entirely new format that made use of new ideas, rather than something that steals original work and gives it enough tweaks to make it questionably legal.
Seriously, guys, this is what patents are for. H.264 is an excellent format, quite efficient to implement in hardware. The guys who designed it deserve to get paid something, even if much of the complexity is in the codec - as the x264 blog says, there is only so much you can do with a bad format.
Sounds like someone has been living in a perfect reality (aka drugs).
I dare you to make a voltage regulator with better precision than an IEEE 64-bit floating point number... or even a 32-bit one.
Then try to implement mixers and actual logic.
Then embed it into a tiny circuit amid an extremely noisy environment.
Of course, the last two are just academic, as you're never even going to manage the voltage regulator without some extreme equipment.
See slide 41 for the NAND gate they are bragging about.
I'm a bit worried about them being completely fabless. I'm sure all their circuits work in SPICE, but how is this going to deal with real world noise, especially embedded on some other digital chip? The powerpoint explicitly states that is adversely affected especially by the sudden spikes caused by digital noise...
I was about to post the slideshow myself, but I see you beat me to it:)
I'm not sure that this is to much of an issue, unless there is some kind of tone-mapping involved it would be near impossible to see the indirect lighting while have the direct component at the correct exposure level. I think that the way most games pump up the ambient term in order to show the contents of the shadows looks bad, it kills the contrast.
Go in a dark room, aim a bright flashlight at a ceiling, and see what happens.
I think he wants to make it through the entire 20 minute instructional video on battery...
Enjoy your horribly wasteful software decoding, or use h.264 which has very liberal and cheap licensing requirements (in fact, you won't have to pay anything as the hardware decoder is already paid for by the hardware manufacturer, and you don't owe anything for encoding the video, look it up)
From a business standpoint, which makes more sense?
P.S. not to give you a new one, but you fail to list any reasons why Theora was superior. In fact, it's been said many many times again that it's quite a bit worse.
QVGA is horrible on modern smartphones which have very high resolution displays, and young users who can see the detail on a high resolution screen.
48kbit mp3 sounds like a metallic mess even for voice to me, especially considering that this is a portable market and many users will use headphones. Have you actually attempted mono mp3 at 48kbit/s?
I think you have your perfect world wrong here - the only thing that restricts h.264 is the patents (and relatively cheap, they are). Vorbis is admittedly a bit superior, but mp3 encoders have gotten so much better it matters far less than the video.
Bandwidth to the LCD isn't really a problem at all.
Making a large quantity of pixels, however, is.
The trick is that customers expect a perfect display - therefore, as you get more pixels, your yield drops, as a single dead line makes a display completely unsellable.
Then of course, there is existing software that expects a screen to be 72-96 dpi (e.g. LABVIEW I HATE YOU WITH PASSION). Smartphones don't have this problem because they were designed from the ground up for variable resolution and dpi displays.
Safari isn't the only browser to support 3D CSS transforms. QtWebkit also added support for accelerated transforms a little while ago. Yes, that's only two browsers, but it's a rather hard thing to implement considering how complex it makes drawing code (and in its implementation, might use OpenGL).
See http://labs.trolltech.com/blogs/2010/05/17/qtwebkit-now-accelerates-css-animations-3d-transforms/
Don't forget that the header of encfs causes it not to be 4k block aligned, which kills performance on 4k-sector drives, which should be arriving very soon (filesystems have used 4k or larger sector sizes for a long time, however).
A pile of explosives goes poof with a flash and some flame. That's it. Even a really big pile. A pile of explosives in a very solid tube with one end open is a gun, which can shoot stuff out of the open end. A pile of explosives in a sealed container is a bomb, and can build up enough pressure to blow holes in things.
Incorrect, sir. Any decent high explosive does not need a sealed container. What happened more likely is that the explosive deflagrated rather than detonated... aka it burned his pants but didn't actually blow up anything.
Nevermind, of course, that flash memory is sector-based as well. I've never seen flash memory with a sector size below 512 bytes.
To make matters worse, you can only erase Flash a block at a time - a block being a group of sectors that I've never seen smaller than 64KiB.
... I think I've been trolled.
P.S. Would you count FeRAM and MRAM as magnetic media?
It's a good thing the kernel supports modules, so that the 0.1% of users that use this feature can still have it supported without any performance or memory usage detriment to the other 99.9% of users.
Malicious software running as a user can also exploit existing packages.
For a home user it makes sense to trust every signed package in Fedora's main repositories as being secure, especially with frequent updates.
You complain about the ability to install packages with security holes, but don't you already put trust in the repositories by using their packages?
I'm also pretty confident that Fedora can patch security holes in their packages faster than you can patch or remove them, or even be notified of them. Even though you are worried about packages not-yet-installed on their server, these are even less sensitive to exploits as the only lag in patches is pushing the package to all the mirrors, and this happens whether or not the user frequently updates their packages.
Varying color depth - X has supported this for _years_. You can do 1bit if you really, really want.
Widescreen display ratios - ditto.
Scaling elements - if you want it pretty, see XRender.
Transparency / composite - AIGLX
GEM / KMS / DRI - these aren't new hardware, they are parts of X11.
hardware / software acceleration - What, sofware acceleration? What is this? And X11 has supported hardware acceleration since man first put peanut butter on bread.
modern font rendering / sub-pixel hinting - I had these back in the windows 98 days, so X11 was ahead here.
anti-aliasing - see XRender, though most efficient apps prerender to pixel-aligned pixmaps first for efficiency, so this is a non-issue.
I'm not going to even go into your list of inputs just because almost all have those have existed for a very very long time.
What would actually involve a bit of innovation is if someone hooked up those glasses to, say, a pocket beagleboard or similar device capable of video output, and ported/hacked Google Street View to output stereo information (or fake it with a sphere and/or luminosity info).
In fact, said mini ARM computer could even run Android!
A cardboard box with a phone taped on one end, "Virtual Reality Goggles" written with marker on the side, and an elastic cord to hold it to your head.
Man, I totally want one of these. Where do I buy them?
Unfortunately, these devices are huge compared to transistors, with the device in the picture about 30 micrometers long. While these might be neat for all sorts of sensors and possibly new ways to send information using light or mechanical vibration, I don't expect them to come close to the practicality of transistors for switching or computation.
First off, I would like to point out that I don't support the idea of making binaries universal by packing them in the same.elf. Sure, it would be neat to have a DVD that can install to different architectures, it's currently not possible because the bootloader _has_ to be native. You'd probably end up with a bunch of boot floppies for a single installation media. In addition, is there any difference to having a package for each architecture on this DVD rather than universal packages? With separate packages the same amount of DVD space is consumed but far less is consumed on the target hard disk.
In addition, this isn't going to make companies support uncommon architectures any faster. Maintaining multiple packages is really easy, keeping the code working across different architectures is not so hard. I think it's mostly programmer laziness not bothering to compile other architecture packages - and there is no reason fatELF is going to decrease this laziness.
If you _really_ want architecture independence (which universal binaries don't really provide, they still only support architectures that the author had in mind), you'll need a recompiler of some sort. LLVM is designed to be suited to this task, so why not use it? Apple already does. Yes, I know it's a bit slower, but a small price to pay if you need your app to run on every system under the sun.
Of course, there is always the option of web apps...
Slashdot Mirror
For serious? Their leading feature is the ability to run even less efficiency than before? Extra speed at expense of power is great for desktops - too bad people hardly buy those anymore. Some of us actually want to run these things ON A BATTERY - can you imagine? Then again, being in Minnesota, I welcome the added heat.
Don't let these MPEG LA devils fool you.
Oh my, we're really in for it now.
By continuing to use h264, you support the developers who support intellectual property and DRM protected hardware. Do you really want to do that? I don't want to support developers who stand behind "intellectual property" and "Digital Rights Management" software and hardware.
Excuse me, but what does H.264 have to do with DRM?
It stifles innovation and widens the disparity between the rich and the poor because the poor will have less opportunity to learn how all of this hardware works in order to create and innovate similar products.
Hmm? Patents are freely viewable online, as is the H.264 spec. "create and innovate similar products"... similar products? I thought innovation generally resulted in original products? I digress.
Don't let all those intellectual assholes "smoke and mirrors" confuse you and and distract you by saying there are other codecs "technically superior" to Theora.
So you can magically make facts not important by enclosing them with double quotes?
I've been witness to all this video intellectual property crapola since the mid 1990's. All these different audio/video formats to obfuscate, divide and conquer the open-source world: mpeg, mp4, aac, nmr-nb, nmr-wb, 3gp, 3gp2. dirac, matroska, wav, mp3, flac.
Great job listing off open formats like dirac, matroska, wav, and flac, I see you really did your homework there. Also, mp4, 3gp, and 3gp2 are containers for the MPEG-4 format, of which aac is a component. I don't see a lot of division there - just different containers for certain specific applications with specific needs.
Not to mention the price to purchase the hardware had been quite exclusive for the longest time for the cameras and the encoder cards.
Man, if that $200 MPEG-4 encoding video camera was only $0.20 cheaper...
The phone makers and the MID makers should be supporting the open-source route because it makes their hardware less expensive to buy in the long-run.
Uhh, that's the whole point of selling or licensing things. To delegate production or R&D to other parties, so you don't have to reinvent the wheel.
Why is it they are still selling stuff with mp4/mpeg chipsets? Why are they supporting these intellectual property guys?
Consumers have buying power. They will vote for open-source with their money if well-informed.
Let's see... a well-informed customer would know that the Theora product would offer two advantages over the H.264 product... $0.20 cheaper and significantly worse video quality. This is assuming, of course, that Theora encoders and decoders are manufactured in great enough volumes to make the cost equal to H.264.
I know the real point of your post is promoting ideals, and I'm a bit of a practical type... but seriously, isn't there something better for you to campaign about?
I hate to say this, but I don't really consider video patents "landmines" - most of the things patented aren't things that you would accidentally design yourself, rather I think video formats are hard to develop and a lot of people would rather just rip off other peoples' ideas.
Hey guys, before assuming MPEG LA has patents and is therefore evil, have you actually checked the license terms?
The licensing is really quite cheap. At low quantities, the licensing per codec is only $0.20. You really only should need one of these per computer, and there is no particular reason why every piece of video software get for free should need to have its dedicated codec.
Pay per view is the lower of 2% and $0.02 per view.
Based on what the x264 developer diary says, VP8 is a blatant ripoff of H.264 anyway, so I'm a bit dissapointed that Google was tricked into supporting this for WebM. I would have much rather supported an entirely new format that made use of new ideas, rather than something that steals original work and gives it enough tweaks to make it questionably legal.
Seriously, guys, this is what patents are for. H.264 is an excellent format, quite efficient to implement in hardware. The guys who designed it deserve to get paid something, even if much of the complexity is in the codec - as the x264 blog says, there is only so much you can do with a bad format.
It's not analog in the sense that we use op amps, we still use gates
What's the difference? A gate is just a high speed high gain ultra high distortion opamp.
And worse, in this application neither high gain nor high distortion are desired properties.
Sounds like someone has been living in a perfect reality (aka drugs). I dare you to make a voltage regulator with better precision than an IEEE 64-bit floating point number... or even a 32-bit one.
Then try to implement mixers and actual logic.
Then embed it into a tiny circuit amid an extremely noisy environment.
Of course, the last two are just academic, as you're never even going to manage the voltage regulator without some extreme equipment.
See slide 41 for the NAND gate they are bragging about.
:)
I'm a bit worried about them being completely fabless. I'm sure all their circuits work in SPICE, but how is this going to deal with real world noise, especially embedded on some other digital chip? The powerpoint explicitly states that is adversely affected especially by the sudden spikes caused by digital noise...
I was about to post the slideshow myself, but I see you beat me to it
I'm not sure that this is to much of an issue, unless there is some kind of tone-mapping involved it would be near impossible to see the indirect lighting while have the direct component at the correct exposure level. I think that the way most games pump up the ambient term in order to show the contents of the shadows looks bad, it kills the contrast.
Go in a dark room, aim a bright flashlight at a ceiling, and see what happens.
I think he wants to make it through the entire 20 minute instructional video on battery... Enjoy your horribly wasteful software decoding, or use h.264 which has very liberal and cheap licensing requirements (in fact, you won't have to pay anything as the hardware decoder is already paid for by the hardware manufacturer, and you don't owe anything for encoding the video, look it up) From a business standpoint, which makes more sense? P.S. not to give you a new one, but you fail to list any reasons why Theora was superior. In fact, it's been said many many times again that it's quite a bit worse. QVGA is horrible on modern smartphones which have very high resolution displays, and young users who can see the detail on a high resolution screen. 48kbit mp3 sounds like a metallic mess even for voice to me, especially considering that this is a portable market and many users will use headphones. Have you actually attempted mono mp3 at 48kbit/s? I think you have your perfect world wrong here - the only thing that restricts h.264 is the patents (and relatively cheap, they are). Vorbis is admittedly a bit superior, but mp3 encoders have gotten so much better it matters far less than the video.
Bandwidth to the LCD isn't really a problem at all. Making a large quantity of pixels, however, is. The trick is that customers expect a perfect display - therefore, as you get more pixels, your yield drops, as a single dead line makes a display completely unsellable. Then of course, there is existing software that expects a screen to be 72-96 dpi (e.g. LABVIEW I HATE YOU WITH PASSION). Smartphones don't have this problem because they were designed from the ground up for variable resolution and dpi displays.
Safari isn't the only browser to support 3D CSS transforms. QtWebkit also added support for accelerated transforms a little while ago. Yes, that's only two browsers, but it's a rather hard thing to implement considering how complex it makes drawing code (and in its implementation, might use OpenGL). See http://labs.trolltech.com/blogs/2010/05/17/qtwebkit-now-accelerates-css-animations-3d-transforms/
Cells respond, evidently by their very nature, to coherent electromagnetic signals in the 1 to 500Hz range.
It's a good thing, then, that cell signals are in the 900MHz range or higher (for GSM, most newer ones are closer to the 2GHz range)
Don't forget that the header of encfs causes it not to be 4k block aligned, which kills performance on 4k-sector drives, which should be arriving very soon (filesystems have used 4k or larger sector sizes for a long time, however).
A pile of explosives goes poof with a flash and some flame. That's it. Even a really big pile. A pile of explosives in a very solid tube with one end open is a gun, which can shoot stuff out of the open end. A pile of explosives in a sealed container is a bomb, and can build up enough pressure to blow holes in things.
Incorrect, sir. Any decent high explosive does not need a sealed container. What happened more likely is that the explosive deflagrated rather than detonated... aka it burned his pants but didn't actually blow up anything.
Nevermind, of course, that flash memory is sector-based as well. I've never seen flash memory with a sector size below 512 bytes. To make matters worse, you can only erase Flash a block at a time - a block being a group of sectors that I've never seen smaller than 64KiB.
... I think I've been trolled.
P.S. Would you count FeRAM and MRAM as magnetic media?
It's a good thing the kernel supports modules, so that the 0.1% of users that use this feature can still have it supported without any performance or memory usage detriment to the other 99.9% of users.
The senators can sign a law that takes a way the parts of the bill of rights.
After which it will be immediately ruled unconstitutional by the Supreme Court.
One would never, _ever_ withdraw life support without this sort of brain scan, at the bare minimum.
So having a package with a known root exploit in the repository makes sense?
Malicious software running as a user can also exploit existing packages. For a home user it makes sense to trust every signed package in Fedora's main repositories as being secure, especially with frequent updates. You complain about the ability to install packages with security holes, but don't you already put trust in the repositories by using their packages?
I'm also pretty confident that Fedora can patch security holes in their packages faster than you can patch or remove them, or even be notified of them. Even though you are worried about packages not-yet-installed on their server, these are even less sensitive to exploits as the only lag in patches is pushing the package to all the mirrors, and this happens whether or not the user frequently updates their packages.
Varying color depth - X has supported this for _years_. You can do 1bit if you really, really want.
Widescreen display ratios - ditto.
Scaling elements - if you want it pretty, see XRender.
Transparency / composite - AIGLX
GEM / KMS / DRI - these aren't new hardware, they are parts of X11.
hardware / software acceleration - What, sofware acceleration? What is this? And X11 has supported hardware acceleration since man first put peanut butter on bread.
modern font rendering / sub-pixel hinting - I had these back in the windows 98 days, so X11 was ahead here.
anti-aliasing - see XRender, though most efficient apps prerender to pixel-aligned pixmaps first for efficiency, so this is a non-issue.
I'm not going to even go into your list of inputs just because almost all have those have existed for a very very long time.
What would actually involve a bit of innovation is if someone hooked up those glasses to, say, a pocket beagleboard or similar device capable of video output, and ported/hacked Google Street View to output stereo information (or fake it with a sphere and/or luminosity info). In fact, said mini ARM computer could even run Android!
A cardboard box with a phone taped on one end, "Virtual Reality Goggles" written with marker on the side, and an elastic cord to hold it to your head. Man, I totally want one of these. Where do I buy them?
Unfortunately, these devices are huge compared to transistors, with the device in the picture about 30 micrometers long. While these might be neat for all sorts of sensors and possibly new ways to send information using light or mechanical vibration, I don't expect them to come close to the practicality of transistors for switching or computation.
First off, I would like to point out that I don't support the idea of making binaries universal by packing them in the same .elf. Sure, it would be neat to have a DVD that can install to different architectures, it's currently not possible because the bootloader _has_ to be native. You'd probably end up with a bunch of boot floppies for a single installation media. In addition, is there any difference to having a package for each architecture on this DVD rather than universal packages? With separate packages the same amount of DVD space is consumed but far less is consumed on the target hard disk.
In addition, this isn't going to make companies support uncommon architectures any faster. Maintaining multiple packages is really easy, keeping the code working across different architectures is not so hard. I think it's mostly programmer laziness not bothering to compile other architecture packages - and there is no reason fatELF is going to decrease this laziness.
If you _really_ want architecture independence (which universal binaries don't really provide, they still only support architectures that the author had in mind), you'll need a recompiler of some sort. LLVM is designed to be suited to this task, so why not use it? Apple already does. Yes, I know it's a bit slower, but a small price to pay if you need your app to run on every system under the sun.
Of course, there is always the option of web apps...