[SVT-HEVC integration] several problems

[Mike L.]

1. when using FFmpeg, input-res and fps are not passed through (running on Fedora 33 with FFmpeg from negativo17 repo with x265 SVT-HEVC integration enabled)
2. mapping from keyint to IntraPeriod could be reworked to include -2 (auto) - I would go as far as setting that as default; also, the actual gop-size is calculated as IntraPeriod + 1 for values > 0 (i.e. IntraPeriod of 0 matches keyint of 1 in x265, cf. https://github.com/OpenVisualCloud/SVT-HEVC/issues/584, https://github.com/OpenVisualCloud/SVT-HEVC/blob/master/Docs/svt-hevc_encoder_user_guide.md#3-headervps-sps-pps-insertion)

3. open-gop is broken:

   • the new standard (after https://github.com/OpenVisualCloud/SVT-HEVC/pull/435) is -1, while previous standard was 0 (=no-open-gop of x265)

   • the mapping logic is outdated (to be fair, their unit test is also outdated): open-gop should be mapped to -1 (currently 1), and no-open-gop to 0 (currently 2); values > 0 are not taken advantage of with x265 (https://github.com/OpenVisualCloud/SVT-HEVC/blob/master/Docs/svt-hevc_encoder_user_guide.md#3-headervps-sps-pps-insertion), but I personally don’t have any need for that behavior (otherwise, I would propose an extra option like --svt-header-insert-int and map that to IntraRefreshType + 1 (a value of N = header to be inserted once every N IDR frames, default value: 1):

     1. open-gop (default), this value is ignored entirely (show a warning)
     2. no-open-gop, a value < 1 should throw an error in all cases
     3. no-open-gop, a value > 1 should throw an error if RateControlMode is CQP (qp is given in x265), saying that value is unsupported for CQP mode (currently just segfaults, which is frustrating)

A PR implementing 2. and 3. should be easy enough. Point 1 might require more work. I’d be more than happy to try out the results.

Edit: segfault seems unrelated, reporting to distro repo maintainer

Edit 2: it seems this ultimately boils down to the fact that bitstreams created by x265 and SVT-HEVC are not compatible, so FFmpeg doesn’t know how to handle a bitstream generated by the latter when being fed from the former. I now realize that this might not be what x265’s SVT-HEVC integration is supposted to be used in other programs (contrary to information I’ve seen at some places). I’ve really hoped to be able to take advantage of the ability to add arbitrary SVT-HEVC parameters without patching either SVT-HEVC or FFmpeg. Hope someone could pick this up. Points 2 and 3 still apply, though.

[Mike L.]

Forgot to mention:

• setting svt=1 in FFmpeg’s -x265-params generates a warning, it would be nice to eliminate that
• setting keyint via -g in FFmpeg plugin is not effective with svt=1 (value not passed over to `svtHevcParams`, while -x265-params obviously works fine)

‌