WebPlugin for Chrome : Use new "pepper" API (ie deprecation of NPAPI in Chrome 42.X)
Since a few days, Chrome is no more supporting NPAPI per default on Windows (already the case on Linux since a few months, AFAIK). It would be great to have an update version of the web plugin using the "pepper" API in order to re-enable browser integration
Activity
You can manually enable NPAPI in Chrome - still.
Porting VLC to Native Client is probably several developper-years worth of effort. It is not going to happen in the four months until Chrome removes NPAPI support, unless someone has millions to spend on a dedicated large enough task force. So I am not sure what the value of a NaCl port is anymore.
As for Chromebooks, VLC should run better via ARC than via NaCl... so no value there either.
several developper-years worth of effort.
Really? I can see that you would have to replace all the networking and display output code, but my sense is that the really difficult parts of VLC are the native UIs (irrelevant in plugins) and video codecs and such, which will run unchanged under NaCL.
In order to run under PNaCL, all the inline assembly will have to be replaced with C/C++ code, but aren't there fallbacks for all of that already?
I am not sure what the value of a NaCl port is anymore.
If the plugin is rebuilt using PNaCL, you restore VLC-in-browsers not only on Windows, but also on Linux and Mac OS X, which have been broken for years. Eventually, it could even allow mobile.
Google wants you to believe that all these new web APIs will save us from needing plugins, but HTML5 video and WebRTC don't let you do things like decode raw UDP multicast MPEG-2 transport streams, and there is no reason to expect that this will change. IPTV is going to be with us for many years yet.
-
Replying to [comment:4 tangent]:
several developper-years worth of effort.
Really? I can see that you would have to replace all the networking and display output code, but my sense is that the really difficult parts of VLC are the native UIs (irrelevant in plugins) and video codecs and such, which will run unchanged under NaCL.
You have to rework the build system, add a new base port, new audio output, new video output. And then the real fun starts when you start porting the contribs.
In order to run under PNaCL, all the inline assembly will have to be replaced with C/C++ code, but aren't there fallbacks for all of that already?
Yes, there are. And they are slow. And video decoding hardware acceleration is totally lost also.
If the plugin is rebuilt using PNaCL, you restore VLC-in-browsers not only on Windows, but also on Linux and Mac OS X, which have been broken for years. Eventually, it could even allow mobile.
It will be even more broken. Especially for PNaCl, the performance will be terrible.
Google wants you to believe that all these new web APIs will save us from needing plugins, but HTML5 video and WebRTC don't let you do things like decode raw UDP multicast MPEG-2 transport streams, and there is no reason to expect that this will change. IPTV is going to be with us for many years yet.
As far as I know, you cannot receive multicast with Google native client. And it is unclear whether BSD sockets are provided, or just some weird incompatible ersatz that will not work with any of the existing network protocol implementations in VLC and contribs.
But by all means, if you do not believe that this is too much effort for too little gain, please help yourself to it and submit patches.
You have to rework the build system, add a new base port, new audio output, new video output
VLC already has several of each, which is actually the hard part: making it possible to have multiples of these.
And then the real fun starts when you start porting the contribs.
The PPAPI version of VLC doesn't have to be 100% equivalent to desktop VLC on day 1. Elements can be ported over on an as-wanted basis. Elements that directly compete with HTML5 video and WebRTC don't need to be supported. None of the control APIs need be ported, since JS will serve that need in this case. Few codecs will be required; DivX and CinePak are irrelevant today, for example.
video decoding hardware acceleration is totally lost also.
Fair point, PNaCl is out, then.
The next question then is whether NaCl blocks hardware decoding, too. I assume it does not, since Chrome's own Flash plugin has been using PPAPI for years now.
you cannot receive multicast with Google native client.
It appears that you are right. PPAPI has two of the three socket options that VLC needs: it has "reuse address" and "set recv buffer size", but no "IGMP group join" option.
Given that PPAPI allows TCP and UDP listeners, I assume that the lack of support for multicast reception is an oversight rather than an intended limitation. I expect it is easily corrected by contacting the PPAPI developers.
the existing network protocol implementations in VLC and contribs.
How much of that uses BSD sockets directly? I would have assumed that generic TCP and UDP I/O is a low-level thing, and that the protocol handlers would just be dealing with buffers of data that come from somewhere.
If there is not already a network I/O abstraction layer in place, one would have to be created, but that's not that difficult. Ive recreated that wheel many times, because it's generally a good thing to have regardless.
I saw this comment on Google NativeClientDiscuss and mentions multicast as been accessible via nacl_io NACL SDK library on top of PPAPI:
This references Multicast: Cld someone follow up and comment:
It is worth considering applying to Google for a grant to port VLC to PPAPI.
"The NaCl SDK provides a library called nacl_io that implements the BSD socket API on top of the Pepper APIs which should allow most code the uses <socket.h> to function as intended. There are some corner cases that are not supported and probable never will be, but most common networking feature are supported (DNS, UDP, TCP, listening sockets, multicast, select/poll)."
added Type::feature label
added Status::will not fix label
