There is no such thing as truly fair, reasonable and non-discriminatory in software. This is known an 'RAND' in other circles, and what it usually means is: (patent) license fee applies, same rate to everyone. This instantly discriminates against free implementations, because they're basically excluded. This famously came up in Web standards back in 2000, with the W3C being pro-RAND. This nearly resulted in them being disbanded, because their entire purpose was a free web, not a closed one.
The word 'Open' has completely lost its meaning in recent years, and this year in particular it's had a final assault against it. You can declare anything as 'Open' so long as you make a passing gesture at documentation. That documentation can even be under 'RAND' license (you have to pay to see it, but hey, everyone pays equally to see it, e.g ISO standards). The content protection keys aren't open (they're secret). The implementation isn't necessarily 'open' because there are restrictions on what you can and can't implement.
The more this comes up, the more I agree with folks who say 'Open' is often a way to misrepresent something as more 'Free' than it is. It has turned into a marketing bullet point. Hell, even Skype just announced an 'Open' version of their library for Linux (binary blob, license restriction, implementation restriction, er, why the fuck is that called open?)
So back on subject: Project Canvas sounds all very nice, but to me it sounds like a Closed, Licensed, Restricted but Documented system. The BBC should absolutely research IPTV standards, but not a system like this. Leave inventing DRM to Big Business. BBC, what do you think your entire purpose is?
No, it is true. At idle it's in the same ballpark as ARM SoCs. At peak performance, it's faster, but it's (not exaggerating) an order of magnitude worse performance/power. That means at every point on the graph above idle, Moorestown is worse performance/power than ARM - the only thing in its favor is its graph carries on to the right a bit further. The problem is nobody needs that section to the right of where ARM stops.
Partial BS. Moorestown has idle power numbers competitive with ARM.
It's partial BS from Intel too. They haven't released enough information to make anything from their figures. (See one of my other posts) They've very carefully not drawn enough dots to connect anything together - notably they omit the size of the battery they're talking about when they say how many hours they can do things. Easily missed by a journalist, but an obvious half truth in the eyes of an engineer.
But even if they do (optimistically) end up with the same idle power consumption as ARM SoCs, that just means their baseline is the same. At every fraction of CPU usage above idle, they'll be worse than ARM. These devices spend an increasingly large fraction of their time actually doing stuff. That's where the DMIPS/mW comes in, and Intel just isn't there yet, by a very wide margin.
I'm afraid your numbers are off by orders of magnitude. A raw Cortex A8 core idles in microwatts, not even in milliwatts. The SoC itself will be idling - with keepalive of radios etc - somewhere more realistically on average 10-50mW depending on the device. The figures Intel give are drawn up by weasels: the power consumption of 25mW they state for a system playing MP3s is with the Intel core basically switched off and the IO processor doing all the work (which is, and I'm sure this is too ironic to be true, rumored to be an ARM).
I'm sure you can get an Atom based handset idling at roughly the same power cost as an ARM based one. That just means they've got their silicon process finally optimized for power, not performance, and Intel has a huge advantage in general when it comes to this stuff. But that's not where all the interesting stuff is. It's the realm somewhere-between-idle-and-peak where all the efficiency counts: browsing a web page, flipping through contacts, playing a game, watching a video. That's where efficiency really counts, and Atom will struggle. Again, Intel has very carefully provided "number of hours of playback" for some figures and "watts" for others, but never "battery size". So they've made very sure you can't connect the dots and get a power figure for any of those tasks.
Guess we'll have to wait and see, but I'm not holding my breath. Even the most optimistic interpretation says they're competitive with handsets... from about 5 years ago.
In terms of performance per Watt, the Core i7 family beats ARM significantly, last I checked. In terms of idle performance, the ARM tears it up, of course, coming in at a quarter watt versus about ten times that for the Core 2 Duo. The Atom, in turn, slaughters comparable ARM CPUs in idle power, with comparable performance-per-watt, but has lower total performance-per-clock, IIRC.
Bizarro world, apparently. I just searched for the DMIPS/mW figures for a Core i7 and an ARM Cortex A8. Guess what, the first clue is that the Core i7 is listed in DMIPS/Watt. A Core i7 is about 1DMIPS/mW, while a Cortex A8 is about 16DMIPS/mW. The ARMs are an order of magnitude more efficient. I didn't really have to search - it's common knowledge in the industry and it's always funny seeing Slashdot articles and posts which haven't got this yet.
The Atom is still nowhere near: about 2DMIPS/mW. Even that sucks for idle consumption compared to pretty much anything ARM even from 5 years ago. Most ARM SoCs made for a portable device idle - and we're talking total system with background processing here - somewhere between 5-50mW depending on whether you're talking about an MP3 player or a big tablet. The clue, as always, is that Intel stuff is talked about in Watts, not milliwatts.
Basically the only thing Intel CPUs are better at is peak performance, and by a large margin. Not performance/watt. Not idling. Atom, when we're talking complete system, doesn't even have a peak performance advantage compared to Cortex-A9 based SoCs. And all that peak in an Core i7 goes to waste because you just don't need it for the target devices.
Android is 100% open source. Don't like the Market? Replace it. Don't like the keyboard? Replace it. Don't like Google integrations? Remove them.
Except that, for the vast majority of Android handsets, you can't actually do that. You're missing one essential piece of source code: the private key you need to sign binaries with.
You're also missing the source to the baseband, many drivers (just binary blobs), boot loader, and even the Google apps themselves. 'Open' is really getting used inappropriately these days.
It's because the controller operates at a level below file system. It sees raw sectors, not files. It would be wrong for it to infer anything about the data contained in sectors.
The 'trim' command is to tell the flash controller which sectors become free in the file system. The next time you write data, rather than it shuffling around data to wear level, it can just erase and overwrite an already free block. Flash controllers which don't support this will eventually always have to do a 'swap' or some other shuffling of block data once every sector of flash has been written to. This is slow.
There's no other way for this to work other than the flash controller handling the file system, which is a bad idea for many reasons.
It dismays me that whenever I (in other circumstances) also claim that the US is the only country to have used a nuke on an enemy, someone says something along the lines of "it wasn't really a nuke". It doesn't matter that they were small yield. They still pretty much wiped out a large part of both cities and irradiated the surrounding areas in a single blast.
But they were only small nukes, so I guess they don't count?
The only saving grace of this mentality is that it reveals people are still ashamed that this ever occurred. So ashamed they're trying to twist the logic so it appears it never happened.
This sounds absolutely no different to how all wear-leveled, error correcting flash controllers work. They all use multiple levels of ECC to decrease the error rate. The 'signal processing' they're doing doesn't sound like anything new.
If there is something new going on here, it's absolutely impossible to decode from the layman's language used in the article. All I hear is "Other vendors use X bits for ECC. We use Y bits and we do it in software instead of hardware.", which is basically just another way of saying "Other vendors have 4 blades, we have 5 blades."
Actually, it's trolls like you who are breaking Slashdot. Not that one person makes much difference. You're adding to the breakage because you're allowed to post more than people can down-mod you.
I mean, your post history is there for everyone to see, and it's not a pretty record - you obviously have morality and empathy issues.
That's the issue. Loosely, "3G" tends to indicate that service has serious provision for data but is still largely voice, while "4G" indicates a service is data-oriented. There's huge overlap between all the competing systems in bandwidth, coverage, latency and features (e.g shared voice+data). Hell, even "2G" (GSM) can be faster than "4G" when your 4G signal is very weak. The current AT&T vs Verizon spat is pretty much dictionary definition Strawman.
It's most obvious when you talk about Verizon and, well, pretty much everyone else's "3G". They're not even running the same modulation scheme or protocols. And sadly it seems the same will happen with "4G" as there's WiMax competing with LTE.
The funny thing is this is almost entirely a US-only issue. I'm sure there's some outliers, but otherwise the entire of Europe, and I think most of the rest of the world uses UTMS/HSPA for 3G and is going LTE for 4G. I can't think of anywhere else apart from the US (and strangely, Iraq due to, ahem, presidential order, despite every surrounding country using an incompatible system) that uses CDMA2000, EVDO, or WiMax (except 1 carrier in Sweden?)
It's pretty much only possible in the US due to the tight carrier-vs-phone contracts you get.
There, fixed that for you. In most countries, as far as the law is concerned, mistakenly breaking the law does not absolve you.
In most countries, people who mistakenly, unintentionally break with law, with no actual harm done and corrective action taken, are not pursued. It's a waste of time: enforcement isn't going to make anyone safer, it won't prevent another occurrence (it was never intended anyway and there were safeguards that simply failed), and it'll cost the taxpayers money for a pointless, very obviously politically motivated action.
Sure, if you pick a suitably low-end Xeon. Not sure why I'm bothering to reply to that.
All AM2/AM3 AMD motherboards I know of support ECC. In fact, all the Intel motherboards too - it's just that the ECC block is purposefully disabled in the Core i7 for no reason other than market segmentation.
This is a big reason I picked an AMD Phenom II over a Core i7 recently. To get ECC support from Intel, you need to buy a Xeon, at which point they charge you an extra $800-$1000 for the gates to be enabled. Screw that, I'll go with a chip 80% cheaper and 10% slower.
I hadn't considered a packet being split into multiple segments, because that would make even less sense for low-latency streaming. The case I'm thinking of is:
No packets crossing pages.
Segment == packet.
A small number of packets per page (e.g 4).
However, there's still just 1 CRC per page. This means that the demux must wait until all 4 packets are entirely received (the entire page) before it is allowed to pass the contents on to the decoder layer.
If CRC were not mandatory, or you ignored it, then the demux could pass each packet along as it's received instead of waiting for the link to receive all of them.
On the sender's side, the CRC being before the data also means you need to buffer up the entire page before it can be transmitted. However, there's bigger problems here, such as the lacing values not being available until the size of each packet is known. There's no decent solution to that, other than moving the packet size fields to being placed between packets. That has its own problems and advantages.
None of this is an issue if you restrict to 1 packet per page, and I guess you could just ignore the CRC, but it is something about the design that doesn't help.
My rant with Ogg is not so much the minute details of the format itself but that it works badly in a few common real world cases:
Resizing metadata. It's stored at the beginning, so resizing the metadata requires moving the majority of the file around (or rewriting it).
Metadata growing across a page boundary (64KB). Not unlikely if you're storing anything substantial such as album art. I know, that's slightly abusing it, but it's convenient to go there and it's common practice. The trouble is this affects the page numbering, requiring every page in the stream to be renumbered, and then every page including its contents to have its CRC recalculated. Very expensive.
No index. Seriously, why can't we have an index? It doesn't have to be at the beginning of stream - the end is fine too. Which leads me to...
Random access video across a high latency link. Think that's uncommon? What about cell phones playing a web-hosted video, where 1000ms+ is the norm? Or even laptops with a 3G access dongle? An index (even a small one) mitigates the issue, even if placed at the end of stream.
Mandatory per-page CRC forces low-latency streaming to use single packet per page. Demux cannot continue before an entire page is received, which increases latency by the number of packets in a page (minus 1). Per-packet or even no CRC would be more appropriate.
I know it's all been said before, but these are pretty common cases and Ogg isn't great when you have to deal with them. Everything else is nit-picking. I'm not a fan of the minute details of the format either, to be honest, but the above are real world examples of where it falls a little short. I should add that none of these issues make it unusable in any of those situations: just annoying.
This keeps getting brought up, and people keep regurgitating the same bad information. Here's the facts:
Most smartphones sold in the last 2 years will manage QVGA (320x240x25fps) Theora in software-only, no problem.
High-end smartphones (3GS, Nexus, etc) will manage VGA (640x480) Theora, with a bit of help from dedicated YUV to RGB conversion.
720p and high bitrate Theora streams need hardware acceleration on even the fastest smartphones. Do you really care if your mobile phone is only playing back in 480p?
Theora is about 10-20% less quality for same bandwidth. There's a lot of really bad comparisons out there, the most popular of which make mistakes such as comparing streams even an iPhone 3GS can't play (H.264 in stupidly high profiles). For normal usage, 10-20% less quality is perfectly fine. Again, do you really care about that 10-20% on your mobile phone?
The power consumption difference between pure software and hardware accelerated implementations is small. There's other big power users such as the radio and the backlight. Don't get me wrong: it's worth doing, but people shouldn't view the (guesstimate) 20% difference in battery time as a deal-breaker. Again, hyperbole turns this into 'totally unusable' in some people's minds.
It's Slashdot hyperbole and trolling again. I know I fall into that trap myself, but being slightly behind the best does not translate to totally useless. On the contrary: being a format that can potentially be used universally by any platform is a HUGE advantage that more than outweighs the slight difference in quality.
Which comparison page? I don't recall mentioning one.
Why do you want 720p playback on a mobile device? Ok, if your screen is at least 720p, but they're the vast minority, and the bandwidth required is still fairly severe for all but the best 3G+ links. 480p is a perfectly reasonable baseline that the vast majority of people would prefer rather than having nothing at all.
Like GP said, WebKit is basically just the work of the KHTML devs. Apple leeched off of their work.
If by 'leeched' you mean they took an existing open project, modified and extended it, then released that work for free. I guess if you redefine leech then yes they leeched it.
I hope Mozilla gets a clue about their video tag implementation while they still have a chance. It is quite obvious that sites want HTML5 but they also want to stream h264. If Mozilla doesn't provide a way to do this, the browser is going to get sidelined.
You're asking an organization setup to promote free-as-in-freedom software, a charity, to simply get over themselves, turn it into a free-as-in-beer project, and break with their ethics.
Google knew what they were doing when they went with H.264 (I even shouted very strongly about this while I worked there). The combination of Chrome existing whatsoever, and moving to a patent encumbered format, is hurting a free software organization, and it's not something they should be proud of achieving.
Mozilla can certainly afford the $5m cap on H.264 licensing fees given that they get over ten times that annually from Google alone.
A pointless figure to give, because Mozilla cannot pay the fee without going against everything they stand for. It's supposed to be a free-as-in-freedom browser, which none of the other major competitors can claim. Even Chrome is only free-as-in-beer.
Theora cannot compete at any level with H.264; not in compression ratio, availability of hardware support, market share or industry support. The longer Mozilla decries H.264 as evil and patent-encumbered technology while at the same time offering almost automated installs for Flash, the more users will migrate to browsers that do support H.264 as websites are already starting to migrate for the iPad.
Why do people regurgitate this cruft? Theora is only slightly worse than H.264. The lack of hardware support is a red herring: for anything up to 480p you don't need hardware decode. Even smart phones can manage 480p software-only in real time (I have tried this), without too big a hit on power consumption. Not being able to decode 720p does not make it useless. It gives you a nice baseline codec you can use on any platform, and quite frankly I don't think you'll mind (much) that you're streaming YouTube videos to your phone in only 480p.
Mozilla offers automated installs of Flash because it's pretty much the first thing anyone does, and because Flash is a huge security hole if it's not installed right (i.e the latest version). Everyone wishes this wasn't necessary.
Does it seem a bit odd to anyone else that Apple of all companies is more-or-less leading the charge against Flash?
H.264 can deliver watchable video in less than 1/2 the bitrate...
A fair comparison is more like 10-30% less, depending on the content. The comparisons which show 1/2 the bitrate are for an H.264 profile that most devices can't play (e.g iPhones), and that's not useful.
H.264 can deliver high quality video (at higher bitrates) that Theora can't match AT ANY RATE.
Where did you get that from? Of course it can. Unless you mean truncation artifacts? I'm guessing you didn't
H.264 can be decoded on innumerable devices.
So can Theora. You don't need hardware to decode a VGA 30fps Theora stream on modern smartphones. It'll manage it fine entirely in software.
There are numerous implementations of H.264, and just 1 of Theora.
Is this a point in favor or against? There is only one implementation of gcc. There is only one implementation of Vorbis (actually, I've written another myself). There is only one implementation of WebKit, but hey that powers a large fraction of browsers in the world. What is this supposed to demonstrate?
H.264 is developing and improving quickly, while Theora continues to stagnate.
The H.264 specification is set in stone and won't change. Implementations for both are being actively developed. The Theora spec could change (minor or major version upgrade) just like it could for H.264. This is surely just your opinion and not fact.
Slashdot Mirror
There is no such thing as truly fair, reasonable and non-discriminatory in software. This is known an 'RAND' in other circles, and what it usually means is: (patent) license fee applies, same rate to everyone. This instantly discriminates against free implementations, because they're basically excluded. This famously came up in Web standards back in 2000, with the W3C being pro-RAND. This nearly resulted in them being disbanded, because their entire purpose was a free web, not a closed one.
The word 'Open' has completely lost its meaning in recent years, and this year in particular it's had a final assault against it. You can declare anything as 'Open' so long as you make a passing gesture at documentation. That documentation can even be under 'RAND' license (you have to pay to see it, but hey, everyone pays equally to see it, e.g ISO standards). The content protection keys aren't open (they're secret). The implementation isn't necessarily 'open' because there are restrictions on what you can and can't implement.
The more this comes up, the more I agree with folks who say 'Open' is often a way to misrepresent something as more 'Free' than it is. It has turned into a marketing bullet point. Hell, even Skype just announced an 'Open' version of their library for Linux (binary blob, license restriction, implementation restriction, er, why the fuck is that called open?)
So back on subject: Project Canvas sounds all very nice, but to me it sounds like a Closed, Licensed, Restricted but Documented system. The BBC should absolutely research IPTV standards, but not a system like this. Leave inventing DRM to Big Business. BBC, what do you think your entire purpose is?
No, it is true. At idle it's in the same ballpark as ARM SoCs. At peak performance, it's faster, but it's (not exaggerating) an order of magnitude worse performance/power. That means at every point on the graph above idle, Moorestown is worse performance/power than ARM - the only thing in its favor is its graph carries on to the right a bit further. The problem is nobody needs that section to the right of where ARM stops.
Partial BS. Moorestown has idle power numbers competitive with ARM.
It's partial BS from Intel too. They haven't released enough information to make anything from their figures. (See one of my other posts) They've very carefully not drawn enough dots to connect anything together - notably they omit the size of the battery they're talking about when they say how many hours they can do things. Easily missed by a journalist, but an obvious half truth in the eyes of an engineer.
But even if they do (optimistically) end up with the same idle power consumption as ARM SoCs, that just means their baseline is the same. At every fraction of CPU usage above idle, they'll be worse than ARM. These devices spend an increasingly large fraction of their time actually doing stuff. That's where the DMIPS/mW comes in, and Intel just isn't there yet, by a very wide margin.
I'm afraid your numbers are off by orders of magnitude. A raw Cortex A8 core idles in microwatts, not even in milliwatts. The SoC itself will be idling - with keepalive of radios etc - somewhere more realistically on average 10-50mW depending on the device. The figures Intel give are drawn up by weasels: the power consumption of 25mW they state for a system playing MP3s is with the Intel core basically switched off and the IO processor doing all the work (which is, and I'm sure this is too ironic to be true, rumored to be an ARM).
I'm sure you can get an Atom based handset idling at roughly the same power cost as an ARM based one. That just means they've got their silicon process finally optimized for power, not performance, and Intel has a huge advantage in general when it comes to this stuff. But that's not where all the interesting stuff is. It's the realm somewhere-between-idle-and-peak where all the efficiency counts: browsing a web page, flipping through contacts, playing a game, watching a video. That's where efficiency really counts, and Atom will struggle. Again, Intel has very carefully provided "number of hours of playback" for some figures and "watts" for others, but never "battery size". So they've made very sure you can't connect the dots and get a power figure for any of those tasks.
Guess we'll have to wait and see, but I'm not holding my breath. Even the most optimistic interpretation says they're competitive with handsets... from about 5 years ago.
In terms of performance per Watt, the Core i7 family beats ARM significantly, last I checked. In terms of idle performance, the ARM tears it up, of course, coming in at a quarter watt versus about ten times that for the Core 2 Duo. The Atom, in turn, slaughters comparable ARM CPUs in idle power, with comparable performance-per-watt, but has lower total performance-per-clock, IIRC.
Bizarro world, apparently. I just searched for the DMIPS/mW figures for a Core i7 and an ARM Cortex A8. Guess what, the first clue is that the Core i7 is listed in DMIPS/Watt. A Core i7 is about 1DMIPS/mW, while a Cortex A8 is about 16DMIPS/mW. The ARMs are an order of magnitude more efficient. I didn't really have to search - it's common knowledge in the industry and it's always funny seeing Slashdot articles and posts which haven't got this yet.
The Atom is still nowhere near: about 2DMIPS/mW. Even that sucks for idle consumption compared to pretty much anything ARM even from 5 years ago. Most ARM SoCs made for a portable device idle - and we're talking total system with background processing here - somewhere between 5-50mW depending on whether you're talking about an MP3 player or a big tablet. The clue, as always, is that Intel stuff is talked about in Watts, not milliwatts.
Basically the only thing Intel CPUs are better at is peak performance, and by a large margin. Not performance/watt. Not idling. Atom, when we're talking complete system, doesn't even have a peak performance advantage compared to Cortex-A9 based SoCs. And all that peak in an Core i7 goes to waste because you just don't need it for the target devices.
Android is 100% open source. Don't like the Market? Replace it. Don't like the keyboard? Replace it. Don't like Google integrations? Remove them.
Except that, for the vast majority of Android handsets, you can't actually do that. You're missing one essential piece of source code: the private key you need to sign binaries with.
You're also missing the source to the baseband, many drivers (just binary blobs), boot loader, and even the Google apps themselves. 'Open' is really getting used inappropriately these days.
It's because the controller operates at a level below file system. It sees raw sectors, not files. It would be wrong for it to infer anything about the data contained in sectors.
The 'trim' command is to tell the flash controller which sectors become free in the file system. The next time you write data, rather than it shuffling around data to wear level, it can just erase and overwrite an already free block. Flash controllers which don't support this will eventually always have to do a 'swap' or some other shuffling of block data once every sector of flash has been written to. This is slow.
There's no other way for this to work other than the flash controller handling the file system, which is a bad idea for many reasons.
But they still dropped a nuke, and are the only nation to drop a nuke on an enemy.
Word your way around it all you like, that fact still stands.
The banana equivalent dose is 0. Cell phone radiation is non-ionizing.
It dismays me that whenever I (in other circumstances) also claim that the US is the only country to have used a nuke on an enemy, someone says something along the lines of "it wasn't really a nuke". It doesn't matter that they were small yield. They still pretty much wiped out a large part of both cities and irradiated the surrounding areas in a single blast.
But they were only small nukes, so I guess they don't count?
The only saving grace of this mentality is that it reveals people are still ashamed that this ever occurred. So ashamed they're trying to twist the logic so it appears it never happened.
This sounds absolutely no different to how all wear-leveled, error correcting flash controllers work. They all use multiple levels of ECC to decrease the error rate. The 'signal processing' they're doing doesn't sound like anything new.
If there is something new going on here, it's absolutely impossible to decode from the layman's language used in the article. All I hear is "Other vendors use X bits for ECC. We use Y bits and we do it in software instead of hardware.", which is basically just another way of saying "Other vendors have 4 blades, we have 5 blades."
Actually, it's trolls like you who are breaking Slashdot. Not that one person makes much difference. You're adding to the breakage because you're allowed to post more than people can down-mod you.
I mean, your post history is there for everyone to see, and it's not a pretty record - you obviously have morality and empathy issues.
That's the issue. Loosely, "3G" tends to indicate that service has serious provision for data but is still largely voice, while "4G" indicates a service is data-oriented. There's huge overlap between all the competing systems in bandwidth, coverage, latency and features (e.g shared voice+data). Hell, even "2G" (GSM) can be faster than "4G" when your 4G signal is very weak. The current AT&T vs Verizon spat is pretty much dictionary definition Strawman.
It's most obvious when you talk about Verizon and, well, pretty much everyone else's "3G". They're not even running the same modulation scheme or protocols. And sadly it seems the same will happen with "4G" as there's WiMax competing with LTE.
The funny thing is this is almost entirely a US-only issue. I'm sure there's some outliers, but otherwise the entire of Europe, and I think most of the rest of the world uses UTMS/HSPA for 3G and is going LTE for 4G. I can't think of anywhere else apart from the US (and strangely, Iraq due to, ahem, presidential order, despite every surrounding country using an incompatible system) that uses CDMA2000, EVDO, or WiMax (except 1 carrier in Sweden?)
It's pretty much only possible in the US due to the tight carrier-vs-phone contracts you get.
There, fixed that for you. In most countries, as far as the law is concerned, mistakenly breaking the law does not absolve you.
In most countries, people who mistakenly, unintentionally break with law, with no actual harm done and corrective action taken, are not pursued. It's a waste of time: enforcement isn't going to make anyone safer, it won't prevent another occurrence (it was never intended anyway and there were safeguards that simply failed), and it'll cost the taxpayers money for a pointless, very obviously politically motivated action.
Sure, if you pick a suitably low-end Xeon. Not sure why I'm bothering to reply to that.
All AM2/AM3 AMD motherboards I know of support ECC. In fact, all the Intel motherboards too - it's just that the ECC block is purposefully disabled in the Core i7 for no reason other than market segmentation.
This is a big reason I picked an AMD Phenom II over a Core i7 recently. To get ECC support from Intel, you need to buy a Xeon, at which point they charge you an extra $800-$1000 for the gates to be enabled. Screw that, I'll go with a chip 80% cheaper and 10% slower.
It talks about high latency. It doesn't solve it.
I hadn't considered a packet being split into multiple segments, because that would make even less sense for low-latency streaming. The case I'm thinking of is:
However, there's still just 1 CRC per page. This means that the demux must wait until all 4 packets are entirely received (the entire page) before it is allowed to pass the contents on to the decoder layer.
If CRC were not mandatory, or you ignored it, then the demux could pass each packet along as it's received instead of waiting for the link to receive all of them.
On the sender's side, the CRC being before the data also means you need to buffer up the entire page before it can be transmitted. However, there's bigger problems here, such as the lacing values not being available until the size of each packet is known. There's no decent solution to that, other than moving the packet size fields to being placed between packets. That has its own problems and advantages.
None of this is an issue if you restrict to 1 packet per page, and I guess you could just ignore the CRC, but it is something about the design that doesn't help.
My rant with Ogg is not so much the minute details of the format itself but that it works badly in a few common real world cases:
I know it's all been said before, but these are pretty common cases and Ogg isn't great when you have to deal with them. Everything else is nit-picking. I'm not a fan of the minute details of the format either, to be honest, but the above are real world examples of where it falls a little short. I should add that none of these issues make it unusable in any of those situations: just annoying.
This keeps getting brought up, and people keep regurgitating the same bad information. Here's the facts:
It's Slashdot hyperbole and trolling again. I know I fall into that trap myself, but being slightly behind the best does not translate to totally useless. On the contrary: being a format that can potentially be used universally by any platform is a HUGE advantage that more than outweighs the slight difference in quality.
Which comparison page? I don't recall mentioning one.
Why do you want 720p playback on a mobile device? Ok, if your screen is at least 720p, but they're the vast minority, and the bandwidth required is still fairly severe for all but the best 3G+ links. 480p is a perfectly reasonable baseline that the vast majority of people would prefer rather than having nothing at all.
Like GP said, WebKit is basically just the work of the KHTML devs. Apple leeched off of their work.
If by 'leeched' you mean they took an existing open project, modified and extended it, then released that work for free. I guess if you redefine leech then yes they leeched it.
I hope Mozilla gets a clue about their video tag implementation while they still have a chance. It is quite obvious that sites want HTML5 but they also want to stream h264. If Mozilla doesn't provide a way to do this, the browser is going to get sidelined.
You're asking an organization setup to promote free-as-in-freedom software, a charity, to simply get over themselves, turn it into a free-as-in-beer project, and break with their ethics.
Google knew what they were doing when they went with H.264 (I even shouted very strongly about this while I worked there). The combination of Chrome existing whatsoever, and moving to a patent encumbered format, is hurting a free software organization, and it's not something they should be proud of achieving.
Mozilla can certainly afford the $5m cap on H.264 licensing fees given that they get over ten times that annually from Google alone.
A pointless figure to give, because Mozilla cannot pay the fee without going against everything they stand for. It's supposed to be a free-as-in-freedom browser, which none of the other major competitors can claim. Even Chrome is only free-as-in-beer.
Theora cannot compete at any level with H.264; not in compression ratio, availability of hardware support, market share or industry support. The longer Mozilla decries H.264 as evil and patent-encumbered technology while at the same time offering almost automated installs for Flash, the more users will migrate to browsers that do support H.264 as websites are already starting to migrate for the iPad.
Why do people regurgitate this cruft? Theora is only slightly worse than H.264. The lack of hardware support is a red herring: for anything up to 480p you don't need hardware decode. Even smart phones can manage 480p software-only in real time (I have tried this), without too big a hit on power consumption. Not being able to decode 720p does not make it useless. It gives you a nice baseline codec you can use on any platform, and quite frankly I don't think you'll mind (much) that you're streaming YouTube videos to your phone in only 480p.
Mozilla offers automated installs of Flash because it's pretty much the first thing anyone does, and because Flash is a huge security hole if it's not installed right (i.e the latest version). Everyone wishes this wasn't necessary.
Does it seem a bit odd to anyone else that Apple of all companies is more-or-less leading the charge against Flash?
No.
None of this is true:
H.264 can deliver watchable video in less than 1/2 the bitrate...
A fair comparison is more like 10-30% less, depending on the content. The comparisons which show 1/2 the bitrate are for an H.264 profile that most devices can't play (e.g iPhones), and that's not useful.
H.264 can deliver high quality video (at higher bitrates) that Theora can't match AT ANY RATE.
Where did you get that from? Of course it can. Unless you mean truncation artifacts? I'm guessing you didn't
H.264 can be decoded on innumerable devices.
So can Theora. You don't need hardware to decode a VGA 30fps Theora stream on modern smartphones. It'll manage it fine entirely in software.
There are numerous implementations of H.264, and just 1 of Theora.
Is this a point in favor or against? There is only one implementation of gcc. There is only one implementation of Vorbis (actually, I've written another myself). There is only one implementation of WebKit, but hey that powers a large fraction of browsers in the world. What is this supposed to demonstrate?
H.264 is developing and improving quickly, while Theora continues to stagnate.
The H.264 specification is set in stone and won't change. Implementations for both are being actively developed. The Theora spec could change (minor or major version upgrade) just like it could for H.264. This is surely just your opinion and not fact.