Re: [FFmpeg-devel] [RFC] Release 6.1
Leavitt https://en.wikipedia.org/wiki/Henrietta_Swan_Leavitt > On 7 Jul 2023, at 08:40, Lynne wrote: > > Jul 6, 2023, 18:19 by j...@videolan.org: > >> Heya, >> >> On Thu, 6 Jul 2023, at 18:04, Lynne wrote: >> >>> It's been a while since we've had a release, and we've had >>> a lot of new features in. >>> We did say we would make releases more often, and I think >>> it's about time we have a new release. >>> >> >> It's a good idea. >> >>> Anything anyone wants to have merged or should we branch >>> off 6.1 in a few days? >>> >> >> By experience, it requires a bit more than a few days... :D >> > > May as well decide on a name in the meanwhile. > Anyone got any suggestions? > ___ > 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".
Re: [FFmpeg-devel] [RFC] Release 6.1
Jul 6, 2023, 18:19 by j...@videolan.org: > Heya, > > On Thu, 6 Jul 2023, at 18:04, Lynne wrote: > >> It's been a while since we've had a release, and we've had >> a lot of new features in. >> We did say we would make releases more often, and I think >> it's about time we have a new release. >> > > It's a good idea. > >> Anything anyone wants to have merged or should we branch >> off 6.1 in a few days? >> > > By experience, it requires a bit more than a few days... :D > May as well decide on a name in the meanwhile. Anyone got any suggestions? ___ 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".
Re: [FFmpeg-devel] [PATCH 2/3] avformat/evcdec: Check that enough data has been read
On 7/6/2023 10:24 PM, Andreas Rheinhardt wrote: James Almer: On 7/6/2023 6:08 PM, Andreas Rheinhardt wrote: Fixes potential use of uninitialized values in evc_read_nal_unit_length(). Signed-off-by: Andreas Rheinhardt --- libavformat/evcdec.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavformat/evcdec.c b/libavformat/evcdec.c index 9886542311..0f464930f7 100644 --- a/libavformat/evcdec.c +++ b/libavformat/evcdec.c @@ -162,6 +162,8 @@ static int evc_read_packet(AVFormatContext *s, AVPacket *pkt) ret = avio_read(s->pb, buf, EVC_NALU_LENGTH_PREFIX_SIZE); if (ret < 0) return ret; + if (ret != EVC_NALU_LENGTH_PREFIX_SIZE) + return AVERROR_INVALIDDATA; There's a ffio_ensure_seekback() for EVC_NALU_LENGTH_PREFIX_SIZE bytes immediately before the avio_read() call. Shouldn't that be enough to guarantee that much can be read? ffio_ensure_seekback() ensures that the read buffer is big enough so that reading EVC_NALU_LENGTH_PREFIX_SIZE bytes does not lead to a reset of the buffer; it does not imply that the buffer already contains EVC_NALU_LENGTH_PREFIX_SIZE bytes. In fact, there is not a single codepath in ffio_ensure_seekback() that actually reads further input. (If EVC_NALU_LENGTH_PREFIX_SIZE bytes are not available in the buffer, then the buf_size <= s->buffer_size codepath will likely be taken in the non-seekable case (in the seekable case, ffio_ensure_seekback() does even less, namely nothing).) Also, you can just pass ret to evc_read_nal_unit_length() below instead of adding this check here. It will return an error if it's < EVC_NALU_LENGTH_PREFIX_SIZE. It will actually return 0 which the caller will transform into an error. I do not want to rely on this behaviour. Ok, patch LGTM then. (Why did you add two inline functions of the same name in different evc headers?) If i recall correctly, because the probe function must not call av_log. nalu_size = evc_read_nal_unit_length(buf, EVC_NALU_LENGTH_PREFIX_SIZE); if (!nalu_size || nalu_size > INT_MAX) ___ 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".
Re: [FFmpeg-devel] [PATCH 2/3] avformat/evcdec: Check that enough data has been read
James Almer: > On 7/6/2023 10:30 PM, Andreas Rheinhardt wrote: >> James Almer: >>> On 7/6/2023 10:14 PM, James Almer wrote: On 7/6/2023 6:08 PM, Andreas Rheinhardt wrote: > Fixes potential use of uninitialized values > in evc_read_nal_unit_length(). > > Signed-off-by: Andreas Rheinhardt > --- > libavformat/evcdec.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/libavformat/evcdec.c b/libavformat/evcdec.c > index 9886542311..0f464930f7 100644 > --- a/libavformat/evcdec.c > +++ b/libavformat/evcdec.c > @@ -162,6 +162,8 @@ static int evc_read_packet(AVFormatContext *s, > AVPacket *pkt) > ret = avio_read(s->pb, buf, EVC_NALU_LENGTH_PREFIX_SIZE); > if (ret < 0) > return ret; > + if (ret != EVC_NALU_LENGTH_PREFIX_SIZE) > + return AVERROR_INVALIDDATA; There's a ffio_ensure_seekback() for EVC_NALU_LENGTH_PREFIX_SIZE bytes immediately before the avio_read() call. Shouldn't that be enough to guarantee that much can be read? Also, you can just pass ret to evc_read_nal_unit_length() below instead of adding this check here. It will return an error if it's < EVC_NALU_LENGTH_PREFIX_SIZE. >>> >>> Oh, my bad, i was looking at the function of the same name in >>> libavcodec/evc_parse.h >>> >>> The function in evc.h could be changed to also use the same check as the >>> one the evc_parse.h version alongside the other change you're doing in >>> patch 3/3. >>> >> >> These functions already do the same (except for the log message); they >> both return 0 if not enough data is available. The return value would >> need to be int64_t if one wanted to return both error codes and lengths >> via it. I don't really see the advantage of this. > > Fair enough. Then what about ffio_ensure_seekback()? Should that not > guarantee at least EVC_NALU_LENGTH_PREFIX_SIZE bytes are buffered, thus > readable and seekable backwards? No. It is just supposed to ensure that if one reads EVC_NALU_LENGTH_PREFIX_SIZE bytes, one can seek back and "unread" them. See also my earlier mail. - 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] avformat/evcdec: Check that enough data has been read
James Almer: > On 7/6/2023 6:08 PM, Andreas Rheinhardt wrote: >> Fixes potential use of uninitialized values >> in evc_read_nal_unit_length(). >> >> Signed-off-by: Andreas Rheinhardt >> --- >> libavformat/evcdec.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/libavformat/evcdec.c b/libavformat/evcdec.c >> index 9886542311..0f464930f7 100644 >> --- a/libavformat/evcdec.c >> +++ b/libavformat/evcdec.c >> @@ -162,6 +162,8 @@ static int evc_read_packet(AVFormatContext *s, >> AVPacket *pkt) >> ret = avio_read(s->pb, buf, EVC_NALU_LENGTH_PREFIX_SIZE); >> if (ret < 0) >> return ret; >> + if (ret != EVC_NALU_LENGTH_PREFIX_SIZE) >> + return AVERROR_INVALIDDATA; > > There's a ffio_ensure_seekback() for EVC_NALU_LENGTH_PREFIX_SIZE bytes > immediately before the avio_read() call. Shouldn't that be enough to > guarantee that much can be read? > ffio_ensure_seekback() ensures that the read buffer is big enough so that reading EVC_NALU_LENGTH_PREFIX_SIZE bytes does not lead to a reset of the buffer; it does not imply that the buffer already contains EVC_NALU_LENGTH_PREFIX_SIZE bytes. In fact, there is not a single codepath in ffio_ensure_seekback() that actually reads further input. (If EVC_NALU_LENGTH_PREFIX_SIZE bytes are not available in the buffer, then the buf_size <= s->buffer_size codepath will likely be taken in the non-seekable case (in the seekable case, ffio_ensure_seekback() does even less, namely nothing).) > Also, you can just pass ret to evc_read_nal_unit_length() below instead > of adding this check here. It will return an error if it's < > EVC_NALU_LENGTH_PREFIX_SIZE. > It will actually return 0 which the caller will transform into an error. I do not want to rely on this behaviour. (Why did you add two inline functions of the same name in different evc headers?) >> nalu_size = evc_read_nal_unit_length(buf, >> EVC_NALU_LENGTH_PREFIX_SIZE); >> if (!nalu_size || nalu_size > INT_MAX) ___ 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".
Re: [FFmpeg-devel] [PATCH 2/3] avformat/evcdec: Check that enough data has been read
On 7/6/2023 10:30 PM, Andreas Rheinhardt wrote: James Almer: On 7/6/2023 10:14 PM, James Almer wrote: On 7/6/2023 6:08 PM, Andreas Rheinhardt wrote: Fixes potential use of uninitialized values in evc_read_nal_unit_length(). Signed-off-by: Andreas Rheinhardt --- libavformat/evcdec.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavformat/evcdec.c b/libavformat/evcdec.c index 9886542311..0f464930f7 100644 --- a/libavformat/evcdec.c +++ b/libavformat/evcdec.c @@ -162,6 +162,8 @@ static int evc_read_packet(AVFormatContext *s, AVPacket *pkt) ret = avio_read(s->pb, buf, EVC_NALU_LENGTH_PREFIX_SIZE); if (ret < 0) return ret; + if (ret != EVC_NALU_LENGTH_PREFIX_SIZE) + return AVERROR_INVALIDDATA; There's a ffio_ensure_seekback() for EVC_NALU_LENGTH_PREFIX_SIZE bytes immediately before the avio_read() call. Shouldn't that be enough to guarantee that much can be read? Also, you can just pass ret to evc_read_nal_unit_length() below instead of adding this check here. It will return an error if it's < EVC_NALU_LENGTH_PREFIX_SIZE. Oh, my bad, i was looking at the function of the same name in libavcodec/evc_parse.h The function in evc.h could be changed to also use the same check as the one the evc_parse.h version alongside the other change you're doing in patch 3/3. These functions already do the same (except for the log message); they both return 0 if not enough data is available. The return value would need to be int64_t if one wanted to return both error codes and lengths via it. I don't really see the advantage of this. Fair enough. Then what about ffio_ensure_seekback()? Should that not guarantee at least EVC_NALU_LENGTH_PREFIX_SIZE bytes are buffered, thus readable and seekable backwards? ___ 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".
Re: [FFmpeg-devel] [PATCH 2/3] avformat/evcdec: Check that enough data has been read
James Almer: > On 7/6/2023 10:14 PM, James Almer wrote: >> On 7/6/2023 6:08 PM, Andreas Rheinhardt wrote: >>> Fixes potential use of uninitialized values >>> in evc_read_nal_unit_length(). >>> >>> Signed-off-by: Andreas Rheinhardt >>> --- >>> libavformat/evcdec.c | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/libavformat/evcdec.c b/libavformat/evcdec.c >>> index 9886542311..0f464930f7 100644 >>> --- a/libavformat/evcdec.c >>> +++ b/libavformat/evcdec.c >>> @@ -162,6 +162,8 @@ static int evc_read_packet(AVFormatContext *s, >>> AVPacket *pkt) >>> ret = avio_read(s->pb, buf, EVC_NALU_LENGTH_PREFIX_SIZE); >>> if (ret < 0) >>> return ret; >>> + if (ret != EVC_NALU_LENGTH_PREFIX_SIZE) >>> + return AVERROR_INVALIDDATA; >> >> There's a ffio_ensure_seekback() for EVC_NALU_LENGTH_PREFIX_SIZE bytes >> immediately before the avio_read() call. Shouldn't that be enough to >> guarantee that much can be read? >> >> Also, you can just pass ret to evc_read_nal_unit_length() below >> instead of adding this check here. It will return an error if it's < >> EVC_NALU_LENGTH_PREFIX_SIZE. > > Oh, my bad, i was looking at the function of the same name in > libavcodec/evc_parse.h > > The function in evc.h could be changed to also use the same check as the > one the evc_parse.h version alongside the other change you're doing in > patch 3/3. > These functions already do the same (except for the log message); they both return 0 if not enough data is available. The return value would need to be int64_t if one wanted to return both error codes and lengths via it. I don't really see the advantage of this. - 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] avformat/evcdec: Check that enough data has been read
On 7/6/2023 10:14 PM, James Almer wrote: On 7/6/2023 6:08 PM, Andreas Rheinhardt wrote: Fixes potential use of uninitialized values in evc_read_nal_unit_length(). Signed-off-by: Andreas Rheinhardt --- libavformat/evcdec.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavformat/evcdec.c b/libavformat/evcdec.c index 9886542311..0f464930f7 100644 --- a/libavformat/evcdec.c +++ b/libavformat/evcdec.c @@ -162,6 +162,8 @@ static int evc_read_packet(AVFormatContext *s, AVPacket *pkt) ret = avio_read(s->pb, buf, EVC_NALU_LENGTH_PREFIX_SIZE); if (ret < 0) return ret; + if (ret != EVC_NALU_LENGTH_PREFIX_SIZE) + return AVERROR_INVALIDDATA; There's a ffio_ensure_seekback() for EVC_NALU_LENGTH_PREFIX_SIZE bytes immediately before the avio_read() call. Shouldn't that be enough to guarantee that much can be read? Also, you can just pass ret to evc_read_nal_unit_length() below instead of adding this check here. It will return an error if it's < EVC_NALU_LENGTH_PREFIX_SIZE. Oh, my bad, i was looking at the function of the same name in libavcodec/evc_parse.h The function in evc.h could be changed to also use the same check as the one the evc_parse.h version alongside the other change you're doing in patch 3/3. nalu_size = evc_read_nal_unit_length(buf, EVC_NALU_LENGTH_PREFIX_SIZE); if (!nalu_size || nalu_size > INT_MAX) ___ 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".
Re: [FFmpeg-devel] [PATCH 1/3] avformat/evcdec: Avoid nonsense casts
On 7/6/2023 6:06 PM, Andreas Rheinhardt wrote:
For uint8_t buf[EVC_NALU_LENGTH_PREFIX_SIZE], &buf still points
to the beginning of buf, but it is of type "pointer to array of
EVC_NALU_LENGTH_PREFIX_SIZE uint8_t" (i.e. pointer arithmetic
would operate on blocks of size EVC_NALU_LENGTH_PREFIX_SIZE).
This is of course a different type than uint8_t*, which is why
there have been casts in evc_read_packet(). But these are unnecessary
if one justs removes the unnecessary address-of operator.
Signed-off-by: Andreas Rheinhardt
---
libavformat/evcdec.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavformat/evcdec.c b/libavformat/evcdec.c
index 73aab6c52f..9886542311 100644
--- a/libavformat/evcdec.c
+++ b/libavformat/evcdec.c
@@ -65,7 +65,7 @@ static int annexb_probe(const AVProbeData *p)
int nalu_type;
size_t nalu_size;
int got_sps = 0, got_pps = 0, got_idr = 0, got_nonidr = 0;
-unsigned char *bits = (unsigned char *)p->buf;
+unsigned char *bits = p->buf;
int bytes_to_read = p->buf_size;
while (bytes_to_read > EVC_NALU_LENGTH_PREFIX_SIZE) {
@@ -159,11 +159,11 @@ static int evc_read_packet(AVFormatContext *s, AVPacket
*pkt)
if (ret < 0)
return ret;
-ret = avio_read(s->pb, (unsigned char *)&buf, EVC_NALU_LENGTH_PREFIX_SIZE);
+ret = avio_read(s->pb, buf, EVC_NALU_LENGTH_PREFIX_SIZE);
if (ret < 0)
return ret;
-nalu_size = evc_read_nal_unit_length((const uint8_t *)&buf, EVC_NALU_LENGTH_PREFIX_SIZE);
+nalu_size = evc_read_nal_unit_length(buf, EVC_NALU_LENGTH_PREFIX_SIZE);
if (!nalu_size || nalu_size > INT_MAX)
return AVERROR_INVALIDDATA;
LGTM.
___
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".
Re: [FFmpeg-devel] [PATCH 2/3] avformat/evcdec: Check that enough data has been read
On 7/6/2023 6:08 PM, Andreas Rheinhardt wrote: Fixes potential use of uninitialized values in evc_read_nal_unit_length(). Signed-off-by: Andreas Rheinhardt --- libavformat/evcdec.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavformat/evcdec.c b/libavformat/evcdec.c index 9886542311..0f464930f7 100644 --- a/libavformat/evcdec.c +++ b/libavformat/evcdec.c @@ -162,6 +162,8 @@ static int evc_read_packet(AVFormatContext *s, AVPacket *pkt) ret = avio_read(s->pb, buf, EVC_NALU_LENGTH_PREFIX_SIZE); if (ret < 0) return ret; +if (ret != EVC_NALU_LENGTH_PREFIX_SIZE) +return AVERROR_INVALIDDATA; There's a ffio_ensure_seekback() for EVC_NALU_LENGTH_PREFIX_SIZE bytes immediately before the avio_read() call. Shouldn't that be enough to guarantee that much can be read? Also, you can just pass ret to evc_read_nal_unit_length() below instead of adding this check here. It will return an error if it's < EVC_NALU_LENGTH_PREFIX_SIZE. nalu_size = evc_read_nal_unit_length(buf, EVC_NALU_LENGTH_PREFIX_SIZE); if (!nalu_size || nalu_size > INT_MAX) ___ 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".
Re: [FFmpeg-devel] [PATCH v5] avformat/ivfenc: Set the "number of frames" in IVF header
> -Original Message-
> From: ffmpeg-devel On Behalf Of Dai,
> Jianhui J
> Sent: Monday, July 3, 2023 12:26 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v5] avformat/ivfenc: Set the "number of
> frames" in IVF header
>
> Should set "number of frames" to bytes 24-27 of IVF header, not duration.
> It is described by [1], and confirmed by parsing all IVF files in [2].
>
> This commit also updates the md5sum of refs to pass fate-cbs.
>
> [1] Duck IVF - MultimediaWiki
> https://wiki.multimedia.cx/index.php/Duck_IVF
>
> [2] webm/vp8-test-vectors
> https://chromium.googlesource.com/webm/vp8-test-vectors
>
> Signed-off-by: Jianhui Dai
> ---
> libavformat/ivfdec.c| 13 ++---
> libavformat/ivfenc.c| 13 +
> tests/ref/fate/cbs-vp9-vp90-2-03-deltaq | 2 +-
> tests/ref/fate/cbs-vp9-vp90-2-06-bilinear | 2 +-
> tests/ref/fate/cbs-vp9-vp90-2-09-lf_deltas | 2 +-
> .../ref/fate/cbs-vp9-vp90-2-10-show-existing-frame | 2 +-
> .../ref/fate/cbs-vp9-vp90-2-10-show-existing-frame2 | 2 +-
> tests/ref/fate/cbs-vp9-vp90-2-segmentation-aq-akiyo | 2 +-
> tests/ref/fate/cbs-vp9-vp90-2-segmentation-sf-akiyo | 2 +-
> tests/ref/fate/cbs-vp9-vp90-2-tiling-pedestrian | 2 +-
> tests/ref/fate/cbs-vp9-vp91-2-04-yuv440 | 2 +-
> tests/ref/fate/cbs-vp9-vp91-2-04-yuv444 | 2 +-
> tests/ref/fate/cbs-vp9-vp92-2-20-10bit-yuv420 | 2 +-
> tests/ref/fate/cbs-vp9-vp93-2-20-10bit-yuv422 | 2 +-
> tests/ref/fate/cbs-vp9-vp93-2-20-12bit-yuv444 | 2 +-
> 15 files changed, 28 insertions(+), 24 deletions(-)
>
> diff --git a/libavformat/ivfdec.c b/libavformat/ivfdec.c index
> 511f2387ed..141ce4f1be 100644
> --- a/libavformat/ivfdec.c
> +++ b/libavformat/ivfdec.c
> @@ -51,11 +51,18 @@ static int read_header(AVFormatContext *s)
> st->codecpar->codec_id = ff_codec_get_id(ff_codec_bmp_tags, st-
> >codecpar->codec_tag);
> st->codecpar->width = avio_rl16(s->pb);
> st->codecpar->height = avio_rl16(s->pb);
> -time_base.den = avio_rl32(s->pb);
> -time_base.num = avio_rl32(s->pb);
> -st->duration = avio_rl32(s->pb);
> +time_base.den= avio_rl32(s->pb);
> +time_base.num= avio_rl32(s->pb);
> +st->nb_frames= avio_rl32(s->pb);
> avio_skip(s->pb, 4); // unused
>
> +// Infer duration from nb_frames, in order to be backward compatible
> with
> +// previous IVF demuxer.
> +// It is popular to configure time_base to 1/frame_rate by IVF muxer,
> that
> +// the duration happens to be the same with nb_frames. See
> +// `https://chromium.googlesource.com/webm/vp8-test-
> vectors/+/refs/heads/main`
> +st->duration = st->nb_frames;
> +
> ffstream(st)->need_parsing = AVSTREAM_PARSE_HEADERS;
>
> if (!time_base.den || !time_base.num) { diff --git a/libavformat/ivfenc.c
> b/libavformat/ivfenc.c index 47b4efbcd1..88399099d4 100644
> --- a/libavformat/ivfenc.c
> +++ b/libavformat/ivfenc.c
> @@ -72,7 +72,8 @@ static int ivf_write_header(AVFormatContext *s)
> avio_wl16(pb, par->height);
> avio_wl32(pb, s->streams[0]->time_base.den);
> avio_wl32(pb, s->streams[0]->time_base.num);
> -avio_wl64(pb, 0xULL); // length is overwritten at the end
> of muxing
> +avio_wl32(pb, 0x); // "number of frames" is overwritten at the
> end of muxing
> +avio_wl32(pb, 0); // unused
>
> return 0;
> }
> @@ -99,16 +100,12 @@ static int ivf_write_trailer(AVFormatContext *s)
> AVIOContext *pb = s->pb;
> IVFEncContext *ctx = s->priv_data;
>
> -if ((pb->seekable & AVIO_SEEKABLE_NORMAL) &&
> -(ctx->frame_cnt > 1 || (ctx->frame_cnt == 1 &&
> ctx->last_pkt_duration)))
> {
> +// overwrite the "number of frames"
> +if ((pb->seekable & AVIO_SEEKABLE_NORMAL)) {
> int64_t end = avio_tell(pb);
>
> avio_seek(pb, 24, SEEK_SET);
> -// overwrite the "length" field (duration)
> -avio_wl32(pb, ctx->last_pkt_duration ?
> - ctx->sum_delta_pts + ctx->last_pkt_duration :
> - ctx->frame_cnt * ctx->sum_delta_pts / (ctx->frame_cnt -
> 1));
> -avio_wl32(pb, 0); // zero out unused bytes
> +avio_wl32(pb, ctx->frame_cnt);
> avio_seek(pb, end, SEEK_SET);
> }
>
> diff --git a/tests/ref/fate/cbs-vp9-vp90-2-03-deltaq b/tests/ref/fate/cbs-vp9-
> vp90-2-03-deltaq
> index db09cfd5e0..f621d7a480 100644
> --- a/tests/ref/fate/cbs-vp9-vp90-2-03-deltaq
> +++ b/tests/ref/fate/cbs-vp9-vp90-2-03-deltaq
> @@ -1 +1 @@
> -bb630ef560f83951fa6547a664fdb636
> +fe62460fe28202e0666e628afd8602ca
> diff --git a/tests/ref/fate/cbs-vp9-vp90-2-06-bilinear b/tests/ref/fate/cbs-
> vp9-vp90-2-06-bilinear
> index f579459179..9359e21e40 100644
> --- a/tests/ref/fate/cbs-vp9-vp90-2-06-bilinear
> +++ b/tests/ref/f
Re: [FFmpeg-devel] [PATCH 1/2] avformat/hlsenc: fall back to av_get_random_seed() when generating AES128 key
On Thu, Jul 06, 2023 at 09:52:12AM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2023-07-06 00:54:47)
> > On Wed, Jul 05, 2023 at 11:22:44AM +0200, Anton Khirnov wrote:
> > > Quoting Michael Niedermayer (2023-07-05 01:50:12)
> > > > On Tue, Jul 04, 2023 at 07:54:06AM +0200, Anton Khirnov wrote:
> > > > > Quoting Michael Niedermayer (2023-07-04 01:50:57)
> > > > > > On Mon, Jul 03, 2023 at 11:09:54PM +0200, Anton Khirnov wrote:
> > > > > > > Quoting Marton Balint (2023-07-03 22:54:41)
> > > > > > > > On Mon, 3 Jul 2023, Anton Khirnov wrote:
> > > > > > > > My patch use av_get_random_seed() which uses what the
> > > > > > > > underlying OS
> > > > > > > > provides, BCrypt for Windows, /dev/urandom for Linux,
> > > > > > > > arc4random() for
> > > > > > > > BSD/Mac.
> > > > > > >
> > > > > > > IOW it's a jungle of various paths, some of which are not
> > > > > > > guaranteed to
> > > > > > > be cryptographically secure. I see no such guarantees for
> > > > > > > arc4random()
> > > > > > > from a brief web search, and the fallback get_generic_seed()
> > > > > > > certainly
> > > > > > > is not either. Granted it's only used on obscure architectures,
> > > > > > > but
> > > > > > > still.
> > > > > > >
> > > > > > > The doxy even says
> > > > > > > > This function tries to provide a good seed at a best effort
> > > > > > > > bases.
> > > > > > >
> > > > > > > > You really think that these are significantly worse than
> > > > > > > > OpenSSL/GCrypt, so it should not be allowed to fallback to?
> > > > > > >
> > > > > > > I think we should be using cryptographically secure PRNG for
> > > > > > > generating
> > > > > > > encryption keys, or fail when they are not available. If you want
> > > > > > > to get
> > > > > > > rid of the openssl dependency, IMO the best solution is a new
> > > > > > > int av_random(uint8_t* buf, size_t len);
> > > > > > > that guarantees either cryptographically secure randomness or an
> > > > > > > error.
> > > > > >
> > > > > > "guarantees cryptographically secure randomness" ?
> > > > > > If one defined "cryptographically secure" as "not broken publically
> > > > > > as of today"
> > > > > >
> > > > > > Iam saying that as i think "guarantees" can be misleading in what
> > > > > > it means
> > > > >
> > > > > I feel your snark is very much misplaced.
> > > > >
> > > >
> > > > > I recall way more instances of broken crypto caused by overconfident
> > > > > non-experts with an attitude like yours ("those silly crypto
> > > > > libraries,
> > > > > broken all the time, how hard can it be really") than by actual
> > > > > vulnerabilities in actual crypto libraries.
> > > > >
> > > > > In fact the highest-profile break I remember (Debian key entropy bug)
> > > > > was caused precisely by non-experts fiddling with code they did not
> > > > > understand.
> > > >
> > > > There is no snark here, at least that was not the intend
> > > > Also what you say in these 2 paragraphs is true but isnt really
> > > > related to what i said or meant to say
> > > >
> > > > these cryptographically secure PRNGS are secure as long as the
> > > > currently used components and assumtations they are build on havnt
> > > > been broken.
> > > > Can i do better? no. but that doesnt mean that these
> > > > are going to be unbroken in 30 years.
> > > > just look 30 years in the past what percentage of what was believed to
> > > > be secure 30 years ago has been broken today. or 50 or 100years
> > > > thats really what i meant
> > >
> > > I still don't see what point are you trying to make here.
> > > Yes, any practical cryptographic algorithm could potentially be broken
> > > at some point. And everything in real life is imperfect, because we do
> > > not live in the world of ideal forms.
> >
> > > But I don't see what practical steps could or should be taken in
> > > response to this.
> >
> > for us i dont know but a user could
> > instead of putting critical data in a system that might be broken in 30
> > years
> > just write it down on paper and burn and grind the paper when its not
> > needed anymore
> > (which may or may not be an option)
> >
> > nothing is perfect but there are methods to transfer and destroy data which
> > have a
> > long track record of being secure and are simple.
> >
> > I think we should not make it sound like encrypting with these random
> > numbers
> > is as good as not storing/transmitting or using bits from fliping a real
> > fair coin
>
> We are not claiming that. We are claiming that the random numbers
> generated are (to the best of our ability, and that of the underlying
> libraries we rely on) cryptographically secure. This means suitable for
> use in state of the art cryptographic algorithms like AES.
> I do not think it makes sense to mistrust CSPRNGs, yet still trust AES.
The litteral wording was
"that guarantees either cryptographically secure randomness or an error."
that was what i refered to.
the wording used now:
"to th
Re: [FFmpeg-devel] [PATCH 1/2] avformat/hlsenc: fall back to av_get_random_seed() when generating AES128 key
On Thu, 6 Jul 2023, 08:52 Anton Khirnov, wrote: > > We are not claiming that. We are claiming that the random numbers > generated are (to the best of our ability, and that of the underlying > libraries we rely on) cryptographically secure. This means suitable for > use in state of the art cryptographic algorithms like AES. > I do not think it makes sense to mistrust CSPRNGs, yet still trust AES. Agreed, I don't think it's ffmpeg's job to get into a philosophical discussion about the state of the art of random number generation. Kieran > ". > ___ 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".
Re: [FFmpeg-devel] [PATCH v2 5/5] libavformat/webp: add WebP demuxer
Am 06.07.23 um 22:24 schrieb James Zern: On Thu, Jul 6, 2023 at 4:28 AM Thilo Borgmann wrote: From: Josef Zlomek Adds the demuxer of animated WebP files. It supports non-animated, animated, truncated, and concatenated files. Reading from a pipe (and other non-seekable inputs) is also supported. The WebP demuxer splits the input stream into packets containing one frame. It also marks the key frames properly. The loop count is ignored by default (same behaviour as animated PNG and GIF), it may be enabled by the option '-ignore_loop 0'. The frame rate is set according to the frame delay in the ANMF chunk. If the delay is too low, or the image is not animated, the default frame rate is set to 10 fps, similarly to other WebP libraries and browsers. The fate suite was updated accordingly. Signed-off-by: Josef Zlomek --- Changelog | 1 + doc/demuxers.texi | 28 + libavformat/Makefile| 1 + libavformat/allformats.c| 1 + libavformat/version.h | 2 +- libavformat/webpdec.c | 733 tests/ref/fate/webp-rgb-lena-lossless | 2 +- tests/ref/fate/webp-rgb-lena-lossless-rgb24 | 2 +- tests/ref/fate/webp-rgb-lossless| 2 +- tests/ref/fate/webp-rgb-lossy-q80 | 2 +- tests/ref/fate/webp-rgba-lossless | 2 +- tests/ref/fate/webp-rgba-lossy-q80 | 2 +- 12 files changed, 771 insertions(+), 7 deletions(-) create mode 100644 libavformat/webpdec.c Looks like fate is breaking on fate-exif-image-webp with this change. Oh will add it! I also noticed a few corrupt files could hang this. I'll send some examples. Looking into them. [...] +// fallback if VP8X chunk was not present +if (!canvas_width && width > 0) +canvas_width = width; +if (!canvas_height && height > 0) +canvas_height = height; +} + +// WebP format operates with time in "milliseconds", therefore timebase is 1/100 1/1000 Fixed locally. Thanks, Thilo ___ 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] [PATCH 3/3] avformat/evc: Don't cast const away, avoid loop
Signed-off-by: Andreas Rheinhardt
---
libavformat/evc.h | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/libavformat/evc.h b/libavformat/evc.h
index 46b27f7df7..f30831257d 100644
--- a/libavformat/evc.h
+++ b/libavformat/evc.h
@@ -23,16 +23,17 @@
#define AVFORMAT_EVC_H
#include
+
+#include "libavutil/intreadwrite.h"
#include "libavutil/rational.h"
#include "libavcodec/evc.h"
#include "avio.h"
-static inline int evc_get_nalu_type(const uint8_t *bits, int bits_size)
+static inline int evc_get_nalu_type(const uint8_t *p, int bits_size)
{
int unit_type_plus1 = 0;
if (bits_size >= EVC_NALU_HEADER_SIZE) {
-unsigned char *p = (unsigned char *)bits;
// forbidden_zero_bit
if ((p[0] & 0x80) != 0) // Cannot get bitstream information.
Malformed bitstream.
return -1;
@@ -46,16 +47,10 @@ static inline int evc_get_nalu_type(const uint8_t *bits,
int bits_size)
static inline uint32_t evc_read_nal_unit_length(const uint8_t *bits, int
bits_size)
{
-uint32_t nalu_len = 0;
-
-if (bits_size >= EVC_NALU_LENGTH_PREFIX_SIZE) {
-unsigned char *p = (unsigned char *)bits;
-
-for (int i = 0; i < EVC_NALU_LENGTH_PREFIX_SIZE; i++)
-nalu_len = (nalu_len << 8) | p[i];
-}
+if (bits_size >= EVC_NALU_LENGTH_PREFIX_SIZE)
+return AV_RB32(bits);
-return nalu_len;
+return 0;
}
/**
--
2.34.1
___
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] [PATCH 2/3] avformat/evcdec: Check that enough data has been read
Fixes potential use of uninitialized values in evc_read_nal_unit_length(). Signed-off-by: Andreas Rheinhardt --- libavformat/evcdec.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavformat/evcdec.c b/libavformat/evcdec.c index 9886542311..0f464930f7 100644 --- a/libavformat/evcdec.c +++ b/libavformat/evcdec.c @@ -162,6 +162,8 @@ static int evc_read_packet(AVFormatContext *s, AVPacket *pkt) ret = avio_read(s->pb, buf, EVC_NALU_LENGTH_PREFIX_SIZE); if (ret < 0) return ret; +if (ret != EVC_NALU_LENGTH_PREFIX_SIZE) +return AVERROR_INVALIDDATA; nalu_size = evc_read_nal_unit_length(buf, EVC_NALU_LENGTH_PREFIX_SIZE); if (!nalu_size || nalu_size > INT_MAX) -- 2.34.1 ___ 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] [PATCH 1/3] avformat/evcdec: Avoid nonsense casts
For uint8_t buf[EVC_NALU_LENGTH_PREFIX_SIZE], &buf still points
to the beginning of buf, but it is of type "pointer to array of
EVC_NALU_LENGTH_PREFIX_SIZE uint8_t" (i.e. pointer arithmetic
would operate on blocks of size EVC_NALU_LENGTH_PREFIX_SIZE).
This is of course a different type than uint8_t*, which is why
there have been casts in evc_read_packet(). But these are unnecessary
if one justs removes the unnecessary address-of operator.
Signed-off-by: Andreas Rheinhardt
---
libavformat/evcdec.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavformat/evcdec.c b/libavformat/evcdec.c
index 73aab6c52f..9886542311 100644
--- a/libavformat/evcdec.c
+++ b/libavformat/evcdec.c
@@ -65,7 +65,7 @@ static int annexb_probe(const AVProbeData *p)
int nalu_type;
size_t nalu_size;
int got_sps = 0, got_pps = 0, got_idr = 0, got_nonidr = 0;
-unsigned char *bits = (unsigned char *)p->buf;
+unsigned char *bits = p->buf;
int bytes_to_read = p->buf_size;
while (bytes_to_read > EVC_NALU_LENGTH_PREFIX_SIZE) {
@@ -159,11 +159,11 @@ static int evc_read_packet(AVFormatContext *s, AVPacket
*pkt)
if (ret < 0)
return ret;
-ret = avio_read(s->pb, (unsigned char *)&buf,
EVC_NALU_LENGTH_PREFIX_SIZE);
+ret = avio_read(s->pb, buf, EVC_NALU_LENGTH_PREFIX_SIZE);
if (ret < 0)
return ret;
-nalu_size = evc_read_nal_unit_length((const uint8_t *)&buf,
EVC_NALU_LENGTH_PREFIX_SIZE);
+nalu_size = evc_read_nal_unit_length(buf, EVC_NALU_LENGTH_PREFIX_SIZE);
if (!nalu_size || nalu_size > INT_MAX)
return AVERROR_INVALIDDATA;
--
2.34.1
___
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".
Re: [FFmpeg-devel] [PATCH 2/2] lavf/dv: stop setting a random video bitrate
LGTM ___ 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".
Re: [FFmpeg-devel] [PATCH 1/2] lavc/dvdec: export bitrate
LGTM ___ 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".
Re: [FFmpeg-devel] [PATCH v2 5/5] libavformat/webp: add WebP demuxer
On Thu, Jul 6, 2023 at 4:28 AM Thilo Borgmann wrote: > > From: Josef Zlomek > > Adds the demuxer of animated WebP files. > It supports non-animated, animated, truncated, and concatenated files. > Reading from a pipe (and other non-seekable inputs) is also supported. > > The WebP demuxer splits the input stream into packets containing one frame. > It also marks the key frames properly. > The loop count is ignored by default (same behaviour as animated PNG and GIF), > it may be enabled by the option '-ignore_loop 0'. > > The frame rate is set according to the frame delay in the ANMF chunk. > If the delay is too low, or the image is not animated, the default frame rate > is set to 10 fps, similarly to other WebP libraries and browsers. > The fate suite was updated accordingly. > > Signed-off-by: Josef Zlomek > --- > Changelog | 1 + > doc/demuxers.texi | 28 + > libavformat/Makefile| 1 + > libavformat/allformats.c| 1 + > libavformat/version.h | 2 +- > libavformat/webpdec.c | 733 > tests/ref/fate/webp-rgb-lena-lossless | 2 +- > tests/ref/fate/webp-rgb-lena-lossless-rgb24 | 2 +- > tests/ref/fate/webp-rgb-lossless| 2 +- > tests/ref/fate/webp-rgb-lossy-q80 | 2 +- > tests/ref/fate/webp-rgba-lossless | 2 +- > tests/ref/fate/webp-rgba-lossy-q80 | 2 +- > 12 files changed, 771 insertions(+), 7 deletions(-) > create mode 100644 libavformat/webpdec.c > Looks like fate is breaking on fate-exif-image-webp with this change. I also noticed a few corrupt files could hang this. I'll send some examples. > [...] > +// fallback if VP8X chunk was not present > +if (!canvas_width && width > 0) > +canvas_width = width; > +if (!canvas_height && height > 0) > +canvas_height = height; > +} > + > +// WebP format operates with time in "milliseconds", therefore timebase > is 1/100 1/1000 ___ 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".
Re: [FFmpeg-devel] [PATCH] fftools/ffplay: Fixed typo in frame_queue_destory
On Wed, 5 Jul 2023, QiTong Li wrote:
Not sure if the function naming frame_queue_destory is intended because "destory" is not
really a word. Changing it to "destroy" makes more sense.
Thanks, will apply.
Regards,
Marton
Signed-off-by: QiTong Li
---
fftools/ffplay.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 663f61d8b2..51cde0d208 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -696,7 +696,7 @@ static int frame_queue_init(FrameQueue *f, PacketQueue
*pktq, int max_size, int
return 0;
}
-static void frame_queue_destory(FrameQueue *f)
+static void frame_queue_destroy(FrameQueue *f)
{
int i;
for (i = 0; i < f->max_size; i++) {
@@ -1252,9 +1252,9 @@ static void stream_close(VideoState *is)
packet_queue_destroy(&is->subtitleq);
/* free all pictures */
-frame_queue_destory(&is->pictq);
-frame_queue_destory(&is->sampq);
-frame_queue_destory(&is->subpq);
+frame_queue_destroy(&is->pictq);
+frame_queue_destroy(&is->sampq);
+frame_queue_destroy(&is->subpq);
SDL_DestroyCond(is->continue_read_thread);
sws_freeContext(is->sub_convert_ctx);
av_free(is->filename);
--
2.33.0.windows.2
___
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".
Re: [FFmpeg-devel] [PATCH v3 3/3] avutil/random_seed: add support for gcrypt and OpenSSL as source of randomness
On 7/6/2023 2:56 PM, Marton Balint wrote: On Thu, 6 Jul 2023, James Almer wrote: On 7/6/2023 4:52 AM, Anton Khirnov wrote: Quoting James Almer (2023-07-05 15:03:07) On 7/5/2023 9:56 AM, Anton Khirnov wrote: Quoting James Almer (2023-07-05 01:26:14) Signed-off-by: James Almer --- configure | 2 +- libavutil/random_seed.c | 16 2 files changed, 17 insertions(+), 1 deletion(-) diff --git a/configure b/configure index 107d533b3e..d6e78297fe 100755 --- a/configure +++ b/configure @@ -3892,7 +3892,7 @@ avfilter_deps="avutil" avfilter_suggest="libm stdatomic" avformat_deps="avcodec avutil" avformat_suggest="libm network zlib stdatomic" -avutil_suggest="clock_gettime ffnvcodec libm libdrm libmfx opencl user32 vaapi vulkan videotoolbox corefoundation corevideo coremedia bcrypt stdatomic" +avutil_suggest="clock_gettime ffnvcodec gcrypt libm libdrm libmfx opencl openssl user32 vaapi vulkan videotoolbox corefoundation corevideo coremedia bcrypt stdatomic" What will this do exactly? It's a soft dependency. Only if OpenSSL or GCrypt are enabled they will be added to avutil's library dependencies. Notice the bcrypt entry, also used in random_seed, and all the hwcontext backends. Ok then. Any opinion on the order of function calls? Should i leave /dev/urandom as last resort after all (if any) external lib implementations failed, considering what Remí mentioned? I think it is fine as is. Buffering can be turned off with setvbuf(f, NULL, _IONBF, 0); so that should not relevant. Ok, applied as is, then. ___ 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] [PATCH] avutil/random_seed: add support for GnuTLS as source of randomness
Signed-off-by: James Almer --- configure | 2 +- libavutil/random_seed.c | 6 ++ 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/configure b/configure index d6e78297fe..56e2b85f97 100755 --- a/configure +++ b/configure @@ -3892,7 +3892,7 @@ avfilter_deps="avutil" avfilter_suggest="libm stdatomic" avformat_deps="avcodec avutil" avformat_suggest="libm network zlib stdatomic" -avutil_suggest="clock_gettime ffnvcodec gcrypt libm libdrm libmfx opencl openssl user32 vaapi vulkan videotoolbox corefoundation corevideo coremedia bcrypt stdatomic" +avutil_suggest="clock_gettime ffnvcodec gcrypt gnutls libm libdrm libmfx opencl openssl user32 vaapi vulkan videotoolbox corefoundation corevideo coremedia bcrypt stdatomic" postproc_deps="avutil gpl" postproc_suggest="libm stdatomic" swresample_deps="avutil" diff --git a/libavutil/random_seed.c b/libavutil/random_seed.c index 2980e565e0..e02431898e 100644 --- a/libavutil/random_seed.c +++ b/libavutil/random_seed.c @@ -34,6 +34,8 @@ #include #elif CONFIG_OPENSSL #include +#elif CONFIG_GNUTLS +#include #endif #include #include @@ -158,6 +160,10 @@ int av_random_bytes(uint8_t* buf, size_t len) if (RAND_bytes(buf, len) == 1) return 0; err = AVERROR_EXTERNAL; +#elif CONFIG_GNUTLS +err = gnutls_rnd(GNUTLS_RND_KEY, buf, len); +if (!err) +return 0; #endif return err; -- 2.41.0 ___ 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".
Re: [FFmpeg-devel] [PATCH v3 3/3] avutil/random_seed: add support for gcrypt and OpenSSL as source of randomness
On Thu, 6 Jul 2023, James Almer wrote: On 7/6/2023 4:52 AM, Anton Khirnov wrote: Quoting James Almer (2023-07-05 15:03:07) On 7/5/2023 9:56 AM, Anton Khirnov wrote: Quoting James Almer (2023-07-05 01:26:14) Signed-off-by: James Almer --- configure | 2 +- libavutil/random_seed.c | 16 2 files changed, 17 insertions(+), 1 deletion(-) diff --git a/configure b/configure index 107d533b3e..d6e78297fe 100755 --- a/configure +++ b/configure @@ -3892,7 +3892,7 @@ avfilter_deps="avutil" avfilter_suggest="libm stdatomic" avformat_deps="avcodec avutil" avformat_suggest="libm network zlib stdatomic" -avutil_suggest="clock_gettime ffnvcodec libm libdrm libmfx opencl user32 vaapi vulkan videotoolbox corefoundation corevideo coremedia bcrypt stdatomic" +avutil_suggest="clock_gettime ffnvcodec gcrypt libm libdrm libmfx opencl openssl user32 vaapi vulkan videotoolbox corefoundation corevideo coremedia bcrypt stdatomic" What will this do exactly? It's a soft dependency. Only if OpenSSL or GCrypt are enabled they will be added to avutil's library dependencies. Notice the bcrypt entry, also used in random_seed, and all the hwcontext backends. Ok then. Any opinion on the order of function calls? Should i leave /dev/urandom as last resort after all (if any) external lib implementations failed, considering what Remí mentioned? I think it is fine as is. Buffering can be turned off with setvbuf(f, NULL, _IONBF, 0); so that should not relevant. Regards, Marton ___ 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".
Re: [FFmpeg-devel] [PATCH v3 3/3] avutil/random_seed: add support for gcrypt and OpenSSL as source of randomness
On 7/6/2023 4:52 AM, Anton Khirnov wrote: Quoting James Almer (2023-07-05 15:03:07) On 7/5/2023 9:56 AM, Anton Khirnov wrote: Quoting James Almer (2023-07-05 01:26:14) Signed-off-by: James Almer --- configure | 2 +- libavutil/random_seed.c | 16 2 files changed, 17 insertions(+), 1 deletion(-) diff --git a/configure b/configure index 107d533b3e..d6e78297fe 100755 --- a/configure +++ b/configure @@ -3892,7 +3892,7 @@ avfilter_deps="avutil" avfilter_suggest="libm stdatomic" avformat_deps="avcodec avutil" avformat_suggest="libm network zlib stdatomic" -avutil_suggest="clock_gettime ffnvcodec libm libdrm libmfx opencl user32 vaapi vulkan videotoolbox corefoundation corevideo coremedia bcrypt stdatomic" +avutil_suggest="clock_gettime ffnvcodec gcrypt libm libdrm libmfx opencl openssl user32 vaapi vulkan videotoolbox corefoundation corevideo coremedia bcrypt stdatomic" What will this do exactly? It's a soft dependency. Only if OpenSSL or GCrypt are enabled they will be added to avutil's library dependencies. Notice the bcrypt entry, also used in random_seed, and all the hwcontext backends. Ok then. Any opinion on the order of function calls? Should i leave /dev/urandom as last resort after all (if any) external lib implementations failed, considering what Remí mentioned? ___ 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] [PATCH] avformat/hlsenc: use av_random_bytes() for generating AES128 key
av_random_bytes() can use OS provided strong random functions and does not
depend soley on openssl/gcrypt external libraries.
Fixes ticket #10441.
Signed-off-by: Marton Balint
---
configure| 1 -
libavformat/hlsenc.c | 23 ++-
2 files changed, 2 insertions(+), 22 deletions(-)
diff --git a/configure b/configure
index 107d533b3e..b331b2e9db 100755
--- a/configure
+++ b/configure
@@ -3507,7 +3507,6 @@ gxf_muxer_select="pcm_rechunk_bsf"
hds_muxer_select="flv_muxer"
hls_demuxer_select="adts_header ac3_parser mov_demuxer mpegts_demuxer"
hls_muxer_select="mov_muxer mpegts_muxer"
-hls_muxer_suggest="gcrypt openssl"
image2_alias_pix_demuxer_select="image2_demuxer"
image2_brender_pix_demuxer_select="image2_demuxer"
imf_demuxer_deps="libxml2"
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 1e0848ce3d..27d97f5f72 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -27,12 +27,6 @@
#include
#endif
-#if CONFIG_GCRYPT
-#include
-#elif CONFIG_OPENSSL
-#include
-#endif
-
#include "libavutil/avassert.h"
#include "libavutil/mathematics.h"
#include "libavutil/avstring.h"
@@ -40,6 +34,7 @@
#include "libavutil/intreadwrite.h"
#include "libavutil/opt.h"
#include "libavutil/log.h"
+#include "libavutil/random_seed.h"
#include "libavutil/time.h"
#include "libavutil/time_internal.h"
@@ -710,20 +705,6 @@ fail:
return ret;
}
-static int randomize(uint8_t *buf, int len)
-{
-#if CONFIG_GCRYPT
-gcry_randomize(buf, len, GCRY_VERY_STRONG_RANDOM);
-return 0;
-#elif CONFIG_OPENSSL
-if (RAND_bytes(buf, len))
-return 0;
-#else
-return AVERROR(ENOSYS);
-#endif
-return AVERROR(EINVAL);
-}
-
static int do_encrypt(AVFormatContext *s, VariantStream *vs)
{
HLSContext *hls = s->priv_data;
@@ -775,7 +756,7 @@ static int do_encrypt(AVFormatContext *s, VariantStream *vs)
if (!*hls->key_string) {
AVDictionary *options = NULL;
if (!hls->key) {
-if ((ret = randomize(key, sizeof(key))) < 0) {
+if ((ret = av_random_bytes(key, sizeof(key))) < 0) {
av_log(s, AV_LOG_ERROR, "Cannot generate a strong random
key\n");
return ret;
}
--
2.35.3
___
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] [PATCH v2 1/2] avcodec/cbs_h266: fix use of uninitialized value
And fix the allowed range for ph_log2_diff_max_bt_min_qt_intra_slice_luma while
at it.
Signed-off-by: James Almer
---
libavcodec/cbs_h266_syntax_template.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/libavcodec/cbs_h266_syntax_template.c
b/libavcodec/cbs_h266_syntax_template.c
index b984a12d8f..29eb9b70ed 100644
--- a/libavcodec/cbs_h266_syntax_template.c
+++ b/libavcodec/cbs_h266_syntax_template.c
@@ -2730,9 +2730,14 @@ static int FUNC(picture_header) (CodedBitstreamContext
*ctx, RWContext *rw,
0, FFMIN(6, ctb_log2_size_y) - min_cb_log2_size_y);
ue(ph_max_mtt_hierarchy_depth_intra_slice_luma,
0, 2 * (ctb_log2_size_y - min_cb_log2_size_y));
+min_qt_log2_size_intra_y =
+current->ph_log2_diff_min_qt_min_cb_intra_slice_luma +
+min_cb_log2_size_y;
if (current->ph_max_mtt_hierarchy_depth_intra_slice_luma != 0) {
ue(ph_log2_diff_max_bt_min_qt_intra_slice_luma,
- 0, ctb_log2_size_y - min_qt_log2_size_intra_y);
+ 0, (sps->sps_qtbtt_dual_tree_intra_flag ?
+ FFMIN(6, ctb_log2_size_y) :
+ ctb_log2_size_y) - min_qt_log2_size_intra_y);
ue(ph_log2_diff_max_tt_min_qt_intra_slice_luma,
0, FFMIN(6, ctb_log2_size_y) - min_qt_log2_size_intra_y);
} else {
--
2.41.0
___
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".
Re: [FFmpeg-devel] [RFC] Release 6.1
Heya, On Thu, 6 Jul 2023, at 18:04, Lynne wrote: > It's been a while since we've had a release, and we've had > a lot of new features in. > We did say we would make releases more often, and I think > it's about time we have a new release. It's a good idea. > Anything anyone wants to have merged or should we branch > off 6.1 in a few days? By experience, it requires a bit more than a few days... :D jb -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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] [RFC] Release 6.1
It's been a while since we've had a release, and we've had a lot of new features in. We did say we would make releases more often, and I think it's about time we have a new release. Anything anyone wants to have merged or should we branch off 6.1 in a few days? ___ 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] [PATCH 2/2] avcodec/cbs_h266: use exp_tile_height when checking the allowed range for pps_num_exp_tile_rows_minus1
Fixes warnings about variable set but not used.
Signed-off-by: James Almer
---
libavcodec/cbs_h266_syntax_template.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/cbs_h266_syntax_template.c
b/libavcodec/cbs_h266_syntax_template.c
index f6aae3ac51..97ca6fd32b 100644
--- a/libavcodec/cbs_h266_syntax_template.c
+++ b/libavcodec/cbs_h266_syntax_template.c
@@ -1845,7 +1845,7 @@ static int FUNC(pps) (CodedBitstreamContext *ctx,
RWContext *rw,
}
for (i = 0; i <= current->pps_num_exp_tile_rows_minus1; i++) {
ues(pps_tile_row_height_minus1[i],
-0, pic_height_in_ctbs_y - 1, 1, i);
+0, pic_height_in_ctbs_y - exp_tile_height - 1, 1, i);
exp_tile_height += current->pps_tile_row_height_minus1[i] + 1;
}
--
2.41.0
___
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] [PATCH 1/2] avcodec/cbs_h266: fix use of uninitialized value
And fix the allowed range for ph_log2_diff_max_bt_min_qt_intra_slice_luma while
at it.
Signed-off-by: James Almer
---
libavcodec/cbs_h266_syntax_template.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/libavcodec/cbs_h266_syntax_template.c
b/libavcodec/cbs_h266_syntax_template.c
index b984a12d8f..f6aae3ac51 100644
--- a/libavcodec/cbs_h266_syntax_template.c
+++ b/libavcodec/cbs_h266_syntax_template.c
@@ -2730,9 +2730,14 @@ static int FUNC(picture_header) (CodedBitstreamContext
*ctx, RWContext *rw,
0, FFMIN(6, ctb_log2_size_y) - min_cb_log2_size_y);
ue(ph_max_mtt_hierarchy_depth_intra_slice_luma,
0, 2 * (ctb_log2_size_y - min_cb_log2_size_y));
+min_qt_log2_size_intra_y =
+current->ph_log2_diff_min_qt_min_cb_intra_slice_luma +
+min_cb_log2_size_y;
if (current->ph_max_mtt_hierarchy_depth_intra_slice_luma != 0) {
ue(ph_log2_diff_max_bt_min_qt_intra_slice_luma,
- 0, ctb_log2_size_y - min_qt_log2_size_intra_y);
+ 0, (sps->sps_qtbtt_dual_tree_intra_flag ?
+ FFMIN(6, ctb_log2_size_y) :
+ ctb_log2_size_y) - min_qt_log2_size_intra_y);
ue(ph_log2_diff_max_tt_min_qt_intra_slice_luma,
0, FFMIN(6, ctb_log2_size_y) - min_qt_log2_size_intra_y);
} else {
@@ -2780,9 +2785,6 @@ static int FUNC(picture_header) (CodedBitstreamContext
*ctx, RWContext *rw,
sps->sps_log2_diff_max_tt_min_qt_intra_slice_chroma);
}
-min_qt_log2_size_intra_y =
-current->ph_log2_diff_min_qt_min_cb_intra_slice_luma +
-min_cb_log2_size_y;
if (pps->pps_cu_qp_delta_enabled_flag)
ue(ph_cu_qp_delta_subdiv_intra_slice, 0,
2 * (ctb_log2_size_y - min_qt_log2_size_intra_y +
--
2.41.0
___
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".
Re: [FFmpeg-devel] [PATCH v4] avcodec/cbs_h266: add support for Adaptation parameter set NALU type
On Thu, Jul 6, 2023 at 9:04 AM James Almer wrote:
> On 7/5/2023 9:41 PM, Nuo Mi wrote:
> >> +if (current->alf_cc_cb_filter_signal_flag)
> >> +ue(alf_cc_cb_filters_signalled_minus1, 0, 3);
> >> +else
> >> +infer(alf_cc_cb_filters_signalled_minus1, 0);
> >>
> > Not right, it will overread one filter set even
> > alf_cc_cb_filter_signal_flag is false.
>
> It will infer all values in alf_cc_cb_mapped_coeff_abs[0][0..7] and
> alf_cc_cb_coeff_sign[0][0..7] to be 0, as they are not present.
>
> Oh, my bad. thank you for the explanation.
LGTM now.
> >
> >> +for (k = 0; k <= current->alf_cc_cb_filters_signalled_minus1; k++)
> {
> >> +for (j = 0; j < 7; j++) {
> >> +if (current->alf_cc_cb_filter_signal_flag)
> >> +ubs(3, alf_cc_cb_mapped_coeff_abs[k][j], 2, k, j);
> >> +else
> >> +infer(alf_cc_cb_mapped_coeff_abs[k][j], 0);
> >> +if (current->alf_cc_cb_mapped_coeff_abs[k][j])
> >> +ubs(1, alf_cc_cb_coeff_sign[k][j], 2, k, j);
> >> +else
> >> +infer(alf_cc_cb_coeff_sign[k][j], 0);
> >> +}
> >> +}
> >> +
> >> +if (current->alf_cc_cr_filter_signal_flag)
> >> +ue(alf_cc_cr_filters_signalled_minus1, 0, 3);
> >> +else
> >> +infer(alf_cc_cr_filters_signalled_minus1, 0);
> >>
> > Not right,
>
> Same as the above.
> ___
> 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".
Re: [FFmpeg-devel] [PATCH v2] cbs_h266: add range extension support
On 7/5/2023 11:01 AM, Nuo Mi wrote: From: frankplow example clips: * 12b444vvc1_E_Sony_2 * 12b444Ietsrc_A_Kwai_2 * 10b444P16_D_Sony_2 * 12b444Iepp_A_Sharp_2 * 12b444SPetsrc_B_Kwai_2 Co-authored-by: Nuo Mi --- libavcodec/cbs_h266.h | 23 +++- libavcodec/cbs_h266_syntax_template.c | 81 +-- 2 files changed, 96 insertions(+), 8 deletions(-) Applied, thanks. ___ 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".
Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: fix intraRefreshPeriod setting
> On Jul 6, 2023, at 18:23, Timo Rothenpieler wrote:
>
> On 06/07/2023 14:00, Zhao Zhili wrote:
>> From: Zhao Zhili
>> Regression since 99dfdb45. intraRefreshPeriod access cc->gopLength,
>> which has been overwritten to NVENC_INFINITE_GOPLENGTH before.
>> Fixes #10445.
>> ---
>> libavcodec/nvenc.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>> diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
>> index 06579a502b..13fafcd246 100644
>> --- a/libavcodec/nvenc.c
>> +++ b/libavcodec/nvenc.c
>> @@ -1173,6 +1173,7 @@ static av_cold int
>> nvenc_setup_h264_config(AVCodecContext *avctx)
>> h264->enableIntraRefresh = 1;
>> h264->intraRefreshPeriod = cc->gopLength;
>> h264->intraRefreshCnt = cc->gopLength - 1;
>> +cc->gopLength = NVENC_INFINITE_GOPLENGTH;
>> #ifdef NVENC_HAVE_SINGLE_SLICE_INTRA_REFRESH
>> h264->singleSliceIntraRefresh = ctx->single_slice_intra_refresh;
>> #endif
>> @@ -1297,6 +1298,7 @@ static av_cold int
>> nvenc_setup_hevc_config(AVCodecContext *avctx)
>> hevc->enableIntraRefresh = 1;
>> hevc->intraRefreshPeriod = cc->gopLength;
>> hevc->intraRefreshCnt = cc->gopLength - 1;
>> +cc->gopLength = NVENC_INFINITE_GOPLENGTH;
>> #ifdef NVENC_HAVE_SINGLE_SLICE_INTRA_REFRESH
>> hevc->singleSliceIntraRefresh = ctx->single_slice_intra_refresh;
>> #endif
>> @@ -1415,6 +1417,7 @@ static av_cold int
>> nvenc_setup_av1_config(AVCodecContext *avctx)
>> av1->enableIntraRefresh = 1;
>> av1->intraRefreshPeriod = cc->gopLength;
>> av1->intraRefreshCnt = cc->gopLength - 1;
>> +cc->gopLength = NVENC_INFINITE_GOPLENGTH;
>>av1->idrPeriod = NVENC_INFINITE_GOPLENGTH;
>> } else if (cc->gopLength > 0) {
>> @@ -1619,9 +1622,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
>> if(ctx->single_slice_intra_refresh)
>> ctx->intra_refresh = 1;
>> -if (ctx->intra_refresh)
>> -ctx->encode_config.gopLength = NVENC_INFINITE_GOPLENGTH;
>> -
>> nvenc_recalc_surfaces(avctx);
>>nvenc_setup_rate_control(avctx);
>
> Shouldn't it be enough to move this block down a bit, below
> nvenc_setup_codec_config?
> That way the codec specific configs can still access the value, and the logic
> of setting it to infinite for intra refresh mode doesn't have to be
> duplicated everywhere.
Then people lost the context and hard to get why it should be put after
nvenc_setup_codec_config(), and might move it before by accident.
Another benefit to set cc->gopLength at here is idrPeriod can be set
to gopLength unconditionally:
http://ffmpeg.org/pipermail/ffmpeg-devel/2023-July/311694.html
To reduce code duplication, the codec specific intra_refresh configure
can be replaced by a macro, but it doesn’t looks good IMO.
>
> Though I'm not sure which way I prefer. Having it in the intra_refresh
> specific block in each codec definitely also has its advantage of keeping
> that logic in one place.
> ___
> 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".
[FFmpeg-devel] [PATCH 2/2] avcodec/nvenc: set idrPeriod to gopLength unconditionally
From: Zhao Zhili
When intra_refresh is enabled, gopLength is equal to
NVENC_INFINITE_GOPLENGTH. gopLength should be 1 at least.
Signed-off-by: Zhao Zhili
---
libavcodec/nvenc.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 13fafcd246..0b6417674e 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -1191,11 +1191,7 @@ static av_cold int
nvenc_setup_h264_config(AVCodecContext *avctx)
h264->maxNumRefFrames = ctx->dpb_size;
}
-if (ctx->intra_refresh) {
-h264->idrPeriod = NVENC_INFINITE_GOPLENGTH;
-} else if (cc->gopLength > 0) {
-h264->idrPeriod = cc->gopLength;
-}
+h264->idrPeriod = cc->gopLength;
if (IS_CBR(cc->rcParams.rateControlMode)) {
h264->outputBufferingPeriodSEI = 1;
@@ -1318,11 +1314,7 @@ static av_cold int
nvenc_setup_hevc_config(AVCodecContext *avctx)
hevc->maxNumRefFramesInDPB = ctx->dpb_size;
}
-if (ctx->intra_refresh) {
-hevc->idrPeriod = NVENC_INFINITE_GOPLENGTH;
-} else if (cc->gopLength > 0) {
-hevc->idrPeriod = cc->gopLength;
-}
+hevc->idrPeriod = cc->gopLength;
if (IS_CBR(cc->rcParams.rateControlMode)) {
hevc->outputBufferingPeriodSEI = 1;
@@ -1418,12 +1410,10 @@ static av_cold int
nvenc_setup_av1_config(AVCodecContext *avctx)
av1->intraRefreshPeriod = cc->gopLength;
av1->intraRefreshCnt = cc->gopLength - 1;
cc->gopLength = NVENC_INFINITE_GOPLENGTH;
-
-av1->idrPeriod = NVENC_INFINITE_GOPLENGTH;
-} else if (cc->gopLength > 0) {
-av1->idrPeriod = cc->gopLength;
}
+av1->idrPeriod = cc->gopLength;
+
if (IS_CBR(cc->rcParams.rateControlMode)) {
av1->enableBitstreamPadding = 1;
}
--
2.25.1
___
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] [PATCH v2 5/5] libavformat/webp: add WebP demuxer
From: Josef Zlomek
Adds the demuxer of animated WebP files.
It supports non-animated, animated, truncated, and concatenated files.
Reading from a pipe (and other non-seekable inputs) is also supported.
The WebP demuxer splits the input stream into packets containing one frame.
It also marks the key frames properly.
The loop count is ignored by default (same behaviour as animated PNG and GIF),
it may be enabled by the option '-ignore_loop 0'.
The frame rate is set according to the frame delay in the ANMF chunk.
If the delay is too low, or the image is not animated, the default frame rate
is set to 10 fps, similarly to other WebP libraries and browsers.
The fate suite was updated accordingly.
Signed-off-by: Josef Zlomek
---
Changelog | 1 +
doc/demuxers.texi | 28 +
libavformat/Makefile| 1 +
libavformat/allformats.c| 1 +
libavformat/version.h | 2 +-
libavformat/webpdec.c | 733
tests/ref/fate/webp-rgb-lena-lossless | 2 +-
tests/ref/fate/webp-rgb-lena-lossless-rgb24 | 2 +-
tests/ref/fate/webp-rgb-lossless| 2 +-
tests/ref/fate/webp-rgb-lossy-q80 | 2 +-
tests/ref/fate/webp-rgba-lossless | 2 +-
tests/ref/fate/webp-rgba-lossy-q80 | 2 +-
12 files changed, 771 insertions(+), 7 deletions(-)
create mode 100644 libavformat/webpdec.c
diff --git a/Changelog b/Changelog
index 271926ed8f..9d16537e2d 100644
--- a/Changelog
+++ b/Changelog
@@ -26,6 +26,7 @@ version :
- Bitstream filter for editing metadata in VVC streams
- Bitstream filter for converting VVC from MP4 to Annex B
- animated WebP parser/decoder
+- animated WebP demuxer
version 6.0:
- Radiance HDR image support
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index 2d33b47a56..084a9c97bb 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -936,4 +936,32 @@ which in turn, acts as a ceiling for the size of scripts
that can be read.
Default is 1 MiB.
@end table
+@section webp
+
+Animated WebP demuxer.
+
+It accepts the following options:
+
+@table @option
+@item -min_delay @var{int}
+Set the minimum valid delay between frames in milliseconds.
+Range is 0 to 6. Default value is 10.
+
+@item -max_webp_delay @var{int}
+Set the maximum valid delay between frames in milliseconds.
+Range is 0 to 16777215. Default value is 16777215 (over four hours),
+the maximum value allowed by the specification.
+
+@item -default_delay @var{int}
+Set the default delay between frames in milliseconds.
+Range is 0 to 6. Default value is 100.
+
+@item -ignore_loop @var{bool}
+WebP files can contain information to loop a certain number of times
+(or infinitely). If @option{ignore_loop} is set to true, then the loop
+setting from the input will be ignored and looping will not occur.
+If set to false, then looping will occur and will cycle the number
+of times according to the WebP. Default value is true.
+@end table
+
@c man end DEMUXERS
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 4cb00f8700..4293dad0c6 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -616,6 +616,7 @@ OBJS-$(CONFIG_WEBM_MUXER)+= matroskaenc.o
matroska.o \
av1.o avlanguage.o
OBJS-$(CONFIG_WEBM_DASH_MANIFEST_MUXER) += webmdashenc.o
OBJS-$(CONFIG_WEBM_CHUNK_MUXER) += webm_chunk.o
+OBJS-$(CONFIG_WEBP_DEMUXER) += webpdec.o
OBJS-$(CONFIG_WEBP_MUXER)+= webpenc.o
OBJS-$(CONFIG_WEBVTT_DEMUXER)+= webvttdec.o subtitles.o
OBJS-$(CONFIG_WEBVTT_MUXER) += webvttenc.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 6324952bd2..98ed52bbde 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -500,6 +500,7 @@ extern const AVInputFormat ff_webm_dash_manifest_demuxer;
extern const FFOutputFormat ff_webm_dash_manifest_muxer;
extern const FFOutputFormat ff_webm_chunk_muxer;
extern const FFOutputFormat ff_webp_muxer;
+extern const AVInputFormat ff_webp_demuxer;
extern const AVInputFormat ff_webvtt_demuxer;
extern const FFOutputFormat ff_webvtt_muxer;
extern const AVInputFormat ff_wsaud_demuxer;
diff --git a/libavformat/version.h b/libavformat/version.h
index 979952183c..787ee8c90b 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -32,7 +32,7 @@
#include "version_major.h"
#define LIBAVFORMAT_VERSION_MINOR 10
-#define LIBAVFORMAT_VERSION_MICRO 100
+#define LIBAVFORMAT_VERSION_MICRO 101
#define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
LIBAVFORMAT_VERSION_MINOR, \
diff --git a/libavformat/webpdec.c b/libavformat/webpdec.c
new file mode 100644
index 00..9f330bd246
--- /dev/null
+++ b/libavformat/webpdec.c
@@ -0,0 +1,733 @@
+/*
+ * WebP demuxer
+ * Copyrigh
[FFmpeg-devel] [PATCH v2 2/5] avcodec/webp_parser: parse each frame into one packet
---
libavcodec/webp_parser.c | 132 ++-
1 file changed, 90 insertions(+), 42 deletions(-)
diff --git a/libavcodec/webp_parser.c b/libavcodec/webp_parser.c
index bd5f94dac5..d10d06bd0e 100644
--- a/libavcodec/webp_parser.c
+++ b/libavcodec/webp_parser.c
@@ -25,13 +25,17 @@
#include "libavutil/bswap.h"
#include "libavutil/common.h"
+#include "libavutil/intreadwrite.h"
#include "parser.h"
typedef struct WebPParseContext {
ParseContext pc;
+int frame;
+int first_frame;
uint32_t fsize;
-uint32_t remaining_size;
+uint32_t remaining_file_size;
+uint32_t remaining_tag_size;
} WebPParseContext;
static int webp_parse(AVCodecParserContext *s, AVCodecContext *avctx,
@@ -41,62 +45,106 @@ static int webp_parse(AVCodecParserContext *s,
AVCodecContext *avctx,
WebPParseContext *ctx = s->priv_data;
uint64_t state = ctx->pc.state64;
int next = END_NOT_FOUND;
-int i = 0;
+int i, len;
-*poutbuf = NULL;
-*poutbuf_size = 0;
-
-restart:
-if (ctx->pc.frame_start_found <= 8) {
-for (; i < buf_size; i++) {
+for (i = 0; i < buf_size;) {
+if (ctx->remaining_tag_size) {
+/* consuming tag */
+len = FFMIN(ctx->remaining_tag_size, buf_size - i);
+i += len;
+ctx->remaining_tag_size -= len;
+ctx->remaining_file_size -= len;
+} else {
+/* scan for the next tag or file */
state = (state << 8) | buf[i];
-if (ctx->pc.frame_start_found == 0) {
-if ((state >> 32) == MKBETAG('R', 'I', 'F', 'F')) {
-ctx->fsize = av_bswap32(state);
-if (ctx->fsize > 15 && ctx->fsize <= UINT32_MAX - 10) {
-ctx->pc.frame_start_found = 1;
-ctx->fsize += 8;
+i++;
+
+if (!ctx->remaining_file_size) {
+/* scan for the next file */
+if (ctx->pc.frame_start_found == 4) {
+ctx->pc.frame_start_found = 0;
+if ((uint32_t) state == MKBETAG('W', 'E', 'B', 'P')) {
+if (ctx->frame || i != 12) {
+ctx->frame = 0;
+next = i - 12;
+state = 0;
+ctx->pc.frame_start_found = 0;
+break;
+}
+ctx->remaining_file_size = ctx->fsize - 4;
+ctx->first_frame = 1;
+continue;
}
}
-} else if (ctx->pc.frame_start_found == 8) {
-if ((state >> 32) != MKBETAG('W', 'E', 'B', 'P')) {
+if (ctx->pc.frame_start_found == 0) {
+if ((state >> 32) == MKBETAG('R', 'I', 'F', 'F')) {
+ctx->fsize = av_bswap32(state);
+if (ctx->fsize > 15 && ctx->fsize <= UINT32_MAX - 10) {
+ctx->fsize += (ctx->fsize & 1);
+ctx->pc.frame_start_found = 1;
+}
+}
+} else
+ctx->pc.frame_start_found++;
+} else {
+/* read the next tag */
+ctx->remaining_file_size--;
+if (ctx->remaining_file_size == 0) {
ctx->pc.frame_start_found = 0;
continue;
}
ctx->pc.frame_start_found++;
-ctx->remaining_size = ctx->fsize + i - 15;
-if (ctx->pc.index + i > 15) {
-next = i - 15;
-state = 0;
-break;
-} else {
-ctx->pc.state64 = 0;
-goto restart;
+if (ctx->pc.frame_start_found < 8)
+continue;
+
+switch (state >> 32) {
+case MKBETAG('A', 'N', 'M', 'F'):
+case MKBETAG('V', 'P', '8', ' '):
+case MKBETAG('V', 'P', '8', 'L'):
+if (ctx->frame) {
+ctx->frame = 0;
+next = i - 8;
+state = 0;
+ctx->pc.frame_start_found = 0;
+goto flush;
+}
+ctx->frame = 1;
+break;
+default:
+break;
}
-} else if (ctx->pc.frame_start_found)
-ctx->pc.frame_start_found++;
-}
-ctx->pc.state64 = state;
-} else {
-if (ctx->remaining_size) {
-i = FFMIN(ctx->remaining_size, buf_size);
-ctx->remaining_size -= i;
-if (ctx->remaining_size)
-
[FFmpeg-devel] [PATCH v2 4/5] avcodec/webp: make init_canvas_frame static
---
libavcodec/webp.c | 143 +++---
1 file changed, 71 insertions(+), 72 deletions(-)
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index bee43fcf19..d3e3f85dd3 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -1337,7 +1337,77 @@ static int vp8_lossy_decode_frame(AVCodecContext *avctx,
AVFrame *p,
}
return ret;
}
-int init_canvas_frame(WebPContext *s, int format, int key_frame);
+
+static int init_canvas_frame(WebPContext *s, int format, int key_frame)
+{
+AVFrame *canvas = s->canvas_frame.f;
+int height;
+int ret;
+
+// canvas is needed only for animation
+if (!(s->vp8x_flags & VP8X_FLAG_ANIMATION))
+return 0;
+
+// avoid init for non-key frames whose format and size did not change
+if (!key_frame &&
+canvas->data[0] &&
+canvas->format == format &&
+canvas->width == s->canvas_width &&
+canvas->height == s->canvas_height)
+return 0;
+
+// canvas changes within IPPP sequences will loose thread sync
+// because of the ThreadFrame reallocation and will wait forever
+// so if frame-threading is used, forbid canvas changes and unlock
+// previous frames
+if (!key_frame && canvas->data[0]) {
+if (s->avctx->thread_count > 1) {
+av_log(s->avctx, AV_LOG_WARNING, "Canvas change detected. The
output will be damaged. Use -threads 1 to try decoding with best effort.\n");
+// unlock previous frames that have sent an _await() call
+ff_thread_report_progress(&s->canvas_frame, INT_MAX, 0);
+return AVERROR_PATCHWELCOME;
+} else {
+// warn for damaged frames
+av_log(s->avctx, AV_LOG_WARNING, "Canvas change detected. The
output will be damaged.\n");
+}
+}
+
+s->avctx->pix_fmt = format;
+canvas->format= format;
+canvas->width = s->canvas_width;
+canvas->height= s->canvas_height;
+
+// VP8 decoder changed the width and height in AVCodecContext.
+// Change it back to the canvas size.
+ret = ff_set_dimensions(s->avctx, s->canvas_width, s->canvas_height);
+if (ret < 0)
+return ret;
+
+ff_thread_release_ext_buffer(s->avctx, &s->canvas_frame);
+ret = ff_thread_get_ext_buffer(s->avctx, &s->canvas_frame,
AV_GET_BUFFER_FLAG_REF);
+if (ret < 0)
+return ret;
+
+if (canvas->format == AV_PIX_FMT_ARGB) {
+height = canvas->height;
+memset(canvas->data[0], 0, height * canvas->linesize[0]);
+} else /* if (canvas->format == AV_PIX_FMT_YUVA420P) */ {
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(canvas->format);
+for (int comp = 0; comp < desc->nb_components; comp++) {
+int plane = desc->comp[comp].plane;
+
+if (comp == 1 || comp == 2)
+height = AV_CEIL_RSHIFT(canvas->height, desc->log2_chroma_h);
+else
+height = FFALIGN(canvas->height, 1 << desc->log2_chroma_h);
+
+memset(canvas->data[plane], s->transparent_yuva[plane],
+ height * canvas->linesize[plane]);
+}
+}
+
+return 0;
+}
static int webp_decode_frame_common(AVCodecContext *avctx, uint8_t *data, int
size,
int *got_frame, int key_frame)
@@ -1577,77 +1647,6 @@ exif_end:
return size;
}
-int init_canvas_frame(WebPContext *s, int format, int key_frame)
-{
-AVFrame *canvas = s->canvas_frame.f;
-int height;
-int ret;
-
-// canvas is needed only for animation
-if (!(s->vp8x_flags & VP8X_FLAG_ANIMATION))
-return 0;
-
-// avoid init for non-key frames whose format and size did not change
-if (!key_frame &&
-canvas->data[0] &&
-canvas->format == format &&
-canvas->width == s->canvas_width &&
-canvas->height == s->canvas_height)
-return 0;
-
-// canvas changes within IPPP sequences will loose thread sync
-// because of the ThreadFrame reallocation and will wait forever
-// so if frame-threading is used, forbid canvas changes and unlock
-// previous frames
-if (!key_frame && canvas->data[0]) {
-if (s->avctx->thread_count > 1) {
-av_log(s->avctx, AV_LOG_WARNING, "Canvas change detected. The
output will be damaged. Use -threads 1 to try decoding with best effort.\n");
-// unlock previous frames that have sent an _await() call
-ff_thread_report_progress(&s->canvas_frame, INT_MAX, 0);
-return AVERROR_PATCHWELCOME;
-} else {
-// warn for damaged frames
-av_log(s->avctx, AV_LOG_WARNING, "Canvas change detected. The
output will be damaged.\n");
-}
-}
-
-s->avctx->pix_fmt = format;
-canvas->format= format;
-canvas->width = s->canvas_width;
-canvas->height= s->canvas_height;
-
-// VP8 decoder changed the width and height in AVCodecContext.
-// C
[FFmpeg-devel] [PATCH v2 3/5] libavcodec/webp: add support for animated WebP decoding
From: Josef Zlomek
Fixes: 4907
Adds support for decoding of animated WebP.
The WebP decoder adds the animation related features according to the specs:
https://developers.google.com/speed/webp/docs/riff_container#animation
The frames of the animation may be smaller than the image canvas.
Therefore, the frame is decoded to a temporary frame,
then it is blended into the canvas, the canvas is copied to the output frame,
and finally the frame is disposed from the canvas.
The output to AV_PIX_FMT_YUVA420P/AV_PIX_FMT_YUV420P is still supported.
The background color is specified only as BGRA in the WebP file
so it is converted to YUVA if YUV formats are output.
Signed-off-by: Josef Zlomek
---
Changelog | 1 +
libavcodec/codec_desc.c | 3 +-
libavcodec/version.h| 2 +-
libavcodec/webp.c | 714
4 files changed, 658 insertions(+), 62 deletions(-)
diff --git a/Changelog b/Changelog
index 3876082844..271926ed8f 100644
--- a/Changelog
+++ b/Changelog
@@ -25,6 +25,7 @@ version :
- Raw VVC bitstream parser, muxer and demuxer
- Bitstream filter for editing metadata in VVC streams
- Bitstream filter for converting VVC from MP4 to Annex B
+- animated WebP parser/decoder
version 6.0:
- Radiance HDR image support
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 4406dd8318..47a38a4036 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1259,8 +1259,7 @@ static const AVCodecDescriptor codec_descriptors[] = {
.type = AVMEDIA_TYPE_VIDEO,
.name = "webp",
.long_name = NULL_IF_CONFIG_SMALL("WebP"),
-.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY |
- AV_CODEC_PROP_LOSSLESS,
+.props = AV_CODEC_PROP_LOSSY | AV_CODEC_PROP_LOSSLESS,
.mime_types= MT("image/webp"),
},
{
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 9411511e04..9f55381cf1 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -30,7 +30,7 @@
#include "version_major.h"
#define LIBAVCODEC_VERSION_MINOR 22
-#define LIBAVCODEC_VERSION_MICRO 100
+#define LIBAVCODEC_VERSION_MICRO 101
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index 15152ec8fb..bee43fcf19 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -35,12 +35,16 @@
* Exif metadata
* ICC profile
*
+ * @author Josef Zlomek, Pexeso Inc.
+ * Animation
+ *
* Unimplemented:
- * - Animation
* - XMP metadata
*/
+#include "libavcodec/packet.h"
#include "libavutil/imgutils.h"
+#include "libavutil/colorspace.h"
#define BITSTREAM_READER_LE
#include "avcodec.h"
@@ -178,6 +182,8 @@ typedef struct ImageContext {
typedef struct WebPContext {
VP8Context v; /* VP8 Context used for lossy decoding
*/
GetBitContext gb; /* bitstream reader for main image
chunk */
+ThreadFrame canvas_frame; /* ThreadFrame for canvas */
+AVFrame *frame; /* AVFrame for decoded frame */
AVFrame *alpha_frame; /* AVFrame for alpha data decompressed
from VP8L */
AVPacket *pkt; /* AVPacket to be passed to the
underlying VP8 decoder */
AVCodecContext *avctx; /* parent AVCodecContext */
@@ -189,9 +195,24 @@ typedef struct WebPContext {
int alpha_data_size;/* alpha chunk data size */
int has_exif; /* set after an EXIF chunk has been
processed */
int has_iccp; /* set after an ICCP chunk has been
processed */
-int width; /* image width */
-int height; /* image height */
-int lossless; /* indicates lossless or lossy */
+int vp8x_flags; /* global flags from VP8X chunk */
+int canvas_width; /* canvas width */
+int canvas_height; /* canvas height */
+int anmf_flags; /* frame flags from ANMF chunk */
+int width; /* frame width */
+int height; /* frame height */
+int pos_x; /* frame position X */
+int pos_y; /* frame position Y */
+int prev_anmf_flags;/* previous frame flags from ANMF
chunk */
+int prev_width; /* previous frame width */
+int prev_height;/* previous frame height */
+int prev_pos_x; /* previous frame position X */
+int prev_pos_y; /* previous frame position Y */
+int await_progress; /* value of progress to wait for */
+uint8_t background_argb[4]; /* backgroun
[FFmpeg-devel] [PATCH v2 1/5] avcodec/webp: move definitions into header
---
libavcodec/webp.c | 17 +--
libavcodec/webp.h | 55 +++
2 files changed, 56 insertions(+), 16 deletions(-)
create mode 100644 libavcodec/webp.h
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index d35cb66f8d..15152ec8fb 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -52,22 +52,7 @@
#include "thread.h"
#include "tiff_common.h"
#include "vp8.h"
-
-#define VP8X_FLAG_ANIMATION 0x02
-#define VP8X_FLAG_XMP_METADATA 0x04
-#define VP8X_FLAG_EXIF_METADATA 0x08
-#define VP8X_FLAG_ALPHA 0x10
-#define VP8X_FLAG_ICC 0x20
-
-#define MAX_PALETTE_SIZE256
-#define MAX_CACHE_BITS 11
-#define NUM_CODE_LENGTH_CODES 19
-#define HUFFMAN_CODES_PER_META_CODE 5
-#define NUM_LITERAL_CODES 256
-#define NUM_LENGTH_CODES24
-#define NUM_DISTANCE_CODES 40
-#define NUM_SHORT_DISTANCES 120
-#define MAX_HUFFMAN_CODE_LENGTH 15
+#include "webp.h"
static const uint16_t alphabet_sizes[HUFFMAN_CODES_PER_META_CODE] = {
NUM_LITERAL_CODES + NUM_LENGTH_CODES,
diff --git a/libavcodec/webp.h b/libavcodec/webp.h
new file mode 100644
index 00..90baa71182
--- /dev/null
+++ b/libavcodec/webp.h
@@ -0,0 +1,55 @@
+/*
+ * WebP image format definitions
+ * Copyright (c) 2020 Pexeso Inc.
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * WebP image format definitions.
+ */
+
+#ifndef AVCODEC_WEBP_H
+#define AVCODEC_WEBP_H
+
+#define VP8X_FLAG_ANIMATION 0x02
+#define VP8X_FLAG_XMP_METADATA 0x04
+#define VP8X_FLAG_EXIF_METADATA 0x08
+#define VP8X_FLAG_ALPHA 0x10
+#define VP8X_FLAG_ICC 0x20
+
+#define ANMF_DISPOSAL_METHOD0x01
+#define ANMF_DISPOSAL_METHOD_UNCHANGED 0x00
+#define ANMF_DISPOSAL_METHOD_BACKGROUND 0x01
+
+#define ANMF_BLENDING_METHOD0x02
+#define ANMF_BLENDING_METHOD_ALPHA 0x00
+#define ANMF_BLENDING_METHOD_OVERWRITE 0x02
+
+#define MAX_PALETTE_SIZE256
+#define MAX_CACHE_BITS 11
+#define NUM_CODE_LENGTH_CODES 19
+#define HUFFMAN_CODES_PER_META_CODE 5
+#define NUM_LITERAL_CODES 256
+#define NUM_LENGTH_CODES24
+#define NUM_DISTANCE_CODES 40
+#define NUM_SHORT_DISTANCES 120
+#define MAX_HUFFMAN_CODE_LENGTH 15
+
+
+#endif /* AVCODEC_WEBP_H */
--
2.37.1 (Apple Git-137.1)
___
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] [PATCH v2 0/5] webp: add support for animated WebP decoding
Now includes the demuxer again. Absence of the demuxer caused wrong framerate detection. We are promised a review of the demuxer code as well so it shall not rotten again with the remaining patches. Also adds loop control suggested in v1. This makes it feasable again to move some definitions into a shared header which was nak'd in v1. Patch 4/5 is still there for making changes in lavc/webp reviewable but shall be stashed when pushing. The remaining rendering issue is still worked on though we are not yet sure how to fix it because of missing reference. The good news is that this patchset already does a better rendering than libwebp v1.3.1 on the problematic file. Haven't lost hope that this can yet be improved, though. Josef Zlomek (2): libavcodec/webp: add support for animated WebP decoding libavformat/webp: add WebP demuxer Thilo Borgmann (3): avcodec/webp: move definitions into header avcodec/webp_parser: parse each frame into one packet avcodec/webp: make init_canvas_frame static Changelog | 2 + doc/demuxers.texi | 28 + libavcodec/codec_desc.c | 3 +- libavcodec/version.h| 2 +- libavcodec/webp.c | 724 +-- libavcodec/webp.h | 55 ++ libavcodec/webp_parser.c| 132 ++-- libavformat/Makefile| 1 + libavformat/allformats.c| 1 + libavformat/version.h | 2 +- libavformat/webpdec.c | 733 tests/ref/fate/webp-rgb-lena-lossless | 2 +- tests/ref/fate/webp-rgb-lena-lossless-rgb24 | 2 +- tests/ref/fate/webp-rgb-lossless| 2 +- tests/ref/fate/webp-rgb-lossy-q80 | 2 +- tests/ref/fate/webp-rgba-lossless | 2 +- tests/ref/fate/webp-rgba-lossy-q80 | 2 +- 17 files changed, 1571 insertions(+), 124 deletions(-) create mode 100644 libavcodec/webp.h create mode 100644 libavformat/webpdec.c -- 2.37.1 (Apple Git-137.1) ___ 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".
Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: fix intraRefreshPeriod setting
On 06/07/2023 14:00, Zhao Zhili wrote:
From: Zhao Zhili
Regression since 99dfdb45. intraRefreshPeriod access cc->gopLength,
which has been overwritten to NVENC_INFINITE_GOPLENGTH before.
Fixes #10445.
---
libavcodec/nvenc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 06579a502b..13fafcd246 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -1173,6 +1173,7 @@ static av_cold int nvenc_setup_h264_config(AVCodecContext
*avctx)
h264->enableIntraRefresh = 1;
h264->intraRefreshPeriod = cc->gopLength;
h264->intraRefreshCnt = cc->gopLength - 1;
+cc->gopLength = NVENC_INFINITE_GOPLENGTH;
#ifdef NVENC_HAVE_SINGLE_SLICE_INTRA_REFRESH
h264->singleSliceIntraRefresh = ctx->single_slice_intra_refresh;
#endif
@@ -1297,6 +1298,7 @@ static av_cold int nvenc_setup_hevc_config(AVCodecContext
*avctx)
hevc->enableIntraRefresh = 1;
hevc->intraRefreshPeriod = cc->gopLength;
hevc->intraRefreshCnt = cc->gopLength - 1;
+cc->gopLength = NVENC_INFINITE_GOPLENGTH;
#ifdef NVENC_HAVE_SINGLE_SLICE_INTRA_REFRESH
hevc->singleSliceIntraRefresh = ctx->single_slice_intra_refresh;
#endif
@@ -1415,6 +1417,7 @@ static av_cold int nvenc_setup_av1_config(AVCodecContext
*avctx)
av1->enableIntraRefresh = 1;
av1->intraRefreshPeriod = cc->gopLength;
av1->intraRefreshCnt = cc->gopLength - 1;
+cc->gopLength = NVENC_INFINITE_GOPLENGTH;
av1->idrPeriod = NVENC_INFINITE_GOPLENGTH;
} else if (cc->gopLength > 0) {
@@ -1619,9 +1622,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
if(ctx->single_slice_intra_refresh)
ctx->intra_refresh = 1;
-if (ctx->intra_refresh)
-ctx->encode_config.gopLength = NVENC_INFINITE_GOPLENGTH;
-
nvenc_recalc_surfaces(avctx);
nvenc_setup_rate_control(avctx);
Shouldn't it be enough to move this block down a bit, below
nvenc_setup_codec_config?
That way the codec specific configs can still access the value, and the
logic of setting it to infinite for intra refresh mode doesn't have to
be duplicated everywhere.
Though I'm not sure which way I prefer. Having it in the intra_refresh
specific block in each codec definitely also has its advantage of
keeping that logic in one place.
___
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".
Re: [FFmpeg-devel] [PATCH v4 0/7] avfilter/vf_bwdif: Add aarch64 neon functions
On Thu, 6 Jul 2023 00:19:50 +0300 (EEST), you wrote: >On Tue, 4 Jul 2023, John Cox wrote: > >> Also adds a filter_line3 method which on aarch64 neon yields approx 30% >> speedup over 2xfilter_line and a memcpy >> >> Differences from v3: >> Remove a few lines of neon in filter_line that should have been removed >> when copying from line3 >> >> Sorry about the two patch sets in quick succession, but I think I've >> applied all the requested changes and I didn't want this mistake in the >> final patchset. (The mistake was benign - it just wasted a few cycles.) >> >> John Cox (7): >> tests/checkasm: Add test for vf_bwdif filter_intra >> avfilter/vf_bwdif: Add neon for filter_intra >> tests/checkasm: Add test for vf_bwdif filter_edge >> avfilter/vf_bwdif: Add neon for filter_edge >> avfilter/vf_bwdif: Add neon for filter_line >> avfilter/vf_bwdif: Add a filter_line3 method for optimisation >> avfilter/vf_bwdif: Add neon for filter_line3 > >I think this looks ok to me, so I'll go ahead and push it. The tests pass >on x86 too, msvc/aarch64, llvm-mingw/aarch64, macOS and linux. > >Just a couple notes I didn't remember to mention before: > >- Regarding the int parameters on the stack; as long as you do have the C >wrapper functions, you don't strictly need to have the same function >signature for the NEON function as for the actual DSP function. So if >you'd have wanted to have a different signature for the NEON function >(changing it to intptr_t), that'd worked too. But I do see the benefit of >keeping it identical to the DSP function interface. If I was going to do that what I'd actually do is only pass a single prefs arg and no mrefs which would cut the number of args down to something that is register only. (In the only current use case all the other args are multiples of prefs.) >- The way of making the the C function exported and calling that for the >tail is neat, but kinda unusual within ffmpeg. In most cases (except for >parts of swscale), we can just assume and rely on buffers being aligned >enough for the SIMD vector length of the current platform, and freely >overwrite a little into the padding at the end of the lines. Not sure if >this is the case here though. > >(If it is, it's easy enough to remove those bits and make the C functions >static again as a follow-up.) Indeed - if you call the asm functions with a width that is not a multiple of 16 then you will get the rounded up number processed so you can just replace the helper function with the asm. >Also, checkasm coverage for >8bpp would be nice as mentioned, but if >someone wants to write asm for that, it should be doable to factorize the >new tests to run them for both 8 and 16 bpp. There seemed no point writing the test unless I had some asm to back it up! The asm for 9-14bit should be fairly straightforward (15-16-bit requires a little more work due to overflow) if processing 8 pels at a time (16-bytes), 16 pels at a time might be doable but there's a non-trivial chance of running out of registers. However my use case is Kodi on Pi4 where 10-bit interlace has never been seen so this isn't going to happen immediately. >That said, it looks ok enough to me so I'll push it. Thanks JC >// Martin ___ 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".
Re: [FFmpeg-devel] [PATCH 3/5] avcodec/h264_mp4toannexb_bsf: fix missing PS before IDR frames
Am 05.07.23 um 18:08 schrieb Thilo Borgmann:
Hi,
Am 19.05.23 um 18:41 schrieb Zhao Zhili:
From: Zhao Zhili
If there is a single group of SPS/PPS before an IDR frame, but no
SPS/PPS after that, we will miss the chance to reset
idr_sps_seen/idr_pps_seen. No SPS/PPS are inserted afterwards.
This patch saves in-band SPS/PPS and insert them before IDR frames
when necessary.
---
sample file h264/ps_prefix_first_idr.mp4
https://drive.google.com/file/d/1GEImeE-Wx1T0veQClSuasEJbs4fssMo9/view?usp=sharing
libavcodec/h264_mp4toannexb_bsf.c | 83 ---
tests/fate/h264.mak | 8 ++-
2 files changed, 84 insertions(+), 7 deletions(-)
diff --git a/libavcodec/h264_mp4toannexb_bsf.c
b/libavcodec/h264_mp4toannexb_bsf.c
index 846671abb6..4073c780c5 100644
--- a/libavcodec/h264_mp4toannexb_bsf.c
+++ b/libavcodec/h264_mp4toannexb_bsf.c
@@ -36,6 +36,8 @@ typedef struct H264BSFContext {
uint8_t *pps;
int sps_size;
int pps_size;
+ unsigned sps_buf_size;
+ unsigned pps_buf_size;
uint8_t length_size;
uint8_t new_idr;
uint8_t idr_sps_seen;
@@ -130,16 +132,33 @@ pps:
memset(out + total_size, 0, padding);
if (pps_offset) {
- s->sps = out;
+ uint8_t *sps;
+
s->sps_size = pps_offset;
+ sps = av_fast_realloc(s->sps, &s->sps_buf_size, s->sps_size);
+ if (!sps) {
+ av_free(out);
+ return AVERROR(ENOMEM);
+ }
+ s->sps = sps;
+ memcpy(s->sps, out, s->sps_size);
} else {
av_log(ctx, AV_LOG_WARNING,
"Warning: SPS NALU missing or invalid. "
"The resulting stream may not play.\n");
}
if (pps_offset < total_size) {
- s->pps = out + pps_offset;
+ uint8_t *pps;
+
s->pps_size = total_size - pps_offset;
+ pps = av_fast_realloc(s->pps, &s->pps_buf_size, s->pps_size);
+ if (!pps) {
+ av_freep(&s->sps);
+ av_free(out);
+ return AVERROR(ENOMEM);
+ }
+ s->pps = pps;
+ memcpy(s->pps, out + pps_offset, s->pps_size);
} else {
av_log(ctx, AV_LOG_WARNING,
"Warning: PPS NALU missing or invalid. "
@@ -153,6 +172,35 @@ pps:
return length_size;
}
+static int h264_mp4toannexb_save_ps(uint8_t **dst, int *dst_size,
+ unsigned *dst_buf_size,
+ const uint8_t *nal, uint32_t nal_size,
+ int first)
+{
+ static const uint8_t nalu_header[4] = { 0, 0, 0, 1 };
+ const int start_code_size = sizeof(nalu_header);
+ uint8_t *ptr;
+ uint32_t size;
+
+ if (first)
+ size = 0;
+ else
+ size = *dst_size;
+
+ ptr = av_fast_realloc(*dst, dst_buf_size, size + nal_size +
start_code_size);
+ if (!ptr)
+ return AVERROR(ENOMEM);
+
+ memcpy(ptr + size, nalu_header, start_code_size);
+ size += start_code_size;
+ memcpy(ptr + size, nal, nal_size);
+ size += nal_size;
+
+ *dst = ptr;
+ *dst_size = size;
+ return 0;
+}
+
static int h264_mp4toannexb_init(AVBSFContext *ctx)
{
H264BSFContext *s = ctx->priv_data;
@@ -211,6 +259,9 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx,
AVPacket *opkt)
if (j) \
av_log(__VA_ARGS__)
for (int j = 0; j < 2; j++) {
+ int sps_count = 0;
+ int pps_count = 0;
+
buf = in->data;
new_idr = s->new_idr;
sps_seen = s->idr_sps_seen;
@@ -241,8 +292,18 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx,
AVPacket *opkt)
if (unit_type == H264_NAL_SPS) {
sps_seen = new_idr = 1;
+ if (!j) {
+ h264_mp4toannexb_save_ps(&s->sps, &s->sps_size,
&s->sps_buf_size,
+ buf, nal_size, !sps_count);
+ sps_count++;
+ }
} else if (unit_type == H264_NAL_PPS) {
pps_seen = new_idr = 1;
+ if (!j) {
+ h264_mp4toannexb_save_ps(&s->pps, &s->pps_size,
&s->pps_buf_size,
+ buf, nal_size, !pps_count);
+ pps_count++;
+ }
/* if SPS has not been seen yet, prepend the AVCC one to PPS
*/
if (!sps_seen) {
if (!s->sps_size) {
@@ -262,9 +323,10 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx,
AVPacket *opkt)
/* prepend only to the first type 5 NAL unit of an IDR picture,
if no sps/pps are already present */
if (new_idr && unit_type == H264_NAL_IDR_SLICE && !sps_seen &&
!pps_seen) {
- if (ctx->par_out->extradata)
- count_or_copy(&out, &out_size, ctx->par_out->extradata,
- ctx->par_out->extradata_size,
[FFmpeg-devel] [PATCH v2 1/5] avcodec/h264_mp4toannexb_bsf: refactor start_code_size handling
From: Zhao Zhili
start_code_size depends on whether PS comes from out-of-band or
in-band. Make the code more readable.
---
libavcodec/h264_mp4toannexb_bsf.c | 34 ---
1 file changed, 27 insertions(+), 7 deletions(-)
diff --git a/libavcodec/h264_mp4toannexb_bsf.c
b/libavcodec/h264_mp4toannexb_bsf.c
index d11be455c2..7dce1ae9b6 100644
--- a/libavcodec/h264_mp4toannexb_bsf.c
+++ b/libavcodec/h264_mp4toannexb_bsf.c
@@ -43,10 +43,26 @@ typedef struct H264BSFContext {
int extradata_parsed;
} H264BSFContext;
+enum PsSource {
+PS_OUT_OF_BAND = -1,
+PS_NONE = 0,
+PS_IN_BAND = 1,
+};
+
static void count_or_copy(uint8_t **out, uint64_t *out_size,
- const uint8_t *in, int in_size, int ps, int copy)
+ const uint8_t *in, int in_size, enum PsSource ps,
int copy)
{
-uint8_t start_code_size = ps < 0 ? 0 : *out_size == 0 || ps ? 4 : 3;
+uint8_t start_code_size;
+
+if (ps == PS_OUT_OF_BAND)
+/* start code already present in out-of-band ps data, so don't need to
+ * add it manually again
+ */
+start_code_size = 0;
+else if (ps == PS_IN_BAND || *out_size == 0)
+start_code_size = 4;
+else
+start_code_size = 3;
if (copy) {
memcpy(*out + start_code_size, in, in_size);
@@ -202,6 +218,7 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx,
AVPacket *opkt)
do {
uint32_t nal_size = 0;
+enum PsSource ps;
/* possible overread ok due to padding */
for (int i = 0; i < s->length_size; i++)
@@ -230,7 +247,7 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx,
AVPacket *opkt)
if (!s->sps_size) {
LOG_ONCE(ctx, AV_LOG_WARNING, "SPS not present in the
stream, nor in AVCC, stream may be unreadable\n");
} else {
-count_or_copy(&out, &out_size, s->sps, s->sps_size,
-1, j);
+count_or_copy(&out, &out_size, s->sps, s->sps_size,
PS_OUT_OF_BAND, j);
sps_seen = 1;
}
}
@@ -246,19 +263,22 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx,
AVPacket *opkt)
if (new_idr && unit_type == H264_NAL_IDR_SLICE && !sps_seen &&
!pps_seen) {
if (ctx->par_out->extradata)
count_or_copy(&out, &out_size, ctx->par_out->extradata,
- ctx->par_out->extradata_size, -1, j);
+ ctx->par_out->extradata_size,
PS_OUT_OF_BAND, j);
new_idr = 0;
/* if only SPS has been seen, also insert PPS */
} else if (new_idr && unit_type == H264_NAL_IDR_SLICE && sps_seen
&& !pps_seen) {
if (!s->pps_size) {
LOG_ONCE(ctx, AV_LOG_WARNING, "PPS not present in the
stream, nor in AVCC, stream may be unreadable\n");
} else {
-count_or_copy(&out, &out_size, s->pps, s->pps_size, -1, j);
+count_or_copy(&out, &out_size, s->pps, s->pps_size,
PS_OUT_OF_BAND, j);
}
}
-count_or_copy(&out, &out_size, buf, nal_size,
- unit_type == H264_NAL_SPS || unit_type ==
H264_NAL_PPS, j);
+if (unit_type == H264_NAL_SPS || unit_type == H264_NAL_PPS)
+ps = PS_IN_BAND;
+else
+ps = PS_NONE;
+count_or_copy(&out, &out_size, buf, nal_size, ps, j);
if (!new_idr && unit_type == H264_NAL_SLICE) {
new_idr = 1;
sps_seen = 0;
--
2.25.1
___
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] [PATCH v2 4/5] avcodec/h264_mp4toannexb_bsf: process new extradata
From: Zhao Zhili
For fate-h264_mp4toannexb_ticket5927 and
fate-h264_mp4toannexb_ticket5927_2, they work by accident
previously. The sample file has two 'avc1' entries, and video
samples use the second one. It means packets should be decoded with
new extradata in side data. Before this patch, only extradata was
kept in the output, new extradata has been dropped. The output can
be decoded because the two extradata are almost the same, except
level indication. This patch fixed the issue, and add another
fate test.
---
libavcodec/h264_mp4toannexb_bsf.c | 37 ---
tests/fate/h264.mak | 4 +-
.../fate/h264-bsf-mp4toannexb-new-extradata | 9 +
tests/ref/fate/h264_mp4toannexb_ticket5927| 8 ++--
tests/ref/fate/h264_mp4toannexb_ticket5927_2 | 8 ++--
5 files changed, 43 insertions(+), 23 deletions(-)
create mode 100644 tests/ref/fate/h264-bsf-mp4toannexb-new-extradata
diff --git a/libavcodec/h264_mp4toannexb_bsf.c
b/libavcodec/h264_mp4toannexb_bsf.c
index 4073c780c5..120241c892 100644
--- a/libavcodec/h264_mp4toannexb_bsf.c
+++ b/libavcodec/h264_mp4toannexb_bsf.c
@@ -80,7 +80,8 @@ static void count_or_copy(uint8_t **out, uint64_t *out_size,
*out_size += start_code_size + in_size;
}
-static int h264_extradata_to_annexb(AVBSFContext *ctx)
+static int h264_extradata_to_annexb(AVBSFContext *ctx,
+uint8_t *extradata, int extradata_size)
{
H264BSFContext *s = ctx->priv_data;
GetByteContext ogb, *gb = &ogb;
@@ -91,7 +92,7 @@ static int h264_extradata_to_annexb(AVBSFContext *ctx)
const int padding = AV_INPUT_BUFFER_PADDING_SIZE;
int length_size, pps_offset = 0;
-bytestream2_init(gb, ctx->par_in->extradata, ctx->par_in->extradata_size);
+bytestream2_init(gb, extradata, extradata_size);
bytestream2_skipu(gb, 4);
@@ -169,7 +170,13 @@ pps:
ctx->par_out->extradata = out;
ctx->par_out->extradata_size = total_size;
-return length_size;
+s->length_size = length_size;
+s->new_idr = 1;
+s->idr_sps_seen = 0;
+s->idr_pps_seen = 0;
+s->extradata_parsed = 1;
+
+return 0;
}
static int h264_mp4toannexb_save_ps(uint8_t **dst, int *dst_size,
@@ -203,9 +210,7 @@ static int h264_mp4toannexb_save_ps(uint8_t **dst, int
*dst_size,
static int h264_mp4toannexb_init(AVBSFContext *ctx)
{
-H264BSFContext *s = ctx->priv_data;
int extra_size = ctx->par_in->extradata_size;
-int ret;
/* retrieve sps and pps NAL units from extradata */
if (!extra_size ||
@@ -214,15 +219,9 @@ static int h264_mp4toannexb_init(AVBSFContext *ctx)
av_log(ctx, AV_LOG_VERBOSE,
"The input looks like it is Annex B already\n");
} else if (extra_size >= 7) {
-ret = h264_extradata_to_annexb(ctx);
-if (ret < 0)
-return ret;
-
-s->length_size = ret;
-s->new_idr = 1;
-s->idr_sps_seen = 0;
-s->idr_pps_seen = 0;
-s->extradata_parsed = 1;
+return h264_extradata_to_annexb(ctx,
+ctx->par_in->extradata,
+ctx->par_in->extradata_size);
} else {
av_log(ctx, AV_LOG_ERROR, "Invalid extradata size: %d\n", extra_size);
return AVERROR_INVALIDDATA;
@@ -241,11 +240,21 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx,
AVPacket *opkt)
uint8_t *out;
uint64_t out_size;
int ret;
+size_t extradata_size;
+uint8_t *extradata;
ret = ff_bsf_get_packet(ctx, &in);
if (ret < 0)
return ret;
+extradata = av_packet_get_side_data(in, AV_PKT_DATA_NEW_EXTRADATA,
+&extradata_size);
+if (extradata) {
+ret = h264_extradata_to_annexb(ctx, extradata, extradata_size);
+if (ret < 0)
+goto fail;
+}
+
/* nothing to filter */
if (!s->extradata_parsed) {
av_packet_move_ref(opkt, in);
diff --git a/tests/fate/h264.mak b/tests/fate/h264.mak
index c7e0d0a84e..c747111ebe 100644
--- a/tests/fate/h264.mak
+++ b/tests/fate/h264.mak
@@ -225,7 +225,8 @@ FATE_H264-$(call FRAMECRC, MOV, H264) +=
fate-h264-unescaped-extradata
FATE_H264-$(call FRAMECRC, MOV, H264) += fate-h264-twofields-packet
FATE_H264-$(call DEMMUX, MOV, H264, H264_MP4TOANNEXB_BSF) +=
fate-h264-bsf-mp4toannexb \
-
fate-h264-bsf-mp4toannexb-2
+
fate-h264-bsf-mp4toannexb-2 \
+
fate-h264-bsf-mp4toannexb-new-extradata \
FATE_H264-$(call FRAMECRC, MATROSKA, H264) += fate-h264-direct-bff
FATE_H264-$(call FRAMECRC, FLV, H264, SCALE_FILTER) += fate-h264-brokensps-2580
@@ -432,6 +433,7 @@ fate-h264-bsf-
[FFmpeg-devel] [PATCH v2 3/5] avcodec/h264_mp4toannexb_bsf: fix missing PS before IDR frames
From: Zhao Zhili
If there is a single group of SPS/PPS before an IDR frame, but no
SPS/PPS after that, we will miss the chance to reset
idr_sps_seen/idr_pps_seen. No SPS/PPS are inserted afterwards.
This patch saves in-band SPS/PPS and insert them before IDR frames
when necessary.
---
v2: Use a smaller sample (48KB)
md5sum
09e56f41c2c804c3e1110bc2170aaa06 ps_prefix_first_idr.mp4
https://drive.google.com/file/d/1_jf8WmhEjiK2LKY8ZAtnCEubrHR0kJ1w/view?usp=sharing
libavcodec/h264_mp4toannexb_bsf.c | 83 ---
tests/fate/h264.mak | 8 ++-
2 files changed, 84 insertions(+), 7 deletions(-)
diff --git a/libavcodec/h264_mp4toannexb_bsf.c
b/libavcodec/h264_mp4toannexb_bsf.c
index 846671abb6..4073c780c5 100644
--- a/libavcodec/h264_mp4toannexb_bsf.c
+++ b/libavcodec/h264_mp4toannexb_bsf.c
@@ -36,6 +36,8 @@ typedef struct H264BSFContext {
uint8_t *pps;
int sps_size;
int pps_size;
+unsigned sps_buf_size;
+unsigned pps_buf_size;
uint8_t length_size;
uint8_t new_idr;
uint8_t idr_sps_seen;
@@ -130,16 +132,33 @@ pps:
memset(out + total_size, 0, padding);
if (pps_offset) {
-s->sps = out;
+uint8_t *sps;
+
s->sps_size = pps_offset;
+sps = av_fast_realloc(s->sps, &s->sps_buf_size, s->sps_size);
+if (!sps) {
+av_free(out);
+return AVERROR(ENOMEM);
+}
+s->sps = sps;
+memcpy(s->sps, out, s->sps_size);
} else {
av_log(ctx, AV_LOG_WARNING,
"Warning: SPS NALU missing or invalid. "
"The resulting stream may not play.\n");
}
if (pps_offset < total_size) {
-s->pps = out + pps_offset;
+uint8_t *pps;
+
s->pps_size = total_size - pps_offset;
+pps = av_fast_realloc(s->pps, &s->pps_buf_size, s->pps_size);
+if (!pps) {
+av_freep(&s->sps);
+av_free(out);
+return AVERROR(ENOMEM);
+}
+s->pps = pps;
+memcpy(s->pps, out + pps_offset, s->pps_size);
} else {
av_log(ctx, AV_LOG_WARNING,
"Warning: PPS NALU missing or invalid. "
@@ -153,6 +172,35 @@ pps:
return length_size;
}
+static int h264_mp4toannexb_save_ps(uint8_t **dst, int *dst_size,
+unsigned *dst_buf_size,
+const uint8_t *nal, uint32_t nal_size,
+int first)
+{
+static const uint8_t nalu_header[4] = { 0, 0, 0, 1 };
+const int start_code_size = sizeof(nalu_header);
+uint8_t *ptr;
+uint32_t size;
+
+if (first)
+size = 0;
+else
+size = *dst_size;
+
+ptr = av_fast_realloc(*dst, dst_buf_size, size + nal_size +
start_code_size);
+if (!ptr)
+return AVERROR(ENOMEM);
+
+memcpy(ptr + size, nalu_header, start_code_size);
+size += start_code_size;
+memcpy(ptr + size, nal, nal_size);
+size += nal_size;
+
+*dst = ptr;
+*dst_size = size;
+return 0;
+}
+
static int h264_mp4toannexb_init(AVBSFContext *ctx)
{
H264BSFContext *s = ctx->priv_data;
@@ -211,6 +259,9 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx,
AVPacket *opkt)
if (j) \
av_log(__VA_ARGS__)
for (int j = 0; j < 2; j++) {
+int sps_count = 0;
+int pps_count = 0;
+
buf = in->data;
new_idr = s->new_idr;
sps_seen = s->idr_sps_seen;
@@ -241,8 +292,18 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx,
AVPacket *opkt)
if (unit_type == H264_NAL_SPS) {
sps_seen = new_idr = 1;
+if (!j) {
+h264_mp4toannexb_save_ps(&s->sps, &s->sps_size,
&s->sps_buf_size,
+ buf, nal_size, !sps_count);
+sps_count++;
+}
} else if (unit_type == H264_NAL_PPS) {
pps_seen = new_idr = 1;
+if (!j) {
+h264_mp4toannexb_save_ps(&s->pps, &s->pps_size,
&s->pps_buf_size,
+ buf, nal_size, !pps_count);
+pps_count++;
+}
/* if SPS has not been seen yet, prepend the AVCC one to PPS */
if (!sps_seen) {
if (!s->sps_size) {
@@ -262,9 +323,10 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx,
AVPacket *opkt)
/* prepend only to the first type 5 NAL unit of an IDR picture, if
no sps/pps are already present */
if (new_idr && unit_type == H264_NAL_IDR_SLICE && !sps_seen &&
!pps_seen) {
-if (ctx->par_out->extradata)
-count_or_copy(&out, &out_size, ctx->par_out->extradata,
- ctx->par_out->extradata_size,
PS_OUT_OF_BAND, j);
+if (s->sps_size)
+
[FFmpeg-devel] [PATCH v2 5/5] fate/h264: move mp4toannexb_ticket5927 test to fate-h264
From: Zhao Zhili --- tests/fate/ffmpeg.mak | 6 +- tests/fate/h264.mak | 6 ++ 2 files changed, 7 insertions(+), 5 deletions(-) diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak index 2b3135b6a6..b7ced7d23c 100644 --- a/tests/fate/ffmpeg.mak +++ b/tests/fate/ffmpeg.mak @@ -207,13 +207,9 @@ FATE_SAMPLES_FFMPEG-$(call REMUX, MOV, AAC_DEMUXER AAC_DECODER AAC_PARSER AAC_AD fate-adtstoasc_ticket3715: CMD = transcode "aac" $(TARGET_SAMPLES)/aac/foo.aac\ mov "-c copy -bsf:a aac_adtstoasc" "-codec copy" -FATE_SAMPLES_FFMPEG-$(call REMUX, H264, MOV_DEMUXER H264_MP4TOANNEXB_BSF H264_PARSER H264_DECODER EXTRACT_EXTRADATA_BSF) += fate-h264_mp4toannexb_ticket2991 fate-h264_mp4toannexb_ticket5927 fate-h264_mp4toannexb_ticket5927_2 +FATE_SAMPLES_FFMPEG-$(call REMUX, H264, MOV_DEMUXER H264_MP4TOANNEXB_BSF H264_PARSER H264_DECODER EXTRACT_EXTRADATA_BSF) += fate-h264_mp4toannexb_ticket2991 fate-h264_mp4toannexb_ticket2991: CMD = transcode "mp4" $(TARGET_SAMPLES)/h264/wwwq_cut.mp4\ h264 "-c:v copy -bsf:v h264_mp4toannexb" "-codec copy" -fate-h264_mp4toannexb_ticket5927: CMD = transcode "mp4" $(TARGET_SAMPLES)/h264/thezerotheorem-cut.mp4 \ - h264 "-c:v copy -bsf:v h264_mp4toannexb -an" "-c:v copy" -fate-h264_mp4toannexb_ticket5927_2: CMD = transcode "mp4" $(TARGET_SAMPLES)/h264/thezerotheorem-cut.mp4 \ - h264 "-c:v copy -an" "-c:v copy" FATE_SAMPLES_FFMPEG-$(call TRANSCODE, MPEG4 MPEG2VIDEO, AVI, MPEGPS_DEMUXER MPEGVIDEO_DEMUXER MPEGVIDEO_PARSER EXTRACT_EXTRADATA_BSF REMOVE_EXTRADATA_BSF) += fate-ffmpeg-bsf-remove-k fate-ffmpeg-bsf-remove-r fate-ffmpeg-bsf-remove-e fate-ffmpeg-bsf-remove-k: CMD = transcode "mpeg" $(TARGET_SAMPLES)/mpeg2/matrixbench_mpeg2.lq1.mpg\ diff --git a/tests/fate/h264.mak b/tests/fate/h264.mak index c747111ebe..b30d7626c8 100644 --- a/tests/fate/h264.mak +++ b/tests/fate/h264.mak @@ -227,6 +227,8 @@ FATE_H264-$(call FRAMECRC, MOV, H264) += fate-h264-twofields-packet FATE_H264-$(call DEMMUX, MOV, H264, H264_MP4TOANNEXB_BSF) += fate-h264-bsf-mp4toannexb \ fate-h264-bsf-mp4toannexb-2 \ fate-h264-bsf-mp4toannexb-new-extradata \ + fate-h264_mp4toannexb_ticket5927 \ + fate-h264_mp4toannexb_ticket5927_2 \ FATE_H264-$(call FRAMECRC, MATROSKA, H264) += fate-h264-direct-bff FATE_H264-$(call FRAMECRC, FLV, H264, SCALE_FILTER) += fate-h264-brokensps-2580 @@ -434,6 +436,10 @@ fate-h264-bsf-mp4toannexb-2: CMD = md5 -i $(TARGET_SAMPLES) fate-h264-bsf-mp4toannexb-2: CMP = oneline fate-h264-bsf-mp4toannexb-2: REF = cffcfa6a2d0b58c9de1f5785f099f41d fate-h264-bsf-mp4toannexb-new-extradata: CMD = stream_remux mov $(TARGET_SAMPLES)/h264/extradata-reload-multi-stsd.mov h264 "-map 0:v" +fate-h264_mp4toannexb_ticket5927: CMD = transcode "mp4" $(TARGET_SAMPLES)/h264/thezerotheorem-cut.mp4 \ +h264 "-c:v copy -bsf:v h264_mp4toannexb -an" "-c:v copy" +fate-h264_mp4toannexb_ticket5927_2: CMD = transcode "mp4" $(TARGET_SAMPLES)/h264/thezerotheorem-cut.mp4 \ +h264 "-c:v copy -an" "-c:v copy" fate-h264-crop-to-container: CMD = framemd5 -i $(TARGET_SAMPLES)/h264/crop-to-container-dims-canon.mov fate-h264-direct-bff: CMD = framecrc -i $(TARGET_SAMPLES)/h264/direct-bff.mkv -- 2.25.1 ___ 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] [PATCH v2 2/5] avcodec/h264_mp4toannexb_bsf: remove pass padding size as argument
From: Zhao Zhili
It's a fixed value. There is no use case to change that.
---
libavcodec/h264_mp4toannexb_bsf.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/h264_mp4toannexb_bsf.c
b/libavcodec/h264_mp4toannexb_bsf.c
index 7dce1ae9b6..846671abb6 100644
--- a/libavcodec/h264_mp4toannexb_bsf.c
+++ b/libavcodec/h264_mp4toannexb_bsf.c
@@ -78,7 +78,7 @@ static void count_or_copy(uint8_t **out, uint64_t *out_size,
*out_size += start_code_size + in_size;
}
-static int h264_extradata_to_annexb(AVBSFContext *ctx, const int padding)
+static int h264_extradata_to_annexb(AVBSFContext *ctx)
{
H264BSFContext *s = ctx->priv_data;
GetByteContext ogb, *gb = &ogb;
@@ -86,6 +86,7 @@ static int h264_extradata_to_annexb(AVBSFContext *ctx, const
int padding)
uint32_t total_size = 0;
uint8_t *out= NULL, unit_nb, sps_done = 0;
static const uint8_t nalu_header[4] = { 0, 0, 0, 1 };
+const int padding = AV_INPUT_BUFFER_PADDING_SIZE;
int length_size, pps_offset = 0;
bytestream2_init(gb, ctx->par_in->extradata, ctx->par_in->extradata_size);
@@ -165,7 +166,7 @@ static int h264_mp4toannexb_init(AVBSFContext *ctx)
av_log(ctx, AV_LOG_VERBOSE,
"The input looks like it is Annex B already\n");
} else if (extra_size >= 7) {
-ret = h264_extradata_to_annexb(ctx, AV_INPUT_BUFFER_PADDING_SIZE);
+ret = h264_extradata_to_annexb(ctx);
if (ret < 0)
return ret;
--
2.25.1
___
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".
Re: [FFmpeg-devel] [PATCH v3 3/3] avutil/random_seed: add support for gcrypt and OpenSSL as source of randomness
Quoting James Almer (2023-07-05 15:03:07) > On 7/5/2023 9:56 AM, Anton Khirnov wrote: > > Quoting James Almer (2023-07-05 01:26:14) > >> Signed-off-by: James Almer > >> --- > >> configure | 2 +- > >> libavutil/random_seed.c | 16 > >> 2 files changed, 17 insertions(+), 1 deletion(-) > >> > >> diff --git a/configure b/configure > >> index 107d533b3e..d6e78297fe 100755 > >> --- a/configure > >> +++ b/configure > >> @@ -3892,7 +3892,7 @@ avfilter_deps="avutil" > >> avfilter_suggest="libm stdatomic" > >> avformat_deps="avcodec avutil" > >> avformat_suggest="libm network zlib stdatomic" > >> -avutil_suggest="clock_gettime ffnvcodec libm libdrm libmfx opencl user32 > >> vaapi vulkan videotoolbox corefoundation corevideo coremedia bcrypt > >> stdatomic" > >> +avutil_suggest="clock_gettime ffnvcodec gcrypt libm libdrm libmfx opencl > >> openssl user32 vaapi vulkan videotoolbox corefoundation corevideo > >> coremedia bcrypt stdatomic" > > > > What will this do exactly? > > It's a soft dependency. Only if OpenSSL or GCrypt are enabled they will > be added to avutil's library dependencies. > Notice the bcrypt entry, also used in random_seed, and all the hwcontext > backends. Ok then. -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] [PATCH 1/2] avformat/hlsenc: fall back to av_get_random_seed() when generating AES128 key
Quoting Michael Niedermayer (2023-07-06 00:54:47)
> On Wed, Jul 05, 2023 at 11:22:44AM +0200, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2023-07-05 01:50:12)
> > > On Tue, Jul 04, 2023 at 07:54:06AM +0200, Anton Khirnov wrote:
> > > > Quoting Michael Niedermayer (2023-07-04 01:50:57)
> > > > > On Mon, Jul 03, 2023 at 11:09:54PM +0200, Anton Khirnov wrote:
> > > > > > Quoting Marton Balint (2023-07-03 22:54:41)
> > > > > > > On Mon, 3 Jul 2023, Anton Khirnov wrote:
> > > > > > > My patch use av_get_random_seed() which uses what the underlying
> > > > > > > OS
> > > > > > > provides, BCrypt for Windows, /dev/urandom for Linux,
> > > > > > > arc4random() for
> > > > > > > BSD/Mac.
> > > > > >
> > > > > > IOW it's a jungle of various paths, some of which are not
> > > > > > guaranteed to
> > > > > > be cryptographically secure. I see no such guarantees for
> > > > > > arc4random()
> > > > > > from a brief web search, and the fallback get_generic_seed()
> > > > > > certainly
> > > > > > is not either. Granted it's only used on obscure architectures, but
> > > > > > still.
> > > > > >
> > > > > > The doxy even says
> > > > > > > This function tries to provide a good seed at a best effort bases.
> > > > > >
> > > > > > > You really think that these are significantly worse than
> > > > > > > OpenSSL/GCrypt, so it should not be allowed to fallback to?
> > > > > >
> > > > > > I think we should be using cryptographically secure PRNG for
> > > > > > generating
> > > > > > encryption keys, or fail when they are not available. If you want
> > > > > > to get
> > > > > > rid of the openssl dependency, IMO the best solution is a new
> > > > > > int av_random(uint8_t* buf, size_t len);
> > > > > > that guarantees either cryptographically secure randomness or an
> > > > > > error.
> > > > >
> > > > > "guarantees cryptographically secure randomness" ?
> > > > > If one defined "cryptographically secure" as "not broken publically
> > > > > as of today"
> > > > >
> > > > > Iam saying that as i think "guarantees" can be misleading in what it
> > > > > means
> > > >
> > > > I feel your snark is very much misplaced.
> > > >
> > >
> > > > I recall way more instances of broken crypto caused by overconfident
> > > > non-experts with an attitude like yours ("those silly crypto libraries,
> > > > broken all the time, how hard can it be really") than by actual
> > > > vulnerabilities in actual crypto libraries.
> > > >
> > > > In fact the highest-profile break I remember (Debian key entropy bug)
> > > > was caused precisely by non-experts fiddling with code they did not
> > > > understand.
> > >
> > > There is no snark here, at least that was not the intend
> > > Also what you say in these 2 paragraphs is true but isnt really
> > > related to what i said or meant to say
> > >
> > > these cryptographically secure PRNGS are secure as long as the
> > > currently used components and assumtations they are build on havnt
> > > been broken.
> > > Can i do better? no. but that doesnt mean that these
> > > are going to be unbroken in 30 years.
> > > just look 30 years in the past what percentage of what was believed to
> > > be secure 30 years ago has been broken today. or 50 or 100years
> > > thats really what i meant
> >
> > I still don't see what point are you trying to make here.
> > Yes, any practical cryptographic algorithm could potentially be broken
> > at some point. And everything in real life is imperfect, because we do
> > not live in the world of ideal forms.
>
> > But I don't see what practical steps could or should be taken in
> > response to this.
>
> for us i dont know but a user could
> instead of putting critical data in a system that might be broken in 30 years
> just write it down on paper and burn and grind the paper when its not needed
> anymore
> (which may or may not be an option)
>
> nothing is perfect but there are methods to transfer and destroy data which
> have a
> long track record of being secure and are simple.
>
> I think we should not make it sound like encrypting with these random numbers
> is as good as not storing/transmitting or using bits from fliping a real fair
> coin
We are not claiming that. We are claiming that the random numbers
generated are (to the best of our ability, and that of the underlying
libraries we rely on) cryptographically secure. This means suitable for
use in state of the art cryptographic algorithms like AES.
I do not think it makes sense to mistrust CSPRNGs, yet still trust AES.
--
Anton Khirnov
___
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".
Re: [FFmpeg-devel] [PATCH] lavc/libvpxenc: prevent fifo from filling up
Quoting James Zern (2023-07-05 21:16:37) > On Wed, Jul 5, 2023 at 12:15 PM James Zern wrote: > > > > Hi, > > > > +ffmpeg-dev. I took the wrong email off the reply. > > > On Mon, Jul 3, 2023 at 10:08 PM David Lemler wrote: > > > > > > Prevent the fifo used in encoding VPx videos from filling up and stopping > > > encode when it reaches 21845 items, which happens when the video has more > > > than > > > that number of frames. > > > > > > > What failure do you see, a memory allocation error? 21845 sounds > > somewhat arbitrary, maybe specific to your machine, so I'd leave it > > off the comment and commit message. > > > > > This problem occurs when performing the first pass of a 2-pass encode, as > > > otherwise, the fifo is properly drained, preventing it from overflowing. > > > > > > Problem is fixed by manually draining the fifo when performing the first > > > pass > > > of a 2-pass encode. > > > > > > Fixes the regression originally introduced in > > > 5bda4ec6c3cb6f286bb40dee4457c3c26e0f78cb > > > > > > > Anton, any comments here? Is it guaranteed by the libvpx API that no encoded packets are returned for the first pass of 2pass encoding? If so, then it probably makes most sense not to send anything to the fifo in the first place. -- Anton Khirnov ___ 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".
