[Libav-user] Interesting HEVC encoding bug with different presets

[Taha Ansari]

Hi,

Using zeranoe FFmpeg win32 build released on 2014-05-26, entiteled
"ffmpeg-20140526-git-96470ca-win32...", I have noticed a very interesting
bug while selecting different presets for HEVC encoding.

First, the code:

https://gist.github.com/anonymous/80f13fd55eb0e6f15ff1

It is slightly modified version of "muxing.c" example that comes with docs:
the entired muxing process is repeated two times, first with one 'preset',
and then with another.

Notice line# 552 and 556, particularly this segment:

if (fmt->video_codec != AV_CODEC_ID_NONE)
{
    fmt->video_codec = AV_CODEC_ID_HEVC;
    video_st = add_stream(oc, &video_codec, fmt->video_codec);
    switch(i)
    {
        case 0:
            //er = av_opt_set(video_st->codec->priv_data, "preset",
"medium",0);//works
            er = av_opt_set(video_st->codec->priv_data, "preset",
"ultrafast",0);//does not work
            break;
        case 1:
            //er = av_opt_set(video_st->codec->priv_data, "preset",
"fast",0);//works
            er = av_opt_set(video_st->codec->priv_data, "preset",
"veryslow",0);//does not work
            break;
        default:
            break;
    }
}

For this two times encoding, if I use:

av_opt_set(video_st->codec->priv_data, "preset", "medium",0);

for first time encoding, and use

av_opt_set(video_st->codec->priv_data, "preset", "fast",0);

for 2nd time encoding, there is apparently no problem; but, if I use:

av_opt_set(video_st->codec->priv_data, "preset", "ultrafast",0);

for 1st time encoding, and use:

av_opt_set(video_st->codec->priv_data, "preset", "veryslow",0);

for 2nd time encoding, then open_video() function fails on 2nd attempt...

Entire console log is printed as below:

x265 [info]: HEVC encoder version 1.0+38-d0acf82a77f9
x265 [info]: build info [Windows][GCC 4.8.2][32 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: WPP streams / pool / frames         : 9 / 4 / 1
x265 [info]: Main profile, Level-2 (Main tier)
x265 [info]: CU size                             : 32
x265 [info]: Max RQT depth inter / intra         : 1 / 1
x265 [info]: ME / range / subpel / merge         : dia / 25 / 0 / 2
x265 [info]: Keyframe min / max / scenecut       : 25 / 250 / 0
x265 [info]: Lookahead / bframes / badapt        : 10 / 4 / 0
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 0 / 0 / 1
x265 [info]: Rate Control / AQ-Strength / CUTree : ABR-400 kbps / 0.0 / 0
x265 [info]: tools: cfm esd rd=3 lft
Output #0, mp4, to 'output.mp4':
    Stream #0:0: Video: hevc (libx265), yuv420p, 352x288, q=2-31, 400 kb/s,
90k
tbn, 25 tbc
    Stream #0:1: Audio: aac (libvo_aacenc), 44100 Hz, 2 channels, s16, 64
kb/s
x265 [info]: frame I: 1      Avg QP:29.00  kb/s: 248.60
x265 [info]: frame P: 3      Avg QP:22.67  kb/s: 375.00
x265 [info]: frame B: 11     Avg QP:26.73  kb/s: 138.29
x265 [info]: global : 15     Avg QP:26.07  kb/s: 192.99
x265 [info]: consecutive B-frames: 25.0% 0.0% 0.0% 25.0% 50.0%
x265 [info]: HEVC encoder version 1.0+38-d0acf82a77f9
x265 [info]: build info [Windows][GCC 4.8.2][32 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [error]: maxCUSize must be the same for all encoders in a single
process
[libx265 @ 05e06b40] Cannot open libx265 encoder.

Notice the last two lines:

x265 [error]: maxCUSize must be the same for all encoders in a single
process
[libx265 @ 05e06b40] Cannot open libx265 encoder.

Which is kind of strange, because the preset alone is not the problem - I
can swap the sequence, i.e. use:

av_opt_set(video_st->codec->priv_data, "preset", "veryslow",0);

for 1st time encoding, and use:

av_opt_set(video_st->codec->priv_data, "preset", "ultrafast",0);

for 2nd time encoding, then still it fails at 2nd attempt only (so the
presets alone work fine).

Has this been spotted before? I tried to find similar bug reports but none
found so far.

I've been trying to figure this since a day or two now, and this is the
best lead so far.

I hope I did not get any parameters wrong...

Feedback is very much welcome!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://ffmpeg.org/pipermail/libav-user/attachments/20140604/431ac20e/attachment.html>