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?