p2p-media-loader
p2p-media-loader copied to clipboard
Novage
Jwplayer with mpeg-dash support
Hi, Firstly thanks for this wonderful repo. Wanted to check if there is any way to integrate p2p novage loader with jwplayer for mpeg-dash similar to hls integration.
If currently not available, can you kindly suggest any approach to solving this ?
Happy to work on it and send a pull request if it works.
Hi,
JW Player proprietary built-in plugins can't be integrated with P2P unless they add this ability.
We use a custom open-source hls.js plugin for JW Player to integrate P2P Media Loader with it but it works only with HLS streams
For MPEG-DASH streams we support only Shaka Player engine. It means that there should be a Shaka Player engine plugin for JW Player.
Thanks a lot for replying. Can we write a opern-source jwplayer plugin for shaka engine similar to hlsjs plugin by hola.
Does jwplayer allow doing that or is it restricted ?
I see streamroot has a direct integration with jwplayer and shaka engine.
If I would want to develop similar open-source plugin for novage can I work with resources from online or is it proprietary and need to work with jwplayer team ?
Can we write a opern-source jwplayer plugin for shaka engine similar to hlsjs plugin by hola.
Sure you can!
Does jwplayer allow doing that or is it restricted ?
It allows building plugins.
I see Streamroot has a direct integration with jwplayer and shaka engine.
Last time I checked - they had thier own plugin that integrates with JWPlayer to run P2P. For HLS it was build with hls.js. And I have no information about DASH support.
If I would want to develop similar open-source plugin for novage can I work with resources from online or is it proprietary and need to work with jwplayer team ?
JWPlayer has open plugin API and documentation. Moreover it has open-source version (https://github.com/jwplayer/jwplayer) but without HLS and DASH support. HLS and DASH is only is built-in into proprietary version (again as plugins).
Thanks a lot for patiently replying. I have raised a similar issue https://github.com/jwplayer/jwplayer/issues/3731 in jwplayer to see if there shaka provider is open-source. They have mentioned it is proprietary and I am on my own.
I guess I can still try building a plugin but it would need understanding of both jwplayer and shaka engine which could take a lot for effort. So closing the issue for now
I was going through various techniques to approach solving the problem for jwplayer and mpeg-dash
One approach I see which can be done without having custom integration with jwplayer is to run a local http server in the browser and use it as a proxy to route the network requests. Now we can remove the hls or shaka engine integration and just keep the p2p-media-loader-core along with the local http proxy
Wanted your feedback on this approach. What do you feel could be problems with this compared to doing an integration with the engine. One advantage of the approach discussed above is, it is player agnostic and thus removes the hassle of creating and maintaining integrations with all the players. Now I want to know what could be the problems with this kind of an approach.
This approach can further be extended to work with android or ios as well. Write a proxy for exoplayer and use it along with p2p-media-loader-core to run it on any android device.
Looking forward to hear your response. Thanks.
I have come across 3 approaches to solve this problem online
- Run a local http server on each client and change the url to videojs to point to the local http server and then do loadbalancing
- Overwrite XMLHttpRequest
- Use serviceworker
What would be a good approach to solve this problem. Also how do you feel player integration using any above approach works comparable to current engine integration
since jwplayer 8.14.x they've opeend the loader portion of the hlsjs config so you'd just need to use:
hlsjsConfig: {
loader: engine.createLoaderClass()
},
in your jwplayer setup, you no longer need the hola hls provider. Im not sure about dash
It's going to need some fine-tuning for VOD though, because there seems to be a 10s buffering period when using p2p, so im not sure what optimal settings there is.
@mrlika Any feedback w.r.t using a proxy approach for player vs proxy approach for engine. By writing a proxy at engine level there is always an integration bottleneck but when a proxy over the player is written directly there wouldn't be any such constraints. So would love to know how you feel about using something like overriding XMLHttpRequest/using a service worker to proxy requests between http and p2p compares with the current approach.
Proxy or service worker approach has disadvantages:
-
The current playback position is unknown. That is why you can't estimate what to download over P2P or when to switch to CDN to download faster
-
In Safari
<video>element doesn't want to play video generated by a service worker. Using service workers means dropping iPadOS and macOS support. -
Service Workes have no access to P2P currently. You can do P2P stuff only in web page scripts that make implementation more complex. The proposal exists since 2015: https://github.com/w3c/webrtc-pc/issues/230
@mrlika I've fixed the 10s buffering issue for jwplayer regarding hlsjs
@Teranode Would you mind sharing the solution here?
@mrlika I've fixed the 10s buffering issue for jwplayer regarding hlsjs
Hi @Teranode Can you kindly share the solution ? Also @mrlika what do you suggest would be the best approche playing p2p hls content on IOS/iphone devices , i see another vendor called swram something ( don't want to advertise them here) have a seperate engine ( based on serviceworker ) to play p2p content on IOS / IPHONE devices and it works !!! Also i have noticed that you mentioned somewhere that you have a p2p protorype for IOS that is in testing phases can you kindly share the code maybe we will try to help to complete it if such thing exsit .
I would really appreciate your input on this one . Many thanks in advance for taking the time reading this :) .
Best Regards David
