WIP: MPV backend for Kaffeine #13

This is a work in progress for a Kaffeine backend based on the C API of MPV.

Currently supported/implemented:

local/remote video playback (including whatever URLs youtube-dl supports)
playlists
subtitles
Konqueror/TDEParts integration
sound controls
stream recording and screenshots (optional KSnapshot integration)
context menu
media metadata

What is missing:

multiple track support
selecting video/audio output (not possible with C API?)
no DVD navigation support

More ideas:

Audio/Video filters (via af/vf)

Bugs:

[space] != play ??

To build set -DWITH_LIBMPV=ON.

Current state:
I am working on the context menu. It is not finished yet, esp. the subtitles submenu does not work as intended yet. I'll get back to this in a few days' time.

Great, let me know when you need a test.

I think it would be great to have a TDE-wide MPV backend, then various applications like amarok, kaffeine or other players could take advantage of that. What do you think?

I think it would be great to have a TDE-wide MPV backend, then various applications like amarok, kaffeine or other players could take advantage of that. What do you think?

Probably the best way for that would be a TDE API for multimedia playback with several backends, e.g. GStreamer, libMPV, Xine and possibly libVLC. If I'm not mistaken, this was something that was worked on in KDE3 days and resulted in Phonon in KDE4. Providing such unified API for applications is a great idea, but needs additional consideration. I propose discussing this in a separate issue (probably under TDE/tdemultimedia or TDE/tde).

Ok, we can address this separately. I also expect it to be a bigger task to implement.

I was just about to write an issue about the Xine backend for Kaffeine freezing near the end of playing a FLAC but it appears to be an upstream issue because I tried xine-ui and it has the same problem. All the more reason to have newer backends.

@hunter0one

I was just about to write an issue about the Xine backend for Kaffeine freezing near the end of playing a FLAC but it appears to be an upstream issue because I tried xine-ui and it has the same problem. All the more reason to have newer backends.

Have you considered reporting this bug to the Xine developers? Or has it been reported already?

I temporarily put this PR on hold to focus on other issues, but it already has the basic functions and works pretty well. You could help by compiling this and reporting any issues you notice here. :-)

@blu.256

It looks like people have had similar issues with it for over 13 years but the most recent is this and it sounds just like what I experienced, except I found out it only seems to happen near the end of playback. Either way, similar problems with FLAC have been reported, and in all of them I haven't seen any response from the Xine devs.. Good news is Kaffeine using Gstreamer doesn't have this problem, I just miss the audio visualizer effects

Sure thing. I'll try it out and report here again. EDIT: It fails while building in two places.

I temporarily put this PR on hold to focus on other issues, but it already has the basic functions and works pretty well.

I think the idea behind this PR is great, so I encourage you in your work Philippe!

@hunter0one FTBFS should be fixed now; it occured due to recent TQt-related changes.

The latest commit (screenshot) depends on TDE/tdegraphics#77.

I switched to Void Linux recently but I'll try and get a VM up to see if I can test it.

@MicheleC Would you like to test the latest version and especially the screenshot feature? It's fresh out of the oven but seems to work :-)

Hi Philippe, I built this PR on debian, installed and tested. when I select the mpv engine from the menu, kaffeine crashes. I have attached a zip of the crash dump.

Also I noticed a little thing to fix. If you look at the .desktop, .rc and folder names for gstreamer, xine and mpv, you can see that the mpv ones have a 'lib' prefix too much in the names. It would be good to be consistent with the names used in the other engines.

kaffeine_mpv.kcrash.zip

12 KiB

@MicheleC

Hi Philippe, I built this PR on debian, installed and tested. when I select the mpv engine from the menu, kaffeine crashes. I have attached a zip of the crash dump.

Strange. I remember Kaffeine crashing when switching from Xine to GStreamer, but this is new to me. Did you do anything else before switching the engine? (e.g. load a file, press a button)

Just built under debian, launched and selected the mpv xine.

Does Kaffeine launch with the selected engine on next start?

Upd.: Just viewed the crash dump. Looks like we might be trying to access an MPV handle which is not instantiated yet.

Some sort of error might be causing an error dialog to appear very early, triggering pause, while the MPV handle is not yet initialized.

It's a theory which I'll test tomorrow.

Does Kaffeine launch with the selected engine on next start?

Nope, xine is still the selected engine at the next start.

If I launch Kaffeine, select a song, start playing with xine and switch engine while playing, it does not crash. But it crashes if I try to switch back to xine engine.

@MicheleC Could you please test with the latest commit?

