Problem with x265 videos

[JohnDoe-JohnDoe]

Hi,

I've been using Lossless Cut very successfully on many x264 videos but I'm having trouble with x265 files.
The resulting videos have issues at the point of edit/merging.
The image will quickly flash/jump back and forth between the two combined sections for around 2 seconds, then resume normal playback. I have tried all the combinations in the FAQ "The exported video has a problem" with no real improvement. The only difference is that if I use MKV, the video has a 2 second pause instead.

Strangely, if I use a different FFMPEG based editor (Vidcutter), it does a better job, usually no problem or just one corrupt frame before continuing normal playback, only occasionally having the flashing/jumping problem (if that happens I just move the edit point slightly & try again). If this program can do it I would have thought Lossless Cut should be able to.

Is there something I can try to improve the result?

(Just to be clear, I'm using it to shorten long videos, not merge different videos)

Thanks

[mifi]

hi. you tried also different avoid_negative_ts settings? and does the problem only show after merging, or do you also see this problem if you export as individual files and try to play them back individually?

[JohnDoe-JohnDoe]

Thanks for the reply, yes I have tried changing the avoid_negative_ts settings. I think I've tried every combination of settings. I haven't tried exporting them as individual files so I will try that. I don't see how that would reproduce the problem as it wouldn't be able to jump between the frames of the two sections when there is only one section but I will try anyway to see what happens.
Thanks

[mifi]

where did you get the files from? does it happen to all h265 files or only those from a particular source (e.g. camera)? is it possible to share some short files that demonstrate this behaviour?

[JohnDoe-JohnDoe]

Apologies for the delay in replying. I have been doing more experimenting.
Individual exported files before merging play fine.
Yes they are all from the same source. One thing I have noticed is that the keyframes are 10s apart which seems quite large compared to the x264 files I used to edit.
I have at least figured out why Vidcutter had better results. As I was using the keyframe cut mode, I selected the beginning and ending of the segments to be on keyframes. I didn't realise that only the start had to be a keyframe. When I changed the endings to random frames, the resulting merge was ok 4 out of 5 times. If it's not, I just move the ending slightly and it usually works. (Vidcutter doesn't (easily) show keyframes so was always random, hence better results).

From my experiments so far, if preceding segment ends on a keyframe there is a 3 out 4 chance the merge will not play smoothly. Moving the edit point to 2s before the keyframe and it changes to only 1 out of 5. If I import the exact edit points into Vidcutter I get the same results so I assume the rest of the problem is with FFMPEG.

[mifi]

Interesting observation, thanks for sharing.

[JohnDoe-JohnDoe]

After trying Avimux, I get similar results but it complains about "non-IDR keyframes" which I believe is the problem, looks like most x265 videos are encoded this way. After some more googling it seems others have the same issue and just keep trying different cut points until they get it to work. This can be very time consuming.
There must be a better way. Is is possible to detect which cut points will work with non-IDR? Or a way to automatically test the selected cut points and adjust, until it finds a working frame?

[mifi]

Which player are you using when playing back and seeing flash/jumps for 2 sec? is it VLC or some other player that uses libavcodec by chance? I suspect that it's this issue:

• https://avidemux.org/smif/index.php/topic,19284.msg90017.html#msg90017
• https://avidemux.org/smif/index.php?topic=18800.0

It seems that libavcodec handles POC-jumps (caused by cutting at non-IDR keyframes) differently from most other players. Most other players will just discard this POC-jump but libavcodec will parse it, causing playback problems. I guess losslesscut could detect this and warn, but I don't know how to detect it.

looks like most x265 videos are encoded this way

in the links above it seems that it's not that common, but live streams are often encoded like that in order to smoothen the bitrate. However in this post, someone says that non-IDR keyframes are very common and actually the default output for x265. 🤷‍♂️

[JohnDoe-JohnDoe]

I have tried several players but all don't play smoothly over the edits, including whatever player Lossless-cut uses. My default players are VLC in windows & totem in Ubuntu.
There must be a way to improve this. My thoughts are that as some edits work fine, there must be a way of figuring out what points will work in advance, surely there must be something in the video that can be detected as a good cut point. If that's not possible then have a way to test the edit without saving the whole video and looking for the edits (very slow in a long video with many edits ), even better it could test the results automatically and move the edits points until fixed. Or even re-encode the small section around the edit to make it compatible?

[mifi]

It sounds like you tested players on linux. and i believe most players on linux are based on libavcodec so that makes sense. The problem is I don't know how to identify such "non-IDR keyframes". If there's a way to find these frames using ffprobe, then we could do something

[JohnDoe-JohnDoe]

The editing and testing is done on Windows 10 & VLC. Viewing afterwards is often on Linux. All players have very similar results.
If there is a way of finding them using ffprobe or otherwise, then that would be great.
What I don't understand is why changing the end point of the edit (of the previous section) fixes it? I would understand if changing the start point of the new section helped but that usually doesn't make a difference. Makes me wonder if there might be another approach to improving this, like inserting a few blank frames or new keyframe in between the edits, a few milliseconds of blank screen would be far better than 2 seconds of jumping images.
As this appears to be an issue with the way ffmpeg handles it, maybe it needs reporting to them?

[JohnDoe-JohnDoe]

I have still been trying to find a way to cut non-IDR key frame videos. Talking to an ID chatbot seems to think it is possible by recreating "true" keyframes at the cut point. Is this possible?
The complete chat is at https://www.perplexity.ai/search/is-there-a-losses-video-editor-aNXYOipDR5iO0lGHBF0Iqg
Summary is :
Only the GOP around the cut needs to be rewritten; the rest can be copied losslessly.
The main challenge is the lack of tools that automate this with full reliability for all codecs and containers.
If you’re technically inclined, you can script this process with ffmpeg and some manual work.
If a tool existed that did this seamlessly, it would be the holy grail of lossless, frame-accurate video editing!

It does seem that the "Re-encode only GOP", while technically complex, tools like ffmpeg has the capabilities so it is just a matter of creating a script, the majority of which will already have been written for "smart-cut"

You are correct: ffmpeg and similar tools already provide the technical building blocks needed for this kind of "re-encode only GOP" smart editing workflow-it’s largely a matter of scripting and careful stream handling, as you described.
How This Works in Practice

Theory:
You split the video at the desired cut point, re-encode just the affected GOP (to create a new IDR frame at the cut), and then concatenate the untouched rest of the video. This minimizes re-encoding and preserves quality everywhere else

ffmpeg Capabilities:
ffmpeg can:

Copy streams losslessly (-c copy) for segments that don’t need changes

Re-encode only the necessary part (the GOP containing the cut) using matching encoding settings

Concatenate the resulting segments back together

Community Experience:
Users have successfully scripted this process for H.264 and similar codecs. The workflow typically involves:

Splitting the source file into GOP-aligned segments (using the segment muxer or manual analysis).

Re-encoding just the segment that needs a new keyframe (ensuring encoding settings match the original).

Concatenating the untouched and re-encoded segments back together (using ffmpeg’s concat demuxer or similar)

   “This is possible to do, in theory. The key is to match all relevant source bitstream properties when encoding. … Re-encode just these frames to a new short GOP, copy all remaining GOPs losslessly.”

    [video.stackexchange.com]

Why Isn’t This Mainstream Yet?

Complexity:
Automating this reliably for all codecs, containers, and edge cases is nontrivial. It requires careful handling of timestamps, audio sync, and matching encoding parameters

 No One-Click Tool:
While the core functionality exists, most consumer editors don’t expose this as a simple feature. It’s usually a manual or semi-scripted workflow.

Sample Workflow Outline

Split video into GOPs:
Use ffmpeg’s segment muxer with a very low segment time, or analyze keyframe positions.

Re-encode the affected segment:
Use ffmpeg to re-encode only the segment containing the cut, forcing an IDR frame at the desired point.

Concatenate segments:
Use ffmpeg’s concat demuxer to join the untouched and re-encoded segments into a single file.

Conclusion

Yes, it is possible-and ffmpeg has the capabilities.
With a well-designed script, you can automate "smart-cut" editing that only re-encodes the necessary GOP(s), leaving the rest of the video untouched and lossless

This approach is already proven in the community, and most of the groundwork is laid by existing "smart-cut" logic; it just needs to be tailored for your workflow.

If you’d like, I can help sketch out a sample script or step-by-step process for your use case.

[RovoMe]

While I have basically the same issue with HVEC/h.265 which results in either freezes around cut points during video playback or a black video when the experimental smart-cut feature is enabled (v3.64.0 via Windows AppStore), I by far didn't dig that deep yet into what actually is causing the videos to either freeze around cuts for 2-3 seconds when neither key frame nor smart cuts are enabled or produce a completely black screen when smart cuts are enabled. For key-frame cuts unfortunately either unwanted stuff is added to the video or parts that should be in are cut away, due to the app only looking at key frames. I basically tested these with the same 3-4 movies over and over again with various settings.

Note, I see those freezes or generated artifacts also in single exported segments. Within the LosslessCut editor the video though plays fine.

I did cut and render the same videos with BandiCut and these videos all worked fine then, even with precise cuts in-between key-frames. I'm not sure what BandiCut does differently here or what it uses internally, All I know is that as long as the non high-speed export mode is used, those videos all render fine. With the high-speed mode BandiCut basically falls back into key-frame cuts and therefore leaves unwanted footage in the output like LosslessCut does with its key-frame cut enabled.

[JohnDoe-JohnDoe]

I haven't used Bandicut but from the website:
"With [High-Speed mode], you can quickly cut/merge videos without converting (encoding) them and without decreasing the quality.
With [Encoding mode], you can convert (encode) videos according to your configuration (codec and quality) but the process takes some time"

So if you aren't using High-Speed mode, it's doing a full re-encode and isn't lossless. This would explain why the cuts are rendered correctly, as they are on most editors that re-encoded.

[Alexander-Serov]

For those coming here like me to look for an easy solution when the exact start/end frames do not matter, for me the following has provided an acceptable solution. Once you mark up a segment, go to Segments --> Align Segment Time to Keyframes (you can even set up a hotkey for that). After a small shift, my H.265 video exported and played without any problem.

By the way, in the menu popping up, the option that might be useful but is currently missing is to expand the segment to keyframes, i.e. shift the start to the previous one and the end to the next one.