[x264-devel] Clipping min-keyint

[BugMaster]

On Tue, 27 Sep 2016 19:04:37 -0700, Tom Vaughan wrote:
> Hi Bugmaster,
> There are many companies that use x264 and x265 in applications that require
> a fixed GOP length.  This can be for a variety of reasons, but typically it
> is either to comply with a system standard, or just to simplify adaptive
> bitrate streaming (all audio, video and metadata segments will be the same
> length, always).  Some of these users were puzzled as to why we forced them
> to disable scene cut detection in order to enable a fixed GOP length.  So
> we've made the change for x265, and we're developing a patch for x264 to do
> the same thing.

> So, what can scenecut do for you if you have a fixed GOP length?  Two
> things.  First, we know that inter-prediction isn't effective across scene
> boundaries.  So the last frame of a scene will not benefit from
> bi-prediction, and the first frame of a new scene will need to be coded with
> Intra prediction.  With scene detection working properly, x264 and x265 can
> make better frame/slice type decisions before and after the scene cut,
> choosing more optimal frame types and reference frames.  Second, I'm told by
> experts that you can code a frame with intra-coded blocks more efficiently
> if you encode it as an I frame (due to coding syntax).  So it's better to
> make the first frame of a new scene a non-IDR I frame instead of a large P
> frame.

> The way we specify a fixed GOP is simply to specify the same value for
> keyint and min-keyint.  These parameters are already in the API, and so no
> API change is needed.

> Optimizing slice types for all content is really key to encoding efficiency.
> We're doing what we can to optimize this in our lookahead, and we'll
> contribute any improvements back to x264.

> Tom

Hi Tom,
My internal testing of "min-keyint=keyint" vs "no-scenecut"
contradicts to such statements and instead of quality gain I was
getting quality hit with "min-keyint=keyint". That is at least with
sources I used and encoding settings with equal bitrates around --crf 18.
So without another testing results your statements are baseless or
even false.

Settings:

Non-fixed GOP (base):
--preset veryslow --psy-rd 0 --ssim --psnr --keyint 30

Fixed GOP "no-scenecut" (v0):
--preset veryslow --psy-rd 0 --ssim --psnr --keyint 30 --no-scenecut

Fixed GOP "min-keyint=keyint" (v1):
--preset veryslow --psy-rd 0 --ssim --psnr --keyint 30 --min-keyint 30

Fixed GOP "no-scenecut b-adapt=1" (v2):
--preset veryslow --psy-rd 0 --ssim --psnr --keyint 30 --no-scenecut --b-adapt 1

Fixed GOP "min-keyint=keyint b-adapt=1" (v3):
--preset veryslow --psy-rd 0 --ssim --psnr --keyint 30 --min-keyint 30 --b-adapt 1

Results:

azumanga (640x480):
     |    SSIM   |    APSNR   |    OPSNR  |
-------------------------------------------
base | 0.9983669 | 49.2820000 | 48.2990000|
v0   | 0.9982809 | 49.0514819 | 48.1124217|
v1   | 0.9982638 | 49.0267895 | 48.0302368|
v2   | 0.9982533 | 48.9990000 | 48.0300000|
v3   | 0.9982181 | 48.8677568 | 47.8401351|
-------------------------------------------

scherzo_inferna (1920x1080):
     |    SSIM   |    APSNR   |    OPSNR  |
-------------------------------------------
base | 0.9720802 | 42.4280000 | 41.9480000|
v0   | 0.9718534 | 42.3870713 | 41.8956372|
v1   | 0.9717174 | 42.3999341 | 41.8924678|
v2   | 0.9719181 | 42.3816765 | 41.8881952|
v3   | 0.9715764 | 42.4302790 | 41.8827348|
-------------------------------------------

SourceCode (768x432):
     |    SSIM   |    APSNR   |    OPSNR  |
-------------------------------------------
base | 0.9837157 | 47.1410000 | 45.3310000|
v0   | 0.9836656 | 47.1082194 | 45.3094387|
v1   | 0.9835531 | 47.0779036 | 45.2659036|
v2   | 0.9833698 | 47.0335714 | 45.2138571|
v3   | 0.9832497 | 46.9939939 | 45.1635671|
-------------------------------------------

Result logs and encoded samples:
http://www.datafilehost.com/d/0d1a2416
http://rusfolder.com/45309357
Choose to download for free (with Ads) and without any managers.