Solved mpv couldn't play video, mplayer could

S

scottro

I thought this was kind of interesting. I had a video that made (just a scene from a movie I watched). On my main workstation it played normally. However, on the Beelink I have, it wouldn't play, but if I used mplayer it was fine. With mpv it just showed a screen of a blur with traces of a picture.
I did some searching, and I confess, I wound up going to Claude.ai. The answer turned out to be that mplayer uses vo=xv or other older vo's while mpv seems to use gpu-next, but according to Claude there's some sort of bug



Anyway, the fix, according to Claude.ai, (and all suggested fixes worked) was to either run the video as mpv --vo=xv myvid.mp4 or to add these lines to $HOME/.config/mpv/mpv.conf

vo=gpu-next
gpu-api=opengl


I read this a few days ago, and have already forgotten the details, but it may be a bug with mpv, FreeBSD, and handling of AMD gpu's. But figured I'd put these two quick fixes up here. It holds for both Wayland and X.

Doing
Code: 
mpv --vo=gpu-next
doesn't work.
So, if you have a video that won't work with mpv, but will with mplayer, either the edit of mpv.conf or the mpv vo=xv should work.[/file]
 
mpv is the the replacement for the defunct mplayer, which was initially forked as mplayer2. It is buggy, but it's also a very complex piece of software. The bugs themselves don't bug me so much as the attitude of the mpv dev team. They make it very difficult to submit bug reports and then if they are not against the latest and greatest version then they silently close and ignore the report. I understand the the issue, but when the latest is version 0.41 and the bug report is against version 0.40 I think it's kind of silly to ignore the feedback...especially with as many corner cases exist that need to be tested and debugged.

I myself don't have the time or resources to do a parallel build of mpv using all the requisite library versions just to be able to report a problem.

OP doesn't mention the type of media that wouldn't play. Knowing it's 4cc codec type would be useful. mpv, using gpu-next, will by default attempt to use the hardware mp4 decoder it it is that type and there are countless options to use different decoders or video objects.
 
scottro said:
...
I did some searching, and I confess, I wound up going to Claude.ai. The answer turned out to be that mplayer uses vo=xv or other older vo's while mpv seems to use gpu-next, but according to Claude there's some sort of bug
...yet
Click to expand...

I wonder if a local claude would have given you that answer? IE claude running with ollama and a model of choice as backend?

I have managed to ignore AI until basically these last weeks when a bad hip got worse and gave me the opportunity to fiddle around with my computers. Previous this year I have attempted to do some ports and for the one I'm working on now I have started to use the Google AI mode and it has surprised me.

I can understand why developers that have spent years of education and work experience are angry and scared at what AI can do when it comes to refactoring code.

With that said and AI being a new thing for me I find it very very very very usable providing that your questions (prompts?) are to the point.

For me the next logical step was/is to get this local so when I had overcome the "lamer" insinuation for the name I grabbed misc/ollama pulled a small model and setup misc/claude-code . Haven't had time yet to play with it but I understand now why the cost of RAM is through the roof.

/grandpa
 
scottro said:
I thought this was kind of interesting. I had a video that made (just a scene from a movie I watched). On my main workstation it played normally. However, on the Beelink I have, it wouldn't play, but if I used mplayer it was fine. With mpv it just showed a screen of a blur with traces of a picture.
I did some searching, and I confess, I wound up going to Claude.ai. The answer turned out to be that mplayer uses vo=xv or other older vo's while mpv seems to use gpu-next, but according to Claude there's some sort of bug



Anyway, the fix, according to Claude.ai, (and all suggested fixes worked) was to either run the video as mpv --vo=xv myvid.mp4 or to add these lines to $HOME/.config/mpv/mpv.conf

vo=gpu-next
gpu-api=opengl


I read this a few days ago, and have already forgotten the details, but it may be a bug with mpv, FreeBSD, and handling of AMD gpu's. But figured I'd put these two quick fixes up here. It holds for both Wayland and X.

Doing
Code: 
mpv --vo=gpu-next
doesn't work.
So, if you have a video that won't work with mpv, but will with mplayer, either the edit of mpv.conf or the mpv vo=xv should work.[/file]
Click to expand...
This commands work forme

mpv --gpu-api=opengl --hwdec=opengl
 
First of all, note that I'm NOT using multimedia/mpv directly, but via multimedia/smplayer. Output driver is default, and hardware decoding is set ot vdpau.

If I recall correctly, multimedia/mpv attempted to try CUDA on NVIDIA GPUs on some specific configurations for hardware decoding (sorry, forgot about which it was, but not cuda nor cuda-copy) and once multimedia/mpv becomes in such a situation, switching to others alone didn't help.
I thought I've set something for multimedia/mpv in advanced settings, not sure why, but it IS blank now.

The difference when I've encountered the regression and now is that I have some more ports for testing CUDA (emulators/libc6-shim, devel/libepoll-shim and science/linux-ai-ml-env) now.
 
You must log in or register to reply here.
Back
Top