Cut+append HEVC 10-bit introduces glitches, even at keyframes

[metal450]

For years, I've used avidemux to trim h264 video clips, then append those trimmed clips together.  As long as I always trim at keyframes (i.e. I use "go to next keyframe" to set my trim points), the resulting videos play smoothly.

However, if I try to do the same with HEVC 10-bit videos, it always introduces a section of glitchy/jumpy video right at the cut point.  Is this avoidable? Is there something unsupported about trimming & joining HEVC 10-bit?

I'm using 2.7.5 Final x64 on Windows.

Here's a sample video showing the issue: https://www.dropbox.com/s/fzbtdz9o833p9bx/avidemux-sample.mp4?dl=0

At ~3sec in, you can see the cut - and for a second or two after, the video is all garbled.

[eumagga0x2a]

2.7.5 release is very old, I just can't recommend the latest nightly at the moment as the good build from today (200606) got superceded by a bad one (the build env is being updated right now). In recent nightly builds the POC check, introduced during the 2.7.4 development cycle for H.264 only, was extended to HEVC, so that users get warned when a cut is going to result in POC (picture order count, a value embedded into H.264 and HEVC slice headers) going back in an unexpected way. The check allows to avoid especially bad breakage by prompting the user to choose a different cut point.

Your sample is badly damaged due to POC irregularity, which newer Avidemux builds would have warned about.

The problem is not specific to HEVC, but to the way the encoder, which generated the video, was configured. Most broadcasters use nowadays streams almost completely without IDR (instantaneous decoder refresh) frames. Clean cuts are possible only at IDR frames which guarantee that no later frame may depend on any frame before the IDR.

Frames used just for direct access during navigation (which Avidemux also calls "I-Frames") do not have this quality as later frames may reference pictures preceding the keyframe. As result, there are almost always areas at the cut, which end up separated from their "family members" and thus exhibit block artifacts.

[metal450]

Thanks for all the details!

>>The problem is not specific to HEVC, but to the way the encoder, which generated the video, was configured.

I actually encoded the video myself; it came from h264 (out of a digital camera), which I re-encoded to HEVC using ffmpeg, with params:

-c:v libx265 -preset medium -x265-params crf=20:keyint=30 -c:a copy -pix_fmt yuv420p10le -map_metadata 0

So then I guess a better question would be: how would I need to change these encoding options to permit cutting?  Basically, I'm able to cut & append the original videos just fine; it's only the re-encoded ones that display this behavior.  That forces me to have a workflow of doing all my trimming before doing any of my compressing, but it would be much more convenient if I could compress then trim.  Thus, if it's my *encoding* that causes the issue...perhaps it would be solved by a tweak to the ffmpeg arguments used to encode them?

Thanks again!

[eumagga0x2a]

libx265 defaults to open GOP. Disable it (--no-open-gop with x265 on command line). I would still recommend to use the latest Avidemux nightly, just wait a day or two until things settle down (or build yourself from source).

By the way, keint=30 is extremely short and without open GOP it would result in a huge file.

[metal450]

>>Disable it (--no-open-gop with x265 on command line).

So just to clarify the ramifications of this: the default, "open gop," is what causes this issue when cutting at keyframes, and setting it to "closed gop" would fix this.  The (only?) negative ramification is worse compression - aka larger filesize?  So the choice is solely between balancing the desire to be able to cut "cleanly," or having better compression?

>>By the way, keint=30 is extremely short and without open GOP it would result in a huge file.

Thanks for the tip. I added keyint=30 because I observed that the recompressed videos were noticeably slower to seek than the source video.  So as I'll be changing to Closed GOP now, what would you suggest for keyint (or just leave it off & let x265 use its default?)

[metal450]

Some notes:

* The param I actually had to use was open-gop=0 (vs --no-open-gop)
* For anyone else reading / learning from this, here's an extremely clear explanation of GOPs & the various types of frames: https://video.stackexchange.com/questions/24680/what-is-keyint-and-min-keyint-and-no-scenecut , and here's a great deep-dive on GOPs: https://streaminglearningcenter.com/articles/open-and-closed-gops-all-you-need-to-know.html

Also, to add to my previous question, I did some test encodes & I was surprised at the small difference between not specifying keyint (MediaInfo says the default is 250, or at 30fps, roughly every 8sec) and 30 (every second).  The filesize barely grew by 5%. You mentioned 30 is extremely short & would result in a huge file - would you have expected to see more of a difference than I'm observing...?

[eumagga0x2a]

Yes, I would expect a much bigger impact from increasing the number of full (intra-coded) frames.

The nightly builds from June 6, avidemux_r200606_win64Qt5_105.zip and the previous one, 104, are good (104 lacks just translation updates), you may want to use one of these builds rather than the outdated release for now.

[metal450]

The only negative ramification of Closed GOP is larger filesize (so the choice is solely between balancing the desire to be able to cut "cleanly," or having smaller files?)

With Closed GOP, what would you suggest as a reasonable keyint?

If you would've expected to see a much bigger difference...I wonder if it's reducing the visual quality to keep the filesize similar (aka rather than raising the filesize, it's lower the quality to compensate for the extra overhead of those keyframes)?

[eumagga0x2a]

I think, quality should be the last thing to sacrifice.

keyint should satisfy your need for seek granularity, so as high (well, I think 250 should be the upper limit) as possible, but as low as necessary.

Open GOP helps to reduce data rate spikes, which is important for broadcast over bandwidth-constrained medium. If the output file is meant to be always played from local storage, open GOP brings IMVHO no benefits but rather considerable penalties.

[metal450]

Gotcha, thanks.  I think I just got paranoid/concerned about quality because your previous reply expected a huge file with a keyint=30 - whereas what I saw wasn't huge at all, so I was worried that I was somehow sacrificing quality etc.  But if that's not the case, I don't really see any issue with 30, as it's great seek granularity and seems to be very little size overhead...

[mrtoad883]

I'm experiencing the same issue, can't seamlessly cut on I frames for hevc and copy from source. Was there ever a way to fix this? Using the current build 2.7.6

[eumagga0x2a]

By all means, please update to the latest 64-bit nightly available for your platform, substantial bugs affecting cut point checks in H.264 and HEVC streams were fixed post-release. Apart from getting correct warnings about especially bad cut points, the underlying problem is fundamental, inherent to the way such streams are created and not fixable or solvable.

[mrtoad883]

So I'm able to get that warning message that it may be corrupted. But still unable to cut on I frames on hevc x265 videos. Are you saying it's currently not possible to do in avidemux for this type of video file?

[eumagga0x2a]

Avidemux GUI doesn't differentiate between "I-frames" which are merely direct access frames for navigation and IDR frames, which reset decoding state. One cannot cut on non-IDR frames and expect clean results. All depends on the internal structure of the stream as created by its encoder. The problem is fundamental, not specific to Avidemux.

The warning about POC going back is a different story, related to peculiarities of H.264 and HEVC decoding in libavcodec, used by hugely popular players like VLC, adding another level of complexity.

[mrtoad883]

Ok so let me see if I'm following. With HEVC, avidemux can only cut on IDR frames without encoding, as opposed to I frames for everything else. Is there a way to know where an IDR frame is? Any program that can differentiate between IDR frames and I frames?