Cutting and compiling clips together results in freeze frames?

Started by ball2hi, November 08, 2016, 07:08:47 PM

Previous topic - Next topic

ball2hi

https://www.youtube.com/watch?v=nqNusZ9y49I

Here is a video I just uploaded. Over a 4 hour livestream, I went in and cut out short highlights then restarted Avidemux and put them together into a single video. In this video I was using Quicksync with OBS Studio for recording locally. I've never had this happen, but then again my other videos I used x264?

Proof:
https://www.youtube.com/watch?v=8vtPz9kmYpk
https://www.youtube.com/watch?v=HBnGsnCtgf4

Is this a quick-sync issue, or am I doing a something wrong in Avidemux?

eumagga0x2a

I'm not sure I get what kind of issue you have with your videos. Please explain.

/edit: it would be helpful if you provided the original samples you appended to produce the video.

eumagga0x2a

Just in case, I'd recommend not to save fragments and then combine them together (append videos), but instead delete parts of the source video you don't need (no worry, they are not really deleted but just hidden, unless you overwrite the source video).

The way how Avidemux calculates the total duration of a video might pose a problem, i.e. the duration might be too high, resulting in perceptible gaps between the last frame of the first video and the first keyframe of the appended second one. You could try to delete the last one or even two GOPs of the already loaded video after appending another, if you would like to continue working with separate short video files.

In any case I'd recommend using the most current nightly build matching your operating system instead of the 2.6.14 release, because the latter lacks some important fixes relevant for editing.

ball2hi

Quote from: eumagga0x2a on November 08, 2016, 07:32:48 PM
I'm not sure I get what kind of issue you have with your videos. Please explain.

/edit: it would be helpful if you provided the original samples you appended to produce the video.
I explained it in the above post, with a link to the video in question. It's still applying to newer videos and I can try and upload some in an hour or two as I'm about to head out. I already deleted the segments an hour ago but still have the current (The upload to YouTube) video on my HDD.

Quote from: eumagga0x2a on November 08, 2016, 07:48:51 PM
Just in case, I'd recommend not to save fragments and then combine them together (append videos), but instead delete parts of the source video you don't need (no worry, they are not really deleted but just hidden, unless you overwrite the source video).

The way how Avidemux calculates the total duration of a video might pose a problem, i.e. the duration might be too high, resulting in perceptible gaps between the last frame of the first video and the first keyframe of the appended second one. You could try to delete the last one or even two GOPs of the already loaded video after appending another, if you would like to continue working with separate short video files.

In any case I'd recommend using the most current nightly build matching your operating system instead of the 2.6.14 release, because the latter lacks some important fixes relevant for editing.
The issue with that is I sometimes take highlights from several different video sources over a week or two and then mash them together. It's also much easier to keep track of all the clips and put them together.

Uh... most current nightly build. Am I looking at avidemux_2.6.14_r161106_win64.exe under http://avidemux.org/nightly/win64/ ?

eumagga0x2a

Quote from: ball2hi on November 08, 2016, 08:16:55 PM
Quote from: eumagga0x2a on November 08, 2016, 07:32:48 PM
I'm not sure I get what kind of issue you have with your videos. Please explain.

/edit: it would be helpful if you provided the original samples you appended to produce the video.
I explained it in the above post,

You tried to explain it in the subject, not in the body of the post. Anyway...

Quotewith a link to the video in question.

...I don't see the issue in that youtube video, but hear gaps in audio.

QuoteIt's still applying to newer videos and I can try and upload some in an hour or two as I'm about to head out. I already deleted the segments an hour ago but still have the current (The upload to YouTube) video on my HDD.

Only the source videos (the fragments you append) would be of interest, not the result.

Quote
Quote from: eumagga0x2a on November 08, 2016, 07:48:51 PM
Just in case, I'd recommend not to save fragments and then combine them together (append videos), but instead delete parts of the source video you don't need (no worry, they are not really deleted but just hidden, unless you overwrite the source video).

The issue with that is I sometimes take highlights from several different video sources over a week or two and then mash them together. It's also much easier to keep track of all the clips and put them together.

You should make longer fragments then and cut excessive duration after appending them.

QuoteUh... most current nightly build. Am I looking at avidemux_2.6.14_r161106_win64.exe under http://avidemux.org/nightly/win64/ ?

No, the latest (with a "Minimize to Tray" button added to the encoding dialog) is avidemux_2.6.14_r161107_win64.exe as .exe or the same build packaged as a ZIP archive named avidemux_r161107_win64Qt5_291.zip.

eumagga0x2a

WRT the screenshot you posted: The total duration of a short video loaded in Avidemux is shown as 28.351 seconds. Go to the last frame (press END) and look at the time displayed by Avidemux. This time (the PTS of the last frame) is probably considerably less than 28.351 seconds.

At the same time the first keyframe of a video has often a non-zero PTS (presentation time stamp). Now add the difference between the calculated total duration and the PTS of the last frame to the PTS of the first frame of the video you want to append and you get the duration of the resulting gap.

Therefore, your source videos should always be at least one GOP (group of pictures) longer than necessary to be able to delete the GOP adjacent to the boundary between appended videos.

ball2hi

Quote from: eumagga0x2a on November 08, 2016, 09:05:29 PM
...I don't see the issue in that youtube video, but hear gaps in audio.
I literally don't know how you can not see the issue. This is definitely not a playback issue because none of my other mashed up videos have a problem, even my viewers have pointed out something is wrong with the video

Video - YouTube Test
Video - Comparison from 3 months ago

