Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH 2/4] avcodec/ccaption_dec: check the length of packet and return used length
Date: Thu, 12 May 2022 18:29:51 +0200
Message-ID: <DB6PR0101MB2214D983C5A3F91AC8C7AB548FCB9@DB6PR0101MB2214.eurprd01.prod.exchangelabs.com> (raw)
In-Reply-To: <DB6PR0101MB221456738F2A0326641AB46E8FCB9@DB6PR0101MB2214.eurprd01.prod.exchangelabs.com>

Andreas Rheinhardt:
> lance.lmwang@gmail.com:
>> On Thu, May 12, 2022 at 08:25:29AM +0200, Paul B Mahol wrote:
>>> On Thu, May 12, 2022 at 1:39 AM <lance.lmwang@gmail.com> wrote:
>>>
>>>> On Wed, May 11, 2022 at 09:47:52PM +0200, Paul B Mahol wrote:
>>>>> why?
>>>>
>>>> assuming the len is 1, the following code will access the next 3
>>>> array anymore, I think it's better to check the i with len -2.
>>>>
>>>> for (i = 0; i < len; i += 3) {
>>>> to
>>>> for (i = 0; i < len - 2; i += 3) {
>>>>
>>>> for the return, I think it's correct to return the used length,
>>>> if it's error, have return already. right?
>>>
>>>
>>> I doubt so.
>>
>> maybe I'm misunderstand it, but from the comments, the API claims that:
>> libavcodec/codec_internal.h
>> 175          * @return amount of bytes read from the packet on success,
>> 176          *         negative error code on failure
>> 177          */
>> 178         int (*decode)(struct AVCodecContext *avctx, struct AVFrame *frame,
>> 179                       int *got_frame_ptr, struct AVPacket *avpkt);
>> 180         /**
>> 181          * Decode subtitle data to an AVSubtitle.
>> 182          * cb is in this state if cb_type is FF_CODEC_CB_TYPE_DECODE_SUB.
>> 183          *
>> 184          * Apart from that this is like the decode callback.
>> 185          */
>> 186         int (*decode_sub)(struct AVCodecContext *avctx, struct AVSubtitle *sub,
>> 187                           int *got_frame_ptr, const struct AVPacket *avpkt);
>>
> 
> This is correct. It is not only the internal API which claims that, but
> the public API, too. And this just not honoured, in particular not in
> case of subtitle recoding. See
> https://github.com/mkver/FFmpeg/commit/ba1564c532654888015d67b70bf73d117c2d9f75
> 

It seems like there really are people who call this in a loop until all
the input is exhausted (as the documentation leads you to believe (The
internal uses of avcodec_decode_subtitle2 don't do this.)):
https://github.com/HandBrake/HandBrake/blob/a40fb6bce6755209461166140f131f26a2857eb9/libhb/decavsub.c#L335
I wonder if they ever got something meaningful the second time they
called it with the same packet (presuming there was a second time).

- Andreas
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

  reply	other threads:[~2022-05-12 16:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-11 14:48 [FFmpeg-devel] [PATCH 1/4] remove sccenc dependency on subtitles lance.lmwang
2022-05-11 14:48 ` [FFmpeg-devel] [PATCH 2/4] avcodec/ccaption_dec: check the length of packet and return used length lance.lmwang
2022-05-11 19:47   ` Paul B Mahol
2022-05-11 23:38     ` lance.lmwang
2022-05-12  6:25       ` Paul B Mahol
2022-05-12 15:17         ` lance.lmwang
2022-05-12 15:30           ` Andreas Rheinhardt
2022-05-12 16:29             ` Andreas Rheinhardt [this message]
2022-05-13  2:10               ` lance.lmwang
2022-05-11 14:48 ` [FFmpeg-devel] [PATCH 3/4] avformat/sccenc: avoid potential invalid access lance.lmwang
2022-05-11 14:48 ` [FFmpeg-devel] [PATCH 4/4] avcodec/dvdsubenc: return error if canvas_size is too small for subtitle render lance.lmwang
2022-05-18 13:42   ` lance.lmwang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DB6PR0101MB2214D983C5A3F91AC8C7AB548FCB9@DB6PR0101MB2214.eurprd01.prod.exchangelabs.com \
    --to=andreas.rheinhardt@outlook.com \
    --cc=ffmpeg-devel@ffmpeg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git