Bug 485733

I have encountered the same bug(s), it might be related to graphics hardware (I use a notebook with AMD APU (Ryzen 5500U)).

And in the console output I see this message:

> *** pw_stream_destroy called from wrong context, check thread and locking: Not in loop
> *** impl_ext_end_proxy called from wrong context, check thread and locking: Not in loop
> 'pthread_equal(impl->thread, thread_id)' failed at ../spa/plugins/support/loop.c:363 loop_leave()

bump

Are you using X11? Spectacle does not currently support recording on X11. I once saw that error when trying to record on X11 (I was testing things).

.

(In reply to Noah Davis from comment #3)
> Are you using X11? Spectacle does not currently support recording on X11. I
> once saw that error when trying to record on X11 (I was testing things).

No, happens when using Wayland. This is a follow up on 484620 after the segfault was fixed.

What are your settings for recording? Where are you saving your recording to? Is your /tmp folder a local folder?

(In reply to Noah Davis from comment #6)
> What are your settings for recording?

All default.
Filename is the default: Screencast_<yyyy><MM><dd>_<hh><mm><ss>
Format the only available one: WebM/VP9

But I also tried using different saving places, no difference.

> Where are you saving your recording to?

Default location: /home/XXX/Videos/Screencasts

> Is your /tmp folder a local folder?

No /tmp is a tmpfs

---

My guess is that kpipewire has a bug on amd gpu, because of this console output:

> kpipewire_record_logging: VAAPI: Display initialized
> kpipewire_record_logging: VAAPI: API version 1 . 21
> kpipewire_record_logging: VAAPI: Mesa Gallium driver 24.0.5 for AMD Radeon Graphics (radeonsi, renoir, LLVM 18.1.4, DRM 3.57, 6.8.7-1-default) in use for device "/dev/dri/renderD128"
> *** pw_stream_destroy called from wrong context, check thread and locking: Not in loop
> *** impl_ext_end_proxy called from wrong context, check thread and locking: Not in loop
> 'pthread_equal(impl->thread, thread_id)' failed at ../spa/plugins/support/loop.c:363 loop_leave()

sorry for the late response, all default here too, and amd gpu here too.

I'm having the same erro on a intel GPU and on a NVIDIA GPU, I guess its unrelated to the manufacturer.


❯ spectacle
kpipewire_vaapi_logging: VAAPI: Intel iHD driver for Intel(R) Gen Graphics - 24.2.3 () in use for device "/dev/dri/renderD128"
*** pw_stream_destroy called from wrong context, check thread and locking: Not in loop
*** impl_ext_end_proxy called from wrong context, check thread and locking: Not in loop

Spectacle video recording worked fine on NVIDIA 535 Wayland until I upgraded to 555

Ferdinand, your issue may be separate from the original issue. Do you think you had pipewire 1.2 at the time that you started having this bug? If so, https://bugs.kde.org/show_bug.cgi?id=489434 might be your bug.

The reason I asked if /tmp was a local file is because recording currently only works with local files (i.e., on your storage device), although you should be able to save a recording to a network storage device after recording has finished. One of the ways the message from the original post is sent is when the file is not a local file.

(In reply to bruno from comment #8)
> sorry for the late response, all default here too, and amd gpu here too.

So you are still getting the "Failed to export video: Temporary file URL must be an existing local file" message? If you are getting the following message, you are experiencing bug 489434 instead.

> *** pw_stream_destroy called from wrong context, check thread and locking: Not in loop
> *** impl_ext_end_proxy called from wrong context, check thread and locking: Not in loop

Changing back to REPORTED since I was never able to reproduce the original issue with the original error message.

(In reply to Noah Davis from comment #14)
> Changing back to REPORTED since I was never able to reproduce the original
> issue with the original error message.

For me it was fixed for a couple of weeks now, and in general the reported issue is gone.
(But now after weeks of working versions I updated to latest version and when saving the recoding spectle now freezes for ever, so broken again but a different issue. Will try to collect information and open another ticket).

I can confirm this bug occurs with the current versions.

Operating System: KDE neon 6.0
KDE Plasma Version: 6.1.3
KDE Frameworks Version: 6.4.0
Qt Version: 6.7.2
Kernel Version: 6.5.0-44-generic (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 5700X 8-Core Processor
Memory: 31.3 GiB of RAM
Graphics Processor: AMD Radeon RX 580 Series
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: B450 AORUS PRO
Spectacle version: 24.02.2

/tmp is tmpfs

For me, this problem is remaining persistent for only one specific case that requires:

- mp4 output set as output,  
- "Window" selected as recording mode,
- the selected window is not maximized,

It doesn't happen with all apps, for example Konsole and Firefox are affected.


Pipewire: 1.2.2
Operating System: Manjaro Linux 
KDE Plasma Version: 6.1.4
KDE Frameworks Version: 6.4.0
Qt Version: 6.7.2
Kernel Version: 6.10.3-5-MANJARO (64-bit)
Graphics Platform: Wayland

*** Bug 488895 has been marked as a duplicate of this bug. ***

Unfortunately, I still cannot reproduce the issue. I tried to record an unmaximized Konsole window. I'm on PipeWire 1.2.2, git master Plasma (basically 6.2 alpha) and KDE Frameworks 6.6.0, but there shouldn't be much of a difference between the behavior on our systems. Maybe there's some other setting or condition that I don't know about.

I can reproduce this with 100% reliability like so:

1. Have a 4K screen and scale it to 225% (total number of screens does not matter for this)
2. Have Spectacle and configured to record in MP4/H.264 by default
3. Press Meta+R to start a screen recording
4. Drag a box around the entire screen area and press return to start recording
5. After any length of time (even like one second) click the red dot in the system tray to end recording

This is with an Intel 10th gen HD630 iGPU.

Created attachment 172994 [details]
Spectacle fails to record a specific non maximized window in mp4 format

In terminal, when I unmaximize Konsole and start recording it in "Window" mode, I get the following errors:


kpipewire_record_logging: Hardware encoding is not supported on this device.
[libx264 @ 0x7d73141079c0] -qscale is ignored, -crf is recommended.
[libx264 @ 0x7d73141079c0] height not divisible by 2 (680x511)
kpipewire_record_logging: Could not open codec Generic error in an external library
kpipewire_record_logging: libopenh264 codec not found
kpipewire_record_logging: No encoder could be created
Failed to export video: Temporary file URL must be an existing local file


If I maximize Konsole window, and start recording again, the above errors disappear.


Operating System: Manjaro Linux 
KDE Plasma Version: 6.1.4
KDE Frameworks Version: 6.5.0
Qt Version: 6.7.2
Kernel Version: 6.10.6-10-MANJARO (64-bit)
Graphics Platform: Wayland

To anyone who is still able to reproduce the bug, do you have OpenH264 installed? If you don't, does installing OpenH264 make the problem go away? I found out that KPipeWire tries to use OpenH264 before x264 and unlike x264, OpenH264 supports odd sized recordings.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kpipewire/-/merge_requests/175

changing status

(In reply to Noah Davis from comment #22)
> To anyone who is still able to reproduce the bug, do you have OpenH264
> installed? If you don't, does installing OpenH264 make the problem go away?
> I found out that KPipeWire tries to use OpenH264 before x264 and unlike
> x264, OpenH264 supports odd sized recordings.

I just installed OpenH264 to test it and nope, it doesn't make the problem go away.

(In reply to smow from comment #25)
> (In reply to Noah Davis from comment #22)
> > To anyone who is still able to reproduce the bug, do you have OpenH264
> > installed? If you don't, does installing OpenH264 make the problem go away?
> > I found out that KPipeWire tries to use OpenH264 before x264 and unlike
> > x264, OpenH264 supports odd sized recordings.
> 
> I just installed OpenH264 to test it and nope, it doesn't make the problem
> go away.

Actually, it only works on selection recordings like 1080x720, 1280x720, 550x550. Trying to record something like a 227x247 or 459x369 selection, will always fail.

Are you sure you're actually using OpenH264? Compare recording with these two commands:

KPIPEWIRE_FORCE_ENCODER=libx264 spectacle -i

KPIPEWIRE_FORCE_ENCODER=libopenh264 spectacle -i

`spectacle -i` opens a new instance in gui mode, so you will have to go to the recording tab to start recording.

(In reply to Noah Davis from comment #27)
> Are you sure you're actually using OpenH264? Compare recording with these
> two commands:
> 
> KPIPEWIRE_FORCE_ENCODER=libx264 spectacle -i
> 
> KPIPEWIRE_FORCE_ENCODER=libopenh264 spectacle -i
> 
> `spectacle -i` opens a new instance in gui mode, so you will have to go to
> the recording tab to start recording.

Now that's strange.. I'm getting
> kpipewire_record_logging: Forcing encoder to "libopenh264"
> kpipewire_record_logging: libopenh264 codec not found
> kpipewire_record_logging: No encoder could be created
after issuing the second command, even though I have https://archlinux.org/packages/extra/x86_64/openh264/ installed, which provides libopenh264.

(In reply to smow from comment #28)
> Now that's strange.. I'm getting
> > kpipewire_record_logging: Forcing encoder to "libopenh264"
> > kpipewire_record_logging: libopenh264 codec not found
> > kpipewire_record_logging: No encoder could be created
> after issuing the second command, even though I have
> https://archlinux.org/packages/extra/x86_64/openh264/ installed, which
> provides libopenh264.

I did a bit of research and apparently you need to use https://aur.archlinux.org/packages/ffmpeg-full from the AUR if you are on Arch Linux. I'm surprised you have to use the AUR package to encode with OpenH264 using FFmpeg. KPipeWire uses FFmpeg internally.

(In reply to Noah Davis from comment #29)
> (In reply to smow from comment #28)
> > Now that's strange.. I'm getting
> > > kpipewire_record_logging: Forcing encoder to "libopenh264"
> > > kpipewire_record_logging: libopenh264 codec not found
> > > kpipewire_record_logging: No encoder could be created
> > after issuing the second command, even though I have
> > https://archlinux.org/packages/extra/x86_64/openh264/ installed, which
> > provides libopenh264.
> 
> I did a bit of research and apparently you need to use
> https://aur.archlinux.org/packages/ffmpeg-full from the AUR if you are on
> Arch Linux. I'm surprised you have to use the AUR package to encode with
> OpenH264 using FFmpeg. KPipeWire uses FFmpeg internally.

I'm pretty surprised about it too, though, yep, installing ffmpeg-full (from chaotic-aur, since compiling it all would take too much time) seems to resolve the issue of not picking OpenH264, and I suppose, this whole bug. Many thanks for that research.

Git commit e8a3160d02399592a219d688d81a0ec61764f772 by Arjen Hiemstra.
Committed on 23/10/2024 at 13:19.
Pushed by ahiemstra into branch 'master'.

libx264encoder: Ensure stream size is always a multiple of 2

libx264 apparently rejects any stream that is not a multiple of 2. So
ensure we adjust the stream size to that. This also inserts a pad filter
to ensure we pad with black rather than garbage.

M  +12   -2    src/libx264encoder.cpp

https://invent.kde.org/plasma/kpipewire/-/commit/e8a3160d02399592a219d688d81a0ec61764f772

Git commit 54a5077ba4eb48ef8d7df865c7a974e9fb59f71f by Arjen Hiemstra.
Committed on 23/10/2024 at 13:31.
Pushed by ahiemstra into branch 'Plasma/6.2'.

libx264encoder: Ensure stream size is always a multiple of 2

libx264 apparently rejects any stream that is not a multiple of 2. So
ensure we adjust the stream size to that. This also inserts a pad filter
to ensure we pad with black rather than garbage.


(cherry picked from commit e8a3160d02399592a219d688d81a0ec61764f772)

Co-authored-by: Arjen Hiemstra <ahiemstra@heimr.nl>

M  +12   -2    src/libx264encoder.cpp

https://invent.kde.org/plasma/kpipewire/-/commit/54a5077ba4eb48ef8d7df865c7a974e9fb59f71f

*** Bug 482738 has been marked as a duplicate of this bug. ***

*** Bug 475472 has been marked as a duplicate of this bug. ***

I (and a user of Alpine Linux downstream) can reproduce this error on Plasma 6.2.4, so I don't believe this issue is fixed.

Issue persists even with webm.

I'm also getting -- 
qt.qml.list.incompatible: Cannot append QQuickRepeater(0x562eacd4cdf0) to a QML list of QQuickAbstractButton*
qt.qml.list.incompatible: Cannot append QQuickRepeater(0x562eacd4cdf0) to a QML list of QQuickAbstractButton*
qt.qml.list.incompatible: Cannot append QQuickRepeater(0x562eacd4cdf0) to a QML list of QQuickAbstractButton*

But I don't think that's a deal breaker.

FWIW, I'm not able to reproduce the issue with nay video formats in Spectacle from git master with Plasma from git master.

*** Bug 487542 has been marked as a duplicate of this bug. ***

*** Bug 478184 has been marked as a duplicate of this bug. ***

unclear to me how this was resolved.. I see a patch for Plasma 6.2, I run 6.3.5 on Fedora 42 Wayland mode...

```
bash$ spectacle -v
spectacle 6.3.5
QThreadStorage: Thread 0x55fd721fe9e0 exited after QThreadStorage 9 destroyed
QThreadStorage: Thread 0x55fd721fe9e0 exited after QThreadStorage 5 destroyed
QThreadStorage: Thread 0x55fd721fe9e0 exited after QThreadStorage 4 destroyed
bash$ plasmashell -v
plasmashell 6.3.5
bash$
```

I tried switching my TMPDIR but still does not work...

```
bash$ TMPDIR=~/.tmp/ spectacle 
QThreadStorage: Thread 0x560552b339e0 exited after QThreadStorage 9 destroyed
QThreadStorage: Thread 0x560552b339e0 exited after QThreadStorage 5 destroyed
QThreadStorage: Thread 0x560552b339e0 exited after QThreadStorage 4 destroyed
bash$ df /tmp ~/.tmp
Filesystem     1K-blocks      Used Available Use% Mounted on
tmpfs           16243368     43504  16199864   1% /tmp
/dev/nvme0n1p9 435004416 133458248 284013832  32% /home
bash$

I still somestimes see this message on

Operating System: Fedora Linux 42
KDE Plasma Version: 6.4.4
KDE Gear: 25.08.0
KDE Frameworks Version: 6.17.0
Qt Version: 6.9.1
Kernel Version: 6.15.10-200.fc42.x86_64 (64-bit)
Graphics Platform: Wayland

Shall we re-open or shall I open a new ticket?

The just linked report #507486 is just about the error message - so again: Re-open or a new ticket?

If it's back for you, it's like an issue with a different root cause, so I'd recommend opening a new bug report for it. Thanks!