Description: Working with QT only (qt6/kf6). When you drag an audio file (wav) from the gallery, LibreOffice crashes. It reproduces with any media, audio or video, when launched with SAL_VCL_QT_USE_QT_FRAME_GRABBER. Problem feels same as #166055 Steps to Reproduce: Reproduces when building with Qt6/KF6, for example in KDE. For reproduction, simply drag a .wav file with the mouse into Impress. For reproduction with other file types, you need to: 1.Launch with SAL_VCL_QT_USE_QT_FRAME_GRABBER 2.Drag any media file into the Impress window Actual Results: Program crash Expected Results: The Impress window contains the inserted file. Reproducible: Always User Profile Reset: No Additional Info: Version: 26.8.0.0.alpha0+ (x86_64)
I'm already have some solution for this (it's frame grabbing problem, as I can see), so I'll assign it to myself.
(In reply to nuke from comment #0) > When you drag an audio file (wav) from the gallery, LibreOffice crashes. Can you please describe the exact steps to get an audio or video file into the gallery first? (I couldn't manage to in a quick test, got the message that they are not valid image files). > It reproduces with any media, audio or video, when launched with > SAL_VCL_QT_USE_QT_FRAME_GRABBER. > Problem feels same as #166055 This being the same underlying issue as tdf#166055 sounds likely, since it happens when explicitly enabling the off-by-default QtFrameGrabber that was disabled by default to avoid the issue described in tdf#166055 for now. Out of interest: Do you have any particular reason for setting SAL_VCL_QT_USE_QT_FRAME_GRABBER ? (In reply to nuke from comment #1) > I'm already have some solution for this (it's frame grabbing problem, as I > can see), so I'll assign it to myself. Thanks! For reference: https://gerrit.libreoffice.org/c/core/+/199083 I'll comment there, too.
Created attachment 205480 [details] Impress window
(In reply to Michael Weghorn from comment #2) > (In reply to nuke from comment #0) > > When you drag an audio file (wav) from the gallery, LibreOffice crashes. > > Can you please describe the exact steps to get an audio or video file into > the gallery first? (I couldn't manage to in a quick test, got the message > that they are not valid image files). > > > It reproduces with any media, audio or video, when launched with > > SAL_VCL_QT_USE_QT_FRAME_GRABBER. > > Problem feels same as #166055 > > This being the same underlying issue as tdf#166055 sounds likely, since it > happens when explicitly enabling the off-by-default QtFrameGrabber that was > disabled by default to avoid the issue described in tdf#166055 for now. > > Out of interest: Do you have any particular reason for setting > SAL_VCL_QT_USE_QT_FRAME_GRABBER ? > > > (In reply to nuke from comment #1) > > I'm already have some solution for this (it's frame grabbing problem, as I > > can see), so I'll assign it to myself. > > Thanks! > For reference: https://gerrit.libreoffice.org/c/core/+/199083 > > I'll comment there, too. Probably I didn't express myself correctly: you just need to drag and drop audio files from the sidebar, and that's it—the program crashes. (I added an attachment to the bug) Regarding adding SAL_VCL_QT_USE_QT_FRAME_GRABBER—I found this flag during debugging :) I didn't understand why, for example, a WAV file from the sidebar causes a crash, but an AVI file from my personal directory does not. So I enabled it solely for more thorough debugging, to not miss anything.
(In reply to nuke from comment #4) > Probably I didn't express myself correctly: you just need to drag and drop > audio files from the sidebar, and that's it—the program crashes. (I added an > attachment to the bug) Thanks! Your explanation was fine. I'm just not familiar with the gallery and didn't notice there a "Sounds" category that already contains audio files (and then had trouble trying to insert custom audio files into the gallery instead). Right now, I cannot reproduce the crash in my local development build of git master, regardless of whether or not I set SAL_VCL_QT_USE_QT_FRAME_GRABBER=1 . Version: 26.8.0.0.alpha0+ (X86_64) Build ID: 04121e1740ee41b4689e1854f146c250c1d6074b CPU threads: 32; OS: Linux 6.18; UI render: default; VCL: qt6 (cairo+wayland) Locale: en-US (en_GB.UTF-8); UI: en-US Calc: threaded But interestingly, I can reproduce the crash e.g. in the last version available in the linux-64-26.8 bibisect repo or the Debian-provided 26.2.0 Version: 26.8.0.0.alpha0+ (X86_64) Build ID: 540d53505863665c43f1d4960c33bf960c543cdc CPU threads: 32; OS: Linux 6.18; UI render: default; VCL: qt6 (cairo+wayland) Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: CL threaded Version: 26.2.0.3 (X86_64) Build ID: 620(Build:3) CPU threads: 32; OS: Linux 6.18; UI render: default; VCL: qt6 (cairo+wayland) Locale: en-GB (en_GB.UTF-8); UI: en-GB Debian package version: 4:26.2.0-1 Calc: threaded For these, the crash even appears without explicitly setting SAL_VCL_QT_USE_QT_FRAME_GRABBER and the backtrace suggests that the QtFrameGrabber path is presumably taken anyway, which seems odd after commit 08533ca4e2526644b803c40c0c3d3c96f43762af Author: Michael Weghorn Date: Fri May 2 17:52:19 2025 +0200 tdf#166055 avmedia qt: Use GStreamer frame grabber by default > Regarding adding SAL_VCL_QT_USE_QT_FRAME_GRABBER—I found this flag during > debugging :) > > I didn't understand why, for example, a WAV file from the sidebar causes a > crash, but an AVI file from my personal directory does not. So I enabled it > solely for more thorough debugging, to not miss anything. Does that mean you also ran into the same crash even before setting the environment variable?
(In reply to Michael Weghorn from comment #5) > Does that mean you also ran into the same crash even before setting the > environment variable? OK, debugging into QtPlayer::createFrameGrabber, I see that `createPlatformFrameGrabber` also returns an empty reference in my case, because aPrefSize has 0 width and height in Player::createFrameGrabber: uno::Reference< media::XFrameGrabber > SAL_CALL Player::createFrameGrabber() { ::osl::MutexGuard aGuard(m_aMutex); rtl::Reference<FrameGrabber> pFrameGrabber; const awt::Size aPrefSize( getPreferredPlayerWindowSize() ); if( ( aPrefSize.Width > 0 ) && ( aPrefSize.Height > 0 ) ) pFrameGrabber = FrameGrabber::create( maURL ); SAL_INFO( "avmedia.gstreamer", AVVERSION "created FrameGrabber " << pFrameGrabber.get() ); return pFrameGrabber; } Since audio-only files don't have any video/images to show, a 0 size seems to make sense in general. But then, that seems to be the reason why the known problematic QtFrameGrabber source path is triggered here even without SAL_VCL_QT_USE_QT_FRAME_GRABBER=1. (It just doesn't crash for me in my development build anyway for some reason.) Could you possibly check whether those two changes would also fix the issue for you? https://gerrit.libreoffice.org/c/core/+/199293 https://gerrit.libreoffice.org/c/core/+/199294 (Then we can discuss what's the best way forward, s.a. my other comments in https://gerrit.libreoffice.org/c/core/+/199083 .)
(In reply to Michael Weghorn from comment #6) > Since audio-only files don't have any video/images to show, a 0 size seems > to make sense in general. But then, that seems to be the reason why the > known problematic QtFrameGrabber source path is triggered here even without > SAL_VCL_QT_USE_QT_FRAME_GRABBER=1. (It just doesn't crash for me in my > development build anyway for some reason.) https://gerrit.libreoffice.org/c/core/+/199356 could be a potential way forward to avoid the problems with the experimental grabber unless explicitly enabled. That one could also be safely backported to release branches. Solving the experimental SAL_VCL_QT_USE_QT_FRAME_GRABBER=1 case could then be handled separately, potentially on master only (in particular in case it requires more fundamental changes). What do you think?
> (Then we can discuss what's the best way forward, s.a. my other comments in > https://gerrit.libreoffice.org/c/core/+/199083 .) Not sure where it's better to continue the discussion—here or in Gerrit :) So: Yes, the bug occurs without SAL_VCL_QT_USE_QT_FRAME_GRABBER=1. I noticed the flag during debugging and used it to test video files (not just audio). I also looked for ways to avoid processing Qt events, but ran into the issue that without the GUI thread, there won't be a frame change signal from the player. Moving it to a separate QProcess seemed too radical to me :) I also tried to interrupt event processing earlier if the frame hasn't been captured yet, but couldn't figure out how :) I have a lot of confusion about how the DragNDrop mechanism works in general. For example, when dropping media onto the canvas, we first arrive at grabFrame with an empty path, and then again, almost through the same call chain, but already with the file path. Why is it implemented this way if the path could be passed immediately? Why does QtFrameGrabber even have its own separate player that we reload media into again, if the object lifetimes allow us to simply pass it a pointer to the player from QtPlayer?
(In reply to nuke from comment #8) > > (Then we can discuss what's the best way forward, s.a. my other comments in > > https://gerrit.libreoffice.org/c/core/+/199083 .) > > Not sure where it's better to continue the discussion—here or in Gerrit :) Either works. :) > So: > Yes, the bug occurs without SAL_VCL_QT_USE_QT_FRAME_GRABBER=1. I noticed > the flag during debugging and used it to test video files (not just audio). Thanks for the confirmation. I was just initially surprised why you would explicitly enable an experimental (and known to potentially cause crashes) feature. (But with the findings from comment 6, it's clear now why the problems were there even without it.) > I also looked for ways to avoid processing Qt events, but ran into the > issue that without the GUI thread, there won't be a frame change signal from > the player. Moving it to a separate QProcess seemed too radical to me :) Yes, I was hesitating with that, too, but couldn't come up with another better idea for now (without digging deeper and considering more fundamental changes to the other Impress video/audio logic for now). > I have a lot of confusion about how the DragNDrop mechanism works in > general. For example, when dropping media onto the canvas, we first arrive > at grabFrame with an empty path, and then again, almost through the same > call chain, but already with the file path. Why is it implemented this way > if the path could be passed immediately? Good question, to which I don't have an answer either without further analysis. (And the answer may well be that there is no good reason for it to be implemented this way.) > Why does QtFrameGrabber even have its own separate player that we reload > media into again, if the object lifetimes allow us to simply pass it a > pointer to the player from QtPlayer? Could sharing a player cause problems of maintaining the player state in QtPlayer? E.g. if a frame grab is requested, that requires setting the time to a certain point and start playing there until the first frame arrives. If that happens e.g. while "actual" playback happens or the "actual" player was used before and has some state, messing with it might potentially be problematic. I didn't check in more detail whether these can actually happen, but thought it would be safer to keep them separate when initially implementing the QtMultimedia-based logic. FYI: The QtMultimedia-based implementation was mostly written to adhere with other implementations/existing code the XPlayer/XFrameGrabber API. There might be potential to optimize the overall logic in Impress, but I personally didn't (want) to look too much into that so far. Doing so might well give interesting insights and ideas on potential alternatives/solutions, however. :)
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d7d542b198d4edb3938b69ff31f07c1b2d0d0fb4 tdf#170681 qt avmedia: Don't fall back to QtFrameGrabber unless enabled It will be available in 26.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Michael Weghorn from comment #7) > https://gerrit.libreoffice.org/c/core/+/199356 could be a potential way > forward to avoid the problems with the experimental grabber unless > explicitly enabled. > That one could also be safely backported to release branches. > > Solving the experimental SAL_VCL_QT_USE_QT_FRAME_GRABBER=1 case could then > be handled separately, potentially on master only (in particular in case it > requires more fundamental changes). https://gerrit.libreoffice.org/c/core/+/199356 was reviewed and merged in the meantime, and I've created cherry-picks for release branches, so we can focus on the SAL_VCL_QT_USE_QT_FRAME_GRABBER=1 case on git master now.
> https://gerrit.libreoffice.org/c/core/+/199356 was reviewed and merged in > the meantime, and I've created cherry-picks for release branches, so we can > focus on the SAL_VCL_QT_USE_QT_FRAME_GRABBER=1 case on git master now. I rebuilt and tested it, and the patch does not fully fix the problem - the crashes are still there. The thing is that in addition to QtFrameGrabber, event processing is also triggered from QtPlayer itself, from the QtPlayer::getPreferredPlayerWindowSize() function, which will inevitably be called from grabFrame with an empty xGrabber. Event processing is started if the file is not loaded, which is quite likely. while (m_xMediaPlayer->mediaStatus() == QMediaPlayer::LoadingMedia) QCoreApplication::processEvents();
I would suggest temporarily abandoning QtPlayer altogether and using, for example, avmedia.gstreamer instead, but that introduces other issues that need to be addressed -_-
(In reply to nuke from comment #12) > I rebuilt and tested it, and the patch does not fully fix the problem - the > crashes are still there. The thing is that in addition to QtFrameGrabber, > event processing is also triggered from QtPlayer itself, from the > QtPlayer::getPreferredPlayerWindowSize() function, which will inevitably be > called from grabFrame with an empty xGrabber. Event processing is started if > the file is not loaded, which is quite likely. > while (m_xMediaPlayer->mediaStatus() == QMediaPlayer::LoadingMedia) > QCoreApplication::processEvents(); One option could be moving that logic to the separate process as well. New potential implementation to do that in addition is now in Gerrit change series up to https://gerrit.libreoffice.org/c/core/+/199621 . Does that fix the problems with and without SAL_VCL_QT_USE_QT_FRAME_GRABBER=1 when the series is applied on top of master? (In reply to nuke from comment #13) > I would suggest temporarily abandoning QtPlayer altogether and using, for > example, avmedia.gstreamer instead, but that introduces other issues that > need to be addressed -_- The reason why QtPlayer was introduced was to support video playback on Wayland, which wasn't working previously (see tdf#145735 for some more details). In case of dropping QtPlayer, that would need another solution.
> Does that fix the problems with and without > SAL_VCL_QT_USE_QT_FRAME_GRABBER=1 when the series is applied on top of > master? After applying all the proposed patches, I observe no crashes, even with the SAL_VCL_QT_USE_QT_FRAME_GRABBER=1. This is undoubtedly a success; however, in my opinion, the solution via launching separate processes is too "brutal" :). In my patch https://gerrit.libreoffice.org/c/core/+/199083, I aimed for minimal changes to the existing codebase.
(In reply to nuke from comment #15) > After applying all the proposed patches, I observe no crashes, even with the > SAL_VCL_QT_USE_QT_FRAME_GRABBER=1. Thanks for testing and the feedback. > in my opinion, the solution via launching separate processes is too "brutal" > :). In my patch https://gerrit.libreoffice.org/c/core/+/199083, I aimed for > minimal changes to the existing codebase. I'm open to alternative solutions. :) As mentioned in https://gerrit.libreoffice.org/c/core/+/199083 , the current version has an issue with intermittently showing a black frame when inserting a video, but maybe the solution can be further refined?
> I'm open to alternative solutions. :) > > As mentioned in https://gerrit.libreoffice.org/c/core/+/199083 , the current > version has an issue with intermittently showing a black frame when > inserting a video, but maybe the solution can be further refined? I have an alternative solution that involves suppressing the forwarding of Qt events further into LibreOffice (in CallCallback in QtTimer). "In spirit," it is similar to my current solution using the "cached" boolean flag, but slightly more flexible. And it has not "black frame" problem (At least, I didn't notice it during testing)
Michael Weghorn committed a patch related to this issue. It has been pushed to "libreoffice-26-2": https://git.libreoffice.org/core/commit/5c4baf4d850703977d085e26b0a458362f65574f tdf#170681 qt avmedia: Don't fall back to QtFrameGrabber unless enabled It will be available in 26.2.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Weghorn committed a patch related to this issue. It has been pushed to "libreoffice-25-8": https://git.libreoffice.org/core/commit/330fae366e018c9c24433b741a5fc666b82e3494 tdf#170681 qt avmedia: Don't fall back to QtFrameGrabber unless enabled It will be available in 25.8.6. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Weghorn committed a patch related to this issue. It has been pushed to "libreoffice-26-2-1": https://git.libreoffice.org/core/commit/06db80859097390dd80902cc98988f958fdbe87b tdf#170681 qt avmedia: Don't fall back to QtFrameGrabber unless enabled It will be available in 26.2.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Sergey Anisimov committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/64c7eac19219055ad228098926d6577cfcf0720a tdf#170681 - Using separated QThread for Qt frame grabber It will be available in 26.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Sergey: if you are happy, feel free to close as fixed.