Skip to content
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

Closed
hbiyik opened this issue Jun 18, 2020 · 23 comments
Closed

Use external VLC player #5388

hbiyik opened this issue Jun 18, 2020 · 23 comments

Comments

@hbiyik
Copy link

hbiyik commented Jun 18, 2020

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.

  1. 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.

  2. 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.

@devos50
Copy link
Contributor

devos50 commented Jun 18, 2020

Thanks for your work on the streaming component!

this means it is possible totally get rid of VLC and player facilities from tribler.

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?

@qstokkink
Copy link
Contributor

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.

@hbiyik
Copy link
Author

hbiyik commented Jun 18, 2020

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 :)

@devos50
Copy link
Contributor

devos50 commented Jun 18, 2020

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?

@qstokkink
Copy link
Contributor

nevertheless it will suck less than the internal player :)

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.

@hbiyik
Copy link
Author

hbiyik commented Jun 18, 2020

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.

@ichorid
Copy link
Contributor

ichorid commented Jun 18, 2020

@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.

@egbertbouman
Copy link
Member

egbertbouman commented Jun 18, 2020

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.

@synctext
Copy link
Member

VLC can hopefully be saved with some repairing. Browser playback breaks usability for normal people sadly.
it's been a while since we synced with the VLC founder. Goal in a few years is to preserve the tight integration and try to get LibTribler shipped by default in VLC... More bloat never hurt anybody:-)

@ichorid
Copy link
Contributor

ichorid commented Jun 18, 2020

@synctext , that is not browser playback. That is, calling browser MIME-hook to call the system player.

@ichorid
Copy link
Contributor

ichorid commented Jun 18, 2020

@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.

@hbiyik
Copy link
Author

hbiyik commented Jun 18, 2020

@synctext

Goal in a few years is to preserve the tight integration and try to get LibTribler shipped by default in VLC...

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.
Btw libvlc for current streaming is more than fine, the problem i think is to really to implement those to tribler and maintain and pack them

@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)
https://github.com/python/cpython/blob/3.8/Lib/webbrowser.py

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

@ichorid
Copy link
Contributor

ichorid commented Jun 19, 2020

@hbiyik , I'm going to merge release-7.5 into devel today, so keep that in mind.

@hbiyik
Copy link
Author

hbiyik commented Jun 19, 2020

I just tested this, browser dispatching will work cross platform,
and it will ask which app to open with

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:
https://github.com/python/cpython/blob/4dd10ed6942ab99bc5b0b1c5ecc88a753877aefd/Lib/webbrowser.py#L458 which means more pain rather than gain.

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.

@ichorid
Copy link
Contributor

ichorid commented Jun 19, 2020

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.

@synctext
Copy link
Member

synctext commented Jun 20, 2020

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".

@ichorid
Copy link
Contributor

ichorid commented Jun 20, 2020

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.

@ichorid
Copy link
Contributor

ichorid commented Jul 17, 2020

From our forum:

As a long-time user of P2P and torrents just trying out Tribler, this one is rough around the edges, and I’ve a few comments. In no particular order:
The entire idea of a video player embedded in a torrent client is kind of silly, in my opinion. It’s not small and is questionably necessary. More-or-less all users will have a media player from their OS, browser, or a dedicated program, so there’s little reason to jam one into the torrent client too.

Another user in the same thread:

I too agree that a video player isn’t necessary.
I had a problem where I accidentally started a video playing when I thought I was just downloading it, and I didn’t know it until I checked the next day and saw a negative value of around 2.5g. I couldn’t find an obvious way to stop the process and remove the video. I finally had to log off. When I logged back in later the video was cleared but then my negative value almost doubled. I finally decided to trash the app and will do a new install.

@synctext
Copy link
Member

synctext commented Jul 20, 2020

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.
Decision making can be hard, we are focused on the TikTok generation. The introduction of Youtube and Facebook has deteriorated the Internet search skills in the general population that the boomers pioneered. [insert meme]
image

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

@ichorid
Copy link
Contributor

ichorid commented Jul 20, 2020

our goal is not product building. Tribler is a tool to enable us to dream about changing the world.

@synctext
Some time ago you bought your team a book called "Effective Engineer". I've read it. Maybe you intended to buy a book called "Effective Dreamer" instead, but didn't find one?

@hbiyik
Copy link
Author

hbiyik commented Jul 20, 2020

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 :))

@synctext
Copy link
Member

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

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!
Kodi usage is very much part of that, gives us breathing space to do what we do best: LibTribler. Broad view of Peer-to-peer technologies and 15 year of history.

@Ronaldvr
Copy link

I install vlc via Chocolatey, and after tribler was installed I get this error

Installing vlc...
vlc has been installed.
vlc installed to 'C:\Program Files\Tribler\VLC'
ERROR: Path doesn't exist: C:\Program Files\Tribler\VLC\vlc.exe
  vlc may be able to be automatically uninstalled.
The install of vlc was NOT successful.
Error while running 'C:\ProgramData\chocolatey\lib\vlc\tools\chocolateyInstall.ps1'.
 See log for details.

Chocolatey installed 0/1 packages. 1 packages failed.
 See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).

Failures
 - vlc (exited -1) - Error while running 'C:\ProgramData\chocolatey\lib\vlc\tools\chocolateyInstall.ps1'.
 See log for details.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

7 participants