This should fix the crash that you sent the dump for, though I expect that you will still see an error dialog pop up, which is probably related to another bug. If you do see it, it would help if you could send the details and probably the full mpv log (which you can copy through File->View MPV log->Copy).

Thank you very much for the feedback so far. :)

Hi Philippe,
I tested the latest version under Debian.
This time kaffeine crashes at the start, without even creating a window. See attached crash dump.
I think kaffeine was set to start with mpv engine.

Thank you very much for the feedback so far. :)

No problem, that is what team work means 🙂

kaffeine.kcrash.zip

12 KiB

I think kaffeine was set to start with mpv engine.

Confirmed. I deleted kaffeinerc and kaffeine can launch with xine engine. If I switch to mpv engine, it crashes with similar crash dump.

I hope this time fixes it. I was sure that I had initialized m_mpv as a null pointer but in fact I had forgotten to do so, and anything that checked if m_mpv was initialized was bound to have unexpected behaviour... It's a miracle that it worked flawlessly for me so far.

Hi Philippe,
new test, new crash, new crash dump file.
Launched Kaffeine with xine engine. Selected mpv engine from Settings menu. SEGV.

kaffeine2.kcrash.zip

12 KiB

Well, I'm running out of ideas :(

Could you please send the stdout/stderr output, if any? I'm interested in any sort of debug information.

This is all I get if I run Kaffeine from command line:

[2023/12/02 14:53:51.449] [kaffeine] [164426] WARNING: mpv: error reading metadata
[2023/12/02 14:53:51.449] [kaffeine] [164426] WARNING: mpv: error reading metadata
libEGL warning: DRI2: failed to authenticate
VMware: No 3D enabled (0, Success).
VMware: No 3D enabled (0, Success).
[kcrash] TDECrash: Application 'kaffeine' crashing...

If this is still not enough, I guess I will need to help you debugging locally at some point :-)

It is important to note that this might be a double bug:

Something is causing an error in MPV, which is received by MpvPart and handled by trying to display an MpvErrorDlg, which in its constructor tries to pause any playing media;
Something goes wrong while trying to pause, possibly because the error pops up very early, and Kaffeine crashes.

VMware: No 3D enabled (0, Success).

Does this mean that you are testing in a VM? I remember you saying that you usually test in a VM. I'm testing on real hardware, so things are surely different. Could it be that lack of 3D acceleration somehow triggers point 1 above?

If this is still not enough, I guess I will need to help you debugging locally at some point :-)

That would be helpful, but it is not a priority right now since this PR is not totally feature complete and you are doing some very important work on TQt/tqtinterface merge.

which in its constructor tries to pause any playing media;

I have not selected any file to play in Kaffeine, so in theory there should be nothing being played

VMware: No 3D enabled (0, Success).
Does this mean that you are testing in a VM?

This one buffles me too. I do use a VM, but it is a VirtualBox one, not a VMware. No idea where and why that msg is popping up. The only vmware related package installed on my machine is xserver-xorg-video-vmware. I removed that and I still get the same crash and same weird message.

Could it be that lack of 3D acceleration somehow triggers point 1 above?

Will try enabling 3D acceleration and let you know. Just tried mpv from CLI: audio files play fine but video files give an error, so I think you assumption could be correct.

Will try enabling 3D acceleration and let you know.

I have enabled 3D acceleration and there is no more any crash.
This brings up two topics:

a user may want to use kaffeine to play audio files only, so there would be no need for any video driver/3D acceleration
TDE could be used on old hardware which potentially does not have 3D acceleration capabilities (maybe??)

I think the mpv backend should:
a. only instantiate the video backend part if needed, that is when we want to play video files
b. detect whether 3D acceleration is available or not, avoid crashing and at worst bring up a message dialog telling the users that video could not be played.

What do you think?

I have not selected any file to play in Kaffeine, so in theory there should be nothing being played

This is not totally true. On startup Kaffeine "plays" its logo file, which is a small video or image located in its data folder. This is something that all of the backends do.

only instantiate the video backend part if needed, that is when we want to play video files

This would probably mean that we would not play the logo file on startup.

detect whether 3D acceleration is available or not, avoid crashing and at worst bring up a message dialog telling the users that video could not be played.

Probably makes sense to test for 3D acceleration and handle it specially.

This is not totally true. On startup Kaffeine "plays" its logo file, which is a small video or image located in its data folder. This is something that all of the backends do.

Thanks for the info, I wasn't aware/didn't notice that.

Probably makes sense to test for 3D acceleration and handle it specially.

Yeah, probably the most sensible choice. I can help testing there are no crashes when 3D is not there.