Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
21st August 2015, 22:34 | #1 | Link |
Registered User
Join Date: May 2015
Posts: 11
|
x265 Adaptive GOP - not really adaptive
Hi,
I am trying to investigate GoP size changes based on scene changes in video. i've used x265 to encode a y4m (raw) file to hevc bitstream. A standard fight scene : high moving, fast paced, 2-3 mins). So I was hoping to get highly varying scene changes. I used this command: ./x265 --input ../../../../ffmpeg_work/vids/originals/FightScene.y4m -F 0 -o FightScene_x265.bin --csv FightScene_x265.csv --csv-log-level 2 // -- more info -- y4m [info]: 312x176 fps 25/1 i420p8 frames 0 - 5104 of 5105 raw [info]: output file: FightScene_x265.bin x265 [info]: HEVC encoder version 1.7+431-f63273fa3137 x265 [info]: build info [Linux][GCC 4.8.4][64 bit] 8bit x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2 x265 [info]: Main profile, Level-2 (Main tier) x265 [info]: Thread pool created using 4 threads x265 [info]: frame threads / pool features : 2 / wpp(3 rows) x265 [info]: Coding QT: max CU size, min CU size : 64 / 8 x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2 x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 40 x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2 x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0 x265 [info]: References / ref-limit cu / depth : 3 / 0 / 0 x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1 x265 [info]: Rate Control / qCompress : CRF-28.0 / 0.60 x265 [info]: tools: rd=3 psy-rd=0.30 signhide tmvp strong-intra-smoothing x265 [info]: tools: deblock sao x265 [info]: frame I: 2, Avg QP:27.50 kb/s: 919.70 x265 [info]: frame P: 82, Avg QP:29.56 kb/s: 170.33 x265 [info]: frame B: 195, Avg QP:35.66 kb/s: 27.40 x265 [info]: Weighted P-Frames: Y:1.2% UV:1.2% x265 [info]: consecutive B-frames: 9.3% 18.6% 12.8% 44.2% 15.1% // --------- So very basic, using only the defaults. I then investgate the csv file, and check the I-SLICE to I-SLICE frame gap (I assume I-Slice --> I-Slice is a GOP) They all seem around 246 to 252 frames per GoP. I was hoping to get drastic GoP changes : e.g. GoP sizes 25, 36, 100 .. 250 etc. Any thoughts why the difference are so small ? Many thanks |
22nd August 2015, 22:07 | #2 | Link | |
Testeur de codecs
Join Date: May 2003
Location: France
Posts: 2,484
|
Quote:
2) High motion can be more efficient if you use PFrame vs IFrance. Scenecut for codec is by defition a very high change in the scene like ... like scene cut.
__________________
Le Sagittaire ... ;-) 1- Ateme AVC or x264 2- VP7 or RV10 only for anime 3- XviD, DivX or WMV9 Last edited by Sagittaire; 22nd August 2015 at 22:19. |
|
24th August 2015, 18:23 | #3 | Link |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
|
Also, a higher --rc-lookahead and/or a 2-pass encode might give you more variance, as it'll be able to find optimal IDR placements over a bigger window. High motion and faced paced content may not trigger a scene cut anyway if there is enough to predict from past frames. A new IDR will generally get triggered when there is barely anything useful to predict from the previous frames, like with a hard cut.
Your results suggest that with your content, it is most efficient to use the fewest IDRs as possible, and so x265 is putting them in as infrequently as your parameters allow. |
2nd September 2015, 22:07 | #4 | Link |
Registered User
Join Date: May 2015
Posts: 11
|
Thank you benwaggoner and Sagittaire for your replies.
Apparently the x265 decoder highly prefers putting in P-frames for scene-changes unless the end of a GoP is coming near. This is regardless of those parameter changes. Below is a related conversation I had on the x265 mailing list: https://mailman.videolan.org/piperma...st/009204.html But I will check if the two parameters you both have mentioned make any difference. What I hope to do is to, count multiple contiguous P-frames as start of a new GoP. The 'foreman' video actually has a good scene change at the end of the clip, maybe I will try with that and report back. |
3rd September 2015, 18:23 | #5 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
|
Quote:
And if you're just trying to get more IDR's in there, you can brute force by setting --scenecut to a value >>40. Also, setting --no-open-gop may help a bit as well (or hurt...) and also makes the actual GOPs easier to classify. Reducing --keyint will make sure you have an IDR at least that often as well, if there's a minimum number you want to hit. For your use case, you might want to set --rc-lookahead to the same value as --keyint, so the encoder sees the whole potential GOP when it is making its decision. Just remember, you're trying to detune the encoder to illustrate something, so your output isn't going to be as optimal or representative as if you had used defaults. |
|
15th September 2015, 21:05 | #6 | Link |
Registered User
Join Date: May 2015
Posts: 11
|
Hi benwaggoner,
What you have suggested made sense, so I tried it. I set : --rc-lookahead=8 --scenecut=10000 (>40) --min-keyint=8 --keyint=60 (max intra period) And still the same result. I-frame period fixed around 60 (max intra period) BUT, the debug from the encoder showed that scene-cuts were happing in between gops : e.g. : x265 [debug]: scene cut at 95 Icost:109995 Pcost:109344 ratio:0.0059 bias:639.4231 gop:35 (imb:553 pmb:17) So it seems that nothing will make it put an IDR/I-frame at a scene-change detection. It will always be a P-frame. If using a P-frame for scene change instead of an I-frame results in better coding efficiency (i.e. better compression) would it result it worse quality/PSNR when compared to using an I-frame at scene-changes ? Hence for scenarios where you need better quality instead of compression, using I-frames as scene-cuts are beneficial ? Many thanks Rosh |
Tags |
adaptive gop, gop size, x265 |
Thread Tools | Search this Thread |
Display Modes | |
|
|