Bug 491496 - The last few seconds of screencasts are cut off/removed
Summary: The last few seconds of screencasts are cut off/removed
Status: RESOLVED DUPLICATE of bug 471159
Alias: None
Product: Spectacle
Classification: Applications
Component: General (show other bugs)
Version: 24.05.2
Platform: Fedora RPMs Linux
: VHI grave
Target Milestone: ---
Assignee: Noah Davis
URL: https://discuss.kde.org/t/spectacle-c...
Keywords:
Depends on:
Blocks:
 
Reported: 2024-08-09 17:40 UTC by Roke Julian Lockhart Beedell
Modified: 2024-08-13 19:37 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
The truncated screencast from Spectacle. (1.24 MB, video/webm)
2024-08-09 17:49 UTC, Roke Julian Lockhart Beedell
Details
The untruncated screencast from OBS. (2.50 MB, video/mp4)
2024-08-09 17:51 UTC, Roke Julian Lockhart Beedell
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roke Julian Lockhart Beedell 2024-08-09 17:40:29 UTC
SUMMARY
Spectacle removes the last few seconds of screencasts.

STEPS TO REPRODUCE
Record a screencast.

OBSERVED RESULT
The longer the video, (seemingly) the more it redacts of the end.

EXPECTED RESULT
It shouldn't redact the end of the screencast.

SOFTWARE/OS VERSIONS
Operating System: Fedora Linux 40
KDE Plasma Version: 6.1.3
KDE Frameworks Version: 6.4.0
Qt Version: 6.7.2
Kernel Version: 6.10.3-200.fc40.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 7600X 6-Core Processor
Memory: 30.5 GiB of RAM
Graphics Processor: AMD Radeon RX 5700
Manufacturer: ASRock
Product Name: X670E Taichi

ADDITIONAL INFORMATION
Originally reported at https://discuss.kde.org/t/spectacle-cuts-off-last-few-seconds-of-video-recordings/1694/2?u=rokejulianlockhart. To my knowledge, this is a regression.
Comment 1 Roke Julian Lockhart Beedell 2024-08-09 17:49:51 UTC
Created attachment 172450 [details]
The truncated screencast from Spectacle.

Compare this to the video from OBS (to be attached).
Comment 2 Roke Julian Lockhart Beedell 2024-08-09 17:51:15 UTC
Created attachment 172451 [details]
The untruncated screencast from OBS.

This is approximately 7 seconds longer.
Comment 3 xezo360hye@gmail.com 2024-08-09 20:23:20 UTC
Can confirm, here are the logs a few comments just in case. I use Intel iGPU + AMD dGPU if it matters

$ spectacle -Rs
libva info: VA-API version 1.22.0
libva info: Trying to open /run/opengl-driver/lib/dri/iHD_drv_video.so
libva info: Trying to open /usr/lib/dri/iHD_drv_video.so
libva info: Trying to open /usr/lib32/dri/iHD_drv_video.so
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Trying to open /usr/lib/i386-linux-gnu/dri/iHD_drv_video.so
libva info: va_openDriver() returns -1
libva info: Trying to open /run/opengl-driver/lib/dri/i965_drv_video.so
libva info: Trying to open /usr/lib/dri/i965_drv_video.so
libva info: Trying to open /usr/lib32/dri/i965_drv_video.so
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Trying to open /usr/lib/i386-linux-gnu/dri/i965_drv_video.so
libva info: va_openDriver() returns -1
kpipewire_vaapi_logging: VAAPI: Failed to initialize display
libva info: VA-API version 1.22.0
libva info: Trying to open /run/opengl-driver/lib/dri/r600_drv_video.so
libva info: Found init function __vaDriverInit_1_22
libva info: va_openDriver() returns 0
kpipewire_vaapi_logging: VAAPI: Mesa Gallium driver 24.1.4 for AMD CAICOS (DRM 2.50.0 / 6.6.44, LLVM 18.1.8) in use for device "/dev/dri/renderD129"
kpipewire_vaapi_logging: DRM device not found
[libvpx-vp9 @ 0x7fc63022fec0] v1.14.1
kpipewire_dmabuf_logging: eglChooseConfig returned this many configs: 1

// Begins after some time of recording, typically at ~2 seconds.
// After the first such message there are no more frames in resulting video.

kpipewire_record_logging: Filter queue is full, dropping frame 5692
kpipewire_record_logging: Filter queue is full, dropping frame 5719
kpipewire_record_logging: Filter queue is full, dropping frame 5732
kpipewire_record_logging: Filter queue is full, dropping frame 5745
kpipewire_record_logging: Filter queue is full, dropping frame 5772

// And so on, until I stop the recording, there it pauses for a few seconds

qt.multimedia.ffmpeg.mediadataholder: AVStream duration -9223372036854775808 is invalid. Taking it from the metadata
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory
qt.qml.context: qrc:/qt/qml/org/kde/spectacle/private/Gui/InlineMessage.qml:20:5 Parameter "link" is not declared. Injection of parameters into signal handlers is deprecated. Use JavaScript functions with formal parameters instead.

// EOF
Comment 4 Nate Graham 2024-08-09 20:31:34 UTC
Can reproduce! Eek.
Comment 5 Roke Julian Lockhart Beedell 2024-08-09 20:37:54 UTC
(In reply to Nate Graham from comment #4)
Sorry for not reporting this for over a year... I could have helped you to fix this earlier.
Comment 6 Lê Hoàng Phương 2024-08-12 12:02:45 UTC
This bug report probably should be collapsed to below older bug report more than 1 year ago.

https://bugs.kde.org/show_bug.cgi?id=471159
Comment 7 Roke Julian Lockhart Beedell 2024-08-12 12:20:20 UTC
(In reply to Lê Hoàng Phương from comment #6)
Is this a duplicate of it?
Comment 8 xezo360hye@gmail.com 2024-08-12 12:43:54 UTC
(In reply to Roke Julian Lockhart Beedell from comment #7)
> Is this a duplicate of it?

Idk probably yes, however I don’t experience that huge delay between clicking “stop” and actual end of recording. It’s always approximately 2-3 seconds, definitely not “5-10 or not at all” as in the linked bug report. Maybe the source of problem is the same, I don’t see any logs there so who knows
Comment 9 Roke Julian Lockhart Beedell 2024-08-12 12:45:49 UTC
(In reply to xezo360hye@gmail.com from comment #8)
I agree. I've added it to the "See also" field until we can ascertain whether a common cause exists for both, then whether (consequently) they're duplicates, or different problems caused by that common problem.
Comment 10 Nate Graham 2024-08-13 19:37:54 UTC
Good catch, it does seem to be a duplicate. The exact amount of time doesn't really matter; what does matter is that the recording doesn't stop immediately, and the last few seconds get cut off.

*** This bug has been marked as a duplicate of bug 471159 ***