What is your Shotcut version (see Help > About Shotcut)?
shotcut-23.07.29-1.fc38.x86_64
mlt-7.16.0-1.fc38.x86_64
Can you repeat the problem? If so, what are the steps?
100%
I have mlt files which were produced by Shotcut version 22.12.21 (mlt 7.12.0). They contain references to jpg images (no, no funny file names). If I open the mlt files with Shotcut version 23.07.29 then the images remain white.
Yes, this sounds like similar bugs, but I have both qt6-qtimageformats and qt6-qt5compat.
More observations:
In the original mlt file, those images have <property name="mlt_service">qimage</property>. If I open the file (image shows blank) and resave this is converted into <property name="mlt_service">avformat</property> (among other changes related to the new type).
If I create a new mlt and save I get <property name="mlt_service">pixbuf</property> for jpgs.
If I take the old mlts and simply replace qimage by pixbuf then shotcut will display the image, so this seems to be an easy workaround.
Questions:
Can older shotcut versions read pixbuf?
Shouldn’t shotcut convert qimage into an image type rather than avformat?
What could have gone wrong with this shotcut build (rpmfusion for Fedora)?
That is an unsupported version of MLT for Shotcut. It has known severe bugs including this one. There is newer version 7.18.0 of MLT since July 28. I encourage you to use our builds (including Flatpak) that are better managed.
Thanks for the hint, I’ll prod our packagers to update mlt then.
I had tried the flatpak meanwhile, btw. While it opens my file, the standard filesystem isolation of the pak did not allow it to follow symlinks outside of $HOME (where some files resided), and when I added filesystem=host the flatpak could not write to $HOME any more.
I’m sure this could be made to work somehow, switching to the flatpak is not a straight drop-in replacement.
… and, finally, mlt 7.16.0 renders the mlt correctly to mp4. It really is shotcut’s reading of the mlt file (maybe querying the jpg format/qimage) which is thrown off by something, and it still is with mlt 7.18.0. As such I don’t consider this solved, unless “flatpak works” is the definition of “works”.
OK, I will unsolve it, but I do not have an answer. There was a bug in MLT 7.16.0 where very a very large image would exceed some new default maximum in Qt 6, and I thought this was it. Your description suggests the Qt-based qimage module is not loading. Maybe something is going wrong if MLT is built against both Qt5 and Qt6.
Additional point of information: The combination shotcut-22.12.21-1.fc38.x86_64 with mlt-7.18.0-1.fc38.x86_64 works, too. I’m working with that partial downgrade for now.
So, together with the working flatpak, it means that the (Fedora) rpmfusion package for shotcut-23.07.29-1.fc38.x86_64 has a problem with qimage which the flatpak has not, be it due to packaging or shotcut itself.
I still think that shotcut could handle this more gracefully, but it seems you are right in that the root cause is with the packaging which apparantly would need some more adjustment for newer shotcut.