LongChair
commented
7 years ago I had to add such a patch to avoid the corruption when playing 4K media in 1080p output :
index 7e2f096..2f76e76 100644
--- a/video/out/opengl/hwdec_drmprime_drm.c
+++ b/video/out/opengl/hwdec_drmprime_drm.c
@@ -123,6 +123,13 @@ static int overlay_frame(struct gl_hwdec *hw, struct mp_image *hw_image)
int dstw = MP_ALIGN_UP(p->dst.x1 - p->dst.x0, 16);
int dsth = MP_ALIGN_UP(p->dst.y1 - p->dst.y0, 16);
+ if ((srcw >= 3840) && (dstw <= 1920))
+ {
+ pitches[0] *= 2;
+ pitches[1] *= 2;
+ srch /= 2;
+ hw_image->h /= 2
+ }
ret = drmModeAddFB2(p->kms->fd, hw_image->w, hw_image->h, desc->format,
handles, pitches, offsets, &next_frame.fb_id, 0);
But there is no chance that such a patch would make it upstream mpv as it would break other platforms, So i hope we can find a way to get that workaround put in the kernel.
yanghanxing
Kwiboo
When using 4K playback on a 1080p screen, we had some display artefacts (white horizontal lines).
After discussing with Jacob, it came out that VPU downscaling has some limitation and that 4K-> 1080p is a bit too heavy for it. So he mentionned that some other userland apps are using the "skip line trick". That trick basically doubles the line width and reduces the height by 2 so that VOP skips one line over two for downscaling.
That kind of trick can be found here : https://github.com/rockchip-linux/gstreamer-rockchip/blob/master/gst/rkximage/ximagesink.c#L608
The main problem we have with that is that in terms of rendering, we will use a generic renderer for drm. And that trick would need to be in the renderer. This will make upstreaming that trick impossible as it woudl break other platforms rendering.
We do believe that such a VOP limitation should be handled in the VOP driver and not in every single userland applciation that uses it.
I asked Mark Yao about that and he told me that it was kind of tricky to get that into upstream DRM.
At this point we have two options : 1 - either we have a patch that would be applied to kernel to handle that if this cannot make it upstream. 2 - either we keep a patch on mpv for this as upstreaming that will be refused. 3 - either this gets fixed properly in kernel upstream.
I think that -3- would be the right way to do it, because even if we get patches on 1 or 2 for LibreElec, it means that mpv will not work right without that patches on other distro (ie debian and such).
If 3 is not possible, then it would be nice to have a patch for 1.