https://bugs.kde.org/show_bug.cgi?id=527680

            Bug ID: 527680
           Summary: Crash in av_write_trailer() when stopping a recording
                    after avformat_write_header() failed (e.g. H.264 into
                    WebM)
    Classification: Frameworks and Libraries
           Product: KPipeWire
      Version First 6.7.5
       Reported In:
          Platform: Gentoo Packages
                OS: Linux
            Status: REPORTED
          Severity: crash
          Priority: NOR
         Component: general
          Assignee: [email protected]
          Reporter: [email protected]
                CC: [email protected]
  Target Milestone: ---

SUMMARY
If the recorder fails to write the container header when a recording starts,
KPipeWire logs the error but keeps the recording "running". When the user then
stops the recording, KPipeWire calls av_write_trailer() on that format context
and the app segfaults in libavformat.

FFmpeg's API only allows av_write_trailer() after a successful
avformat_write_header(), so the stop path should skip finalizing (and report an
error) when setup failed. Seen through Spectacle, but the crash is inside
libKPipeWireRecord on the PipeWireProduce thread.

How the header failure happened here: FFmpeg was built without libvpx and
without VAAPI, so the WebM/VP9 profile had no VP9 encoder. KPipeWire fell back
to libx264 but still used the WebM muxer, which rejects H.264. That mismatch is
a second, smaller issue: KPipeWire should either refuse to start, or pick a
container that matches the encoder it actually got.

STEPS TO REPRODUCE
1. Use an FFmpeg build without libvpx-vp9 and without vp9_vaapi (e.g. Gentoo
media-video/ffmpeg with USE="-vpx -vaapi").
2. In Spectacle, set the video format to WebM and start a screen recording.
3. Stop the recording.

OBSERVED RESULT
Starting the recording logs:

  [AVFilterGraph] No such filter: 'scale_vaapi'
  kpipewire_record_logging: Failed creating filter graph
  [libx264] profile Main, level 6.2, 4:2:0, 8-bit
  [webm] Only VP8 or VP9 or AV1 video and Vorbis or Opus audio and WebVTT
subtitles are supported for WebM.
  kpipewire_record_logging: Error occurred when writing header: Invalid
argument
  kpipewire_record_logging: Could not set up the producing thread

The UI still shows the recording as running. Stopping it crashes the app
(SIGSEGV), 100% of the time (2 of 2 attempts):

  Thread "PipeWireProduce" (crashing):
  #3  
  #4  ??? () at /usr/lib64/libavformat.so.62
  #5  ??? () at /usr/lib64/libavformat.so.62
  #6  av_write_trailer () at /usr/lib64/libavformat.so.62
  #7  ??? () at /usr/lib64/libKPipeWireRecord.so.6
  #8  ??? () at /usr/lib64/libKPipeWireRecord.so.6
  #9  QObject::event(QEvent*) () at /usr/lib64/libQt6Core.so.6
  #10 QApplicationPrivate::notify_helper(QObject*, QEvent*) () at
/usr/lib64/libQt6Widgets.so.6
  #11 QCoreApplication::notifyInternal2(QObject*, QEvent*) () at
/usr/lib64/libQt6Core.so.6
  #12 QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) ()
at /usr/lib64/libQt6Core.so.6
  ...
  #18 QEventLoop::exec(...) () at /usr/lib64/libQt6Core.so.6
  #19 QThread::exec() () at /usr/lib64/libQt6Core.so.6

(No debug symbols installed for kpipewire; both crashes have the same stack.)

EXPECTED RESULT
- If avformat_write_header() fails, the recording is aborted and the app gets
an error it can show, instead of a recording that looks active.
- Stopping a recording that never started properly does not call
av_write_trailer() and does not crash.
- Ideally the WebM profile does not silently fall back to an encoder the WebM
muxer cannot accept.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Gentoo Linux, kernel 6.18.57-gentoo-dist-bin
KDE Plasma Version: 6.7.5 (Wayland session)
KDE Frameworks Version: 6.29.0
Qt Version: 6.11.2
KPipeWire: 6.7.5, Spectacle: 6.7.5
FFmpeg 8.1.3 (built without vpx and vaapi at the time of the crash), PipeWire
1.6.8

ADDITIONAL INFORMATION
Hardware: Intel TigerLake-LP GT2 (Iris Xe), Mesa 26.1.8, intel-media-driver
26.2.4.
Rebuilding FFmpeg with vpx and vaapi makes WebM recording work and the crash no
longer happens, which fits the header failure being the trigger.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to