Re: [FFmpeg-devel] [PATCH v1 00/11] Add support for H266/VVC
Hi Thomas, Thank you for sending the patch set. It seems the patchset is based on https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=3487 Please do not change the author's name. thank you On Wed, Oct 19, 2022 at 3:26 PM wrote: > From: Thomas Siedel > > This patch set adds H266/VVC support. > This includes parsing, muxing, demuxing, decoding and encoding. > Decoding is done using the external library VVdeC > (https://github.com/fraunhoferhhi/vvdec.git) and can be enabled with > --enable-libvvdec. > Encoding is done using the external library VVenC > (https://github.com/fraunhoferhhi/vvenc.git) and can be enabled with > --enable-libvvenc. > > Thomas Siedel (11): > avcodec: add enum types for H266/VVC > avcodec: add cbs for H266/VVC > avcodec: enable cbs for H266/VVC > avcodec: add bitstream parser for H266/VVC > avcodec: add MP4 to annexb support for H266/VVC > avformat: add demuxer and probe support for H266/VVC > avformat: add muxer support for H266/VVC > avcodec: add external decoder libvvdec for H266/VVC > avcodec: add external encoder libvvenc for H266/VVC > avformat: add ts stream types for H266/VVC > avcodec: increase minor version for H266/VVC > > configure | 16 +- > libavcodec/Makefile |6 + > libavcodec/allcodecs.c|2 + > libavcodec/bitstream_filters.c|2 + > libavcodec/cbs.c |6 + > libavcodec/cbs_h2645.c| 384 +++- > libavcodec/cbs_h266.h | 791 +++ > libavcodec/cbs_h266_syntax_template.c | 3010 + > libavcodec/cbs_internal.h |3 +- > libavcodec/cbs_sei.c | 29 + > libavcodec/h2645_parse.c | 71 +- > libavcodec/h266_metadata_bsf.c| 145 ++ > libavcodec/libvvdec.c | 511 + > libavcodec/libvvenc.c | 432 > libavcodec/parsers.c |1 + > libavcodec/version.h |2 +- > libavcodec/vvc.h | 142 ++ > libavcodec/vvc_mp4toannexb_bsf.c | 318 +++ > libavcodec/vvc_paramset.c | 972 > libavcodec/vvc_paramset.h | 429 > libavcodec/vvc_parse_extradata.c | 241 ++ > libavcodec/vvc_parse_extradata.h | 36 + > libavcodec/vvc_parser.c | 588 + > libavformat/Makefile |8 +- > libavformat/allformats.c |2 + > libavformat/demux.c |7 +- > libavformat/isom.c|1 + > libavformat/isom_tags.c |3 + > libavformat/mov.c |6 + > libavformat/movenc.c | 41 +- > libavformat/mpeg.c|3 + > libavformat/mpeg.h|1 + > libavformat/mpegts.c |2 + > libavformat/mpegts.h |1 + > libavformat/mpegtsenc.c | 65 + > libavformat/rawenc.c | 23 + > libavformat/vvc.c | 918 > libavformat/vvc.h | 99 + > libavformat/vvcdec.c | 61 + > 39 files changed, 9366 insertions(+), 12 deletions(-) > create mode 100644 libavcodec/cbs_h266.h > create mode 100644 libavcodec/cbs_h266_syntax_template.c > create mode 100644 libavcodec/h266_metadata_bsf.c > create mode 100644 libavcodec/libvvdec.c > create mode 100644 libavcodec/libvvenc.c > create mode 100644 libavcodec/vvc.h > create mode 100644 libavcodec/vvc_mp4toannexb_bsf.c > create mode 100644 libavcodec/vvc_paramset.c > create mode 100644 libavcodec/vvc_paramset.h > create mode 100644 libavcodec/vvc_parse_extradata.c > create mode 100644 libavcodec/vvc_parse_extradata.h > create mode 100644 libavcodec/vvc_parser.c > create mode 100644 libavformat/vvc.c > create mode 100644 libavformat/vvc.h > create mode 100644 libavformat/vvcdec.c > > -- > 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 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/7] avcodec/mediacodecenc: use bsf to handle crop
> On Dec 12, 2022, at 23:27, Tomas Härdin wrote: > > lör 2022-12-10 klockan 01:22 +0800 skrev Zhao Zhili: >> From: Zhao Zhili >> >> It's well known that mediacodec encoder requires 16x16 alignment. >> Use our bsf to fix the crop info. >> --- >> v3: don't change the dimension for AV_PIX_FMT_MEDIACODEC. It can have >> side effect. > > Looks like this silently crops? Is that really a good idea? We usually > don't do stuff like that. For example codecs that require even > dimensions complain loudly then fail. It’s reasonable to require even dimensions. Require dimensions aligned to 16 is uncommon. Everyone will complain why 1080x1920 doesn’t work. A lot of apps just use aligned dimensions. Users have no control on these apps. It’s not the same with FFmpeg, users (developer or not) can specify the dimension directly. If we don’t fix it, either: 1. Reject and fail directly. User complain why. 2. Accept and keep going. Sometimes it works, sometimes don’t. It depends on the device and get into a confused situation. I know there are getWidthAlignment()/getHeightAlignment() to get alignment info of codecs. The results are unreliable. The only reliable way I can find is don’t depends on those API and fix it by ourself. I’d like to know if there are better choices. > > /Tomas > > ___ > 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 5/7] avcodec/mediacodecenc: remove the strategy to create DTS
> On Dec 12, 2022, at 23:28, Tomas Härdin wrote: > > ons 2022-12-07 klockan 17:31 +0800 skrev Zhao Zhili: >> From: Zhao Zhili >> >> Use input PTS as DTS has multiple problems: >> 1. If there is no reordering, it's better to just use the output >> PTS as DTS, since encoder may change the timestamp value (do it >> on purpose or rounding error). >> >> 2. If there is reordering, input PTS should be shift a few frames >> as DTS to satisfy the requirement of PTS >= DTS. I can't find a >> reliable way to determine how many frames to be shift. For example, >> we don't known if the encoder use hierarchical B frames. The >> max_num_reorder_frames can be get from VUI, but VUI is optional. >> >> 3. Encoder dropping frames makes the case worse. Android has an >> BITRATE_MODE_CBR_FD option to allow it explicitly. > > Don't we already have code to parse this stuff from h.264 streams? We have code to parse max_num_reorder_frames, if the stream contains the field. We have some code to generate/guess DTS but doesn’t work reliably for H.264/H.265. I guess it’s hard, if not impossible. We don’t know the prediction structures. Use encoder’s input PTS as DTS works for some transport protocols like RTP, and MP4 with negative_cts_offsets, otherwise it’s broken due to PTS >= DTS. If we can and decided to implement such algorithm, it should go in a higher level, so remux raw stream works better. > > /Tomas > > ___ > 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 v3 4/4] swscale/bswapdsp: copy over bswapdsp from avcodec
From: Mark Reid
There are some places in input.c that could use it too
but they aren't currently being pass the SwsContext
---
libswscale/Makefile | 1 +
libswscale/bswapdsp.c| 59
libswscale/bswapdsp.h| 66 +
libswscale/output.c | 36 +++
libswscale/riscv/Makefile| 7 +-
libswscale/riscv/bswapdsp_init.c | 46 +
libswscale/riscv/bswapdsp_rvb.S | 68 +
libswscale/riscv/bswapdsp_rvv.S | 62
libswscale/swscale_internal.h| 3 +
libswscale/swscale_unscaled.c| 26 ++---
libswscale/utils.c | 2 +
libswscale/x86/Makefile | 6 +-
libswscale/x86/bswapdsp.asm | 157 +++
libswscale/x86/bswapdsp_init.c | 40
14 files changed, 537 insertions(+), 42 deletions(-)
create mode 100644 libswscale/bswapdsp.c
create mode 100644 libswscale/bswapdsp.h
create mode 100644 libswscale/riscv/bswapdsp_init.c
create mode 100644 libswscale/riscv/bswapdsp_rvb.S
create mode 100644 libswscale/riscv/bswapdsp_rvv.S
create mode 100644 libswscale/x86/bswapdsp.asm
create mode 100644 libswscale/x86/bswapdsp_init.c
diff --git a/libswscale/Makefile b/libswscale/Makefile
index 757997b401..4a916739c3 100644
--- a/libswscale/Makefile
+++ b/libswscale/Makefile
@@ -6,6 +6,7 @@ HEADERS = swscale.h
\
version_major.h \
OBJS = alphablend.o \
+ bswapdsp.o \
hscale.o \
hscale_fast_bilinear.o \
gamma.o \
diff --git a/libswscale/bswapdsp.c b/libswscale/bswapdsp.c
new file mode 100644
index 00..a164d89a76
--- /dev/null
+++ b/libswscale/bswapdsp.c
@@ -0,0 +1,59 @@
+/*
+ * 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
+ */
+
+#include
+
+#include "libavutil/attributes.h"
+#include "libavutil/bswap.h"
+#include "bswapdsp.h"
+
+static void bswap32_buf(uint32_t *dst, const uint32_t *src, int len)
+{
+int i;
+
+for (i = 0; i + 8 <= len; i += 8) {
+dst[i + 0] = av_bswap32(src[i + 0]);
+dst[i + 1] = av_bswap32(src[i + 1]);
+dst[i + 2] = av_bswap32(src[i + 2]);
+dst[i + 3] = av_bswap32(src[i + 3]);
+dst[i + 4] = av_bswap32(src[i + 4]);
+dst[i + 5] = av_bswap32(src[i + 5]);
+dst[i + 6] = av_bswap32(src[i + 6]);
+dst[i + 7] = av_bswap32(src[i + 7]);
+}
+for (; i < len; i++)
+dst[i + 0] = av_bswap32(src[i + 0]);
+}
+
+static void bswap16_buf(uint16_t *dst, const uint16_t *src, int len)
+{
+while (len--)
+*dst++ = av_bswap16(*src++);
+}
+
+av_cold void ff_sws_bswapdsp_init(BswapDSPContext *c)
+{
+c->bswap32_buf = bswap32_buf;
+c->bswap16_buf = bswap16_buf;
+
+#if ARCH_RISCV
+ff_sws_bswapdsp_init_riscv(c);
+#elif ARCH_X86
+ff_sws_bswapdsp_init_x86(c);
+#endif
+}
diff --git a/libswscale/bswapdsp.h b/libswscale/bswapdsp.h
new file mode 100644
index 00..f2e12d1b8f
--- /dev/null
+++ b/libswscale/bswapdsp.h
@@ -0,0 +1,66 @@
+/*
+ * 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
+ */
+
+#ifndef SWSCALE_BSWAPDSP_H
+#define SWSCALE_BSWAPDSP_H
+
+#include
+
+/**
+ * @file
+ * Optimized buffer byte swapping routines.
+ */
+
+typedef struct BswapDSPContext {
+/**
+ * Byte swap 32 bit elements in
[FFmpeg-devel] [PATCH v3 3/4] avcodec/bswapdsp: add documentation
From: Mark Reid
---
libavcodec/bswapdsp.h | 33 +
1 file changed, 33 insertions(+)
diff --git a/libavcodec/bswapdsp.h b/libavcodec/bswapdsp.h
index 10519cfd2e..ecc37d2c56 100644
--- a/libavcodec/bswapdsp.h
+++ b/libavcodec/bswapdsp.h
@@ -21,11 +21,44 @@
#include
+/**
+ * @file
+ * Optimized buffer byte swapping routines.
+ */
+
typedef struct BswapDSPContext {
+/**
+ * Byte swap 32 bit elements in a buffer.
+
+ * @param dst Destination buffer.
+ * @param src Source buffer, may be the same as dst.
+ * @param len The number of elements in the buffer.
+ *
+ */
+ /** @{ */
void (*bswap32_buf)(uint32_t *dst, const uint32_t *src, int len);
+/** @} */
+
+/**
+ * Byte swap 16 bit elements in a buffer.
+ *
+ * @param dst Destination buffer.
+ * @param src Source buffer, may be the same as dst.
+ * @param len The number of elements in the buffer.
+ *
+ */
+/** @{ */
void (*bswap16_buf)(uint16_t *dst, const uint16_t *src, int len);
+/** @} */
} BswapDSPContext;
+
+/**
+ * Initialize BswapDSPContext function pointers.
+ *
+ * @param c pointer to BswapDSPContext
+ *
+ */
void ff_bswapdsp_init(BswapDSPContext *c);
void ff_bswapdsp_init_riscv(BswapDSPContext *c);
void ff_bswapdsp_init_x86(BswapDSPContext *c);
--
2.31.1.windows.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 v3 2/4] avcodec/bswapdsp: rename bswap_buf to bswap_buf32
From: Mark Reid
---
libavcodec/4xm.c | 8
libavcodec/alsdec.c | 6 +++---
libavcodec/apedec.c | 4 ++--
libavcodec/asvdec.c | 4 ++--
libavcodec/asvenc.c | 4 ++--
libavcodec/bswapdsp.c| 8
libavcodec/bswapdsp.h| 2 +-
libavcodec/eatqi.c | 4 ++--
libavcodec/fraps.c | 4 ++--
libavcodec/huffyuvdec.c | 8
libavcodec/huffyuvenc.c | 2 +-
libavcodec/imm4.c| 6 +++---
libavcodec/mimic.c | 6 +++---
libavcodec/motionpixels.c| 4 ++--
libavcodec/mpc7.c| 4 ++--
libavcodec/rawdec.c | 2 +-
libavcodec/riscv/bswapdsp_init.c | 4 ++--
libavcodec/truemotion2.c | 4 ++--
libavcodec/truespeech.c | 2 +-
libavcodec/utvideodec.c | 12 ++--
libavcodec/utvideoenc.c | 6 +++---
libavcodec/x86/bswapdsp.asm | 2 +-
libavcodec/x86/bswapdsp_init.c | 6 +++---
libavcodec/ylc.c | 12 ++--
tests/checkasm/bswapdsp.c| 2 +-
25 files changed, 63 insertions(+), 63 deletions(-)
diff --git a/libavcodec/4xm.c b/libavcodec/4xm.c
index 5636fdef2d..a26b2f9004 100644
--- a/libavcodec/4xm.c
+++ b/libavcodec/4xm.c
@@ -469,8 +469,8 @@ static int decode_p_frame(FourXContext *f, const uint8_t
*buf, int length)
bitstream_size);
if (!f->bitstream_buffer)
return AVERROR(ENOMEM);
-f->bbdsp.bswap_buf(f->bitstream_buffer, (const uint32_t *) (buf + extra),
- bitstream_size / 4);
+f->bbdsp.bswap32_buf(f->bitstream_buffer, (const uint32_t *) (buf + extra),
+ bitstream_size / 4);
init_get_bits(&f->gb, f->bitstream_buffer, 8 * bitstream_size);
wordstream_offset = extra + bitstream_size;
@@ -813,8 +813,8 @@ static int decode_i_frame(FourXContext *f, const uint8_t
*buf, int length)
prestream_size);
if (!f->bitstream_buffer)
return AVERROR(ENOMEM);
-f->bbdsp.bswap_buf(f->bitstream_buffer, (const uint32_t *) prestream,
- prestream_size / 4);
+f->bbdsp.bswap32_buf(f->bitstream_buffer, (const uint32_t *) prestream,
+ prestream_size / 4);
init_get_bits(&f->pre_gb, f->bitstream_buffer, 8 * prestream_size);
f->last_dc = 0 * 128 * 8 * 8;
diff --git a/libavcodec/alsdec.c b/libavcodec/alsdec.c
index 4605b2248f..6f401cf890 100644
--- a/libavcodec/alsdec.c
+++ b/libavcodec/alsdec.c
@@ -1899,9 +1899,9 @@ static int decode_frame(AVCodecContext *avctx, AVFrame
*frame,
sample++)
*dest++ = av_bswap16(src[sample]);
} else {
-ctx->bdsp.bswap_buf((uint32_t *) ctx->crc_buffer,
-(uint32_t *) frame->data[0],
-ctx->cur_frame_length * channels);
+ctx->bdsp.bswap32_buf((uint32_t *) ctx->crc_buffer,
+ (uint32_t *) frame->data[0],
+ ctx->cur_frame_length * channels);
}
crc_source = ctx->crc_buffer;
} else {
diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c
index c08d13d6c2..b7856c82e5 100644
--- a/libavcodec/apedec.c
+++ b/libavcodec/apedec.c
@@ -1499,8 +1499,8 @@ static int ape_decode_frame(AVCodecContext *avctx,
AVFrame *frame,
av_fast_padded_malloc(&s->data, &s->data_size, buf_size);
if (!s->data)
return AVERROR(ENOMEM);
-s->bdsp.bswap_buf((uint32_t *) s->data, (const uint32_t *) buf,
- buf_size >> 2);
+s->bdsp.bswap32_buf((uint32_t *) s->data, (const uint32_t *) buf,
+buf_size >> 2);
memset(s->data + (buf_size & ~3), 0, buf_size & 3);
s->ptr = s->data;
s->data_end = s->data + buf_size;
diff --git a/libavcodec/asvdec.c b/libavcodec/asvdec.c
index 699aab9f8f..25dab7473f 100644
--- a/libavcodec/asvdec.c
+++ b/libavcodec/asvdec.c
@@ -253,8 +253,8 @@ static int decode_frame(AVCodecContext *avctx, AVFrame *p,
if (!a->bitstream_buffer)
return AVERROR(ENOMEM);
-c->bbdsp.bswap_buf((uint32_t *) a->bitstream_buffer,
- (const uint32_t *) buf, buf_size / 4);
+c->bbdsp.bswap32_buf((uint32_t *) a->bitstream_buffer,
+ (const uint32_t *) buf, buf_size / 4);
ret = init_get_bits8(&a->gb, a->bitstream_buffer, buf_size);
} else {
ret = init_get_bits8_le(&a->gb, buf, buf_size);
diff --git a/libavcodec/asvenc.c b/libavcodec/asvenc.c
index 9da7cbb986..2bf67d686c 100644
--- a/libavcodec/asvenc.c
+++ b/libavcodec/asvenc.c
@@ -309,8 +309,8 @@ static int encode_frame(AVCodecContext *avctx, AVPacket
*pkt,
[FFmpeg-devel] [PATCH v3 1/4] avcodec/bswapdsp: remove unused cextern
From: Mark Reid --- libavcodec/x86/bswapdsp.asm | 2 -- 1 file changed, 2 deletions(-) diff --git a/libavcodec/x86/bswapdsp.asm b/libavcodec/x86/bswapdsp.asm index 31c6c48a21..2aa235e13c 100644 --- a/libavcodec/x86/bswapdsp.asm +++ b/libavcodec/x86/bswapdsp.asm @@ -26,8 +26,6 @@ SECTION_RODATA pb_bswap32: db 3, 2, 1, 0, 7, 6, 5, 4, 11, 10, 9, 8, 15, 14, 13, 12 -cextern pb_80 - SECTION .text ; %1 = aligned/unaligned -- 2.31.1.windows.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] av1dec: fix typo in logged error
On Mon, Nov 28, 2022 at 10:39 AM Tristan Matthews wrote:
>
> ---
> libavcodec/av1dec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
> index 80da0943d4..d83c902f1f 100644
> --- a/libavcodec/av1dec.c
> +++ b/libavcodec/av1dec.c
> @@ -567,7 +567,7 @@ static int get_pixel_format(AVCodecContext *avctx)
> * implemented in the future, need remove this check.
> */
> if (!avctx->hwaccel) {
> -av_log(avctx, AV_LOG_ERROR, "Your platform doesn't suppport"
> +av_log(avctx, AV_LOG_ERROR, "Your platform doesn't support"
> " hardware accelerated AV1 decoding.\n");
> return AVERROR(ENOSYS);
> }
> --
> 2.34.1
>
Ping
___
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] avfilter/avfilter: add avfilter_print_config_formats()
Another Ping
Thanks,
softworkz
> -Original Message-
> From: Paul B Mahol
> Sent: Thursday, November 3, 2022 10:58 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: softworkz
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] avfilter/avfilter: add
> avfilter_print_config_formats()
>
> On 10/11/22, softworkz wrote:
> > From: softworkz
> >
> > Prints the following to AVBPrint:
> >
> > For pass-through filter links:
> >
> > "All (passthrough)"
> >
> > For filters using query_formats:
> >
> > "Dynamic"
> >
> > For filters using query_formats where a call to query_formats
> > succeeds (example):
> >
> > "Dynamic, Defaults: [yuv420p, yuvj420p, yuva420p, nv12, nv21]"
> >
> > For all other filters (example):
> >
> > "[s16p, s32p, fltp, dblp]"
> >
> > Except in case when the number of formats equals the number of
> > available formats:
> >
> > "All"
> >
> > Signed-off-by: softworkz
> > ---
> > doc/APIchanges | 3 ++
> > libavfilter/avfilter.c | 102
> +++-
> > libavfilter/avfilter.h | 12 +
> > libavfilter/avfiltergraph.c | 14 +++--
> > libavfilter/internal.h | 9
> > libavfilter/version.h | 4 +-
> > 6 files changed, 136 insertions(+), 8 deletions(-)
> >
> > diff --git a/doc/APIchanges b/doc/APIchanges
> > index cbb579612e..6e2a528b04 100644
> > --- a/doc/APIchanges
> > +++ b/doc/APIchanges
> > @@ -14,6 +14,9 @@ libavutil: 2021-04-27
> >
> > API changes, most recent first:
> >
> > +2022-10-11 - xx - lavf 59.50.100 - avfilter.h
> > + Add add avfilter_print_config_formats().
> > +
> > 2022-10-05 - 37d5ddc317 - lavu 57.39.100 - cpu.h
> >Add AV_CPU_FLAG_RVB_BASIC.
> >
> > diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
> > index cc5505e65b..8cc665e19c 100644
> > --- a/libavfilter/avfilter.c
> > +++ b/libavfilter/avfilter.c
> > @@ -196,6 +196,104 @@ void avfilter_link_free(AVFilterLink **link)
> > av_freep(link);
> > }
> >
> > +static unsigned get_nb_pix_fmts()
> > +{
> > +unsigned i = 0;
> > +while (av_pix_fmt_desc_get(i++)) {}
> > +return i - 1;
> > +}
> > +
> > +static unsigned get_nb_sample_fmts()
> > +{
> > +unsigned i = 0;
> > +while (av_get_sample_fmt_name(i++)) {}
> > +return i - 1;
> > +}
> > +
> > +int avfilter_print_config_formats(AVBPrint *bp, const struct
> AVFilter
> > *filter, int for_output, unsigned pad_index)
> > +{
> > +AVFilterGraph *graph;
> > +AVFilterContext *filter_context;
> > +AVFilterFormatsConfig *config;
> > +enum AVMediaType media_type;
> > +int ret = 0;
> > +
> > +if (filter->formats_state == FF_FILTER_FORMATS_PASSTHROUGH) {
> > +av_bprintf(bp, "All (passthrough)");
> > +return 0;
> > +}
> > +
> > +graph = avfilter_graph_alloc();
> > +if (!graph) {
> > +av_log(NULL, AV_LOG_ERROR, "Failed to create
> filtergraph\n");
> > +ret = AVERROR(ENOMEM);
> > +goto cleanup;
> > +}
> > +
> > +filter_context = avfilter_graph_alloc_filter(graph, filter,
> "filter");
> > +if (!filter_context) {
> > +av_log(NULL, AV_LOG_ERROR, "Failed to create filter\n");
> > +ret = AVERROR(ENOMEM);
> > +goto cleanup;
> > +}
> > +
> > +avfilter_init_str(filter_context, NULL);
> > +
> > +if (filter->formats_state == FF_FILTER_FORMATS_QUERY_FUNC)
> > +av_bprintf(bp, "Dynamic");
> > +
> > +if (!for_output && pad_index >= filter_context->nb_inputs
> > +|| for_output && pad_index >= filter_context->nb_outputs)
> > +goto cleanup;
> > +
> > +avfilter_graph_config(graph, graph);
> > +
> > +for (unsigned i = 0; i < filter_context->nb_inputs; i++)
> > +filter_context->inputs[i] = (AVFilterLink
> > *)av_mallocz(sizeof(AVFilterLink));
> > +
> > +for (unsigned i = 0; i < filter_context->nb_outputs; i++)
> > +filter_context->outputs[i] = (AVFilterLink
> > *)av_mallocz(sizeof(AVFilterLink));
> > +
> > +ff_filter_query_formats(filter_context);
> > +
> > +config = for_output ? &filter_context->outputs[pad_index]-
> >incfg :
> > &filter_context->inputs[pad_index]->outcfg;
> > +
> > +if (!config || !config->formats)
> > +goto cleanup;
> > +
> > +media_type= for_output ? filter->outputs[pad_index].type :
> > filter->inputs[pad_index].type;
> > +
> > +if (filter->formats_state == FF_FILTER_FORMATS_QUERY_FUNC) {
> > +if (config->formats && config->formats->nb_formats)
> > +av_bprintf(bp, ", Default: ");
> > +}
> > +
> > +if (config->formats == NULL)
> > +av_bprintf(bp, "unknown");
> > +else if (media_type == AVMEDIA_TYPE_VIDEO &&
> > config->formats->nb_formats == get_nb_pix_fmts() ||
> > + media_type == AVMEDIA_TYPE_AUDIO &&
> > config->formats->nb_formats == get_nb_sample_fmts())
> > +av_bprintf(bp, "All");
> > +else {
> > +for (unsigned i = 0; i < config->formats->nb_
Re: [FFmpeg-devel] [PATCH 0/3] Add option to log timing
Ping again Thanks > -Original Message- > From: ffmpegagent > Sent: Wednesday, August 24, 2022 9:38 PM > To: ffmpeg-devel@ffmpeg.org > Cc: softworkz > Subject: [PATCH 0/3] Add option to log timing > > This pathcset adds two logging flags: 'timing' and 'datetiming'. > > Usage: > > ffmpeg -loglevel +timing > > or > > ffmpeg -loglevel +datetiming > > softworkz (3): > avutil/log: support logging of date and timing information > fftools/opt_common: add timing and datetiming log flags > doc/fftools-common-opts: document log timing flags > > doc/APIchanges | 3 +++ > doc/fftools-common-opts.texi | 4 > fftools/opt_common.c | 12 > libavutil/log.c | 32 +--- > libavutil/log.h | 10 ++ > libavutil/version.h | 4 ++-- > 6 files changed, 60 insertions(+), 5 deletions(-) > > > base-commit: 48cb2c7a8a2deca40dd2f143848dd5addc25465c > Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr- > ffstaging-37%2Fsoftworkz%2Fsubmit_logtiming-v1 > Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr- > ffstaging-37/softworkz/submit_logtiming-v1 > Pull-Request: https://github.com/ffstaging/FFmpeg/pull/37 > -- > ffmpeg-codebot ___ 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 v5 2/2] avcodec/mjpegdec: add support for frame threading
In my tests, this lead to a notable speed increase with the amount
of threads used. Decoding a 720p sample gave the following results:
1 Thread: 1428 FPS
2 Threads: 2501 FPS
8 Threads: 7575 FPS
Automatic: 11326 FPS (On a 16 Core/32 Threads system)
---
libavcodec/jpeglsdec.c | 2 +-
libavcodec/mjpegdec.c | 11 ++-
libavcodec/sp5xdec.c | 4 ++--
3 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/libavcodec/jpeglsdec.c b/libavcodec/jpeglsdec.c
index ec163b8964..6e75c9b406 100644
--- a/libavcodec/jpeglsdec.c
+++ b/libavcodec/jpeglsdec.c
@@ -559,6 +559,6 @@ const FFCodec ff_jpegls_decoder = {
.init = ff_mjpeg_decode_init,
.close = ff_mjpeg_decode_end,
FF_CODEC_DECODE_CB(ff_mjpeg_decode_frame),
-.p.capabilities = AV_CODEC_CAP_DR1,
+.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
};
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index f33911e1a8..41d3f36940 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -54,6 +54,7 @@
#include "exif.h"
#include "bytestream.h"
#include "tiff_common.h"
+#include "thread.h"
static int init_default_huffman_tables(MJpegDecodeContext *s)
@@ -712,7 +713,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
s->avctx->pix_fmt,
AV_PIX_FMT_NONE,
};
-s->hwaccel_pix_fmt = ff_get_format(s->avctx, pix_fmts);
+s->hwaccel_pix_fmt = ff_thread_get_format(s->avctx, pix_fmts);
if (s->hwaccel_pix_fmt < 0)
return AVERROR(EINVAL);
@@ -728,7 +729,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
}
av_frame_unref(s->picture_ptr);
-if (ff_get_buffer(s->avctx, s->picture_ptr, AV_GET_BUFFER_FLAG_REF) <
0)
+if (ff_thread_get_buffer(s->avctx, s->picture_ptr,
AV_GET_BUFFER_FLAG_REF) < 0)
return -1;
s->picture_ptr->pict_type = AV_PICTURE_TYPE_I;
s->picture_ptr->key_frame = 1;
@@ -2954,7 +2955,7 @@ const FFCodec ff_mjpeg_decoder = {
.close = ff_mjpeg_decode_end,
FF_CODEC_DECODE_CB(ff_mjpeg_decode_frame),
.flush = decode_flush,
-.p.capabilities = AV_CODEC_CAP_DR1,
+.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
.p.max_lowres = 3,
.p.priv_class = &mjpegdec_class,
.p.profiles = NULL_IF_CONFIG_SMALL(ff_mjpeg_profiles),
@@ -2983,7 +2984,7 @@ const FFCodec ff_thp_decoder = {
.close = ff_mjpeg_decode_end,
FF_CODEC_DECODE_CB(ff_mjpeg_decode_frame),
.flush = decode_flush,
-.p.capabilities = AV_CODEC_CAP_DR1,
+.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
.p.max_lowres = 3,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
};
@@ -3062,7 +3063,7 @@ const FFCodec ff_smvjpeg_decoder = {
.close = ff_mjpeg_decode_end,
FF_CODEC_RECEIVE_FRAME_CB(smvjpeg_receive_frame),
.flush = decode_flush,
-.p.capabilities = AV_CODEC_CAP_DR1,
+.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
.caps_internal = FF_CODEC_CAP_EXPORTS_CROPPING |
FF_CODEC_CAP_SETS_PKT_DTS | FF_CODEC_CAP_INIT_CLEANUP,
};
diff --git a/libavcodec/sp5xdec.c b/libavcodec/sp5xdec.c
index dfed725500..af1b6400e1 100644
--- a/libavcodec/sp5xdec.c
+++ b/libavcodec/sp5xdec.c
@@ -103,7 +103,7 @@ const FFCodec ff_sp5x_decoder = {
.init = ff_mjpeg_decode_init,
.close = ff_mjpeg_decode_end,
FF_CODEC_DECODE_CB(sp5x_decode_frame),
-.p.capabilities = AV_CODEC_CAP_DR1,
+.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
.p.max_lowres = 3,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
};
@@ -119,7 +119,7 @@ const FFCodec ff_amv_decoder = {
.close = ff_mjpeg_decode_end,
FF_CODEC_DECODE_CB(sp5x_decode_frame),
.p.max_lowres = 3,
-.p.capabilities = AV_CODEC_CAP_DR1,
+.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
};
#endif
--
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 v5 1/2] lavc: convert frame threading to the receive_frame() pattern
From: Anton Khirnov
Reorganize the code such that the frame threading code does not call the
decoders directly, but instead calls back into the generic decoding
code. This avoids duplicating the logic that wraps the decoder
invocation and will be useful in the following commits.
---
libavcodec/decode.c| 62 ++---
libavcodec/decode.h| 7 +
libavcodec/internal.h | 7 +
libavcodec/pthread_frame.c | 265 -
libavcodec/thread.h| 18 +--
5 files changed, 236 insertions(+), 123 deletions(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index b184c3f55b..672bf472dd 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -180,6 +180,11 @@ fail:
return ret;
}
+#if !HAVE_THREADS
+#define ff_thread_get_packet(avctx, pkt) (AVERROR_BUG)
+#define ff_thread_receive_frame(avctx, frame) (AVERROR_BUG)
+#endif
+
int ff_decode_get_packet(AVCodecContext *avctx, AVPacket *pkt)
{
AVCodecInternal *avci = avctx->internal;
@@ -188,7 +193,14 @@ int ff_decode_get_packet(AVCodecContext *avctx, AVPacket
*pkt)
if (avci->draining)
return AVERROR_EOF;
-ret = av_bsf_receive_packet(avci->bsf, pkt);
+/* If we are a worker thread, get the next packet from the threading
+ * context. Otherwise we are the main (user-facing) context, so we get the
+ * next packet from the input filterchain.
+ */
+if (avctx->internal->is_frame_mt)
+ret = ff_thread_get_packet(avctx, pkt);
+else
+ret = av_bsf_receive_packet(avci->bsf, pkt);
if (ret == AVERROR_EOF)
avci->draining = 1;
if (ret < 0)
@@ -273,30 +285,25 @@ static inline int decode_simple_internal(AVCodecContext
*avctx, AVFrame *frame,
return AVERROR_EOF;
if (!pkt->data &&
-!(avctx->codec->capabilities & AV_CODEC_CAP_DELAY ||
- avctx->active_thread_type & FF_THREAD_FRAME))
+!(avctx->codec->capabilities & AV_CODEC_CAP_DELAY))
return AVERROR_EOF;
got_frame = 0;
-if (HAVE_THREADS && avctx->active_thread_type & FF_THREAD_FRAME) {
-ret = ff_thread_decode_frame(avctx, frame, &got_frame, pkt);
-} else {
-ret = codec->cb.decode(avctx, frame, &got_frame, pkt);
-
-if (!(codec->caps_internal & FF_CODEC_CAP_SETS_PKT_DTS))
-frame->pkt_dts = pkt->dts;
-if (avctx->codec->type == AVMEDIA_TYPE_VIDEO) {
-if(!avctx->has_b_frames)
-frame->pkt_pos = pkt->pos;
-//FIXME these should be under if(!avctx->has_b_frames)
-/* get_buffer is supposed to set frame parameters */
-if (!(avctx->codec->capabilities & AV_CODEC_CAP_DR1)) {
-if (!frame->sample_aspect_ratio.num)
frame->sample_aspect_ratio = avctx->sample_aspect_ratio;
-if (!frame->width)frame->width
= avctx->width;
-if (!frame->height) frame->height
= avctx->height;
-if (frame->format == AV_PIX_FMT_NONE) frame->format
= avctx->pix_fmt;
-}
+ret = codec->cb.decode(avctx, frame, &got_frame, pkt);
+
+if (!(codec->caps_internal & FF_CODEC_CAP_SETS_PKT_DTS))
+frame->pkt_dts = pkt->dts;
+if (avctx->codec->type == AVMEDIA_TYPE_VIDEO) {
+if(!avctx->has_b_frames)
+frame->pkt_pos = pkt->pos;
+//FIXME these should be under if(!avctx->has_b_frames)
+/* get_buffer is supposed to set frame parameters */
+if (!(avctx->codec->capabilities & AV_CODEC_CAP_DR1)) {
+if (!frame->sample_aspect_ratio.num) frame->sample_aspect_ratio =
avctx->sample_aspect_ratio;
+if (!frame->width)frame->width =
avctx->width;
+if (!frame->height) frame->height =
avctx->height;
+if (frame->format == AV_PIX_FMT_NONE) frame->format =
avctx->pix_fmt;
}
}
emms_c();
@@ -546,7 +553,7 @@ static int decode_simple_receive_frame(AVCodecContext
*avctx, AVFrame *frame)
return 0;
}
-static int decode_receive_frame_internal(AVCodecContext *avctx, AVFrame *frame)
+int ff_decode_receive_frame_internal(AVCodecContext *avctx, AVFrame *frame)
{
AVCodecInternal *avci = avctx->internal;
const FFCodec *const codec = ffcodec(avctx->codec);
@@ -569,6 +576,17 @@ static int decode_receive_frame_internal(AVCodecContext
*avctx, AVFrame *frame)
return ok;
}
+return ret;
+}
+
+static int decode_receive_frame_internal(AVCodecContext *avctx, AVFrame *frame)
+{
+int ret;
+if (avctx->active_thread_type & FF_THREAD_FRAME)
+ret = ff_thread_receive_frame(avctx, frame);
+else
+ret = ff_decode_receive_frame_internal(avctx, frame);
+
if (!ret) {
frame->best_effort_timestamp = guess_correct_pts(avctx,
Re: [FFmpeg-devel] [PATCH] configure: Change _cflags_noopt for MSVC to -Od
Am Mo., 12. Dez. 2022 um 22:02 Uhr schrieb Thomson Tan : > > I built the latest FFmpeg with WSL2+MSVC on Windows. Tried configure > with --disable-optimizations, but still got an optimized build which makes > it hard to set breakpoint on hot functions (likely inlined). Of course, this explains why you wrote the patch. But I still wonder how you tested it. Please find out what top-posting means and avoid it here, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] configure: Change _cflags_noopt for MSVC to -Od
I built the latest FFmpeg with WSL2+MSVC on Windows. Tried configure with
--disable-optimizations, but still got an optimized build which makes it
hard to set breakpoint on hot functions (likely inlined).
On Mon, Dec 12, 2022 at 12:49 PM Carl Eugen Hoyos
wrote:
> Am Mo., 12. Dez. 2022 um 19:30 Uhr schrieb :
> >
> > Currently -O1 is set to _cflags_noopt, but -O1 is actually for size
> > optimization instead of no-opt which causes size optimized binaries
> > been built with --disable-optimizations.
> >
> > Signed-off-by: Thomson Tan
> > ---
> > configure | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/configure b/configure
> > index f4eedfc207..388d518345 100755
> > --- a/configure
> > +++ b/configure
> > @@ -4825,7 +4825,7 @@ probe_cc(){
> > _DEPFLAGS='$(CPPFLAGS) $(CFLAGS) -showIncludes -Zs'
> > _cflags_speed="-O2"
> > _cflags_size="-O1"
> > -_cflags_noopt="-O1"
> > +_cflags_noopt="-Od"
>
> I am curious:
> How did you test this patch?
>
> Thank you, Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] configure: Change _cflags_noopt for MSVC to -Od
Am Mo., 12. Dez. 2022 um 19:30 Uhr schrieb :
>
> Currently -O1 is set to _cflags_noopt, but -O1 is actually for size
> optimization instead of no-opt which causes size optimized binaries
> been built with --disable-optimizations.
>
> Signed-off-by: Thomson Tan
> ---
> configure | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index f4eedfc207..388d518345 100755
> --- a/configure
> +++ b/configure
> @@ -4825,7 +4825,7 @@ probe_cc(){
> _DEPFLAGS='$(CPPFLAGS) $(CFLAGS) -showIncludes -Zs'
> _cflags_speed="-O2"
> _cflags_size="-O1"
> -_cflags_noopt="-O1"
> +_cflags_noopt="-Od"
I am curious:
How did you test this patch?
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] configure: Change _cflags_noopt for MSVC to -Od
On 12.12.2022 21:32, Thomson Tan wrote: Thanks. Wondering why and where DCE is needed in FFmpeg build? Every single time "HAVE_SOMETHING" or "CONFIG_SOMETHING" is used in a normal if() instead of a pre-processor #if. That's used in a lot of places all over the codebase. ___ 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] configure: Change _cflags_noopt for MSVC to -Od
Thanks. Wondering why and where DCE is needed in FFmpeg build? On Mon, Dec 12, 2022 at 12:26 PM Timo Rothenpieler wrote: > On 12.12.2022 19:30, lilo...@gmail.com wrote: > > Currently -O1 is set to _cflags_noopt, but -O1 is actually for size > > optimization instead of no-opt which causes size optimized binaries > > been built with --disable-optimizations. > > It's like this very intentionally, since ffmpeg relies on > dead-code-elimination in a lot of places, which MSVC does not perform > when optimizations are turned off. > So optimizations cannot be fully turned off on MSVC. > ___ > 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] configure: Change _cflags_noopt for MSVC to -Od
On 12.12.2022 19:30, lilo...@gmail.com wrote: Currently -O1 is set to _cflags_noopt, but -O1 is actually for size optimization instead of no-opt which causes size optimized binaries been built with --disable-optimizations. It's like this very intentionally, since ffmpeg relies on dead-code-elimination in a lot of places, which MSVC does not perform when optimizations are turned off. So optimizations cannot be fully turned off on MSVC. ___ 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] libavcodec: Make disposition forced work with mov_text subtitles.
We are not currently able to force mov_text subtitles by setting
-disposition:s:0 +forced or equivalent. By setting the forced flags in
movtextenc as specifid in
https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html
subtitles can be forced as expected in VLC and similar players.
Copy AVStream disposition to AVCodecContext and use to set
DISPLAY_FLAG_ALL_SAMPLES_FORCED in movtextenc.c.
Signed-off-by: facefunk
---
fftools/ffmpeg_mux_init.c | 5 +
libavcodec/avcodec.h | 11 +++
libavcodec/movtextenc.c | 41 ++-
3 files changed, 56 insertions(+), 1 deletion(-)
diff --git a/fftools/ffmpeg_mux_init.c b/fftools/ffmpeg_mux_init.c
index 0280759b05..86cc304b71 100644
--- a/fftools/ffmpeg_mux_init.c
+++ b/fftools/ffmpeg_mux_init.c
@@ -1717,6 +1717,11 @@ static int set_dispositions(Muxer *mux, const
OptionsContext *o)
if (ret < 0)
goto finish;
+
+// For output streams, Set subtitle flags to forced when stream
+// disposition is forced.
+if(ost->enc_ctx && ost->st->disposition & AV_DISPOSITION_FORCED)
+ost->enc_ctx->subtitle_flags |= AV_SUBTITLE_FLAG_FORCED;
}
} else {
// For each media type with more than one stream, find a suitable
stream to
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 0ac581d660..2735a1c847 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2057,6 +2057,17 @@ typedef struct AVCodecContext {
* The decoder can then override during decoding as needed.
*/
AVChannelLayout ch_layout;
+
+/**
+ * Subtitle codecs only. Bit set of AV_SUBTITLE_FLAG_*.
+ *
+ * Some subtitle codecs may use this field to determine the subtitle
+ * display flags to encode.
+ *
+ * - encoding: set by user
+ * - decoding: unused
+ */
+int subtitle_flags;
} AVCodecContext;
/**
diff --git a/libavcodec/movtextenc.c b/libavcodec/movtextenc.c
index 7aa74d7c9d..875e003fc4 100644
--- a/libavcodec/movtextenc.c
+++ b/libavcodec/movtextenc.c
@@ -50,6 +50,40 @@
#define FONTSIZE_SCALE(s,fs) ((fs) * (s)->font_scale_factor + 0.5)
#define av_bprint_append_any(buf, data, size) av_bprint_append_data(buf,
((const char*)data), size)
+/**
+ *
https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html
+ *
+ * Display flags
+ * A 32-bit integer containing flags that describe how the subtitle text should
+ * be drawn.
+ * The following flags are defined:
+ *
+ * Vertical placement
+ * Controls vertical placement of the subtitle text.
+ * If this flag is set, the subtitle media handler uses the top coordinate of
+ * the display bounds of the override 'tbox' text box to determine the
+ * subtitle’s vertical placement as described in Subtitle Track Header Size
+ * and Placement. Otherwise, the subtitle displays at the bottom of the video.
+ */
+#define DISPLAY_FLAG_VERTICAL_PLACEMENT_TOP 0x2000
+
+/**
+ * Some samples are forced
+ * Indicates whether any subtitle samples contain forced atoms. If this flag is
+ * set, at least one sample contains a forced ('frcd') atom as described in
+ * Subtitle Sample Data.
+ */
+#define DISPLAY_FLAG_SOME_SAMPLES_FORCED0x4000
+
+/**
+ * All samples are forced
+ * If this flag is set, the subtitle media handler treats all samples as forced
+ * subtitles, regardless of the presence or absence of a 'frcd' atom.
+ * If this flag is set, the Some Samples Are Forced flag must also be set
+ * (making 0xC000).
+ */
+#define DISPLAY_FLAG_ALL_SAMPLES_FORCED 0x8000
+
typedef struct {
uint16_t style_start;
uint16_t style_end;
@@ -183,6 +217,7 @@ static int encode_sample_description(AVCodecContext *avctx)
int font_names_total_len = 0;
MovTextContext *s = avctx->priv_data;
uint8_t buf[30], *p = buf;
+uint32_t display_flags = 0;
// 0x00, 0x00, 0x00, 0x00, // uint32_t displayFlags
// 0x01, // int8_t horizontal-justification
@@ -241,7 +276,11 @@ static int encode_sample_description(AVCodecContext *avctx)
(255 - ((uint32_t)style->back_color >> 24));
}
-bytestream_put_be32(&p, 0); // displayFlags
+if (avctx->subtitle_flags & AV_SUBTITLE_FLAG_FORCED)
+display_flags = DISPLAY_FLAG_SOME_SAMPLES_FORCED |
+DISPLAY_FLAG_ALL_SAMPLES_FORCED;
+
+bytestream_put_be32(&p, display_flags); // displayFlags
bytestream_put_be16(&p, 0x01FF); // horizontal/vertical justification (2x
int8_t)
bytestream_put_be32(&p, back_color);
bytestream_put_be64(&p, 0); // BoxRecord - 4xint16_t: top, left, bottom,
right
--
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.
Re: [FFmpeg-devel] [PATCH] swscale/output: Use av_sat_add32 in yuv2rgba64 templates to avoid underflow
Here is the problematic input video attached.
On Mon, Dec 12, 2022 at 3:08 PM Drew Dunne wrote:
> Previously I sent this patch to solve an overflow in these templates. That
> patch wasn't used in favor of one that biased the output calculations to
> avoid the double clipping. Now I've found an underflow case, which I've put
> the command below, and I'll attach an input image in a reply.
>
> ./ffmpeg \
> -f rawvideo -video_size 64x64 -pixel_format yuva420p10le \
> -i yuv2rgb_underflow_w64h64.yuva \
> -filter_complex \
>
> "scale=flags=bicubic+full_chroma_int+full_chroma_inp+bitexact+accurate_rnd:in_color_matrix=bt2020:out_color_matrix=bt2020:in_range=mpeg:out_range=mpeg,format=rgba64[out]"
> \
> -f rawvideo -codec:v:0 rawvideo -pixel_format rgba64 -map '[out]' \
> -y underflow_w64h64.rgba64
>
> The previous overflow case was in this thread:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2022-November/303532.html
>
> ---
> libswscale/output.c | 96 ++---
> 1 file changed, 48 insertions(+), 48 deletions(-)
>
> diff --git a/libswscale/output.c b/libswscale/output.c
> index 5c85bff971..8abf043d73 100644
> --- a/libswscale/output.c
> +++ b/libswscale/output.c
> @@ -1109,20 +1109,20 @@ yuv2rgba64_X_c_template(SwsContext *c, const
> int16_t *lumFilter,
> B =U * c->yuv2rgb_u2b_coeff;
>
> // 8 bits: 30 - 22 = 8 bits, 16 bits: 30 bits - 14 = 16 bits
> -output_pixel(&dest[0], av_clip_uintp2(((R_B + Y1) >> 14) +
> (1<<15), 16));
> -output_pixel(&dest[1], av_clip_uintp2((( G + Y1) >> 14) +
> (1<<15), 16));
> -output_pixel(&dest[2], av_clip_uintp2(((B_R + Y1) >> 14) +
> (1<<15), 16));
> +output_pixel(&dest[0], av_clip_uintp2(((av_sat_add32(R_B, Y1)) >>
> 14) + (1<<15), 16));
> +output_pixel(&dest[1], av_clip_uintp2(((av_sat_add32( G, Y1)) >>
> 14) + (1<<15), 16));
> +output_pixel(&dest[2], av_clip_uintp2(((av_sat_add32(B_R, Y1)) >>
> 14) + (1<<15), 16));
> if (eightbytes) {
> output_pixel(&dest[3], av_clip_uintp2(A1 , 30) >> 14);
> -output_pixel(&dest[4], av_clip_uintp2(((R_B + Y2) >> 14) +
> (1<<15), 16));
> -output_pixel(&dest[5], av_clip_uintp2((( G + Y2) >> 14) +
> (1<<15), 16));
> -output_pixel(&dest[6], av_clip_uintp2(((B_R + Y2) >> 14) +
> (1<<15), 16));
> +output_pixel(&dest[4], av_clip_uintp2(((av_sat_add32(R_B,
> Y2)) >> 14) + (1<<15), 16));
> +output_pixel(&dest[5], av_clip_uintp2(((av_sat_add32( G,
> Y2)) >> 14) + (1<<15), 16));
> +output_pixel(&dest[6], av_clip_uintp2(((av_sat_add32(B_R,
> Y2)) >> 14) + (1<<15), 16));
> output_pixel(&dest[7], av_clip_uintp2(A2 , 30) >> 14);
> dest += 8;
> } else {
> -output_pixel(&dest[3], av_clip_uintp2(((R_B + Y2) >> 14) +
> (1<<15), 16));
> -output_pixel(&dest[4], av_clip_uintp2((( G + Y2) >> 14) +
> (1<<15), 16));
> -output_pixel(&dest[5], av_clip_uintp2(((B_R + Y2) >> 14) +
> (1<<15), 16));
> +output_pixel(&dest[3], av_clip_uintp2(((av_sat_add32(R_B,
> Y2)) >> 14) + (1<<15), 16));
> +output_pixel(&dest[4], av_clip_uintp2(((av_sat_add32( G,
> Y2)) >> 14) + (1<<15), 16));
> +output_pixel(&dest[5], av_clip_uintp2(((av_sat_add32(B_R,
> Y2)) >> 14) + (1<<15), 16));
> dest += 6;
> }
> }
> @@ -1175,20 +1175,20 @@ yuv2rgba64_2_c_template(SwsContext *c, const
> int32_t *buf[2],
> A2 += 1 << 13;
> }
>
> -output_pixel(&dest[0], av_clip_uintp2(((R_B + Y1) >> 14) +
> (1<<15), 16));
> -output_pixel(&dest[1], av_clip_uintp2((( G + Y1) >> 14) +
> (1<<15), 16));
> -output_pixel(&dest[2], av_clip_uintp2(((B_R + Y1) >> 14) +
> (1<<15), 16));
> +output_pixel(&dest[0], av_clip_uintp2(((av_sat_add32(R_B, Y1)) >>
> 14) + (1<<15), 16));
> +output_pixel(&dest[1], av_clip_uintp2(((av_sat_add32( G, Y1)) >>
> 14) + (1<<15), 16));
> +output_pixel(&dest[2], av_clip_uintp2(((av_sat_add32(B_R, Y1)) >>
> 14) + (1<<15), 16));
> if (eightbytes) {
> output_pixel(&dest[3], av_clip_uintp2(A1 , 30) >> 14);
> -output_pixel(&dest[4], av_clip_uintp2(((R_B + Y2) >> 14) +
> (1<<15), 16));
> -output_pixel(&dest[5], av_clip_uintp2((( G + Y2) >> 14) +
> (1<<15), 16));
> -output_pixel(&dest[6], av_clip_uintp2(((B_R + Y2) >> 14) +
> (1<<15), 16));
> +output_pixel(&dest[4], av_clip_uintp2(((av_sat_add32(R_B,
> Y2)) >> 14) + (1<<15), 16));
> +output_pixel(&dest[5], av_clip_uintp2(((av_sat_add32( G,
> Y2)) >> 14) + (1<<15), 16));
> +output_pixel(&dest[6], av_clip_uintp2(((av_sat_add32(B_R,
> Y2)) >> 14) + (1<<15), 16));
> output_pixel(&dest[7], av_clip_uintp2(A2 , 30) >> 14);
> dest += 8;
> } else {
> -output_pixel(&de
[FFmpeg-devel] [PATCH] swscale/output: Use av_sat_add32 in yuv2rgba64 templates to avoid underflow
Previously I sent this patch to solve an overflow in these templates. That
patch wasn't used in favor of one that biased the output calculations to
avoid the double clipping. Now I've found an underflow case, which I've put
the command below, and I'll attach an input image in a reply.
./ffmpeg \
-f rawvideo -video_size 64x64 -pixel_format yuva420p10le \
-i yuv2rgb_underflow_w64h64.yuva \
-filter_complex \
"scale=flags=bicubic+full_chroma_int+full_chroma_inp+bitexact+accurate_rnd:in_color_matrix=bt2020:out_color_matrix=bt2020:in_range=mpeg:out_range=mpeg,format=rgba64[out]"
\
-f rawvideo -codec:v:0 rawvideo -pixel_format rgba64 -map '[out]' \
-y underflow_w64h64.rgba64
The previous overflow case was in this thread:
https://ffmpeg.org/pipermail/ffmpeg-devel/2022-November/303532.html
---
libswscale/output.c | 96 ++---
1 file changed, 48 insertions(+), 48 deletions(-)
diff --git a/libswscale/output.c b/libswscale/output.c
index 5c85bff971..8abf043d73 100644
--- a/libswscale/output.c
+++ b/libswscale/output.c
@@ -1109,20 +1109,20 @@ yuv2rgba64_X_c_template(SwsContext *c, const int16_t
*lumFilter,
B =U * c->yuv2rgb_u2b_coeff;
// 8 bits: 30 - 22 = 8 bits, 16 bits: 30 bits - 14 = 16 bits
-output_pixel(&dest[0], av_clip_uintp2(((R_B + Y1) >> 14) + (1<<15),
16));
-output_pixel(&dest[1], av_clip_uintp2((( G + Y1) >> 14) + (1<<15),
16));
-output_pixel(&dest[2], av_clip_uintp2(((B_R + Y1) >> 14) + (1<<15),
16));
+output_pixel(&dest[0], av_clip_uintp2(((av_sat_add32(R_B, Y1)) >> 14)
+ (1<<15), 16));
+output_pixel(&dest[1], av_clip_uintp2(((av_sat_add32( G, Y1)) >> 14)
+ (1<<15), 16));
+output_pixel(&dest[2], av_clip_uintp2(((av_sat_add32(B_R, Y1)) >> 14)
+ (1<<15), 16));
if (eightbytes) {
output_pixel(&dest[3], av_clip_uintp2(A1 , 30) >> 14);
-output_pixel(&dest[4], av_clip_uintp2(((R_B + Y2) >> 14) +
(1<<15), 16));
-output_pixel(&dest[5], av_clip_uintp2((( G + Y2) >> 14) +
(1<<15), 16));
-output_pixel(&dest[6], av_clip_uintp2(((B_R + Y2) >> 14) +
(1<<15), 16));
+output_pixel(&dest[4], av_clip_uintp2(((av_sat_add32(R_B, Y2)) >>
14) + (1<<15), 16));
+output_pixel(&dest[5], av_clip_uintp2(((av_sat_add32( G, Y2)) >>
14) + (1<<15), 16));
+output_pixel(&dest[6], av_clip_uintp2(((av_sat_add32(B_R, Y2)) >>
14) + (1<<15), 16));
output_pixel(&dest[7], av_clip_uintp2(A2 , 30) >> 14);
dest += 8;
} else {
-output_pixel(&dest[3], av_clip_uintp2(((R_B + Y2) >> 14) +
(1<<15), 16));
-output_pixel(&dest[4], av_clip_uintp2((( G + Y2) >> 14) +
(1<<15), 16));
-output_pixel(&dest[5], av_clip_uintp2(((B_R + Y2) >> 14) +
(1<<15), 16));
+output_pixel(&dest[3], av_clip_uintp2(((av_sat_add32(R_B, Y2)) >>
14) + (1<<15), 16));
+output_pixel(&dest[4], av_clip_uintp2(((av_sat_add32( G, Y2)) >>
14) + (1<<15), 16));
+output_pixel(&dest[5], av_clip_uintp2(((av_sat_add32(B_R, Y2)) >>
14) + (1<<15), 16));
dest += 6;
}
}
@@ -1175,20 +1175,20 @@ yuv2rgba64_2_c_template(SwsContext *c, const int32_t
*buf[2],
A2 += 1 << 13;
}
-output_pixel(&dest[0], av_clip_uintp2(((R_B + Y1) >> 14) + (1<<15),
16));
-output_pixel(&dest[1], av_clip_uintp2((( G + Y1) >> 14) + (1<<15),
16));
-output_pixel(&dest[2], av_clip_uintp2(((B_R + Y1) >> 14) + (1<<15),
16));
+output_pixel(&dest[0], av_clip_uintp2(((av_sat_add32(R_B, Y1)) >> 14)
+ (1<<15), 16));
+output_pixel(&dest[1], av_clip_uintp2(((av_sat_add32( G, Y1)) >> 14)
+ (1<<15), 16));
+output_pixel(&dest[2], av_clip_uintp2(((av_sat_add32(B_R, Y1)) >> 14)
+ (1<<15), 16));
if (eightbytes) {
output_pixel(&dest[3], av_clip_uintp2(A1 , 30) >> 14);
-output_pixel(&dest[4], av_clip_uintp2(((R_B + Y2) >> 14) +
(1<<15), 16));
-output_pixel(&dest[5], av_clip_uintp2((( G + Y2) >> 14) +
(1<<15), 16));
-output_pixel(&dest[6], av_clip_uintp2(((B_R + Y2) >> 14) +
(1<<15), 16));
+output_pixel(&dest[4], av_clip_uintp2(((av_sat_add32(R_B, Y2)) >>
14) + (1<<15), 16));
+output_pixel(&dest[5], av_clip_uintp2(((av_sat_add32( G, Y2)) >>
14) + (1<<15), 16));
+output_pixel(&dest[6], av_clip_uintp2(((av_sat_add32(B_R, Y2)) >>
14) + (1<<15), 16));
output_pixel(&dest[7], av_clip_uintp2(A2 , 30) >> 14);
dest += 8;
} else {
-output_pixel(&dest[3], av_clip_uintp2(((R_B + Y2) >> 14) +
(1<<15), 16));
-output_pixel(&dest[4], av_clip_uintp2((( G + Y2) >> 14) +
(1<<15), 16));
-output_pixel(&dest[5], av_clip_uintp2(((B_R + Y2) >> 14) +
(1<<15), 16));
+output_pixel(&dest[3], av_c
Re: [FFmpeg-devel] [PATCH 1/2] avfilter/src_movie: switch to activate()
Can I ask some knowledgeable people to comment why this patch
have issues?
On 4/2/22, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/src_movie.c | 90 +
> 1 file changed, 56 insertions(+), 34 deletions(-)
>
> diff --git a/libavfilter/src_movie.c b/libavfilter/src_movie.c
> index 711854c23c..bc7b0d37af 100644
> --- a/libavfilter/src_movie.c
> +++ b/libavfilter/src_movie.c
> @@ -46,6 +46,7 @@
>
> #include "audio.h"
> #include "avfilter.h"
> +#include "filters.h"
> #include "formats.h"
> #include "internal.h"
> #include "video.h"
> @@ -55,6 +56,7 @@ typedef struct MovieStream {
> AVCodecContext *codec_ctx;
> int64_t discontinuity_threshold;
> int64_t last_pts;
> +int got_eof;
> } MovieStream;
>
> typedef struct MovieContext {
> @@ -70,6 +72,8 @@ typedef struct MovieContext {
> int64_t discontinuity_threshold;
> int64_t ts_offset;
> int dec_threads;
> +int got_eagain;
> +int got_wanted;
>
> AVFormatContext *format_ctx;
>
> @@ -100,7 +104,6 @@ static const AVOption movie_options[]= {
> };
>
> static int movie_config_output_props(AVFilterLink *outlink);
> -static int movie_request_frame(AVFilterLink *outlink);
>
> static AVStream *find_stream(void *log, AVFormatContext *avf, const char
> *spec)
> {
> @@ -314,7 +317,6 @@ static av_cold int movie_common_init(AVFilterContext
> *ctx)
> if (!pad.name)
> return AVERROR(ENOMEM);
> pad.config_props = movie_config_output_props;
> -pad.request_frame = movie_request_frame;
> if ((ret = ff_append_outpad_free_name(ctx, &pad)) < 0)
> return ret;
> if ( movie->st[i].st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO
> &&
> @@ -554,47 +556,67 @@ static int movie_push_frame(AVFilterContext *ctx,
> unsigned out_id)
> return 0;
> }
>
> -static int movie_request_frame(AVFilterLink *outlink)
> +static int activate(AVFilterContext *ctx)
> {
> -AVFilterContext *ctx = outlink->src;
> MovieContext *movie = ctx->priv;
> -unsigned out_id = FF_OUTLINK_IDX(outlink);
> +int ret = 0;
> +
> +/* check all decoders for available output */
> +for (int i = 0; i < ctx->nb_outputs; i++) {
> +if (movie->st[i].got_eof)
> +continue;
> +
> +if (ff_outlink_frame_wanted(ctx->outputs[i]))
> +movie->got_wanted++;
>
> -while (1) {
> -int got_eagain = 0, got_eof = 0;
> -int ret = 0;
> +ret = movie_push_frame(ctx, i);
> +if (ret == AVERROR(EAGAIN))
> +movie->got_eagain++;
> +else if (ret == AVERROR_EOF)
> +movie->st[i].got_eof = 1;
> +else if (ret < 0)
> +return ret;
> +}
> +
> +if (movie->got_eagain || movie->got_wanted) {
> +/* all decoders require more input -> read a new packet */
> +movie->got_eagain = 0;
> +movie->got_wanted = 0;
> +ret = movie_decode_packet(ctx);
> +if (ret < 0 && ret != AVERROR(EAGAIN))
> +return ret;
> +ff_filter_set_ready(ctx, 100);
> +return 0;
> +} else {
> +int nb_eofs = 0;
>
> -/* check all decoders for available output */
> for (int i = 0; i < ctx->nb_outputs; i++) {
> -ret = movie_push_frame(ctx, i);
> -if (ret == AVERROR(EAGAIN))
> -got_eagain++;
> -else if (ret == AVERROR_EOF)
> -got_eof++;
> -else if (ret < 0)
> -return ret;
> -else if (i == out_id)
> -return 0;
> +if (movie->st[i].got_eof) {
> +if (movie->loop_count == 1)
> +ff_outlink_set_status(ctx->outputs[i], AVERROR_EOF,
> movie->st[i].last_pts);
> +nb_eofs++;
> +}
> +}
> +
> +if (nb_eofs != ctx->nb_outputs) {
> +ff_filter_set_ready(ctx, 100);
> +return 0;
> }
>
> -if (got_eagain) {
> -/* all decoders require more input -> read a new packet */
> -ret = movie_decode_packet(ctx);
> +if (movie->loop_count != 1) {
> +ret = rewind_file(ctx);
> if (ret < 0)
> return ret;
> -} else if (got_eof) {
> -/* all decoders flushed */
> -if (movie->loop_count != 1) {
> -ret = rewind_file(ctx);
> -if (ret < 0)
> -return ret;
> -movie->loop_count -= movie->loop_count > 1;
> -av_log(ctx, AV_LOG_VERBOSE, "Stream finished,
> looping.\n");
> -continue;
> -}
> -return AVERROR_EOF;
> +movie->loop_count -= movie->loop_count > 1;
> +av_log(ctx, AV_LOG_VERBOSE, "Stream finished, looping.\n");
> +for (int i = 0; i < ctx->nb_outputs; i++)
> +movie->st[i].got_eof = 0;
>
Re: [FFmpeg-devel] [PATCH v2 2/2] avformat/mov: re-allow zero sample sizes if that is not the default
On Sun, Dec 11, 2022 at 2:34 PM Chris Ribble wrote: > > This looks great and I've confirmed it fixes the issue. I see the > warning on STDERR about ignoring the trun box: "Ignoring trun box with > zero sized samples", which is great. > Actually, this introduces a new issue when I try to transcode the problematic mp4 and then segment it with the DASH muxer. It appears that ignoring the trun box while reading the input affects the segment alignment of the audio with the video.The durations jitter around quite a bit and some of them are very long. The same problem seems to exist whether I transcode or copy the audio. ___ 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] avcodec/jpeg2000dec: Add support for HTJ2K decoding.
On Fri, Dec 2, 2022 at 10:46 AM Tomas Härdin wrote:
>
> fre 2022-12-02 klockan 21:11 +0300 skrev etemesica...@gmail.com:
> >
> > +/**
> > + * Given a precomputed c, checks whether n % d == 0
> > + */
> > +static av_always_inline uint32_t is_divisible(uint32_t n, uint64_t
> > c)
> > +{
> > +return n * c <= c - 1;
> > +}
>
> This looks like something that could go in lavu, say intmath.h
Two thoughts:
- `is_divisible(n, c)` doesn't make sense without the matching
`precompute_c(d)`. I suggest at least modifying the documentation for
`is_divisible` and possibly defining `precompute_c(d)`
- I suggest focusing this patchset on Part 15 decoding, and
refactoring common math functions into intmath.h as a follow-up step
>
> > +
> > +/**
> > + * @brief Refill the buffer backwards in little Endian while
> > skipping
> > + * over stuffing bits
> > + *
> > + * Stuffing bits are those that appear in the position of any byte
> > whose
> > + * LSBs are all 1's if the last consumed byte was larger than 0x8F
> > + */
> > +static int jpeg2000_bitbuf_refill_backwards(StateVars *buffer,
> > +const uint8_t *array)
>
> Don't we already have sufficient bitreading capabilities already? Maybe
> it doesn't do the necessary unstuffing..
>
>
> > +/*
> > + * As an optimization, we can replace modulo operations with
> > + * checking if a number is divisible , since that's the only
> > thing we need.
> > + * this is paired with is_divisible.
> > + * Credits to Daniel Lemire blog post:
> > + *
> > https://lemire.me/blog/2019/02/08/faster-remainders-when-the-divisor-is-a-constant-beating-compilers-and-libdivide/
> > + * It's UB on zero, but we can't have a quad being zero, the
> > spec doesn't allow,
> > + * so we error out early in case that's the case.
> > + */
> > +
> > +c = 1 + UINT64_C(0x) / quad_width;
>
> Just 0xULL would work
+1
>
> > +
> > +for (int row = 1; row < quad_height; row++) {
> > +while ((q - (row * quad_width)) < quad_width - 1 && q <
> > (quad_height * quad_width)) {
> > +q1 = q;
> > +q2 = q + 1;
> > +context1 = sigma_n[4 * (q1 - quad_width) + 1];
> > +context1 += sigma_n[4 * (q1 - quad_width) + 3] << 2; //
> > ne
> > +
> > +if (!is_divisible(q1, c)) {
>
> These divisibility checks look like they could be even simpler given
> that q always increases by 2
Is the idea that `q1 mod d` can be sped up knowing that `d = 2 n + {0,
1}`? Per the below, I suggest tackling finer optimizations in
follow-up patchsets.
>
> > +context1 |= sigma_n[4 * (q1 - quad_width) -
> > 1]; // nw
> > +context1 += (sigma_n[4 * q1 - 1] | sigma_n[4 * q1 -
> > 2]) << 1; // sw| q
> > +}
> > +if (!is_divisible(q1 + 1, c))
> > +context1 |= sigma_n[4 * (q1 - quad_width) + 5] << 2;
> > +
> > +if ((ret = jpeg2000_decode_sig_emb(s, mel_state,
> > mel_stream, vlc_stream,
> > + dec_CxtVLC_table1,
> > Dcup, sig_pat, res_off,
> > + emb_pat_k, emb_pat_1,
> > J2K_Q1, context1, Lcup,
> > + Pcup))
> > +< 0)
> > +goto free;
> > +
> > +for (int i = 0; i < 4; i++)
> > +sigma_n[4 * q1 + i] = (sig_pat[J2K_Q1] >> i) & 1;
> > +
> > +context2 = sigma_n[4 * (q2 - quad_width) + 1];
> > +context2 += sigma_n[4 * (q2 - quad_width) + 3] << 2;
> > +
> > +if (!is_divisible(q2, c)) {
> > +context2 |= sigma_n[4 * (q2 - quad_width) - 1];
> > +context2 += (sigma_n[4 * q2 - 1] | sigma_n[4 * q2 -
> > 2]) << 1;
> > +}
> > +if (!is_divisible(q2 + 1, c))
> > +context2 |= sigma_n[4 * (q2 - quad_width) + 5] << 2;
> > +
> > +if ((ret = jpeg2000_decode_sig_emb(s, mel_state,
> > mel_stream, vlc_stream,
> > + dec_CxtVLC_table1,
> > Dcup, sig_pat, res_off,
> > + emb_pat_k, emb_pat_1,
> > J2K_Q2, context2, Lcup,
> > + Pcup))
> > +< 0)
> > +goto free;
> > +
> > +for (int i = 0; i < 4; i++)
> > +sigma_n[4 * q2 + i] = (sig_pat[J2K_Q2] >> i) & 1;
> > +
> > +u[J2K_Q1] = 0;
> > +u[J2K_Q2] = 0;
> > +
> > +jpeg2000_bitbuf_refill_backwards(vlc_stream, vlc_buf);
> > +
> > +if (res_off[J2K_Q1] == 1 && res_off[J2K_Q2] == 1) {
> > +u_pfx[J2K_Q1] = vlc_decode_u_prefix(vlc_stream,
> > vlc_buf);
> > +u_pfx[J2K_Q2] = vlc_decode_u_prefix(vlc_stream,
> > vlc_buf);
> > +
> > +u_sfx[J2K_Q1] = vlc_decode_u_suffix(vlc_stream,
[FFmpeg-devel] [PATCH] configure: Change _cflags_noopt for MSVC to -Od
Currently -O1 is set to _cflags_noopt, but -O1 is actually for size
optimization instead of no-opt which causes size optimized binaries
been built with --disable-optimizations.
Signed-off-by: Thomson Tan
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index f4eedfc207..388d518345 100755
--- a/configure
+++ b/configure
@@ -4825,7 +4825,7 @@ probe_cc(){
_DEPFLAGS='$(CPPFLAGS) $(CFLAGS) -showIncludes -Zs'
_cflags_speed="-O2"
_cflags_size="-O1"
-_cflags_noopt="-O1"
+_cflags_noopt="-Od"
if $_cc -nologo- 2>&1 | grep -q Linker; then
_ld_o='-out:$@'
else
--
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] avformat/file: add fd protocol
On Mon, 2022-12-12 at 18:31 +0200, Rémi Denis-Courmont wrote:
> Le maanantaina 5. joulukuuta 2022, 4.51.34 EET zhilizhao(赵志立) a écrit
> :
> > > On Nov 19, 2022, at 02:48, Zhao Zhili
> > > wrote:
> > >
> > > From: Zhao Zhili
> > >
> > > Unlike the pipe protocol, fd protocol has seek support if it
> > > corresponding to a regular file.
> > > ---
> > > Sometimes it's the only way to access files via file descriptor,
> > > e.g.,
> > > requesting a shared file on Android:
> > > https://developer.android.com/training/secure-file-sharing/request-file
> > >
> > > doc/protocols.texi | 24 +++
> > > libavformat/Makefile| 1 +
> > > libavformat/file.c | 51
> > > +
> > > libavformat/protocols.c | 1 +
> > > libavformat/version.h | 4 ++--
> > > 5 files changed, 79 insertions(+), 2 deletions(-)
> >
> > Ping for review.
>
> VLC does this (with a slightly different syntax, i.e. fd://$NUM) and
> in
> hindsight, I think that it was a big mistake.
>
> It should not be possible to refer to an opaque handle from within
> the URL.
> This leads to all sorts of mischief, bordering on security issue, in
> the
> common case that the URL string is untrusted.
Could you elaborate on the security issue?
>
> To support this use case, IMO, the file descriptor should be passed
> explicitly
> via a trusted channel, *not* the URL.
Does an explicit option works here?
static const AVOption pipe_options[] = {
{ "blocksize", "set I/O operation maximum block size",
offsetof(FileContext, blocksize), AV_OPT_TYPE_INT, { .i64 = INT_MAX },
1, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM },
+{ "fd", "set file descriptor", offsetof(FileContext, fd),
AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM
},
{ NULL }
};
___
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 1/3] avformat/file: add fd protocol
Le sunnuntaina 11. joulukuuta 2022, 17.17.27 EET Zhao Zhili a écrit :
> From: Zhao Zhili
>
> Unlike the pipe protocol, fd protocol has seek support if it
> corresponding to a regular file.
> ---
> v2: dup the file descriptor for safety
>
> doc/protocols.texi | 24 ++
> libavformat/Makefile| 1 +
> libavformat/file.c | 55 +
> libavformat/protocols.c | 1 +
> libavformat/version.h | 4 +--
> 5 files changed, 83 insertions(+), 2 deletions(-)
>
> diff --git a/doc/protocols.texi b/doc/protocols.texi
> index 5e9198e67c..d9f2d2dec3 100644
> --- a/doc/protocols.texi
> +++ b/doc/protocols.texi
> @@ -275,6 +275,30 @@ For example, to convert a GIF file given inline with
> @command{ffmpeg}: ffmpeg -i
> "data:image/gif;base64,R0lGODdhCAAIAMIE//8AAP//AP///ywA
> CAAIAAADF0gEDLojDgdGiJdJqUX02iB4E8Q9jUMkADs=" smiley.png @end example
>
> +@section fd
> +
> +File descriptor access protocol.
> +
> +The accepted syntax is:
> +@example
> +fd:[@var{number}]
> +@end example
C.f. what I wrote in the previous version thread.
--
Реми Дёни-Курмон
http://www.remlab.net/
___
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] avformat/file: add fd protocol
Le maanantaina 5. joulukuuta 2022, 4.51.34 EET zhilizhao(赵志立) a écrit : > > On Nov 19, 2022, at 02:48, Zhao Zhili wrote: > > > > From: Zhao Zhili > > > > Unlike the pipe protocol, fd protocol has seek support if it > > corresponding to a regular file. > > --- > > Sometimes it's the only way to access files via file descriptor, e.g., > > requesting a shared file on Android: > > https://developer.android.com/training/secure-file-sharing/request-file > > > > doc/protocols.texi | 24 +++ > > libavformat/Makefile| 1 + > > libavformat/file.c | 51 + > > libavformat/protocols.c | 1 + > > libavformat/version.h | 4 ++-- > > 5 files changed, 79 insertions(+), 2 deletions(-) > > Ping for review. VLC does this (with a slightly different syntax, i.e. fd://$NUM) and in hindsight, I think that it was a big mistake. It should not be possible to refer to an opaque handle from within the URL. This leads to all sorts of mischief, bordering on security issue, in the common case that the URL string is untrusted. To support this use case, IMO, the file descriptor should be passed explicitly via a trusted channel, *not* the URL. -- Реми Дёни-Курмон http://www.remlab.net/ ___ 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] avformat: Rename IPFS to IPFS gateway
fre 2022-12-09 klockan 15:52 + skrev Derek Buitenhuis:
> On 12/9/2022 3:45 PM, Nicolas George wrote:
> > > -static int ipfs_read(URLContext *h, unsigned char *buf, int
> > > size)
> > > +static int ipfs_gateway_read(URLContext *h, unsigned char *buf,
> > > int size)
> >
> > There is no need to rename local symbols.
>
> My intent was to rename in case we ever got an actual IPFS
> implementation,
> but I have no strong opinion on whether to keep this part of the
> patch or
> not.
>
> > > +const URLProtocol ff_ipfs_gateway_protocol = {
> > > + .name = "ipfs_gateway",
> >
> > It is a bit of a mouthful. Maybe "ipfsgw"?
>
> My personal preference is verbosity here, but it's not a strong
> preference.
I agree verbosity is better here
/Tomas
___
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] doc/protocols: Remove third party server
On 12/9/2022 3:27 PM, Derek Buitenhuis wrote: > --- > doc/protocols.texi | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) I will push these two later today if there are no objections. - Derek ___ 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] Defect: MediaCodec Encoder - Pixel ColorSpace of many Adreno GPUs not supported
tor 2022-12-08 klockan 01:16 +0800 skrev Zhao Zhili: > > We can add query the supported color format and add some hints when > mediacodec configure failed. > Or we can add a helper function for user to query the color format. > It will be a bunch of JNI code, limited > by the ugly MediaCodecInfo.CodecCapabilities API. It's easy to be > done with Java. TBH, it's much easier with > trial and error, try nv12 then yuv420. > > We can do something with FFCodec.init_static_data, but we need a > strategy first. I don't want to go with a long > blacklist/whitelist. I plan on hacking on something for this this week /Tomas ___ 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/7] avcodec/mediacodecenc: remove the strategy to create DTS
ons 2022-12-07 klockan 17:31 +0800 skrev Zhao Zhili: > From: Zhao Zhili > > Use input PTS as DTS has multiple problems: > 1. If there is no reordering, it's better to just use the output > PTS as DTS, since encoder may change the timestamp value (do it > on purpose or rounding error). > > 2. If there is reordering, input PTS should be shift a few frames > as DTS to satisfy the requirement of PTS >= DTS. I can't find a > reliable way to determine how many frames to be shift. For example, > we don't known if the encoder use hierarchical B frames. The > max_num_reorder_frames can be get from VUI, but VUI is optional. > > 3. Encoder dropping frames makes the case worse. Android has an > BITRATE_MODE_CBR_FD option to allow it explicitly. Don't we already have code to parse this stuff from h.264 streams? /Tomas ___ 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/7] avcodec/mediacodecenc: use bsf to handle crop
lör 2022-12-10 klockan 01:22 +0800 skrev Zhao Zhili: > From: Zhao Zhili > > It's well known that mediacodec encoder requires 16x16 alignment. > Use our bsf to fix the crop info. > --- > v3: don't change the dimension for AV_PIX_FMT_MEDIACODEC. It can have > side effect. Looks like this silently crops? Is that really a good idea? We usually don't do stuff like that. For example codecs that require even dimensions complain loudly then fail. /Tomas ___ 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] configure: add OpenVino v.2022.x support
Since OpenVino release 2022.1, the C API library filename changed from
'libinference_engine_c_api.so' to 'libopenvino_c.so'.
This commit reflects such rename in the 'configure' script.
Signed-off-by: Rafik Saliev
---
configure | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index f4eedfc207..92cd2cbdfb 100755
--- a/configure
+++ b/configure
@@ -6635,7 +6635,8 @@ enabled libopenh264 && require_pkg_config
libopenh264 openh264 wels/codec_
enabled libopenjpeg && { check_pkg_config libopenjpeg "libopenjp2 >=
2.1.0" openjpeg.h opj_version ||
{ require_pkg_config libopenjpeg "libopenjp2 >=
2.1.0" openjpeg.h opj_version -DOPJ_STATIC && add_cppflags -DOPJ_STATIC; } }
enabled libopenmpt&& require_pkg_config libopenmpt "libopenmpt >=
0.2.6557" libopenmpt/libopenmpt.h openmpt_module_create -lstdc++ && append
libopenmpt_extralibs "-lstdc++"
-enabled libopenvino && require libopenvino c_api/ie_c_api.h
ie_c_api_version -linference_engine_c_api
+enabled libopenvino && { check_lib libopenvino c_api/ie_c_api.h
ie_c_api_version -linference_engine_c_api ||
+ require libopenvino c_api/ie_c_api.h
ie_c_api_version -lopenvino_c; }
enabled libopus && {
enabled libopus_decoder && {
require_pkg_config libopus opus opus_multistream.h
opus_multistream_decoder_create
--
2.31.1.windows.1
-
Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial
Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 |
Kapital zakladowy 200.000 PLN.
Spolka oswiadcza, ze posiada status duzego przedsiebiorcy w rozumieniu ustawy z
dnia 8 marca 2013 r. o przeciwdzialaniu nadmiernym opoznieniom w transakcjach
handlowych.
Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i
moze zawierac informacje poufne. W razie przypadkowego otrzymania tej
wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie;
jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). If you are not the intended recipient, please
contact the sender and delete all copies; any review or distribution by others
is strictly prohibited.
___
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] avfilter/vf_blackdetect: support full-range YUV
Any objections to these two patches? On Fri, 09 Dec 2022 01:28:05 +0100 Niklas Haas wrote: > From: Niklas Haas > > This filter currently makes the distinction between limited and full > range by testing for the deprecated YUVJ pixel formats at link setup > time. This is deprecated and should be improved to perform the detection > based on the per-frame metadata. > > Rewrite it to calculate the black pixel threshold at the time of > filtering a frame, when metadata about the frame's color range is known. > Doing it this way has the small side benefit of being able to handle > streams with variable metadata, and is not a meaningful performance > cost. > > Signed-off-by: Niklas Haas > --- > libavfilter/vf_blackdetect.c | 20 ++-- > 1 file changed, 10 insertions(+), 10 deletions(-) > > diff --git a/libavfilter/vf_blackdetect.c b/libavfilter/vf_blackdetect.c > index 99ff1ac606..c937248169 100644 > --- a/libavfilter/vf_blackdetect.c > +++ b/libavfilter/vf_blackdetect.c > @@ -102,8 +102,6 @@ static int config_input(AVFilterLink *inlink) > BlackDetectContext *s = ctx->priv; > const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(inlink->format); > const int depth = desc->comp[0].depth; > -const int max = (1 << depth) - 1; > -const int factor = (1 << (depth - 8)); > > s->depth = depth; > s->nb_threads = ff_filter_get_nb_threads(ctx); > @@ -113,16 +111,10 @@ static int config_input(AVFilterLink *inlink) > if (!s->counter) > return AVERROR(ENOMEM); > > -s->pixel_black_th_i = ff_fmt_is_in(inlink->format, yuvj_formats) ? > -// luminance_minimum_value + pixel_black_th * luminance_range_size > - s->pixel_black_th * max : > -16 * factor + s->pixel_black_th * (235 - 16) * factor; > - > av_log(s, AV_LOG_VERBOSE, > - "black_min_duration:%s pixel_black_th:%f pixel_black_th_i:%d > picture_black_ratio_th:%f\n", > + "black_min_duration:%s pixel_black_th:%f > picture_black_ratio_th:%f\n", > av_ts2timestr(s->black_min_duration, &s->time_base), > - s->pixel_black_th, s->pixel_black_th_i, > - s->picture_black_ratio_th); > + s->pixel_black_th, s->picture_black_ratio_th); > return 0; > } > > @@ -182,6 +174,14 @@ static int filter_frame(AVFilterLink *inlink, AVFrame > *picref) > AVFilterContext *ctx = inlink->dst; > BlackDetectContext *s = ctx->priv; > double picture_black_ratio = 0; > +const int max = (1 << s->depth) - 1; > +const int factor = (1 << (s->depth - 8)); > +const int full = picref->color_range == AVCOL_RANGE_JPEG || > + ff_fmt_is_in(picref->format, yuvj_formats); > + > +s->pixel_black_th_i = full ? s->pixel_black_th * max : > +// luminance_minimum_value + pixel_black_th * luminance_range_size > +16 * factor + s->pixel_black_th * (235 - 16) * factor; > > ff_filter_execute(ctx, black_counter, picref, NULL, >FFMIN(inlink->h, s->nb_threads)); > -- > 2.38.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 1/5] avcodec/decode: add a function to set frame props from a user provided packet
On 12/8/2022 11:07 AM, James Almer wrote: It will be useful for decoders that don't rely on last_pkt_props to set frame props. Signed-off-by: James Almer --- libavcodec/decode.c | 19 +++ libavcodec/decode.h | 5 + 2 files changed, 20 insertions(+), 4 deletions(-) Will apply set. ___ 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 5/5] avcodec/mpeg4videodec: duplicate the last decoded frame when the last coded frame was skipped
On 12/4/2022 6:52 PM, James Almer wrote:
This ensures the video stream duration is not lost after decoding.
Signed-off-by: James Almer
---
libavcodec/h263dec.c | 13 +
libavcodec/mpegvideo.h | 1 +
2 files changed, 14 insertions(+)
diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
index ac7a8521e5..0a2d7487a8 100644
--- a/libavcodec/h263dec.c
+++ b/libavcodec/h263dec.c
@@ -430,6 +430,18 @@ int ff_h263_decode_frame(AVCodecContext *avctx, AVFrame
*pict,
return ret;
s->next_picture_ptr = NULL;
+*got_frame = 1;
+} else if (s->skipped_last_frame && s->current_picture_ptr) {
+/* Output the last picture we decoded again if the stream ended
with
+ * an NVOP */
+if ((ret = av_frame_ref(pict, s->current_picture_ptr->f)) < 0)
+return ret;
+/* Copy props from the last input packet. Otherwise, props from
the last
+ * returned picture would be reused */
+if ((ret = ff_decode_frame_props(avctx, pict)) < 0)
+return ret;
+s->current_picture_ptr = NULL;
+
*got_frame = 1;
}
@@ -500,6 +512,7 @@ retry:
s->extradata_parsed = 1;
}
ret = ff_mpeg4_decode_picture_header(avctx->priv_data, &s->gb, 0, 0);
+s->skipped_last_frame = (ret == FRAME_SKIPPED);
} else if (CONFIG_H263I_DECODER && s->codec_id == AV_CODEC_ID_H263I) {
ret = ff_intel_h263_decode_picture_header(s);
} else if (CONFIG_FLV_DECODER && s->h263_flv) {
diff --git a/libavcodec/mpegvideo.h b/libavcodec/mpegvideo.h
index 6440b906b1..42275953b9 100644
--- a/libavcodec/mpegvideo.h
+++ b/libavcodec/mpegvideo.h
@@ -175,6 +175,7 @@ typedef struct MpegEncContext {
Picture *last_picture_ptr; ///< pointer to the previous picture.
Picture *next_picture_ptr; ///< pointer to the next picture (for
bidir pred)
Picture *current_picture_ptr; ///< pointer to the current picture
+int skipped_last_frame;
int last_dc[3];///< last DC values for MPEG-1
int16_t *dc_val_base;
int16_t *dc_val[3];///< used for MPEG-4 DC prediction, all 3
arrays must be continuous
Will apply.
___
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] libavfilter/dnn/dnn_backend_openvino.c: fix openvino async mode
Bugfix: The OpenVino DNN backend in the 'async' mode sets
'task->inference_done' to 'complete' prior to data copy from
OpenVino output buffer to task's output frame.
This order causes task destroy in ff_dnn_get_result_common()
prior to model output processing.
Signed-off-by: Rafik Saliev
---
libavfilter/dnn/dnn_backend_openvino.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/dnn/dnn_backend_openvino.c
b/libavfilter/dnn/dnn_backend_openvino.c
index b494f26f55..b67f288336 100644
--- a/libavfilter/dnn/dnn_backend_openvino.c
+++ b/libavfilter/dnn/dnn_backend_openvino.c
@@ -244,7 +244,6 @@ static void infer_completion_callback(void *args)
av_assert0(request->lltask_count >= 1);
for (int i = 0; i < request->lltask_count; ++i) {
task = request->lltasks[i]->task;
-task->inference_done++;
switch (ov_model->model->func_type) {
case DFT_PROCESS_FRAME:
@@ -278,6 +277,7 @@ static void infer_completion_callback(void *args)
break;
}
+task->inference_done++;
av_freep(&request->lltasks[i]);
output.data = (uint8_t *)output.data
+ output.width * output.height * output.channels *
get_datatype_size(output.dt);
--
2.31.1.windows.1
-
Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial
Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 |
Kapital zakladowy 200.000 PLN.
Spolka oswiadcza, ze posiada status duzego przedsiebiorcy w rozumieniu ustawy z
dnia 8 marca 2013 r. o przeciwdzialaniu nadmiernym opoznieniom w transakcjach
handlowych.
Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i
moze zawierac informacje poufne. W razie przypadkowego otrzymania tej
wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie;
jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). If you are not the intended recipient, please
contact the sender and delete all copies; any review or distribution by others
is strictly prohibited.
___
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".
