I’ve been clipping a file while using a proxy in project mode, on finishing I switched off proxy. When proxy is then disabled the clips aren’t in the right place, I’m missing bits I didn’t remove and bits are included which I clipped away. Any ideas how to get the original synced up?
The created proxy file is 1 second longer than the original video, so assuming that’s where the error is coming from. It was automatically made using the useProxy feature.
Does this issue with proxy happen every single time or did it happen just one time and never again in your project? Can you repeat this issue again in the project you are working on? Do you have an mlt project file for this project where this issue is happening?
Seems to happen when I use .ts files as input that are tv recordings, so have interlacing. Seems to happen on all of them, in multiple different projects. I probably have a workaround by converting them to standard mp4 before starting.
Sorry for side question: what formats are .ts and .mts exactly?
I normally get these when recording with my Lumix camera and i also get them from my smart phone i guess. I should never use them directly for editing in SC (and other editors as well i would assume?)?
They dont have variable bitrates, do they?
P.S. o.k. .ts stands for transport stream, mts for mpeg-ts, both being containers for mpeg-2 blocks as i understand it. Should they be converted by ts-converter or could SC be used as well, without any losses? What are the specific problems when editing .ts files directly? Is it not possible to cut at each frame e.g. because the blocks of 188 bytes dont offer that freedom?
Not all .ts and MTS is non-editable. Austin only offered his opinion, but he is not the decision maker. No dialog will be presented automatically for this. Most people convert only when necessary, which is as it should be in my opinion. Sometimes that is determined after a problem occurs.
Occasional brief “scrambled egg” effect, meaning extreme glitch-colored blockiness.
When cuts are made in a long clip, each sub-clip may start on a different frame than expected when previewed and could be different on each export because seeking is not frame-accurate.
Scrubbing the playhead can sometimes have lag because seeking in .TS can be slower than other formats.
I assume you meant variable frame rate. Generally no, VFR isn’t the issue, but I noticed a close runner-up today.
I have an old Sony CX110 camcorder that makes AVCHD MTS files in 1080i 59.94 fields per second. When I look at its metadata, I see a FourCC of “HDMV”, a container timebase of 90K, and a video stream timebase of 59.94. This file is constant frame rate but still has problems when used directly, as described above.
So, I remuxed with ffmpeg to a new MTS container, meaning no re-encoding of the video and audio streams:
ffmpeg -i Original.MTS -codec copy Remux.MTS
This new file has FourCC “HDMV”, container timebase of 90K, and stream timebase of 90K. Notice there was a timebase mismatch between the container and the video stream in the file that came directly out of the camcorder. I wondered if rounding errors due to the mismatch could account for seeks that were not frame-accurate. In essence, this could look like unintentional variable frame rate.
Running Remux.MTS through Shotcut revealed that it had all the same problems as the original file.
Time for a new theory… maybe the TS container itself is the problem:
ffmpeg -i Original.MTS -codec copy Remux.MP4
No re-encoding of the streams, but now the container is MPEG-4 instead of TS.
The original file had four frames of scrambled egg at the very beginning and then a time-skip where it looked like a couple of frames were lost before the video cleaned up. With the MPEG-4 version, the video starts directly on the clean frame, and skips over the scrambled egg at the beginning. The MPEG-4 version also seeks on the timeline fast, was frame-accurate in a cut-and-export test, and had no scrambled egg anywhere. It also had timebases that were all in alignment at 90K, and a FourCC of “avc1”.
Even more interesting is that Original.MTS and Remux.MTS had seek issues in MPC-BE media player, but Remux.MP4 did not.
This is telling me the problem is in parsing TS containers. I don’t know if this means consumer cameras are writing bad TS, or if ffmpeg isn’t good at reading consumer TS. Regardless, moving the streams to a MPEG-4 container seems to fix pretty much everything.
For any ffmpeg-based editors like Shotcut, this appears to be true, at least with the wide assortment of consumer cameras I’ve tried. Professional cameras might be fine. And other editors besides Shotcut/ffmpeg may have entirely different TS parsers that are fine.
Almost! @shotcut will get a kick out of this. The “Extract sub-clip” feature calls ffmpeg command-line to do the extraction. I tried opening Original.MTS in Shotcut and then doing “Extract sub-clip”, but saving the sub-clip as Extract.MP4 instead of Extract.MTS. In theory, this would force the streams into an MP4 container just like I did in the ffmpeg examples above. Unfortunately, my Sony camera wrote a subtitle stream with the date and time of when the video was taken (gotta go all-in with the 80’s vibe), and that subtitle format was not allowed in an MP4 container. The extract process failed because of it. One workaround is to not extract subtitles so this MTS-to-MP4 hack becomes possible. But I also understand the desire to do a full -map 0 extraction in case somebody has purposes for the clip beyond Shotcut.
So for now, the only lossless transcode option in Shotcut is to convert with Ut Video. The resulting file would likely be very large.
I have a number of Lumix cameras and love them. Somewhere in the menu should be an option to save video as AVC or MP4. The AVC option is what makes the .TS files. The MP4 option has none of the problems I listed at the beginning, and also has a higher bitrate than is allowed by the AVC option, so the video looks better in MP4 too.
Below is the Extract Sub-Clip conversion code that is preserving subtitles:
I am keenly aware of this and try not to talk as if I am. My apologies that my writing style suggested otherwise. For the OP’s sake, I was trying to clarify the post you made prior to mine (regarding clip conversion) by describing the entire process they would need to do in a single list.
Thank you very much, Austin, for the detailed description.
I was not aware of the problems .ts or .mts files can produce in editing.
I am afraid i don’t understand all the technical details but good to know how to convert the .ts-files into mp4-files for editing.
My Lumix is an FZ 1000 which i like for its small size and rather good video and photo quality.
For really high demanding tasks i also use my Canon EOS 5D-MkII, but you have to carry some more kg and lenses around.