[FFmpeg-devel] [PATCH] libavcodec/libx265.c: support for the x265 loglevel configured with ffmpeg loglevel option
From: Limin Wang
---
libavcodec/libx265.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 27c90b3..3a08767 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -108,6 +108,24 @@ static av_cold int libx265_encode_init(AVCodecContext
*avctx)
return AVERROR(EINVAL);
}
+switch (av_log_get_level()) {
+case AV_LOG_ERROR:
+ctx->params->logLevel = X265_LOG_ERROR;
+break;
+case AV_LOG_INFO:
+ctx->params->logLevel = X265_LOG_INFO;
+break;
+case AV_LOG_DEBUG:
+ctx->params->logLevel = X265_LOG_DEBUG;
+break;
+case AV_LOG_WARNING:
+ctx->params->logLevel = X265_LOG_WARNING;
+break;
+case AV_LOG_TRACE:
+ctx->params->logLevel = X265_LOG_FULL;
+break;
+}
+
ctx->params->frameNumThreads = avctx->thread_count;
ctx->params->fpsNum = avctx->time_base.den;
ctx->params->fpsDenom= avctx->time_base.num *
avctx->ticks_per_frame;
--
2.6.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] doc: change OS X to macOS
--- src/download | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/download b/src/download index 0bda5a0..40f4706 100644 --- a/src/download +++ b/src/download @@ -95,7 +95,7 @@ https://evermeet.cx/ffmpeg/";> -Static builds for OS X Intel 64-bit +Static builds for macOS 64-bit https://ffmpeg.zeranoe.com/builds/";> Static and shared builds for macOS 64-bit -- 2.19.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 02/12] avformat/mxfenc: write index delta entry array needed by sony vegas pro 11
On Sun, Oct 14, 2018 at 03:05:38PM -0700, Baptiste Coudurier wrote: > On Sat, Oct 13, 2018 at 7:13 PM Michael Niedermayer > wrote: > > > On Sat, Oct 13, 2018 at 06:24:52PM +0200, Martin Vignali wrote: > > > > > > > > Applied > > > > > > > > > > > Seems like fate-mxf-reel_name doesn't pass after your patchs > > > make fate-mxf-reel_name SAMPLES=fate-suite > > > > this also broke 2 other fate tests: > > make: *** [fate-mxf-reel_name] Error 1 > > make: *** [fate-copy-trac4914] Error 1 > > make: *** [fate-time_base] Error 1 > > > > i would look at it but i just now noticed and i need to go to bed :( > > > > also when testing i needed a "rm tests/data/fate/time_base.out", this seemd > > not to be removed (thats unrelated to the commit i assume, iam just saying > > so noone wastes time debuging a mysterious long standing failure) > > > > Seems like all these tests generate mxf files, which would change after > this patch. > I'm looking and will fix them. ive already pushed a patch to update the tests earlier today [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] ffmpeg: log corrupted packets and frames
On Thu, 11 Oct 2018, Michael Niedermayer wrote: On Wed, Oct 10, 2018 at 01:32:13AM +0200, Marton Balint wrote: Signed-off-by: Marton Balint --- fftools/ffmpeg.c | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-) maybe this should also print some time information so the user knows from the printout when issues occured but LGTM otherwise Thanks pushed. Will send a separate patch with some additional time information. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 02/12] avformat/mxfenc: write index delta entry array needed by sony vegas pro 11
On Sat, Oct 13, 2018 at 7:13 PM Michael Niedermayer wrote: > On Sat, Oct 13, 2018 at 06:24:52PM +0200, Martin Vignali wrote: > > > > > > Applied > > > > > > > > Seems like fate-mxf-reel_name doesn't pass after your patchs > > make fate-mxf-reel_name SAMPLES=fate-suite > > this also broke 2 other fate tests: > make: *** [fate-mxf-reel_name] Error 1 > make: *** [fate-copy-trac4914] Error 1 > make: *** [fate-time_base] Error 1 > > i would look at it but i just now noticed and i need to go to bed :( > > also when testing i needed a "rm tests/data/fate/time_base.out", this seemd > not to be removed (thats unrelated to the commit i assume, iam just saying > so noone wastes time debuging a mysterious long standing failure) > Seems like all these tests generate mxf files, which would change after this patch. I'm looking and will fix them. -- Baptiste Coudurier ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/sinewin: Do not declare tables as const
2018-10-14 22:30 GMT+02:00, Hendrik Leppkes : > On Sun, Oct 14, 2018 at 10:18 PM Carl Eugen Hoyos > wrote: >> >> Attached patch is supposed to fix ticket #7491, I currently >> don't have gcc 8 to test myself. > > Only the 120 and 960 tables are affected by this bug because > they are not being created by the hardcoded tables logic, yet > this patch changes the const attribute for all tables, defeating > one purpose of the hardcoded tables. > Can we adjust this to only affect the two tables that need it Did that in attached patch, please comment. > or remove hardcoded tables for sinewin entirely, instead of leaving > them half-baked, or add 120 and 960 to hardcoded tables generation? Carl Eugen From 55fc231778360c921827915e6aa8a2b1a592dfdd Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Sun, 14 Oct 2018 23:48:23 +0200 Subject: [PATCH] lavc/sinewin: Do not declare AAC 120/960 tables as const. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ff_sine_window_init() is writing to these tables causing a crash if compiled with gcc 8 and lto. Analyzed by Martin Liška in: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85132 Fixes ticket #7491. --- libavcodec/sinewin.h |7 +-- libavcodec/sinewin_tablegen.h |4 ++-- libavcodec/sinewin_tablegen_template.c |2 ++ 3 files changed, 9 insertions(+), 4 deletions(-) diff --git a/libavcodec/sinewin.h b/libavcodec/sinewin.h index 6b97a71..329e9bb 100644 --- a/libavcodec/sinewin.h +++ b/libavcodec/sinewin.h @@ -38,6 +38,9 @@ #define SINETABLE(size) \ SINETABLE_CONST DECLARE_ALIGNED(32, INTFLOAT, AAC_RENAME(ff_sine_##size))[size] +#define SINETABLE120960(size) \ +DECLARE_ALIGNED(32, INTFLOAT, AAC_RENAME(ff_sine_##size))[size] + /** * Generate a sine window. * @param window pointer to half window @@ -52,11 +55,11 @@ void AAC_RENAME(ff_init_ff_sine_windows)(int index); extern SINETABLE( 32); extern SINETABLE( 64); -extern SINETABLE( 120); +extern SINETABLE120960(120); extern SINETABLE( 128); extern SINETABLE( 256); extern SINETABLE( 512); -extern SINETABLE( 960); +extern SINETABLE120960(960); extern SINETABLE(1024); extern SINETABLE(2048); extern SINETABLE(4096); diff --git a/libavcodec/sinewin_tablegen.h b/libavcodec/sinewin_tablegen.h index 0fa3561..dc52234 100644 --- a/libavcodec/sinewin_tablegen.h +++ b/libavcodec/sinewin_tablegen.h @@ -32,8 +32,8 @@ #include "libavutil/common.h" #if !USE_FIXED -SINETABLE( 120); -SINETABLE( 960); +SINETABLE120960(120); +SINETABLE120960(960); #endif #if !CONFIG_HARDCODED_TABLES SINETABLE( 32); diff --git a/libavcodec/sinewin_tablegen_template.c b/libavcodec/sinewin_tablegen_template.c index 43ce1ba..b8eb407 100644 --- a/libavcodec/sinewin_tablegen_template.c +++ b/libavcodec/sinewin_tablegen_template.c @@ -33,6 +33,8 @@ #define SINETABLE_CONST #define SINETABLE(size) \ INTFLOAT AAC_RENAME(ff_sine_##size)[size] +#define SINETABLE120960(size) \ +INTFLOAT AAC_RENAME(ff_sine_##size)[size] #define FF_ARRAY_ELEMS(a) (sizeof(a) / sizeof((a)[0])) #include "sinewin_tablegen.h" #include "tableprint.h" -- 1.7.10.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] MAINTAINERS: remove myself as hls demuxer maintainer
--- Unfortunately I haven't really had the time lately to maintain the HLS demuxer properly and I don't see that changing in the near future. So I intend to apply this removal tomorrow. If anyone is interested in taking over, please do :) I'll continue to maintain the lower-traffic spdif (de)muxers. - Anssi Hannula MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 3dd26e374f..bc2ae13320 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -413,7 +413,6 @@ Muxers/Demuxers: flvenc.c Michael Niedermayer, Steven Liu gxf.c Reimar Doeffinger gxfenc.c Baptiste Coudurier - hls.c Anssi Hannula hlsenc.c Christian Suloway, Steven Liu idcin.c Mike Melanson idroqdec.cMike Melanson -- 2.14.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/sinewin: Do not declare tables as const
On Sun, Oct 14, 2018 at 10:18 PM Carl Eugen Hoyos wrote: > > Hi! > > Attached patch is supposed to fix ticket #7491, I currently don't have > gcc 8 to test myself. > Only the 120 and 960 tables are affected by this bug because they are not being created by the hardcoded tables logic, yet this patch changes the const attribute for all tables, defeating one purpose of the hardcoded tables. Can we adjust this to only affect the two tables that need it, or remove hardcoded tables for sinewin entirely, instead of leaving them half-baked, or add 120 and 960 to hardcoded tables generation? - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavc/sinewin: Do not declare tables as const
Hi!
Attached patch is supposed to fix ticket #7491, I currently don't have
gcc 8 to test myself.
Please comment, Carl Eugen
From 90ac3c2b931d060e918a66047ff76c7d45f2274a Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Sun, 14 Oct 2018 22:13:34 +0200
Subject: [PATCH] lavc/sinewin: Do not declare the tables as const.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
At least ff_sine_window_init() is writing to some of the tables causing
a crash if compiled with gcc 8 and lto.
Analyzed by Martin Liška in:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85132
Fixes ticket #7491.
---
libavcodec/sinewin.h | 10 ++
libavcodec/sinewin_tablegen.h |2 +-
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/libavcodec/sinewin.h b/libavcodec/sinewin.h
index 6b97a71..146d4e5 100644
--- a/libavcodec/sinewin.h
+++ b/libavcodec/sinewin.h
@@ -25,18 +25,12 @@
#include "libavutil/mem.h"
#include "libavcodec/aac_defines.h"
-#if CONFIG_HARDCODED_TABLES
-# define SINETABLE_CONST const
-#else
-# define SINETABLE_CONST
-#endif
-
#ifndef USE_FIXED
#define USE_FIXED 0
#endif
#define SINETABLE(size) \
-SINETABLE_CONST DECLARE_ALIGNED(32, INTFLOAT, AAC_RENAME(ff_sine_##size))[size]
+DECLARE_ALIGNED(32, INTFLOAT, AAC_RENAME(ff_sine_##size))[size]
/**
* Generate a sine window.
@@ -62,6 +56,6 @@ extern SINETABLE(2048);
extern SINETABLE(4096);
extern SINETABLE(8192);
-extern SINETABLE_CONST INTFLOAT * const AAC_RENAME(ff_sine_windows)[16];
+extern INTFLOAT * const AAC_RENAME(ff_sine_windows)[16];
#endif /* AVCODEC_SINEWIN_H */
diff --git a/libavcodec/sinewin_tablegen.h b/libavcodec/sinewin_tablegen.h
index 0fa3561..e1f7c4f 100644
--- a/libavcodec/sinewin_tablegen.h
+++ b/libavcodec/sinewin_tablegen.h
@@ -59,7 +59,7 @@ SINETABLE(8192);
#define SIN_FIX(a) a
#endif
-SINETABLE_CONST INTFLOAT * const AAC_RENAME(ff_sine_windows)[] = {
+INTFLOAT * const AAC_RENAME(ff_sine_windows)[] = {
NULL, NULL, NULL, NULL, NULL, // unused
AAC_RENAME(ff_sine_32) , AAC_RENAME(ff_sine_64), AAC_RENAME(ff_sine_128),
AAC_RENAME(ff_sine_256), AAC_RENAME(ff_sine_512), AAC_RENAME(ff_sine_1024),
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/av1_parse: Check obu_size
On 10/14/2018 2:56 PM, Michael Niedermayer wrote: > Fixes: out of array read > Fixes: SIGSEGV_get_obu_bit_length_av1_parse > > Found-by: keval shah > Signed-off-by: Michael Niedermayer > --- > libavcodec/av1_parse.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/libavcodec/av1_parse.h b/libavcodec/av1_parse.h > index 276af33ba9..864308f81d 100644 > --- a/libavcodec/av1_parse.h > +++ b/libavcodec/av1_parse.h > @@ -134,8 +134,8 @@ static inline int parse_obu_header(const uint8_t *buf, > int buf_size, > > size = *obu_size + *start_pos; > > -if (size > INT_MAX) > -return AVERROR(ERANGE); > +if (size > buf_size) > +return AVERROR_INVALIDDATA; > > return size; > } LGTM, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/av1_parse: Check obu_size
Fixes: out of array read Fixes: SIGSEGV_get_obu_bit_length_av1_parse Found-by: keval shah Signed-off-by: Michael Niedermayer --- libavcodec/av1_parse.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/av1_parse.h b/libavcodec/av1_parse.h index 276af33ba9..864308f81d 100644 --- a/libavcodec/av1_parse.h +++ b/libavcodec/av1_parse.h @@ -134,8 +134,8 @@ static inline int parse_obu_header(const uint8_t *buf, int buf_size, size = *obu_size + *start_pos; -if (size > INT_MAX) -return AVERROR(ERANGE); +if (size > buf_size) +return AVERROR_INVALIDDATA; return size; } -- 2.19.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] swscale : add YA16 LE/BE output
Hello, Patch in attach add YA16 le/be output for swscale (only available as input before this patch) Martin 0001-swscale-add-YA16-LE-BE-output.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/av1_parse: Check obu_size
On 10/14/2018 12:18 PM, Michael Niedermayer wrote: > On Sun, Oct 14, 2018 at 11:03:29AM -0300, James Almer wrote: >> On 10/14/2018 10:43 AM, Michael Niedermayer wrote: >>> Fixes: out of array read >>> Fixes: SIGSEGV_get_obu_bit_length_av1_parse >>> >>> Found-by: keval shah >>> Signed-off-by: Michael Niedermayer >>> --- >>> libavcodec/av1_parse.h | 3 +++ >>> 1 file changed, 3 insertions(+) >>> >>> diff --git a/libavcodec/av1_parse.h b/libavcodec/av1_parse.h >>> index 276af33ba9..312d8825e1 100644 >>> --- a/libavcodec/av1_parse.h >>> +++ b/libavcodec/av1_parse.h >>> @@ -130,6 +130,9 @@ static inline int parse_obu_header(const uint8_t *buf, >>> int buf_size, >>> if (get_bits_left(&gb) < 0) >>> return AVERROR_INVALIDDATA; >>> >>> +if (*obu_size > (uint64_t)buf_size - get_bits_count(&gb) / 8) >>> +return AVERROR_INVALIDDATA; >>> + >>> *start_pos = get_bits_count(&gb) / 8; >>> >>> size = *obu_size + *start_pos; >> >> Right below this line there's the check >> >> if (size > INT_MAX) >> return AVERROR(ERANGE); >> >> So i think you could just change it to "size > (int64_t)buf_size" and >> achieve the same effect without adding an extra check. > > ive written it a bit overly defensive, not assuming any range limitation > of leb128(). > But you are correct, ill simplify and repost it Make it return AVERROR_INVALIDDATA instead of ERANGE as well while at it. Thanks. > > thx > > > [...] > > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/av1_parse: Check obu_size
On Sun, Oct 14, 2018 at 11:03:29AM -0300, James Almer wrote: > On 10/14/2018 10:43 AM, Michael Niedermayer wrote: > > Fixes: out of array read > > Fixes: SIGSEGV_get_obu_bit_length_av1_parse > > > > Found-by: keval shah > > Signed-off-by: Michael Niedermayer > > --- > > libavcodec/av1_parse.h | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/libavcodec/av1_parse.h b/libavcodec/av1_parse.h > > index 276af33ba9..312d8825e1 100644 > > --- a/libavcodec/av1_parse.h > > +++ b/libavcodec/av1_parse.h > > @@ -130,6 +130,9 @@ static inline int parse_obu_header(const uint8_t *buf, > > int buf_size, > > if (get_bits_left(&gb) < 0) > > return AVERROR_INVALIDDATA; > > > > +if (*obu_size > (uint64_t)buf_size - get_bits_count(&gb) / 8) > > +return AVERROR_INVALIDDATA; > > + > > *start_pos = get_bits_count(&gb) / 8; > > > > size = *obu_size + *start_pos; > > Right below this line there's the check > > if (size > INT_MAX) > return AVERROR(ERANGE); > > So i think you could just change it to "size > (int64_t)buf_size" and > achieve the same effect without adding an extra check. ive written it a bit overly defensive, not assuming any range limitation of leb128(). But you are correct, ill simplify and repost it thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "Nothing to hide" only works if the folks in power share the values of you and everyone you know entirely and always will -- Tom Scott signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/av1_parse: Check obu_size
On 10/14/2018 10:43 AM, Michael Niedermayer wrote: > Fixes: out of array read > Fixes: SIGSEGV_get_obu_bit_length_av1_parse > > Found-by: keval shah > Signed-off-by: Michael Niedermayer > --- > libavcodec/av1_parse.h | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/libavcodec/av1_parse.h b/libavcodec/av1_parse.h > index 276af33ba9..312d8825e1 100644 > --- a/libavcodec/av1_parse.h > +++ b/libavcodec/av1_parse.h > @@ -130,6 +130,9 @@ static inline int parse_obu_header(const uint8_t *buf, > int buf_size, > if (get_bits_left(&gb) < 0) > return AVERROR_INVALIDDATA; > > +if (*obu_size > (uint64_t)buf_size - get_bits_count(&gb) / 8) > +return AVERROR_INVALIDDATA; > + > *start_pos = get_bits_count(&gb) / 8; > > size = *obu_size + *start_pos; Right below this line there's the check if (size > INT_MAX) return AVERROR(ERANGE); So i think you could just change it to "size > (int64_t)buf_size" and achieve the same effect without adding an extra check. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/av1_parse: Check obu_size
Fixes: out of array read Fixes: SIGSEGV_get_obu_bit_length_av1_parse Found-by: keval shah Signed-off-by: Michael Niedermayer --- libavcodec/av1_parse.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavcodec/av1_parse.h b/libavcodec/av1_parse.h index 276af33ba9..312d8825e1 100644 --- a/libavcodec/av1_parse.h +++ b/libavcodec/av1_parse.h @@ -130,6 +130,9 @@ static inline int parse_obu_header(const uint8_t *buf, int buf_size, if (get_bits_left(&gb) < 0) return AVERROR_INVALIDDATA; +if (*obu_size > (uint64_t)buf_size - get_bits_count(&gb) / 8) +return AVERROR_INVALIDDATA; + *start_pos = get_bits_count(&gb) / 8; size = *obu_size + *start_pos; -- 2.19.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On 10/14/2018 9:59 AM, Michael Niedermayer wrote: > On Sun, Oct 14, 2018 at 01:29:53PM +0300, Jan Ekström wrote: >> On Sun, Oct 14, 2018 at 1:27 PM Jan Ekström wrote: >>> >>> On Sun, Oct 14, 2018 at 3:17 AM Michael Niedermayer >>> wrote: On Fri, Oct 12, 2018 at 01:13:45AM +0100, Derek Buitenhuis wrote: > On 11/10/2018 23:39, Alex Sukhanov wrote: >> The only "spec" I'm aware of:https://wiki.multimedia.cx/index.php/IVF > > Yeah, not really a spec. > > I have no strong objections, I guess. so IIUC noone is against this ? if so i will apply the last patch in a few days unless i forget or someone else does before thx >>> >>> As mentioned, since this is nothing should have ever been used outside >>> of one of GOOG's legacy systems, I would only apply this with a >>> warning and strictness requirement of experimental or whatever level >>> matches these sorts of cases. >>> >> >> For the record, this was regarding the muxer so that unknowing people >> will not generate such files that nothing else can read. > > If you choose a random container and store a random codec in it (which you > can do) > chances are theres not much that will play it. > > for example i just tried muxing a stream of png images into mpeg and FFmpeg > does that without complaining. > ./ffmpeg -i matrixbench_mpeg2.mpg -vcodec png test.mpeg > > So if we do not check this for a major format that has a proper specification > which i belive nowhere allows png > > Why should we add a limitation on a format that has nothing saying that you > cannot put some other codec into it ? The proper thing to do would be to effectively disallow such invalid muxing scenarios, fixing this instead of adding even more wrong cases to the pile. I'm fairly sure we blocked a patch to allow muxing hevc into flv years ago. That's what needs to be done in general. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On Sun, Oct 14, 2018 at 01:29:53PM +0300, Jan Ekström wrote: > On Sun, Oct 14, 2018 at 1:27 PM Jan Ekström wrote: > > > > On Sun, Oct 14, 2018 at 3:17 AM Michael Niedermayer > > wrote: > > > > > > On Fri, Oct 12, 2018 at 01:13:45AM +0100, Derek Buitenhuis wrote: > > > > On 11/10/2018 23:39, Alex Sukhanov wrote: > > > > > The only "spec" I'm aware of:https://wiki.multimedia.cx/index.php/IVF > > > > > > > > Yeah, not really a spec. > > > > > > > > I have no strong objections, I guess. > > > > > > so IIUC noone is against this ? > > > if so i will apply the last patch in a few days unless i forget or > > > someone else does before > > > > > > thx > > > > > > > As mentioned, since this is nothing should have ever been used outside > > of one of GOOG's legacy systems, I would only apply this with a > > warning and strictness requirement of experimental or whatever level > > matches these sorts of cases. > > > > For the record, this was regarding the muxer so that unknowing people > will not generate such files that nothing else can read. If you choose a random container and store a random codec in it (which you can do) chances are theres not much that will play it. for example i just tried muxing a stream of png images into mpeg and FFmpeg does that without complaining. ./ffmpeg -i matrixbench_mpeg2.mpg -vcodec png test.mpeg So if we do not check this for a major format that has a proper specification which i belive nowhere allows png Why should we add a limitation on a format that has nothing saying that you cannot put some other codec into it ? And i mean there IS software that uses that what is asked for here. If you object because the text at https://wiki.multimedia.cx/index.php/IVF does not list all codecs. Well its a wiki, the author of the patch could get an account and update this. In fact independant of this discussion here it surely wont hurt if the people using the format review and update that page. The other concern IIUC (please correct me if i misunderstood) is that its a legacy format. FFmpeg is full of legacy format support, we suport some really bizare formats ... And another concern IIUC ( again please correct me if i misunderstood) is that someone might unintentionally generate a unsupported file this is tricky, the default video codec for ivf is AV_CODEC_ID_VP8 to get something else, one would need to manually override this and as we already saw thats not something we current protect against very well. Iam not against disallowing the new codecs by default but it feels inconsistent compared to other containers. what do you say ? did i convince you or should we disallow it and add a check. Iam happy with whatever people agree on thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Modern terrorism, a quick summary: Need oil, start war with country that has oil, kill hundread thousand in war. Let country fall into chaos, be surprised about raise of fundamantalists. Drop more bombs, kill more people, be surprised about them taking revenge and drop even more bombs and strip your own citizens of their rights and freedoms. to be continued signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On Sun, Oct 14, 2018 at 3:17 AM Michael Niedermayer wrote: > > On Fri, Oct 12, 2018 at 01:13:45AM +0100, Derek Buitenhuis wrote: > > On 11/10/2018 23:39, Alex Sukhanov wrote: > > > The only "spec" I'm aware of:https://wiki.multimedia.cx/index.php/IVF > > > > Yeah, not really a spec. > > > > I have no strong objections, I guess. > > so IIUC noone is against this ? > if so i will apply the last patch in a few days unless i forget or > someone else does before > > thx > As mentioned, since this is nothing should have ever been used outside of one of GOOG's legacy systems, I would only apply this with a warning and strictness requirement of experimental or whatever level matches these sorts of cases. Nothing in public that utilizes IVF files will output or read AVC/HEVC from IVF files. It was explicitly only utilized by the webm/libvpx project publicly, and that for obvious reasons will not support AVC/HEVC. Best regards, Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On Sun, Oct 14, 2018 at 1:27 PM Jan Ekström wrote: > > On Sun, Oct 14, 2018 at 3:17 AM Michael Niedermayer > wrote: > > > > On Fri, Oct 12, 2018 at 01:13:45AM +0100, Derek Buitenhuis wrote: > > > On 11/10/2018 23:39, Alex Sukhanov wrote: > > > > The only "spec" I'm aware of:https://wiki.multimedia.cx/index.php/IVF > > > > > > Yeah, not really a spec. > > > > > > I have no strong objections, I guess. > > > > so IIUC noone is against this ? > > if so i will apply the last patch in a few days unless i forget or > > someone else does before > > > > thx > > > > As mentioned, since this is nothing should have ever been used outside > of one of GOOG's legacy systems, I would only apply this with a > warning and strictness requirement of experimental or whatever level > matches these sorts of cases. > For the record, this was regarding the muxer so that unknowing people will not generate such files that nothing else can read. Best regards, Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
