Update for compatibility with libx265 4.0

[Lastique]

libx265 4.0 has changed the signature of x265_api::encoder_encode and x265_encoder_encode functions to accept a pointer to an array of pointers to output pictures. That pointer is now required to be non-null, otherwise the encode call crashes.

Upstream bug report: https://bitbucket.org/multicoreware/x265_git/issues/952/crash-in-libheif-tests

[farindk]

Thanks you.

Does that image have to be released?
I'm also wondering whether having the output image affects the encoding speed.

[Lastique]

Does that image have to be released?

No. My understanding is that the purpose of the output picture is to communicate to the caller various metadata, such as the encoded frame type (intra vs. inter-dependent), timestamps and so on. The only thing that changed is the number of these pictures that could be populated - in previous libx265 releases it was at most one, in libx265 4.0 it's one picture per layer. The number of layers is specified in x265_param::numLayers and by default is 1.

I'm also wondering whether having the output image affects the encoding speed.

To be clear, this PR still doesn't produce the output picture, as the original code didn't. encoder_encode does not allocate a picture, if the pointer is null. If you want to receive an output image then each pointer to an output image should point to a pre-existing x265_picture struct that encoder_encode will then populate with data.

However, requesting an output picture should not meaningfully affect performance, as it should just populate the struct members. Producing a decoded picture should happen internally anyway to implement the encoder feedback loop. I didn't benchmark, though.

[farindk]

Thanks for the background information.

Producing a decoded picture should happen internally anyway to implement the encoder feedback loop. I didn't benchmark, though.

Yes, but since we're only encoding one I-frame, that reconstructed image is not needed. But I don't believe x265 considers this special case.

[farindk]

x265 changed the function signature back to the old parameters in build version 213. I have adapted the #if in 9c39813.