[FFmpeg-devel] [PATCH v15 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper

[Limin Wang]

On Tue, Jul 30, 2019 at 07:48:43PM +0200, Carl Eugen Hoyos wrote:
> Am Di., 30. Juli 2019 um 15:20 Uhr schrieb James Almer <jamrial at gmail.com>:
> >
> > On 7/30/2019 2:59 AM, Limin Wang wrote:
> > >> +    if (avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER) {
> > >> +        EB_BUFFERHEADERTYPE *header_ptr = NULL;
> > >> +
> > >> +        svt_ret = EbH265EncStreamHeader(svt_enc->svt_handle, &header_ptr);
> > >> +        if (svt_ret != EB_ErrorNone) {
> > >> +            av_log(avctx, AV_LOG_ERROR, "Failed to build stream header\n");
> > >> +            goto failed_init_encoder;
> > >> +        }
> > >> +
> > >> +        avctx->extradata_size = header_ptr->nFilledLen;
> > >> +        avctx->extradata = av_malloc(avctx->extradata_size + AV_INPUT_BUFFER_PADDING_SIZE);
> > > It's preferalbe to use av_mallocz
> >
> > He was asked to do it this way as it's faster. No need to zero the whole
> > buffer if it's going to be written to immediately afterwards. Only the
> > trailing padding bytes needs to be zeroed.
> 
> In this case I suspect there is an unneeded cast in the next line.

It's very confusing to allocate with extra padding size, then memcpy the
actual data size, then zero the padding data.

IMO, the padding size is used for the bitstream optimized buffer read(32 or 64
bit for minimal at least). If it's memcpy, do we need malloc with extra 
AV_INPUT_BUFFER_PADDING_SIZE?


> 
> Carl Eugen
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".