VO xv segfaults when 4K is played #320
Comments
|
As determined on IRC, the segfault is because the XvShmCreateImage API function returns a smaller image than requested, which, if I read the manpage right, is not allowed. Broken driver? Broken something else? I don't know, but not our problem. |
ghost
closed this as 
|
May still be a good idea to gracefully fail then. |
|
Gracefully failing or telling "your hardware/driver does not support playing such files with VO xv" would be a good solution. |
|
I don't know, that's kind of like having to check whether the pointer |
|
Reported upstream: |
|
As for detecting it - asking as I do not see this in the backtrace yet: how Can we detect this from our code? Is it worth the effort? |
|
It can be easily detected, because the resulting XvImage has the "real" image dimensions set. The manpage says the real dimensions can be larger - but there's no word about them being smaller. The requested image size is way smaller than the maximal image size too. I don't really want to add hacks for things that obviously shouldn't happen. |
|
Oddly, the manpage does not say at all what should happen if the requested Also, I bet it may also enlarge dimensions in some RGB situations when So maybe we should code defensively there... But let's wait what happens on
|
|
The manpage just says: |
|
Seems vlc does some checks of xvideo related driver features and shows warning when required: |
|
No idea what this is about (their idea of DR?), but just to make it clear: we do check for the max. image size. |
|
For me vlc does show above warning: after changing vo from opengl to xv every time i try to open 4k file vlc tells that max supported resolution for xv is 2046x1744, but i try to play 4096x1744. What is mpv supposed to do when xv checks fail? Show some warning in output and skip vo? It did not do any of it. May be xv checks in mpv are different and do not fail in this case? |
|
Didn't you say xvinfo reported 8192x8192 as maximum image size? |
|
Yes, xvinfo reported 8192x8192. |
|
Can you paste your full xvinfo output? |
|
Fixes mpv-player#320 (which is closed as 'not our problem' but eh) Relevant xorg bug: https://bugs.freedesktop.org/show_bug.cgi?id=70931 For me this happened when (accidentally) trying to play a 8460x2812 jpg file with mpv. Like the referenced bug, xvinfo reports "maximum XvImage size: 8192 x 8192". So the returned XvImage is 8192x2812 and memory corruption happens. Only after handling this BadShmSeg X11 errors are shown.
Fixes #320 (which is closed as 'not our problem' but eh) Relevant xorg bug: https://bugs.freedesktop.org/show_bug.cgi?id=70931 For me this happened when (accidentally) trying to play a 8460x2812 jpg file with mpv. Like the referenced bug, xvinfo reports "maximum XvImage size: 8192 x 8192". So the returned XvImage is 8192x2812 and memory corruption happens. Only after handling this BadShmSeg X11 errors are shown.
|
Ehm. mpv had worked perfectly before this checking. It always miscalculates the correct size by 1 pixel with my buggy sis671 card. I had to remove this code to watch movies again. :-/ |
|
Fixed via 22c76e8. |
For one of my systems playing 4K files causes mov segfault when vo xv is used:
xf86-video-nouveau-1.0.9, mesa-9.1.6
bt:
The text was updated successfully, but these errors were encountered: