James Almer: > On 5/21/2021 6:17 AM, Andreas Rheinhardt wrote: >> Its documentation described the way user-supplied buffers worked >> before 93016f5d1d280f9cb7856883af287fa66affc04c. >> >> Signed-off-by: Andreas Rheinhardt <andreas.rheinha...@outlook.com> >> --- >> libavcodec/internal.h | 16 ++++++---------- >> 1 file changed, 6 insertions(+), 10 deletions(-) >> >> diff --git a/libavcodec/internal.h b/libavcodec/internal.h >> index 60f65d3f2c..19c4e9e3f4 100644 >> --- a/libavcodec/internal.h >> +++ b/libavcodec/internal.h >> @@ -229,20 +229,16 @@ void ff_color_frame(AVFrame *frame, const int >> color[4]); >> #define FF_MAX_EXTRADATA_SIZE ((1 << 28) - >> AV_INPUT_BUFFER_PADDING_SIZE) >> /** >> - * Check AVPacket size and/or allocate data. >> + * Check AVPacket size and allocate data. >> * >> * Encoders supporting AVCodec.encode2() can use this as a >> convenience to >> - * ensure the output packet data is large enough, whether provided by >> the user >> - * or allocated in this function. >> + * obtain a big enough buffer for the encoded bitstream. >> * >> * @param avctx the AVCodecContext of the encoder >> - * @param avpkt the AVPacket >> - * If avpkt->data is already set, avpkt->size is checked >> - * to ensure it is large enough. >> - * If avpkt->data is NULL, a new buffer is allocated. >> - * avpkt->size is set to the specified size. >> - * All other AVPacket fields will be reset with >> av_init_packet(). >> - * @param size the minimum required packet size >> + * @param avpkt The AVPacket: on success, avpkt->data will point to >> a buffer >> + * of size at least `size`; avpkt->buf may be `NULL`. > > May? You're no longer calling av_new_packet() in any scenario. IMO > better be explicit that the resulting packet will not be refcounted. >
Changed "avpkt->buf may be `NULL`" to "the packet will not be refcounted". - Andreas >> + * This packet must be initially blank. >> + * @param size an upper bound of the size of the packet to encode >> * @param min_size This is a hint to the allocation algorithm, which >> indicates >> * to what minimal size the caller might later shrink >> the packet >> * to. Encoders often allocate packets which are >> larger than the > > LGTM otherwise. > _______________________________________________ > 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".
