Something is wrong with trimming

[balintlaczko]

This is a strange issue as I don't recall this problem from earlier. Seems like trimming introduces some weird artifacts, as if it was damaging the file. For example:

It is typically happening around the cut time-point. It is also curious that the resulting file has the same length and frame-count in its metadata. BUT if I cut at a different time-point, the frame-count and length update in the metadata, but I get the "glitch" again at the starting point:

Again, trimming is probably the one function I have been using every day of testing, and it never seemed to behave like this before. I am using the patched ffmpeg build (where they fixed the issue with normalize). I have been using this build on a different computer before with no such errors. Will have to investigate this further.

[balintlaczko]

The issue seems to happen when performing "fast" trimming with ffmpeg. Like this:
ffmpeg -y -ss 5.00 -i dance2.mp4 -t 5.00 -map 0 -codec copy dance2_trim.mp4
In this case VLC produces the glitch above and the built in Movies app in Windows 10 starts playing the video from the beginning (audio intact but with a black screen) and when the playhead reaches the cut point it continues "normally".
But if I do ffmpeg -y -ss 5.00 -i dance2.mp4 -t 5.00 -map 0 -c:a copy dance2_trim.mp4 then everything is fine (of corse, since in this case we remux the video), though it's much slower...

[balintlaczko]

Created new ticket for the issue.

[balintlaczko]

For now I will implement a condition to not use codec copy when the input video is not .avi.

[balintlaczko]

Got back the answer from the devs that this is "normal" and unavoidable. Tested the behavior on ffmpeg 4.2.2 as well, same results.

[balintlaczko]

Implemented the condition that if the input file is not in an avi container, the don't copy the codec.