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.
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.
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!
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.
>>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?)
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...?
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.
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)?
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.
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...
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
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.
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?
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.
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?
Quote from: mrtoad883 on December 16, 2020, 11:08:41 AMWith HEVC
No, with any codec. The only special thing regarding H.264 and HEVC is that the standard allows non-IDR frames to be keyframes and this feature is widely used (and even the default for x265 output).
Quote from: mrtoad883 on December 16, 2020, 11:08:41 AMavidemux can only cut on IDR frames without encoding
It can cut on non-IDR keyframes too, but with open GOP some artifacts due to missing reference pictures are often unavoidable.
Please note that starting output in copy mode on a non-IDR keyframe is fine. The problem strikes only when either deleting or pasting within a stream / appending to a stream with cut points placed on non-IDR keyframes.
Quote from: mrtoad883 on December 16, 2020, 11:08:41 AMIs there a way to know where an IDR frame is?
Avidemux actually detects the exact type when checking cut points. It is pretty much pointless to communicate it via GUI beforehand as in many streams captured e.g. from broadcasts, you won't encounter even a single IDR frame.
If you wonder why broadcasters are doing such a cruel thing, the purpose is to reduce bitrate fluctuations while using a bandwidth-constrained medium. You can imagine this as spreading an I-frame over multiple frames, some intra-coded macroblocks in each. An IDR frame has to consist only of intra-coded macroblocks, resulting in a huge bitrate spike or restricting quality.
Thank you so much for the info, I guess I should've been more specific that I am cutting and appending a video and I need to do it on a closed GOP in order for it not to artifact/get all glitchy. As long as I cut and append on a closed GOP it should be ok?
Just in case: are you aware that Avidemux can copy to internal clipboard and paste from it, not just delete ("cut" = "copy to clipboard" + "delete" in one go)? Sometimes people start fiddling with cutting, saving and appending while the only thing they need is copy & paste.
Do you create (including encoder settings!) videos you append yourself or are they given, out of your control?
If the former, you should disable "Open GOP" in x265 settings, of course (this is the default in latest Avidemux nightlies). You must ensure encoder settings for all videos you are going to append in order to save in copy mode are exactly identical.
If the latter, all that complexity is irrelevant if you re-encode the output instead of using the copy mode.
Quote from: mrtoad883 on December 16, 2020, 10:48:55 PMAs long as I cut and append on a closed GOP it should be ok?
Given that codec settings used to create all appended videos are identical, you should be indeed fine if you cut on IDR frames. Keyframes will be IDR frames if "Open GOP" mode has not been used when creating the source.
I did not encode the video myself here unfortunately, but this is the mediainfo for one of the two videos (i assume the other one is encoding the same since its from the same person):
Writing library : x265 3.2.1+1-b5c86a64bbbe:[Mac OS X][clang 11.0.3][64 bit] 10bit
Encoding settings : cpuid=1049583 / frame-threads=4 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=3840x2160 / interlace=0 / total-frames=0 / level-idc=51 / high-tier=1 / uhd-bd=0 / ref=4 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=24 / keyint=240 / gop-lookahead=0 / bframes=8 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=25 / lookahead-slices=4 / scenecut=40 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=2 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=3 / limit-modes / me=3 / subme=3 / merange=57 / temporal-mvp / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / no-sao / no-sao-non-deblock / rd=4 / selective-sao=0 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=1.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=15.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / vbv-maxrate=160000 / vbv-bufsize=160000 / vbv-init=0.9 / crf-max=0.0 / crf-min=0.0 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=1 / transfer=1 / colormatrix=1 / chromaloc=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00
not sure if you will be able to tell from this if I can still cut and append on idr frames or not
The stream is encoded with Open GOP enabled (else the settings would contain an entry "no-open-gop"). If the stream hasn't been cut since its creation, the first frame must be an IDR, so that append should be possible when you keep the first GOP of the appended video, even if you save in copy mode.
If you need more freedom for editing, you'll have to re-encode, which will result in loss of bit depth as Avidemux' internal pixel format is YV12 (8-bit planar with 1/4 resolution for chroma).
Quote from: mrtoad883 on December 17, 2020, 02:52:50 PMi assume the other one is encoding the same since its from the same person
Avidemux will warn if there is a mismatch and you are going to save in copy mode.
Quote from: eumagga0x2a on December 17, 2020, 07:48:09 PMIf the stream hasn't been cut since its creation, the first frame must be an IDR, so that append should be possible when you keep the first GOP of the appended video, even if you save in copy mode.
sorry that part is confusing to me. so only the first frame is an IDR, all the other i frames I wont be able to cut on even if they are closed GOP? there are plenty of i frames that are closed in by P frames on each side. for example lower case will be outside frames, capital will be frame im cutting on.
pIBBPBBBBPBBBBBPPibb
isn't that a closed group which means i should be able to cut on it and merge the other video and still be able to do copy mode?
I-frame followed in stream order by a B-frame = Open GOP. You got it right, the first one is an IDR and usually none thereafter.
So i wont be able to make multiple cuts throughout? youre saying theres only one IDR in the whole video?
Clean, artifact-less cuts – most likely not.
Quote from: mrtoad883 on December 18, 2020, 12:43:28 AMyoure saying theres only one IDR in the whole video?
Probably, yes.