Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
DRM Desktops (Apple) Television

Netflix Ditches Silverlight For HTML5 On Macs 202

Posted by Unknown Lamer from the giving-up-freedom-for-tv dept.
An anonymous reader writes "Netflix yesterday furthered its plans to ditch Silverlight for HTML5 on Macs, having already done so last year in IE11 on Windows 8.1. HTML5 video is now supported by Netflix in Safari on OS X Yosemite, meaning you can stream your favorite movies and TV shows without having to install any plugins." Courtesy of encrypted media extensions.
This discussion has been archived. No new comments can be posted.

Netflix Ditches Silverlight For HTML5 On Macs More

Netflix Ditches Silverlight For HTML5 On Macs

Comments Filter:

  • Linux soon? (Score:5, Insightful)

    by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Wednesday June 04, 2014 @10:15AM (#47163999) Homepage Journal

    So presumably, Firefox will bring Netflix to Linux as well [mozilla.org]. While I can't say I'm happy to see DRM, I'm happier to be able to play the content than not be able to, and I don't think not including support for broadly-used technologies is going to win any wars.

    • Re:Linux soon? (Score:4, Interesting)

      by sanosuke001 ( 640243 ) on Wednesday June 04, 2014 @10:24AM (#47164071)
      Can't you just get a browser-id-changing-plugin and tell it you're using mac? I didn't RTFA and don't know what it does under the hood but if its just a "turn it on for this OS" and no other special installable bit, it should work?

      • Re: (Score:3, Informative)

        by Anonymous Coward
        As you can see from TFS without reading TFA, it relies on the encrypted media extensions. The odds are long on Linux support coming as everyone seems to conclude that it is too easy for Linux folks to grab video streams and record them.

        • The odds are long on Linux support coming as everyone seems to conclude that it is too easy for Linux folks to grab video streams and record them.

          I don't think so. I think both nVidia and AMD will be happy to cooperate with bringing every bit of that functionality to Linux. It's plausible, since they have closed-source drivers. Of course, it won't be in the OSS drivers, but the people who run those won't want that functionality on their system anyway.

          • Re: (Score:2)

            by AvitarX ( 172628 )

            Also, valve is gonna want this for Steam OS.

            • Here's to hoping that it gets implemented in a vanilla-GNU/Linux-compatible fashion! (As opposed to the existing Android or Chrome OS implementations which, AFAIK, are incompatible with vanilla GNU/Linux.)

          • It's already in Chrome on Linux, if it's on a chromebook device "certified" by Google ( as far as I know this is just a "yes, it's a chromebook" and not "yes, this is user X that google knows about" I.E. pretty sure the "guest" account should work[1]). That means it is on the OSS Intel drivers.

            I have no idea why the "certification" is even necessary, my chromebook is in developer mode ( meaning I have root level access, and can build / install binaries of pretty much anything I want ) and Netflix still r

        • Why the hell would anyone want to copy a stream from them anyway? Even on HD it still looks DVD quality at best. IF I am going to copy or download a movie I am going for highest quality possible.
          • Enjoy your 50GB Blu-Ray rips. I hope your ISP doesn't have a transit limit and accompanied overage fees.

            • Re:Linux soon? (Score:5, Funny)

              by Anonymous Coward on Wednesday June 04, 2014 @11:17AM (#47164493)

              It doesn't. Thanks for your support :)

            • No cap at all. You're aware that you can compress them down to less than 5GB without losing much quality? If not, I see large pointless purchasing of 4TB HDDs in your future.

              • Re: (Score:2)

                by lgw ( 121541 )

                You're aware that you can compress them down to less than 5GB without losing much quality?

                More to the point, you can compress them to about 10GB (depending on content) without any loss of quality.

          • Re: (Score:2)

            by santax ( 1541065 )
            Yeah its idiotic, but probably a demand from the contentprovidors. But indeed... I am a paying member of netflix... If I would have wanted to rip your stuf, I would have gone straight to the pirate bay or usenet or whatever is the fastest source of new material at the moment.

        • but surely there's a good reason to support it on Linux - all those TVs and set top boxes that are running Linux would love to have Netflix support (or rather, Netflix would love those to support them)

          • all those TVs and set top boxes that are running Linux would love to have Netflix support (or rather, Netflix would love those to support them)

            I thought Netflix would love to support only that can support the robustness [wikipedia.org] that the studios demand. This often involves a locked bootloader, which when used with devices that run Linux is called tivoization [wikipedia.org].

      • Re: (Score:3)

        by DrXym ( 126579 )
        No because even if you pretend to be a Mac, your browser would fall on its ass as soon as the HTML video object encountered encrypted content and had no idea what to do with it. Your browser would have to have a video tag which could handle encrypted content and call out to the JS to supply it with a decryption key in order to play it.

        That presumably means Firefox or Chrome on Linux would have to ship as a binary blob containing code from one or more DRM vendors that the was linked into the multimedia fra

        • That presumably means Firefox or Chrome on Linux would have to ship as a binary blob containing code from one or more DRM vendors that the was linked into the multimedia framework (including whatever provider Netflix uses) so it could do the decryption.

          You would only need one library (perhaps even a plugin) to handle the video. The rest of the browser can still be source.

          • Re: (Score:2)

            by DrXym ( 126579 )
            Of course you could build from source and probably Firefox will ship a DRM-less version too. I doubt the DRM component will ship as a removable component though since it makes it easier to isolate and hack on it. It's bound to be linked in and Firefox might have to strip symbols, run various integrity & bounds checks to trip up anybody attempting to debug it. And that's assuming it even appears on Linux.

      • Re: (Score:2)

        by Manuka ( 4415 )

        It's not a matter of what browser it THINKS you have, it's a matter of the browser supporting what you need to stream encrypted MPEG-DASH.

    • Re:Linux soon? (Score:5, Insightful)

      by CastrTroy ( 595695 ) on Wednesday June 04, 2014 @10:51AM (#47164253)
      I really don't see why they just don't abandon the whole "watch video in your web browser" scenario. Since Netflix only supports paying customers, it isn't really much to expect that people will download an app/application to play the videos. They already have apps for Android, iOS, Windows, XBox 360/One, Playstation 3/4, Wii (U), a bunch of apps integrated into various smart TVs. There's probably a few that I'm missing here. I don't know why they just wouldn't require that you install an application to view videos on Mac, Windows 7, or Linux. If the Linux client was a pre-compiled binary, it could probably be made reasonably secure against people trying to copy content. At least as secure as a DVD or BluRay anyway.

      • I really don't see why they just don't abandon the whole "watch video in your web browser" scenario.

        It's all about locked-down company computers, kiosks, borrowed laptops, etc., where people can't install software. It's crazy as hell, but it has been a driving force in getting crazy crap rebuilt to run inside a web browser, no matter how HORRENDOUS the experience.

        In fact HuluDesktop is GREAT for media PCs operated by remote control, while navigating their website via remote would be a tedious nightmare. H

      • Re: (Score:3)

        by tlhIngan ( 30335 )

        I really don't see why they just don't abandon the whole "watch video in your web browser" scenario. Since Netflix only supports paying customers, it isn't really much to expect that people will download an app/application to play the videos. They already have apps for Android, iOS, Windows, XBox 360/One, Playstation 3/4, Wii (U), a bunch of apps integrated into various smart TVs. There's probably a few that I'm missing here. I don't know why they just wouldn't require that you install an application to vie

      • ... If the Linux client was a pre-compiled binary, it could probably be made reasonably secure against people trying to copy content. At least as secure as a DVD or BluRay anyway.

        I'd say, you just answered your own question: If a Linux binary could be made "at least as secure as a DVD or BluRay," then Big Media would instantly label it as a non-starter, because optical media is not even remotely secure at this point; all you need to do is pop open MakeMKV [makemkv.com], and those movies will come off of the disk in an unencrypted format in short order, ready to be converted by Handbrake [handbrake.fr] for whatever purpose you might find appealing, from PSP to piracy.

        Which, I think, is actually the entire point

    • Yeah, to voluntarily compromise on another freedom so people from the following areas can watch Netflix online: United States, Canada, Mexico, South America, United Kingdom, Ireland, Netherlands, Nordic countries.

      Because without it nobody would ever put videos online.

      • Yeah, to voluntarily compromise on another freedom so people from the following areas can watch Netflix online:

        Nothing will be compromised, because the distributions for people who care about FreedomLibre(tm) or whatever we're calling it this week will offer builds without the feature, perhaps exclusively.

        Because without it nobody would ever put videos online.

        Because its existence threatens your non-DRM'ed media how?

        • Nothing will be compromised, because the distributions for people who care about FreedomLibre(tm) or whatever we're calling it this week will offer builds without the feature, perhaps exclusively.

          True, but that is not the point being presented there. The concern is if it is appropriate for an organization whose primary goal [w3.org] is to make the benefits of the social value of the Web "available to all people, whatever their hardware, software, network infrastructure, native language, culture, geographical locat

          • Re: (Score:2)

            by narcc ( 412956 )

            My thinking here is that, to remain competitive, Mozilla needs to support this feature. To not include that feature would do more harm to the goals of the organization than good.

        • Because its existence threatens your non-DRM'ed media how?

          The existence of digital restrictions management encourages the design of distribution platforms that forbid publishers from making a DRM-free release even if they want to. This has already happened with Blu-ray Disc, which requires all discs with menus to carry DRM (BDMV requires the payment of AACS royalties and BDAV appears to disallow rich menus), and with video game consoles.

    • Firefox may bring the EME interface to Linux, but it's up to Adobe to make the CDM work on Linux. I suspect they won't be allowed to due to the lack of platform level DRM.

    • Re: (Score:2)

      by silviuc ( 676999 )
      If they wanted to, they could've already done it already since Chrome has supported HTML5 DRM for quite a while...
    • It is well-documented by the MAFIAA that all Linux users are thieving, murderous scum that deserve nothing but the grinding heel of a jackboot.

    • It works well under ChromeOS which afaict is just a customized Gentoo running Chrome.

      I don't own an Intel Chromebook, but tried to get a libnetflixplayer.so (of dubious origin) to work with chrome under Debian and was not successful, although I didn't try very hard.

      I think it should work (at least on processors that are like Chrome-device processors)

  • They've been doing this for a year (Score:4, Interesting)

    by Chrisq ( 894406 ) on Wednesday June 04, 2014 @10:16AM (#47164011)
    They've been doing this for a year on Chrome OS [netflix.com]

    • Re: (Score:2)

      by Manuka ( 4415 )

      That's because ChromeOS has supported MSE for MPEG-DASH for about a year now. At this point, Netflix is in the driver's seat for pushing DASH adoption. They'll be early to the game on H.265 as well.

  • Because Silverlight *NEVER* worked on the Mac under Chrome. Video would stutter, the audio wouldn't play, it was a useless mess that reminded you that the internet is a minefield of incompatible "standards" and brought me back to the old days of "it must be cool if it crashed my browser"!

    • Then you have a shitty computer, slow connection or user error. I've been using it on 10.6 for over 2 yrs on my MBP. I usually watch a movie before bed while in bed, so maybe a good 2-3 movies a week on it and I've never experienced what you speak of.

  • saves battery (Score:5, Insightful)

    by Noah Haders ( 3621429 ) on Wednesday June 04, 2014 @10:38AM (#47164165)
    also, it saves a bunch of battery to run it in html5 than in the silverlight. for a macbook air you can get an extra 2 hours watching netflix in html5 instead of silverlight! that's huge!

    • also, it saves a bunch of battery to run it in html5 than in the silverlight. for a macbook air you can get an extra 2 hours watching netflix in html5 instead of silverlight! that's huge!

      And how are we to get corn to pop just using HTML5? Run Flash in the background?

  • "HTML5 video" doesn't actually exist. (Score:5, Informative)

    by Manuka ( 4415 ) on Wednesday June 04, 2014 @10:41AM (#47164185) Homepage

    From the looks of this, the technical version of what this means is that Netflix has been working closely with Apple to bring MPEG-DASH Media Stream Extensions to Safari (they're already present in Chrome and IE11), and that MSE will be in the Yosemite release of Safari. This is good news for MPEG-DASH adoption. Hopefully we'll also start seeing hardware H.265/HEVC support in new silicon soon which will really open up the door for 4K (and significantly reducing current bandwidth usage for 2K/HD)

    Contrary to widely held popular belief (especially among marketing types), there's not such thing as "HTML5 Video". There's a Video tag in HTML5 that allows you to embed a video player in a web page, but there's no standard as to what that actually means. When someone says they "support HTML5 streaming", they're spewing you a line of BS, because it doesn't exist. There are currently at least 5 different ways to send video to an HTML5-compliant browser: Apple HLS (supported by Safari, some WebKit browsers), MPEG-DASH (Supported by IE11 and very recent versions of Chrome), RTMP (Supported by Flash), RTSP (Supported by all kinds of things, but no adaptive streaming), and progressive download (Supported by just about anything, but can't do live streaming). Silverlight is HTTP-based, but not supported directly in the browser (Microsoft missed a golden opportunity with IE10+ to do that), and Adobe also has an HTTP transport called HDS, but it's not useful outside of Flash.

    Once you've figured that much out, then you have to figure out what codecs your browser supports. If you're trying to stream live to Firefox, your options are pretty much Flash or nothing, since it supports neither HLS, DASH, or H.264, although MSE is being developed into the Firefox code, it's not ready yet - https://wiki.mozilla.org/Platform/MediaSourceExtensions

    And if you're running Android, all bets are off depending on Google's whims for that particular version's stock browser. When Android 4.1 came out they took HLS support OUT of the Android browser and at the same time got rid of Flash support, which means that in-browser streaming on Android became limited to the ancient RTSP protocol (HLS is still supported in the OS media player, and can also be accessed via API). Chrome for Android sort of supports MSE for DASH, but not yet. Google isn't part of DASH-IF, so they're not exactly anxious to support it on Android.

    • Re: (Score:2)

      by simonbp ( 412489 )

      "very recent versions of Chrome"

      It's been supported for around a year now on the ARM chromebooks. Which, combined with their HDMI output, makes them great Netflix boxes for on the road.

    • Contrary to widely held popular belief (especially among marketing types), there's not such thing as "HTML5 Video". There's a Video tag in HTML5 that allows you to embed a video player in a web page, but there's no standard as to what that actually means. When someone says they "support HTML5 streaming", they're spewing you a line of BS, because it doesn't exist. There are currently at least 5 different ways to send video to an HTML5-compliant browser: Apple HLS (supported by Safari, some WebKit browsers), MPEG-DASH (Supported by IE11 and very recent versions of Chrome), RTMP (Supported by Flash), RTSP (Supported by all kinds of things, but no adaptive streaming), and progressive download (Supported by just about anything, but can't do live streaming).

      RTMP is flash only [stackoverflow.com]. There is no native browser support for RTMP.

      The IETF has recognized this codec and even protocol mess, and they try to make a mandatory to implement codec for WebRTC. However, they are not very [webrtchacks.com] successful.

      WebRTC can be added to your list instead. It also allows unidirectional video, but is not scalable [stackoverflow.com] (yet).

      • Re: (Score:2)

        by Manuka ( 4415 )

        Correct, in order to use RTMP, you must use Flash (as I mentioned in the original post - HTML5 doesn't preclude using a Flash object). There are players such as JWPlayer that do an excellent job of using HTML5 media objects if supported and falling back to Flash if they're not, in order to provide a seamless experience to the end user (but Android is still a mess).

        DASH is going a long way towards fixing the mess, but it's still very early in that lifecycle. One of the really neat things about it is that the

    • you have an amazing grasp of this topic...

      but you're arguing rhetoric and being pedantic...here's how:

      "support HTML5 streaming", they're spewing you a line of BS, because it doesn't exist. There are currently at least 5 different ways to send video to an HTML5-compliant browser:

      you say "it doesn't exist"...

      then say there are "5...ways to send video" via HTML5

      the problem is YOU...you don't understand that Netflix was foolish to use Silverlight, and only did it b/c they had to make Netflix work with anything

      • Re: (Score:2)

        by Manuka ( 4415 )

        The main reason they used silverlight is that of all the ways of streaming content, Silverlight has the most robust DRM support. It's been said that MPEG-DASH combines the best of HLS and Silverlight into an open protocol - namely, HLS' ease of use with Silverlight's robust DRM. HLS has decent DRM support as well, but it's still a proprietary Apple protocol (a "standard" in the Sony sense of the word: because they say it's a standard)

      • Re: (Score:2)

        by Manuka ( 4415 )

        "HTML5" in the context of streaming simply refers to placing a media object on a page without benefit of external players such as Flash or Silverlight. The HTML5 spec quite intentionally does not specify codecs or transports in order to be flexible to upcoming technologies (which change awfully fast in the streaming world). Since HTML (and by extension Javascript) deals with rendering, not transport (that's done over HTTP), it's a technical impossibility to stream with HTML.

    • you can always do DASH in Flash like Youtube :)
      or raw mpeg streaming in javascript if you are crazy enough
      https://github.com/phoboslab/j... [github.com]
      http://phoboslab.org/log/2013/... [phoboslab.org]
      http://phoboslab.org/log/2013/... [phoboslab.org]

      and look, iOS streaming app using this code: http://instant-webcam.com/ [instant-webcam.com]

    • in-browser streaming on Android became limited to the ancient RTSP protocol

      Meanwhile, it runs on the even older TCP/IP protocols!!! What's the name for something a DECADE older than "ancient"?

    • From the looks of this, the technical version of what this means is that Netflix has been working closely with Apple to bring MPEG-DASH Media Stream Extensions to Safari (they're already present in Chrome and IE11)

      So why do they still require Silverlight for IE 11 on Windows 7?

  • It seems to me that an EME module would be much easier to crack than a full browser plugin. In which case I predict that the secret keys will be disclosed rather soon.

    • Re: (Score:3)

      by Ark42 ( 522144 )

      It looks to me like the EME would basically be a DLL on Windows, and I don't see why you can't rename the DLL to something else, and drop in a shim DLL that Firefox loads. The shim DLL then loads the real EME DLL, and just proxies all the API calls back and forth. Encrypted data goes into the shim, to the EME, decrypted video comes back. The shim would then be free to copy and redirect the decrypted video elsewhere. I doubt Firefox or the real EME would even know that it was happening.
      If the EME is renderin

  • A year or so ago I complained about Netflix using silverlight. I said that it was a stupid choice and that Silverlight was a Microsoft also-ran. A few people replied that they knew programmers at Netflix and that they were very smart and knew far more than some simpleton like me.

    But the proof will be in the pudding. I suspect that with silverlight gone that people like me will finally be able to watch Netflix on their macs as I was 100% opposed to installing anything microsoft based on my machines, and ab

  • This doesn't appear to be specifically broken out anywhere, but I think it's an important point that the Silverlight Netflix client software has never supported greater than 720p at 3Mbps. Adding support for HTML5/MSE/EME to Safari will mean that Mac users can finally view all of those "Super HD" streams in full 1080p on their computers. (I've been chomping at the bit for that one, myself... now, if Apple would just release those darned beta redemption codes, so I can go play!)

  • One of the big reasons I cancelled my Netflix subscription was cause it ran like shit on my MBP.

    I'm sorry, but if you can't display a simple streaming video feed, not even HD, on a quad-core i7 with a honking video card, you're doing something wrong.

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close