Re: [FFmpeg-devel] [PATCH v2 1/2] lavc/qsv: make some functions inline
On Mon, 2020-12-07 at 03:10 +0100, Andreas Rheinhardt wrote:
> Haihao Xiang:
> > ff_qsv_print_iopattern, ff_qsv_print_error, ff_qsv_print_warning and
> > ff_qsv_map_error can be used outside of lavc, make them inline in a
> > private header so that other libraries may include this private header.
> > In addition, QSV_VERSION_ATLEAST() and QSV_RUNTIME_VERSION_ATLEAST() can
> > be used across libraries as well.
> >
> > Signed-off-by: Haihao Xiang
> > ---
> > Per the comments from Anton and James, I used inline functions instead
> > of avpriv functions in this patch
> >
> > libavcodec/Makefile| 2 +-
> > libavcodec/qsv.c | 132 ---
> > libavcodec/qsv_core_internal.h | 139 +
> > libavcodec/qsv_internal.h | 24 +-
> > libavcodec/qsvdec.c| 16 ++--
> > libavcodec/qsvenc.c| 36 -
> > 6 files changed, 181 insertions(+), 168 deletions(-)
> > create mode 100644 libavcodec/qsv_core_internal.h
> >
> > diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> > index 33e08548f5..20d9e5159a 100644
> > --- a/libavcodec/Makefile
> > +++ b/libavcodec/Makefile
> > @@ -1196,7 +1196,7 @@ SKIPHEADERS-$(CONFIG_MEDIACODEC) +=
> > mediacodecdec_common.h mediacodec_surf
> > SKIPHEADERS-$(CONFIG_MEDIAFOUNDATION) += mf_utils.h
> > SKIPHEADERS-$(CONFIG_NVDEC)+= nvdec.h
> > SKIPHEADERS-$(CONFIG_NVENC)+= nvenc.h
> > -SKIPHEADERS-$(CONFIG_QSV) += qsv.h qsv_internal.h
> > +SKIPHEADERS-$(CONFIG_QSV) += qsv.h qsv_internal.h
> > qsv_core_internal.h
> > SKIPHEADERS-$(CONFIG_QSVDEC) += qsvdec.h
> > SKIPHEADERS-$(CONFIG_QSVENC) += qsvenc.h
> > SKIPHEADERS-$(CONFIG_XVMC) += xvmc.h
> > diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
> > index 6e3154e1a3..76be7b2e77 100644
> > --- a/libavcodec/qsv.c
> > +++ b/libavcodec/qsv.c
> > @@ -89,110 +89,6 @@ int ff_qsv_level_to_mfx(enum AVCodecID codec_id, int
> > level)
> > }
> > }
> >
> > -static const struct {
> > -int mfx_iopattern;
> > -const char *desc;
> > -} qsv_iopatterns[] = {
> > -{MFX_IOPATTERN_IN_VIDEO_MEMORY, "input is video memory
> > surface" },
> > -{MFX_IOPATTERN_IN_SYSTEM_MEMORY,"input is system memory
> > surface"},
> > -{MFX_IOPATTERN_IN_OPAQUE_MEMORY,"input is opaque memory
> > surface"},
> > -{MFX_IOPATTERN_OUT_VIDEO_MEMORY,"output is video memory
> > surface"},
> > -{MFX_IOPATTERN_OUT_SYSTEM_MEMORY, "output is system memory
> > surface" },
> > -{MFX_IOPATTERN_OUT_OPAQUE_MEMORY, "output is opaque memory
> > surface" },
> > -};
> > -
> > -int ff_qsv_print_iopattern(void *log_ctx, int mfx_iopattern,
> > - const char *extra_string)
> > -{
> > -const char *desc = NULL;
> > -
> > -for (int i = 0; i < FF_ARRAY_ELEMS(qsv_iopatterns); i++) {
> > -if (qsv_iopatterns[i].mfx_iopattern == mfx_iopattern) {
> > -desc = qsv_iopatterns[i].desc;
> > -}
> > -}
> > -if (!desc)
> > -desc = "unknown iopattern";
> > -
> > -av_log(log_ctx, AV_LOG_VERBOSE, "%s: %s\n", extra_string, desc);
> > -return 0;
> > -}
> > -
> > -static const struct {
> > -mfxStatus mfxerr;
> > -int averr;
> > -const char *desc;
> > -} qsv_errors[] = {
> > -{
> > MFX_ERR_NONE, 0, "success"
> > },
> > -{ MFX_ERR_UNKNOWN, AVERROR_UNKNOWN, "unknown
> > error"},
> > -{ MFX_ERR_NULL_PTR, AVERROR(EINVAL), "NULL
> > pointer" },
> > -{ MFX_ERR_UNSUPPORTED, AVERROR(ENOSYS),
> > "unsupported" },
> > -{ MFX_ERR_MEMORY_ALLOC, AVERROR(ENOMEM), "failed to
> > allocate memory"},
> > -{ MFX_ERR_NOT_ENOUGH_BUFFER,AVERROR(ENOMEM), "insufficient
> > input/output buffer" },
> > -{ MFX_ERR_INVALID_HANDLE, AVERROR(EINVAL), "invalid
> > handle" },
> > -{ MFX_ERR_LOCK_MEMORY, AVERROR(EIO),"failed to lock
> > the memory block" },
> > -{ MFX_ERR_NOT_INITIALIZED, AVERROR_BUG, "not
> > initialized" },
> > -{ MFX_ERR_NOT_FOUND,AVERROR(ENOSYS), "specified object
> > was not found" },
> > -/* the following 3 errors should always be handled explicitly, so those
> > "mappings"
> > - * are for completeness only */
> > -{ MFX_ERR_MORE_DATA,AVERROR_UNKNOWN, "expect more data
> > at input"},
> > -{ MFX_ERR_MORE_SURFACE, AVERROR_UNKNOWN, "expect more
> > surface at output"},
> > -{ MFX_ERR_MORE_BITSTREAM, AVERROR_UNKNOWN, "expect more
> > bitstream at output" },
> > -{ MFX_ERR_ABORTED
[FFmpeg-devel] [PATCH v3] avformat/framecrcenc: Make side-data checksums endian-independent
Do this by converting big-endian side data to little endian for
checksumming.
Reviewed-by: Andriy Gelman
Reviewed-by: Michael Niedermayer
Signed-off-by: Andreas Rheinhardt
---
I have incorporated Michael's resp. Andriy's suggestion regarding
av_unused resp. renaming the buffer for the actual output. But I have
left hashenc.c untouched. Unfortunately one can't simply merge framecrc
into hashenc.c without changing every checksum, because the av_hash_* API
initializes its adler-32 checksums to 1, whereas framecrc initializes it
to 0. The latter seems to be wrong; if one intends to switch to the
former, then I suggest to use the framehash muxer in FATE instead of
framecrc and deprecate framecrc without modifying it and make framehash
endian-independent (essentially using the patch here); after all, other
people may use it, too. The diff would be huge (more than 7 lines
of removal), but if that is preferred, I can do so.
libavformat/framecrcenc.c | 59 +++
1 file changed, 54 insertions(+), 5 deletions(-)
diff --git a/libavformat/framecrcenc.c b/libavformat/framecrcenc.c
index f7c48779a0..1fbe4aa4ee 100644
--- a/libavformat/framecrcenc.c
+++ b/libavformat/framecrcenc.c
@@ -21,9 +21,11 @@
#include
+#include "config.h"
#include "libavutil/adler32.h"
#include "libavutil/avstring.h"
#include "libavutil/intreadwrite.h"
+#include "libavcodec/avcodec.h"
#include "avformat.h"
#include "internal.h"
@@ -43,6 +45,17 @@ static int framecrc_write_header(struct AVFormatContext *s)
return ff_framehash_write_header(s);
}
+static av_unused void inline bswap(char *buf, int offset, int size)
+{
+if (size == 8) {
+uint64_t val = AV_RN64(buf + offset);
+AV_WN64(buf + offset, av_bswap64(val));
+} else if (size == 4) {
+uint32_t val = AV_RN32(buf + offset);
+AV_WN32(buf + offset, av_bswap32(val));
+}
+}
+
static int framecrc_write_packet(struct AVFormatContext *s, AVPacket *pkt)
{
uint32_t crc = av_adler32_update(0, pkt->data, pkt->size);
@@ -58,17 +71,53 @@ static int framecrc_write_packet(struct AVFormatContext *s,
AVPacket *pkt)
for (i=0; iside_data_elems; i++) {
const AVPacketSideData *const sd = &pkt->side_data[i];
+const uint8_t *data = sd->data;
uint32_t side_data_crc = 0;
-if (HAVE_BIGENDIAN && AV_PKT_DATA_PALETTE ==
pkt->side_data[i].type) {
+
+switch (sd->type) {
+#if HAVE_BIGENDIAN
+uint8_t bswap_buf[FFMAX(sizeof(AVCPBProperties),
+sizeof(AVProducerReferenceTime))];
+case AV_PKT_DATA_PALETTE:
+case AV_PKT_DATA_REPLAYGAIN:
+case AV_PKT_DATA_DISPLAYMATRIX:
+case AV_PKT_DATA_STEREO3D:
+case AV_PKT_DATA_AUDIO_SERVICE_TYPE:
+case AV_PKT_DATA_FALLBACK_TRACK:
+case AV_PKT_DATA_MASTERING_DISPLAY_METADATA:
+case AV_PKT_DATA_SPHERICAL:
+case AV_PKT_DATA_CONTENT_LIGHT_LEVEL:
+case AV_PKT_DATA_S12M_TIMECODE:
for (int j = 0; j < sd->size / 4; j++) {
uint8_t buf[4];
AV_WL32(buf, AV_RB32(sd->data + 4 * j));
side_data_crc = av_adler32_update(side_data_crc, buf, 4);
}
-} else {
-side_data_crc = av_adler32_update(0,
- pkt->side_data[i].data,
- pkt->side_data[i].size);
+break;
+case AV_PKT_DATA_CPB_PROPERTIES:
+#define BSWAP(struct, field) bswap(bswap_buf, offsetof(struct, field),
sizeof(((struct){0}).field))
+if (sd->size == sizeof(AVCPBProperties)) {
+memcpy(bswap_buf, sd->data, sizeof(AVCPBProperties));
+data = bswap_buf;
+BSWAP(AVCPBProperties, max_bitrate);
+BSWAP(AVCPBProperties, min_bitrate);
+BSWAP(AVCPBProperties, avg_bitrate);
+BSWAP(AVCPBProperties, buffer_size);
+BSWAP(AVCPBProperties, vbv_delay);
+}
+goto pod;
+case AV_PKT_DATA_PRFT:
+if (sd->size == sizeof(AVProducerReferenceTime)) {
+memcpy(bswap_buf, sd->data,
sizeof(AVProducerReferenceTime));
+data = bswap_buf;
+BSWAP(AVProducerReferenceTime, wallclock);
+BSWAP(AVProducerReferenceTime, flags);
+}
+goto pod;
+pod:
+#endif
+default:
+side_data_crc = av_adler32_update(0, data, sd->size);
}
av_strlcatf(buf, sizeof(buf), ", %8d, 0x%08"PRIx32,
pkt->side_data[i].size, side_data_crc);
}
--
2.25.1
___
ffmpeg-devel mailing list
ffmpe
Re: [FFmpeg-devel] [PATCH v2 1/2] lavc/qsv: make some functions inline
Haihao Xiang:
> ff_qsv_print_iopattern, ff_qsv_print_error, ff_qsv_print_warning and
> ff_qsv_map_error can be used outside of lavc, make them inline in a
> private header so that other libraries may include this private header.
> In addition, QSV_VERSION_ATLEAST() and QSV_RUNTIME_VERSION_ATLEAST() can
> be used across libraries as well.
>
> Signed-off-by: Haihao Xiang
> ---
> Per the comments from Anton and James, I used inline functions instead
> of avpriv functions in this patch
>
> libavcodec/Makefile| 2 +-
> libavcodec/qsv.c | 132 ---
> libavcodec/qsv_core_internal.h | 139 +
> libavcodec/qsv_internal.h | 24 +-
> libavcodec/qsvdec.c| 16 ++--
> libavcodec/qsvenc.c| 36 -
> 6 files changed, 181 insertions(+), 168 deletions(-)
> create mode 100644 libavcodec/qsv_core_internal.h
>
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 33e08548f5..20d9e5159a 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -1196,7 +1196,7 @@ SKIPHEADERS-$(CONFIG_MEDIACODEC) +=
> mediacodecdec_common.h mediacodec_surf
> SKIPHEADERS-$(CONFIG_MEDIAFOUNDATION) += mf_utils.h
> SKIPHEADERS-$(CONFIG_NVDEC)+= nvdec.h
> SKIPHEADERS-$(CONFIG_NVENC)+= nvenc.h
> -SKIPHEADERS-$(CONFIG_QSV) += qsv.h qsv_internal.h
> +SKIPHEADERS-$(CONFIG_QSV) += qsv.h qsv_internal.h
> qsv_core_internal.h
> SKIPHEADERS-$(CONFIG_QSVDEC) += qsvdec.h
> SKIPHEADERS-$(CONFIG_QSVENC) += qsvenc.h
> SKIPHEADERS-$(CONFIG_XVMC) += xvmc.h
> diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
> index 6e3154e1a3..76be7b2e77 100644
> --- a/libavcodec/qsv.c
> +++ b/libavcodec/qsv.c
> @@ -89,110 +89,6 @@ int ff_qsv_level_to_mfx(enum AVCodecID codec_id, int
> level)
> }
> }
>
> -static const struct {
> -int mfx_iopattern;
> -const char *desc;
> -} qsv_iopatterns[] = {
> -{MFX_IOPATTERN_IN_VIDEO_MEMORY, "input is video memory surface"
>},
> -{MFX_IOPATTERN_IN_SYSTEM_MEMORY,"input is system memory surface"
>},
> -{MFX_IOPATTERN_IN_OPAQUE_MEMORY,"input is opaque memory surface"
>},
> -{MFX_IOPATTERN_OUT_VIDEO_MEMORY,"output is video memory surface"
>},
> -{MFX_IOPATTERN_OUT_SYSTEM_MEMORY, "output is system memory surface"
>},
> -{MFX_IOPATTERN_OUT_OPAQUE_MEMORY, "output is opaque memory surface"
>},
> -};
> -
> -int ff_qsv_print_iopattern(void *log_ctx, int mfx_iopattern,
> - const char *extra_string)
> -{
> -const char *desc = NULL;
> -
> -for (int i = 0; i < FF_ARRAY_ELEMS(qsv_iopatterns); i++) {
> -if (qsv_iopatterns[i].mfx_iopattern == mfx_iopattern) {
> -desc = qsv_iopatterns[i].desc;
> -}
> -}
> -if (!desc)
> -desc = "unknown iopattern";
> -
> -av_log(log_ctx, AV_LOG_VERBOSE, "%s: %s\n", extra_string, desc);
> -return 0;
> -}
> -
> -static const struct {
> -mfxStatus mfxerr;
> -int averr;
> -const char *desc;
> -} qsv_errors[] = {
> -{ MFX_ERR_NONE, 0, "success"
>},
> -{ MFX_ERR_UNKNOWN, AVERROR_UNKNOWN, "unknown error"
>},
> -{ MFX_ERR_NULL_PTR, AVERROR(EINVAL), "NULL pointer"
>},
> -{ MFX_ERR_UNSUPPORTED, AVERROR(ENOSYS), "unsupported"
>},
> -{ MFX_ERR_MEMORY_ALLOC, AVERROR(ENOMEM), "failed to allocate
> memory"},
> -{ MFX_ERR_NOT_ENOUGH_BUFFER,AVERROR(ENOMEM), "insufficient
> input/output buffer" },
> -{ MFX_ERR_INVALID_HANDLE, AVERROR(EINVAL), "invalid handle"
>},
> -{ MFX_ERR_LOCK_MEMORY, AVERROR(EIO),"failed to lock the
> memory block" },
> -{ MFX_ERR_NOT_INITIALIZED, AVERROR_BUG, "not initialized"
>},
> -{ MFX_ERR_NOT_FOUND,AVERROR(ENOSYS), "specified object
> was not found" },
> -/* the following 3 errors should always be handled explicitly, so those
> "mappings"
> - * are for completeness only */
> -{ MFX_ERR_MORE_DATA,AVERROR_UNKNOWN, "expect more data
> at input"},
> -{ MFX_ERR_MORE_SURFACE, AVERROR_UNKNOWN, "expect more
> surface at output"},
> -{ MFX_ERR_MORE_BITSTREAM, AVERROR_UNKNOWN, "expect more
> bitstream at output" },
> -{ MFX_ERR_ABORTED, AVERROR_UNKNOWN, "operation aborted"
>},
> -{ MFX_ERR_DEVICE_LOST, AVERROR(EIO),"device lost"
>},
> -{ MFX_ERR_INCOMPATIBLE_VIDEO_PARAM, AVERROR(EINVAL), "incompatible video
> para
Re: [FFmpeg-devel] [PATCH 1/2] lavc/qsv: use avpriv_ instead of ff_ as prefix for some functions
On Fri, 2020-12-04 at 10:21 -0300, James Almer wrote: > On 12/4/2020 7:24 AM, Anton Khirnov wrote: > > Quoting Haihao Xiang (2020-11-23 09:16:13) > > > ff_qsv_print_iopattern, ff_qsv_print_error and ff_qsv_print_warning can be > > > used outside of lavc. In addition, ff_qsv_map_error is used in > > > libavcodec/qsv.c only, so remove ff_ from ff_qsv_map_error and make it > > > static. > > > > > > Signed-off-by: Haihao Xiang > > > --- > > > > New avpriv functions are strongly discouraged. Dependencies between > > libavcodec and libavfilter are also not good. > > > > Those should either be inline in a private header, or exported as proper > > public API from libavutil. > > Public API, or even avpriv_ symbols that depend on external > libraries/hardware are not a good idea and should be avoided. And these > are all "print error", "print warning" kind of helpers that most likely > have no use outside of libav*. > > All of them look like can be inlined just fine, too, so he should do > that instead. Thanks for the feedback. I sent out a new version of the patch that uses inline functions instead of avpriv functions Regards Haihao > ___ > 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 v2 2/2] qsv: dump more info in error, debug and verbose mode
Dump iopattern mode and the SDK error/warning desciptions for qsv based
filters and iopattern mode for qsvenc
Signed-off-by: Haihao Xiang
---
libavcodec/qsvenc.c | 1 +
libavfilter/qsvvpp.c | 21 +--
libavfilter/qsvvpp.h | 10 +
libavfilter/vf_deinterlace_qsv.c | 36 +++-
libavfilter/vf_scale_qsv.c | 30 +++---
5 files changed, 65 insertions(+), 33 deletions(-)
diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 53377fbf26..b15434d4a4 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -1132,6 +1132,7 @@ int ff_qsv_enc_init(AVCodecContext *avctx, QSVEncContext
*q)
if (!iopattern)
iopattern = MFX_IOPATTERN_IN_SYSTEM_MEMORY;
q->param.IOPattern = iopattern;
+qsv_print_iopattern(avctx, iopattern, "Encoder");
ret = qsvenc_init_session(avctx, q);
if (ret < 0)
diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
index 8d5ff2eb65..1cfad4c445 100644
--- a/libavfilter/qsvvpp.c
+++ b/libavfilter/qsvvpp.c
@@ -505,15 +505,19 @@ static int init_vpp_session(AVFilterContext *avctx,
QSVVPPContext *s)
}
}
-if (ret != MFX_ERR_NONE) {
-av_log(avctx, AV_LOG_ERROR, "Error getting the session handle\n");
+if (ret < 0)
+return qsv_print_error(avctx, ret, "Error getting the session handle");
+else if (ret > 0) {
+qsv_print_warning(avctx, ret, "Warning in getting the session handle");
return AVERROR_UNKNOWN;
}
/* create a "slave" session with those same properties, to be used for vpp
*/
ret = MFXInit(impl, &ver, &s->session);
-if (ret != MFX_ERR_NONE) {
-av_log(avctx, AV_LOG_ERROR, "Error initializing a session for
scaling\n");
+if (ret < 0)
+return qsv_print_error(avctx, ret, "Error initializing a session");
+else if (ret > 0) {
+qsv_print_warning(avctx, ret, "Warning in session initialization");
return AVERROR_UNKNOWN;
}
@@ -646,11 +650,16 @@ int ff_qsvvpp_create(AVFilterContext *avctx,
QSVVPPContext **vpp, QSVVPPParam *p
else if (IS_OPAQUE_MEMORY(s->out_mem_mode))
s->vpp_param.IOPattern |= MFX_IOPATTERN_OUT_OPAQUE_MEMORY;
+/* Print input memory mode */
+qsv_print_iopattern(avctx, s->vpp_param.IOPattern & 0x0F, "VPP");
+/* Print output memory mode */
+qsv_print_iopattern(avctx, s->vpp_param.IOPattern & 0xF0, "VPP");
ret = MFXVideoVPP_Init(s->session, &s->vpp_param);
if (ret < 0) {
-av_log(avctx, AV_LOG_ERROR, "Failed to create a qsvvpp, ret = %d.\n",
ret);
+ret = qsv_print_error(avctx, ret, "Failed to create a qsvvpp");
goto failed;
-}
+} else if (ret > 0)
+qsv_print_warning(avctx, ret, "Warning When creating qsvvpp");
*vpp = s;
return 0;
diff --git a/libavfilter/qsvvpp.h b/libavfilter/qsvvpp.h
index c2bcce7548..da4ed56ce4 100644
--- a/libavfilter/qsvvpp.h
+++ b/libavfilter/qsvvpp.h
@@ -24,21 +24,13 @@
#ifndef AVFILTER_QSVVPP_H
#define AVFILTER_QSVVPP_H
-#include
+#include "libavcodec/qsv_core_internal.h"
#include "avfilter.h"
#define FF_INLINK_IDX(link) ((int)((link)->dstpad - (link)->dst->input_pads))
#define FF_OUTLINK_IDX(link) ((int)((link)->srcpad - (link)->src->output_pads))
-#define QSV_VERSION_ATLEAST(MAJOR, MINOR) \
-(MFX_VERSION_MAJOR > (MAJOR) || \
- MFX_VERSION_MAJOR == (MAJOR) && MFX_VERSION_MINOR >= (MINOR))
-
-#define QSV_RUNTIME_VERSION_ATLEAST(MFX_VERSION, MAJOR, MINOR) \
-((MFX_VERSION.Major > (MAJOR)) || \
-(MFX_VERSION.Major == (MAJOR) && MFX_VERSION.Minor >= (MINOR)))
-
typedef struct QSVVPPContext QSVVPPContext;
typedef struct QSVVPPCrop {
diff --git a/libavfilter/vf_deinterlace_qsv.c b/libavfilter/vf_deinterlace_qsv.c
index 80217c8419..30d1bed526 100644
--- a/libavfilter/vf_deinterlace_qsv.c
+++ b/libavfilter/vf_deinterlace_qsv.c
@@ -202,16 +202,20 @@ static int init_out_session(AVFilterContext *ctx)
}
}
-if (err != MFX_ERR_NONE) {
-av_log(ctx, AV_LOG_ERROR, "Error getting the session handle\n");
+if (err < 0)
+return qsv_print_error(ctx, err, "Error getting the session handle");
+else if (err > 0) {
+qsv_print_warning(ctx, err, "Warning in getting the session handle");
return AVERROR_UNKNOWN;
}
/* create a "slave" session with those same properties, to be used for
* actual deinterlacing */
err = MFXInit(impl, &ver, &s->session);
-if (err != MFX_ERR_NONE) {
-av_log(ctx, AV_LOG_ERROR, "Error initializing a session for
deinterlacing\n");
+if (err < 0)
+return qsv_print_error(ctx, err, "Error initializing a session for
deinterlacing");
+else if (err > 0) {
+qsv_print_warning(ctx, err, "Warning in session initialization");
return AVERROR_UNKNOWN;
}
@@ -309,9 +313,17 @@ static int init_out_session(AVFilte
[FFmpeg-devel] [PATCH v2 1/2] lavc/qsv: make some functions inline
ff_qsv_print_iopattern, ff_qsv_print_error, ff_qsv_print_warning and
ff_qsv_map_error can be used outside of lavc, make them inline in a
private header so that other libraries may include this private header.
In addition, QSV_VERSION_ATLEAST() and QSV_RUNTIME_VERSION_ATLEAST() can
be used across libraries as well.
Signed-off-by: Haihao Xiang
---
Per the comments from Anton and James, I used inline functions instead
of avpriv functions in this patch
libavcodec/Makefile| 2 +-
libavcodec/qsv.c | 132 ---
libavcodec/qsv_core_internal.h | 139 +
libavcodec/qsv_internal.h | 24 +-
libavcodec/qsvdec.c| 16 ++--
libavcodec/qsvenc.c| 36 -
6 files changed, 181 insertions(+), 168 deletions(-)
create mode 100644 libavcodec/qsv_core_internal.h
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 33e08548f5..20d9e5159a 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1196,7 +1196,7 @@ SKIPHEADERS-$(CONFIG_MEDIACODEC) +=
mediacodecdec_common.h mediacodec_surf
SKIPHEADERS-$(CONFIG_MEDIAFOUNDATION) += mf_utils.h
SKIPHEADERS-$(CONFIG_NVDEC)+= nvdec.h
SKIPHEADERS-$(CONFIG_NVENC)+= nvenc.h
-SKIPHEADERS-$(CONFIG_QSV) += qsv.h qsv_internal.h
+SKIPHEADERS-$(CONFIG_QSV) += qsv.h qsv_internal.h
qsv_core_internal.h
SKIPHEADERS-$(CONFIG_QSVDEC) += qsvdec.h
SKIPHEADERS-$(CONFIG_QSVENC) += qsvenc.h
SKIPHEADERS-$(CONFIG_XVMC) += xvmc.h
diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
index 6e3154e1a3..76be7b2e77 100644
--- a/libavcodec/qsv.c
+++ b/libavcodec/qsv.c
@@ -89,110 +89,6 @@ int ff_qsv_level_to_mfx(enum AVCodecID codec_id, int level)
}
}
-static const struct {
-int mfx_iopattern;
-const char *desc;
-} qsv_iopatterns[] = {
-{MFX_IOPATTERN_IN_VIDEO_MEMORY, "input is video memory surface"
},
-{MFX_IOPATTERN_IN_SYSTEM_MEMORY,"input is system memory surface"
},
-{MFX_IOPATTERN_IN_OPAQUE_MEMORY,"input is opaque memory surface"
},
-{MFX_IOPATTERN_OUT_VIDEO_MEMORY,"output is video memory surface"
},
-{MFX_IOPATTERN_OUT_SYSTEM_MEMORY, "output is system memory surface"
},
-{MFX_IOPATTERN_OUT_OPAQUE_MEMORY, "output is opaque memory surface"
},
-};
-
-int ff_qsv_print_iopattern(void *log_ctx, int mfx_iopattern,
- const char *extra_string)
-{
-const char *desc = NULL;
-
-for (int i = 0; i < FF_ARRAY_ELEMS(qsv_iopatterns); i++) {
-if (qsv_iopatterns[i].mfx_iopattern == mfx_iopattern) {
-desc = qsv_iopatterns[i].desc;
-}
-}
-if (!desc)
-desc = "unknown iopattern";
-
-av_log(log_ctx, AV_LOG_VERBOSE, "%s: %s\n", extra_string, desc);
-return 0;
-}
-
-static const struct {
-mfxStatus mfxerr;
-int averr;
-const char *desc;
-} qsv_errors[] = {
-{ MFX_ERR_NONE, 0, "success"
},
-{ MFX_ERR_UNKNOWN, AVERROR_UNKNOWN, "unknown error"
},
-{ MFX_ERR_NULL_PTR, AVERROR(EINVAL), "NULL pointer"
},
-{ MFX_ERR_UNSUPPORTED, AVERROR(ENOSYS), "unsupported"
},
-{ MFX_ERR_MEMORY_ALLOC, AVERROR(ENOMEM), "failed to allocate
memory"},
-{ MFX_ERR_NOT_ENOUGH_BUFFER,AVERROR(ENOMEM), "insufficient
input/output buffer" },
-{ MFX_ERR_INVALID_HANDLE, AVERROR(EINVAL), "invalid handle"
},
-{ MFX_ERR_LOCK_MEMORY, AVERROR(EIO),"failed to lock the
memory block" },
-{ MFX_ERR_NOT_INITIALIZED, AVERROR_BUG, "not initialized"
},
-{ MFX_ERR_NOT_FOUND,AVERROR(ENOSYS), "specified object was
not found" },
-/* the following 3 errors should always be handled explicitly, so those
"mappings"
- * are for completeness only */
-{ MFX_ERR_MORE_DATA,AVERROR_UNKNOWN, "expect more data at
input"},
-{ MFX_ERR_MORE_SURFACE, AVERROR_UNKNOWN, "expect more surface
at output"},
-{ MFX_ERR_MORE_BITSTREAM, AVERROR_UNKNOWN, "expect more
bitstream at output" },
-{ MFX_ERR_ABORTED, AVERROR_UNKNOWN, "operation aborted"
},
-{ MFX_ERR_DEVICE_LOST, AVERROR(EIO),"device lost"
},
-{ MFX_ERR_INCOMPATIBLE_VIDEO_PARAM, AVERROR(EINVAL), "incompatible video
parameters"},
-{ MFX_ERR_INVALID_VIDEO_PARAM, AVERROR(EINVAL), "invalid video
parameters" },
-{ MFX_ERR_UNDEFINED_BEHAVIOR, AVERROR_BUG, "undefined behavior"
},
-{ MFX_ERR_DEVICE_FAILED,
Re: [FFmpeg-devel] [PATCH] avformat/matroskadec: Sanity check codec_id/track type
Michael Niedermayer:
> Fixes: memleak
> Fixes:
> 27766/clusterfuzz-testcase-minimized-ffmpeg_dem_MATROSKA_fuzzer-5198300814508032
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/matroskadec.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index 44db2c8358..18fc2750a1 100644
> --- a/libavformat/matroskadec.c
> +++ b/libavformat/matroskadec.c
> @@ -2318,6 +2318,18 @@ static int matroska_parse_tracks(AVFormatContext *s)
> if (!track->codec_id)
> continue;
>
> +if (track->type == MATROSKA_TRACK_TYPE_AUDIO && track->codec_id[0]
> == 'A') {
> +;
> +} else if (track->type == MATROSKA_TRACK_TYPE_VIDEO &&
> track->codec_id[0] == 'V') {
> +;
> +} else if ((track->type == MATROSKA_TRACK_TYPE_SUBTITLE ||
> track->type == MATROSKA_TRACK_TYPE_METADATA) &&
> + (track->codec_id[0] == 'S' || track->codec_id[0] == 'D'))
> {
> +;
> +} else {
> +av_log(matroska->ctx, AV_LOG_INFO, "Inconsistent track type\n");
> +continue;
> +}
> +
> if (track->audio.samplerate < 0 || track->audio.samplerate > INT_MAX
> ||
> isnan(track->audio.samplerate)) {
> av_log(matroska->ctx, AV_LOG_WARNING,
>
Let me guess: The audio buffer used for Real audio codecs leaks because
matroska_read_close() only frees it for audio tracks, whereas it is
possible that a codec gets one of these audio track codec ids without
being of MATROSKA_TRACK_TYPE_AUDIO (hence also not being of
AVMEDIA_TYPE_AUDIO, which is a bug in itself). So I agree with the aim
of these checks, but I think writing
if ((track->type == MATROSKA_TRACK_TYPE_AUDIO && track->codec_id[0] !=
'A') ||
(track->type == MATROSKA_TRACK_TYPE_VIDEO && track->codec_id[0] !=
'V') ||
...
makes the intent clearer.
- 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".
[FFmpeg-devel] [PATCH] avformat/matroskadec: Sanity check codec_id/track type
Fixes: memleak
Fixes:
27766/clusterfuzz-testcase-minimized-ffmpeg_dem_MATROSKA_fuzzer-5198300814508032
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/matroskadec.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 44db2c8358..18fc2750a1 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -2318,6 +2318,18 @@ static int matroska_parse_tracks(AVFormatContext *s)
if (!track->codec_id)
continue;
+if (track->type == MATROSKA_TRACK_TYPE_AUDIO && track->codec_id[0] ==
'A') {
+;
+} else if (track->type == MATROSKA_TRACK_TYPE_VIDEO &&
track->codec_id[0] == 'V') {
+;
+} else if ((track->type == MATROSKA_TRACK_TYPE_SUBTITLE || track->type
== MATROSKA_TRACK_TYPE_METADATA) &&
+ (track->codec_id[0] == 'S' || track->codec_id[0] == 'D')) {
+;
+} else {
+av_log(matroska->ctx, AV_LOG_INFO, "Inconsistent track type\n");
+continue;
+}
+
if (track->audio.samplerate < 0 || track->audio.samplerate > INT_MAX ||
isnan(track->audio.samplerate)) {
av_log(matroska->ctx, AV_LOG_WARNING,
--
2.17.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] avformat/hashenc: Reuse hash_free() for framehash muxers
Signed-off-by: Andreas Rheinhardt
---
libavformat/hashenc.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/libavformat/hashenc.c b/libavformat/hashenc.c
index ce609f6efa..5523dfd1cd 100644
--- a/libavformat/hashenc.c
+++ b/libavformat/hashenc.c
@@ -156,6 +156,7 @@ static int hash_write_trailer(struct AVFormatContext *s)
return 0;
}
+#endif
static void hash_free(struct AVFormatContext *s)
{
@@ -168,7 +169,6 @@ static void hash_free(struct AVFormatContext *s)
}
av_freep(&c->hashes);
}
-#endif
#if CONFIG_HASH_MUXER
static const AVClass hashenc_class = {
@@ -326,14 +326,6 @@ static int framehash_write_packet(struct AVFormatContext
*s, AVPacket *pkt)
avio_printf(s->pb, "\n");
return 0;
}
-
-static void framehash_free(struct AVFormatContext *s)
-{
-struct HashContext *c = s->priv_data;
-if (c->hashes)
-av_hash_freep(&c->hashes[0]);
-av_freep(&c->hashes);
-}
#endif
#if CONFIG_FRAMEHASH_MUXER
@@ -353,7 +345,7 @@ AVOutputFormat ff_framehash_muxer = {
.init = framehash_init,
.write_header = framehash_write_header,
.write_packet = framehash_write_packet,
-.deinit= framehash_free,
+.deinit= hash_free,
.flags = AVFMT_VARIABLE_FPS | AVFMT_TS_NONSTRICT |
AVFMT_TS_NEGATIVE,
.priv_class= &framehash_class,
@@ -377,7 +369,7 @@ AVOutputFormat ff_framemd5_muxer = {
.init = framehash_init,
.write_header = framehash_write_header,
.write_packet = framehash_write_packet,
-.deinit= framehash_free,
+.deinit= hash_free,
.flags = AVFMT_VARIABLE_FPS | AVFMT_TS_NONSTRICT |
AVFMT_TS_NEGATIVE,
.priv_class= &framemd5_class,
--
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 2/2] avcodec/dynamic_hdr10_plus: don't take a GetBitContext as input argument
On Mon, Dec 7, 2020 at 1:23 AM Jan Ekström wrote: > > On Sun, Dec 6, 2020 at 5:44 PM James Almer wrote: > > > > Create a local one instead from a byte buffer input argument. > > > > Signed-off-by: James Almer > > The actual change mentioned in the commit message is LGTM, and the > updated sanity checks seem good (since now the alternatives at that > point are either 3+3 (2094-40) or 3+4 (closed captions)), but they are > pretty separate from the actual change of this commit. So in that > sense it might make sense to just separate them into their own fixup > commit when pushing. Or at least mention the sanity check fixups in > the commit message instead of them being a silent good change. For the record, I only now grasped after it being mentioned that what I took for just sanity check fixups are actually needed for the gdc changes since otherwise the size variable's value is out-of-sync. So yea, overall LGTM as long as that part of the change set is mentioned, since otherwise it just looked like nice (but unrelated) sanity check fixups. Jan ___ 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] avcodec/hevc_sei: split Dynamic HDR10+ SEI parsing into its own function
On Sun, Dec 6, 2020 at 5:43 PM James Almer wrote: > > Signed-off-by: James Almer 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/2] avcodec/dynamic_hdr10_plus: don't take a GetBitContext as input argument
On Sun, Dec 6, 2020 at 5:44 PM James Almer wrote: > > Create a local one instead from a byte buffer input argument. > > Signed-off-by: James Almer The actual change mentioned in the commit message is LGTM, and the updated sanity checks seem good (since now the alternatives at that point are either 3+3 (2094-40) or 3+4 (closed captions)), but they are pretty separate from the actual change of this commit. So in that sense it might make sense to just separate them into their own fixup commit when pushing. Or at least mention the sanity check fixups in the commit message instead of them being a silent good change. Jan ___ 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] avfilter: add asuperpass and asuperstop filter
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 50 ++
libavfilter/Makefile | 2 +
libavfilter/af_asupercut.c | 133 +++--
libavfilter/allfilters.c | 2 +
4 files changed, 183 insertions(+), 4 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 3a31f72d79..5519d90327 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -2733,6 +2733,56 @@ Set input gain level. Allowed range is from 0 to 1.
Default value is 1.
This filter supports the all above options as @ref{commands}.
+@section asuperpass
+Apply high order Butterworth band-pass filter.
+
+The filter accepts the following options:
+
+@table @option
+@item centerf
+Set center frequency in Hertz. Allowed range is 2 to 192000.
+Default value is 1000.
+
+@item order
+Set filter order. Available values are from 4 to 20.
+Default value is 4.
+
+@item qfactor
+Set Q-factor. Allowed range is from 0 to 999. Default value is 1.
+
+@item level
+Set input gain level. Allowed range is from 0 to 1. Default value is 1.
+@end table
+
+@subsection Commands
+
+This filter supports the all above options as @ref{commands}.
+
+@section asuperstop
+Apply high order Butterworth band-stop filter.
+
+The filter accepts the following options:
+
+@table @option
+@item centerf
+Set center frequency in Hertz. Allowed range is 2 to 192000.
+Default value is 1000.
+
+@item order
+Set filter order. Available values are from 4 to 20.
+Default value is 4.
+
+@item qfactor
+Set Q-factor. Allowed range is from 0 to 999. Default value is 1.
+
+@item level
+Set input gain level. Allowed range is from 0 to 1. Default value is 1.
+@end table
+
+@subsection Commands
+
+This filter supports the all above options as @ref{commands}.
+
@section atempo
Adjust audio tempo.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 77cd55688b..4a96e04999 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -92,6 +92,8 @@ OBJS-$(CONFIG_ASTREAMSELECT_FILTER) +=
f_streamselect.o framesync.o
OBJS-$(CONFIG_ASUBBOOST_FILTER) += af_asubboost.o
OBJS-$(CONFIG_ASUBCUT_FILTER)+= af_asupercut.o
OBJS-$(CONFIG_ASUPERCUT_FILTER) += af_asupercut.o
+OBJS-$(CONFIG_ASUPERPASS_FILTER) += af_asupercut.o
+OBJS-$(CONFIG_ASUPERSTOP_FILTER) += af_asupercut.o
OBJS-$(CONFIG_ATEMPO_FILTER) += af_atempo.o
OBJS-$(CONFIG_ATILT_FILTER) += af_atilt.o
OBJS-$(CONFIG_ATRIM_FILTER) += trim.o
diff --git a/libavfilter/af_asupercut.c b/libavfilter/af_asupercut.c
index 6d0a2b79a9..48738ad083 100644
--- a/libavfilter/af_asupercut.c
+++ b/libavfilter/af_asupercut.c
@@ -1,4 +1,7 @@
/*
+ * Copyright (c) 2005 Boðaç Topaktaþ
+ * Copyright (c) 2020 Paul B Mahol
+ *
* This file is part of FFmpeg.
*
* FFmpeg is free software; you can redistribute it and/or
@@ -33,6 +36,7 @@ typedef struct ASuperCutContext {
double cutoff;
double level;
+double qfactor;
int order;
int filter_count;
@@ -93,10 +97,11 @@ static int get_coeffs(AVFilterContext *ctx)
if (s->bypass)
return 0;
-s->filter_count = s->order / 2 + (s->order & 1);
-calc_q_factors(s->order, q);
-
if (!strcmp(ctx->filter->name, "asubcut")) {
+s->filter_count = s->order / 2 + (s->order & 1);
+
+calc_q_factors(s->order, q);
+
if (s->order & 1) {
BiquadCoeffs *coeffs = &s->coeffs[0];
double omega = 2. * tan(M_PI * w0);
@@ -119,7 +124,11 @@ static int get_coeffs(AVFilterContext *ctx)
coeffs->a1 = -2.0 * (K * K - 1.0) * norm;
coeffs->a2 = -(1.0 - K / q[idx] + K * K) * norm;
}
-} else {
+} else if (!strcmp(ctx->filter->name, "asupercut")) {
+s->filter_count = s->order / 2 + (s->order & 1);
+
+calc_q_factors(s->order, q);
+
if (s->order & 1) {
BiquadCoeffs *coeffs = &s->coeffs[0];
double omega = 2. * tan(M_PI * w0);
@@ -142,6 +151,74 @@ static int get_coeffs(AVFilterContext *ctx)
coeffs->a1 = -2.0 * (K * K - 1.0) * norm;
coeffs->a2 = -(1.0 - K / q[idx] + K * K) * norm;
}
+} else if (!strcmp(ctx->filter->name, "asuperpass")) {
+double alpha, beta, gamma, theta;
+double theta_0 = 2. * M_PI * (s->cutoff / inlink->sample_rate);
+double d_E;
+
+s->filter_count = s->order / 2;
+d_E = (2. * tan(theta_0 / (2. * s->qfactor))) / sin(theta_0);
+
+for (int b = 0; b < s->filter_count; b += 2) {
+double D = 2. * sin(((b + 1) * M_PI) / (2. * s->filter_count));
+double A = (1. + pow((d_E / 2.), 2)) / (D * d_E / 2.);
+double d = sqrt((d_E * D) / (A + sqrt(A * A - 1.)));
+double B = D * (d_E / 2.) / d;
+double W = B + sqrt(B * B - 1.);
+
+for (int j = 0; j < 2; j++) {
+BiquadCoeffs *coeffs = &s->coeffs[b
Re: [FFmpeg-devel] [PATCH v2 000/162] VLC, esp. init_vlc patches
Andreas Rheinhardt: > This is the second version of my init_vlc patchset [1]. Given the > feedback I received for the last version I stressed thread-safety of > init functions of decoders. As a consequence, the amount of decoders > with FF_CODEC_CAP_INIT_THREADSAFE increased by 25 (some of them were > already thread-safe, just the flag was missing). I am not finished yet*, > but I don't see a reason to postpone sending this patchset already. > > It now saves 146KiB from the binary (and much more when using hardcoded > tables). > > [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-November/272127.html > > Two patches of this patchset (#55 and #161) change MIPS code; this is > untested as I don't have a MIPS. Would be nice if someone could test it. > > *: AAC needs much more work (e.g. these decoders claim to be > init-threadsafe, but aren't). > Will apply this set tomorrow (with the exception of VC-1, where I think I missed a slight optimization) unless there are objections. - 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/2] avformat/framecrcenc: Make side-data checksums endian-independent
Andriy Gelman:
> On Sun, 06. Dec 04:09, Andreas Rheinhardt wrote:
>> Do this by converting big-endian side data to little endian for
>> checksumming. Fixes the ts-demux FATE test.
>
> It's quite nicely done imo.
>
> Same as Michael, I enabled ts-demux test in link below and it worked fine
> (PPC64 qemu)
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20201206030934.395352-2-andreas.rheinha...@gmail.com/
>
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> a) When commenting the #if HAVE_BIGENDIAN out, I get the same checksum
>> for the test in [1] as Andriy got on a real BE system; I have not done
>> more testing, lacking actual BE hardware. In particular, the claim about
>> the ts-demux FATE test is untested.
>> b) If side data doesn't have the expected size, then LE and BE might
>> still produce different results (but then there must be a bigger problem
>> elsewhere).
>> c) This code here is designed to work even after the next major version
>> bump when the size of some members of AVCPBProperties change. (Of course,
>> some FATE checksums will need to be adapted then, but for both LE and BE
>> in the same manner.)
>>
>> libavformat/framecrcenc.c | 61 +++
>> 1 file changed, 56 insertions(+), 5 deletions(-)
>>
>> diff --git a/libavformat/framecrcenc.c b/libavformat/framecrcenc.c
>> index f7c48779a0..390024dbe8 100644
>> --- a/libavformat/framecrcenc.c
>> +++ b/libavformat/framecrcenc.c
>> @@ -21,9 +21,11 @@
>>
>> #include
>>
>> +#include "config.h"
>> #include "libavutil/adler32.h"
>> #include "libavutil/avstring.h"
>> #include "libavutil/intreadwrite.h"
>> +#include "libavcodec/avcodec.h"
>> #include "avformat.h"
>> #include "internal.h"
>>
>> @@ -43,6 +45,19 @@ static int framecrc_write_header(struct AVFormatContext
>> *s)
>> return ff_framehash_write_header(s);
>> }
>>
>> +#if HAVE_BIGENDIAN
>> +static void inline bswap(char *buf, int offset, int size)
>> +{
>> +if (size == 8) {
>> +uint64_t val = AV_RN64(buf + offset);
>> +AV_WN64(buf + offset, av_bswap64(val));
>> +} else if (size == 4) {
>> +uint32_t val = AV_RN32(buf + offset);
>> +AV_WN32(buf + offset, av_bswap32(val));
>> +}
>
> Just wondering why you decided this way with av_bswap and not AV_WLx
> as in the code below.
>
I thought that maybe we want to some day use the BE checksum in our FATE
tests (at least for some types of side data) in which case we would have
to do a conversion for LE, hence bswap.
>> +}
>> +#endif
>> +
>> static int framecrc_write_packet(struct AVFormatContext *s, AVPacket *pkt)
>> {
>> uint32_t crc = av_adler32_update(0, pkt->data, pkt->size);
>> @@ -58,17 +73,53 @@ static int framecrc_write_packet(struct AVFormatContext
>> *s, AVPacket *pkt)
>>
>> for (i=0; iside_data_elems; i++) {
>> const AVPacketSideData *const sd = &pkt->side_data[i];
>> +const uint8_t *data = sd->data;
>> uint32_t side_data_crc = 0;
>> -if (HAVE_BIGENDIAN && AV_PKT_DATA_PALETTE ==
>> pkt->side_data[i].type) {
>> +
>> +switch (sd->type) {
>> +#if HAVE_BIGENDIAN
>> +uint8_t buf[FFMAX(sizeof(AVCPBProperties),
>> + sizeof(AVProducerReferenceTime))];
>> +case AV_PKT_DATA_PALETTE:
>> +case AV_PKT_DATA_REPLAYGAIN:
>> +case AV_PKT_DATA_DISPLAYMATRIX:
>> +case AV_PKT_DATA_STEREO3D:
>
>
>
>> +case AV_PKT_DATA_AUDIO_SERVICE_TYPE:
>> +case AV_PKT_DATA_FALLBACK_TRACK:
>> +case AV_PKT_DATA_MASTERING_DISPLAY_METADATA:
>> +case AV_PKT_DATA_SPHERICAL:
>> +case AV_PKT_DATA_CONTENT_LIGHT_LEVEL:
>> +case AV_PKT_DATA_S12M_TIMECODE:
>> for (int j = 0; j < sd->size / 4; j++) {
>> uint8_t buf[4];
>> AV_WL32(buf, AV_RB32(sd->data + 4 * j));
>> side_data_crc = av_adler32_update(side_data_crc, buf,
>> 4);
>> }
>> -} else {
>> -side_data_crc = av_adler32_update(0,
>> - pkt->side_data[i].data,
>> - pkt->side_data[i].size);
>> +break;
>> +case AV_PKT_DATA_CPB_PROPERTIES:
>> +#define BSWAP(struct, field) bswap(buf, offsetof(struct, field),
>> sizeof(((struct){0}).field))
>> +if (sd->size == sizeof(AVCPBProperties)) {
>> +memcpy(buf, sd->data, sizeof(AVCPBProperties));
>> +data = buf;
>> +BSWAP(AVCPBProperties, max_bitrate);
>> +BSWAP(AVCPBProperties, min_bitrate);
>> +BSWAP(AVCPBProperties, avg_bitrate);
>> +BSWAP(AVCPBProperties, buffer_size);
>> +BSWAP(AVCPBProperties, vbv_delay);
>> +}
>> +
[FFmpeg-devel] [PATCH v3 161/191] avcodec/mpegaudiodec: Hardcode tables to save space
The csa_tables (which always consist of 32 entries of four byte each,
but the type depends upon whether the decoder is fixed or
floating-point) are currently initialized once during decoder
initialization; yet it turns out that this is actually no benefit: The
code used to initialize these tables takes up 153 (fixed point) and 122
(floating point) bytes when compiled with GCC 9.3 with -O3 on x64, so it
is better to just hardcode these tables.
Essentially the same applies to the is_tables: They have a size or 128
each and the code to initialize them occupies 149 (fixed point) resp.
140 (floating point) bytes. So hardcode them, too.
To make the origin of the tables clear, references to the code used to
create them have been added.
Signed-off-by: Andreas Rheinhardt
---
Hope the references are fine now
libavcodec/mips/compute_antialias_fixed.h | 3 +-
libavcodec/mips/compute_antialias_float.h | 2 +-
libavcodec/mpegaudiodata.h| 3 --
libavcodec/mpegaudiodec_common.c | 4 ---
libavcodec/mpegaudiodec_fixed.c | 20
libavcodec/mpegaudiodec_float.c | 33 +++
libavcodec/mpegaudiodec_template.c| 39 ++-
7 files changed, 58 insertions(+), 46 deletions(-)
diff --git a/libavcodec/mips/compute_antialias_fixed.h
b/libavcodec/mips/compute_antialias_fixed.h
index a967f67de7..1f395d2302 100644
--- a/libavcodec/mips/compute_antialias_fixed.h
+++ b/libavcodec/mips/compute_antialias_fixed.h
@@ -59,7 +59,8 @@
static void compute_antialias_mips_fixed(MPADecodeContext *s,
GranuleDef *g)
{
-int32_t *ptr, *csa;
+const int32_t *csa;
+int32_t *ptr;
int n, i;
int MAX_lo = 0x;
diff --git a/libavcodec/mips/compute_antialias_float.h
b/libavcodec/mips/compute_antialias_float.h
index e2b4f29f4a..633eb9589d 100644
--- a/libavcodec/mips/compute_antialias_float.h
+++ b/libavcodec/mips/compute_antialias_float.h
@@ -63,7 +63,7 @@ static void compute_antialias_mips_float(MPADecodeContext *s,
GranuleDef *g)
{
float *ptr, *ptr_end;
-float *csa = &csa_table[0][0];
+const float *csa = &csa_table[0][0];
/* temporary variables */
float in1, in2, in3, in4, in5, in6, in7, in8;
float out1, out2, out3, out4;
diff --git a/libavcodec/mpegaudiodata.h b/libavcodec/mpegaudiodata.h
index ec969353f3..01b1f88cd0 100644
--- a/libavcodec/mpegaudiodata.h
+++ b/libavcodec/mpegaudiodata.h
@@ -65,9 +65,6 @@ extern uint16_t ff_scale_factor_modshift[64];
extern const uint8_t ff_mpa_pretab[2][22];
-/* table for alias reduction (XXX: store it as integer !) */
-extern const float ff_ci_table[8];
-
/* Initialize tables shared between the fixed and
* floating point MPEG audio decoders. */
void ff_mpegaudiodec_common_init_static(void);
diff --git a/libavcodec/mpegaudiodec_common.c b/libavcodec/mpegaudiodec_common.c
index 2ac9bb95bc..4333746e9a 100644
--- a/libavcodec/mpegaudiodec_common.c
+++ b/libavcodec/mpegaudiodec_common.c
@@ -396,10 +396,6 @@ const uint8_t ff_mpa_pretab[2][22] = {
{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 2, 2, 3, 3, 3, 2, 0 },
};
-const float ff_ci_table[8] = {
--0.6, -0.535, -0.33, -0.185, -0.095, -0.041, -0.0142, -0.0037,
-};
-
static av_cold void mpegaudiodec_common_init_static(void)
{
const uint8_t *huff_sym = mpa_huffsymbols, *huff_lens = mpa_hufflens;
diff --git a/libavcodec/mpegaudiodec_fixed.c b/libavcodec/mpegaudiodec_fixed.c
index 99d7156764..6eb57c8354 100644
--- a/libavcodec/mpegaudiodec_fixed.c
+++ b/libavcodec/mpegaudiodec_fixed.c
@@ -36,6 +36,26 @@
#define OUT_FMT AV_SAMPLE_FMT_S16
#define OUT_FMT_P AV_SAMPLE_FMT_S16P
+/* Intensity stereo table. See commit b91d46614df189e7905538e7f5c4ed9c7ed0d274
+ * (float based mp1/mp2/mp3 decoders.) for how they were created. */
+static const int32_t is_table[2][16] = {
+{ 0x00, 0x1B0CB1, 0x2ED9EC, 0x40, 0x512614, 0x64F34F, 0x80 },
+{ 0x80, 0x64F34F, 0x512614, 0x40, 0x2ED9EC, 0x1B0CB1, 0x00 }
+};
+
+/* Antialiasing table. See commit ce4a29c066cddfc180979ed86396812f24337985
+ * (optimize antialias) for how they were created. */
+static const int32_t csa_table[8][4] = {
+{ 0x36E129F8, 0xDF128056, 0x15F3AA4E, 0xA831565E },
+{ 0x386E75F2, 0xE1CF24A5, 0x1A3D9A97, 0xA960AEB3 },
+{ 0x3CC6B73A, 0xEBF19FA6, 0x28B856E0, 0xAF2AE86C },
+{ 0x3EEEA054, 0xF45B88BC, 0x334A2910, 0xB56CE868 },
+{ 0x3FB6905C, 0xF9F27F18, 0x39A90F74, 0xBA3BEEBC },
+{ 0x3FF23F20, 0xFD60D1E4, 0x3D531104, 0xBD6E92C4 },
+{ 0x3FFE5932, 0xFF175EE4, 0x3F15B816, 0xBF1905B2 },
+{ 0x3FFFE34A, 0xFFC3612F, 0x3FC34479, 0xBFC37DE5 }
+};
+
#include "mpegaudiodec_template.c"
#if CONFIG_MP1_DECODER
diff --git a/libavcodec/mpegaudiodec_float.c b/libavcodec/mpegaudiodec_float.c
index b8f2c25cac..9633393590 100644
--- a/libavcodec/mpegaudiodec_float.c
+++ b/libavcodec/mpegaudiodec_float.c
@@ -36,6 +3
Re: [FFmpeg-devel] [PATCH] avformat/dv: fix timestamps of audio packets in case of dropped corrupt audio frames
On Sat, 5 Dec 2020, Michael Niedermayer wrote: On Sun, Nov 15, 2020 at 01:14:55AM +0100, Marton Balint wrote: On Fri, 6 Nov 2020, Michael Niedermayer wrote: On Wed, Nov 04, 2020 at 10:44:56PM +0100, Marton Balint wrote: On Wed, 4 Nov 2020, Michael Niedermayer wrote: we have "millisecond" based formats, rounded timestamps we have "exact" cases, maybe the timebase being 1 packet/frame per tick we have "high precission" where the timebase is so precisse it doesnt matter This here though is a bit an oddball, the size if 1 PCM frame is 1 sample The timebase is not a millisecond based one, its not 1 frame either nor is it exact nor high precission. Its 1 video frame, and whatever amount of audio there is in the container which IIUC can differ from 1 video frame even rounded. maybe this just doesnt occur and each frame has a count of samples always rounded to the closes integer count for the video frame. The difference between the audio timestamp and the video timestamp for packets from the same DV frame is at most 0.3929636797*frame_duration as the specification says, as Dave quoted, so I don't see how the error can be bigger than this. It looks to me you are mixing timestamps coming from a demuxer, and timestamps you calculate by counting the number of demuxed/decoded audio samples or video frames. Synchronization is done using the former. But if for example some hardware was using internally a 16 sample buffer and only put multiplies of 16 samples in frames this would introduce a considerable amount of jitter in the timestamps in relation to the actual duration. And using async to fix this without introducing more problems might require some care. I still don't see why timestamp or duration jitter is a problem as long as the error is below frame_duration/2. You can safely use async with min_hard_comp set to frame_duration/2. Thats exactly what i meant. an async like filter which behaves differently or async with a different value there can mess this up. IMHO such mess up is ok when the input is corrupted or invalid. OTOH here it is valid and correct data. In general, don't you find it problematic that the dv demuxer can return different timestamps if you read packets sequentially and if you seek to the end of a file? It looks like a huge bug yes, this is not great but even with your patch you still have this effect when seeking to some point in time a player has to output video and audio to the user at an exact time and that will differ even with async from linear playbacks presentation which is not fixable if you insist on sample counting... I think you misunderstood me, or maybe i didnt state my opinion well, iam not saying that i consider what dv in git does good. Rather that there is a problem beyond what these patches fix. Some concept of timestamp accuracy independant of the distance of representable values would be usefull. if you take teh 1/25 or whatever they are based on dv timestamps and convert that to teh mpeg 90khz based ones thats not making it that accurate. OTOH if you take 1/25 based audio where each packet is 1/25sec worth of samples that very well might be sample accurate or even beyond. knowing this accuracy is usefull for configuring a async like filter or also in knowing how to deal with inconsistencies, is that timestamp jtter ? or the sample rate jittering / some droped samples ? Its important to know as in one instance its the timestamps that need adjustment while in the other the samples need adjustment ATM its down to the user to figure out on a file by file base how to deal or ignore this. Instead it should be possible for an automated system to compensate such issues ... OK, but the automated solution is far from trivial, e.g. it should start with a analysis of the file to check if the sample rate is accurate or not... And if it is not, is the difference constant througout the file? Then there are several methods to fix it and the user might have a preference. E.g consider audio clock "master" and duplicate/drop video frames. Or keep all video frames, but stretch audio (with or without pitch correction - and which filter you want for pitch correction? atempo? rubberband?). So making it automated is not trivial at all. Anyhow, is it OK to apply this patch then? yes Thanks, applied. 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] avcodec/nvdec: Add support for decoding monochrome av1
nvdec change is simple enough. Can't really say too much about the av1dec changes, other than they look generally sensible. ___ 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] avformat/framecrcenc: Make side-data checksums endian-independent
On Sun, 06. Dec 04:09, Andreas Rheinhardt wrote:
> Do this by converting big-endian side data to little endian for
> checksumming. Fixes the ts-demux FATE test.
It's quite nicely done imo.
Same as Michael, I enabled ts-demux test in link below and it worked fine
(PPC64 qemu)
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20201206030934.395352-2-andreas.rheinha...@gmail.com/
>
> Signed-off-by: Andreas Rheinhardt
> ---
> a) When commenting the #if HAVE_BIGENDIAN out, I get the same checksum
> for the test in [1] as Andriy got on a real BE system; I have not done
> more testing, lacking actual BE hardware. In particular, the claim about
> the ts-demux FATE test is untested.
> b) If side data doesn't have the expected size, then LE and BE might
> still produce different results (but then there must be a bigger problem
> elsewhere).
> c) This code here is designed to work even after the next major version
> bump when the size of some members of AVCPBProperties change. (Of course,
> some FATE checksums will need to be adapted then, but for both LE and BE
> in the same manner.)
>
> libavformat/framecrcenc.c | 61 +++
> 1 file changed, 56 insertions(+), 5 deletions(-)
>
> diff --git a/libavformat/framecrcenc.c b/libavformat/framecrcenc.c
> index f7c48779a0..390024dbe8 100644
> --- a/libavformat/framecrcenc.c
> +++ b/libavformat/framecrcenc.c
> @@ -21,9 +21,11 @@
>
> #include
>
> +#include "config.h"
> #include "libavutil/adler32.h"
> #include "libavutil/avstring.h"
> #include "libavutil/intreadwrite.h"
> +#include "libavcodec/avcodec.h"
> #include "avformat.h"
> #include "internal.h"
>
> @@ -43,6 +45,19 @@ static int framecrc_write_header(struct AVFormatContext *s)
> return ff_framehash_write_header(s);
> }
>
> +#if HAVE_BIGENDIAN
> +static void inline bswap(char *buf, int offset, int size)
> +{
> +if (size == 8) {
> +uint64_t val = AV_RN64(buf + offset);
> +AV_WN64(buf + offset, av_bswap64(val));
> +} else if (size == 4) {
> +uint32_t val = AV_RN32(buf + offset);
> +AV_WN32(buf + offset, av_bswap32(val));
> +}
Just wondering why you decided this way with av_bswap and not AV_WLx
as in the code below.
> +}
> +#endif
> +
> static int framecrc_write_packet(struct AVFormatContext *s, AVPacket *pkt)
> {
> uint32_t crc = av_adler32_update(0, pkt->data, pkt->size);
> @@ -58,17 +73,53 @@ static int framecrc_write_packet(struct AVFormatContext
> *s, AVPacket *pkt)
>
> for (i=0; iside_data_elems; i++) {
> const AVPacketSideData *const sd = &pkt->side_data[i];
> +const uint8_t *data = sd->data;
> uint32_t side_data_crc = 0;
> -if (HAVE_BIGENDIAN && AV_PKT_DATA_PALETTE ==
> pkt->side_data[i].type) {
> +
> +switch (sd->type) {
> +#if HAVE_BIGENDIAN
> +uint8_t buf[FFMAX(sizeof(AVCPBProperties),
> + sizeof(AVProducerReferenceTime))];
> +case AV_PKT_DATA_PALETTE:
> +case AV_PKT_DATA_REPLAYGAIN:
> +case AV_PKT_DATA_DISPLAYMATRIX:
> +case AV_PKT_DATA_STEREO3D:
> +case AV_PKT_DATA_AUDIO_SERVICE_TYPE:
> +case AV_PKT_DATA_FALLBACK_TRACK:
> +case AV_PKT_DATA_MASTERING_DISPLAY_METADATA:
> +case AV_PKT_DATA_SPHERICAL:
> +case AV_PKT_DATA_CONTENT_LIGHT_LEVEL:
> +case AV_PKT_DATA_S12M_TIMECODE:
> for (int j = 0; j < sd->size / 4; j++) {
> uint8_t buf[4];
> AV_WL32(buf, AV_RB32(sd->data + 4 * j));
> side_data_crc = av_adler32_update(side_data_crc, buf, 4);
> }
> -} else {
> -side_data_crc = av_adler32_update(0,
> - pkt->side_data[i].data,
> - pkt->side_data[i].size);
> +break;
> +case AV_PKT_DATA_CPB_PROPERTIES:
> +#define BSWAP(struct, field) bswap(buf, offsetof(struct, field),
> sizeof(((struct){0}).field))
> +if (sd->size == sizeof(AVCPBProperties)) {
> +memcpy(buf, sd->data, sizeof(AVCPBProperties));
> +data = buf;
> +BSWAP(AVCPBProperties, max_bitrate);
> +BSWAP(AVCPBProperties, min_bitrate);
> +BSWAP(AVCPBProperties, avg_bitrate);
> +BSWAP(AVCPBProperties, buffer_size);
> +BSWAP(AVCPBProperties, vbv_delay);
> +}
> +goto pod;
> +case AV_PKT_DATA_PRFT:
> +if (sd->size == sizeof(AVProducerReferenceTime)) {
> +memcpy(buf, sd->data, sizeof(AVProducerReferenceTime));
> +data = buf;
> +BSWAP(AVProducerReferenceTime, wallclock);
> +BSWAP(AVP
Re: [FFmpeg-devel] [FFmpeg-cvslog] fate: add a test for HDR10+ metadata in HEVC
On 12/6/2020 1:20 PM, Michael Niedermayer wrote: On Sat, Dec 05, 2020 at 10:24:53PM +, Mohammad Izadi wrote: ffmpeg | branch: master | Mohammad Izadi | Mon Nov 23 13:29:37 2020 -0800| [89e3f5abb72aeb3ef55e7da2b9693a6caa391d5f] | committer: James Almer fate: add a test for HDR10+ metadata in HEVC Signed-off-by: James Almer http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=89e3f5abb72aeb3ef55e7da2b9693a6caa391d5f --- tests/fate/hevc.mak | 3 ++ tests/ref/fate/hevc-hdr10-plus-metadata | 62 + 2 files changed, 65 insertions(+) This breaks fate Assertion n>0 && n<=25 failed at libavcodec/get_bits.h:402 Aborted (core dumped) tests/Makefile:255: recipe for target 'fate-hevc-hdr10-plus-metadata' failed Should be fixed. For context, this breaks with ASSERT_LEVEL == 2, which is why fate isn't completely red. [...] ___ 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 6/7] avcodec/h264idct_template: Fix integer overflow in ff_h264_chroma422_dc_dequant_idct()
On Fri, Nov 06, 2020 at 12:11:09AM +0100, Michael Niedermayer wrote: > Fixes: signed integer overflow: -2105540608 - 2105540608 cannot be > represented in type 'int' > Fixes: > 26870/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5656647567147008 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/h264idct_template.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates signature.asc Description: PGP signature ___ 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/7] avformat/dsfdec: Check block_align more completely
On Fri, Nov 06, 2020 at 12:11:08AM +0100, Michael Niedermayer wrote: > Fixes: infinite loop > Fixes: > 26865/clusterfuzz-testcase-minimized-ffmpeg_dem_DSF_fuzzer-5649473830912000 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/dsfdec.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus signature.asc Description: PGP signature ___ 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/7] avformat/av1dec: check size before addition in probing
On Fri, Nov 06, 2020 at 12:11:06AM +0100, Michael Niedermayer wrote: > Fixes: signed integer overflow: 175 + 2147483571 cannot be represented in > type 'int' > Fixes: > 26833/clusterfuzz-testcase-minimized-ffmpeg_dem_IMAGE2_fuzzer-5969501214212096 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/av1dec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: PGP signature ___ 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/7] avformat/realtextdec: read_ts() in 64bits
On Fri, Nov 06, 2020 at 12:11:05AM +0100, Michael Niedermayer wrote: > Fixes: signed integer overflow: 46671062 * 100 cannot be represented in type > 'int' > Fixes: > 26826/clusterfuzz-testcase-minimized-ffmpeg_dem_REALTEXT_fuzzer-5644062910316544 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/realtextdec.c | 14 +++--- > 1 file changed, 7 insertions(+), 7 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The smallest minority on earth is the individual. Those who deny individual rights cannot claim to be defenders of minorities. - Ayn Rand signature.asc Description: PGP signature ___ 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] [FFmpeg-cvslog] fate: add a test for HDR10+ metadata in HEVC
On Sat, Dec 05, 2020 at 10:24:53PM +, Mohammad Izadi wrote: > ffmpeg | branch: master | Mohammad Izadi | Mon Nov 23 > 13:29:37 2020 -0800| [89e3f5abb72aeb3ef55e7da2b9693a6caa391d5f] | committer: > James Almer > > fate: add a test for HDR10+ metadata in HEVC > > Signed-off-by: James Almer > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=89e3f5abb72aeb3ef55e7da2b9693a6caa391d5f > --- > > tests/fate/hevc.mak | 3 ++ > tests/ref/fate/hevc-hdr10-plus-metadata | 62 > + > 2 files changed, 65 insertions(+) This breaks fate Assertion n>0 && n<=25 failed at libavcodec/get_bits.h:402 Aborted (core dumped) tests/Makefile:255: recipe for target 'fate-hevc-hdr10-plus-metadata' failed [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle signature.asc Description: PGP signature ___ 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/dynamic_hdr10_plus: don't take a GetBitContext as input argument
Create a local one instead from a byte buffer input argument.
Signed-off-by: James Almer
---
libavcodec/dynamic_hdr10_plus.c | 13 ++---
libavcodec/dynamic_hdr10_plus.h | 7 ---
libavcodec/hevc_sei.c | 26 --
3 files changed, 34 insertions(+), 12 deletions(-)
diff --git a/libavcodec/dynamic_hdr10_plus.c b/libavcodec/dynamic_hdr10_plus.c
index 5684bfb2ef..432ef8f6a1 100644
--- a/libavcodec/dynamic_hdr10_plus.c
+++ b/libavcodec/dynamic_hdr10_plus.c
@@ -17,6 +17,7 @@
*/
#include "dynamic_hdr10_plus.h"
+#include "get_bits.h"
static const uint8_t usa_country_code = 0xB5;
static const uint16_t smpte_provider_code = 0x003C;
@@ -30,11 +31,19 @@ static const int32_t knee_point_den = 4095;
static const int32_t bezier_anchor_den = 1023;
static const int32_t saturation_weight_den = 8;
-int ff_parse_itu_t_t35_to_dynamic_hdr10_plus(GetBitContext *gb,
AVDynamicHDRPlus *s)
+int ff_parse_itu_t_t35_to_dynamic_hdr10_plus(AVDynamicHDRPlus *s, const
uint8_t *data,
+ int size)
{
+GetBitContext gbc, *gb = &gbc;
+int ret;
+
if (!s)
return AVERROR(ENOMEM);
+ret = init_get_bits8(gb, data, size);
+if (ret < 0)
+return ret;
+
s->application_version = get_bits(gb, 8);
if (get_bits_left(gb) < 2)
@@ -189,7 +198,5 @@ int ff_parse_itu_t_t35_to_dynamic_hdr10_plus(GetBitContext
*gb, AVDynamicHDRPlus
}
}
-skip_bits(gb, get_bits_left(gb));
-
return 0;
}
diff --git a/libavcodec/dynamic_hdr10_plus.h b/libavcodec/dynamic_hdr10_plus.h
index 06053f88e7..cd7acf0432 100644
--- a/libavcodec/dynamic_hdr10_plus.h
+++ b/libavcodec/dynamic_hdr10_plus.h
@@ -20,15 +20,16 @@
#define AVCODEC_DYNAMIC_HDR10_PLUS_H
#include "libavutil/hdr_dynamic_metadata.h"
-#include "get_bits.h"
/**
* Parse the user data registered ITU-T T.35 to AVbuffer (AVDynamicHDRPlus).
- * @param gb The bit content to be decoded.
* @param s A pointer containing the decoded AVDynamicHDRPlus structure.
+ * @param data The byte array containing the raw ITU-T T.35 data.
+ * @param size Size of the data array in bytes.
*
* @return 0 if succeed. Otherwise, returns the appropriate AVERROR.
*/
-int ff_parse_itu_t_t35_to_dynamic_hdr10_plus(GetBitContext *gb,
AVDynamicHDRPlus *s);
+int ff_parse_itu_t_t35_to_dynamic_hdr10_plus(AVDynamicHDRPlus *s, const
uint8_t *data,
+ int size);
#endif /* AVCODEC_DYNAMIC_HDR10_PLUS_H */
diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
index 8af9f9b29d..3b0fa43439 100644
--- a/libavcodec/hevc_sei.c
+++ b/libavcodec/hevc_sei.c
@@ -216,7 +216,8 @@ static int
decode_registered_user_data_dynamic_hdr_plus(HEVCSEIDynamicHDRPlus *s
if (!metadata)
return AVERROR(ENOMEM);
-err = ff_parse_itu_t_t35_to_dynamic_hdr10_plus(gb, metadata);
+err = ff_parse_itu_t_t35_to_dynamic_hdr10_plus(metadata,
+ gb->buffer +
get_bits_count(gb) / 8, size);
if (err < 0) {
av_free(metadata);
return err;
@@ -229,6 +230,8 @@ static int
decode_registered_user_data_dynamic_hdr_plus(HEVCSEIDynamicHDRPlus *s
return AVERROR(ENOMEM);
}
+skip_bits_long(gb, size * 8);
+
return 0;
}
@@ -241,9 +244,9 @@ static int
decode_nal_sei_user_data_registered_itu_t_t35(HEVCSEI *s, GetBitConte
uint8_t country_code = 0;
uint16_t provider_code = 0;
-if (size < 7)
+if (size < 3)
return AVERROR(EINVAL);
-size -= 7;
+size -= 3;
country_code = get_bits(gb, 8);
if (country_code == 0xFF) {
@@ -258,16 +261,27 @@ static int
decode_nal_sei_user_data_registered_itu_t_t35(HEVCSEI *s, GetBitConte
// A/341 Amendment - 2094-40
const uint16_t smpte2094_40_provider_oriented_code = 0x0001;
const uint8_t smpte2094_40_application_identifier = 0x04;
+uint16_t provider_oriented_code;
+uint8_t application_identifier;
-uint16_t provider_oriented_code = get_bits(gb, 16);
-uint8_t application_identifier = get_bits(gb, 8);
+if (size < 3)
+return AVERROR(EINVAL);
+size -= 3;
+provider_oriented_code = get_bits(gb, 16);
+application_identifier = get_bits(gb, 8);
if (provider_oriented_code == smpte2094_40_provider_oriented_code &&
application_identifier == smpte2094_40_application_identifier) {
return
decode_registered_user_data_dynamic_hdr_plus(&s->dynamic_hdr_plus, gb, size);
}
} else {
-uint32_t user_identifier = get_bits_long(gb, 32);
+uint32_t user_identifier;
+
+if (size < 4)
+return AVERROR(EINVAL);
+size -= 4;
+
+user_identifier = get_bits_long(gb, 32);
switch (user_identifier) {
case MKBETAG('G', 'A', '9', '4'):
return decode_registered_user_data_closed_caption(&s->a53
[FFmpeg-devel] [PATCH 1/2] avcodec/hevc_sei: split Dynamic HDR10+ SEI parsing into its own function
Signed-off-by: James Almer
---
libavcodec/hevc_sei.c | 45 +--
1 file changed, 26 insertions(+), 19 deletions(-)
diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
index 8a29181a31..8af9f9b29d 100644
--- a/libavcodec/hevc_sei.c
+++ b/libavcodec/hevc_sei.c
@@ -207,6 +207,31 @@ static int
decode_nal_sei_user_data_unregistered(HEVCSEIUnregistered *s, GetBitC
return 0;
}
+static int decode_registered_user_data_dynamic_hdr_plus(HEVCSEIDynamicHDRPlus
*s,
+GetBitContext *gb, int
size)
+{
+size_t meta_size;
+int err;
+AVDynamicHDRPlus *metadata = av_dynamic_hdr_plus_alloc(&meta_size);
+if (!metadata)
+return AVERROR(ENOMEM);
+
+err = ff_parse_itu_t_t35_to_dynamic_hdr10_plus(gb, metadata);
+if (err < 0) {
+av_free(metadata);
+return err;
+}
+
+av_buffer_unref(&s->info);
+s->info = av_buffer_create((uint8_t *)metadata, meta_size, NULL, NULL, 0);
+if (!s->info) {
+av_free(metadata);
+return AVERROR(ENOMEM);
+}
+
+return 0;
+}
+
static int decode_nal_sei_user_data_registered_itu_t_t35(HEVCSEI *s,
GetBitContext *gb,
int size)
{
@@ -239,25 +264,7 @@ static int
decode_nal_sei_user_data_registered_itu_t_t35(HEVCSEI *s, GetBitConte
if (provider_oriented_code == smpte2094_40_provider_oriented_code &&
application_identifier == smpte2094_40_application_identifier) {
-int err = 0;
-size_t meta_size = 0;
-AVDynamicHDRPlus *metadata = av_dynamic_hdr_plus_alloc(&meta_size);
-if (!metadata)
-return AVERROR(ENOMEM);
-
-err = ff_parse_itu_t_t35_to_dynamic_hdr10_plus(gb, metadata);
-if (err < 0) {
-av_free(metadata);
-return err;
-}
-
-av_buffer_unref(&s->dynamic_hdr_plus.info);
-s->dynamic_hdr_plus.info = av_buffer_create((uint8_t *)metadata,
-meta_size, NULL, NULL,
0);
-if (!s->dynamic_hdr_plus.info) {
-av_free(metadata);
-return AVERROR(ENOMEM);
-}
+return
decode_registered_user_data_dynamic_hdr_plus(&s->dynamic_hdr_plus, gb, size);
}
} else {
uint32_t user_identifier = get_bits_long(gb, 32);
--
2.29.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".
Re: [FFmpeg-devel] [PATCH 2/2] avformat/framecrcenc: Make side-data checksums endian-independent
On Sun, Dec 06, 2020 at 04:09:34AM +0100, Andreas Rheinhardt wrote:
> Do this by converting big-endian side data to little endian for
> checksumming. Fixes the ts-demux FATE test.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> a) When commenting the #if HAVE_BIGENDIAN out, I get the same checksum
> for the test in [1] as Andriy got on a real BE system; I have not done
> more testing, lacking actual BE hardware. In particular, the claim about
> the ts-demux FATE test is untested.
fate-ts-demux passes with this set on qemu mips
> b) If side data doesn't have the expected size, then LE and BE might
> still produce different results (but then there must be a bigger problem
> elsewhere).
> c) This code here is designed to work even after the next major version
> bump when the size of some members of AVCPBProperties change. (Of course,
> some FATE checksums will need to be adapted then, but for both LE and BE
> in the same manner.)
>
> libavformat/framecrcenc.c | 61 +++
> 1 file changed, 56 insertions(+), 5 deletions(-)
>
> diff --git a/libavformat/framecrcenc.c b/libavformat/framecrcenc.c
> index f7c48779a0..390024dbe8 100644
> --- a/libavformat/framecrcenc.c
> +++ b/libavformat/framecrcenc.c
> @@ -21,9 +21,11 @@
>
> #include
>
> +#include "config.h"
> #include "libavutil/adler32.h"
> #include "libavutil/avstring.h"
> #include "libavutil/intreadwrite.h"
> +#include "libavcodec/avcodec.h"
> #include "avformat.h"
> #include "internal.h"
>
> @@ -43,6 +45,19 @@ static int framecrc_write_header(struct AVFormatContext *s)
> return ff_framehash_write_header(s);
> }
>
> +#if HAVE_BIGENDIAN
> +static void inline bswap(char *buf, int offset, int size)
> +{
> +if (size == 8) {
> +uint64_t val = AV_RN64(buf + offset);
> +AV_WN64(buf + offset, av_bswap64(val));
> +} else if (size == 4) {
> +uint32_t val = AV_RN32(buf + offset);
> +AV_WN32(buf + offset, av_bswap32(val));
> +}
> +}
> +#endif
instead of the #if a av_unused could be used
that way the code is compile tested on LE and its a bit cleaner
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Never trust a computer, one day, it may think you are the virus. -- Compn
signature.asc
Description: PGP signature
___
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/mxfenc: Discard audio until valid video has been received
On Sun, 6 Dec 2020, Andreas Rheinhardt wrote: Marton Balint: On Sat, 5 Dec 2020, Andreas Rheinhardt wrote: Normally, video packets are muxed before audio packets for mxf (there is a dedicated interleave function for this); furthermore the first (video) packet triggers writing the actual header. Yet when the first video packet fails the checks performed on it, codec_ul (a value set based upon properties of the bitstream which necessitates actually inspecting packets) may be NULL; the next packet written (an audio packet) will then trigger outputting the header and this leads to a segfault because codec_ul is dereferenced (this is ticket #7993). Therefore this commit discards audio packets until a valid video packet has been received, fixing said ticket. I don't think in general it is expected by muxers to do anything useful if a write_packet call fails and a subsequent write_packet call is attempted. A write_packet call error is not an error a muxer can recover from, and attempting another write_packet seems like undefined behaviour to me, admittedly this is not really documented. While this is true in lots of error scenarios, it is not true for all of them. It can also be that it is just a single packet that is crap and gets rejected; e.g. the Matroska muxer rejects packets without PTS (i.e. pkt->pts == AV_NO_PTS_VALUE), yet packets after that can be handled just fine. This looks like something that happens to work this way, not intentionally. And how broken the file will be for which the muxer rejected some packets? Another case are some output devices that return AVERROR(EAGAIN). Good point, EAGAIN should not be considered fatal. Although EAGAIN is kind of an exception, because that means that you should wait some time and retry the same packet later, and not continue with the next packet... And given that no prohibition is documented, adding such a prohibition would be an API break that could would require a deprecation period. I think you overestimate the usefulness of this feature. Sure, we can wait the API bump with this change, but I don't think it's worth waiting for a deprecation period. Anyhow, since general solution clearly won't happen anytime soon, feel free to apply the patch as is. But I am certainly not against a more generic solution. How about a new field in AVFormatInternal that a muxer can set if writing more packets is hopeless and should not be attempted any more and if it is set and a new attempt at writing a packet is attempted, it gets rejected without reaching the muxer at all. This should be opt-out, not opt-in IMHO, because not counting EAGAIN I am still skeptical about a particularly useful scenario. Maybe a muxer flag is enough? Although before adding any support for this, I still would like to see a justified use. In the ticket above, it is write_trailer that is crashing because write_trailer tries to output more packets after an earlier write_packet failure. Sure about that? My stacktrace says that it comes from av_interleaved_write_frame(); av_write_trailer() is never called. I tested the command line on the ticket: ffmpeg_g -y -i tmp.vob -map 0 -c:v prores_ks -c:v:122 fits -disposition:a:39 h261 -disposition:a:114 wmv1 -vframes 17 -b:v 587 -strict 1 tmp_.mxf and got this with gdb at the crash: __memcpy_ssse3 at /lib64/libc.so.6 avio_write at libavformat/aviobuf.c:234 mxf_write_cdci_common at libavformat/mxfenc.c:1244 mxf_write_cdci_desc at libavformat/mxfenc.c:1324 mxf_write_package at libavformat/mxfenc.c:1612 mxf_write_header_metadata_sets at libavformat/mxfenc.c:1683 mxf_write_partition at libavformat/mxfenc.c:1944 mxf_write_packet at libavformat/mxfenc.c:2903 write_packet at libavformat/mux.c:731 interleaved_write_packet at libavformat/mux.c:1104 av_write_trailer at libavformat/mux.c:1266 transcode at fftools/ffmpeg.c:4795 main at fftools/ffmpeg.c:4966 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] [RFC] Tech Resolution Process
Jean-Baptiste Kempf (12020-12-05): > --- > doc/dev_community/resolution_process.md | 83 + > 1 file changed, 83 insertions(+) > create mode 100644 doc/dev_community/resolution_process.md > > diff --git a/doc/dev_community/resolution_process.md > b/doc/dev_community/resolution_process.md > new file mode 100644 > index 00..0df584bae4 > --- /dev/null > +++ b/doc/dev_community/resolution_process.md > @@ -0,0 +1,83 @@ > +# Technical Committee > + > +_This document only makes sense with the rules from [the community > document](community)_. > + > +The Technical Committee (**TC**) is here to arbitrate and make decisions when > +technical conflicts occur in the project. > + > +The TC main role is to resolve technical conflicts. > +It is therefore not a technical steering committee, but it is understood that > +some decisions might impact the future of the project. > + > +# Process > + > +## Seizing > + > +The TC can take possession of any technical matter that it sees fit. > + > +To involve the TC in a matter, email tc@ or CC them on an ongoing discussion. > + > +As members of TC are developers, they also can email tc@ to raise an issue. > + > +## Announcement > + > +The TC, once seized, must announce itself on the main mailing list, with a > _[TC]_ tag. > + > +The TC has 2 modes of operation: a RFC one and an internal one. > + > +If the TC thinks it needs the input from the larger community, the TC can > call > +for a RFC. Else, it can decide by itself. I think another clause is needed around here: # If the disagreement involves a member of the TC, that member must recuse # themselves from the internal discussion and the decision vote. > + > +The decision to use a RFC process or an internal discussion is a > discretionary > +decision of the TC. > + > +The TC can also reject a seizure for a few reasons such as: > +the matter was not discussed enough previously; it lacks expertise to reach a > +beneficial decision on the matter; or the matter is too trivial. > + > +### RFC call > + > +In the RFC mode, one person from the TC posts on the mailing list the > +technical question and will request input from the community. > + > +The mail will have the following specification: > +* a precise title > +* a specific tag [TC RFC] > +* a top-level email > +* contain a precise question that does not exceed 100 words and that is > answerable by developers > +* contain a precise end date for the answers. > + > +The answers from the community must be on the main mailing list and must have > +the following specification: > +* keep the tag and the title unchanged > +* limited to 400 words > +* a first-level, answering directly to the main email > +* answering to the question. > + > +Further replies to answers are permitted, as long as they conform to the > +community standards of politeness, they are limited to 100 words, and are not > +nested more than once. (max-depth=2) > + > +After the end-date, no mail on the thread is accepted. > + > +Violations of this rule will give a ban of the mailing-list. This sounds harsh and unnecessary. What are the reasons for these limits? > + > +After all the emails are in, the TC has 96 hours to give its final decision. > + > +### Within TC > + > +In the internal case, the TC has 96 hours to give its final decision. > + > + > +## Decisions > + > +The decisions from the TC will be sent on the mailing list, with the _[TC]_ > tag. > + > +Internally, the TC should take decisions with a majority, or using > +ranked-choice voting. > + > +The reasons for the decisions from the TC can be kept internal by the TC, > +if deemed necessary. This feels shady. I suggest to reverse the wording, and make it much stronger: # The decision of the TC is published along with a summary of the reasons # that lead to the decision, and the archives of the internal discussion # are made available. If there are sensitive pieces of information, they # can be withheld on an exceptional basis, and a convincing reason must be # given. The TC is there to resolve conflicts over technical questions between developers, not to make them worse with secretive dictatorial practices and arbitrary decisions. > + > +The decisions from the TC are final, until the matters are reopened after > +no less than one year, the GA or the TC auto-seizing. Regards, -- Nicolas George signature.asc Description: PGP signature ___ 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] Support HDR10+ metadata for HEVC.
On 12/6/2020 8:13 AM, Hendrik Leppkes wrote: On Sat, Dec 5, 2020 at 11:28 PM James Almer wrote: On 12/1/2020 3:09 PM, Mohammad Izadi wrote: Ian, can you please take a look into it? And if it's fine to push it. Thanks, Mohammad I removed the packet side data addition since it was not used by any module. It can be added when a demuxer needs to propagate it. Also removed the entry for dynamic_hdr10_plus.h in the installed libraries list as it's internal, simplified the test (cut the sample into a single frame, 70kb vs 1mb sample) and split the patch in four commits before pushing. I looked through the committed patch as I was curious how it compares to the code i've been using for a bit, and I noticed some concerns with the GetBitContext handling. - All SEI parsing uses one shared "gb", not only for one SEI message, but the entire SEI NALU (this is fine, but important to know for the other points) Apparently, h264 creates standalone GetBitContexts for each SEI message, whereas hevc doesn't. This was probably written with the former in mind. - ff_parse_itu_t_t35_to_dynamic_hdr10_plus will always consume the *full* GetBitContext with a "skip_bits(gb, get_bits_left(gb));" at its end, so it may skip over a SEI message following the HDR10+ data? - The skip in decode_nal_sei_user_data_registered_itu_t_t35 was moved out of any conditions, so in case of decoding HDR10+ data, it would skip data despite it already being consumed by parsing? It seems like the intention of the code was to pass a copy of the GetBitContex (and not the original) to ff_parse_itu_t_t35_to_dynamic_hdr10_plus, as it would avoid any of these issues, but then I don't know what the skip at the end of the hdr10+ function is for? It may be better to make ff_parse_itu_t_t35_to_dynamic_hdr10_plus() behave like ff_parse_a53_cc(), taking a buffer as argument and creating a GetBitContext internally instead. I'll send a patch for that. ___ 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] avfilter/vf_hwupload_cuda: add YUVA420P to pix_fmts
Signed-off-by: Daniel Raniz Raneland --- libavfilter/vf_hwupload_cuda.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavfilter/vf_hwupload_cuda.c b/libavfilter/vf_hwupload_cuda.c index 33906f2515..c98ef7dd95 100644 --- a/libavfilter/vf_hwupload_cuda.c +++ b/libavfilter/vf_hwupload_cuda.c @@ -60,6 +60,7 @@ static int cudaupload_query_formats(AVFilterContext *ctx) AV_PIX_FMT_NV12, AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV444P, AV_PIX_FMT_P010, AV_PIX_FMT_P016, AV_PIX_FMT_YUV444P16, AV_PIX_FMT_0RGB32, AV_PIX_FMT_0BGR32, +AV_PIX_FMT_YUVA420P, #if CONFIG_VULKAN AV_PIX_FMT_VULKAN, #endif -- 2.29.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".
Re: [FFmpeg-devel] [PATCH] avfilter/vf_hwupload_cuda: add transparent pix_fmts
Oh, I just assumed it would work since YUVA420P worked out of the box and both YUV420P and YUV444P were on the list of supported formats. Removing then since I only need YUVA420P. ___ 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] Support HDR10+ metadata for HEVC.
On Sat, Dec 5, 2020 at 11:28 PM James Almer wrote: > > On 12/1/2020 3:09 PM, Mohammad Izadi wrote: > > Ian, can you please take a look into it? And if it's fine to push it. > > > > Thanks, > > Mohammad > > I removed the packet side data addition since it was not used by any > module. It can be added when a demuxer needs to propagate it. > > Also removed the entry for dynamic_hdr10_plus.h in the installed > libraries list as it's internal, simplified the test (cut the sample > into a single frame, 70kb vs 1mb sample) and split the patch in four > commits before pushing. > I looked through the committed patch as I was curious how it compares to the code i've been using for a bit, and I noticed some concerns with the GetBitContext handling. - All SEI parsing uses one shared "gb", not only for one SEI message, but the entire SEI NALU (this is fine, but important to know for the other points) - ff_parse_itu_t_t35_to_dynamic_hdr10_plus will always consume the *full* GetBitContext with a "skip_bits(gb, get_bits_left(gb));" at its end, so it may skip over a SEI message following the HDR10+ data? - The skip in decode_nal_sei_user_data_registered_itu_t_t35 was moved out of any conditions, so in case of decoding HDR10+ data, it would skip data despite it already being consumed by parsing? It seems like the intention of the code was to pass a copy of the GetBitContex (and not the original) to ff_parse_itu_t_t35_to_dynamic_hdr10_plus, as it would avoid any of these issues, but then I don't know what the skip at the end of the hdr10+ function is for? - Hendrik ___ 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] [RFC] Tech Resolution Process
Hi,
Le sam. 5 déc. 2020 à 15:59, Jean-Baptiste Kempf a écrit :
> +After all the emails are in, the TC has 96 hours to give its final decision.
> +
> +### Within TC
> +
> +In the internal case, the TC has 96 hours to give its final decision.
How is the unavailability of any TC member handled? What about a
quorum? Would you have deputy ("fallback") TC members then?
The unavailability can just be because the weekend falls in this 96H
period, but special (bank or not) holidays also.
--
Christophe
___
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] avcodec/nvdec: Add support for decoding monochrome av1
The nvidia hardware explicitly supports decoding monochrome content,
presumably for the AVIF alpha channel. Supporting this requires an
adjustment in av1dec and explicit monochrome detection in nvdec.
I'm not sure why the monochrome path in av1dec did what it did - it
seems non-functional - YUV440P doesn't seem a logical pix_fmt for
monochrome and conditioning on chroma sub-sampling doesn't make sense.
So I changed it.
I've tested 8bit content, but I haven't found a way to create a 10bit
sample, so that path is untested for now.
Signed-off-by: Philip Langdale
---
libavcodec/av1dec.c | 23 ++-
libavcodec/nvdec.c | 3 +++
libavcodec/version.h | 2 +-
3 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
index d7b2ac9d46..f973d93edc 100644
--- a/libavcodec/av1dec.c
+++ b/libavcodec/av1dec.c
@@ -387,11 +387,14 @@ static int get_pixel_format(AVCodecContext *avctx)
av_log(avctx, AV_LOG_WARNING, "Unknown AV1 pixel format.\n");
}
} else {
-if (seq->color_config.subsampling_x == 1 &&
-seq->color_config.subsampling_y == 1)
-pix_fmt = AV_PIX_FMT_YUV440P;
-else
-av_log(avctx, AV_LOG_WARNING, "Unknown AV1 pixel format.\n");
+if (bit_depth == 8)
+pix_fmt = AV_PIX_FMT_GRAY8;
+else if (bit_depth == 10)
+pix_fmt = AV_PIX_FMT_GRAY10;
+else if (bit_depth == 12)
+pix_fmt = AV_PIX_FMT_GRAY12;
+else
+av_log(avctx, AV_LOG_WARNING, "Unknown AV1 pixel format.\n");
}
av_log(avctx, AV_LOG_DEBUG, "AV1 decode get format: %s.\n",
@@ -430,6 +433,16 @@ static int get_pixel_format(AVCodecContext *avctx)
#endif
#if CONFIG_AV1_VAAPI_HWACCEL
*fmtp++ = AV_PIX_FMT_VAAPI;
+#endif
+break;
+case AV_PIX_FMT_GRAY8:
+#if CONFIG_AV1_NVDEC_HWACCEL
+*fmtp++ = AV_PIX_FMT_CUDA;
+#endif
+break;
+case AV_PIX_FMT_GRAY10:
+#if CONFIG_AV1_NVDEC_HWACCEL
+*fmtp++ = AV_PIX_FMT_CUDA;
#endif
break;
}
diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
index dd7dcccafa..d45804994f 100644
--- a/libavcodec/nvdec.c
+++ b/libavcodec/nvdec.c
@@ -84,6 +84,9 @@ static int map_chroma_format(enum AVPixelFormat pix_fmt)
{
int shift_h = 0, shift_v = 0;
+if (av_pix_fmt_count_planes(pix_fmt) == 1)
+return cudaVideoChromaFormat_Monochrome;
+
av_pix_fmt_get_chroma_sub_sample(pix_fmt, &shift_h, &shift_v);
if (shift_h == 1 && shift_v == 1)
diff --git a/libavcodec/version.h b/libavcodec/version.h
index e4b81da7cb..d1f6fb440a 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
#define LIBAVCODEC_VERSION_MAJOR 58
#define LIBAVCODEC_VERSION_MINOR 114
-#define LIBAVCODEC_VERSION_MICRO 100
+#define LIBAVCODEC_VERSION_MICRO 101
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
--
2.27.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".
