Re: [FFmpeg-devel] autofate system
Hi Andriy, Thanks for letting me know that there is already something doing this. It was something which I thought would exist but I couldn't see it in my searching of the ffmpeg documentation. Something which would be nice is finding a way for us to tie the results back into the fate system, or to have the results of the fate system submitted back into patchwork. What is particularly confusing today is what state origin/master is in with regards to bugs and the official documentation states that as far as testing is concerned, we should be running fate locally, but that doesn't help in the case of interoperability between many patches. One more concern which I think is worth us investigating is multi-platform build reporting. Today, ffmpeg is run on a large variety of platforms with it seemingly growing with SoC computing becoming more popular. Being able to test releases and the tip of git on a wide range of these will help ensure that bugs are caught quickly and effectively. Happy to help integrate whichever system we think would work best for this, just want to ideally have a good means to know that origin/master is constantly well tested! Thanks, *Chris Miceli* On Wed, Oct 7, 2020 at 3:07 AM Andriy Gelman wrote: > On Tue, 06. Oct 16:07, Nicolas George wrote: > > Andriy Gelman (12020-10-06): > > > I'm not familiar with the setup on fate.ffmpeg.org, but we have > something > > > similar running patchwork.ffmpeg.org > > > > > > The site fetches patches from the mailing list. Jenkins server runs > make/fate > > > and reports the results back to patchwork. > > > > That means anybody can run arbitrary code on your server. Native code. > > Does it not worry you? > > > > Thanks Nicolas, good point. Replied privately about the precautions I take. > > -- > Andriy > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] swscale: separate exported and internal range flags
On Wed, Oct 7, 2020 at 2:03 AM Jan Ekström wrote: > > Fixes vf_scale outputting RGB AVFrames with limited range in > case either input or output specifically sets the range. > > Keeps the external interfaces the same, but allows us to retrieve > and set nonzero value for RGB. Additionally defines the default > value of the AVOption as -1 so we can differentiate between > attempting to force limited range and requesting the default. > --- For context, this fixes the issue mentioned in the patch set sent earlier where actually plugging color space values into encoders from the received decoded/filtered AVFrames led to the finding that vf_scale was actually pushing out RGB AVFrames with narrow range, missed so far due to no-one plugging the pipes together. Ref. https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200913102622.168011-5-jee...@gmail.com/#58426 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 2/2] swscale: separate exported and internal range flags
Fixes vf_scale outputting RGB AVFrames with limited range in
case either input or output specifically sets the range.
Keeps the external interfaces the same, but allows us to retrieve
and set nonzero value for RGB. Additionally defines the default
value of the AVOption as -1 so we can differentiate between
attempting to force limited range and requesting the default.
---
libswscale/options.c | 4 +-
libswscale/swscale_internal.h | 3 +
libswscale/utils.c| 154 +++---
3 files changed, 108 insertions(+), 53 deletions(-)
diff --git a/libswscale/options.c b/libswscale/options.c
index 7eb2752543..48dcfc7634 100644
--- a/libswscale/options.c
+++ b/libswscale/options.c
@@ -59,8 +59,8 @@ static const AVOption swscale_options[] = {
{ "dsth","destination height",OFFSET(dstH),
AV_OPT_TYPE_INT,{ .i64 = 16 }, 1, INT_MAX,VE
},
{ "src_format", "source format", OFFSET(srcFormat),
AV_OPT_TYPE_PIXEL_FMT,{ .i64 = DEFAULT }, 0, INT_MAX, VE },
{ "dst_format", "destination format",OFFSET(dstFormat),
AV_OPT_TYPE_PIXEL_FMT,{ .i64 = DEFAULT }, 0, INT_MAX, VE },
-{ "src_range", "source is full range", OFFSET(srcRange),
AV_OPT_TYPE_BOOL, { .i64 = DEFAULT}, 0, 1, VE
},
-{ "dst_range", "destination is full range", OFFSET(dstRange),
AV_OPT_TYPE_BOOL, { .i64 = DEFAULT}, 0, 1, VE
},
+{ "src_range", "source is full range",
OFFSET(exported_srcRange), AV_OPT_TYPE_BOOL, { .i64 = -1}, -1,
1, VE },
+{ "dst_range", "destination is full range",
OFFSET(exported_dstRange), AV_OPT_TYPE_BOOL, { .i64 = -1}, -1,
1, VE },
{ "param0", "scaler param 0",OFFSET(param[0]),
AV_OPT_TYPE_DOUBLE, { .dbl = SWS_PARAM_DEFAULT }, INT_MIN, INT_MAX,VE
},
{ "param1", "scaler param 1",OFFSET(param[1]),
AV_OPT_TYPE_DOUBLE, { .dbl = SWS_PARAM_DEFAULT }, INT_MIN, INT_MAX,VE
},
diff --git a/libswscale/swscale_internal.h b/libswscale/swscale_internal.h
index 013ad51299..7ce475de85 100644
--- a/libswscale/swscale_internal.h
+++ b/libswscale/swscale_internal.h
@@ -625,6 +625,9 @@ typedef struct SwsContext {
SwsDither dither;
SwsAlphaBlend alphablend;
+
+int exported_srcRange;
+int exported_dstRange;
} SwsContext;
//FIXME check init (where 0)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 9ca378bd3b..11e0898360 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -864,6 +864,69 @@ static void fill_xyztables(struct SwsContext *c)
}
}
+static int handle_jpeg(enum AVPixelFormat *format)
+{
+switch (*format) {
+case AV_PIX_FMT_YUVJ420P:
+*format = AV_PIX_FMT_YUV420P;
+return 1;
+case AV_PIX_FMT_YUVJ411P:
+*format = AV_PIX_FMT_YUV411P;
+return 1;
+case AV_PIX_FMT_YUVJ422P:
+*format = AV_PIX_FMT_YUV422P;
+return 1;
+case AV_PIX_FMT_YUVJ444P:
+*format = AV_PIX_FMT_YUV444P;
+return 1;
+case AV_PIX_FMT_YUVJ440P:
+*format = AV_PIX_FMT_YUV440P;
+return 1;
+case AV_PIX_FMT_GRAY8:
+case AV_PIX_FMT_YA8:
+case AV_PIX_FMT_GRAY9LE:
+case AV_PIX_FMT_GRAY9BE:
+case AV_PIX_FMT_GRAY10LE:
+case AV_PIX_FMT_GRAY10BE:
+case AV_PIX_FMT_GRAY12LE:
+case AV_PIX_FMT_GRAY12BE:
+case AV_PIX_FMT_GRAY14LE:
+case AV_PIX_FMT_GRAY14BE:
+case AV_PIX_FMT_GRAY16LE:
+case AV_PIX_FMT_GRAY16BE:
+case AV_PIX_FMT_YA16BE:
+case AV_PIX_FMT_YA16LE:
+return 1;
+default:
+return 0;
+}
+}
+
+static int check_format_range(SwsContext *c, enum AVPixelFormat *format,
+ int range, const char *descriptor)
+{
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(*format);
+int default_range = handle_jpeg(format);
+av_assert0(desc);
+
+if (isAnyRGB(*format) && !range) {
+// first, handle the special case of limited range RGB
+av_log(c, AV_LOG_WARNING,
+ "%s range set to limited for %s, unsupported! "
+ "Overriding to full range.\n",
+ descriptor ? descriptor : "Color", desc->name);
+
+return 1;
+}
+
+
+if (range != -1)
+// for YCbCr and gray, we return the value if set
+return range;
+
+return isAnyRGB(*format) ? 1 : default_range;
+}
+
int sws_setColorspaceDetails(struct SwsContext *c, const int inv_table[4],
int srcRange, const int table[4], int dstRange,
int brightness, int contrast, int saturation)
@@ -876,10 +939,23 @@ int sws_setColorspaceDetails(struct SwsContext *c, const
int inv_table[4],
desc_dst =
[FFmpeg-devel] [PATCH 1/2] swscale/swscale_internal: interpret RGB paletted pixel formats as RGB
This makes isAnyRGB return true for AV_PIX_FMT_PAL8 which is currently
the only pixel format with this flag.
This lets us have a single query for formats where we need to force
range as only full range content is supported.
---
libswscale/swscale_internal.h| 2 +-
tests/ref/fate/sws-pixdesc-query | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/libswscale/swscale_internal.h b/libswscale/swscale_internal.h
index d207d3beff..013ad51299 100644
--- a/libswscale/swscale_internal.h
+++ b/libswscale/swscale_internal.h
@@ -775,7 +775,7 @@ static av_always_inline int isAnyRGB(enum AVPixelFormat
pix_fmt)
{
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pix_fmt);
av_assert0(desc);
-return (desc->flags & AV_PIX_FMT_FLAG_RGB) ||
+return (desc->flags & (AV_PIX_FMT_FLAG_RGB | AV_PIX_FMT_FLAG_PAL)) ||
pix_fmt == AV_PIX_FMT_MONOBLACK || pix_fmt == AV_PIX_FMT_MONOWHITE;
}
diff --git a/tests/ref/fate/sws-pixdesc-query b/tests/ref/fate/sws-pixdesc-query
index c3cccfa492..42e82389af 100644
--- a/tests/ref/fate/sws-pixdesc-query
+++ b/tests/ref/fate/sws-pixdesc-query
@@ -570,6 +570,7 @@ AnyRGB:
gbrpf32le
monob
monow
+ pal8
rgb0
rgb24
rgb32
--
2.26.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] avformat/mpegts: ensure seekback for small probesize
On Mon, 05. Oct 10:31, Marton Balint wrote: > > > On Sun, 4 Oct 2020, Andriy Gelman wrote: > > > From: Andriy Gelman > > > > get_packet_size() may read upto PROBE_PACKET_MAX_BUF bytes, which may be > > larger than probesize. > > > > Signed-off-by: Andriy Gelman > > --- > > > > An alternative could be to make sure we don't read more than s->probesize > > bytes > > in get_packet_size(), but because this function is also called during resync > > (midstream) limiting the read bytes may not be the best option. > > > > libavformat/mpegts.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c > > index 50d4d5e9bc..019b627d51 100644 > > --- a/libavformat/mpegts.c > > +++ b/libavformat/mpegts.c > > @@ -3054,7 +3054,7 @@ static int mpegts_read_header(AVFormatContext *s) > > > > s->internal->prefer_codec_framerate = 1; > > > > -if (ffio_ensure_seekback(pb, probesize) < 0) > > +if (ffio_ensure_seekback(pb, FFMAX(probesize, PROBE_PACKET_MAX_BUF)) < > > 0) > > av_log(s, AV_LOG_WARNING, "Failed to allocate buffers for > > seekback\n"); > > I posted a similar patch not long ago which is I think better because it > also takes into account ts->resync_size. > > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200929211021.25030-4-...@passwd.hu/ Thanks, I missed in your patch in the set. -- Andriy ___ 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] libavcodec/adts_header: add frame_length field and avpriv function to parse AAC ADTS header
From: ffmpeg-devel on behalf of James Almer
Sent: Tuesday, October 6, 2020 8:47 PM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] libavcodec/adts_header: add frame_length
field and avpriv function to parse AAC ADTS header
On 10/6/2020 11:30 AM, Nachiket Tarate wrote:
> These will be used by HLS demuxer for SAMPLE-AES decryption.
>
> Signed-off-by: Nachiket Tarate
> ---
> libavcodec/adts_header.c | 18 ++
> libavcodec/adts_header.h | 4
> 2 files changed, 22 insertions(+)
>
> diff --git a/libavcodec/adts_header.c b/libavcodec/adts_header.c
> index 0889820f8a..006455b110 100644
> --- a/libavcodec/adts_header.c
> +++ b/libavcodec/adts_header.c
> @@ -3,6 +3,7 @@
> * Copyright (c) 2003 Fabrice Bellard
> * Copyright (c) 2003 Michael Niedermayer
> * Copyright (c) 2009 Alex Converse
> + * Copyright (c) 2020 Nachiket Tarate
> *
> * This file is part of FFmpeg.
> *
> @@ -66,6 +67,23 @@ int ff_adts_header_parse(GetBitContext *gbc,
> AACADTSHeaderInfo *hdr)
> hdr->sample_rate= avpriv_mpeg4audio_sample_rates[sr];
> hdr->samples= (rdb + 1) * 1024;
> hdr->bit_rate = size * 8 * hdr->sample_rate / hdr->samples;
> +hdr->frame_length= size;
>
> return size;
> }
> +
> +int avpriv_adts_header_parse (AACADTSHeaderInfo *hdr, const uint8_t *buf,
> size_t size)
You're making sizeof(AACADTSHeaderInfo) part of the ABI this way, which
is not desirable. If you look at avpriv_ac3_parse_header(), it takes a
pointer to pointer to AC3HeaderInfo, and allocates it if needed.
Also, you should instead add this function to adts_parser.c and make it
return AVERROR(ENOSYS) when CONFIG_ADTS_HEADER is 0. This is done so the
symbol is always present even when the functionality is not.
Nachiket> I will do these changes and resubmit the patch.
I assume you're adding this function because you need AACADTSHeaderInfo
fields that av_adts_header_parse() alone does not provide, like
frame_length?
Nachiket > Yes. Your understanding is correct.
> +{
> +int ret = 0;
> +GetBitContext gb;
> +if (size < AV_AAC_ADTS_HEADER_SIZE)
> +return AVERROR_INVALIDDATA;
> +ret = init_get_bits8(, buf, AV_AAC_ADTS_HEADER_SIZE);
> +if (ret < 0)
> +return ret;
> +ret = ff_adts_header_parse(, hdr);
> +if (ret < 0)
> +return ret;
> +return 0;
> +}
> +
> diff --git a/libavcodec/adts_header.h b/libavcodec/adts_header.h
> index f615f6a9f9..d33bd61818 100644
> --- a/libavcodec/adts_header.h
> +++ b/libavcodec/adts_header.h
> @@ -2,6 +2,7 @@
> * AAC ADTS header decoding prototypes and structures
> * Copyright (c) 2003 Fabrice Bellard
> * Copyright (c) 2003 Michael Niedermayer
> + * Copyright (c) 2020 Nachiket Tarate
> *
> * This file is part of FFmpeg.
> *
> @@ -34,6 +35,7 @@ typedef struct AACADTSHeaderInfo {
> uint8_t sampling_index;
> uint8_t chan_config;
> uint8_t num_aac_frames;
> +uint32_t frame_length;
> } AACADTSHeaderInfo;
>
> /**
> @@ -47,4 +49,6 @@ typedef struct AACADTSHeaderInfo {
> */
> int ff_adts_header_parse(GetBitContext *gbc, AACADTSHeaderInfo *hdr);
>
> +int avpriv_adts_header_parse (AACADTSHeaderInfo *hdr, const uint8_t *buf,
> size_t size);
> +
> #endif /* AVCODEC_ADTS_HEADER_H */
>
___
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] libswcale/input: use more accurate planer rgb16 yuv conversions
On Sat, Oct 03, 2020 at 04:31:58PM -0700, mindm...@gmail.com wrote: > From: Mark Reid > > These conversion appears to be exhibiting the same rounding error as the > rgbf32 formats where. > I seperated the rounding value from the 16 and 128 offsets, I think it makes > it a little more clear. > > --- > libswscale/input.c | 6 ++-- > tests/ref/fate/filter-pixfmts-scale| 32 +++--- > tests/ref/fate/psd-rgb48 | 2 +- > tests/ref/fate/psd-rgba64 | 2 +- > tests/ref/fate/sws-floatimg-cmp| 32 +++--- > tests/ref/vsynth/vsynth1-ffv1-v3-rgb48 | 4 +-- > tests/ref/vsynth/vsynth1-r210 | 4 +-- > tests/ref/vsynth/vsynth2-ffv1-v3-rgb48 | 4 +-- > tests/ref/vsynth/vsynth2-r210 | 4 +-- > tests/ref/vsynth/vsynth3-ffv1-v3-rgb48 | 4 +-- > tests/ref/vsynth/vsynth3-r210 | 4 +-- > tests/ref/vsynth/vsynth_lena-ffv1-v3-rgb48 | 4 +-- > tests/ref/vsynth/vsynth_lena-r210 | 4 +-- > 13 files changed, 53 insertions(+), 53 deletions(-) will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In fact, the RIAA has been known to suggest that students drop out of college or go to community college in order to be able to afford settlements. -- The RIAA 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] autofate system
On Tue, 06. Oct 16:07, Nicolas George wrote: > Andriy Gelman (12020-10-06): > > I'm not familiar with the setup on fate.ffmpeg.org, but we have something > > similar running patchwork.ffmpeg.org > > > > The site fetches patches from the mailing list. Jenkins server runs > > make/fate > > and reports the results back to patchwork. > > That means anybody can run arbitrary code on your server. Native code. > Does it not worry you? > Thanks Nicolas, good point. Replied privately about the precautions I take. -- Andriy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/3] avfilter/vf_minterpolate: Reject too small dimensions
The latter code relies upon the dimensions to be not too small;
otherwise one will call av_clip() with min > max lateron which aborts
in case ASSERT_LEVEL is >= 2 or one will get a nonsense result that may
lead to a heap-buffer-overflow/underflow. The latter has happened in
ticket #8248 which this commit fixes.
Signed-off-by: Andreas Rheinhardt
---
libavfilter/vf_minterpolate.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavfilter/vf_minterpolate.c b/libavfilter/vf_minterpolate.c
index c9ce80420d..e1fe5e32b5 100644
--- a/libavfilter/vf_minterpolate.c
+++ b/libavfilter/vf_minterpolate.c
@@ -363,6 +363,11 @@ static int config_input(AVFilterLink *inlink)
}
if (mi_ctx->mi_mode == MI_MODE_MCI) {
+if (mi_ctx->b_width < 2 || mi_ctx->b_height < 2) {
+av_log(inlink->dst, AV_LOG_ERROR, "Height or width < %d\n",
+ 2 * mi_ctx->mb_size);
+return AVERROR(EINVAL);
+}
mi_ctx->pixel_mvs = av_mallocz_array(width * height, sizeof(PixelMVS));
mi_ctx->pixel_weights = av_mallocz_array(width * height,
sizeof(PixelWeights));
mi_ctx->pixel_refs = av_mallocz_array(width * height,
sizeof(PixelRefs));
--
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] libavcodec/adts_header: add frame_length field and avpriv function to parse AAC ADTS header
On 10/6/2020 11:30 AM, Nachiket Tarate wrote:
> These will be used by HLS demuxer for SAMPLE-AES decryption.
>
> Signed-off-by: Nachiket Tarate
> ---
> libavcodec/adts_header.c | 18 ++
> libavcodec/adts_header.h | 4
> 2 files changed, 22 insertions(+)
>
> diff --git a/libavcodec/adts_header.c b/libavcodec/adts_header.c
> index 0889820f8a..006455b110 100644
> --- a/libavcodec/adts_header.c
> +++ b/libavcodec/adts_header.c
> @@ -3,6 +3,7 @@
> * Copyright (c) 2003 Fabrice Bellard
> * Copyright (c) 2003 Michael Niedermayer
> * Copyright (c) 2009 Alex Converse
> + * Copyright (c) 2020 Nachiket Tarate
> *
> * This file is part of FFmpeg.
> *
> @@ -66,6 +67,23 @@ int ff_adts_header_parse(GetBitContext *gbc,
> AACADTSHeaderInfo *hdr)
> hdr->sample_rate= avpriv_mpeg4audio_sample_rates[sr];
> hdr->samples= (rdb + 1) * 1024;
> hdr->bit_rate = size * 8 * hdr->sample_rate / hdr->samples;
> +hdr->frame_length= size;
>
> return size;
> }
> +
> +int avpriv_adts_header_parse (AACADTSHeaderInfo *hdr, const uint8_t *buf,
> size_t size)
You're making sizeof(AACADTSHeaderInfo) part of the ABI this way, which
is not desirable. If you look at avpriv_ac3_parse_header(), it takes a
pointer to pointer to AC3HeaderInfo, and allocates it if needed.
Also, you should instead add this function to adts_parser.c and make it
return AVERROR(ENOSYS) when CONFIG_ADTS_HEADER is 0. This is done so the
symbol is always present even when the functionality is not.
I assume you're adding this function because you need AACADTSHeaderInfo
fields that av_adts_header_parse() alone does not provide, like
frame_length?
> +{
> +int ret = 0;
> +GetBitContext gb;
> +if (size < AV_AAC_ADTS_HEADER_SIZE)
> +return AVERROR_INVALIDDATA;
> +ret = init_get_bits8(, buf, AV_AAC_ADTS_HEADER_SIZE);
> +if (ret < 0)
> +return ret;
> +ret = ff_adts_header_parse(, hdr);
> +if (ret < 0)
> +return ret;
> +return 0;
> +}
> +
> diff --git a/libavcodec/adts_header.h b/libavcodec/adts_header.h
> index f615f6a9f9..d33bd61818 100644
> --- a/libavcodec/adts_header.h
> +++ b/libavcodec/adts_header.h
> @@ -2,6 +2,7 @@
> * AAC ADTS header decoding prototypes and structures
> * Copyright (c) 2003 Fabrice Bellard
> * Copyright (c) 2003 Michael Niedermayer
> + * Copyright (c) 2020 Nachiket Tarate
> *
> * This file is part of FFmpeg.
> *
> @@ -34,6 +35,7 @@ typedef struct AACADTSHeaderInfo {
> uint8_t sampling_index;
> uint8_t chan_config;
> uint8_t num_aac_frames;
> +uint32_t frame_length;
> } AACADTSHeaderInfo;
>
> /**
> @@ -47,4 +49,6 @@ typedef struct AACADTSHeaderInfo {
> */
> int ff_adts_header_parse(GetBitContext *gbc, AACADTSHeaderInfo *hdr);
>
> +int avpriv_adts_header_parse (AACADTSHeaderInfo *hdr, const uint8_t *buf,
> size_t size);
> +
> #endif /* AVCODEC_ADTS_HEADER_H */
>
___
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 9/9] avformat/aviobuf: increase default read buffer size to 2*max_buffer_size for streamed data
On Wed, 30 Sep 2020, Paul B Mahol wrote: On Tue, Sep 29, 2020 at 11:10:21PM +0200, Marton Balint wrote: This should increase the effectiveness of ffio_ensure_seekback by reducing the number of buffer reallocations and memmoves/memcpys because even a small seekback window requires max_buffer_size+window_size buffer space. Signed-off-by: Marton Balint --- libavformat/aviobuf.c | 5 + 1 file changed, 5 insertions(+) This patch set fixes demuxing chained oggs via pipe, so I'm not against it. Thanks for testing. Is there anybody who would like to comment on the patch series before I push it? I know that some regression tests for avio would be good, but it is not something I plan working on. Thanks, 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] Document community process
Jean-Baptiste Kempf (12020-10-05): > General Assembly + Main Elections > --- > doc/dev_community/community.md | 60 ++ > 1 file changed, 60 insertions(+) > create mode 100644 doc/dev_community/community.md > > diff --git a/doc/dev_community/community.md b/doc/dev_community/community.md > new file mode 100644 > index 00..4e17ce4d4f > --- /dev/null > +++ b/doc/dev_community/community.md > @@ -0,0 +1,60 @@ > +# FFmpeg project > + > +## Organisation > + > +The FFmpeg project is organized through a community working on global > consensus. > + > +Decisions are taken by the ensemble of active members, through voting and > are aided by two committees. Global nit: I think it would be more readable without a Markdown engine if it were pre-wrapped. > + > +## General Assembly > + > +The ensemble of active members is called the General Assembly (GA). > + > +The General Assembly is sovereign and legitimate for all its decisions > regarding the FFmpeg project. > + > +The General Assembly is made up of active contributors. > + > +Contributors are considered "active contributors" if they have pushed more > than 20 patches in the last 36 months in the main FFmpeg repository, or if > they have been voted in by the GA. Should the vote for non-commit contributors expire after 36 months too? > + > +Additional members are added to the General Assembly through a vote after > proposal by a member of the General Assembly. > + > +## Voting > + > +Voting is done using a ranked voting system, currently running on > https://vote.ffmpeg.org/ . > + > +Majority vote means more than 50% of the expressed ballots. > + > +## Technical Committee > + > +The Technical Committee (TC) is here to arbitrage and take decisions when > technical conflicts occur in the project. They will consider the merits of > all the positions, judge them and take a decision. > + > +The TC resolves technical conflicts but is not a technical steering > committee. > + > +Decisions by the TC are binding for all the contributors. > + > +Decisions taken by the TC can be re-opened after 1 year or by a majority > vote of the General Assembly, requested by one of the member of the GA. > + > +The TC is elected by the General Assembly for a duration of 1 year, and is > composed of 5 members. > +Members can be reelected if they wish. A majority vote in the General > Assembly can trigger a new election of the TC. > + > +The members of the TC can be elected from outside of the GA. > +Candidates for election can either be suggested or self-nominated. > + > +The conflict resolution process is detailed in the [resolution process] > document. > + > +## Community committee > + > +The Community Committee (CC) is here to arbitrage and take decisions when > inter-personal conflicts occur in the project. It will decide quickly and > take actions, for the sake of the project. > + > +The CC can remove privileges of offending members, including removal of > commit access and temporary ban from the community. > + > +Decisions taken by the CC can be re-opened after 1 year or by a majority > vote of the General Assembly. Indefinite bans from the community must be > confirmed by the General Assembly, in a majority vote. > + > +The CC is elected by the General Assembly for a duration of 1 year, and is > composed of 5 members. > +Members can be reelected if they wish. A majority vote in the General > Assembly can trigger a new election of the CC. > + > +The members of the CC can be elected from outside of the GA. > +Candidates for election can either be suggested or self-nominated. > + > +The CC is governed by and responsible for enforcing the Code of Conduct. > + This looks good to me on the whole, not repeating comments by Chris. Two extra comments: The current list of members of both committees should probably be somewhere on the web page. There is a need for a mail address to contact committees. 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".
[FFmpeg-devel] [PATCH] libavcodec/adts_header: add frame_length field and avpriv function to parse AAC ADTS header
These will be used by HLS demuxer for SAMPLE-AES decryption.
Signed-off-by: Nachiket Tarate
---
libavcodec/adts_header.c | 18 ++
libavcodec/adts_header.h | 4
2 files changed, 22 insertions(+)
diff --git a/libavcodec/adts_header.c b/libavcodec/adts_header.c
index 0889820f8a..006455b110 100644
--- a/libavcodec/adts_header.c
+++ b/libavcodec/adts_header.c
@@ -3,6 +3,7 @@
* Copyright (c) 2003 Fabrice Bellard
* Copyright (c) 2003 Michael Niedermayer
* Copyright (c) 2009 Alex Converse
+ * Copyright (c) 2020 Nachiket Tarate
*
* This file is part of FFmpeg.
*
@@ -66,6 +67,23 @@ int ff_adts_header_parse(GetBitContext *gbc,
AACADTSHeaderInfo *hdr)
hdr->sample_rate= avpriv_mpeg4audio_sample_rates[sr];
hdr->samples= (rdb + 1) * 1024;
hdr->bit_rate = size * 8 * hdr->sample_rate / hdr->samples;
+hdr->frame_length = size;
return size;
}
+
+int avpriv_adts_header_parse (AACADTSHeaderInfo *hdr, const uint8_t *buf,
size_t size)
+{
+int ret = 0;
+GetBitContext gb;
+if (size < AV_AAC_ADTS_HEADER_SIZE)
+return AVERROR_INVALIDDATA;
+ret = init_get_bits8(, buf, AV_AAC_ADTS_HEADER_SIZE);
+if (ret < 0)
+return ret;
+ret = ff_adts_header_parse(, hdr);
+if (ret < 0)
+return ret;
+return 0;
+}
+
diff --git a/libavcodec/adts_header.h b/libavcodec/adts_header.h
index f615f6a9f9..d33bd61818 100644
--- a/libavcodec/adts_header.h
+++ b/libavcodec/adts_header.h
@@ -2,6 +2,7 @@
* AAC ADTS header decoding prototypes and structures
* Copyright (c) 2003 Fabrice Bellard
* Copyright (c) 2003 Michael Niedermayer
+ * Copyright (c) 2020 Nachiket Tarate
*
* This file is part of FFmpeg.
*
@@ -34,6 +35,7 @@ typedef struct AACADTSHeaderInfo {
uint8_t sampling_index;
uint8_t chan_config;
uint8_t num_aac_frames;
+uint32_t frame_length;
} AACADTSHeaderInfo;
/**
@@ -47,4 +49,6 @@ typedef struct AACADTSHeaderInfo {
*/
int ff_adts_header_parse(GetBitContext *gbc, AACADTSHeaderInfo *hdr);
+int avpriv_adts_header_parse (AACADTSHeaderInfo *hdr, const uint8_t *buf,
size_t size);
+
#endif /* AVCODEC_ADTS_HEADER_H */
--
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".
Re: [FFmpeg-devel] [PATCH 2/2] libavcodec/ac3tab: rename ff_ac3_sample_rate_tab to avpriv_ac3_sample_rate_tab so that it can be used in libavformat
Anton Khirnov (12020-10-06): > Would you please stop with spamming this propaganda in unrelated topics? > Merging the libraries is your personal opinion, not "the only way > forward". Nobody, including you, has been able to express one practical benefit of having separate libraries that could not be achieved in other, less problematic ways. So no, it is not just my personal opinion. -- 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 2/2] libavcodec/ac3tab: rename ff_ac3_sample_rate_tab to avpriv_ac3_sample_rate_tab so that it can be used in libavformat
Quoting Nicolas George (2020-10-05 12:53:44) > Nachiket Tarate (12020-10-05): > > What is your opinion about Anton Khirnov 's review > > comments ? > > The only way forward is to merge the libraries. The split of shared > objects brings all kinds of issues, including the problem of avpriv > symbols, and no practical benefit. Would you please stop with spamming this propaganda in unrelated topics? Merging the libraries is your personal opinion, not "the only way forward". And I don't know about anyone beside you who wants to do that. Feel free to send patches or RFCs to discuss the topic, but it does not belong in this thread. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/utils: do not fallback to av1dec for probing
Made obsolete via 214998c55ff99586b57c1ccd34a7e6f15c4fcdb8 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/3] avfilter/vf_minterpolate: Fix left shift of negative value
This has happened when initializing the motion estimation context if
width or height of the video was smaller than the block size used
for motion estimation and if the motion interpolation mode indicates
not to use motion estimation.
The solution is of course to only initialize the motion estimation
context if the interpolation mode uses motion estimation.
Signed-off-by: Andreas Rheinhardt
---
libavfilter/vf_minterpolate.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/libavfilter/vf_minterpolate.c b/libavfilter/vf_minterpolate.c
index e1fe5e32b5..bf45662913 100644
--- a/libavfilter/vf_minterpolate.c
+++ b/libavfilter/vf_minterpolate.c
@@ -368,6 +368,15 @@ static int config_input(AVFilterLink *inlink)
2 * mi_ctx->mb_size);
return AVERROR(EINVAL);
}
+ff_me_init_context(me_ctx, mi_ctx->mb_size, mi_ctx->search_param,
+ width, height, 0, (mi_ctx->b_width - 1) <<
mi_ctx->log2_mb_size,
+ 0, (mi_ctx->b_height - 1) << mi_ctx->log2_mb_size);
+
+if (mi_ctx->me_mode == ME_MODE_BIDIR)
+me_ctx->get_cost = _sad_ob;
+else if (mi_ctx->me_mode == ME_MODE_BILAT)
+me_ctx->get_cost = _sbad_ob;
+
mi_ctx->pixel_mvs = av_mallocz_array(width * height, sizeof(PixelMVS));
mi_ctx->pixel_weights = av_mallocz_array(width * height,
sizeof(PixelWeights));
mi_ctx->pixel_refs = av_mallocz_array(width * height,
sizeof(PixelRefs));
@@ -395,13 +404,6 @@ static int config_input(AVFilterLink *inlink)
return AVERROR(EINVAL);
}
-ff_me_init_context(me_ctx, mi_ctx->mb_size, mi_ctx->search_param, width,
height, 0, (mi_ctx->b_width - 1) << mi_ctx->log2_mb_size, 0, (mi_ctx->b_height
- 1) << mi_ctx->log2_mb_size);
-
-if (mi_ctx->me_mode == ME_MODE_BIDIR)
-me_ctx->get_cost = _sad_ob;
-else if (mi_ctx->me_mode == ME_MODE_BILAT)
-me_ctx->get_cost = _sbad_ob;
-
return 0;
fail:
for (i = 0; i < NB_FRAMES; i++)
@@ -830,9 +832,10 @@ static int inject_frame(AVFilterLink *inlink, AVFrame
*avf_in)
return 0;
}
-static int detect_scene_change(MIContext *mi_ctx)
+static int detect_scene_change(AVFilterContext *ctx)
{
-AVMotionEstContext *me_ctx = _ctx->me_ctx;
+MIContext *mi_ctx = ctx->priv;
+AVFilterLink *input = ctx->inputs[0];
uint8_t *p1 = mi_ctx->frames[1].avf->data[0];
ptrdiff_t linesize1 = mi_ctx->frames[1].avf->linesize[0];
uint8_t *p2 = mi_ctx->frames[2].avf->data[0];
@@ -841,9 +844,9 @@ static int detect_scene_change(MIContext *mi_ctx)
if (mi_ctx->scd_method == SCD_METHOD_FDIFF) {
double ret = 0, mafd, diff;
uint64_t sad;
-mi_ctx->sad(p1, linesize1, p2, linesize2, me_ctx->width,
me_ctx->height, );
+mi_ctx->sad(p1, linesize1, p2, linesize2, input->w, input->h, );
emms_c();
-mafd = (double) sad * 100.0 / (me_ctx->height * me_ctx->width) / (1 <<
mi_ctx->bitdepth);
+mafd = (double) sad * 100.0 / (input->h * input->w) / (1 <<
mi_ctx->bitdepth);
diff = fabs(mafd - mi_ctx->prev_mafd);
ret = av_clipf(FFMIN(mafd, diff), 0, 100.0);
mi_ctx->prev_mafd = mafd;
@@ -1191,7 +1194,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*avf_in)
if (!mi_ctx->frames[0].avf)
return 0;
-mi_ctx->scene_changed = detect_scene_change(mi_ctx);
+mi_ctx->scene_changed = detect_scene_change(ctx);
for (;;) {
AVFrame *avf_out;
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/3] avfilter/vf_minterpolate: Remove redundant code for freeing
ad73b32d2922f4237405043d19763229aee0e59e added some code for freeing in
the input's config_props function, yet this is unnecessary as uninit is
called anyway if config_props fails.
Signed-off-by: Andreas Rheinhardt
---
libavfilter/vf_minterpolate.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/libavfilter/vf_minterpolate.c b/libavfilter/vf_minterpolate.c
index bf45662913..969463f021 100644
--- a/libavfilter/vf_minterpolate.c
+++ b/libavfilter/vf_minterpolate.c
@@ -340,7 +340,7 @@ static int config_input(AVFilterLink *inlink)
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(inlink->format);
const int height = inlink->h;
const int width = inlink->w;
-int i, ret = 0;
+int i;
mi_ctx->log2_chroma_h = desc->log2_chroma_h;
mi_ctx->log2_chroma_w = desc->log2_chroma_w;
@@ -380,10 +380,8 @@ static int config_input(AVFilterLink *inlink)
mi_ctx->pixel_mvs = av_mallocz_array(width * height, sizeof(PixelMVS));
mi_ctx->pixel_weights = av_mallocz_array(width * height,
sizeof(PixelWeights));
mi_ctx->pixel_refs = av_mallocz_array(width * height,
sizeof(PixelRefs));
-if (!mi_ctx->pixel_mvs || !mi_ctx->pixel_weights ||
!mi_ctx->pixel_refs) {
-ret = AVERROR(ENOMEM);
-goto fail;
-}
+if (!mi_ctx->pixel_mvs || !mi_ctx->pixel_weights ||
!mi_ctx->pixel_refs)
+return AVERROR(ENOMEM);
if (mi_ctx->me_mode == ME_MODE_BILAT)
if (!(mi_ctx->int_blocks = av_mallocz_array(mi_ctx->b_count,
sizeof(Block
@@ -405,13 +403,6 @@ static int config_input(AVFilterLink *inlink)
}
return 0;
-fail:
-for (i = 0; i < NB_FRAMES; i++)
-av_freep(_ctx->frames[i].blocks);
-av_freep(_ctx->pixel_mvs);
-av_freep(_ctx->pixel_weights);
-av_freep(_ctx->pixel_refs);
-return ret;
}
static int config_output(AVFilterLink *outlink)
--
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 v2 3/3] avformat/mxfdec: Read Apple private Content Light Level from MXF
On Mon, Oct 05, 2020 at 10:18:32AM +0200, Tomas Härdin wrote: > tor 2020-10-01 klockan 22:13 +0200 skrev Michael Niedermayer: > > On Thu, Oct 01, 2020 at 03:29:19PM +0100, Harry Mallon wrote: > > > > On 30 Sep 2020, at 08:32, Michael Niedermayer > > > > wrote: > > > > > > > > fails on big endian > > > > > > > > --- src/tests/ref/fate/mxf-probe-applehdr10 2020-09-28 > > > > 23:21:12.291897976 +0200 > > > > +++ tests/data/fate/mxf-probe-applehdr102020-09-30 > > > > 09:31:38.614653806 +0200 > > > > @@ -14,7 +14,7 @@ > > > > has_b_frames=0 > > > > sample_aspect_ratio=1:1 > > > > display_aspect_ratio=16:9 > > > > -pix_fmt=yuv422p10le > > > > +pix_fmt=yuv422p10be > > > > level=-99 > > > > color_range=tv > > > > color_space=bt2020nc > > > > Test mxf-probe-applehdr10 failed. Look at > > > > tests/data/fate/mxf-probe-applehdr10.err for details. > > > > src/tests/Makefile:255: recipe for target 'fate-mxf-probe-applehdr10' > > > > failed > > > > make: *** [fate-mxf-probe-applehdr10] Error 1 > > > > > > It seems fair that the pixel type is in native endian. > > > > maybe but the endianness of the decoder output doesnt belong in the > > comparission > > > > > > > I'm not really familiar enough with FATE to provide a patch to fix this > > > though. Do any other FATE tests have wildcards or two versions for big > > > and little endian? > > > > i dont see another probe reference file that contains a le/be format > > > > we had le/be issues in other places though where they where fixed by forcing > > a format with specific endianness in the test IIRC > > How about something like this? it solves the problem here. so LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- 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] autofate system
Andriy Gelman (12020-10-06): > I'm not familiar with the setup on fate.ffmpeg.org, but we have something > similar running patchwork.ffmpeg.org > > The site fetches patches from the mailing list. Jenkins server runs make/fate > and reports the results back to patchwork. That means anybody can run arbitrary code on your server. Native code. Does it not worry you? 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] autofate system
Hi, On Tue, 06. Oct 14:16, Chris Miceli wrote: > Hi all, > > I have written a small system called autofate ( > https://github.com/cmiceli/autofate) which is designed to basically run > fate on every commit in master, ideally capturing and then reporting broken > builds. It's written in rust so that it can run on a wide variety of > platforms (I am currently testing on multiple architectures and multiple > operating systems). > > Ideally, I'd love to get this reporting to the fate server and get other's > running on various flavours of hardware where ffmpeg support is used > widely. Right now I have it on 64bit and 32 bit rpi for example. > > What I was wondering is: > 1. Do people think this is a step in the right direction? > 2. How would we like to integrate with FATE server? > 3. How would we like this to report failures? Email? > 4. Any other features desired, I'm happy to add or accept pull requests. > > I look forward to hearing thoughts from the community, have a great day. > I'm not familiar with the setup on fate.ffmpeg.org, but we have something similar running patchwork.ffmpeg.org The site fetches patches from the mailing list. Jenkins server runs make/fate and reports the results back to patchwork. Patchwork itself is an open source project: https://github.com/getpatchwork/patchwork https://github.com/michaelni/patchwork-update-bot Slides to setup the CI in Jenkins: https://speakerdeck.com/stephenfin/mailing-list-meet-ci There are some problems with patchwork when a user sends a new version, but does not send the full series. These patches are not linked and not captured by CI. It would be great to fix this eventually.. Something else to keep in mind: There are often discussions to switch to gitlab or something similar. And they will probably come up again. Thanks, -- Andriy ___ 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/utils: do not fallback to av1dec for probing
On 06.10.2020 15:38, Nicolas George wrote:
Timo Rothenpieler (12020-10-06):
---
libavformat/utils.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index a2e701ea1a..871e655e13 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -222,6 +222,10 @@ static const AVCodec *find_probe_decoder(AVFormatContext
*s, const AVStream *st,
while ((probe_codec = av_codec_iterate())) {
if (probe_codec->id == codec->id &&
av_codec_is_decoder(probe_codec) &&
+/* The av1 "decoder" exists purely for hwaccel purposes.
+ * It cannot probe on its own and causes an error if it
tries.
+ * Remove this check if av1dec ever gains software decode
support. */
+strcmp(probe_codec->name, "av1") &&
!(probe_codec->capabilities & (AV_CODEC_CAP_AVOID_PROBING
| AV_CODEC_CAP_EXPERIMENTAL))) {
return probe_codec;
}
Is this not what AV_CODEC_CAP_AVOID_PROBING is for?
Regards,
No it's not. You want av1dec to be used for probing, but only if it's
the actual hwaccel decoder.
You never want it to be used for probing in any other case.
Which is pretty much the opposite of AV_CODEC_CAP_AVOID_PROBING.
So this either needs a new AV_CODEC_CAP_ flag, or code like this.
Given how unique the situation is for this specific decoder shim, and
that it will likely gain software decode support eventually, this seems
more appropiate to me.
The background to this is that with AV1 enabled cuviddec, which has
rightfully set AV_CODEC_CAP_AVOID_PROBING on it, find_probe_decoder
tries to probe via av1dec, which then fails because av1dec has no
hwaccel set on it.
The same would happen with any other av1 decoder with
AV_CODEC_CAP_AVOID_PROBING set on it.
___
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/utils: do not fallback to av1dec for probing
Timo Rothenpieler (12020-10-06):
> ---
> libavformat/utils.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index a2e701ea1a..871e655e13 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -222,6 +222,10 @@ static const AVCodec *find_probe_decoder(AVFormatContext
> *s, const AVStream *st,
> while ((probe_codec = av_codec_iterate())) {
> if (probe_codec->id == codec->id &&
> av_codec_is_decoder(probe_codec) &&
> +/* The av1 "decoder" exists purely for hwaccel purposes.
> + * It cannot probe on its own and causes an error if it
> tries.
> + * Remove this check if av1dec ever gains software
> decode support. */
> +strcmp(probe_codec->name, "av1") &&
> !(probe_codec->capabilities &
> (AV_CODEC_CAP_AVOID_PROBING | AV_CODEC_CAP_EXPERIMENTAL))) {
> return probe_codec;
> }
Is this not what AV_CODEC_CAP_AVOID_PROBING is for?
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".
[FFmpeg-devel] [PATCH] avformat/utils: do not fallback to av1dec for probing
---
libavformat/utils.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index a2e701ea1a..871e655e13 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -222,6 +222,10 @@ static const AVCodec *find_probe_decoder(AVFormatContext
*s, const AVStream *st,
while ((probe_codec = av_codec_iterate())) {
if (probe_codec->id == codec->id &&
av_codec_is_decoder(probe_codec) &&
+/* The av1 "decoder" exists purely for hwaccel purposes.
+ * It cannot probe on its own and causes an error if it
tries.
+ * Remove this check if av1dec ever gains software decode
support. */
+strcmp(probe_codec->name, "av1") &&
!(probe_codec->capabilities & (AV_CODEC_CAP_AVOID_PROBING
| AV_CODEC_CAP_EXPERIMENTAL))) {
return probe_codec;
}
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] Convert logfile to AVIOContext to fix file parser
The lack of AVIOContext means that ffmpeg was attempting to open
logfiles for two pass encoding with the "protocol" part of the url on
the first pass. This manifested mainly when a user needed to have a
colon in the filename as they would require a url style path (according
to #8898).
---
fftools/ffmpeg.c | 12 +++-
fftools/ffmpeg.h | 2 +-
fftools/ffmpeg_opt.c | 7 +++
3 files changed, 7 insertions(+), 14 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 84306818a2..d292e346a9 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1313,7 +1313,7 @@ static void do_video_out(OutputFile *of,
/* if two pass, output log */
if (ost->logfile && enc->stats_out) {
-fprintf(ost->logfile, "%s", enc->stats_out);
+avio_write(ost->logfile, enc->stats_out,
strlen(enc->stats_out));
}
}
ost->sync_opts++;
@@ -1937,7 +1937,7 @@ static void flush_encoders(void)
exit_program(1);
}
if (ost->logfile && enc->stats_out) {
-fprintf(ost->logfile, "%s", enc->stats_out);
+avio_write(ost->logfile, enc->stats_out,
strlen(enc->stats_out));
}
if (ret == AVERROR_EOF) {
output_packet(of, , ost, 1);
@@ -4751,13 +4751,7 @@ static int transcode(void)
for (i = 0; i < nb_output_streams; i++) {
ost = output_streams[i];
if (ost) {
-if (ost->logfile) {
-if (fclose(ost->logfile))
-av_log(NULL, AV_LOG_ERROR,
- "Error closing logfile, loss of information
possible: %s\n",
- av_err2str(AVERROR(errno)));
-ost->logfile = NULL;
-}
+avio_closep(>logfile);
av_freep(>forced_kf_pts);
av_freep(>apad);
av_freep(>disposition);
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 8665218dcf..d907d4a6ad 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -500,7 +500,7 @@ typedef struct OutputStream {
int audio_channels_mapped; /* number of channels in
audio_channels_map */
char *logfile_prefix;
-FILE *logfile;
+AVIOContext *logfile;
OutputFilter *filter;
char *avfilter;
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 19f719e3ff..e3e6054b06 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -1813,7 +1813,6 @@ static OutputStream *new_video_stream(OptionsContext *o,
AVFormatContext *oc, in
if (do_pass) {
char logfilename[1024];
-FILE *f;
snprintf(logfilename, sizeof(logfilename), "%s-%d.log",
ost->logfile_prefix ? ost->logfile_prefix :
@@ -1833,14 +1832,14 @@ static OutputStream *new_video_stream(OptionsContext
*o, AVFormatContext *oc, in
video_enc->stats_in = logbuffer;
}
if (video_enc->flags & AV_CODEC_FLAG_PASS1) {
-f = av_fopen_utf8(logfilename, "wb");
-if (!f) {
+int ret = avio_open(>logfile, logfilename,
AVIO_FLAG_WRITE);
+
+if (ret < 0) {
av_log(NULL, AV_LOG_FATAL,
"Cannot write log file '%s' for pass-1
encoding: %s\n",
logfilename, strerror(errno));
exit_program(1);
}
-ost->logfile = f;
}
}
}
--
2.28.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 4/4] avcodec/apedec: use ff_clz() instead of while loop
Quoting Paul B Mahol (2020-10-06 10:19:13)
> On Tue, Oct 06, 2020 at 10:08:58AM +0200, Anton Khirnov wrote:
> > Quoting Paul B Mahol (2020-10-06 02:17:14)
> > > Signed-off-by: Paul B Mahol
> > > ---
> > > libavcodec/apedec.c | 10 +++---
> > > 1 file changed, 3 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c
> > > index 8fe7b5ee86..ea36247eb9 100644
> > > --- a/libavcodec/apedec.c
> > > +++ b/libavcodec/apedec.c
> > > @@ -575,14 +575,10 @@ static inline int ape_decode_value_3990(APEContext
> > > *ctx, APERice *rice)
> > > base = range_decode_culfreq(ctx, pivot);
> > > range_decode_update(ctx, 1, base);
> > > } else {
> > > -int base_hi = pivot, base_lo;
> > > -int bbits = 0;
> > > +int base_hi, base_lo;
> > > +int bbits = 16 - ff_clz(pivot);
> >
> > This assumes unsigned is always 32bit, no?
>
> ksum is 32 bit, from which pivot is derived.
>
> Should I use explicitly uint32_t type instead?
> Where is unsigned not 32bit?
I don't think uint32_t would help, as ff_clz() can expand to a compiler
builtin.
What I'm concerned about is the unstated assumption about
sizeof(int/unsigned) == 4 spreading through the codebase. It's already
present in plenty of places, so I certainly don't intend to block your
patch over this. But we should consider explitly documenting this, and
maybe testing in configure.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/4] avcodec/apedec: properly calculate and store absolute value
Quoting Paul B Mahol (2020-10-06 10:23:13)
> On Tue, Oct 06, 2020 at 09:53:44AM +0200, Anton Khirnov wrote:
> > Quoting Paul B Mahol (2020-10-06 02:17:12)
> > > Signed-off-by: Paul B Mahol
> > > ---
> > > libavcodec/apedec.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c
> > > index 273abe2490..aa4d8fa524 100644
> > > --- a/libavcodec/apedec.c
> > > +++ b/libavcodec/apedec.c
> > > @@ -1311,7 +1311,7 @@ static void do_apply_filter(APEContext *ctx, int
> > > version, APEFilter *f,
> > > int32_t *data, int count, int order, int
> > > fracbits)
> > > {
> > > int res;
> > > -int absres;
> > > +unsigned absres;
> >
> > Does anything other than the type change?
>
> absres value should change in single case when -INT32_MIN is stored again in
> int.
> Reference implementation use int64_t type instead.
ok then
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] ?= [PATCH v4]=?utf-8?q? avformat/libsrt: print streamid at client
Raghavendra Rao Sidlagatta (12020-10-06): > I believe that the end user could retrieve the stream information How? > and this could be handy in debugging as well. AV_LOG_DEBUG then. > On Tuesday, October 06, 2020 08:38 BST, Nicolas George > wrote: Don't top-post. If you don't know what it means, look it up. 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 2/4] avcodec/apedec: properly calculate and store absolute value
On Tue, Oct 06, 2020 at 09:53:44AM +0200, Anton Khirnov wrote:
> Quoting Paul B Mahol (2020-10-06 02:17:12)
> > Signed-off-by: Paul B Mahol
> > ---
> > libavcodec/apedec.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c
> > index 273abe2490..aa4d8fa524 100644
> > --- a/libavcodec/apedec.c
> > +++ b/libavcodec/apedec.c
> > @@ -1311,7 +1311,7 @@ static void do_apply_filter(APEContext *ctx, int
> > version, APEFilter *f,
> > int32_t *data, int count, int order, int
> > fracbits)
> > {
> > int res;
> > -int absres;
> > +unsigned absres;
>
> Does anything other than the type change?
absres value should change in single case when -INT32_MIN is stored again in
int.
Reference implementation use int64_t type instead.
___
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 4/4] avcodec/apedec: use ff_clz() instead of while loop
On Tue, Oct 06, 2020 at 10:08:58AM +0200, Anton Khirnov wrote:
> Quoting Paul B Mahol (2020-10-06 02:17:14)
> > Signed-off-by: Paul B Mahol
> > ---
> > libavcodec/apedec.c | 10 +++---
> > 1 file changed, 3 insertions(+), 7 deletions(-)
> >
> > diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c
> > index 8fe7b5ee86..ea36247eb9 100644
> > --- a/libavcodec/apedec.c
> > +++ b/libavcodec/apedec.c
> > @@ -575,14 +575,10 @@ static inline int ape_decode_value_3990(APEContext
> > *ctx, APERice *rice)
> > base = range_decode_culfreq(ctx, pivot);
> > range_decode_update(ctx, 1, base);
> > } else {
> > -int base_hi = pivot, base_lo;
> > -int bbits = 0;
> > +int base_hi, base_lo;
> > +int bbits = 16 - ff_clz(pivot);
>
> This assumes unsigned is always 32bit, no?
ksum is 32 bit, from which pivot is derived.
Should I use explicitly uint32_t type instead?
Where is unsigned not 32bit?
>
> --
> Anton Khirnov
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
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 4/4] avcodec/apedec: use ff_clz() instead of while loop
Quoting Paul B Mahol (2020-10-06 02:17:14)
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/apedec.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c
> index 8fe7b5ee86..ea36247eb9 100644
> --- a/libavcodec/apedec.c
> +++ b/libavcodec/apedec.c
> @@ -575,14 +575,10 @@ static inline int ape_decode_value_3990(APEContext
> *ctx, APERice *rice)
> base = range_decode_culfreq(ctx, pivot);
> range_decode_update(ctx, 1, base);
> } else {
> -int base_hi = pivot, base_lo;
> -int bbits = 0;
> +int base_hi, base_lo;
> +int bbits = 16 - ff_clz(pivot);
This assumes unsigned is always 32bit, no?
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/4] avcodec/apedec: properly calculate and store absolute value
Quoting Paul B Mahol (2020-10-06 02:17:12)
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/apedec.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c
> index 273abe2490..aa4d8fa524 100644
> --- a/libavcodec/apedec.c
> +++ b/libavcodec/apedec.c
> @@ -1311,7 +1311,7 @@ static void do_apply_filter(APEContext *ctx, int
> version, APEFilter *f,
> int32_t *data, int count, int order, int
> fracbits)
> {
> int res;
> -int absres;
> +unsigned absres;
Does anything other than the type change?
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] ?==?utf-8?q? ?==?utf-8?q? [PATCH v4]?==?utf-8?q? avformat/libsrt: print streamid at client
Hello Nicolas, I believe that the end user could retrieve the stream information and this could be handy in debugging as well. Regards, Raghavendra Rao On Tuesday, October 06, 2020 08:38 BST, Nicolas George wrote: Raghavendra Rao Sidlagatta (12020-10-06): > I believe that the stream id information should be logged to info instead of > verbose as it contains important infor mation about the stream. What can an end-user do with it? Note: your MUA mangled the subject line. Regards, -- Nicolas George ___ 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 v4] avformat/libsrt: print streamid at client
Raghavendra Rao Sidlagatta (12020-10-06): > I believe that the stream id information should be logged to info instead of > verbose as it contains important infor mation about the stream. What can an end-user do with it? Note: your MUA mangled the subject line. Regards, -- Nicolas George ___ 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] ?==?utf-8?q? ?==?utf-8?q? [PATCH v4]?==?utf-8?q? avformat/libsrt: print streamid at client
Hello,
I believe that the stream id information should be logged to info instead of
verbose as it contains important infor mation about the stream.
Regards,
Raghavendra Rao
On Tuesday, October 06, 2020 08:18 BST, raghavendra
wrote:
Print the SRT streamid at the client.
Logged to info.
Signed-off-by: raghavendra
---
libavformat/libsrt.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index 4025b24976..eed48c11cf 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -359,6 +359,13 @@ static int libsrt_set_options_pre(URLContext *h, int fd)
return 0;
}
+static void libsrt_dump_streamid(URLContext *h, int fd)
+{
+ char streamid[512];
+ int optlen = sizeof(streamid);
+ if (!libsrt_getsockopt(h, fd, SRTO_STREAMID, "SRTO_STREAMID", streamid,
))
+ av_log(h, AV_LOG_INFO, "srt_streamid : %s\n", streamid);
+}
static int libsrt_setup(URLContext *h, const char *uri, int flags)
{
@@ -442,6 +449,8 @@ static int libsrt_setup(URLContext *h, const char *uri, int
flags)
goto fail1;
listen_fd = fd;
fd = ret;
+ // dump srt streamid at client
+ libsrt_dump_streamid(h, fd);
} else {
if (s->mode == SRT_MODE_RENDEZVOUS) {
ret = srt_bind(fd, cur_ai->ai_addr, cur_ai->ai_addrlen);
--
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".
[FFmpeg-devel] [PATCH v4] avformat/libsrt: print streamid at client
Print the SRT streamid at the client.
Logged to info.
Signed-off-by: raghavendra
---
libavformat/libsrt.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index 4025b24976..eed48c11cf 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -359,6 +359,13 @@ static int libsrt_set_options_pre(URLContext *h, int fd)
return 0;
}
+static void libsrt_dump_streamid(URLContext *h, int fd)
+{
+char streamid[512];
+int optlen = sizeof(streamid);
+if (!libsrt_getsockopt(h, fd, SRTO_STREAMID, "SRTO_STREAMID", streamid,
))
+av_log(h, AV_LOG_INFO, "srt_streamid : %s\n", streamid);
+}
static int libsrt_setup(URLContext *h, const char *uri, int flags)
{
@@ -442,6 +449,8 @@ static int libsrt_setup(URLContext *h, const char *uri, int
flags)
goto fail1;
listen_fd = fd;
fd = ret;
+// dump srt streamid at client
+libsrt_dump_streamid(h, fd);
} else {
if (s->mode == SRT_MODE_RENDEZVOUS) {
ret = srt_bind(fd, cur_ai->ai_addr, cur_ai->ai_addrlen);
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] doc/general_contents.texi: add uavs3d section
From: hwren
Signed-off-by: hwren
---
doc/general_contents.texi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/doc/general_contents.texi b/doc/general_contents.texi
index 598e0e74da..f441a75ee9 100644
--- a/doc/general_contents.texi
+++ b/doc/general_contents.texi
@@ -119,6 +119,14 @@ libdavs2 is under the GNU Public License Version 2 or later
details), you must upgrade FFmpeg's license to GPL in order to use it.
@end float
+@section uavs3d
+
+FFmpeg can make use of the uavs3d library for AVS3-P2/IEEE1857.10 video
decoding.
+
+Go to @url{https://github.com/uavs3/uavs3d} and follow the instructions for
+installing the library. Then pass @code{--enable-libuavs3d} to configure to
+enable it.
+
@section Game Music Emu
FFmpeg can make use of the Game Music Emu library to read audio from supported
video game
@@ -816,6 +824,8 @@ following image formats are supported:
@tab Video encoding used by the Creature Shock game.
@item AVS2-P2/IEEE1857.4 @tab E @tab E
@tab Supported through external libraries libxavs2 and libdavs2
+@item AVS3-P2/IEEE1857.10@tab @tab E
+@tab Supported through external library libuavs3d
@item AYUV @tab X @tab X
@tab Microsoft uncompressed packed 4:4:4:4
@item Beam Software VB @tab @tab X
--
2.23.0.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".
