keyframes only created every keyint frames with 10 bits

[Gerhard Bogner]

When encoding any 10 bit video with the current stable branch (and ffmpeg) keyframes seem to be created exactly every keyint frames, regardless of min-keyint.

The command line i used (for yuv420p10le in yuv4mpegpipe on stdin) was:

ffmpeg -hide_banner -i - -c:v libx265 -preset slower -x265-params aq_mode=3:crf=22:keyint=480:min-keyint=24:nr-intra=125:nr-inter=125:rc-lookahead=48 -movflags frag_keyframe out.mp4

The parameters seem to be passed correctly:

... x265 [info]: Keyframe min / max / scenecut : 24 / 480 / 40 ...

[Deepthi Nandakumar]

The min-keyint parameter only specifies the minimum distance between 2 I-frames.

If no scenecuts are detected by x265 lookahead, then I frames will be inserted every keyint-max period.

[Gerhard Bogner]

I know, and more keyframes are inserted when encoding to 8 bits and otherwise using the same arguments. However x265 with 8 bits doesn't detect all actual scene changes (above min-keyint) or even as many as x264 (using default arguments) either.

The clip I noticed this on was the "previously on" for a tv show in a DVB-S transport stream, with scenecuts roughly every 3 seconds.

[Deepthi Nandakumar]

Ah, ok - the 10-bit part sounds like a bug.

The cost of encoding a P-frame is much lesser in HEVC than in H.264 (versus an I-frame). That could make x265 more conservative when inserting I-frames.

[Gerhard Bogner]

That seems to be correct, the few I-frames in the 10 bit encode are also keyframes. They are however not on actual scenecuts...

[Gerhard Bogner]

I encoded 2 minutes of another video for testing, here's a list of I-frames with x264 and x265 (in this case both 8 and 10 bit). generated using 'ffprobe -hide_banner -show_frames -pretty om.mp4 | grep "pkt_dts_time|pict_type" | grep -B 1 =I'.

x264 (most of the I-Frames are also keyframes and scenecuts):

pkt_dts_time=0:00:00.080000 pict_type=I -- pkt_dts_time=0:00:01.800000 pict_type=I -- pkt_dts_time=0:00:02.440000 pict_type=I -- pkt_dts_time=0:00:03.840000 pict_type=I -- pkt_dts_time=0:00:05.880000 pict_type=I -- pkt_dts_time=0:00:07.520000 pict_type=I -- pkt_dts_time=0:00:10.920000 pict_type=I -- pkt_dts_time=0:00:11.840000 pict_type=I -- pkt_dts_time=0:00:12.800000 pict_type=I -- pkt_dts_time=0:00:14.440000 pict_type=I -- pkt_dts_time=0:00:17.040000 pict_type=I -- pkt_dts_time=0:00:18.280000 pict_type=I -- pkt_dts_time=0:00:19.400000 pict_type=I -- pkt_dts_time=0:00:20.880000 pict_type=I -- pkt_dts_time=0:00:21.760000 pict_type=I -- pkt_dts_time=0:00:24.920000 pict_type=I -- pkt_dts_time=0:00:27.200000 pict_type=I -- pkt_dts_time=0:00:28.000000 pict_type=I -- pkt_dts_time=0:00:29.880000 pict_type=I -- pkt_dts_time=0:00:30.720000 pict_type=I -- pkt_dts_time=0:00:39.880000 pict_type=I -- pkt_dts_time=0:00:40.400000 pict_type=I -- pkt_dts_time=0:00:42.760000 pict_type=I -- pkt_dts_time=0:00:44.320000 pict_type=I -- pkt_dts_time=0:00:45.640000 pict_type=I -- pkt_dts_time=0:00:46.320000 pict_type=I -- pkt_dts_time=0:00:46.840000 pict_type=I -- pkt_dts_time=0:00:48.320000 pict_type=I -- pkt_dts_time=0:00:49.440000 pict_type=I -- pkt_dts_time=0:00:50.800000 pict_type=I -- pkt_dts_time=0:00:51.800000 pict_type=I -- pkt_dts_time=0:00:57.800000 pict_type=I -- pkt_dts_time=0:00:58.800000 pict_type=I -- pkt_dts_time=0:01:00.920000 pict_type=I -- pkt_dts_time=0:01:03.240000 pict_type=I -- pkt_dts_time=0:01:03.760000 pict_type=I -- pkt_dts_time=0:01:05.480000 pict_type=I -- pkt_dts_time=0:01:08.880000 pict_type=I -- pkt_dts_time=0:01:10.640000 pict_type=I -- pkt_dts_time=0:01:18.800000 pict_type=I -- pkt_dts_time=0:01:21.680000 pict_type=I -- pkt_dts_time=0:01:25.840000 pict_type=I -- pkt_dts_time=0:01:26.680000 pict_type=I -- pkt_dts_time=0:01:28.040000 pict_type=I -- pkt_dts_time=0:01:29.240000 pict_type=I -- pkt_dts_time=0:01:30.080000 pict_type=I -- pkt_dts_time=0:01:30.440000 pict_type=I -- pkt_dts_time=0:01:30.880000 pict_type=I -- pkt_dts_time=0:01:33.320000 pict_type=I -- pkt_dts_time=0:01:36.760000 pict_type=I -- pkt_dts_time=0:01:37.720000 pict_type=I -- pkt_dts_time=0:01:41.920000 pict_type=I -- pkt_dts_time=0:01:43.480000 pict_type=I -- pkt_dts_time=0:01:44.400000 pict_type=I -- pkt_dts_time=0:01:45.680000 pict_type=I -- pkt_dts_time=0:01:47.320000 pict_type=I -- pkt_dts_time=0:01:49.840000 pict_type=I -- pkt_dts_time=0:01:52.920000 pict_type=I -- pkt_dts_time=0:01:54.760000 pict_type=I -- pkt_dts_time=0:01:57.360000 pict_type=I

x265 (every 10 sec or 250 frames - equals keyint):

pkt_dts_time=0:00:00.080000 pict_type=I -- pkt_dts_time=0:00:10.080000 pict_type=I -- pkt_dts_time=0:00:20.080000 pict_type=I -- pkt_dts_time=0:00:30.080000 pict_type=I -- pkt_dts_time=0:00:40.080000 pict_type=I -- pkt_dts_time=0:00:50.080000 pict_type=I -- pkt_dts_time=0:01:00.080000 pict_type=I -- pkt_dts_time=0:01:10.080000 pict_type=I -- pkt_dts_time=0:01:20.080000 pict_type=I -- pkt_dts_time=0:01:30.080000 pict_type=I -- pkt_dts_time=0:01:40.080000 pict_type=I -- pkt_dts_time=0:01:50.080000 pict_type=I

[Deepthi Nandakumar]

We're on this high priority - expect this to be fixed in the next day or two.

[Gerhard Bogner]

I haven't had time to properly try out commit a850117 yet, but in a quick test I can confirm keyframes being added on actual scenecuts and more often than keyint frames. There still appear to be lots scene changes that aren't marked as key- or I-frame (in the "previously on...").

[Gerhard Bogner]

After encoding around 2 minutes of video I haven't seen any I-frame that wasn't also keyframes (though that might be by design), and some keyframes (after keyint frames) that weren't on scenecuts where scene changes shortly before were apparently not detected.

[Former user]

I faced something similar. In 8 bit. In version 1.7, the scene-cut is much different from 1.6. I encoded the same sample using 1.6 and 1.7. In 1.6, the keyframes are there in proper positions. In 1.7, they are in insane positions, in the middle of the scenes… And the whole video looks low quality compared to 1.6 :/

[Gerhard Bogner]

When I tested it with 8 bits i got more I/keyframes, but it might have been a different encoder version than i used for 10 bit since it came from the Linux distribution, while the other was compiled from source. I'll test the same clip again with a newly compiled 8/10 bit multilib x265.

[Deepthi Nandakumar]

Thanks, this issue actually exists for both 8bpp and 10bpp. We're close to a fix here.

[Gerhard Bogner]

Thanks, good to know. Since I already finished the test (with the latest episode) I might as well post the result anyways:

x265 1.7+447-a85011719ea18128 8 bit:

pkt_dts_time=0:00:00.104958 pict_type=I -- pkt_dts_time=0:00:00.188375 pict_type=I -- pkt_dts_time=0:00:09.948125 pict_type=I -- pkt_dts_time=0:00:10.448625 pict_type=I -- pkt_dts_time=0:00:29.968125 pict_type=I -- pkt_dts_time=0:00:40.186667 pict_type=I -- pkt_dts_time=0:00:45.483625 pict_type=I -- pkt_dts_time=0:00:46.276083 pict_type=I -- pkt_dts_time=0:01:05.503625 pict_type=I -- pkt_dts_time=0:01:25.523625 pict_type=I -- pkt_dts_time=0:01:45.543625 pict_type=I -- pkt_dts_time=0:01:47.086833 pict_type=I

x265 1.7+447-a85011719ea18128 10 bit:

pkt_dts_time=0:00:00.104958 pict_type=I -- pkt_dts_time=0:00:09.948125 pict_type=I -- pkt_dts_time=0:00:21.835000 pict_type=I -- pkt_dts_time=0:00:40.186667 pict_type=I -- pkt_dts_time=0:00:45.483625 pict_type=I -- pkt_dts_time=0:00:46.276083 pict_type=I -- pkt_dts_time=0:01:05.503625 pict_type=I -- pkt_dts_time=0:01:25.523625 pict_type=I -- pkt_dts_time=0:01:28.985417 pict_type=I -- pkt_dts_time=0:01:47.170250 pict_type=I

x264 core 148 r2579 73ae2d1 (2 frames offset cause encoded without audio):

pkt_dts_time=0:00:00.000000 pict_type=I -- pkt_dts_time=0:00:00.083417 pict_type=I -- pkt_dts_time=0:00:08.508500 pict_type=I -- pkt_dts_time=0:00:10.385375 pict_type=I -- pkt_dts_time=0:00:13.054708 pict_type=I -- pkt_dts_time=0:00:16.766750 pict_type=I -- pkt_dts_time=0:00:23.481792 pict_type=I -- pkt_dts_time=0:00:24.733042 pict_type=I -- pkt_dts_time=0:00:26.317958 pict_type=I -- pkt_dts_time=0:00:29.738042 pict_type=I -- pkt_dts_time=0:00:33.825458 pict_type=I -- pkt_dts_time=0:00:44.210833 pict_type=I -- pkt_dts_time=0:00:54.179125 pict_type=I -- pkt_dts_time=0:01:04.606208 pict_type=I -- pkt_dts_time=0:01:04.981583 pict_type=I -- pkt_dts_time=0:01:06.274542 pict_type=I -- pkt_dts_time=0:01:12.197125 pict_type=I -- pkt_dts_time=0:01:13.573500 pict_type=I -- pkt_dts_time=0:01:18.870458 pict_type=I -- pkt_dts_time=0:01:25.710625 pict_type=I -- pkt_dts_time=0:01:27.587500 pict_type=I -- pkt_dts_time=0:01:29.798042 pict_type=I -- pkt_dts_time=0:01:31.299542 pict_type=I -- pkt_dts_time=0:01:34.511083 pict_type=I -- pkt_dts_time=0:01:38.181417 pict_type=I -- pkt_dts_time=0:01:40.183417 pict_type=I -- pkt_dts_time=0:01:43.436667 pict_type=I -- pkt_dts_time=0:01:51.861750 pict_type=I -- pkt_dts_time=0:01:56.074292 pict_type=I

[Deepthi Nandakumar]

Fixed, pushed and tagged 1.8. Please confirm all's good.

[Gerhard Bogner]

As far as I can tell I-frames are now properly inserted at scenecuts, and despite the extra I-frames the new encode is only 0.4% larger.

x265 1.8+1-5dcc9d3a928c400b 10 bit:

pkt_dts_time=0:00:00.104958 pict_type=I -- pkt_dts_time=0:00:00.188375 pict_type=I -- pkt_dts_time=0:00:02.524042 pict_type=I -- pkt_dts_time=0:00:03.316500 pict_type=I -- pkt_dts_time=0:00:05.360208 pict_type=I -- pkt_dts_time=0:00:08.613458 pict_type=I -- pkt_dts_time=0:00:09.239083 pict_type=I -- pkt_dts_time=0:00:09.948125 pict_type=I -- pkt_dts_time=0:00:10.990833 pict_type=I -- pkt_dts_time=0:00:13.159667 pict_type=I -- pkt_dts_time=0:00:15.453625 pict_type=I -- pkt_dts_time=0:00:21.835000 pict_type=I -- pkt_dts_time=0:00:23.586750 pict_type=I -- pkt_dts_time=0:00:24.838000 pict_type=I -- pkt_dts_time=0:00:26.422917 pict_type=I -- pkt_dts_time=0:00:29.843000 pict_type=I -- pkt_dts_time=0:00:32.428917 pict_type=I -- pkt_dts_time=0:00:33.930417 pict_type=I -- pkt_dts_time=0:00:36.140958 pict_type=I -- pkt_dts_time=0:00:38.685167 pict_type=I -- pkt_dts_time=0:00:39.227375 pict_type=I -- pkt_dts_time=0:00:40.019833 pict_type=I -- pkt_dts_time=0:00:40.186667 pict_type=I -- pkt_dts_time=0:00:41.062542 pict_type=I -- pkt_dts_time=0:00:41.980125 pict_type=I -- pkt_dts_time=0:00:43.147958 pict_type=I -- pkt_dts_time=0:00:45.483625 pict_type=I -- pkt_dts_time=0:00:46.276083 pict_type=I -- pkt_dts_time=0:00:47.277083 pict_type=I -- pkt_dts_time=0:00:54.284083 pict_type=I -- pkt_dts_time=0:01:02.917708 pict_type=I -- pkt_dts_time=0:01:05.086542 pict_type=I -- pkt_dts_time=0:01:06.379500 pict_type=I -- pkt_dts_time=0:01:08.548333 pict_type=I -- pkt_dts_time=0:01:09.257375 pict_type=I -- pkt_dts_time=0:01:10.300083 pict_type=I -- pkt_dts_time=0:01:12.302083 pict_type=I -- pkt_dts_time=0:01:13.678458 pict_type=I -- pkt_dts_time=0:01:15.680458 pict_type=I -- pkt_dts_time=0:01:18.975417 pict_type=I -- pkt_dts_time=0:01:25.815583 pict_type=I -- pkt_dts_time=0:01:27.692458 pict_type=I -- pkt_dts_time=0:01:28.985417 pict_type=I -- pkt_dts_time=0:01:29.903000 pict_type=I -- pkt_dts_time=0:01:31.404500 pict_type=I -- pkt_dts_time=0:01:34.616042 pict_type=I -- pkt_dts_time=0:01:35.950708 pict_type=I -- pkt_dts_time=0:01:38.286375 pict_type=I -- pkt_dts_time=0:01:43.541625 pict_type=I -- pkt_dts_time=0:01:45.752167 pict_type=I -- pkt_dts_time=0:01:47.170250 pict_type=I -- pkt_dts_time=0:01:48.546625 pict_type=I -- pkt_dts_time=0:01:49.714458 pict_type=I -- pkt_dts_time=0:01:50.465208 pict_type=I -- pkt_dts_time=0:01:51.966708 pict_type=I -- pkt_dts_time=0:01:53.843583 pict_type=I -- pkt_dts_time=0:01:56.179250 pict_type=I

[Gerhard Bogner]

I went through all the I-frames in the clip an can report almost all of them are on scenecuts. One was in the middle of a pan, one was during a flash and two I could see were before/after fades. Some scenecuts don't have I-frames, but all but 2 of them appear to switch back to earlier scenes that could still have frames in the DPB. The remaining 2 were between relatively dark scenes. As far as I can tell the bug was resolved.

Finally here's the list of I-frames generated by the 8 bit encoder - 1.8+1-5dcc9d3a928c400b 8 bit:

pkt_dts_time=0:00:00.104958 pict_type=I -- pkt_dts_time=0:00:00.188375 pict_type=I -- pkt_dts_time=0:00:02.315500 pict_type=I -- pkt_dts_time=0:00:03.316500 pict_type=I -- pkt_dts_time=0:00:05.360208 pict_type=I -- pkt_dts_time=0:00:08.613458 pict_type=I -- pkt_dts_time=0:00:09.239083 pict_type=I -- pkt_dts_time=0:00:09.948125 pict_type=I -- pkt_dts_time=0:00:10.448625 pict_type=I -- pkt_dts_time=0:00:10.990833 pict_type=I -- pkt_dts_time=0:00:13.159667 pict_type=I -- pkt_dts_time=0:00:15.453625 pict_type=I -- pkt_dts_time=0:00:22.126958 pict_type=I -- pkt_dts_time=0:00:24.838000 pict_type=I -- pkt_dts_time=0:00:26.422917 pict_type=I -- pkt_dts_time=0:00:29.843000 pict_type=I -- pkt_dts_time=0:00:32.428917 pict_type=I -- pkt_dts_time=0:00:33.930417 pict_type=I -- pkt_dts_time=0:00:36.140958 pict_type=I -- pkt_dts_time=0:00:38.017833 pict_type=I -- pkt_dts_time=0:00:39.227375 pict_type=I -- pkt_dts_time=0:00:40.019833 pict_type=I -- pkt_dts_time=0:00:40.186667 pict_type=I -- pkt_dts_time=0:00:41.062542 pict_type=I -- pkt_dts_time=0:00:41.980125 pict_type=I -- pkt_dts_time=0:00:43.147958 pict_type=I -- pkt_dts_time=0:00:45.483625 pict_type=I -- pkt_dts_time=0:00:46.276083 pict_type=I -- pkt_dts_time=0:00:47.277083 pict_type=I -- pkt_dts_time=0:00:54.284083 pict_type=I -- pkt_dts_time=0:01:02.917708 pict_type=I -- pkt_dts_time=0:01:05.086542 pict_type=I -- pkt_dts_time=0:01:06.379500 pict_type=I -- pkt_dts_time=0:01:08.548333 pict_type=I -- pkt_dts_time=0:01:09.257375 pict_type=I -- pkt_dts_time=0:01:12.302083 pict_type=I -- pkt_dts_time=0:01:13.678458 pict_type=I -- pkt_dts_time=0:01:15.680458 pict_type=I -- pkt_dts_time=0:01:18.975417 pict_type=I -- pkt_dts_time=0:01:21.352792 pict_type=I -- pkt_dts_time=0:01:25.815583 pict_type=I -- pkt_dts_time=0:01:28.985417 pict_type=I -- pkt_dts_time=0:01:29.903000 pict_type=I -- pkt_dts_time=0:01:31.404500 pict_type=I -- pkt_dts_time=0:01:34.616042 pict_type=I -- pkt_dts_time=0:01:35.950708 pict_type=I -- pkt_dts_time=0:01:38.286375 pict_type=I -- pkt_dts_time=0:01:43.541625 pict_type=I -- pkt_dts_time=0:01:45.752167 pict_type=I -- pkt_dts_time=0:01:47.086833 pict_type=I -- pkt_dts_time=0:01:48.546625 pict_type=I -- pkt_dts_time=0:01:49.714458 pict_type=I -- pkt_dts_time=0:01:50.465208 pict_type=I -- pkt_dts_time=0:01:51.966708 pict_type=I -- pkt_dts_time=0:01:53.843583 pict_type=I -- pkt_dts_time=0:01:56.179250 pict_type=I

[Gerhard Bogner]

Apart from a scenecut at 1:27.692458 that the 8 bit encoder missed the I-frames seem identical. (The 8 bit encode is 0.11% larger than the 10 bit encode.)

[Deepthi Nandakumar]

Right, so yeah, for some reason the calculated pcost was lesser. The new scenecut algorithm should enable better quality/ratecontrol at scene fade ins and fade outs, regardless of whether they were tagged as I frame or not.

Most of the time, x265 detects the first frame of a fade out as a scenecut/I frame. If this transitions into a new scene with fade-in, then the length of the fade will impact whether the first frame of the fade in is a scenecut.