[x265] Issue #537: High bit cost and bit cost variation on duplicated frames (multicoreware/x265)

fauxreaper issues-reply at bitbucket.org
Fri Feb 28 21:57:04 CET 2020


New issue 537: High bit cost and bit cost variation on duplicated frames
https://bitbucket.org/multicoreware/x265/issues/537/high-bit-cost-and-bit-cost-variation-on

fauxreaper:

I don't know why x265 spends so many bits on duplicated frames with so much bit cost variation.  
  
Example:  
  
1\) Download wallpaper on https://wallpaperscraft.com/download...4996/1920x1080  
2\) Create avs with  
ImageSource\("planet\_clouds\_light\_star\_94996\_1920x1080.jpg",start=0,end=199,fps=23.976\)  
3\) Encode avs with x265 x64 10bit, crf 22, preset slow and --csv-log-level 2 --csv  
4\) Open csv and examine used bits  
  
https://i.imgur.com/vSwL4KQ.png  
  
Why frames with 100% skip 64x64 need to use more than one thousand bits? Why the bits variation on duplicated frames, shouldn't almost all of them have similar size in bits?  
  
x264 has much less variation on bitrate with same video. x64, 10bit, crf22.   
  
Even using framedup x265 exhibits erratic bit cost on duplicated frames. Testing with --ref 1, to decrease List 0, decrease variation but still have high bit cost. Same with testing with --bframes 0 to decrease List 1. Is there a problem with reference list generation and/or x265 rate-control? I think that, comparing to x264, x265 always tries to fill List 0, increasing bit cost.




More information about the x265-devel mailing list