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

[Feature Request] Support youtube-dl + ffmpeg as an alternative to lavaplayer #1375

Closed
4 tasks done
MichailiK opened this issue May 13, 2023 · 0 comments · Fixed by #1490
Closed
4 tasks done

[Feature Request] Support youtube-dl + ffmpeg as an alternative to lavaplayer #1375

MichailiK opened this issue May 13, 2023 · 0 comments · Fixed by #1490

Comments

@MichailiK
Copy link
Collaborator

MichailiK commented May 13, 2023

Is your feature request related to a problem? Please describe.

lavaplayer has not been receiving any updates recently. As of today, sedmelluq/lavaplayer@707771a is the latest commit & is nearly 2 years old. During the lack of maintenance from lavaplayer, several issues have arised, such as:

What is your ideal solution to the problem?

JMusicBot should use youtube-dl (or any of its derivatives/forks like yt-dlp) for fetching media, and ffmpeg for encoding the media if required.

The issue with lavaplayer is that it is responsible for every step of streaming audio on Discord: It is fetching the media (from YouTube for example), it is encoding to Opus, and it is streaming to Discord.

In comparison, youtube-dl is responsible for fetching the media, and ffmpeg is responsible for encoding the media. As youtube-dl & ffmpeg produce their output in an "universal" manner (i.e. via standard output), both projects are used in vasts amount of ways & situations, making them very popular & well maintained. In our case, we would pipe youtube-dl's results to ffmpeg for encoding it to Opus, then JMusicBot can read ffmpeg's pipe and will be responsible to stream it to Discord.

Other than this, youtube-dl has support for over one thousand platforms and ffmpeg supports many, many audio codecs, allowing playback with practically every audio file a user could send to JMusicBot.

How would this feature be used?

This should hopefully be a change that does not require intervention of the bot owner. There could an option for bot owners to change between lavaplayer and youtube-dl/ffmpeg, or lavaplayer could be replaced entirely with youtube-dl/ffmpeg.

Additional Info

  • This change is monumental & will likely take a lot of effort to code.
  • youtube-dl & ffmpeg binaries would need to be put somewhere. Either the bot owner can obtain them, or the OS & CPU architecture could be detected by JMusicBot and would download the appropiate binaries automatically.
  • youtube-dl & ffmpeg may add increased CPU and RAM overhead to JMusicBot
  • Changing volume while ffmpeg is running could be troublesome, however ffmpeg has the ability to send commands to filters while encoding, so this might not be too difficult.
  • Seeking the track might be a problem. I would need to perform some experiments to see if or how seeking could be reliably done in youtube-dl

Checklist

dmizelle added a commit to dmizelle/MusicBot that referenced this issue Aug 26, 2023
I tried setting this up as an alternative to using red-discordbot and
ended up immediately running into jagrosh#885.

There is also jagrosh#1375 which advocates for moving to youtube-dl+ffmpeg as a
replacement for lavaplayer, but that would take quite a bit of work as
it is called out in the issue.

After the OG lavaplayer repo was abandoned, the community forked it and
has been maintaining it since:

https://github.com/lavalink-devs/lavaplayer

This commit moves us from using this project's forked version to the
community's fork.

I tested this with some tracks that were returning HTTP 403s and it is
now resolved (at least in my testing...)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant