Openshot-qt: (Some) MP3 files containing cover art cause OpenShot to crash on Preview/Export
I'm trying to combine sounds from original video with a background music. As soon as internal viewer or export process starts to process a moment when music kicks in, Openshot crashes.
I tried multiple ways:
- Just to join video and music.
- Separate audio from video first and then join video + original audio + music.
It makes no difference - Openshot crashes in both cases.
Version: 2.4.4
Platform: Windows 10
sknaumov
All 33 comments
@sknaumov It _sounds_ like the issue may be with the format of your music file, more than the combining of them. (If you were to place just the background music alone on the timeline, can you play or export that?)
Either way, it would be helpful if you could collect logs while reproducing the crash, then submit those so we can take a look. I can say that, in _general_, OpenShot is able to combine audio from two sources. So, there must be some issue with the specific audio you're trying to use.
ferdnyc
on 14 Oct 2019
Stack trace is only collected when OpenShot crashes while exporting video. No logs are collected for crashes while in internal viewer. Music file that leads to the crash is attached. I tried another mp3 file and everything worked well.
JAWS 1975 - Main Title (Theme From Jaws) Full HD.zip
libopenshot logging: Wed Oct 16 00:14:48 2019
------------------------------------------
---- Unhandled Exception: Stack Trace ----
_C_specific_handler 7ffc18f67fb0
_chkstk 7ffc1a1410e0
RtlRaiseException 7ffc1a109ef0
KiUserExceptionDispatcher 7ffc1a13fe40
ZN8openshot12FFmpegReader17CheckMissingFrameEx af14b20
ZN8openshot12FFmpegReader18CheckWorkingFramesEbx af160e0
ZN8openshot12FFmpegReader10ReadStreamEx af17b60
ZN8openshot12FFmpegReader8GetFrameEx af183b0
ZN8openshot11FrameMapper16GetOrCreateFrameEx af2b370
ZN8openshot11FrameMapper8GetFrameEx af31740
ZN8openshot4Clip16GetOrCreateFrameEx aed1e00
ZN8openshot4Clip8GetFrameEx aed7710
ZN8openshot8Timeline8GetFrameEx af4bfe0
PyInit__openshot 71271800
PyCFunction_FastCallDict 69c10630
PyEval_EvalFrame 69c801f0
PyEval_EvalFrameDefault 69c81880
PyEval_EvalFrame 69c801f0
PyEval_EvalFrame 69c801f0
PyEval_EvalFrameDefault 69c81880
PyEval_EvalFrame 69c801f0
PyFunction_FastCallDict 69c88a00
PyObject_FastCallDict 69bcb350
PyObject_Call_Prepend 69bcb5e0
PyObject_Call 69bcb220
PyInit_QtCore 6f21e450
PyInit_QtCore 6f21e450
PyInit_QtCore 6f21e450
PyInit_QtCore 6f21e450
PyInit_QtCore 6f21e450
ZN11QMetaObject8activateEP7QObjectiiPPv 6696fe20
ZNK16QDialogButtonBox6buttonENS_14StandardButtonE 4e02340
ZN16QDialogButtonBox18qt_static_metacallEP7QObjectN11QMetaObject4CallEiPPv 4e036e0
ZN11QMetaObject8activateEP7QObjectiiPPv 6696fe20
ZN15QAbstractButton7toggledEb 4d767b0
ZN15QAbstractButton11setIconSizeERK5QSize 4d77780
ZN15QAbstractButton17mouseReleaseEventEP11QMouseEvent 4d77ef0
???
ZN7QWidget5eventEP6QEvent 4cd4a80
???
ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent 4c97c30
ZN12QApplication6notifyEP7QObjectP6QEvent 4c9ec60
???
ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent 669451d0
ZN19QApplicationPrivate14sendMouseEventEP7QWidgetP11QMouseEventS1_S1_PS1_R8QPointerIS0_Eb 4c9e1d0
ZN14QDesktopWidget11qt_metacallEN11QMetaObject4CallEiPPv 4ce6d30
ZN14QDesktopWidget11qt_metacallEN11QMetaObject4CallEiPPv 4ce6d30
ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent 4c97c30
ZN12QApplication6notifyEP7QObjectP6QEvent 4c9ec60
???
ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent 669451d0
ZN22QGuiApplicationPrivate17processMouseEventEPN29QWindowSystemInterfacePrivate10MouseEventE 4749600
ZN22QGuiApplicationPrivate24processWindowSystemEventEPN29QWindowSystemInterfacePrivate17WindowSystemEventE 474b680
ZN22QWindowSystemInterface22sendWindowSystemEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE 4721900
ZN28QEventDispatcherWin32Private14sendTimerEventEi 6699d830
CallWindowProcW 7ffc18656030
DispatchMessageW 7ffc18655bf0
ZN21QEventDispatcherWin3213processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE 6699ccf0
qt_plugin_instance 6dd2a930
ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE 66943b20
---- End of Stack Trace ----
I tried another mp3 file and everything worked well.
OK, cool. That makes sense to me. I mean, I had a timeline with two audio sources playing just _last week_, I know it really does work! Except when it doesn't. :grin:
Music file that leads to the crash is attached.
Uh-oh. I think I know what might be going on here. You may have bumped into a long-standing bug that file just reminded me about, involving image data on (what are expected to be) audio-only files. Sorry about that.
I've attached a copy of your MP3, identical in every way _except_ that I removed the cover-art image from the metadata. Try this out and see if it makes a difference.
ferdnyc
on 16 Oct 2019
@sknaumov I just want to check if @ferdnyc 's mp3 helped solve your problem?
mikelacsa
on 17 Oct 2019
@mikelacsa Yes, it helped. But then Openshot doesn't properly handle extraction of audio from video, because I tried to extract audio from original track using Openshot, it started to show some sound levels on the rectangle, but it didn't help.
sknaumov
on 17 Oct 2019
Hmm. It would appear (#1625) that, a little over a year ago, importing audio files with cover art worked. (They imported as video files and _displayed_ the cover art, which was occasionally problematic, but they didn't crash OpenShot.) Something must've changed since then.
Not sure I'm following you regarding the "extraction" report, though, @sknaumov — can you explain step-by-step what you were trying to do (and maybe why?) What's the definition of "it didn't help", in this context?
ferdnyc
on 18 Oct 2019
@ferdnyc I meant that I tried to do the following with original mp3 with a cover art:
- Place it on timeline.
- Right click on its rectangle -> Separate Audio -> Single Clip (all channels).
- Delete original mp3 audio (with a cover art) from timeline and leave only separated one:
- When I try to preview or export my video, OpenShot crashes.
I could also say that I used audio with cover art in May and everything was fine, but there I completely disabled original audio instead of mixing it with the music file.
sknaumov
on 18 Oct 2019
@sknaumov Oh, OK, that's not surprising. "Separate audio" doesn't literally extract the audio from the video file. It simply disables audio on the original clip, and creates a clone of that clip with audio enabled but _video_ disabled. (Or multiple clones, one for each channel.)
If OpenShot is crashing on the original clip, it's still going to crash on the separated clip(s), since they still reference the same source file.
But the fact that it's crashing at all is the crux of the problem here.
ferdnyc
on 18 Oct 2019
The same issue has been reported downstream in the RPM Fusion bugtracker, meaning that it also affects Linux and is not isolated to the Windows platform. (Not that I ever thought it was, but just for the record.)
ferdnyc
on 18 Oct 2019
Added 'workaround' label, since removing the image data from the MP3 does appear to be a workable solution for now, even though it's obviously not ideal.
ferdnyc
on 18 Oct 2019
Some other MP3 files with cover arts worked fine, but the file from the OP made OpenShot crash.
I've built a debug version of libopenshot and used it for debugging. The backtrace points to:
https://github.com/OpenShot/libopenshot/blob/3f5370a84c92d5c4e1ce8abf634d588dc5966be7/src/FFmpegReader.cpp#L2086
It seems like last_video_frame is null while last_frame isn't. If I replace the last_frame with last_video_frame, OpenShot doesn't crash anymore. OpenShot doesn't display the cover art even after this fix, though.
PhysSong
on 25 Oct 2019
@PhysSong Thank you, incredibly helpful info! I've git blame'd that line back to its source commit, which was part of OpenShot/libopenshot#196, and I've updated @jonoomph with the results of your analysis.
ferdnyc
on 25 Oct 2019
It looks similar to: https://github.com/OpenShot/openshot-qt/issues/2756 isn't it?
SuslikV
on 25 Oct 2019
It looks similar to: #2756 isn't it?
Maybe there are some more duplicates.
PhysSong
on 26 Oct 2019
I wouldn't be surprised, yeah. Since this issue has more detail (including, most importantly, the source location of the crash and the commit that created those lines), I'll close #2756 as a duplicate.
ferdnyc
on 26 Oct 2019
Also #2797 — the issue _reported_ there wasn't the same (it was actually far weirder, there the user reported that slicing or separating the audio from an imported MP3 would cause time-shifts), but I have to believe the cause there is also the OpenShot/libopenshot#196 changes, since removing the cover art fixed the problem.
ferdnyc
on 26 Oct 2019
Anyway, the #2756 is important, because all of you speaking as programmers. And casual user when looking for the crash solution (googling) don't know what steps to take to resolve the issue.
SuslikV
on 26 Oct 2019
I did some more tests:
- If the MP3 file has an MJPEG cover image, it works fine.
- If the format of the cover image is something other than MJPEG, OpenShot crashes.
It turns out the file provided by OP has a PNG-formatted cover image.
PhysSong
on 28 Oct 2019
*nod* @PhysSong That makes sense, I remember in looking around the code for handling MP3 files with "video" data that it seemed to be blindly decoding it as MJPEG. Which is crazy, because if anything PNG cover art is probably _more_ common, at least today. Pretty sure that's the only format iTunes uses. But in theory, I'm pretty sure the image could be anything — even a BMP, GIF, or TIFF file. Not that we have to support all of those, but we have to at least be prepared to encounter them.
Sounds like we need to either do some conversion, or at least _check_ the format before trying to decode it.
ferdnyc
on 28 Oct 2019
That makes sense
(Not the code, that makes no sense at all. But what @PhysSong is saying tracks with what I recall from reading the code. #JustToBeClear :wink: )
ferdnyc
on 28 Oct 2019
It seems like there were no responses from @jonoomph for a while. So, I'd like to look into this a bit more and issue a PR against libopenshot.
PhysSong
on 1 Nov 2019
@PhysSong If you're interested in tracking this down, that would be great — please do! I'll offer whatever assistance I can provide (though I don't know _that_ part of the code well at all), and I have the discretion to merge PRs if it comes to that. (An ability I try to use very sparingly, but for bugfix patches with clear benefits and no obvious "gotchas" there's little argument for _not_ getting the code merged and available to a wider audience for testing.)
ferdnyc
on 1 Nov 2019
I'm digging this one, but I haven't found anything other than https://github.com/OpenShot/openshot-qt/issues/3043#issuecomment-546186184. I'm going to try more to find the underlying issue, but in the case of failure, I'll open a small pull request with the mentioned change.
PhysSong
on 6 Nov 2019
It seems like
last_video_frameis null whilelast_frameisn't. If I replace thelast_framewithlast_video_frame, OpenShot doesn't crash anymore. OpenShot doesn't display the cover art even after this fix, though.
I just took a look at the source, and (more helpfully) the header... It's very poorly commented, but last_frame is type int64_t, while last_video_frame is a shared_ptr<openshot::Frame>. So, you definitely don't want to be copying any data from one to the other or anything like that.
My interpretation, based on the types, is that last_frame would be the frame NUMBER of the frame that's held in last_video_frame. So, it's entirely _plausible_ (though I don't think it's necessarily _correct_) that last_frame could be 0, perhaps, when reading from an MP3 file, and would therefore test false. Perhaps whoever wrote the crazy pile of conditions in that if() statement didn't account for that. (I'm assuming that "last" means the highest-numbered frame decoded, and _not_ previous_frame, because then 0 would be extremely likely the first time through. But if it's the _last_ frame available, I'd expect it should be frame number 1 at least.)
If the frame is _failing_ to decode because it's PNG data rather than MJPEG, then that could conceivably also leave you with a last frame# of 0, since no frames were decoded. But then it's odd that the shared_ptr<openshot::Frame> last_video_frame would have non-null data in it. Unless it's just the default black rectangle that gets filled in when frames aren't available.
ferdnyc
on 6 Nov 2019
I haven't had much time to look into this.
I'm going to look into FFplay's source code(maybe some other software as well) as a reference and see if I can find any issues.
PhysSong
on 12 Nov 2019
There was a progress: I found that AV_DISPOSITION_ATTACHED_PIC may be useful for handling cover arts. I'll research its usage and see if libopenshot can leverage from it.
PhysSong
on 13 Nov 2019
@PhysSong Nice find! Looks like, if that option is set on the input, you can read the cover art directly from an explicit stream AVStream::attached_pic. For files we know are audio with image data (as opposed to video), that might even be safer than relying on automatic inclusion in the video stream.
The semantics on those parts of the API have been unchanged since FFMpeg 2.0, it appears, so you should be safe across all supported FFmpeg releases with no version checks. #WINNING
ferdnyc
on 13 Nov 2019
Additionally, I was able to figure out why OpenShot fails to decode PNG cover arts.
I tried various MP3 files with MJPEG, PNG, BMP, and TIFF cover arts. MJPEG and BMP worked fine, whereas PNG and TIFF didn't. I looked into the FFmpeg source code and noticed that the PNG decoder and the TIFF decoder supports per-frame threading. The documentation for AVCodecContext::thread_type says:
Use of FF_THREAD_FRAME will increase decoding delay by one frame per thread, so clients which cannot provide future frames should not use it.
I think it doesn't matter much for videos, but it's critical for album arts.
As far as I found, there are several ways to disable it as you can see here. However, I think only two of them make sense, one is disabling FF_THREAD_FRAME threading mode directly, the other is setting the AV_CODEC_FLAG_LOW_DELAY flag. Note that this should be done before calling avcodec_open2 for video streams, and there are no AV_ prefixes in FFmpeg older than 2.8.
PhysSong
on 16 Nov 2019
I did some experiments with daily builds as well. OpenShot-v2.5.0-dev1-1579721230-49972b21-f38389fc-x86_64.AppImage crashed when seeking back an MP3 file with MJPEG cover art. The backtrace pointed the same code segment as the reported bug. OpenShot-v2.5.0-release-candidate-1579718998-x86_64.AppImage just hangs, and 2.4.4 works without any issues.
PhysSong
on 30 Jan 2020
Hi there I think I'm having a similar issue here. I've looked through what you guys have said but I honestly don't understand most of it. Is there a way to fix this available? I can consistently get Openshot to crash using this one specific MP3 file while others play nice. The file in question is listed as a video in Openshot and cause the preview to stop when the play bar gets to it. I've tried playing the file by itself and with other files and each time there is a crash. I tried the most recent daily build and although this improved things (the crash did not happen as soon as I introduced the file to the time line) I still get crashes when trying to interact with it after e.g. deleting it from the timeline. I've got a bug report ready to submit for it but I figured I'd check here first.
The file in question:
Backing Track.zip
This is my first time here on Github so any help on etiquette etc. is also appreciated.
The-Mad-Mellon
on 17 Jun 2020
@The-Mad-Mellon https://github.com/OpenShot/openshot-qt/issues/2756#issuecomment-487876270
SuslikV
on 17 Jun 2020
@SuslikV ah thanks a lot, everythings working fine now
The-Mad-Mellon
on 17 Jun 2020
JFTR: To remove the cover art via ffmpeg, the command looks like this:
% ffmpeg -i input.mp3 -vn -acodec copy -f mp3 output.mp3
After that OpenShot imports the output.mp3 fine.
jkirk
on 11 Nov 2020
Related issues
TavernSenses
·
3Comments
CarlBicknell
·
3Comments
LadyReader
·
3Comments
malinga91
·
3Comments
gbbbbb
·
3Comments