[x265] [PATCH] api: add param.bRepeatHeaders - insert stream headers in each keyframe NAL

[Tim Walker]

On 26 Mar 2014, at 20:45, Steve Borho <steve at borho.org> wrote:

> On Wed, Mar 26, 2014 at 6:26 AM, Tim Walker <tdskywalker at gmail.com> wrote:
>> On 25 Mar 2014, at 17:43, Steve Borho <steve at borho.org> wrote:
>> 
>>> # HG changeset patch
>>> # User Steve Borho <steve at borho.org>
>>> # Date 1395765782 18000
>>> #      Tue Mar 25 11:43:02 2014 -0500
>>> # Node ID e739e579609a0bc11ef72368ab39c824411d1d7b
>>> # Parent  4318d47d934857a5d0a5e2a8dc0eaed48f086197
>>> api: add param.bRepeatHeaders - insert stream headers in each keyframe NAL
>> 
>> Semi-related: x265_encoder_headers returns 0 on success, whereas x264_encoder_headers returns the size of the provided NAL units. Since all NAL units are already guaranteed by the x265 API to be contiguous in memory, returning the size would allow to simplify copying of returned headers, like this:
>> 
>> x265_encoder *x265_handle;
>> [...]
>> uint8_t  *buf;
>> x265_nal *nal;
>> uint32_t nnal;
>> 
>> int size = x265_encoder_headers(x265_handle, &nal, &nnal);
>> if (size <= 0)
>>    // handle errors
>> 
>> buf = malloc(size);
>> if (!buf)
>>    // handle errors
>> 
>> memcpy(buf, nal->payload, size);
>> 
>> ...instead of having to loop over the NAL array to compute the size manually.
> 
> I don't mind fixing this, if we can coordinate patches to ffmpeg/libav
> to fix their behavior at the same time.

That means dropping support for APIs <= 12. I have no problem doing that in HandBrake (when API 13 lands in a release), but I don't know about Libav/FFmpeg.

FWIW, the Libav/FFmpeg wrapper already checks for return values < 0 (x265.h claims x265_encoder_headers returns negative on error, even before your patch).

Tim