Red line artifacts on x265 playback on latest git on Arch ARM RPi4 #18444

graysky2 · 2020-09-19T21:32:40Z

Bug report

Describe the bug

Playback of a 4k, x265 video on RPi4 gbm build (latest git) on Arch ARM is polluted with red line artifacts. 1080p x265 content is fine.

Expected Behavior

Playback should be artifact-free.

Actual Behavior

Playback is polluted with red line artifacts.

Possible Fix

Help me understand why my build is affected. I do not see this on for example LibreLE.

To Reproduce

Steps to reproduce the behavior:

Download this 4k x265 sample video.
Install Arch ARM's kodi-rbp4-git package on RPi4 running Arch ARM armv7h.
Try to playback the video. This has been confirmed on several machines.

If you're new to Arch, just login to the system (usernames/passwords shown in the install guide I linked above) update the system, then install kodi-rbp4-git, reboot (changes to /boot/config.txt need to be active), and start kodi:

(as root)
pacman -Syyu
pacman -S kodi-rbp4-git
reboot
systemctl start kodi

Debuglog

The debuglog can be found here: https://gist.github.com/graysky2/b6ed24d7e9f8baaa1b0d3f056320745e

Screenshots

Here are some links or screenshots to help explain the problem:

Additional context or screenshots (if appropriate)

Here is some additional context or explanation that might help:
Kodi for Arch ARM is currently built by this PKGBUILD. Here is the expanded cmake stanza for context:

  cmake -DCMAKE_INSTALL_PREFIX=/usr \
    -DCMAKE_INSTALL_LIBDIR=/usr/lib \
    -DENABLE_EVENTCLIENTS=ON \
    -DENABLE_INTERNAL_FFMPEG=ON \
    -DENABLE_INTERNAL_FMT=ON \
    -DENABLE_INTERNAL_CROSSGUID=ON \
    -DENABLE_INTERNAL_FSTRCMP=ON \
    -DENABLE_INTERNAL_FLATBUFFERS=ON \
    -DENABLE_INTERNAL_SPDLOG=ON \
    -DENABLE_EVENTCLIENTS=ON \
    -DENABLE_VAAPI=OFF \
    -DENABLE_VDPAU=OFF \
    -DENABLE_OPENGL=OFF \
    -DENABLE_MYSQLCLIENT=ON \
    -Dlibdvdcss_URL="/libdvdcss-1.4.2-Leia-Beta-5.tar.gz" \
    -Dlibdvdnav_URL="/libdvdnav-6.0.0-Leia-Alpha-3.tar.gz" \
    -Dlibdvdread_URL="/libdvdread-6.0.0-Leia-Alpha-3.tar.gz" \
    -DFFMPEG_URL="/ffmpeg-4.3.1-Matrix-Alpha1-1.tar.gz" \
    -DFMT_URL="/fmt-6.1.2.tar.gz" \
    -DCROSSGUID_URL="/crossguid-8f399e8bd4.tar.gz" \
    -DFSTRCMP_URL="/fstrcmp-0.7.D001.tar.gz" \
    -DFLATBUFFERS_URL="/flatbuffers-1.11.0.tar.gz" \
    -DSPDLOG_URL="/spdlog-1.5.0.tar.gz" \
    -DCORE_PLATFORM_NAME=gbm \
    -DGBM_RENDER_SYSTEM=gles \
    ../xbmc-e29db7f3918460193c89c486e34e26d0d3ffe6b8

Your Environment

Used Operating system:

Linux
Operating system version/name: Arch ARM armv7h for RPi4
Kodi version: 19.0.r55946.e29db7f391

The text was updated successfully, but these errors were encountered:

graysky2 · 2020-09-21T19:54:27Z

@fuzzard - Would you like me to build 7f6bf8f and apply #18450 to test for a fix?

fuzzard · 2020-09-21T19:56:06Z

Sure, go nuts. Probably worth someone else verifying it for the pr author. If it doesn't fix this issue, I'll unlink it from that pr

graysky2 · 2020-09-21T20:33:56Z

@fuzzard - Just applying that PR to 7f6bf8f did not fix the issue unfortunately.

Link to debug log: https://gist.github.com/graysky2/3c93259256ec88aee718b04501a589a4

