> The analysis over at Dark Shikari's blog was conclusive in saying that VP8 is basically a > poor mans H.264,
Not quite. H.264 is actually 3 specs in one (or rather three specs which allow one to use more and more features of H.264): Baseline profile, Main profile, and High profile. The review you link to tries to compare to all three at once and says that VP8 is somewhat better than Baseline, a bit worse than Main, and somewhat worse than High.
What does this mean in practice? Pretty much all the H.264 on the web is Baseline profile, since that's what cell phones tend to be able to decode in hardware (for example, the iPhone 3GS claims to only support H.264 Baseline profile over at http://www.apple.com/iphone/specs.html ).
So either you use H.264 Baseline (which is somewhat worse quality than VP8) or you don't get that "hardware acceleration" that people keep touting as a reason to use H.264. Of course it's not like you get hardware acceleration of VP8 today. We'll see what profiles of H.264 are supported when phones with hardware accelerated VP8 start shipping.
You just don't seem to be getting it. All I said was that the reason that the packet frequency is as high as it is in this case is because of a fundamental design decision with mDNS and the way wireless networks operate, not because someone purposefully set some sort of packet send timer to fire every 200ms. Anything else you choose to read into that is your problem.
> The idea that "WiFi doesnt have broadcast functionality" is lost on me.
Ethernet has the concept of a "broadcast packet". You put a single packet on the wire, set its destination address to the broadcast address, and the network stack on every single machine on the same wire as you gets the packet (normally the NIC would filter out packets addressed to IPs other than its own, but the broadcast IP is special).
802.11, on the other hand, doesn't have a useful concept of "put a packet on the wire" that would apply in the way it does to ethernet. Each of the devices on the network effectively has an individual point-to-point connection to the access point, at least as I understand. So to simulate a broadcast packet, a whole bunch of actual radio messages have to be sent.
> I don't care what excuse there
I think you need to check the difference in definitions between "reason" and "excuse".
> Imagine that instead of 21 sources, its 100 sources?
Then your network starts collapsing, if they're all on a single access point. Of course a competently set up network that has to handle that many people typically has more than one access point.
> Does that mean 20+ packets per second per machine?
If there were 4+ packets/s with 21 sources, then with 100 sources you would expect about 100+ packets/s in this situation.
The upshot of which is, if you're going to have broadcast packets over 802.11, then you need to be very careful with the number of clients per access point; otherwise it's easy to saturate the network. Or the other way around, you shouldn't use broadcast much if you can avoid it.
Unfortunately, mDNS is designed for your typical home use situation, where the expected number of sources is 5. It works fine in that situation; it just starts to break down when used in large gatherings.
21 sources, right? Sending broadcast packets on a WiFi network? But WiFi has no concept of broadcast packets; these are simulated by the access point transmitting the packet to each wireless client individually.
The question is what tcpdump (which was used to create the logs) would show here. Would it show one broadcast packet? Or 22 separate packets (1 from source to AP, and 21 from AP to destinations)? I think last time I tried (when mDNS traffic from a few hundred laptops all in one room was totally swamping the one access point) it was the latter... but I could be misremembering.
If the latter, then looks like the actual send rate for any given machine is about 1 packet every 6 seconds. But the quadratic growth in number of actual packets in the air due to lack of real broadcast packets makes things suck.
Firefox development versions don't have this issue. The last shipped release does. But were you comparing apples (cutting edge development builds) to oranges (releases that shipped a while back)?
Of course neither is the MPEG-LA for H.264 use... if someone who isn't an MPEG-LA member shows up with a patent affecting H.264, and you're using H.264, you lose.
The point is that most European countries are not in that situation wrt the patents in question. Poland seems to be an exception. Which means that you could create a browser that uses an unlicensed H.264 decoder legally in Poland, but a user in, say, Germany who runs that browser would be liable if the MPEG-LA decided to sue him
1) Webkit provides an HTML/XML/DOM/CSS renderer, period. Gecko provides that plus a
networking library, SSL implementation, and so forth, on most platforms. To create a
usable browser on top of webkit you have to provide all those components. But if you
have to custom-write them anyway for your crazy hardware or OS, then the existing Gecko
implementations don't do you much good. Also, if you want to do something very
different from what the existing infrastructure in Gecko is set up to do in terms of
document navigation, etc, then the existing functionality might get in your way
instead of helping. 2) Webkit is perceived as being simpler and easier to hack than Gecko. It's not clear to
me how much truth there is to this perception nowadays; back when Apple picked khtml I
think it was more true. 3) Webkit has better PR in some ways. It's been actively marketed to developers more
than Gecko has. 4) People seem to have a double standard on embedding the two (e.g. demanding binary
compatibility out of Gecko across releases but not making any such demands on Webkit
for some reason). 5) There are existing Gecko-based browsers on mobile devices (e.g. the n810 and n900
default browser is Gecko-based).
For apple's original decision to use khtml, I believe it was a combination of #2 above and wanting something they would have more of a chance of controlling (hence the forking that happened).
I can assure you that modern web browsers are not written in drag-and-drop IDEs.
I can also assure you that there's a good bit of very low-level optimization work going on in them (L2 cache profiling, trying to squeeze every single cycle out of hot paths, etc).
The one issue is that most people want their web browser to be a language runtime, media player, image viewer, text editor (with spellchecker), and HTML editor. They also expect realtime graphics rendering of arbitrarily complicated scenes, even ones coded in brainless ways. Plus of course actual document layout (including advanced typography features, but not including good line-breaking.... yet).
All of that comes at memory cost. Inlining on hot paths leads to faster but bigger code. Aggressive caching of various sorts to get the needed performance leads to more heap memory usage. That spellcheck dictionary needs to live somewhere. So do all those DOM and layout data structures. CSS requires computing the value of each CSS property (all several hundred of them) for every element in the DOM (all several thousand of them on many websites). Web browser try to optimize this to some extent, but complexity management sets in at some point and clear slightly less optimal code wins out over write-only "optimal" code that stops being optimal next month when a new CSS property is added.
OK; it's possible that the Polish patents on the list are for pure hardware.
Note that what matters isn't only who can create encoders but also who can create decoders _and_ who can actually execute them. MPEG-LA views the use of an unlicensed encoder/decoder (which is a classification _they_ decide on) as an infringement of their patents. So if you have, say, a web browser including a decoder, then for a user to use it without threat of being sued either the decoder needs to be licensed or the user needs to be in a jurisdiction where none of the patents apply.
I think your dichotomy between "software" and "hardware" patents is a false one. There is also a class of patents on solutions to technical problems which may be implemented in software; such patents are defined as a distinct class of patent in Europe, for example. This class is where most of the "software" H.264 patents seem to fall.
> IIRC, the Mozilla Foundation is in large part responsible for H.264 not being part of the > offical HTML 5 standard
Actually, a large part of this is that W3C standards are required to be implementable royalty-free. So as long as HTML 5 is a W3C standard it can't require H.264, unless MPEG-LA licences H.264 royalty-free for purposes of HTML 5 implementation.
The patents involved are method patents, not software patents.
I'm not sure whether you meant to accuse me or the MPEG-LA of fearmongering, by the way. Care to clarify? I just abstracted a list the MPEG-LA provides.
> The browser doesn't have to implement OpenGL itself
However it does have to implement some sort of OpenGL checker (which is actually harder in some ways). Unless you enjoy having web pages send your GPU into an infinite loop, of course. Not to mention that most graphics drivers out there don't handle "invalid" OpenGL very well (read: crash, usually exploitably); needless to say one can't expect websites to stick to "valid" OpenGL.
"Most of the world" by which metric? If you weight countries by number of Firefox users, most of the world has a patent-encumbered H.264.
Unless you're laboring under the same misapprehension as the Wildfox author about the patent status of H.264. It's patent-encumbered in way more than two countries. See http://weblogs.mozillazine.org/bz/archives/020400.html
> The question is whether a bachelors from a top tier school is worth the premium you pay' > versus a bottom tier school.
That depends on the prices you pay. Note that most people don't pay sticker price or anything close to it. I've known several people for whom a top tier school was cheaper than a bottom tier one when you count in financial aid. But that's very much family-finances dependent (and even family demographics; e.g. if there is already one child in college, adding a second one doesn't double the bill).
Also note that what you're buying is not just the degree but also the connections, exposure to things you might not have encountered before, etc. Whether those are useful depends on whether you already know what you want to do when you start college and on what it is you end up doing. While no one cares much where you got your degree 5 years on, in some fields (academia, politics, certain kinds of consulting, possibly journalism, some kinds of business) it can very much matter who you made friends with during your time in college and what they're doing 5, 10, 15, 20 years after that.
Further, in some fields (the one I have experience with hear is math) a top-tier school will in fact prepare you much better for certain career paths (e.g. graduate school and academia) than a bottom-tier one. All else being equal, of course; hard work can compensate to a large extent.
> I am graduating in 2 days. 5 years of education, 2 degrees, $26k in debt, at a reputable > university in a major city (population =~ 1 million). I paid for rent and food like most > people I know, by working.
It's a lot harder to do that for universities in the middle of nowhere, for what it's worth.
$8k tuition sounds about right for a current in-state public school. It's way too low for out-of-state.
I looked at the numbers in your report. One thing to keep in mind is that those are averages; top-tier schools, including public ones, charge more than average.
From what I can see, today' top-tier private schools will run you $200k over 4 years, no $80k.
> Well, ignoring the cost of the (apparently private) school you went to,
The GP said he spent $80k over 4 years, right? That sounds like a public school to me, at least nowadays. For example, the University of Maryland is about $20k/year for tuition+fees+room+board for in-state students.
For private schools, the number nowadays is closer to $50k/year.
Back in 2001 when the GP was presumably in school the numbers were somewhat lower ($35k/yr for private schools, iirc), but it's not obvious that $80k over 4 years means a private school, sadly.
Slashdot Mirror
> The analysis over at Dark Shikari's blog was conclusive in saying that VP8 is basically a
> poor mans H.264,
Not quite. H.264 is actually 3 specs in one (or rather three specs which allow one to use more and more features of H.264): Baseline profile, Main profile, and High profile. The review you link to tries to compare to all three at once and says that VP8 is somewhat better than Baseline, a bit worse than Main, and somewhat worse than High.
What does this mean in practice? Pretty much all the H.264 on the web is Baseline profile, since that's what cell phones tend to be able to decode in hardware (for example, the iPhone 3GS claims to only support H.264 Baseline profile over at http://www.apple.com/iphone/specs.html ).
So either you use H.264 Baseline (which is somewhat worse quality than VP8) or you don't get that "hardware acceleration" that people keep touting as a reason to use H.264. Of course it's not like you get hardware acceleration of VP8 today. We'll see what profiles of H.264 are supported when phones with hardware accelerated VP8 start shipping.
You just don't seem to be getting it. All I said was that the reason that the packet frequency is as high as it is in this case is because of a fundamental design decision with mDNS and the way wireless networks operate, not because someone purposefully set some sort of packet send timer to fire every 200ms. Anything else you choose to read into that is your problem.
> The idea that "WiFi doesnt have broadcast functionality" is lost on me.
Ethernet has the concept of a "broadcast packet". You put a single packet on the wire, set its destination address to the broadcast address, and the network stack on every single machine on the same wire as you gets the packet (normally the NIC would filter out packets addressed to IPs other than its own, but the broadcast IP is special).
802.11, on the other hand, doesn't have a useful concept of "put a packet on the wire" that would apply in the way it does to ethernet. Each of the devices on the network effectively has an individual point-to-point connection to the access point, at least as I understand. So to simulate a broadcast packet, a whole bunch of actual radio messages have to be sent.
> I don't care what excuse there
I think you need to check the difference in definitions between "reason" and "excuse".
> Imagine that instead of 21 sources, its 100 sources?
Then your network starts collapsing, if they're all on a single access point. Of course a competently set up network that has to handle that many people typically has more than one access point.
> Does that mean 20+ packets per second per machine?
If there were 4+ packets/s with 21 sources, then with 100 sources you would expect about 100+ packets/s in this situation.
The upshot of which is, if you're going to have broadcast packets over 802.11, then you need to be very careful with the number of clients per access point; otherwise it's easy to saturate the network. Or the other way around, you shouldn't use broadcast much if you can avoid it.
Unfortunately, mDNS is designed for your typical home use situation, where the expected number of sources is 5. It works fine in that situation; it just starts to break down when used in large gatherings.
21 sources, right? Sending broadcast packets on a WiFi network? But WiFi has no concept of broadcast packets; these are simulated by the access point transmitting the packet to each wireless client individually.
The question is what tcpdump (which was used to create the logs) would show here. Would it show one broadcast packet? Or 22 separate packets (1 from source to AP, and 21 from AP to destinations)? I think last time I tried (when mDNS traffic from a few hundred laptops all in one room was totally swamping the one access point) it was the latter... but I could be misremembering.
If the latter, then looks like the actual send rate for any given machine is about 1 packet every 6 seconds. But the quadratic growth in number of actual packets in the air due to lack of real broadcast packets makes things suck.
Firefox development versions don't have this issue. The last shipped release does. But were you comparing apples (cutting edge development builds) to oranges (releases that shipped a while back)?
> Google is offering no patent indemnification
Of course neither is the MPEG-LA for H.264 use... if someone who isn't an MPEG-LA member shows up with a patent affecting H.264, and you're using H.264, you lose.
How is that different from the VP8 situation?
The point is that most European countries are not in that situation wrt the patents in question. Poland seems to be an exception. Which means that you could create a browser that uses an unlicensed H.264 decoder legally in Poland, but a user in, say, Germany who runs that browser would be liable if the MPEG-LA decided to sue him
There are several things at play here:
1) Webkit provides an HTML/XML/DOM/CSS renderer, period. Gecko provides that plus a
networking library, SSL implementation, and so forth, on most platforms. To create a
usable browser on top of webkit you have to provide all those components. But if you
have to custom-write them anyway for your crazy hardware or OS, then the existing Gecko
implementations don't do you much good. Also, if you want to do something very
different from what the existing infrastructure in Gecko is set up to do in terms of
document navigation, etc, then the existing functionality might get in your way
instead of helping.
2) Webkit is perceived as being simpler and easier to hack than Gecko. It's not clear to
me how much truth there is to this perception nowadays; back when Apple picked khtml I
think it was more true.
3) Webkit has better PR in some ways. It's been actively marketed to developers more
than Gecko has.
4) People seem to have a double standard on embedding the two (e.g. demanding binary
compatibility out of Gecko across releases but not making any such demands on Webkit
for some reason).
5) There are existing Gecko-based browsers on mobile devices (e.g. the n810 and n900
default browser is Gecko-based).
For apple's original decision to use khtml, I believe it was a combination of #2 above and wanting something they would have more of a chance of controlling (hence the forking that happened).
I can assure you that modern web browsers are not written in drag-and-drop IDEs.
I can also assure you that there's a good bit of very low-level optimization work going on in them (L2 cache profiling, trying to squeeze every single cycle out of hot paths, etc).
The one issue is that most people want their web browser to be a language runtime, media player, image viewer, text editor (with spellchecker), and HTML editor. They also expect realtime graphics rendering of arbitrarily complicated scenes, even ones coded in brainless ways. Plus of course actual document layout (including advanced typography features, but not including good line-breaking .... yet).
All of that comes at memory cost. Inlining on hot paths leads to faster but bigger code. Aggressive caching of various sorts to get the needed performance leads to more heap memory usage. That spellcheck dictionary needs to live somewhere. So do all those DOM and layout data structures. CSS requires computing the value of each CSS property (all several hundred of them) for every element in the DOM (all several thousand of them on many websites). Web browser try to optimize this to some extent, but complexity management sets in at some point and clear slightly less optimal code wins out over write-only "optimal" code that stops being optimal next month when a new CSS property is added.
OK; it's possible that the Polish patents on the list are for pure hardware.
Note that what matters isn't only who can create encoders but also who can create decoders _and_ who can actually execute them. MPEG-LA views the use of an unlicensed encoder/decoder (which is a classification _they_ decide on) as an infringement of their patents. So if you have, say, a web browser including a decoder, then for a user to use it without threat of being sued either the decoder needs to be licensed or the user needs to be in a jurisdiction where none of the patents apply.
And the H.264 patents aren't "software" patents under the European patent classifications. They're "method" patents.
> Here in The Netherlands (computer) algorithms cannot be patented, period.
That's not what the wikipedia article linked to from the article summary says, for what it's worth.
I should have been clearer. Those are just non-US countries in the list; there are plenty of US patents there too.
> so it hasn't been granted yet.
Interesting. That's very useful information, thank you!
http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Licensing first paragraph.
I think your dichotomy between "software" and "hardware" patents is a false one. There is also a class of patents on solutions to technical problems which may be implemented in software; such patents are defined as a distinct class of patent in Europe, for example. This class is where most of the "software" H.264 patents seem to fall.
> IIRC, the Mozilla Foundation is in large part responsible for H.264 not being part of the
> offical HTML 5 standard
Actually, a large part of this is that W3C standards are required to be implementable royalty-free. So as long as HTML 5 is a W3C standard it can't require H.264, unless MPEG-LA licences H.264 royalty-free for purposes of HTML 5 implementation.
The patents involved are method patents, not software patents.
I'm not sure whether you meant to accuse me or the MPEG-LA of fearmongering, by the way. Care to clarify? I just abstracted a list the MPEG-LA provides.
The article is wrong. According to the MPEG-LA, there are patents on H.264 in at least the following countries:
Germany, France, UK, Finland, Italy, Sweden, Belgium, Bulgaria, Liechtenstein, Austria, Czech Republic, Denmark, Spain, Hungary, Ireland, The Netherlands, Poland, Romania, Portugal, Slovenia, Japan, China, South Korea, Hong Kong, Singapore, Taiwan, India, Canada, Mexico, Australia
See http://www.mpegla.com/main/programs/AVC/Pages/PatentList.aspx
> The browser doesn't have to implement OpenGL itself
However it does have to implement some sort of OpenGL checker (which is actually harder in some ways). Unless you enjoy having web pages send your GPU into an infinite loop, of course. Not to mention that most graphics drivers out there don't handle "invalid" OpenGL very well (read: crash, usually exploitably); needless to say one can't expect websites to stick to "valid" OpenGL.
"Most of the world" by which metric? If you weight countries by number of Firefox users, most of the world has a patent-encumbered H.264.
Unless you're laboring under the same misapprehension as the Wildfox author about the patent status of H.264. It's patent-encumbered in way more than two countries. See http://weblogs.mozillazine.org/bz/archives/020400.html
> The question is whether a bachelors from a top tier school is worth the premium you pay'
> versus a bottom tier school.
That depends on the prices you pay. Note that most people don't pay sticker price or anything close to it. I've known several people for whom a top tier school was cheaper than a bottom tier one when you count in financial aid. But that's very much family-finances dependent (and even family demographics; e.g. if there is already one child in college, adding a second one doesn't double the bill).
Also note that what you're buying is not just the degree but also the connections, exposure to things you might not have encountered before, etc. Whether those are useful depends on whether you already know what you want to do when you start college and on what it is you end up doing. While no one cares much where you got your degree 5 years on, in some fields (academia, politics, certain kinds of consulting, possibly journalism, some kinds of business) it can very much matter who you made friends with during your time in college and what they're doing 5, 10, 15, 20 years after that.
Further, in some fields (the one I have experience with hear is math) a top-tier school will in fact prepare you much better for certain career paths (e.g. graduate school and academia) than a bottom-tier one. All else being equal, of course; hard work can compensate to a large extent.
> I am graduating in 2 days. 5 years of education, 2 degrees, $26k in debt, at a reputable
> university in a major city (population =~ 1 million). I paid for rent and food like most
> people I know, by working.
It's a lot harder to do that for universities in the middle of nowhere, for what it's worth.
$8k tuition sounds about right for a current in-state public school. It's way too low for out-of-state.
I looked at the numbers in your report. One thing to keep in mind is that those are averages; top-tier schools, including public ones, charge more than average.
From what I can see, today' top-tier private schools will run you $200k over 4 years, no $80k.
> Well, ignoring the cost of the (apparently private) school you went to,
The GP said he spent $80k over 4 years, right? That sounds like a public school to me, at least nowadays. For example, the University of Maryland is about $20k/year for tuition+fees+room+board for in-state students.
For private schools, the number nowadays is closer to $50k/year.
Back in 2001 when the GP was presumably in school the numbers were somewhat lower ($35k/yr for private schools, iirc), but it's not obvious that $80k over 4 years means a private school, sadly.
> You have hundreds of items on your to-do list?
Effectively, yes. I get through a few dozen a day, but more pile on, of course.