Canadian TV, Computing and Home Theatre Forums banner

Netflix drawing criticism from TV industry

Tags
crtc netflix
75K views 412 replies 72 participants last post by  Wayne 
#1 ·
#396 ·
four said:
What Netflix calls high definition is nothing but a joke.
Well, Netflix looks subjectively better than Shaw cable or Telus TV which run higher bitrates. Why is this?

First, Netflix has the opportunity to use more advanced compression algorithms. They can use two-pass h.264 encoding whereas BDUs typically use single pass (since they need to handle "live" content) with fewer h.264 features. Additionally, broadcast TV isn't 1080p at all, it's 1080i which introduces interlacing artifacts, or it's 720p which is lower resolution than Netflix. Additionally, BDUs are doing re-compression where they take an already compressed MPEG2 stream, and squeeze it down further. This damages quality for the same reason why (when encoding AAC files) you don't go from WAV --> 192kbps MP3 --> 160kbps AAC. It causes substantially more quality loss than going right from WAV --> 160kbps AAC.

So, for each byte of data sent Netflix is able to squeeze more quality out than BDUs are able to because it uses higher profile h.264, it's 2-pass, and each encode they do comes from a high quality source in a single encode step. Going forward, Netflix will be able to increase this advantage since I'm sure they'll be able to adopt h.265 much more quickly than BDUs will.

When four waves his hand and says that Netflix high defintion is "nothing but a joke", the only thing he really can say is substantially better today is Blu-ray, and I'm pretty sure that using new technology Netflix will surpass Blu-ray quality with their 4K streams. The only issue is that not many people actually have the required resolution to watch 4K. But this will change over the next couple years.
 
#397 ·
Blu-ray is not good high definition. Blu-ray is high definition.
It looks as good as 1080p can look (given the source). If you can't do the same, why do 1080p?
BTW, imperfect source can look beter at 720p encoding than 1080p...
They can use two-pass h.264 encoding...
2-pass encoding? Never heard they know what that means, doubt it very much.
IIRC, they use real-time encoders, adjusting to the bandwidth available.
Just like they did here with a test H.265 stream
http://forums.xilinx.com/t5/Xcell-D...ds-in-4K-H-265-HEVC-at-CES-in-Las/ba-p/399161

Just what DVDShrink did with DVD VOBs...

I'm watching movies on a HTPC-projector and 98" screen since 2003.
You don't need a rocket science degree to see the crappy upconverting
of Traffic and oversharpening on 2001: A Space Odyssey.
Upconverted DVDs would be the best characteristic of Netflix HD...
 
#402 ·
Not really, I can easily compare the actual PQ's where as you can guess what they could be like. But carry on believing your theory, come back to me when you've watch Netflix Super HD PQ and compared it with cable, IPTV, blu-ray and up converted DVD's..........all of which I am able to do.

I think you might have breathed in too much insect killer in Winnipeg.

"I've never seen it but its sh*t"......that's hysterical
 
#403 ·
four said:
Blu-ray is not good high definition. Blu-ray is high definition.
"High definition" typically means (in the TV space) 1920x1080 or 1280x720. Plenty of other services and storage devices other than Blu-ray support those resolutions.

If you believe than nothing other than Blu-ray is high definition, then you're making up your own definitions for the term.

four said:
2-pass encoding? Never heard they know what that means, doubt it very much.
IIRC, they use real-time encoders, adjusting to the bandwidth available.
Just like they did here with a test H.265 stream
Netflix content is pre-encoded at each supported codec and bitrate. Practically all streaming video services work this way. If you think that Netflix uses real-time encoding, well, you're nuts. Seriously, do you not comprehend how expensive that would be for their server's processors? Even suggesting that they use real-time encoding tells me how much you know about the topic. Sure, Netflix can change bitrates, but each bitrate is encoded separately.

The idea that they'd do real-time encoding with 4K content is even more hilarious. It would literally be >100,000 times more expensive in compute cycles.
 
#407 ·
four said:
Encoding H.264 is very cheap.
How can you believe anybody who does not know even that...
Nope, encoding video is expensive; even a 4-core x86 server couldn't support more than what, 8 users if it was doing real-time encoding of HD video streams. At a (max) of 5mbps per stream it would only be able to send about 40mbps (tops!) of stream data if it was doing real-time encoding.

So, with that in mind let's take a look at Netflix Open Connect hardware...

It has a Xeon E3-1260L, which is a 4-core chip, and it has a 10Gbps Ethernet NIC. It's interesting that Netflix would equip a server with a single middle-of-the-road Xeon CPU and pair it with a high-end 10Gbps NIC when a 100mbps NIC would be able to keep up with the Xeon E3-1260L if the Xeon was doing real-time encoding of every stream.

At least, I think that's interesting. If you were right and Netflix was doing real-time encoding, you would think that they'd put a 2nd CPU in their Open Connect hardware. More likely, you would think they'd equip it with a ridiculous amount of encoding horsepower, but they didn't.

Now, if they pre-encoded the video (and they do), then streaming pre-encoded video has similar CPU cost as reading a file from disk and sending it out the NIC. In that case each of these Open Connect boxes would be able to get close to saturating a 10Gbps NIC. In other words, that box could probably handle ~1900-2000 concurrent streams.

And then there is the slight detail that Netflix doesn't even list encoding software on the Software Design page. You know why that is? Because the servers that Netflix client software interacts with don't do real time encoding.

four said:
I had enough of your rhetoric for today...
Well, at least you've demonstrated that you know as much about video encoding as you do about TRIM.
 
#410 ·
ExDilbert said:
Encoding and decoding H.264 is typically done with dedicated hardware, not a general purpose CPU
That used to be true. The reason why the industry started using dedicated h.264 hardware was that general purpose CPUs combined with the software encoders available at the time weren't fast enough to do real time encoding. Since then both the software has improved and the general purpose hardware got faster.

The best encoding (i.e. highest quality) was always available via software encoding - primarily because engineers can iterate/improve with software much faster than hardware, so if you're doing offline encoding of videos (e.g. a batch job), then you would likely always have been using a software encoder.

Today, there isn't much motivation to ever use dedicate hardware encoders (e.g. custom ASIC) because general purpose CPUs with software encoding are fast enough to encode a single real-time h.264 HD stream at 60fps, especially when utilizing hardware extensions like Intel's QuickSync, but even without QuickSync you can easily achieve 24fps in real time. Even 60fps can be done if your CPU is fast enough.
 
#412 ·
I agree that better encoding can be obtained using software. My system, not a screamer by any means, has a 6 core AMD CPU and a middle of the line AMD video card. H.264 encoding done by the video card is about 4 times faster than software and CPU but still not real time and the quality is poor. A newer Intel CPU would be better but still I don't see Netflix doing much real time encoding.

Francois, thanks for that piece of info regarding Netflix. I had a hunch they were simply switching sources for the streams but didn't really know. It would be interesting to know how they manage to keep the video and audio in sync with adaptive streaming speeds. I can see the video quality change but have yet to see any dropped frames or other artifacts.
 
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top