lrusak · 2020-09-22T01:07:06Z

Seems like it's an 8 bit HEVC. Does it work with 10 bit HEVC?


2020-09-21 17:15:44.889 T:438     DEBUG <general>: plane::SupportsFormatAndModifier - found plane format (YU12) and modifier (0x0)

Likely the lack of modifiers (linear) is causing the banding. I'm not sure why that's happening but perhaps it's a kernel problem (v4l2 decoder not outputting the correct format)

popcornmix · 2020-09-22T10:04:09Z

@graysky2 can you test this with a LibreELEC nightly? It's not an effect I've seen.

(from forum thread it looks like it works correctly with a fairly recent LE nightly build).

I've just tested with latest nightly and it's still good.

I don't see the issue on my own gbm build compiled on Pi4 using RPiOS.

At a guess I'd say the luma pointer is correct but chroma is pointing at garbage.

Some mismatch in build options between kernel/ffmpeg/kodi seems most likely.

I'll ask our codec guy if he can think of anything.

popcornmix · 2020-09-22T10:22:10Z

@graysky2 what is your cma setting?
LE uses "dtoverlay=vc4-fkms-v3d,cma-size=402653184"

popcornmix · 2020-09-22T10:38:33Z

Can you report the kernel version? (ideally git hash it was built from, but "uname -a" output if not.
Also output of "vcgencmd version"

jc-kynesim · 2020-09-22T10:49:53Z

OK - I've no immediate ideas as to why you get that. The modifiers hold the "vertical stride" which is the same for both luma & chroma so given that there appears to be a generally plausible luma there I would guess it is getting through (though the apparent repeats in chroma look like both stride1 & stride2 are zero and I've no idea how you achieve that). It seems very odd to me that you get this artefact with 4k but not with 1080. Do other resolutions work/not-work? Is it all 4k streams?

popcornmix · 2020-09-22T10:58:48Z

Also what about 4k 10-bit hevc?

graysky2 · 2020-09-22T11:38:47Z

@lrusak -

Seems like it's an 8 bit HEVC. Does it work with 10 bit HEVC?

I cannot seem to play 4k HEVC 10-bit content at all. For example, HEVC 10-bit 59.940fps (Korean ATSC 3.0 satellite TV capture sample) from the samples wiki page.

Here I get the animated circles Kodi shows while it loads but I never get video.

Here is my debug log when I try: https://gist.github.com/graysky2/f1bbf3c6eb96192e4d1de11181562098

Note that I can play 1080p 10-bit content just fine, this only happens with 4K content.

graysky2 · 2020-09-22T11:41:17Z

@jc-kynesim - I only tried 4k and 1080p so far. So far no 4k content works and all 1080p content works.

graysky2 · 2020-09-22T11:47:56Z

@popcornmix -

can you test this with a LibreELEC nightly? It's not an effect I've seen.

Yes, the latest LE nightly does NOT show this issue, tested LibreELEC-RPi4.arm-9.80-nightly-20200920-1fcfe6a.tar

what is your cma setting?

I took the settings directly from LE.

% cat /boot/config.txt
#!/bin/sh
# See /boot/overlays/README for all available options

initramfs initramfs-linux.img followkernel

[all]
include kodi-gbm.config.txt

% cat /boot/kodi-gbm.config.txt
# https://github.com/LibreELEC/LibreELEC.tv/blob/master/projects/RPi/devices/RPi4/config/distroconfig.txt

dtoverlay=vc4-kms-v3d-pi4,cma-size=402653184
dtoverlay=rpivid-v4l2
disable_overscan=1

