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 <jamr...@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@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
