(Norway has one third of the population density of the US).
Virtually all of Norway's citizens live in population centers. We have several times your entire population living in shitty little towns where AT&T owns all the fiber for the simple reason that no one else would bother to run anything to them but Ma Bell.
That must be the reason why Norway has such bad mobile coverage.</sarcasm>
And broadband isn't limited to population centers either: With a landline (available in every corner
of the country), you can get DSL everywhere, and VDSL in lots of places, including tiny villages.
And don't make me bring up Finland. There, you get 3G coverage on rural lakes.
Not that I am doubting you, but could you provide the encoding settings you used for both VP8 and H.264?
I'm on vacation until mid next week, so don't have access to the scripts used. From memory:
Both are two-pass encodes. x264 recommends single-pass with --crf nowadays, because it's
faster and nearly as good, but constant quality mode and bitrate limits don't mix too well, and
for my low-bitrate case there's still a clear advantage for longer-range precognition.
The x264 settings are a tweaked "--preset slower", with longer rc-lookahead and added
bandwidth limitations (vbv_maxrate and friends). x264 writes the exact settings used – including
an expansion of a preset into its individual parameters – at the beginning of its output, so have
a look at "strings testenc_x264.mp4 | grep x264", or use mediainfo on the file.
For vpxenc, it's basically the same, using "--good" and "--tune=ssim", adding bitrate control
settings and minor tweaks. No parameter logging in the output here unfortunately, so I can't give
you any more details right now.
The tests I have conducted myself were more-or-less of the same quality so I am curious as to whether or not I did something wrong myself.
You probably did nothing wrong at all, you just didn't restrict the encoder as heavily as I did.
I tried to make it clear that those examples are rather extreme: If you allow higher bitrates, VP8
quality improves quite a bit, and everything above about 1.5Mbit/s is fine in the vast majority of cases.
Also, the test clip used is intentionally really really hard to encode (smooth, slow-moving, weak
gradients; rotations; low contrast; high motion; high frequency; all combined; hard cuts; etc.),
to highlight encoder capabilities – and shortcomings. It stress-tests everything from motion
estimation to several other predictors the encoders may or may not have, to bitrate allocation,
so it's an excellent worst case.
I'm not trashing VP8 or vpxenc by the way, we're still going to use it to serve video to clients and/or
devices without H.264 support. It's just that H.264 (in its x264-encoded manifestation, there are lousy
H.264 encoders out there, mostly the really expensive ones) really shines in low-bandwidth use cases,
and VP8 is universally outclassed by H.264 High Profile.
Excellent examples.
I need to bookmark these for the next time someone claims "MPEG4 is no better than WebM"
Meh, I'm sorry, I didn't consider bookmarking: Those files are in/temp on my server,
where everything older than 10 days gets killed. That was stupid of me.
I've just added an exception to the cleanup script, so the URLs should survive –
but still: Feel free to save the files locally or put them somewhere else.
Besides, VP8 is actually more-or-less equal to H.264 in quality and compression, you can easily verify that yourself with libvpx and x264.
It really isn't. VP8's quality is comparable to that of H.264's Main Profile.
H.264 High Profile eats VP8 for breakfast in bitrate-limited scenarios, meaning
about 800 kilobit/s for SD content.
But even at around 1,5Mbit/s, it's really obvious to the trained and still visible
to the untrained eye. Yes, I actually have done double-blind tests.
vpxenc is still very young, so improvement will happen, in both perfomance
and quality. But the developers themselves have stated that it is unlikely to ever
exceed H.264 MP by much.
I've done extensive tests to try to coax better quality out of VP8, and have pretty
much failed. I even had help from one of the guys at google working on VP8.
And yes, it's part of what I do for a living.
As one of the x264 devolpers said when I showed this around (verbatim quote): "Holycrapbirds".
Of course, that low a bitrate is a very harsh test. At over twice the bitrate, VP8
still needs more bits for similar quality, but the relative difference is much smaller.
At some point around 2Mbit/s, "quality saturation" sets in.
But for sites doing lots of streaming to clients behind <1Mbit/s connections and aiming
for noncrapbird quality, this is a real issue.
Also, the most-common size I recall seeing for PC monitors is 1980x1200, though maybe that's changing with 'HD' sizes for TVs taking over.
Welcome to... well... sometime around 2009 I guess. 1920x1200 is pining for the fjords.
Since then, as you say, "HD" has won big time. This sucks royally of course.
I was told once that the original design for the Shuttle's SRBs did not call for segmentation. It was supposed to be on once piece shipped by boat. But because the manufacturing for contracted elsewhere for political reasons, it required a redesign of the SRBs to be segmented for cargo rail placement.
That's true (not even a boat needed, probably - just built more or less on site).
There was however no way to ship single-body SRBs from Utah.
Yep, unmanned rockets can and often do accelerate quite a bit faster.
However, humans are not able to withstand those foces without trouble,
so if you want to ride along, 5-8 minutes will have to do.
Very good point, you are right. I was stuck with the "one picture per viewing angle" analogy,
because I've seen a low-res prototype version of this in action once (12 horizontal images, IIRC),
but a real light field is indeed more than that.
A high-resolution light field display needs even finer structrures than a simple "directional images"
display of course, so I'm not holding my breath...
The above concept of "one image per viewing angle" simply isn't enough to be undistinguishable
from reality, that's why I kept one "fake" in the name.
For a real holographic display, image content has to depend on viewing distance as well,
to adapt to a changing field of view.
And there's also still the issue of a forced focus point: Image content that changes according
to viewing angle and viewing distace still doesn't adapt to the actual distance I'm looking at.
It would emit directed pictures, and thereby be capable of displaying different
images at different viewing angles simultaneously.
That's great for real fake 3D, where your viewing angle on objects in the image
actually changes, as opposed to today's fake fake 3D, which is just fixed perspective
stereoscopy.
And this even works for more than one viewer. And without special glasses.
In practice, this means that it needs very fine structures for those directed emitters.
Also, the visible resolution will be "pixel count/number of simultaneous pictures displayed"
which means "very low" if it displays more than a handful of angles, that's why it needs
crazy pixel densities for a decent image.
Then you might want to have a look at Portal as well then. Speaking of xkcd 606,
that's a game I played for the very first time a couple of weeks ago coincidentally -
which must make me one of the last three or four on slashdot to do so.
And yes, it's amazing. And Portal 2 is even better.
The green ink probably not, but the sophisticated ink to print those colour-shifting numbers
is a trade secret exclusively owned by a Swiss (not Swedish) company named SICPA
The ink for the specific colour change (greenish to brownish) used on dollar notes is supposed
to be exclusively made for and sold to the US Bureau of Engraving and Printing, so I'm not sure
how North Koreans could get their hands on that.
I realise that SPDY is about reducing the latency of HTTP connection handshakes -
but wouldn't using the already existing and even implemented HTTP 1.1 standards
for pipelining (requesting multiple resources in one request) and keep-alive (keeping
a once-established connection open for reuse) mostly remove the handshake latency
bottleneck?
Slashdot Mirror
(Norway has one third of the population density of the US).
Virtually all of Norway's citizens live in population centers. We have several times your entire population living in shitty little towns where AT&T owns all the fiber for the simple reason that no one else would bother to run anything to them but Ma Bell.
That must be the reason why Norway has such bad mobile coverage.</sarcasm>
And broadband isn't limited to population centers either: With a landline (available in every corner
of the country), you can get DSL everywhere, and VDSL in lots of places, including tiny villages.
And don't make me bring up Finland. There, you get 3G coverage on rural lakes .
Floor level emergency lighting, bird indigestion, de-icing boots, better non-flammable wiring insulation, smoke detectors, lightning hit management, ETOPS, stick-shakers...
There's one in there that sounds more like it should be a concern for the EPA,
or the Department of Agriculture.
Or is the FAA just responsible for everything that flies?
Do they legislate lead content in bird seed?
Not that I am doubting you, but could you provide the encoding settings you used for both VP8 and H.264?
I'm on vacation until mid next week, so don't have access to the scripts used. From memory:
Both are two-pass encodes. x264 recommends single-pass with --crf nowadays, because it's
faster and nearly as good, but constant quality mode and bitrate limits don't mix too well, and
for my low-bitrate case there's still a clear advantage for longer-range precognition.
The x264 settings are a tweaked "--preset slower", with longer rc-lookahead and added
bandwidth limitations (vbv_maxrate and friends). x264 writes the exact settings used – including
an expansion of a preset into its individual parameters – at the beginning of its output, so have
a look at "strings testenc_x264.mp4 | grep x264", or use mediainfo on the file.
For vpxenc, it's basically the same, using "--good" and "--tune=ssim", adding bitrate control
settings and minor tweaks. No parameter logging in the output here unfortunately, so I can't give
you any more details right now.
The tests I have conducted myself were more-or-less of the same quality so I am curious as to whether or not I did something wrong myself.
You probably did nothing wrong at all, you just didn't restrict the encoder as heavily as I did.
I tried to make it clear that those examples are rather extreme: If you allow higher bitrates, VP8
quality improves quite a bit, and everything above about 1.5Mbit/s is fine in the vast majority of cases.
Also, the test clip used is intentionally really really hard to encode (smooth, slow-moving, weak
gradients; rotations; low contrast; high motion; high frequency; all combined; hard cuts; etc.),
to highlight encoder capabilities – and shortcomings. It stress-tests everything from motion
estimation to several other predictors the encoders may or may not have, to bitrate allocation,
so it's an excellent worst case.
I'm not trashing VP8 or vpxenc by the way, we're still going to use it to serve video to clients and/or
devices without H.264 support. It's just that H.264 (in its x264-encoded manifestation, there are lousy
H.264 encoders out there, mostly the really expensive ones) really shines in low-bandwidth use cases,
and VP8 is universally outclassed by H.264 High Profile.
Excellent examples. I need to bookmark these for the next time someone claims "MPEG4 is no better than WebM"
Meh, I'm sorry, I didn't consider bookmarking: Those files are in /temp on my server,
where everything older than 10 days gets killed. That was stupid of me.
I've just added an exception to the cleanup script, so the URLs should survive –
but still: Feel free to save the files locally or put them somewhere else.
Besides, VP8 is actually more-or-less equal to H.264 in quality and compression, you can easily verify that yourself with libvpx and x264.
It really isn't. VP8's quality is comparable to that of H.264's Main Profile.
H.264 High Profile eats VP8 for breakfast in bitrate-limited scenarios, meaning
about 800 kilobit/s for SD content.
But even at around 1,5Mbit/s, it's really obvious to the trained and still visible
to the untrained eye. Yes, I actually have done double-blind tests.
vpxenc is still very young, so improvement will happen, in both perfomance
and quality. But the developers themselves have stated that it is unlikely to ever
exceed H.264 MP by much.
I've done extensive tests to try to coax better quality out of VP8, and have pretty
much failed. I even had help from one of the guys at google working on VP8.
And yes, it's part of what I do for a living.
Have a look yourself:
x264 High Profile, 790Kb/s, 4.3MiB
VP8, best effort, 770Kb/s, 4.2MiB (the encoder was given the same constraints as x264)
VP8 falls completely apart on high-frequency picture content, where H.264 holds up quite well.
As one of the x264 devolpers said when I showed this around (verbatim quote): "Holycrapbirds".
Of course, that low a bitrate is a very harsh test. At over twice the bitrate, VP8
still needs more bits for similar quality, but the relative difference is much smaller.
At some point around 2Mbit/s, "quality saturation" sets in.
But for sites doing lots of streaming to clients behind <1Mbit/s connections and aiming
for noncrapbird quality, this is a real issue.
Sad for NASA that DOE is doing this and not NASA.
It's a ground-based telescope. Where exactly would NASA come in?
Also: Don't start your sentences in the subject field, it's bloody annoying.
Also, the most-common size I recall seeing for PC monitors is 1980x1200, though maybe that's changing with 'HD' sizes for TVs taking over.
Welcome to... well... sometime around 2009 I guess. 1920x1200 is pining for the fjords.
Since then, as you say, "HD" has won big time. This sucks royally of course.
I was told once that the original design for the Shuttle's SRBs did not call for segmentation. It was supposed to be on once piece shipped by boat. But because the manufacturing for contracted elsewhere for political reasons, it required a redesign of the SRBs to be segmented for cargo rail placement.
That's true (not even a boat needed, probably - just built more or less on site).
There was however no way to ship single-body SRBs from Utah.
I am hoping that Bezo will consider [...]
OK, just because you keep calling him that in multiple posts:
The man's name is Bezos. Jeff Bezos. Sheesh.
santorum was against porn which effects many nerds!
Only by accident, usually.
My stepbrother was born in Kaiserslautern, so he technically has German citizenship.
Only if he has a German parent, or in some specific cases is of German descent.
Germany doesn't have "ius soli":
http://en.wikipedia.org/wiki/German_nationality_law
I could keep a leaky boat afloat for much longer peddling a pump.
What if nobody buys it?
Yep, unmanned rockets can and often do accelerate quite a bit faster.
However, humans are not able to withstand those foces without trouble,
so if you want to ride along, 5-8 minutes will have to do.
Very good point, you are right. I was stuck with the "one picture per viewing angle" analogy,
because I've seen a low-res prototype version of this in action once (12 horizontal images, IIRC),
but a real light field is indeed more than that.
A high-resolution light field display needs even finer structrures than a simple "directional images"
display of course, so I'm not holding my breath...
I want one too though.
5 minutes to space is a pretty long time compared to the time a rocket does it in
It isn't. For a Space Shuttle launch, MECO (main engine cut-off) was about 8 minutes after lift-off.
I agree. But it's not there yet.
The above concept of "one image per viewing angle" simply isn't enough to be undistinguishable
from reality, that's why I kept one "fake" in the name.
For a real holographic display, image content has to depend on viewing distance as well,
to adapt to a changing field of view.
And there's also still the issue of a forced focus point: Image content that changes according
to viewing angle and viewing distace still doesn't adapt to the actual distance I'm looking at.
It's a really hard problem to solve.
It would emit directed pictures, and thereby be capable of displaying different
images at different viewing angles simultaneously.
That's great for real fake 3D, where your viewing angle on objects in the image
actually changes, as opposed to today's fake fake 3D, which is just fixed perspective
stereoscopy.
And this even works for more than one viewer. And without special glasses.
In practice, this means that it needs very fine structures for those directed emitters.
Also, the visible resolution will be "pixel count/number of simultaneous pictures displayed"
which means "very low" if it displays more than a handful of angles, that's why it needs
crazy pixel densities for a decent image.
Then you might want to have a look at Portal as well then. Speaking of xkcd 606,
that's a game I played for the very first time a couple of weeks ago coincidentally -
which must make me one of the last three or four on slashdot to do so.
And yes, it's amazing. And Portal 2 is even better.
From the service dashboard:
"4:00 AM UTC We have identified the root cause of this incident. It has been traced back to a cert issue triggered on 2/29/2012 GMT."
So yeah, a leap day bug sounds probable.
The green ink probably not, but the sophisticated ink to print those colour-shifting numbers
is a trade secret exclusively owned by a Swiss (not Swedish) company named SICPA
The ink for the specific colour change (greenish to brownish) used on dollar notes is supposed
to be exclusively made for and sold to the US Bureau of Engraving and Printing, so I'm not sure
how North Koreans could get their hands on that.
I've often wondered what happens to all the 7.62mm that gets fired in intimidation/celebration in Africa and the Middle East.
They kill people.
And a hyperinflation in Germany would affect the face value of US Treasury bonds exactly how?
Question: is an imperial minute longer or shorter than a parsec?
Yes.
I realise that SPDY is about reducing the latency of HTTP connection handshakes -
but wouldn't using the already existing and even implemented HTTP 1.1 standards
for pipelining (requesting multiple resources in one request) and keep-alive (keeping
a once-established connection open for reuse) mostly remove the handshake latency
bottleneck?
What the hell is up with the bold text throughout your comment?
He's probably a professional comic letterer.