Can you report the kernel version? (ideally git hash it was built from, but "uname -a" output if not. Also output of "vcgencmd version"

I have been experiencing this for quite some time, but as I type this, the current kernel is built from raspberrypi/linux@1cbfe9e and:

% uname -a
Linux workbench 5.4.65-1-ARCH #1 SMP PREEMPT Tue Sep 15 11:03:20 EDT 2020 armv7l GNU/Linux

And

% /opt/vc/bin/vcgencmd version
Sep 17 2020 12:31:34
Copyright (c) 2012 Broadcom
version 6105bb6ab6db9d62a57ce2bb96c527a2cc46a717 (clean) (release) (start)

jc-kynesim · 2020-09-22T12:45:47Z

I'd be interested if you could try with some other resolutions. There isn't much in the decoder that has ideas about size. 1920x1088 was intended to be the default size if otherwise unspecified though until recently that was broken in a way that would probably have failed to init. Also is there anything in dmesg? The H265 decoder emits a small amount of info by default and should log cases where it detects errors.

jc-kynesim · 2020-09-22T12:52:38Z

One more question - are you playing to a 4k TV or something else? It shouldn't make any difference but then nor should 4k/not-4k.

graysky2 · 2020-09-22T12:57:58Z

I'd be interested if you could try with some other resolutions.

@jc-kynesim - I am happy to try other resolutions. To be clear, are you asking me to switch the resolution in Kodi to something else while trying to playback the same 4K video or are you asking me to try to find some 4K videos in different resolutions and play them with Kodi set to 4K?

Also is there anything in dmesg? The H265 decoder emits a small amount of info by default and should log cases where it detects errors.

I did not see anything printed to dmesg when I played back that 8-bit clip.

One more question - are you playing to a 4k TV or something else? It shouldn't make any difference but then nor should 4k/not-4k.

I do not own a 4k TV. I have the RPi4 hooked up to a 4K monitor (cheap Philips 276E8V).

graysky2 · 2020-09-22T13:00:03Z

I was wondering what you guys think about the repeating output when I try playing the 10-bit 4K HEVC sample from my comment above #18444 (comment)

The kodi.log is filled with lines like this:

...
2020-09-22 07:36:55.052 T:3425    ERROR <general>: ffmpeg[(nil)X]: [hevc] Duplicate POC in a sequence: 2.
2020-09-22 07:36:55.052 T:3425    DEBUG <general>: ffmpeg[(nil)X]: [hevc] Error parsing NAL unit #1.
2020-09-22 07:36:55.361 T:3429    ERROR <general>: CDVDVideoCodecDRMPRIME::GetPicture - videoBuffer:nullptr format:yuv420p10le
2020-09-22 07:36:55.361 T:3429    DEBUG <general>: CVideoPlayerVideo - video decoder returned error
2020-09-22 07:36:55.383 T:3429    ERROR <general>: CDVDVideoCodecDRMPRIME::GetPicture - videoBuffer:nullptr format:yuv420p10le
2020-09-22 07:36:55.383 T:3429    DEBUG <general>: CVideoPlayerVideo - video decoder returned error
2020-09-22 07:36:55.384 T:3429    ERROR <general>: CDVDVideoCodecDRMPRIME::AddData - send packet failed: Invalid data found when processing input (-1094995529)
2020-09-22 07:36:55.784 T:3429    ERROR <general>: CDVDVideoCodecDRMPRIME::GetPicture - videoBuffer:nullptr format:yuv420p10le
2020-09-22 07:36:55.784 T:3429    DEBUG <general>: CVideoPlayerVideo - video decoder returned error
2020-09-22 07:36:55.881 T:3429    ERROR <general>: CDVDVideoCodecDRMPRIME::GetPicture - videoBuffer:nullptr format:yuv420p10le
2020-09-22 07:36:55.881 T:3429    DEBUG <general>: CVideoPlayerVideo - video decoder returned error
2020-09-22 07:36:55.882 T:3429    ERROR <general>: CDVDVideoCodecDRMPRIME::GetPicture - videoBuffer:nullptr format:yuv420p10le
2020-09-22 07:36:55.882 T:3429    DEBUG <general>: CVideoPlayerVideo - video decoder returned error
2020-09-22 07:36:56.044 T:3429    ERROR <general>: CDVDVideoCodecDRMPRIME::GetPicture - videoBuffer:nullptr format:yuv420p10le
2020-09-22 07:36:56.045 T:3429    DEBUG <general>: CVideoPlayerVideo - video decoder returned error
2020-09-22 07:36:56.118 T:3429    ERROR <general>: CDVDVideoCodecDRMPRIME::GetPicture - videoBuffer:nullptr format:yuv420p10le
2020-09-22 07:36:56.118 T:3429    DEBUG <general>: CVideoPlayerVideo - video decoder returned error
2020-09-22 07:36:56.138 T:3429    ERROR <general>: CDVDVideoCodecDRMPRIME::GetPicture - videoBuffer:nullptr format:yuv420p10le
...

jc-kynesim · 2020-09-22T13:25:36Z

Re resolutions - I meant please try clips that are neither 4k nor 1080p, 720p for instance and/or other random resolutions. I do not care about display resolution.
4k TV == 4k monitor for this purpose - I was wondering about scaling
No dmesg is odd - I think v4l2_info lines come out by default - I would have expected a line along the lines of "rpivid_h265_start: (1920x1080)" at the start of decode and "rpivid_h265_stop" at the end.

lrusak · 2020-09-22T13:42:48Z

@graysky2 do you have the setting enabled to allow HW decoding using DRMPRIME?

Settings -> player -> video

jc-kynesim · 2020-09-22T14:03:44Z

@lrusak I take it you get some dmesg logging when using the V4L2 H265 decode?

graysky2 · 2020-09-22T14:22:37Z

do you have the setting enabled to allow HW decoding using DRMPRIME?

@lrusak - Yes:

Enable EQ scalers for scaling above 20%
Allow using DRM PRIME decoder = enabled
Allow hardware acceleration with DRM PRIME = enabled
PRIME Render Method = Direct To Plane

@jc-kynesim - I will try to find some 720p 8bit HEVC and 720p 10bit HEVC and report back.

I just built fbef8cf and played back the 4k 8bit HEVC I linked above.

Still got red lines
The only thing I got in dmesg after I started playback was:

[Sep22 10:20] vc4_hdmi fef05700.hdmi: ASoC: can't open interface fef05700.hdmi: -19
[  +0.001242] vc4_hdmi fef05700.hdmi: ASoC: can't open interface fef05700.hdmi: -19
[  +0.001200] vc4_hdmi fef05700.hdmi: ASoC: can't open interface fef05700.hdmi: -19
[  +0.000456] vc4_hdmi fef05700.hdmi: ASoC: can't open interface fef05700.hdmi: -19
[  +0.000433] vc4_hdmi fef05700.hdmi: ASoC: can't open interface fef05700.hdmi: -19

Here is debug log from that: https://gist.github.com/graysky2/9faec1f213129ea64b4f2b900d3557bb

graysky2 · 2020-09-22T14:36:10Z

@jc-kynesim - I managed to locate some 720p HEVC content, one 8-bit and the other 10-bit. I do not believe they are copyright free so I do not want to post URLs.

Summary:
I can play the 8-bit one just fine without redlines. I cannot play the 10-bit one at all. No playback.

Log playing back the 8-bit clip: https://gist.github.com/graysky2/24e40d4c931df3fa7199972f80debab1
Log trying to play back the 10-bit clip: https://gist.github.com/graysky2/60349cb2768a713439a3127ab478e15a

jc-kynesim · 2020-09-22T14:37:34Z

There is an option for turning on FFmpeg debug too in Kodi. I've forgotten where it lives though. If you can find it and turn it on it might reveal something in the logs.
Ta

graysky2 · 2020-09-22T15:10:51Z

@jc-kynesim - I googled quite a bit for this but came up empty. Would it be through edited advancedsettings.xml or via commandline switch or within the Kodi GUI menus/expert mode?

popcornmix · 2020-09-22T15:12:08Z

In settings/system/logging there is a component specific debug. Enable that and turn on ffmpeg from the options.

graysky2 · 2020-09-22T15:17:47Z

@popcornmix - Yes, thank you! I just found it also.

Here is a debug log playing back the video I linked (filename is BigBuckBunny_2000hevc.mp4) above that plays but with red line artifacts: https://gist.github.com/graysky2/2f5aff9bd0bebe7d3e8885ef166fb322

Here is a debug log trying to play back HEVC 10-bit 59.940fps (Korean ATSC 3.0 satellite TV capture sample) from the samples wiki page. Here no video is displayed at all: https://gist.github.com/graysky2/d0ad319dacca832c8d8a6e3159aa794c

Both are using kodi built from fbef8cf

popcornmix · 2020-09-22T15:23:58Z

My understanding is that a kodi master build won't support hevc decode as that requires ffmpeg patches that haven't made it upstream yet. I'm not quite sure what will happen here - I'd assume it would fall back to software decode.
These ffmpeg patches are present in my gbm branch and in LE and should allow hardware decode.

popcornmix · 2020-09-28T13:06:03Z

With vc4-fkms-v3d you need dtparam=audio=on and you need to switch to that audio device on kodi system/audio settings.

a-ucontrol · 2020-09-28T13:24:06Z

To be clear, when you boot using dtoverlay=vc4-kms-v3d-pi4,cma-size=402653184 (which is how LE does it), you too experience red line artifacts on some 4k videos as I documented in this report?

When I change the dtoverlay to vc4-fkms-v3d,cma-size=402653184 I am unable to play back anything. The kodi.log is filled with audio errors, can't find sink, etc.

Yes, with a resolution of 3840x2160 and vc4-kms-v3d-pi4, without cma the artifacts are the same.

graysky2 · 2020-09-28T13:31:33Z

With vc4-fkms-v3d you need dtoverlay=audio=on and you need to switch to that audio device on kodi system/audio settings.

Interestingly, system/audio "Audio output device" is grayed out.

# cat /boot/config.txt:

dtoverlay=vc4-fkms-v3d,cma-size=402653184
dtoverlay=audio=on
disable_overscan=1

Kodi log is spammed with lines line:

2020-09-28 13:31:01.746 T:417     ERROR <general>: ActiveAE::InitSink - returned error
2020-09-28 13:31:02.247 T:418      INFO <general>: CActiveAESink::OpenSink - initialize sink
2020-09-28 13:31:02.247 T:418     ERROR <general>: CActiveAESink::OpenSink - no sink was returned

a-ucontrol · 2020-09-28T13:59:10Z

I have something like this

#cat /boot/config.txt:

dtparam=audio=on

#device_tree=bcm2711-rpi-4-b.dtb
dtoverlay=vc4-fkms-v3d
dtoverlay=rpivid-v4l2

disable_overscan=1
disable_splash=1
initial_turbo=60

popcornmix · 2020-09-28T14:17:20Z

Yes - dtparam rather than dtoverlay

graysky2 · 2020-09-28T14:55:16Z

OK! That made all the difference. Now, if I boot using the following, I have no red lines at all. When I switch over to popcornmix/gbm I get HW decoding on all files.

dtoverlay=vc4-fkms-v3d,cma-size=402653184
dtoverlay=rpivid-v4l2
dtparam=audio=on
disable_overscan=1

popcornmix · 2020-09-28T14:58:43Z

Okay, that's interesting. It narrows the problem down to rendering in the kms driver.
This is still in a beta state. The 5.9 kernel is closer to upstream and has some additional improvements.
Are you able to test that easily?

a-ucontrol · 2020-09-28T15:03:12Z

OK! That made all the difference. Now, if I boot using the following, I have no red lines at all. When I switch over to popcornmix/gbm I get HW decoding on all files.

Yes, but vc4-kms-v3d-pi4 works better. Without tearing.
Unfortunately does not support 3840x2160@60 and redline artifacts at 4k.

graysky2 · 2020-09-28T15:21:51Z

The 5.9 kernel is closer to upstream and has some additional improvements. Are you able to test that easily?

I am happy to try. Beyond updating the kernel package, are there any changes to the bootloader or firmware etc. that I need to also change?

popcornmix · 2020-09-28T15:25:41Z

Shouldn't be. As long as they are vaguely current switching between 5.4 and 5.9 should be straightforward.

graysky2 · 2020-09-28T19:51:33Z

@popcornmix - Just had to disable CONFIG_CRYPTO_AEGIS128_SIMD to get a successful build of raspberrypi/linux@62acfe9 ... red line artifacts persist when I use dtoverlay=vc4-kms-v3d-pi4,cma-size=402653184 under that kernel as as 5.4.y branch.

If it is something in kms... why doesn't the bug manifest on LE?

graysky2 · 2020-09-28T19:59:42Z

I should note that as @a-ucontrol noted, using vc4-fkms-v3d causes issues. For me, it's with video skipping ahead on playback all by itself. The log starts with entry CVideoPlayerAudio::Process - stream stalled when I try playing back jellyfish-140-mbps-4k-uhd-hevc-10bit.mkv.

Debug log: https://gist.github.com/graysky2/b88feebaa9e1755018b4adeff6de52d4
@popcornmix - This is with your popcornmix@6b9c53e

EDIT: I am wrong... I get similar errors if I use dtoverlay=vc4-kms-v3d-pi4,cma-size=402653184 as well.

popcornmix · 2020-09-29T10:45:30Z

What resolution are you using in system/video settings? If it's 4k try 1080p.
LE and my builds limit to 1080p as 4k is not fully working.
This commit avoids 4k modes being chosen.

a-ucontrol · 2020-09-29T11:29:40Z

At 1080p I have a normal image.
Artifacts appear when the resolution is 3840x2160@30, 4K video and HW decoding.

popcornmix · 2020-09-29T11:39:07Z

For me, even the kodi gui is corrupted at 3840x2160@30. I'm a little surprised you could use kodi at all at that resolution,
and is why we have the kernel patch to disable 4k modes. Stick to 1080p limit for now. Work is ongoing for proper 4k support on kms.

graysky2 · 2020-10-07T16:18:03Z

@popcornmix - I just built b0dfb3e and it does not exhibit the red line artifacts I initially reported.

Arch ARM, kernel 5.4.70

dtoverlay=vc4-kms-v3d,cma-384
dtoverlay=rpivid-v4l2
dtparam=audio=on
disable_overscan=1

popcornmix · 2020-10-07T16:20:19Z

I suspect that is just by luck. The fix will be in kernel not kodi. Avoid 4K hdmi modes for now.

popcornmix · 2021-03-23T18:25:31Z

@graysky2 I assume this can be closed?
I think it was fixed here: raspberrypi/linux#4075

graysky2 · 2021-03-23T18:33:52Z

I think it's 100% safe to close this. Thanks to everyone who contributed to the discussion and fix.

graysky2 · 2021-03-23T18:37:27Z

@popcornmix - As an aside, I have read mixed things about 60fps running in 4k on the RPi4B. Is this possible in Matrix?

After adding hdmi_enable_4kp60=1 to /boot/config.txt Kodi is pissed. Monitor keeps turning off and on in the Kodi GUI. I also only see options for refresh rates at 4k of: 30.00, 29.97, 25.00, 24.00, and 23.98.

popcornmix · 2021-03-24T10:18:30Z

It needs this series of patches
(also on my kodi/rpi4-kms branch.

graysky2 · 2021-03-24T12:29:26Z

That's excellent. It seems I need more than just those 5 patches. I applied them to the latest commit from rpi-5.10.y (raspberrypi/linux@e1499ba) but the build ended in errors:

...
  CC [M]  drivers/gpu/drm/vc4/vc4_plane.o
drivers/gpu/drm/vc4/vc4_hdmi.c: In function ‘vc4_hdmi_bind’:
drivers/gpu/drm/vc4/vc4_hdmi.c:2691:19: error: implicit declaration of function ‘clk_get_max_rate’; did you mean ‘clk_set_max_rate’? [-Werror=implicit-function-declaration]
 2691 |   long max_rate = clk_get_max_rate(vc4->hvs->core_clk);
      |                   ^~~~~~~~~~~~~~~~
      |                   clk_set_max_rate
  CC [M]  fs/xfs/libxfs/xfs_bit.o
...
  CC [M]  fs/nilfs2/dat.o
cc1: some warnings being treated as errors
distcc[31559] ERROR: compile drivers/gpu/drm/vc4/vc4_hdmi.c on localhost failed
make[4]: *** [scripts/Makefile.build:279: drivers/gpu/drm/vc4/vc4_hdmi.o] Error 1
make[3]: *** [scripts/Makefile.build:496: drivers/gpu/drm/vc4] Error 2
make[2]: *** [scripts/Makefile.build:496: drivers/gpu/drm] Error 2
make[1]: *** [scripts/Makefile.build:496: drivers/gpu] Error 2
make: *** [Makefile:1810: drivers] Error 2
make: *** Waiting for unfinished jobs....
...
```****

popcornmix · 2021-03-24T13:28:52Z

Take this to forums - it's spamming kodi devs with notifications.

xbmc-gh-bot bot added the Triage: Needed (managed by bot!) issue that was just created and needs someone looking at it label Sep 19, 2020

fuzzard linked a pull request Sep 21, 2020 that will close this issue

[gbm] Fix check for supported broadcom modifiers #18450

Merged

13 tasks

lrusak closed this as completed in #18450 Sep 21, 2020

fuzzard reopened this Sep 22, 2020

DaveTBlake added Triage: Confirmed issue has been reproduced by a team member Platform: Linux v19 Matrix and removed Triage: Needed (managed by bot!) issue that was just created and needs someone looking at it Triage: Confirmed issue has been reproduced by a team member labels Dec 8, 2020

graysky2 closed this as completed Mar 23, 2021

Red line artifacts on x265 playback on latest git on Arch ARM RPi4 #18444

Red line artifacts on x265 playback on latest git on Arch ARM RPi4 #18444

Comments

graysky2 commented Sep 19, 2020 • edited

Bug report

Describe the bug

Expected Behavior

Actual Behavior

Possible Fix

To Reproduce

Debuglog

Screenshots

Additional context or screenshots (if appropriate)

Your Environment

graysky2 commented Sep 21, 2020

fuzzard commented Sep 21, 2020

graysky2 commented Sep 21, 2020 • edited

lrusak commented Sep 22, 2020 • edited

popcornmix commented Sep 22, 2020 • edited

popcornmix commented Sep 22, 2020

popcornmix commented Sep 22, 2020

jc-kynesim commented Sep 22, 2020

popcornmix commented Sep 22, 2020

graysky2 commented Sep 22, 2020 • edited

graysky2 commented Sep 22, 2020

graysky2 commented Sep 22, 2020

jc-kynesim commented Sep 22, 2020

jc-kynesim commented Sep 22, 2020

graysky2 commented Sep 22, 2020

graysky2 commented Sep 22, 2020

jc-kynesim commented Sep 22, 2020

lrusak commented Sep 22, 2020

jc-kynesim commented Sep 22, 2020

graysky2 commented Sep 22, 2020

graysky2 commented Sep 22, 2020

jc-kynesim commented Sep 22, 2020

graysky2 commented Sep 22, 2020

popcornmix commented Sep 22, 2020

graysky2 commented Sep 22, 2020 • edited

popcornmix commented Sep 22, 2020

popcornmix commented Sep 28, 2020 • edited

a-ucontrol commented Sep 28, 2020

graysky2 commented Sep 28, 2020

a-ucontrol commented Sep 28, 2020

popcornmix commented Sep 28, 2020

graysky2 commented Sep 28, 2020

popcornmix commented Sep 28, 2020

a-ucontrol commented Sep 28, 2020

graysky2 commented Sep 28, 2020

popcornmix commented Sep 28, 2020

graysky2 commented Sep 28, 2020 • edited

graysky2 commented Sep 28, 2020 • edited

popcornmix commented Sep 29, 2020

a-ucontrol commented Sep 29, 2020

popcornmix commented Sep 29, 2020

graysky2 commented Oct 7, 2020

popcornmix commented Oct 7, 2020

popcornmix commented Mar 23, 2021

graysky2 commented Mar 23, 2021

graysky2 commented Mar 23, 2021 • edited

popcornmix commented Mar 24, 2021

graysky2 commented Mar 24, 2021 • edited

popcornmix commented Mar 24, 2021

graysky2 commented Sep 19, 2020 •

edited

graysky2 commented Sep 21, 2020 •

edited

lrusak commented Sep 22, 2020 •

edited

popcornmix commented Sep 22, 2020 •

edited

graysky2 commented Sep 22, 2020 •

edited

graysky2 commented Sep 22, 2020 •

edited

popcornmix commented Sep 28, 2020 •

edited

graysky2 commented Sep 28, 2020 •

edited

graysky2 commented Sep 28, 2020 •

edited

graysky2 commented Mar 23, 2021 •

edited

graysky2 commented Mar 24, 2021 •

edited