In the first video, right at the end of a clip before it switches to the next clip it freezes for a split second. This does not happen in the second video I made 3 months ago. The only difference between now and then (3 months ago) was I was using an older version of Avidemux, Windows 7, and x264 for recording. I am now currently using the nightly Avidemux build, Windows 10, and Quick-sync for recording.

I uploaded the video segments for the above test video to Mediafire if you want to inspect them.

Quote from: eumagga0x2a on November 08, 2016, 09:27:30 PM
Therefore, your source videos should always be at least one GOP (group of pictures) longer than necessary to be able to delete the GOP adjacent to the boundary between appended videos.

I literally have zero clue about what you just said. When it comes to video editing I am a inexperienced which is why I've been using Avidemux for years since it's super simple and covered exactly what I needed.

eumagga0x2a

Thank you for the samples, I clearly see the issue when playing the TestFINAL.mkv sample. It happens because the fragments don't start with a keyframe, which is causing the whole trouble. Next time please ensure you start the cut at a keyframe (I-frame) only.

You can still rescue the TestFINAL.mkv video with the following script, which deletes unusable parts of the video:

#PY  <- Needed to identify #
#--automatically built--

adm = Avidemux()
adm.clearSegments()
adm.addSegment(0, 0, 3167000)
adm.addSegment(0, 3501000, 2783000)
adm.addSegment(0, 6618000, 2783000)
adm.addSegment(0, 9735000, 2783000)
adm.addSegment(0, 12852000, 3784000)
adm.markerA = 0
adm.markerB = 15300000
adm.audioClearTracks()
adm.audioAddTrack(0)


Load TestFINAL.mkv in Avidemux, then open a text file containing the lines above via File --> Project Script --> Run Project, then save the resulting video in copy mode.

I was wrong telling you to delete the whole group of pictures at the end of each fragment video. Cutting away just the last one or two frames (and all the frames till the first I-frame of the next appended fragment) is enough. The problem was actually with the start of each fragment, not with the end.

ball2hi

Quote from: eumagga0x2a on November 09, 2016, 05:12:59 PM
Thank you for the samples, I clearly see the issue when playing the TestFINAL.mkv sample. It happens because the fragments don't start with a keyframe, which is causing the whole trouble. Next time please ensure you start the cut at a keyframe (I-frame) only.

You can still rescue the TestFINAL.mkv video with the following script, which deletes unusable parts of the video:
I don't need to rescue it, it's just a useless test video for me.

I skip through Avidemux using uparrow and downarrow, which selects the next/last keyframe. I have never had to cut outside of those key-frames before and this is all really new to me. I believe I am doing it the way you are now suggesting, but I am still having the same issue.

Here is the source video if you want to download it: http://www.mediafire.com/file/5zkjkmo31gq3w9k/%28Wednesday%29November+09%2C+2016+-+07%3B52AM.mkv

Like I said, I've never had this issue before.

eumagga0x2a

Thank you very much for the source video, I could reproduce the issue. It is Avidemux itself adding a few B-frames before the actual I-frame in copy mode. This is probably related to the changeset [editor] Try to not drop bframes that will be used later as reference (h264/h265 in copy mode). Experimental, that can cause problems from Jul 26, 2016.

This means, you are not doing anything wrong, but, unless a fix is found (or that changeset reverted, which will bring back issues it helped to solve in the first place), you will have to either cut away thouse few frames from the last frame of an already loaded video to the first I-frame of an appended video manually or give up saving interesting fragments as separate videos and just delete parts of the source video you don't need.

eumagga0x2a

It is not that simple, these "early" B-frames are legitimate (they are a valid feature of the codec). A cutout from Avidemux' console output:

[switchToSegment]  Switched ok to segment 4 (dontdecode=1)
  [checkCutsAreOnIntra]  seg:4 refDTS=0
  [checkCutsAreOnIntra]  seg:4 imgDTS=0
  [checkCutsAreOnIntra]  Segment 4 ok
  [setupVideo]  The video stream is a flavor of H264
  [setupVideo]  The muxer prefers MP4 style H264 bitstream
  [setupVideo]  Simple copy mode engaged
  [ADM_videoStreamCopy]  Creating copy video stream, start time=0,00 s
  [getPKFramePTS]  This video does not start at 0 but at 200 ms, compensating
  [getNonClosedGopDelay]  frame 1 is early
  [getNonClosedGopDelay]  frame 2 is early
  [getNonClosedGopDelay]  frame 3 is early
  [getNonClosedGopDelay]  Not a bframe, stopping (4)
  [getNonClosedGopDelay]  Found maximum non closed gop delay = 50000
  [ADM_videoStreamCopy]  Some B frames are non droppable, increasing delat by 50000 us
  [ADM_videoStreamCopy]  PTS/DTS delta=200000 us


Some logical error results in a big gap in presentation timestamps between the last frame of Test1.mkv and the first (early) frame of Test2.mkv. Apparently the firstFramePts is assumed to be equal the PTS of the first keyframe, from this point the things fall apart if early B-frames are present.

ball2hi

Since there is currently no easy fix nor is a change back possible due to issues it's fixed... is there a version you can recommend I can roll back to? I don't use many of the features of Avidemux and never had many problems with the older versions, just don't know which version to revert back to...

eumagga0x2a

I would not recommend going to anything prior to 2.6.14, but you could test if 2.6.12 or 2.6.13 can deal with your source videos better (please mind that 2.6.13 was shipped with all ffmpeg based encoders broken, but copy mode should work).

ball2hi

Where can I find older builds by the way? I can only find 2.6.14 builds.