Have you done any comparison with something more recent than something 2 years old? There has been a huge amount of change since then. The most interesting would the prior version 20.11. There were major changes in our FFmpeg integration in 21.01 to handle the AV1 decoding. I did do some brief testing with AVCHD (.MTS) after the changes, but it is also known that this format and HDV are some of the most challenging to edit directly against.
I looked into the possibility of installing yet another version of Shotcut on my system for this testing (I spent 14 hours on this today, trying to make some coherent sense out of the apparent randomness), but I could not find a clear explanation anywhere on how to do so. I don’t remember how I first installed Shotcut, except to remember that it was with difficulty (a problem of Ubuntu, and Linux in general, not a Shotcut problem). My copy of 18.11.18 as an app-image on my desktop was a relic of that era, and was a handy alternative for checking.
Is there an easy way to revert to 20.11 on Ubuntu? I was hoping to try that.
However, would that undo any library installations that came with 21.1.29?
I remember when I was shopping around among free video editing software, how each new install would make changes in the FFmpeg library; installing one app would break a previous, competitor app by installing an incompatible FFmpeg version, which all seem to share. (Once, a video editor which did not work suddenly became functional when a competitor app loaded a better FFmpeg library.)
FYI, after posting the bug report, thinking about it…
The sequence leading to the white frames at the beginning is, I think, this:
#1 - The MTS file, as loaded, can be Exported without the leading white frames.
#2 - A Split and a Remove takes off unwanted footage at the beginning of the video.
(#3 - A second split, at the end, or another action such as a filter, triggers the white screen problem.)
(I suspect that the front of the video is now raw and ragged from the
difficulty)
#4 - Any attempt to export this video is a challenge 21.1 cannot meet, although 18.11.18 seems to muddle through without easily noticeable trouble (but 18.11.18 complains voluminously in the log files.)
The process of finding the parameters of the envelope of this problem today have generated dozens of files and many gigabytes; I can post or send anything you want, but did not post any because I didn’t want to flood you with the stuff that wouldn’t help.
Just ask.
I think I can revert the FFmpeg library manually; would that help diagnose? If so, which FFmpeg version?
In a sense, I have already done that comparison; saved edit session which worked fine under 20.11 a few weeks ago now exhibit this problem; reloading the same MLT referencing the same MTS files.
This methodology for dealing with MTS from three identical Panasonic cameras, (and other problematic formats before that), has been used by me over the past two years for dozens of videos using Shotcut with no such problem until now.
Using the portable Linux package, you can have all past versions installed simultaneously:
On further though, I begin to suspect that 18.11.18 simply throws away the frames mangled by the split (which I concur is the fault of the design of the MTS standard, not of the editor software) and I have been none the wiser.
So I have conceived an experiment for this; I may have results tonight, or it may be later. It will take a while to run this further test.
Easy if you do it regularly and know which steps were left out.
I did manage to sort through the link (Thank you!) and find the appimage, which did nothing until the magic I researched was applied…
Now I have the appimage of 20.11.28 up and running on the desktop. We shall see what it does.
Thank you again.
(Since there is a limit on consecutive replies, an extension…)
Running a direct compare now.
So far, looking better that 20.1.29; no white screens yet.
Because I had actually set out to do editing, not testing, at 3 AM this morning, the files I have been working with are production files. Big. I am running the Export now; I will report the results in about an hour.
1 Like
So far, Shotcut 20.11.28 appimage is looking good.
I can’t make it go white-screen no matter what I try.
The same export which produced leading white frames with 21.1.29 give a seemingly perfect output with 20.11.28.
Proceeding on with the test to see if earlier versions are merely throwing away leading frames after a split.
One theory busted and the other theory tottering and about to fall…
The earlier versions are NOT dropping the leading frames at the Split/Remove.
It looks like my library theory was also wrong.
(I couldn’t think of any other way a problem could “travel back in time” to a previous version.)
It now appears that
–Version 181118 has the MTS white-screen problem
–The problem was fixed by 20.11.28.
–The white-screen problem is reintroduced in 21.01.29.
Why did it seem to be a new problem just now appearing in 18.11.18?
I bought my Panasonic cameras in 2019, after I had moved on to another version of Shotcut. I had never used 18.11.18 on MTS files until today. (Why didn’t I think of that earlier???)
What I found:
18.11.18:
–Has whitescreen problems on MTS/MLT combos when a leading Split/Remove was made in 21.01.29,
–Has NO whitescreen problem when opening a seemingly identical MLT when the Split/Remove was done by itself.
–Always Exports properly.
20.11.28:
–Has NO whitescreen problems.
–Always Exports properly.
21.01.29:
–Has a whitescreen problem after it has made Split/Removes.
–The whitescreen problem persists to any session reloading the MLT wherein the Split/Remove was done.
–At first had no whitescreen problem when reloading an MLT file in which a Split/Remove had been done by 18.11.18, but after a back-and-forth between External Monitor and None, the whitescreen problem appeared.
–When Exporting from an MLT in which 181118 had made splits, covered the first few frames with white frames as before.
This is now confirmed.
I found some MTS that reproduced this problem (and some other from another camera that does not) in order to work on this.
1 Like
I am having a similar issue on my Windows machine. I’ve loaded in some MTS files spent quite some time editing the project with with which I used proxy files. The proxy files playback was fine. But when I exported to an MP4 file white frames appeared at the beginning of some segments. Some lasted a few frames others lasted the full second. All files were from the same camera with the same resolution settings. Not being able to output a file for distribution makes the edit process useless. In order to troubleshoot this I went back into the timeline and turned off the proxy files and noticed that some of the files appeared completely white. If I went to the transition prior to the file in question if I played back a few seconds repeatedly eventually the thumbnail would reappear on the timeline. I repeated this process for every clip that showed white on the timeline. Then save the project then went back to play again and some clips once again turned white. When I turn proxy files back on everything looks fine. But then when I export again I have the same issue. Pretty much makes the program useless unless this is fixed.
1 Like
Oh and just to be clear after reading this forum I tried to turn off hardware acceleration had the same issue both ways. Also tried rendering with with proxy files both on and off with the same results either way.
1 Like
Welcome to Shotcut, @Tmc
We are confidently expecting that @shotcut will have this fixed soon.
In the meantime, you could do as I am doing and use the App-image version of the previous revision of Shotcut when working with raw MTS files.
Version 20.11.28 has none of these issues.
You can find it here: Shotcut v20.11.28 archive
Running Windows, I believe you will want shotcut-win64-201128.exe
…and thank @brian for providing this tip originally.
You’ve already got these edited, so it’s too late to change on this project, but on the next project, I would suggest you convert your files to an editor-friendly format and then edit from these intermediate-step files.
You can have Shotcut do this for you (I believe that Shotcut 21.01.29 gets this right; I haven’t tried it with this version. I do my own MP4 intermediates; for this I use Shotcut 20.11.28 appimage.)
!
…or you can make your own. The problem with 21.01.29 Export usually doesn’t appear until an edit is made. Or to be on the safe side, you can do this step in the 20.11.28 appimage.
Thank you kagsundaram, I will try the older version. My project consists of 35 files and all are trimmed at least once. I think I can convert each file to edit friendly from the timeline. Perhaps a batch conversion and then replacing files is an option.
I rerendered the video with the older version and only one edit showed the white frames. Will try converting that clip (within the timeline) to edit friendly. Kept proxy files off for the test.
1 Like
I have found a way to make my MP4 intermediates from my MTS originals with little change to my usual workflow and no white frames at the beginning.
(My workflow first step is to convert the MTS files to edit-friendly MP4 files. These videos are from three cameras which simultaneously captured the same scene from different angles. In this step I also synchronize all three to one audio track, and harmonize the skintones with filters. After all synchronization, and before Export, I copy and edit to create four MLT files, identical in timing, but each exporting only one original track.)
My interim fix now is to use a PNG image bottom track, which I extend in time so that it extends both beyond the beginning and beyond the end of the original videos.
Now, instead of trimming the unwanted beginning and end (holding up the neutral gray card, etc.) as the last step before Export of these intermediates, I am leaving that trim for the first phase of the Main/Production/Final edit.
Because the leading white frames are the result of a Split/Remove operation on an MTS file, and because I am now postponing all Split/Remove until I have it in MP4 format, I no longer have leading white frames.
This solves my problem until…
…is successful.
I am very relieved to report that this bug is fixed for the next version 21.02!
1 Like
Thank you for the speedy resolution!
1 Like
…and I also saw…
…this morning.
@shotcut, if you would be so kind as to create an app-image for Ubuntu Linux, I would be glad to run beta-tests on the as-yet-unreleased 21.02
Beta testing of 21.02.15 shows this problem to be fixed.
1 Like
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.