They said that for Battlefield BC2 too ("dedicated servers are a given for the PC"), and see what you actually got: the "right" to rent a server at a few selected hosters, i.e. the right to pay their hosting bills for them. What a scam.
So please, don't buy the hype from DICE. We'll see how well they support the PC when they actually release it. And their reputation from the last release speaks against them.
Forcing users to a standardized and completely controlled hardware platform allows for easier software development and less potential configuration issues. It also arbitrarily allows blocking competitors or potential competitors out. And after a while you jack prices way up above production cost and hope you get away with it because your users are bunnies that don't like to think for themselves.
They must be thinking "Apple is doing well with this, let's try it too!".
Google, if your motto is "Don't be evil", you're doing it wrong. At least Microsoft didn't try to control your hardware.
that's 140 million dollars in sales in the most recent quarter on iPads alone (nevermind iphones or ipods). You may call that drop in the bucket if you want, but I don't Samsung is going to.
Sure, but they sold over 10 million of the Android phones Apple is pissed about (Galaxy S), at what, 400 bucks each? So that's over twice as much, for one model alone.
Yes, but it's not a vindictive type of thing - it's strategy. "Well Samsung, you have a bit more to lose if you stay on your present course.
How big is the revenue Samsung gets from making Apple devices, percentagewise? It should be tiny compared to all of their business, right?
And the revenue they get from their own Android devices? Is it even less than they get from Apple? After all, the margins on them should be much better for Samsung.
I have some problems believing Samsung would be at all impressed by this, but maybe the numbers I have in my head are off.
Not everybody is a patent troll, you know. Some companies prefer the formats to be used so they can sell hardware or software rather than litigation protection rackets.
See, there are 2 kinds of reasons to contribute to these codecs: 1) to collect license fees 2) to actually sell products that use them.
For the companies in (2), the license fees are a nuisance that potentially stops their products from getting more widespread acceptance. This is why some big guys, which are mostly (2), already joined Google. Even if they gain from the license fees, its much smaller than the actual product sales. They tend to be in the MPEG-LA only because that makes it cheaper to do (2), not because they want (1).
So, if you revenue "depended on video codecs", the critical question is if your revenue is coming only from the patents (also called "patent troll") or if you were actually making products.
They've been spewing FUD about creating a licensing pool for VP8. If Google was right wrt. VP8 rights, that pool could only contain invalid patents. So it would have been interesting to see if anything really showed up in there. So far nothing turned up in the MPEG-LA pool, but the threat that this could happen is FUD to stop VP8/WebM.
It's quite comparable in complexity, but it's less likely to have (full) hardware acceleration support for the decode. Some parts of H.264 decoders would be reusable, though.
Then again, if your laptop is so old that decoding a video overheats it, it probably didn't have it for H.264 either.
Am I misunderstanding, or is the headline "open codec designed for voip is slightly better for voip than closed codec designed for music"? How does it compare to the other voip codecs?
The test wasn't about VoIP but about music. The VoIP codec beat the others at their game.
I would guess that this codec is very likely to gain hardware support, particularly as it's being standardized by the IETF *and* Broadcom seems to have been contributing to the development of it.
This would mean that during Skype calls, the decoding no longer has to be done in software, so battery time when using Skype on a mobile device could increase a lot.
Perhaps they could switch to "has not yet been challenged in court for any possible patent infringement". But who would use a codec like that? Besides Google, of course.
Companies do this all the time. Anyone shipping H.264 has this risk, as the patent pool provides zero guarantee no outside patents will pop up.
Actually, anyone shipping anything at all has this risk.
Realistically, it's more like "does not infringe any known patents, or has licenses for them, and is not infringing any other patents that we could find in a patent search".
Yes, it's the same thing. A low-delay codec like Opus minimizes the decode-to-presentation delay, from something around 94ms for HE-AAC to 22ms (or lower) for Opus.
Again in video (say H.264) terms, this is a bit like a Baseline Profile (without delay-inducing B-frames) beating a High Profile codec.
If you would have RTFA, you would have seen that the actual p value was smaller than 0.000 (99.99%) , not smaller than 0.050 (95%). This even accounts for all comparisons being performed, so the famous xkcd green jelly beans comic does not apply.
Opus is better than Vorbis (p=0.000)
Opus is better than Nero_HE-AAC (p=0.000)
Opus is better than Apple_HE-AAC (p=0.000)
You would also have seen that your "higher bitrate" comment makes no sense, because all codecs were run with settings that average 64kbps on a large corpus of music. The fact that some codecs ended up with slightly higher or lower bitrates on the (much smaller) selected sample does not change that. The full reasoning is again explicitly explained in TFA.
Vorbis predates HE-AAC by several years, so staying competitive with what used to be one of the best HE-AAC encoders before Apple started working on theirs ain't bad at all.
Parent post is complete bullshit. HE-AAC greatly outperforms LC-AAC at 64kbps. This can be seen in several previous listening tests, including the ITU ones that standardized the format itself.
Might one downside be that no single repository has the full history of all possible paths that all devs took, and failed/not ready experiments?
No. Experience says that with a single repository, the developers often just don't commit stuff they don't feel is ready to make public. It gets worse when the centralized system is slow, because there's even less incentive to commit early-commit often then. That makes the problem, and the risk to lose stuff, worse. So the ability to always quickly commit "dirty" stuff is an advantage for distributed version control, not a disadvantage.
Also, any "gotchas" for folks coming from the venerable cvs/svn background?
Yes, because you don't have to wait ages for a "commit" operation to complete on an overloaded server or a slow connection, you will have less free time to post on slashdot. This is a significant disadvantage.
No, it's a massive, gargantuan advantage. Unless you somehow have a repo that is bigger than your disk, in which case: "you're doing it wrong".
Advantages for this scenario: - Speed of all interactions with the version control system is independent of networks speed (or amount of developers - it scales) - Developers can continue working if the remote network or the repository server goes out (with different timezones, this gets more important) - Better branch+merge support helps when there is potentially less direct coordination between devs
Seconded. IRC works great for group discussions. Most IRC software is also very customizable in what messages should cause it to pop up or alter you, so you can continue working concentrated when needed. You can easily move from group discussion to 1-on-1 or seperate chats if needed.
You can also leave an IRC client running and see discussions that happened when you were away/asleep, which is nice if there are timezone differences.
I've used Jabber on a previous job, because this was supposedly more secure, but I don't think there's any advantage over IRC+SSL.
Skype doesn't work as well in my experience, as it's less customizable. During the working day, I want to have my colleagues able to interrupt me, but not my friends. Separate accounts isn't really a good solution for that. Maybe there's add-ons for that?
Slashdot Mirror
They said that for Battlefield BC2 too ("dedicated servers are a given for the PC"), and see what you actually got: the "right" to rent a server at a few selected hosters, i.e. the right to pay their hosting bills for them. What a scam.
So please, don't buy the hype from DICE. We'll see how well they support the PC when they actually release it. And their reputation from the last release speaks against them.
They found him through a courier. So actually, email did get him killed, sortof.
Forcing users to a standardized and completely controlled hardware platform allows for easier software development and less potential configuration issues. It also arbitrarily allows blocking competitors or potential competitors out. And after a while you jack prices way up above production cost and hope you get away with it because your users are bunnies that don't like to think for themselves.
They must be thinking "Apple is doing well with this, let's try it too!".
Google, if your motto is "Don't be evil", you're doing it wrong. At least Microsoft didn't try to control your hardware.
Good point. That would kinda spoil the Samsung/Android party.
OTOH, promoting non-x86 is very contrary to past Intel strategy. That's why they sold off their old ARM business, for starters.
that's 140 million dollars in sales in the most recent quarter on iPads alone (nevermind iphones or ipods).
You may call that drop in the bucket if you want, but I don't Samsung is going to.
Sure, but they sold over 10 million of the Android phones Apple is pissed about (Galaxy S), at what, 400 bucks each? So that's over twice as much, for one model alone.
Yes, but it's not a vindictive type of thing - it's strategy. "Well Samsung, you have a bit more to lose if you stay on your present course.
How big is the revenue Samsung gets from making Apple devices, percentagewise? It should be tiny compared to all of their business, right?
And the revenue they get from their own Android devices? Is it even less than they get from Apple? After all, the margins on them should be much better for Samsung.
I have some problems believing Samsung would be at all impressed by this, but maybe the numbers I have in my head are off.
Probably because (quoting Wikipedia): "P. A. Semi (originally "Palo Alto Semiconductor"[1]) was a fabless semiconductor company"
You still need a fab. Apple already knows how to design CPUs.
They sold off all of that to Marvell, so it's still unlikely.
Not everybody is a patent troll, you know. Some companies prefer the formats to be used so they can sell hardware or software rather than litigation protection rackets.
or face litigation
This can only happen when (1) There are patents (2) They're held by a company not bound to whatever patent pledge was given.
In other words, the situation is exactly the same as before.
H.264 is safer to use
Citation needed.
you have to pay license fees if your software encodes to H.264
And you don't know how much to whom yet, but you are already guaranteed a small part will be to the MPEG-LA. There are no other guarantees.
How is this safer? It isn't.
The important thing is the royalty free part.
See, there are 2 kinds of reasons to contribute to these codecs: 1) to collect license fees 2) to actually sell products that use them.
For the companies in (2), the license fees are a nuisance that potentially stops their products from getting more widespread acceptance. This is why some big guys, which are mostly (2), already joined Google. Even if they gain from the license fees, its much smaller than the actual product sales. They tend to be in the MPEG-LA only because that makes it cheaper to do (2), not because they want (1).
So, if you revenue "depended on video codecs", the critical question is if your revenue is coming only from the patents (also called "patent troll") or if you were actually making products.
Has MPEG-LA caused any troubles
They've been spewing FUD about creating a licensing pool for VP8. If Google was right wrt. VP8 rights, that pool could only contain invalid patents. So it would have been interesting to see if anything really showed up in there. So far nothing turned up in the MPEG-LA pool, but the threat that this could happen is FUD to stop VP8/WebM.
So now Google is spewing back some counter-FUD.
tl;dr
It's quite comparable in complexity, but it's less likely to have (full) hardware acceleration support for the decode. Some parts of H.264 decoders would be reusable, though.
Then again, if your laptop is so old that decoding a video overheats it, it probably didn't have it for H.264 either.
Am I misunderstanding, or is the headline "open codec designed for voip is slightly better for voip than closed codec designed for music"? How does it compare to the other voip codecs?
The test wasn't about VoIP but about music. The VoIP codec beat the others at their game.
I would guess that this codec is very likely to gain hardware support, particularly as it's being standardized by the IETF *and* Broadcom seems to have been contributing to the development of it.
This would mean that during Skype calls, the decoding no longer has to be done in software, so battery time when using Skype on a mobile device could increase a lot.
I'm just guessing!
Perhaps they could switch to "has not yet been challenged in court for any possible patent infringement". But who would use a codec like that? Besides Google, of course.
Companies do this all the time. Anyone shipping H.264 has this risk, as the patent pool provides zero guarantee no outside patents will pop up.
Actually, anyone shipping anything at all has this risk.
Realistically, it's more like "does not infringe any known patents, or has licenses for them, and is not infringing any other patents that we could find in a patent search".
Yes, it's the same thing. A low-delay codec like Opus minimizes the decode-to-presentation delay, from something around 94ms for HE-AAC to 22ms (or lower) for Opus.
Again in video (say H.264) terms, this is a bit like a Baseline Profile (without delay-inducing B-frames) beating a High Profile codec.
If you would have RTFA, you would have seen that the actual p value was smaller than 0.000 (99.99%) , not smaller than 0.050 (95%). This even accounts for all comparisons being performed, so the famous xkcd green jelly beans comic does not apply.
Opus is better than Vorbis (p=0.000)
Opus is better than Nero_HE-AAC (p=0.000)
Opus is better than Apple_HE-AAC (p=0.000)
You would also have seen that your "higher bitrate" comment makes no sense, because all codecs were run with settings that average 64kbps on a large corpus of music. The fact that some codecs ended up with slightly higher or lower bitrates on the (much smaller) selected sample does not change that. The full reasoning is again explicitly explained in TFA.
Vorbis predates HE-AAC by several years, so staying competitive with what used to be one of the best HE-AAC encoders before Apple started working on theirs ain't bad at all.
Parent post is complete bullshit. HE-AAC greatly outperforms LC-AAC at 64kbps. This can be seen in several previous listening tests, including the ITU ones that standardized the format itself.
Might one downside be that no single repository has the full history of all possible paths that all devs took, and failed/not ready experiments?
No. Experience says that with a single repository, the developers often just don't commit stuff they don't feel is ready to make public. It gets worse when the centralized system is slow, because there's even less incentive to commit early-commit often then. That makes the problem, and the risk to lose stuff, worse. So the ability to always quickly commit "dirty" stuff is an advantage for distributed version control, not a disadvantage.
Also, any "gotchas" for folks coming from the venerable cvs/svn background?
Yes, because you don't have to wait ages for a "commit" operation to complete on an overloaded server or a slow connection, you will have less free time to post on slashdot. This is a significant disadvantage.
No, it's a massive, gargantuan advantage. Unless you somehow have a repo that is bigger than your disk, in which case: "you're doing it wrong".
Advantages for this scenario:
- Speed of all interactions with the version control system is independent of networks speed (or amount of developers - it scales)
- Developers can continue working if the remote network or the repository server goes out (with different timezones, this gets more important)
- Better branch+merge support helps when there is potentially less direct coordination between devs
Disadvantages:
Seconded. IRC works great for group discussions. Most IRC software is also very customizable in what messages should cause it to pop up or alter you, so you can continue working concentrated when needed. You can easily move from group discussion to 1-on-1 or seperate chats if needed.
You can also leave an IRC client running and see discussions that happened when you were away/asleep, which is nice if there are timezone differences.
I've used Jabber on a previous job, because this was supposedly more secure, but I don't think there's any advantage over IRC+SSL.
Skype doesn't work as well in my experience, as it's less customizable. During the working day, I want to have my colleagues able to interrupt me, but not my friends. Separate accounts isn't really a good solution for that. Maybe there's add-ons for that?
Sadly, it's an obvious DMCA violation that could put the poster in trouble, isn't it?