On 26 Mar 2014, at 20:45, Steve Borho <[email protected]> wrote: > On Wed, Mar 26, 2014 at 6:26 AM, Tim Walker <[email protected]> wrote: >> On 25 Mar 2014, at 17:43, Steve Borho <[email protected]> wrote: >> >>> # HG changeset patch >>> # User Steve Borho <[email protected]> >>> # 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 _______________________________________________ x265-devel mailing list [email protected] https://mailman.videolan.org/listinfo/x265-devel
