-
Notifications
You must be signed in to change notification settings - Fork 449
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use external VLC player #5388
Comments
Thanks for your work on the streaming component!
This is quite something. The video player in the GUI has always been a component that is hard to get right since it is tightly integrated with our download mechanism. There are also various Qt issues that are holding back a proper design of the integrated video player (e.g., the inability to draw custom elements like a buffering indicator on top of the media player window). I'm not sure how many users actually use the embedded video player. If we would gather statistics on Tribler usage, this is an interesting one to take into account :) Using an external VLC player offers indeed more functionality than the custom, embedded player that is currently shipped with the Tribler GUI. However, it burdens the end-user who simply wants to click and play a video. Removing the video player from Tribler forces the user to use an external application, and deteriorates the overall experience. On the other hand, I acknowledge that our current video player has problems. My question is: should we instead focus on improving the embedded video player, or off-load media presentation to external applications? |
Would this work with a HTML5 video player? If so, we could replace the VLC player with a Qt5 WebView to also have an integrated Tribler viewer still. |
html5 player will probably suck, because the streamed content generally is not meant for streaming (ie: mkv file, or an avi file) but nevertheless it will suck less than the internal player :) |
If we are re-doing the video screen, we should do it properly. Otherwise, we will end up with a half-functioning player again. @hbiyik I've sent you a Slack invite a few days ago, did you already accept it? |
It's been years since we made any improvements to the video player: even a small amount of less suck is good in my books. |
Sidetrack: no i have not? [email protected] should be the mail. I think external plyer is more beneficial for the development than the users, slimming the the code and outsourcing the tasks to the professional apps always leans the dev. in case of web player, than there is the maintenance of this web player. |
@hbiyik , that's a great idea to remove the player in favour of streaming to the platform native player. I don't know how we missed it before 🤦 I completely support removing the embedded player, if we can make the native streaming work on every platform. |
I feel that libVLC stream playback has just gotten worse over time, so if we can get rid of it, I'm all for it! Over the years we've had many different options: embedded player, popup player, OS default. We've never used HTML5 video though. Mostly because at the time we felt that popular browsers did not have support for enough formats to make it a viable option. If we want to get rid of VLC using the default video player is probably our best bet. |
VLC can hopefully be saved with some repairing. Browser playback breaks usability for normal people sadly. |
@synctext , that is not browser playback. That is, calling browser MIME-hook to call the system player. |
@hbiyik , could you please hack a quick proof-of-concept? No usual PR requirements, just a demo to show that it will work as expected. |
did i get your vision correct, you are talking about having libtribler as an access plugin (like https or rtmp etc) for vlc? I am calling this vision because this practically means rewriting the core in a lower level language like c or cpp. @ichorid ok, ill do that after i do a quick rebase streaming branch to 7.5, There already is a very easy way to utilize the browser in a cross platform fashion.(see below). How the browser will handle the url should be dependant on the response header content type. (Ie embedded html5 player or external player) Sidenote: rebasing is for latest anydex pointer upgrades and so forth, the master branch which has streaming fixes keep crashing due to "invalid ask/bid" bug |
@hbiyik , I'm going to merge |
I just tested this, browser dispatching will work cross platform, BUT, the problem is firefox in my case, downloads the overall file, and opens the downloaded file with it after download is finished. So this method will not work. When the content-type is pushed as html5 playable type like video/ogg, html5 player intiilites but of course it does not play anything. Considering most of the videos are matroska files and hevc codec html5 player is also not gonna work. So only viable option left is opening the default media player, it is possible to get the correct app for the mimetype in linux and windows but problem with this approach is, each differrent media player may have different arguments for remote file system. ie, in my case my mint distro is using celluloid plaer as default. And this player has some arguments to be passsed to open a remote url. This means that each different media player type should be maintained like cpython does for browsers in: I think last thing would make sense in this direction would be to support only VLC player, and not bundle libvlc. If a user wants to stream the torrent then tribler can suggest to install the VLC player if not installed. That sounds like a path to try i think. |
Sounds good, I like it. Asking the user to install VLC separately increases security and convenience, as VLC will do its own updates. Also, many Matroska files contain subtitles/multiple audio tracks which require complex controls only available in the full version of VLC. |
The Idea of removing VLC touched a bit of a nerve, sorry for that. Streaming with privacy and ease of use are the foundations of Tribler. Add-on installs and playback fails are a nightmare for normal PC people. Much developer months have been spend evaluating alternatives. Never worked 99% reliable and even that is not good enough for product-grade code. Playback of .mkv files was a show stopper. Lot is formats exist that need both header and tail of file for video decoding. see document on this: https://repository.tudelft.nl/islandora/object/uuid:c5eb65d2-cce5-44db-9e16-e790bd9e1945/datastream/OBJ/download 167 pages about our experimental unstable streaming code: https://repository.tudelft.nl/islandora/object/uuid:80ebec52-2323-4fe0-bf7e-92b594c03d3f/datastream/OBJ/download Please experiment if HTML5 solves that problems of the past. Our long-term 5-10 year vision is indeed another implementation of our stack, besides Python and Kotlin. Geared for mass-VLC deployment. But this is just long-term dreaming what to do once we have a few million users with critical networking mass. The "End Game Move". |
We can start packaging an alternative build ("Tribler Lite") that will use external VLC player. After a couple of releases, we will have enough download/usage statistics to judge if it is more popular than the "fat" version with embedded player. |
From our forum:
Another user in the same thread:
|
As said, VLC can hopefully be saved with some repairing. We are very aware that experienced torrent users, overworked developers and bloat-conscious users don't like VLC bundling. Integrating VLC is a strategic decision. Other projects are free to unbundle our work a merely ship the LibTribler core. Zoomers don't know how to torrent. Mass adoption requires doing the hard work and get seamless fault-free playback operational everywhere. We are a scientific research project, our goal is not product building. Tribler is a tool to enable us to dream about changing the world. We are trying to bring meaningful change to the platform economy by offering an alternative to the masses. We are very much open to Pull Requests which support an external player or strips bloat from VLC, like the DVDplayer.so we ship by default on Windows. Note, After summer of 2021 we will revisit this and other strategic decisions |
@synctext |
I hope I don't overstate when I think what @synctext 's message here is. Tribler in it is fundementals is aiming to liberate the internet, this was the the story all along with dispersy, and will be ipv8. Not just a torrent client. And the most affective control mechanism for the masses is through media. This is why a seamless rich media component is essential/strategic for tribler due to the fact that gen-z does not have attention span or enthusiasm for detailed interactions to reach media, instead they will just consume what is given. But the real question for me is, which profile of people is demanding freedom, the nerds or the zoomers? (i am in between gen x & y, sorry if i offend some gen-z here :)) |
Thnx @hbiyik! "Not just a torrent client." Lot of evolving thinking is going on publicly within these issues for numerous years, without cleaned up conclusions. It's time for issue cleanup coming months. Long-term strategic goal is briefly mentioned here: #573. Getting rid of the "Downloads" section long-term. Offer an experience similar to Youtube, with offline download ability for experts-only (default is to hide storage details). Also "seamless rich media interaction" nails it. These days you need to build in HD-preview content navigator, decentralised Google-performant keyword engine, Youtube-quality streamer, and Twitter responsive discovery feed. That makes our job fun! |
I install vlc via Chocolatey, and after tribler was installed I get this error
Another reason to not bundle it, and use an existing installation if there is one, and to use the standard installer when you want to continue using it. |
Hello
#5301
with the above PR any video player can stream over tribler, this means it is possible totally get rid of VLC and player facilities from tribler.
The reason is, libvlc is too big, around 50mb is only libvlc when packed. This severely increases the bundled package when distributed up to 100MB. Lets be honest there are fully operational OSes around 100MB.
The player is a very detailed work, even though libvlc can do everything, it is still a pain to implement all of them and maintain them. Ie: subtitle support, multittrack audio support, some finiciky decoder or transport issues and etc. This is the reason i never ever use embedded player in tribler, i think most of the users dont.
So my suggestion would be when a user activates the streaming mode, the progress bar of the download would go to preprebuffering indicator, and status would be "prebuffering". When the prebuffering is finished, the tribler will open the streaming url in browser, and browser will open the default media player according to mime-type header info .
So the streaming part in the core will stay intact and all the player stuff from gui will be doomed. And it will focus on doing less things, and doing them better.
The text was updated successfully, but these errors were encountered: