Bug 1185276

Some additional output. Note: once the flicker begins on one channel, only a restart of the program may! help to get rid of it. Until you change to often...

[h264 @ 0x7fbc88003d40] mmco: unref short failure
[00007fbc8410e640] avcodec decoder error: hardware acceleration picture allocation failed
[h264 @ 0x7fbc88003d40] get_buffer() failed
[h264 @ 0x7fbc88003d40] thread_get_buffer() failed
[h264 @ 0x7fbc88003d40] decode_slice_header error
[h264 @ 0x7fbc88003d40] no frame!
[h264 @ 0x7fbc88770c40] mmco: unref short failure
[h264 @ 0x7fbc88770c40] number of reference frames (0+5) exceeds max (4; probably corrupt input), discarding one

Created attachment 848741 [details]
Output of CLI Kaffeine

some more output for completeness.

What else can be observed. 
During the problem with the HD channels, sometimes the second monitor does fail to synchronize and flickers. 
The machine has one graphics card AMD with a HDMI and a VGA.

The first monitor (main) is central and on the HDMI. It is a 
Messeltronik Dresden GmbH (Medion) MD20666 (HDMI-0) 1920 x 1080 with 60 Hz.

The second on VGA is:
Acer AL1716 (DVI-0) (1280x1024) with 60 Hz (can be run on 75 Hz but does not change anything. 

When the Hauppauge card becomes shaky with the HD picture on the Medion the Acer Monitor begins to flicker too. Changing to SD channel stops this.

Hmm. Can you add the output when runing "vainfo"?  (libva-utils package) Outpuf of "vdpauinfo" (package libvdpau1) would also
be useful.

Hi Stefan, always a pleasure. 

So:
entropy@silversurfer:~> vainfo
libva info: VA-API version 1.11.0
libva info: Trying to open /usr/lib64/dri/r600_drv_video.so
libva info: Found init function __vaDriverInit_1_11
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.11 (libva 2.11.1)
vainfo: Driver version: Mesa Gallium driver 21.0.2 for AMD CEDAR (DRM 2.50.0 / 5.11.16-1-default, LLVM 12.0.0)
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointVLD
      VAProfileNone                   : VAEntrypointVideoProc

And: vdpauinfo in attachment as a txtfile (as it is large) 

Some more information:
sometimes when the picture gets green and the HD program and kaffeine stops completely, you have to kill it with alt-cntr-esc as it does not react any more. 
Two scenarios happen:
a) suddenly you discover a "second" instance of kaffeine that works below the actual or
b) the x-server becomes a zombie and you have to kill it.

Created attachment 848921 [details]
vdpauinfo as requested.

Here you go with the vdpau txt in attachement.

Thanks. Both outputs look good to me. I'm not familiar with kaffeine. Mabye you can explicitely chosse between VDPAU or VA-API  and find a combination that works for you - as workaround.

(In reply to Stefan Dirsch from comment #7)
> Thanks. Both outputs look good to me. I'm not familiar with kaffeine. Mabye
> you can explicitely chosse between VDPAU or VA-API  and find a combination
> that works for you - as workaround.

as unique workaround I found (since also vlc is hit by this, kaffeine is only a frontend to it) that you have to deactivate both to well watch videos. So both vdpau and vaapi are gone. 
At most you can watch one movie without changing and afterwards "rien ne va plus". E.g. I did cut with vidcutter a hd movie, after no way to watch in kaffeine, no way to cut in vidcutter, just watch the uncut file in vlc without hardware acceleration.

Resolved with the kernel update from yesterday.

Wow. It has been a kernel issue! So it must have been a temporary radeon driver issue in Kernel 5.11.x and is fixed again with Kernel 5.12.

too optimistic. The problem is back. 
Even if I would postulate a hardware based problem, the fact that vidcutter still works shows it is not just hardware. 
Now instead it seems that either handbrake is abortive with videofiles that are created by the sat card (producing mv4 files without sound (while the m2t files play with sound), or that handbrake encoding is broken. 

This is quite a problem. 
I will try to encode a video file in another handbrake version with a virtualised linux distribution. 
Just to see if the output is broken or if the videofile m2t is borked.

Oh, and of course.....HD flickers.

Ok. :-(

So:
VAAPI seems broken
VDPAU broken
Kaffeine does not register in programmed mode apparently creates only one huge videofile if you program movies on the same channel and aborts programmed registration. 
the converted files have no sound

only standard channels can be watched. 

This is quite a mess. 

When this happens the temperature of the graphic card begins to climb. 
When you, as first instance after a reboot, begin e.g. with ZDF HD and DO NOT CHANGE a channel, the HD program will work. As soon as you change e.g. on ARTE HD it is broken and then it stays broken until reboot. 

Is kaffeine still a supported frontend for vlc or has it been abandoned? 

the frustrating thing is: there is no alternative for satellite TV in linus, at least not a userfriendly, easy working program. 
And that does not solve the cutting, converting issues. 

For what I do understand from the CLI output, the driver for my AMD graphics is broken?
libva info: VA-API version 1.11.0
libva info: Trying to open /usr/lib64/dri/r600_drv_video.so
libva info: Found init function __vaDriverInit_1_11
libva info: va_openDriver() returns 0
[00007faf940130d0] glconv_vaapi_x11 gl error: vaDeriveImage: operation failed
[00007faf7c018ec0] main video output error: video output creation failed
[00007faf84010b10] main decoder error: failed to create video output
[00007faf94787ee0] gl gl: Initialized libplacebo v3.120.2 (API v120)
[00007faf84010b10] avcodec decoder: Using G3DVL VDPAU Driver Shared Library version 1.0 for hardware decoding
[00007faf84010b10] avcodec decoder error: hardware acceleration picture allocation failed
[mpeg2video @ 0x7faf7c013fc0] get_buffer() failed
[mpeg2video @ 0x7faf7c013fc0] thread_get_buffer() failed
[mpeg2video @ 0x7faf7c013fc0] get_buffer() failed (-1 (nil))

So:
in VLC the playback of mkv matrioshka files also fails with the same problems like kaffeine. Sound is good but video flickers wildly with artifacts or still image. 
There is one setting that works:

automatic : does not work
va-api: does not work 
vdpau does not work
va-api through DRM: does work in vlc for mkv files and does eliminate the flicker. 

Looking up the syntax in the config of vlc and setting kaffeine with the parameter:
--avcodec-hw=vaapi_drm

does however not influence the original problem of HD channels in Kaffeine. 

Should I open a seperate bug report on the automatic setting of vlc being broken?

OK, this is interesting. The setting HAS effect but id depending on the channel.

3 Sat HD is working without flicker
Arte too.

But all German public channels "Das Erste HD", the "ZDF HD", zdf Neo HD they all flicker. 

Still some progress and maybe some hint on the issue?

All reproduction of HD channels with the aforementioned hardware asset is now:
black screen only sound. 

So Kaffeine is currently broken for HD satellite cards.

After the mesa and amd driver (r600) updates of today the program is still broken. However the error message in CLI changes for HD channel as follows (screen remains black):
kaffeine
16-05-21 11:00:39.794 [Debug   ] Icon theme "gnome" not found.
16-05-21 11:00:39.794 [Debug   ] Icon theme "ubuntu-mono-dark" not found.
16-05-21 11:00:39.794 [Debug   ] Icon theme "Mint-X" not found.
16-05-21 11:00:39.794 [Debug   ] Icon theme "elementary" not found.
16-05-21 11:00:39.794 [Debug   ] Icon theme "gnome" not found.
16-05-21 11:00:39.822 [Warning ] QCommandLineParser: already having an option named "h"
16-05-21 11:00:39.822 [Warning ] QCommandLineParser: already having an option named "help-all"
16-05-21 11:00:39.822 [Warning ] QCommandLineParser: already having an option named "v"
16-05-21 11:00:40.471 [Info    ] kaffeine.dvb: Using built-in dvb device manager
16-05-21 11:00:41.028 [Info    ] kaffeine.dev: Found dvb device P14f188800070f038: Montage Technology M88RS6000
16-05-21 11:00:41.070 [Info    ] kaffeine.dev: Found dvb device P14f188800070f038: Silicon Labs Si2168
[00007f0744006450] gl gl: Initialized libplacebo v3.120.3 (API v120)
libva info: VA-API version 1.11.0
libva info: Trying to open /usr/lib64/dri/r600_drv_video.so
libva info: Found init function __vaDriverInit_1_11
libva info: va_openDriver() returns 0
[00007f0744006450] glconv_vaapi_x11 gl error: vaDeriveImage: operation failed
[00007f0750077800] main video output error: video output creation failed
[00007f076402dab0] main decoder error: failed to create video output
[00007f0744006450] gl gl: Initialized libplacebo v3.120.3 (API v120)
libva info: VA-API version 1.11.0
libva info: Trying to open /usr/lib64/dri/r600_drv_video.so
libva info: Found init function __vaDriverInit_1_11
libva info: va_openDriver() returns 0
[00007f076402dab0] avcodec decoder: Using OpenGL/VAAPI backend for VDPAU for hardware decoding
[00007f0744006450] glconv_vdpau gl error: glVDPAUMapSurfacesNV failed: 0x502

[00007f0744006450] glconv_vdpau gl error: glVDPAUMapSurfacesNV failed: 0x502

[00007f0744006450] glconv_vdpau gl error: glVDPAUMapSurfacesNV failed: 0x502

[00007f0744006450] glconv_vdpau gl error: glVDPAUMapSurfacesNV failed: 0x502

where the latter spams the log constantly hereafter:

[00007f0744006450] glconv_vdpau gl error: glVDPAUMapSurfacesNV failed: 0x502

So this fills the screen in seconds.

Created attachment 849656 [details]
cli output with  r600-21.1.1-278.1.x86_64.rpm  after latest update

Not complete as the function:
kaffeine -d > outputfile.txt 
appears to be broken and creates only empty files. 

So it is difficult to capture the output these times. :-( 

Currently the HD channels are still all not visible (all black).

Works after a complete reinstall


(To be honest, the last 4 or 5 weeks of update slowly destroyed the system one by one). Strange DNS problems, Mesa not working etc. 
I did put the DNS problems closed as invalid, and will do so for this bug. But both were IMO very absolutely valid, unfortunately, I will not find out any more what was broken.

OK, not 10 minutes after closing the bug it begins again. 

What I did see: I appears that (could be coincidence) the problem started when using the plugin yapstocks with qt-charts plugin. 
When doing some changes there, afterwards the HD channels became first troubled, then "green" and now practically unusable.

OK, there was the last update with all the kernel firmware files and now, at for now, it seems the issue is fixed. 

I allow myself testing for several days to be sure this time. 

This is just to let you know.

I am gonna be bold! Hence (in reminiscence of a former German - quite funny - politician) "I declare this incident as closed".

To tell the truth, it appears that, if you have Kaffeine running for long and changing fast between HD channels, it may appear a disturbance and a flicker, but this seems to be a problem of Kaffeine as vlc works fine and shutting down Kaffeine an restarting it, within the very same session of plasma, resolves the issue instantly. 

So this may be a separate problem. In case it should become an annoyance, I will raise a different bug. But I really hope that the mesa/firware/kernel related part is fixed now. 

So closing it .... boldly going. Thank your for fixing.

Another day, another regression.

With the current Mesa updates in Tumbleweed:
HD channels are all broken again. 

VLC cannot play any video if not via the manual codec selection "va-api via DRM".

Hmm. Not so much changes lately.

-------------------------------------------------------------------
Tue Jun 22 09:22:30 UTC 2021 - Stefan Dirsch <sndirsch@suse.com>

- no longer apply n_drirc-disable-rgb10-for-chromium-on-amd.patch
  on TW; no longer needed with gstreamer-plugins-vaapi 1.18.4; more
  details on 
  https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/410

-------------------------------------------------------------------
Sat Jun 19 08:02:37 UTC 2021 - Stefan Dirsch <sndirsch@suse.com>

- update to 21.1.3
  * third bugfix
  * mostly AMD fixes

-------------------------------------------------------------------
Thu Jun  3 03:11:44 UTC 2021 - Stefan Dirsch <sndirsch@suse.com>

- update to 21.1.2
  * second bugfix
  * mostly AMD and Intel changes as usual, but also a decent amount
    of ARM fixes and more.

Meanwhile we have Mesa 21.2.4 on TW. Do you want to give it another try?

(In reply to Stefan Dirsch from comment #26)
> Meanwhile we have Mesa 21.2.4 on TW. Do you want to give it another try?

rpm --version mesa
RPM versione 4.16.1.3

which is the version applied by TW repos. 

This gives an immediate crash (seems segfault) with the output as of attachment. 
The issue with the newest version persists and the crash persists too. 
HD channels play well. SD channel crash the program.

Created attachment 853324 [details]
segfault with SD channels with the latest mesa (rpm 4.16.1.3 from TW repo)

This is the version of the rpm command. You could check the Mesa version with "rpm -q Mesa", but with current update to TW you should have the latest Mesa version available. Thanks for testing again!

(In reply to Stefan Dirsch from comment #29)
> This is the version of the rpm command. You could check the Mesa version
> with "rpm -q Mesa", but with current update to TW you should have the latest
> Mesa version available. Thanks for testing again!

***blush***

sorryyyyyy.

rpm -q Mesa
Mesa-21.1.6-8.21.x86_64

Here we go ;-)

Hmm. That's meanwhile rather old.

Thu Jul 29 08:28:31 UTC 2021 - Stefan Dirsch <sndirsch@suse.com>

- update to 21.1.6
  * sixth bugfix release

Meanwhile we have newer Mesa in Tumbleweed 20211019

-------------------------------------------------------------------
Fri Oct 15 09:14:11 UTC 2021 - Stefan Dirsch <sndirsch@suse.com>

- update to 21.2.4
  * fourth bugfix release
  * 300 fixes from the new r300 maintainer! Additionally, panfrost,
    lots of crocus, some freedreno, intel, radv, core meas, gallivum,
    anv, spirv, gallim, aco, i915g, lima, and llvmpipe fixes.
- supersedes U_gallivm-add-new-wrapper-around-Module.patch,
  U_gallivm-fix-FTBFS-on-i386-with-LLVM-13.patch

(In reply to Stefan Dirsch from comment #31)
> Hmm. That's meanwhile rather old.
> 
> Thu Jul 29 08:28:31 UTC 2021 - Stefan Dirsch <sndirsch@suse.com>
> 
> - update to 21.1.6
>   * sixth bugfix release
> 
> Meanwhile we have newer Mesa in Tumbleweed 20211019
> 
> -------------------------------------------------------------------
> Fri Oct 15 09:14:11 UTC 2021 - Stefan Dirsch <sndirsch@suse.com>
> 
> - update to 21.2.4
>   * fourth bugfix release
>   * 300 fixes from the new r300 maintainer! Additionally, panfrost,
>     lots of crocus, some freedreno, intel, radv, core meas, gallivum,
>     anv, spirv, gallim, aco, i915g, lima, and llvmpipe fixes.
> - supersedes U_gallivm-add-new-wrapper-around-Module.patch,
>   U_gallivm-fix-FTBFS-on-i386-with-LLVM-13.patch

right, my fault. The 21.1.6 was already after dropping back to Wolfi's repo. It is the last known to work. The crash given was 21.2.4-292.1.x86_64.rpm

Sorry, I am actually now used after every test to switch back to Wolfi's in order to have TV function.

rpm -q Mesa
Mesa-21.2.4-292.1.x86_64

And confirmed it segfaults with SD channels. 
That said, the rpm -q Mesa
Mesa-21.1.6-8.21.x86_64
as for the bug 1189735 concerning segfault, this one is hit by another dysfunction and hits e.g. also vidcutter (only showing green blurred images in the preview). 

So video output is haunted by flicker, blockpixelview, inefficient or impossible video editing since quite some time. The issue handled with 1189735 is just the try to restore normal operation with the hauppauge hardware for what is simultaneous function of SD and HD channels with a quite common diseq as it was since years. 

This one as opposed, we are talking about, I doubt it will be helped by it. 
Naturally, if the fixes would have had effect, I could not see it, because Kaffeine is segfaulting too fast (and without debugger output since the very beginning). So, the very use of SD channels crashes all already. No way to tell you if this bug is in any way helped by the changes. May be, may not be. I would concentrate on the segfault so that then we can go on with this one (if it turns out to be still necessary of course).

Ok. No problem! Thanks for you feedback!

So I wanted to know if this is solvable (together with the other mesa bug) when I change to a modern graphics card to a NAVI based brand new AMD card using Vulcan. 
And yes, this finally works. 
I have now the current mesa drivers installed and using. 

The artifacts that were haunting the R600 are gone. So this is a compatibility issue with Radeon drivers and R600. 

For what is VLC you need to set the following hardware acceleration with the current cards (otherwise video will not be crisp but somewhat big grained) 

Decode with VA-API with DRM. 

Auto and others do not crash but give inferior results. 

The current card is AMD Radeon Pro WX3200.