Network Streaming Performance - Netflix and YouTube

The move from Windows 7 to Windows 8 as our platform of choice for HTPCs has made Silverlight unnecessary. The Netflix app on Windows 8 supports high definition streams (up to a bit rate of 3.85 Mbps for all ISPs, more if the ISP is Super HD enabled) as well as 5.1-channel Dolby Digital Plus audio on selected titles.

It is not immediately evident whether GPU acceleration is available or not from the OSD messages. However, GPU-Z reported an average GPU utilization of 12% throughout the time that the Netflix app was playing back video. The average power consumption is around 28 W.

Unlike Silverlight, Adobe Flash continues to maintain some relevance right now. YouTube continues to use Adobe Flash to serve FLV (at SD resolutions) and MP4 (at both SD and HD resolutions) streams. YouTube's debug OSD indicates whether hardware acceleration is being used or not.

Windows 8 has plenty of YouTube apps. We chose the Megatube YouTube Player / Downloader which allows for stream selection. For our power measurement experiments, we chose the 1080p MP4 stream.

However, we can't be sure whether hardware acceleration is being used with the app, as there is no debug OSD. However, a look at the power consumption numbers reveal that both approaches consume less than 30 W on an average. The difference in the caching of the stream is also visible in this graph, with the Flash approach preferring to download data in bursts while the app prefers to download the whole stream as quickly as possible. Streaming was done over Wi-Fi.

Comparing these numbers with what was obtained using the i3-3225 in a passive build shows that the Haswell build manages to be more efficient even when active cooling (with one big Antec Skeleton chassis fan and a CPU fan) is employed.

On the image quality front, Haswell doesn't seem to change anything here vs. Ivy Bridge. Performance was acceptable before, and it continues to be so here. The big difference is really the additional power savings.

Decoding and Rendering Benchmarks 4K for the Masses
Comments Locked

95 Comments

View All Comments

  • meacupla - Monday, June 3, 2013 - link

    there's like... exactly one mITX FM2 mobo even worth considering out of a grand total of two. One of them catches on fire and neither of them have bluetooth or wifi.

    LGA1155 and LGA1150 have at least four each.
  • TomWomack - Monday, June 3, 2013 - link

    The mITX FM2 motherboard that I bought last week has bluetooth and wifi; they're slightly kludged in (they are USB modules apparently glued into extra USB ports that they've added), but I don't care.

    The Haswell mITX boards aren't available from my preferred supplier yet, so I've gone for micro-ATX for that machine.
  • BMNify - Monday, June 3, 2013 - link

    I know you're trolling but the fact is more people are content with converting their 5 year old C2D cookie cutter desktop into an HTPC ($50 video card + case + IR receiver = job done) than buying all new kit.
    We reached the age of "good enough" years ago. Money is tight and with all the available gadgets on the market (and more to come) people are looking to make it go as far as possible. Intel is going to find it harder and harder to get their high margin silicon into the homes of the average family. Good enough ARM mobile + good enough x86 allows people to own more devices and still pay the bills. It looks like AMD has accepted this, they've taking their lumps and are moving forward in this "new world". I'm not sure what Intels long term strategy is but I'm a bit concerned.
  • Veroxious - Tuesday, June 4, 2013 - link

    Agreed 100%. I am using an old Dell SFF with an E2140 LGA775 CPU running XBMCbuntu. It works like a charm. I can watch movies while simultaneously adding content. That PC is near silent. What incentive do I have for upgrading to a Haswell based system? None whatsoever.
  • kallogan - Monday, June 3, 2013 - link

    2.0 ghz seriously ??? The core 45W Sandy i5-2500T was at 2,3 ghz and 3,3 ghz turbo. LOL at this useless cpu gen.
  • kallogan - Monday, June 3, 2013 - link

    Forget my comment didn't see it was a i7 with 8 threads. 35W tdp is not bad either. But the 45W core i7-3770T would still smoke this.
  • Montago - Monday, June 3, 2013 - link

    I must be blind... i don't see the regression you are talking about.

    HD4000 QSV usually get smudgy and blocky.. and that i don't see in HD4600 ... so i think you are wrong in your statements.

    comparing the frames, there is little difference, and none i would ever notice while watching the movie on a handheld device like an tablet or Smartphone.

    The biggest problem with QSV is not the quality, but the filesize :-(
    QSV is usually 2x larger than x264
  • ganeshts - Monday, June 3, 2013 - link

    Montago,

    Just one example of the many that can be unearthed from the galleries:

    Look at Frame 4 in the 720p encodes in full size here:

    HD4600: http://images.anandtech.com/galleries/2836/QSV-720...
    HD4000: http://images.anandtech.com/galleries/2839/QSV-HD4...

    Look at the horns of the cattle in the background to the right of the horse. The HD4000 version is sharper and more faithful to the original compared to the HD4600 version, even though the target bitrate is the same.

    In general, when looking at the video being played back, these differences added up to a very evident quality loss.

    Objectively, even the FPS took a beating with the HD4600 compared to the HD4000. There is some driver issue managing the new QuickSync Haswell modes definitely.
  • nevcairiel - Monday, June 3, 2013 - link

    The main Haswell performance test from Anand at least showed improved QuickSync performance over Ivy, as well as something called the "Better Quality" mode (which was slower than Ivy, but never specified what it really meant)
  • ganeshts - Monday, June 3, 2013 - link

    Anand used MediaEspresso (CyberLink's commercial app), while I used HandBrake. As far as I remember, MediaEspresso doesn't allow specification of target bitrate (at least from the time that I used it a year or so back), just better quality or better performance. Handbrake allows setting of target bitrate, so the modes that are being used by the Handbrake app might be completely different from those used by MediaEspresso.

    As we theorize, some new Haswell modes which are probably not being used by MediaEspresso are making the transcodes longer and worse quality.

Log in

Don't have an account? Sign up now