Re: [FFmpeg-devel] [PATCH 4/4] lavc/vulkan: add SPIR-V compilation support
On 4 Oct 2024, at 11:31, Lynne via ffmpeg-devel wrote: > This is the same as with libavfilter. > > We will need SPIR-V compilation for at least three different things, > like the VC-2 encoder and decoder, AV1 film grain synthesis for > hardware with no support for it, and possibly other codecs. > --- > libavcodec/Makefile | 4 > libavcodec/vulkan_glslang.c | 19 +++ > libavcodec/vulkan_shaderc.c | 19 +++ > 3 files changed, 42 insertions(+) > create mode 100644 libavcodec/vulkan_glslang.c > create mode 100644 libavcodec/vulkan_shaderc.c > > diff --git a/libavcodec/Makefile b/libavcodec/Makefile > index a253a9b160..7147ed0360 100644 > --- a/libavcodec/Makefile > +++ b/libavcodec/Makefile > @@ -1257,6 +1257,10 @@ OBJS-$(HAVE_THREADS) += pthread.o > pthread_slice.o pthread_fram > > OBJS-$(CONFIG_FRAME_THREAD_ENCODER)+= frame_thread_encoder.o > > +# vulkan libs > +OBJS-$(CONFIG_LIBGLSLANG) += vulkan_glslang.o > +OBJS-$(CONFIG_LIBSHADERC) += vulkan_shaderc.o > + > # Windows resource file > SHLIBOBJS-$(HAVE_GNU_WINDRES) += avcodecres.o > > diff --git a/libavcodec/vulkan_glslang.c b/libavcodec/vulkan_glslang.c > new file mode 100644 > index 00..9aa41567a3 > --- /dev/null > +++ b/libavcodec/vulkan_glslang.c > @@ -0,0 +1,19 @@ > +/* > + * This file is part of FFmpeg. > + * > + * FFmpeg is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * FFmpeg is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with FFmpeg; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 > USA > + */ > + > +#include "libavutil/vulkan_glslang.c" > diff --git a/libavcodec/vulkan_shaderc.c b/libavcodec/vulkan_shaderc.c > new file mode 100644 > index 00..9f60bf4dfd > --- /dev/null > +++ b/libavcodec/vulkan_shaderc.c > @@ -0,0 +1,19 @@ > +/* > + * This file is part of FFmpeg. > + * > + * FFmpeg is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * FFmpeg is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with FFmpeg; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 > USA > + */ > + > +#include "libavutil/vulkan_shaderc.c" Wouldn’t this cause duplicate symbol issues with for example ff_vk_shaderc_init being in both libavfilter and libavcodec? > -- > 2.45.2.753.g447d99e1c3b > ___ > 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/7] lavfi/avfilter: document AVFilterContext.is_disabled as private
On 3 Oct 2024, at 21:31, Anton Khirnov wrote:
> Ideally there should be three parts to the filter context - public,
> private to the filter, and private to generic code, but only the first
> and the last of these exist currently. Until the second is implemented,
> this is better than nothing.
> ---
> libavfilter/avfilter.h | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
> index a255d71700..d13a2df732 100644
> --- a/libavfilter/avfilter.h
> +++ b/libavfilter/avfilter.h
> @@ -512,7 +512,12 @@ struct AVFilterContext {
> ///< @deprecated unused
> double *var_values;
> #endif
> -int is_disabled;///< the enabled state from the last
> expression evaluation
> +/**
> + * MUST NOT be accessed from outside avfilter.
> + *
> + * the enabled state from the last expression evaluation
> + */
The first part should be the brief description for which
„MUST NOT be accessed from outside avfilter.“ is not quite helpful.
You probably want this to be „Enabled state from the last expression evaluation“
and add a @warning for the „MUST NOT be accessed from outside avfilter.“
Also what do you mean by that? The libavfilter internals? Or is it fine to
access it
in a filter, for example? Thats not clear at all from this, at least to me.
> +int is_disabled;
>
> /**
> * For filters which will create hardware frames, sets the device the
> --
> 2.43.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/3] avcodec: make a local copy of executor
On 1 Oct 2024, at 9:51, Lynne via ffmpeg-devel wrote: > On 01/10/2024 08:55, Nuo Mi wrote: >> We still need several refactors to improve the current VVC decoder's >> performance, >> which will frequently break the API/ABI. To mitigate this, we've copied the >> executor from >> avutil to avcodec. Once the API/ABI is stable, we will move this class back >> to avutil >> --- >> libavcodec/Makefile | 1 + >> libavcodec/executor.c | 221 >> libavcodec/executor.h | 73 + >> libavcodec/vvc/thread.c | 2 +- >> 4 files changed, 296 insertions(+), 1 deletion(-) >> create mode 100644 libavcodec/executor.c >> create mode 100644 libavcodec/executor.h >> >> diff --git a/libavcodec/Makefile b/libavcodec/Makefile >> index a4fcce3b42..da1a1aa945 100644 >> --- a/libavcodec/Makefile >> +++ b/libavcodec/Makefile >> @@ -43,6 +43,7 @@ OBJS = ac3_parser.o >> \ >> dirac.o \ >> dv_profile.o \ >> encode.o \ >> + executor.o \ >> get_buffer.o \ >> imgconvert.o \ >> jni.o\ > > You're adding a single field to a structure. This wouldn't break API or ABI. > I don't think this is needed. See patch 2/3 which removes int (*ready)(const AVTask *t, void *user_data); in AVTaskCallbacks. > ___ > 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 01/10] fftools/ffmpeg_filter: stop using avfilter_graph_alloc_filter() incorrectly
On 28 Sep 2024, at 0:27, James Almer wrote: > On 9/25/2024 10:29 AM, Anton Khirnov wrote: >> This function creates AND initializes a filter, so setting any filter >> options after it is wrong. It happens to work when the filter's init >> function does not touch the options in question, but is forbidden by the >> API and is not guaranteed to remain functional. >> >> Instead, use avfilter_graph_alloc_filter(), followed by setting the >> options, and avfilter_init_dict(). > > Shouldn't the subject be "stop using avfilter_graph_create_filter() > incorrectly"? > See https://ffmpeg.org//pipermail/ffmpeg-devel/2024-September/334032.html > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/2] doc/developer: add examples to clarify code style
On 14 Sep 2024, at 0:12, martin schitter wrote: > These a very helpful instructive examples. > > Nevertheless, I would highly prefer a preconfigured `make fmt` command, which > works similar to `cargo fmt` or `deno fmt` and corrects and checks formating > issues without any human intervention. That's IMHO more productive than > constantly work against the default behavior of ones beloved code editor or > educative/social pressure to adapt to a project specific kind of cosmetic > code modification. > I agree it would be nice to have an easy way, like clang-format or so, but I doubt it will happen any time soon as its not trivial to do I think… > martin > > On 18.05.24 19:00, Marvin Scholz wrote: >> Given the frequency that new developers, myself included, get the >> code style wrong, it is useful to add some examples to clarify how >> things should be done. > > ___ > 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] ffbuild: add METALCC and METALLIB to BRIEF
On 12 Jul 2024, at 20:38, Marvin Scholz wrote: > --- > ffbuild/common.mak | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > If no one has objections in the meantime, I will merge it next week. > diff --git a/ffbuild/common.mak b/ffbuild/common.mak > index 87a3ffd2b0..023adb8567 100644 > --- a/ffbuild/common.mak > +++ b/ffbuild/common.mak > @@ -18,7 +18,7 @@ BIN2C = $(BIN2CEXE) > ifndef V > Q = @ > ECHO = printf "$(1)\t%s\n" $(2) > -BRIEF = CC CXX OBJCC HOSTCC HOSTLD AS X86ASM AR LD STRIP CP WINDRES NVCC > BIN2C > +BRIEF = CC CXX OBJCC HOSTCC HOSTLD AS X86ASM AR LD STRIP CP WINDRES NVCC > BIN2C METALCC METALLIB > SILENT = DEPCC DEPHOSTCC DEPAS DEPX86ASM RANLIB RM > > MSG= $@ > > base-commit: 85706f5136cf7c88f95843b2634dd3f7d7d2cb6d > -- > 2.39.3 (Apple Git-146) ___ 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] doc/developer: add examples to clarify code style
On 18 May 2024, at 20:22, Andrew Sayers wrote:
> I would have found this very helpful!
Thanks for the review, I just submitted a new version that hopefully
addresses most of your points.
>
> On Sat, May 18, 2024 at 07:00:50PM +0200, Marvin Scholz wrote:
>> Given the frequency that new developers, myself included, get the
>> code style wrong, it is useful to add some examples to clarify how
>> things should be done.
>> ---
>> doc/developer.texi | 57 +-
>> 1 file changed, 56 insertions(+), 1 deletion(-)
>>
>> diff --git a/doc/developer.texi b/doc/developer.texi
>> index 63835dfa06..d7bf3f9cb8 100644
>> --- a/doc/developer.texi
>> +++ b/doc/developer.texi
>> @@ -115,7 +115,7 @@ Objective-C where required for interacting with
>> macOS-specific interfaces.
>>
>> @section Code formatting conventions
>>
>> -There are the following guidelines regarding the indentation in files:
>> +There are the following guidelines regarding the code style in files:
>>
>> @itemize @bullet
>> @item
>> @@ -135,6 +135,61 @@ K&R coding style is used.
>> @end itemize
>> The presentation is one inspired by 'indent -i4 -kr -nut'.
>>
>> +@subsection Examples
>> +Some notable examples to illustrate common code style in FFmpeg:
>> +
>> +@itemize @bullet
>> +
>> +@item
>> +Spaces around @code{if}/@code{do}/@code{while}/@code{for} conditions and
>> assigments:
>
> s/assigments/assignments/
>
> Also, this might be more readable as "Space around assignments and after
> @code{if}... keywords"? On first pass, I assumed this was telling me
> `( condition )` is correct, then had to re-read when the example showed
> it wasn't.
>
>> +
>> +@example c
>> +if (condition)
>
> `condition` here differs from `cond` below, despite conveying the same
> meaning.
> Either word is fine so long as it's the same word in both places.
>
>> +av_foo();
>> +@end example
>> +
>> +@example c
>> +for (size_t i = 0; i < len; i++)
>
> This lightly implies we prefer `i < len` over `i != len` and `i++` over `++i`.
> Is that something people round here have strong opinions about? Maybe iterate
> over a linked list if this is a controversial question?
>
>> +av_bar(i);
>> +@end example
>> +
>> +@example c
>> +size_t size = 0;
>> +@end example
>> +
>> +However no spaces between the parentheses and condition, unless it helps
>> +readability of complex conditions, so the following should not be done:
>> +
>> +@example c
>> +// Wrong:
>
> Nitpick: if you're going to say "// Wrong" here, it might be better to
> introduce
> the mechanism with some "// Good"s or something above. The consistency
> reduces
> cognitive load on the learner, and it's a good excuse to add a little
> positivity
> to a nerve-wracking experience.
>
>> +if ( cond )
>> +av_foo();
>> +@end example
>> +
>> +@item
>> +No unnecessary parentheses, unless it helps readability:
>> +
>> +@example c
>> +flags = s->mb_x ? RIGHT_EDGE : LEFT_EDGE | RIGHT_EDGE;
>> +@end example
>
> Can the example use "+" or "*" instead of "|"? I've had so many bugs where
> I got the precedence wrong, I'm not sure whether this is supposed to be a good
> or bad example of readability.
>
>> +
>> +@item
>> +No braces around single-line blocks:
>> +
>> +@example c
>> +if (bits_pixel == 24)
>> +avctx->pix_fmt = AV_PIX_FMT_BGR24;
>> +else if (bits_pixel == 8)
>> +avctx->pix_fmt = AV_PIX_FMT_GRAY8;
>> +else @{
>> +av_log(avctx, AV_LOG_ERROR, "Invalid pixel format.\n");
>> +return AVERROR_INVALIDDATA;
>> +@}
>> +@end example
>> +
>> +@end itemize
>> +
>> +
>> @subsection Vim configuration
>> In order to configure Vim to follow FFmpeg formatting conventions, paste
>> the following snippet into your @file{.vimrc}:
>
> Some other things that could help (in decreasing order of importance)...
>
> * if you find a piece of code that looks wrong, should you...
> a) ignore the guide and match your style to the surroundings?
> b) follow the guide and accept the file will look inconsistent?
> c) add an extra patch to fix the formatting?
>
> (I suspect the answer is (b), but could well be wrong)
>
> * example of brace style for both functions and structs
> (as a newbie you don't know if you're about to meet one of those people
> who get all bent out of shape when they see a bracket on a line on its own
> )
>
> * prefer `foo=bar; if (foo)` over `if ((foo=bar))`
> (the latter is sadly used in the code, but is a speedbump for reviewers)
>
> * `foo *bar`, not `foo* bar`
> (I always forget this, not important if it's just me)
>
> Also, way outside the scope of this patch, but a linter that checks these
> things
> would be very much appreciated. There's a lot to get wrong with your first
> patch,
> and a program that just said "yep that's formatted correctly" might save a
> newbie
> enough time to learn git-send-email instead.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/m
Re: [FFmpeg-devel] [PATCH v3 2/2] configure: correctly set sanitizer toolchain compilers
On 13 Sep 2024, at 19:43, Martin Storsjö wrote: > On Thu, 12 Sep 2024, Marvin Scholz wrote: > >> Previously only the C compiler was set, which would lead to >> confusing situations where even though clang-asan was selected, >> it would still use g++ for C++ code, failing because configure >> does not support mixing compilers in this way (which is a separate >> issue not addressed by this commit). >> --- >> configure | 70 --- >> 1 file changed, 41 insertions(+), 29 deletions(-) > > Both these patches seem ok to me. Thanks for the review. I intend to merge these on Monday if there are no further comments till then. > > // Martin > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ 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] configure: fix symbol prefix detection
On 12 Sep 2024, at 8:03, Martin Storsjö wrote:
> On Wed, 11 Sep 2024, Marvin Scholz wrote:
>
>> The symbol prefix check would incorrectly detect a bogus prefix in
>> circumstances where sanitizers
>> instrument the build, like when configuring with the clang-asan toolchain
>> where it would detect the
>> prefix as __odr_asan_gen_, which is obviously wrong.
>>
>> To fix this, adjust the prefix detection to only detect a one-character
>> prefix, which is the only case
>> that matters anywhere right now.
>> ---
>> configure | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/configure b/configure
>> index d3bd46f382a..7e84272b74b 100755
>> --- a/configure
>> +++ b/configure
>> @@ -6131,13 +6131,15 @@ enable_weak_pic() {
>> enabled pic && enable_weak_pic
>>
>> test_cc <> int ff_extern;
>> EOF
>> -sym=$($nm $TMPO | awk '/ff_extern/{ print substr($0, match($0, /[^
>> \t]*ff_extern/)) }')
>> +sym=$($nm $TMPO | awk '/[ \t]+[^ \t]{0,1}ff_extern/{ print substr($0,
>> match($0, /[^ \t]{0,1}ff_extern$/)) }')
>> extern_prefix=${sym%%ff_extern*}
>
> Since we're checking for ff_extern$ in the substr match, would it be safest
> to include the $ in the initial ff_extern match as well? So if there's a
> _ff_extern$foo symbol listed first, that won't be matched?
>
Indeed, sent a v3 where this is fixed.
> // Martin
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
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 02/60] fftools/opt_common: fix variable shadowing
On 9 Sep 2024, at 12:10, Anton Khirnov wrote:
> Quoting Marvin Scholz (2024-09-08 19:43:27)
>> ---
>> fftools/opt_common.c | 12 ++--
>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/fftools/opt_common.c b/fftools/opt_common.c
>> index 9d2d5184a0..059f7a53d2 100644
>> --- a/fftools/opt_common.c
>> +++ b/fftools/opt_common.c
>> @@ -553,15 +553,15 @@ static void show_help_filter(const char *name)
>> }
>> #endif
>>
>> -static void show_help_bsf(const char *name)
>> +static void show_help_bsf(const char *bsf_name)
>> {
>> -const AVBitStreamFilter *bsf = av_bsf_get_by_name(name);
>> +const AVBitStreamFilter *bsf = av_bsf_get_by_name(bsf_name);
>>
>> -if (!name) {
>> +if (!bsf_name) {
>> av_log(NULL, AV_LOG_ERROR, "No bitstream filter name specified.\n");
>> return;
>> } else if (!bsf) {
>> -av_log(NULL, AV_LOG_ERROR, "Unknown bit stream filter '%s'.\n",
>> name);
>> +av_log(NULL, AV_LOG_ERROR, "Unknown bit stream filter '%s'.\n",
>> bsf_name);
>
> What does this fix? I don't see any other instance of 'name' in this
> function.
See the GET_CODEC_NAME definition:
const char *name = avcodec_descriptor_get(id)->name;
>
>> return;
>> }
>>
>> @@ -1205,10 +1205,10 @@ int init_report(const char *env, FILE **file)
>>
>> report_file = fopen(filename.str, "w");
>> if (!report_file) {
>> -int ret = AVERROR(errno);
>> +int err = AVERROR(errno);
>> av_log(NULL, AV_LOG_ERROR, "Failed to open report \"%s\": %s\n",
>> filename.str, strerror(errno));
>> -return ret;
>> +return err;
>
> Might as well use the outer ret.
Ok.
>
> --
> 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 03/60] fftools/opt_common: use av_err2str instead of strerror
On 9 Sep 2024, at 3:30, Andreas Rheinhardt wrote:
> Marvin Scholz:
>> The strerror function must not be used here, as the error is a AVERROR
>> errno, which depending on the platform no longer corresponds to the
>> actual errno that can be handled by strerror.
>> ---
>> fftools/opt_common.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/fftools/opt_common.c b/fftools/opt_common.c
>> index 059f7a53d2..dc5fc7b96d 100644
>> --- a/fftools/opt_common.c
>> +++ b/fftools/opt_common.c
>> @@ -1207,7 +1207,7 @@ int init_report(const char *env, FILE **file)
>> if (!report_file) {
>> int err = AVERROR(errno);
>> av_log(NULL, AV_LOG_ERROR, "Failed to open report \"%s\": %s\n",
>> - filename.str, strerror(errno));
>> + filename.str, av_err2str(errno));
>> return err;
>> }
>> av_log_set_callback(log_callback_report);
>
> The code uses strerror(errno) and not strerror(err), so I don't get the
> rationale for this commit.
Noticed that as well when looking through the patches again before sending
but apparently forgot to drop it…
Dropped locally now, thanks.
>
> - 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 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/iamf_parse: Fix return of uninitialized value
On 31 Aug 2024, at 23:17, James Almer wrote: > On 8/31/2024 5:45 PM, Marvin Scholz wrote: >> The ret value here is not yet intialized so the return would return >> uninitialized data. What was probably meant to be checked here was the >> return value of ffio_read_size, which can return an error. >> >> Introduced in 38bcb3ba7b3424abd772c72f8bdf445d75285e88 >> >> Fixes: CID1618758 >> --- >> libavformat/iamf_parse.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/libavformat/iamf_parse.c b/libavformat/iamf_parse.c >> index f13e76b147..8a0003634b 100644 >> --- a/libavformat/iamf_parse.c >> +++ b/libavformat/iamf_parse.c >> @@ -98,8 +98,8 @@ static int aac_decoder_config(IAMFCodecConfig >> *codec_config, >> return AVERROR(ENOMEM); >>codec_config->extradata_size = ffio_read_size(pb, >> codec_config->extradata, left); >> -if (ret < 0) >> -return ret; >> +if (codec_config->extradata_size < 0) >> +return codec_config->extradata_size; >> memset(codec_config->extradata + codec_config->extradata_size, 0, >> AV_INPUT_BUFFER_PADDING_SIZE); > > LGTM. Please backport to 7.0 too. You (or someone else who can) will have to merge and backport as I have no commit access. Thanks. > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ 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] libavdevice: fix compilation for Mac OS X 10.7-10.12, iOS < 11
On 21 Aug 2024, at 3:09, Gnattu OC via ffmpeg-devel wrote:
>> On Aug 21, 2024, at 07:17, epira...@gmail.com wrote:
>>
>>
>>
>> On 21 Aug 2024, at 0:43, Erik Bråthen Solem wrote:
>>
>>> avfoundation.m uses constants prefixed with AVMediaType on Mac OS X > 10.6.
>>> In 10.7 through 10.12 their type was NSString*, but starting with 10.13 a
>>> new AVMediaType struct type was introduced. In avfoundation.m, the function
>>> getDevicesWithMediaType takes this struct as parameter, which breaks support
>>> for Mac OS X 10.7 through 10.12. By typedef-ing AVMediaType to NSString* for
>>> these versions, the code compiles. Prior to 10.15 the value is passed to a
>>> function that takes AVMediaType on 10.13+ and NSString* on <= 10.12. The
>>> same API change was introduced in iOS starting with iOS 11.
>>>
>>
>> Hi, thanks for the patch. Conceptually looks fine to me.
>>
>> See my remark below:
>>
>>> Signed-off-by: Erik Bråthen Solem
>>> ---
>>> libavdevice/avfoundation.m | 4
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
>>> index c5a09c6563..779bc767d6 100644
>>> --- a/libavdevice/avfoundation.m
>>> +++ b/libavdevice/avfoundation.m
>>> @@ -763,6 +763,10 @@ static int get_audio_config(AVFormatContext *s)
>>>return 0;
>>> }
>>>
>>> +#if ((TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MIN_REQUIRED < 11) ||
>>> (TARGET_OS_OSX && __MAC_OS_X_VERSION_MIN_REQUIRED < 101300))
>>> +typedef NSString* AVMediaType;
>>> +#endif
>>
>> I do not think this is the proper guard here? You want to check
>> *_MAX_ALLOWED if you want to check the SDK version,
>> which is what controls these change (as the SDK changed) not the minimum
>> version you target when compiling.
>
> This depends on use case though. For example, compiling on high version SDK,
> but targeting low version SDK and selectively
> load high version symbols during the runtime should not use *_MAX_ALLOWED
> because that will disable higher version symbols
> at build time which prevents the usage of the runtime version check.
What I meant here is that *_MAX_ALLOWED must be checked as this is about the
SDK version, while the *_MIN_REQUIRED ones are
about the targeted version. You do not runtime-load a typedef, that is purely a
compile-time thing.
So you would incorrectly do the typedef even if your SDK is more recent as
nothing prevents you targeting say 10.12 with a
10.14 SDK.
>
>>
>>> +
>>> static NSArray* getDevicesWithMediaType(AVMediaType mediaType) {
>>> #if ((TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MIN_REQUIRED >= 10) ||
>>> (TARGET_OS_OSX && __MAC_OS_X_VERSION_MIN_REQUIRED >= 101500))
>>>NSMutableArray *deviceTypes = nil;
>>> --
>>> 2.46.0
>>>
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>> To unsubscribe, visit link above, or email
>>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>> ___
>> ffmpeg-devel 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 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] libavdevice: fix compilation for Mac OS X 10.7-10.12, iOS < 11
On 21 Aug 2024, at 0:43, Erik Bråthen Solem wrote:
> avfoundation.m uses constants prefixed with AVMediaType on Mac OS X > 10.6.
> In 10.7 through 10.12 their type was NSString*, but starting with 10.13 a
> new AVMediaType struct type was introduced. In avfoundation.m, the function
> getDevicesWithMediaType takes this struct as parameter, which breaks support
> for Mac OS X 10.7 through 10.12. By typedef-ing AVMediaType to NSString* for
> these versions, the code compiles. Prior to 10.15 the value is passed to a
> function that takes AVMediaType on 10.13+ and NSString* on <= 10.12. The
> same API change was introduced in iOS starting with iOS 11.
>
Hi, thanks for the patch. Conceptually looks fine to me.
See my remark below:
> Signed-off-by: Erik Bråthen Solem
> ---
> libavdevice/avfoundation.m | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
> index c5a09c6563..779bc767d6 100644
> --- a/libavdevice/avfoundation.m
> +++ b/libavdevice/avfoundation.m
> @@ -763,6 +763,10 @@ static int get_audio_config(AVFormatContext *s)
> return 0;
> }
>
> +#if ((TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MIN_REQUIRED < 11) ||
> (TARGET_OS_OSX && __MAC_OS_X_VERSION_MIN_REQUIRED < 101300))
> +typedef NSString* AVMediaType;
> +#endif
I do not think this is the proper guard here? You want to check *_MAX_ALLOWED
if you want to check the SDK version,
which is what controls these change (as the SDK changed) not the minimum
version you target when compiling.
> +
> static NSArray* getDevicesWithMediaType(AVMediaType mediaType) {
> #if ((TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MIN_REQUIRED >= 10) ||
> (TARGET_OS_OSX && __MAC_OS_X_VERSION_MIN_REQUIRED >= 101500))
> NSMutableArray *deviceTypes = nil;
> --
> 2.46.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel 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] avcodec/amfenc: increase precision of Sleep() on Windows
On 19 Aug 2024, at 16:23, Araz Iusubov wrote: > From: Evgeny Pavlov > > This commit increase precision of Sleep() function on Windows. > This fix reduces the sleep time on Windows to improve AMF encoding > performance on low resolution input videos. > > Fix for issue #10622 > > We evaluated CreateWaitableTimerExW with > CREATE_WAITABLE_TIMER_HIGH_RESOLUTION flag. In fact, this function has > the same precision level as the Sleep() function. > > Usually changing the time resolution will only affect the current > process and will not impact other processes, thus it will not cause a > global effect on the current system. Here is an info from > documentation on timeBeginPeriod > https://learn.microsoft.com/en-us/windows/win32/api/timeapi/nf-timeapi-timebeginperiod > > "Prior to Windows 10, version 2004, this function affects a global > Windows setting. For all processes Windows uses the lowest value (that > is, highest resolution) requested by any process. Starting with > Windows 10, version 2004, this function no longer affects global timer > resolution. For processes which call this function, Windows uses the > lowest value (that is, highest resolution) requested by any process. > For processes which have not called this function, Windows does not > guarantee a higher resolution than the default system resolution." > > We provide the following measurement to show performance improvements > with this patch. > > 1. Performance tests show that this high precision sleep will improve > performance, especially for low resolution sequences, it can get about > 20% improvement. > > Frames Per Second (FPS) being encoded by the hardware encoder (Navi 31 > RX7900XT ): > > Source Type: H.264 , Output Type: H.264 > (Sorry for bad formatting) > No. | Sequence Resolution | No. of Frames|FPS Before patch| > FPS after patch | Difference| Improvement % > |---|--||---|---|-- > 1 | 480x360 | 8290 |2030| > 2365| 335 | 16.5% > 2 | 720x576 | 8290 |1440| > 1790| 350 | 24.3% > 3 | 1280x720| 8290 |1120| > 1190| 70| 6.3% > 4 | 1920x1080 | 8290 |692 | > 714 | 22| 3.2% > 5 | 3840x2160 | 8290 |200 | > 200 | 0 | 0.0% > The patch itself isn’t really my area of expertise as it’s very Windows specific APIs, but just a nit about the commit message: These tables are unreadable like this, but you can easily trim it down to fit the width limit: | Resolution | # Frames | FPS before | FPS after | Diff | % | ||--||---|--|---| | 480x360| 8290 | 2030 | 2365 | 335 | 16.5% | > The sample ffmpeg command line: > $ ffmpeg.exe -y -hwaccel d3d11va -hwaccel_output_format d3d11 -i > input.mp4 -c:v h264_amf out.mp4 > where input.mp4 should be changed to corresponding resolution input > H.264 format bitstream. > > 2. The power tests show an increase in power is within limit scope. > > The purpose of the power test is to examine the increase in CPU power > consumption due to the improvement in CPU time resolution after using > this patch. We were testing a product from AMD called Phoenix, which > we refer to as an APU. It combines a general-purpose AMD CPU and a 3D > integrated graphics processing unit (IGPU) on a single die. Only the > APU has a DAP connector to the board's power rails. > > We got the power test data shown below: > > || 480x360 | 720x576 | 1280x720 | > 1920x1080 | 3840x2160 | average > ||---||--|---|---| > |CPU power change | 1.93%| 2.43% | -1.69% | 3.49% > | 2.92% | 1.82% > |APU power total change | 0.86%| 1.34% | -0.62% | 1.54% > | -0.58%| 0.51 > > When using a high precision clock by applying the patch, the average > power consumption for CPU increases 1.82%, and the APU total increases > 0.51%. We can see the power increase in power not very significant. > > Signed-off-by: Evgeny Pavlov > --- > libavcodec/amfenc.c | 31 +++ > libavcodec/amfenc.h | 3 +++ > 2 files changed, 34 insertions(+) > > diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c > index 061859f85c..55e24856e8 100644 > --- a/libavcodec/amfenc.c > +++ b/libavcodec/amfenc.c > @@ -42,7 +42,12 @@ > #endif > > #ifdef _WIN32 > +#include > #include "compat/w32dlfcn.h" > + > +typedef MMRESULT (*timeapi_fun)(UINT uPeriod); > +#define WINMM_DLL "winmm.dll" > + > #else > #include > #endif > @@ -113,6 +118,9 @@ static int amf_load_library(AVCodecContext *avctx) > AMFInit_Fn
Re: [FFmpeg-devel] [PATCH 2/9] avcodec/avcodec: Warn about data returned from get_buffer*()
On 17 Aug 2024, at 1:11, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> doc/APIchanges | 4
> libavcodec/avcodec.h | 4
> 2 files changed, 8 insertions(+)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 173f317ea1b..53d164959c0 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -2,6 +2,10 @@ The last version increases of all libraries were on
> 2024-03-07
>
> API changes, most recent first:
>
> +2024-08-xx - x - lavc 61.11.100- avcodec.h
> + Not really a change but get_buffer*() should not return
> + sensitive data
IMO this is really hard to understand unless you look at exactly this
commit diff which most people reading the change log will not.
Maybe instead:
Clarify the documentation for get_buffer*() functions, making it
clear that the memory returned by them should not contain sensitive
information. This is not a change in the API and how it already worked
before.
> +
> 2024-08-10 - x - lavu 59.34.100 - hwcontext_vulkan.h
>Add qf and nb_qf to AVVulkanDeviceContext.
>Deprecate queue_family_index, nb_graphics_queues,
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 2da63c87ea1..cc6dbfa59fe 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -1175,6 +1175,10 @@ typedef struct AVCodecContext {
> * this callback and filled with the extra buffers if there are more
> * buffers than buf[] can hold. extended_buf will be freed in
> * av_frame_unref().
> + * decoders will generally initialize the whole buffer before it is
> output
„Decoders“ as this is the start of a sentence.
Maybe use \important to make this stand out more as a special consideration for
this API
instead of just general description.
> + * but it can in rare error conditions happen that uninitialized data
> is passed
> + * through. The buffers returned by get_buffer* should thus not
> contain sensitive
> + * data.
> *
> * If AV_CODEC_CAP_DR1 is not set then get_buffer2() must call
> * avcodec_default_get_buffer2() instead of providing buffers allocated
> by
> --
> 2.46.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel 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/7] avutil/riscv/asm: add stack pushing helpers
On 13 Aug 2024, at 17:51, Rémi Denis-Courmont wrote: > Le 13 août 2024 17:03:33 GMT+03:00, "J. Dekker" a écrit : >> From: Niklas Haas >> >> Instead of duplicating these common macros in every file, add them to >> the shared utility file. Also add a base case for sanity. > > Is `#error` a standard directive of C11? The #error directive dates back to C89: https://en.cppreference.com/w/c/preprocessor/error > >> --- >> libavcodec/riscv/h264addpx_rvv.S | 10 -- >> libavcodec/riscv/h264idct_rvv.S | 10 -- >> libavcodec/riscv/startcode_rvb.S | 10 -- >> libavutil/riscv/asm.S| 34 >> 4 files changed, 34 insertions(+), 30 deletions(-) >> >> diff --git a/libavcodec/riscv/h264addpx_rvv.S >> b/libavcodec/riscv/h264addpx_rvv.S >> index 82739881d9..cf3b742294 100644 >> --- a/libavcodec/riscv/h264addpx_rvv.S >> +++ b/libavcodec/riscv/h264addpx_rvv.S >> @@ -26,16 +26,6 @@ >> >> #include "libavutil/riscv/asm.S" >> >> -.macro sx rd, addr >> -#if (__riscv_xlen == 32) >> -sw \rd, \addr >> -#elif (__riscv_xlen == 64) >> -sd \rd, \addr >> -#else >> -sq \rd, \addr >> -#endif >> -.endm >> - >> func ff_h264_add_pixels4_8_rvv, zve32x >> lpad0 >> vsetivlizero, 4, e8, mf4, ta, ma >> diff --git a/libavcodec/riscv/h264idct_rvv.S >> b/libavcodec/riscv/h264idct_rvv.S >> index d2f77a5b47..076935a5d5 100644 >> --- a/libavcodec/riscv/h264idct_rvv.S >> +++ b/libavcodec/riscv/h264idct_rvv.S >> @@ -29,16 +29,6 @@ >> >> #include "libavutil/riscv/asm.S" >> >> -.macro sx rd, addr >> -#if (__riscv_xlen == 32) >> -sw \rd, \addr >> -#elif (__riscv_xlen == 64) >> -sd \rd, \addr >> -#else >> -sq \rd, \addr >> -#endif >> -.endm >> - >> .variant_cc ff_h264_idct4_rvv >> func ff_h264_idct4_rvv, zve32x >> vsra.vi v5, v1, 1 >> diff --git a/libavcodec/riscv/startcode_rvb.S >> b/libavcodec/riscv/startcode_rvb.S >> index eec92d3340..c131ebdf59 100644 >> --- a/libavcodec/riscv/startcode_rvb.S >> +++ b/libavcodec/riscv/startcode_rvb.S >> @@ -26,16 +26,6 @@ >> >> #include "libavutil/riscv/asm.S" >> >> -.macro lx rd, addr >> -#if (__riscv_xlen == 32) >> -lw \rd, \addr >> -#elif (__riscv_xlen == 64) >> -ld \rd, \addr >> -#else >> -lq \rd, \addr >> -#endif >> -.endm >> - >> func ff_startcode_find_candidate_rvb, zbb >> lpad0 >> add a1, a0, a1 >> diff --git a/libavutil/riscv/asm.S b/libavutil/riscv/asm.S >> index ec68a042d1..175f2a8672 100644 >> --- a/libavutil/riscv/asm.S >> +++ b/libavutil/riscv/asm.S >> @@ -237,3 +237,37 @@ >> .macro vntypei rd, rs, n=1 >> vwtypei \rd, \rs, -(\n) >> .endm >> + >> +/** >> + * Write an XLEN-sized register to an address. >> + * @param rs source register >> + * @param addr address to write to >> + */ >> +.macro sx rs, addr >> +#if (__riscv_xlen == 32) >> +sw \rs, \addr >> +#elif (__riscv_xlen == 64) >> +sd \rs, \addr >> +#elif (__riscv_xlen == 128) >> +sq \rs, \addr >> +#else >> +#error Unhandled value of XLEN >> +#endif >> +.endm >> + >> +/** >> + * Read an XLEN-sized register from an address. >> + * @param[out] rd destination register >> + * @param addr address to read from >> + */ >> +.macro lx rd, addr >> +#if (__riscv_xlen == 32) >> +lw \rd, \addr >> +#elif (__riscv_xlen == 64) >> +ld \rd, \addr >> +#elif (__riscv_xlen == 128) >> +lq \rd, \addr >> +#else >> +#error Unhandled value of XLEN >> +#endif >> +.endm > ___ > 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] avutil/hwcontext_videotoolbox: silence warning for RGB
On 10 Aug 2024, at 8:13, gnattu via ffmpeg-devel wrote:
> Hardware frames with RGB colorspace will not have a YCbCrMatrixKey.
> Currently, it will spam the console with warning if rgb frame is
> uploaded.
Thanks, LGTM
>
> Signed-off-by: Gnattu OC
> ---
> libavutil/hwcontext_videotoolbox.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavutil/hwcontext_videotoolbox.c
> b/libavutil/hwcontext_videotoolbox.c
> index 80eaab64f08..122a61d5e78 100644
> --- a/libavutil/hwcontext_videotoolbox.c
> +++ b/libavutil/hwcontext_videotoolbox.c
> @@ -576,7 +576,7 @@ static int vt_pixbuf_set_colorspace(void *log_ctx,
> colormatrix, kCVAttachmentMode_ShouldPropagate);
> else {
> CVBufferRemoveAttachment(pixbuf, kCVImageBufferYCbCrMatrixKey);
> -if (src->colorspace != AVCOL_SPC_UNSPECIFIED)
> +if (src->colorspace != AVCOL_SPC_UNSPECIFIED && src->colorspace !=
> AVCOL_SPC_RGB)
> av_log(log_ctx, AV_LOG_WARNING,
> "Color space %s is not supported.\n",
> av_color_space_name(src->colorspace));
> --
> 2.39.3 (Apple Git-146)
>
> ___
> 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] avutil/hwcontext_videotoolbox: Allocate attachments dictionary
On 2 Aug 2024, at 0:25, gnattu via ffmpeg-devel wrote:
> From: Gnattu OC
>
> Allocate a dedicated attachments dictionary instead of trying to get
> one from the pixel buffer. The attachments got from the pixel buffer
> confuses the CVImageBufferCreateColorSpaceFromAttachments method and
> will make it to output a wrong colorspace that causes problem like
> #10884.
Thanks for the patch. Looks fine in principle given this was essentially
how I did it before.
Did you check if maybe removing the kCVImageBufferCGColorSpaceKey by doing
CVBufferRemoveAttachment(pixbuf, kCVImageBufferCGColorSpaceKey); before
calling CVImageBufferCreateColorSpaceFromAttachments() is enough to make
it work with the attachments obtained from the pixel buffer?
>
> Signed-off-by: gnattu
> ---
> libavutil/hwcontext_videotoolbox.c | 35 ++
> 1 file changed, 21 insertions(+), 14 deletions(-)
>
> diff --git a/libavutil/hwcontext_videotoolbox.c
> b/libavutil/hwcontext_videotoolbox.c
> index 1794459943..dda6ada1af 100644
> --- a/libavutil/hwcontext_videotoolbox.c
> +++ b/libavutil/hwcontext_videotoolbox.c
> @@ -569,11 +569,19 @@ static int vt_pixbuf_set_colorspace(void *log_ctx,
> CGColorSpaceRef colorspace = NULL;
> CFStringRef colormatrix = NULL, colorpri = NULL, colortrc = NULL;
> Float32 gamma = 0;
> +CFMutableDictionaryRef attachments = NULL;
> +attachments = CFDictionaryCreateMutable(NULL, 0,
> +&kCFTypeDictionaryKeyCallBacks,
> +
> &kCFTypeDictionaryValueCallBacks);
> +if (!attachments)
> +return AVERROR(ENOMEM);
>
> colormatrix = av_map_videotoolbox_color_matrix_from_av(src->colorspace);
> -if (colormatrix)
> +if (colormatrix) {
> +CFDictionarySetValue(attachments, kCVImageBufferYCbCrMatrixKey,
> colormatrix);
> CVBufferSetAttachment(pixbuf, kCVImageBufferYCbCrMatrixKey,
> -colormatrix, kCVAttachmentMode_ShouldPropagate);
> + colormatrix,
> kCVAttachmentMode_ShouldPropagate);
> +}
> else {
> CVBufferRemoveAttachment(pixbuf, kCVImageBufferYCbCrMatrixKey);
> if (src->colorspace != AVCOL_SPC_UNSPECIFIED)
> @@ -583,9 +591,11 @@ static int vt_pixbuf_set_colorspace(void *log_ctx,
> }
>
> colorpri =
> av_map_videotoolbox_color_primaries_from_av(src->color_primaries);
> -if (colorpri)
> +if (colorpri) {
> +CFDictionarySetValue(attachments, kCVImageBufferColorPrimariesKey,
> colorpri);
> CVBufferSetAttachment(pixbuf, kCVImageBufferColorPrimariesKey,
> -colorpri, kCVAttachmentMode_ShouldPropagate);
> + colorpri, kCVAttachmentMode_ShouldPropagate);
> +}
> else {
> CVBufferRemoveAttachment(pixbuf, kCVImageBufferColorPrimariesKey);
> if (src->color_primaries != AVCOL_SPC_UNSPECIFIED)
> @@ -595,9 +605,11 @@ static int vt_pixbuf_set_colorspace(void *log_ctx,
> }
>
> colortrc = av_map_videotoolbox_color_trc_from_av(src->color_trc);
> -if (colortrc)
> +if (colortrc) {
> +CFDictionarySetValue(attachments, kCVImageBufferTransferFunctionKey,
> colortrc);
> CVBufferSetAttachment(pixbuf, kCVImageBufferTransferFunctionKey,
> -colorpri, kCVAttachmentMode_ShouldPropagate);
> + colorpri, kCVAttachmentMode_ShouldPropagate);
> +}
> else {
> CVBufferRemoveAttachment(pixbuf, kCVImageBufferTransferFunctionKey);
> if (src->color_trc != AVCOL_TRC_UNSPECIFIED)
> @@ -622,17 +634,12 @@ static int vt_pixbuf_set_colorspace(void *log_ctx,
> #if (TARGET_OS_OSX && __MAC_OS_X_VERSION_MAX_ALLOWED >= 100800) || \
> (TARGET_OS_IOS && __IPHONE_OS_VERSION_MAX_ALLOWED >= 10)
> if (__builtin_available(macOS 10.8, iOS 10, *)) {
> -CFDictionaryRef attachments =
> -vt_cv_buffer_copy_attachments(pixbuf,
> kCVAttachmentMode_ShouldPropagate);
> -
> -if (attachments) {
> -colorspace =
> -CVImageBufferCreateColorSpaceFromAttachments(attachments);
> -CFRelease(attachments);
> -}
> +colorspace =
> CVImageBufferCreateColorSpaceFromAttachments(attachments);
> }
> #endif
>
> +CFRelease(attachments);
> +
> // Done outside the above preprocessor code and if's so that
> // in any case a wrong kCVImageBufferCGColorSpaceKey is removed
> // if the above code is not used or fails.
> --
> 2.39.3 (Apple Git-146)
>
> ___
> 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
Re: [FFmpeg-devel] Merging dashcam videos and adding merged GPX data to final video
On 23 Jul 2024, at 9:26, Prem Thogiti wrote:
> Hi Team,
>
Hi,
I believe this is the wrong list for such a question.
This is the development list, you want to ask on ffmpeg-user instead.
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
> I have a folder with 100+ mp4 files (each 1min duration) and its
> corresponding gpx file extracted from a GPS enabled dashcam device.
>
> Each individual mp4 file has geotagging information for each 1 sec as shown
> below.
>
> SampleTime : 29.00 s
> SampleDuration : 1.00 s
> GPSLatitude : 48 deg 54' 18.95" N
> GPSLongitude: 2 deg 16' 48.06" E
> GPSSpeed: 51.4989
> GPSDateTime : 2022:05:18 09:40:39.000Z
> SampleTime : 0:00:30
> SampleDuration : 0 s
> Text:
> SampleTime : 0:00:30
> SampleDuration : 1.00 s
> GPSLatitude : 48 deg 54' 19.17" N
> GPSLongitude: 2 deg 16' 48.37" E
> GPSSpeed: 51.4989
> GPSDateTime : 2022:05:18 09:40:40.000Z
> SampleTime : 0:00:31
> SampleDuration : 0 s
> Text:
>
>
> Right now I need to merge every 5 consecutive mp4 files together to have
> 5min video and also retain such geotagging metadata for 5 mins. I was able
> to generate a merged mp4 file but I could not add geotagging information
> either from the merged gpx file.
>
> CodeSelect
> ls *.MP4 | awk '{print "file '\''" $0 "'\''"}' > filelist.txt
> ffmpeg -f concat -safe 0 -i filelist.txt -c copy merged.mp4
> Does this exiftool support adding geotagging GPX data to mp4 file? if yes,
> please point to the details
>
> Or may be any other tool which does this job, would love to explore.
>
> Any help would be much appreciated in this regard.
>
> -Prem
> ___
> 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] lavc/videotoolbox: drop HEVC cropping from start_frame rather than end_frame
On 23 Jul 2024, at 9:36, Anton Khirnov wrote:
> HEVCContext.output_frame will be removed in following commits.
>
> Reported-By: Max Bykov
> ---
> Untested, testing welcome.
Tested with fate-hevc-conformance-CONFWIN_A_Sony_1 and works.
LGTM
>
> Cf. '[PATCH 37/39] lavc/hevcdec: use a ContainerFifo to hold frames
> scheduled for output' currently on ML.
> ---
> libavcodec/videotoolbox.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> index 3dd804bb0c..505483ef66 100644
> --- a/libavcodec/videotoolbox.c
> +++ b/libavcodec/videotoolbox.c
> @@ -1053,6 +1053,14 @@ static int
> videotoolbox_hevc_start_frame(AVCodecContext *avctx,
> const uint8_t *buffer,
> uint32_t size)
> {
> +HEVCContext *h = avctx->priv_data;
> +AVFrame *frame = h->cur_frame->f;
> +
> +frame->crop_right = 0;
> +frame->crop_left = 0;
> +frame->crop_top= 0;
> +frame->crop_bottom = 0;
> +
> return 0;
> }
>
> @@ -1079,11 +1087,6 @@ static int videotoolbox_hevc_end_frame(AVCodecContext
> *avctx)
> VTContext *vtctx = avctx->internal->hwaccel_priv_data;
> int ret;
>
> -h->output_frame->crop_right = 0;
> -h->output_frame->crop_left = 0;
> -h->output_frame->crop_top = 0;
> -h->output_frame->crop_bottom = 0;
> -
> ret = ff_videotoolbox_common_end_frame(avctx, frame);
> vtctx->bitstream_size = 0;
> return ret;
> --
> 2.43.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel 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] avutil/hwcontext_videotoolbox: Check CVBufferCopyAttachments during configure
On 22 Jul 2024, at 0:47, gnattu via ffmpeg-devel wrote:
> The __builtin_available function does not do compile time check
> for the availablity of the CVBufferCopyAttachments function
> which will fail the build. Check the availability during configure.
>
> Signed-off-by: Gnattu OC
> ---
> configure | 2 ++
> libavutil/hwcontext_videotoolbox.c | 12 +---
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/configure b/configure
> index f6f5c29fea..54171dd4e5 100755
> --- a/configure
> +++ b/configure
> @@ -2366,6 +2366,7 @@ SYSTEM_FUNCS="
> clock_gettime
> closesocket
> CommandLineToArgvW
> +CVBufferCopyAttachments
> fcntl
> getaddrinfo
> getauxval
> @@ -6684,6 +6685,7 @@ enabled videotoolbox && {
> check_func_headers CoreVideo/CVImageBuffer.h
> kCVImageBufferColorPrimaries_ITU_R_2020 "-framework CoreVideo"
> check_func_headers CoreVideo/CVImageBuffer.h
> kCVImageBufferTransferFunction_ITU_R_2020 "-framework CoreVideo"
> check_func_headers CoreVideo/CVImageBuffer.h
> kCVImageBufferTransferFunction_SMPTE_ST_428_1 "-framework CoreVideo"
> +check_func_headers CoreVideo/CVBuffer.h CVBufferCopyAttachments
> "-framework CoreVideo"
> }
>
Thanks for the fix and sorry for breaking this.
I am not too keen on adding a configure check just for that, as if we do that
for all partially available function
it will make configure even slower than it already is.
I have a fix for this ready testing for the right SDK conditionals (I only did
not catch it before because
the way the SDK annotations work nowadays do not seem to properly honor when I
set my own __MAC_OS_X_VERSION_MAX_ALLOWED
define…) so I will need to actually test this on an old enough SDK just to be
sure, this time…
Then again, if others prefer doing it with configure tests, I am ok with that
as well.
> enabled metal && test_cmd $metalcc -v || disable metal
> diff --git a/libavutil/hwcontext_videotoolbox.c
> b/libavutil/hwcontext_videotoolbox.c
> index ab7556936d..c55d478004 100644
> --- a/libavutil/hwcontext_videotoolbox.c
> +++ b/libavutil/hwcontext_videotoolbox.c
> @@ -592,15 +592,13 @@ static int vt_pixbuf_set_colorspace(void *log_ctx,
> (TARGET_OS_IOS && __IPHONE_OS_VERSION_MAX_ALLOWED >= 10)
> if (__builtin_available(macOS 10.8, iOS 10, *)) {
> CFDictionaryRef attachments = NULL;
> +#if HAVE_CVBUFFERCOPYATTACHMENTS
> if (__builtin_available(macOS 12.0, iOS 15.0, *))
> attachments = CVBufferCopyAttachments(pixbuf,
> kCVAttachmentMode_ShouldPropagate);
> -#if (TARGET_OS_OSX && __MAC_OS_X_VERSION_MIN_REQUIRED <= 12) || \
> -(TARGET_OS_IOS && __IPHONE_OS_VERSION_MIN_REQUIRED <= 15)
> -else {
> -CFDictionaryRef tmp = CVBufferGetAttachments(pixbuf,
> kCVAttachmentMode_ShouldPropagate);
> -if (tmp)
> -attachments = CFDictionaryCreateCopy(NULL, tmp);
> -}
> +#else
> +CFDictionaryRef tmp = CVBufferGetAttachments(pixbuf,
> kCVAttachmentMode_ShouldPropagate);
> +if (tmp)
> +attachments = CFDictionaryCreateCopy(NULL, tmp);
> #endif
> if (attachments) {
> colorspace =
> CVImageBufferCreateColorSpaceFromAttachments(attachments);
> --
> 2.39.3 (Apple Git-146)
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] libavformat/vapoursynth: Update to API version 4, load library at runtime
On 18 Jul 2024, at 16:21, Ramiro Polla wrote:
> On Thu, Jul 18, 2024 at 3:41 PM Stefan Oltmanns via ffmpeg-devel
> wrote:
>> Am 18.07.24 um 15:04 schrieb Ramiro Polla:
>> [...]
>>
>> +static VSScriptLibrary vs_script_library;
>
> Does vs_script_library have to be a global?
>
I think it has to: ffmpeg allows multiple input files, in case you open
two VapourSynth files you want to load the Library only once.
>>>
>>> It should be possible to dlopen()/LoadLibrary() multiple times, and
>>> the library only gets really unloaded after the last call to
>>> dlclose()/FreeLibrary(). In that case you could move that struct to
>>> the context. If it's unavoidable to keep the global, at least add some
>>> locks to access it.
>>
>> Yes, that should be possible. I did a quick search at it seems that
>> dlopen()/LoadLibrary() is smart and will not open the same library
>> multiple times, but return the same pointer.
>> As dlclose won't be used anymore when removing the atexit handler, that
>> is not an issue at all.
>
> dlclose() will have to be called at some point (i.e.: in read_close).
>
This is exactly how it's done for AviSynth.
>>>
>>> Perhaps AviSynth is not the best example to follow :)
>>>
>> +
>> +static int vs_atexit_called = 0;
>> +
>> +static av_cold void vs_atexit_handler(void);
>> +
>> +#ifdef _WIN32
>> +static av_cold char* get_vs_script_dll_name(void) {
>> + LONG r;
>> + WCHAR vss_path[512];
>> + char *vss_path_utf8;
>> + DWORD buf_size = sizeof(vss_path) - 2;
>> + r = RegGetValueW(HKEY_CURRENT_USER, L"SOFTWARE\\VapourSynth",
>> + L"VSScriptDLL", RRF_RT_REG_SZ, NULL,
>> + &vss_path, &buf_size);
>> + if (r == ERROR_SUCCESS && wchartoutf8(vss_path, &vss_path_utf8)
>> == 0)
>> + return vss_path_utf8;
>> + r = RegGetValueW(HKEY_LOCAL_MACHINE, L"SOFTWARE\\VapourSynth",
>> + L"VSScriptDLL", RRF_RT_REG_SZ, NULL,
>> + &vss_path, &buf_size);
>> + if (r == ERROR_SUCCESS && wchartoutf8(vss_path, &vss_path_utf8)
>> == 0)
>> + return vss_path_utf8;
>> + if (wchartoutf8(L"VSScript.dll", &vss_path_utf8) == 0)
>> + return vss_path_utf8;
>> + return 0;
>> +}
>> +#endif
>
> Don't fetch the path on the registry on Windows. The user should set the
> path outside of FFmpeg.
How exactly should the user do that? Additional option to ffmpeg?
>>>
>>> By making sure the libraries are accessible in the PATH environment
>>> variable. For example by adding the VapourSynth path to the PATH
>>> environment variable, or overriding PATH on the call to FFmpeg on a
>>> script. Either way that's outside the scope of FFmpeg.
>>
>> Well, the DLL directory is added to PATH by the VapourSynth installer,
>> but for safety reasons ffmpeg explictly tells the LoadLibrary function
>> to only search the application directory and system32, quote from
>> w32dlfcn.h:
>>
>>> /**
>>> * Safe function used to open dynamic libs. This attempts to improve
>>> program security
>>> * by removing the current directory from the dll search path. Only dll's
>>> found in the
>>> * executable or system directory are allowed to be loaded.
>>> * @param name The dynamic lib name.
>>> * @return A handle to the opened lib.
>>> */
>> So ffmpeg prevents that solution on purpose. Or should that behavior be
>> changed in the w32dlfcn.h?
>
> Oh, bummer. I would expect that overriding the PATH environment
> variable would work kind of like how LD_LIBRARY_PATH works on Linux. I
> don't know why that was changed. I don't really follow what goes on in
> Windowsland anymore. Does anyone else care to comment on this? Martin,
> maybe?
IIRC this is done to prevent DLL injection attacks
https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-security
>
> Ramiro
> ___
> 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] [OSS-Fuzz] Have you considered enabling memory sanitizer?
On 14 Jul 2024, at 21:55, Michael Niedermayer wrote: > On Sat, Jul 13, 2024 at 11:12:40PM +0200, Kacper Michajlow wrote: >> On Thu, 27 Jun 2024 at 02:50, Kacper Michajlow wrote: >>> >>> On Thu, 27 Jun 2024 at 00:45, Michael Niedermayer >>> wrote: On Wed, Jun 26, 2024 at 09:07:42PM +0200, Kacper Michajlow wrote: > Hi, > > Like in the topic. I think it would be useful to enable MSAN on > OSS-Fuzz. We get some tiny issues and it would be probably good to > have them tracked upstream. All infra is here, so enabling it is as > simple as adding it to the project.yaml. Except libbz2.so and libz.so > would have to be built inline instead, looking at the build.sh, they > are prebuilt. The rest should just work (TM), but needs to be tested. > You can set an "experimental' flag to have it not create issues on > monorail, initially. I assumed ossfuzz would enable all sanitizers by default >>> >>> They do not do that by default, because MSAN requires all dependencies >>> to be instrumented too. See >>> https://google.github.io/oss-fuzz/getting-started/new-project-guide/#sanitizers >>> >>> Looking at build.sh for ffmpeg, it should be fine to enable it. >>> Obviously I have not tested everything, but I was running some tests >>> locally with MSAN and also tested it with mpv oss-fuzz builds where we >>> build ffmpeg too with MSAN. >>> >>> - Kacper >> >> I've sent a PR to enable MSAN and a few other build improvements. >> Please take a look https://github.com/google/oss-fuzz/pull/12211 >> > >> Also, would it be ok to add myself to auto_ccs for ffmpeg? Mostly to >> monitor what issues are reported upstream, as we get some reports in >> mpv fuzzing and I never know if I should report it upstream (ffmpeg) >> or it is already found by first-party fuzzing and I shouldn't make >> more noise. > > you are welcome to submit bug reports, you are welcome to submit bug fixes > if you find issues in FFmpeg. > > If someones work in FFmpeg or rather FFmpeg benefits from someone having > access to the reports, then (s)he should receive access. This seems not > to apply here This seems quite rude… Maybe you did not intend it but thats how it reads to me… > > Also i expect the number of outstanding ossfuzz issues to decrease now > after the bulk of coverity issues has been dealt with > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The real ebay dictionary, page 1 > "Used only once"- "Some unspecified defect prevented a second use" > "In good condition" - "Can be repaird by experienced expert" > "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." > ___ > 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 10/11] avfilter/yadif_common: remove unused variable
On 13 Jul 2024, at 2:50, Andreas Rheinhardt wrote:
> Marvin Scholz:
>> ---
>> libavfilter/vf_yadif_videotoolbox.m | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/libavfilter/vf_yadif_videotoolbox.m
>> b/libavfilter/vf_yadif_videotoolbox.m
>> index c47d3edfb8..eb7026395e 100644
>> --- a/libavfilter/vf_yadif_videotoolbox.m
>> +++ b/libavfilter/vf_yadif_videotoolbox.m
>> @@ -172,7 +172,6 @@ static void filter(AVFilterContext *ctx, AVFrame *dst,
>> static av_cold void do_uninit(AVFilterContext *ctx)
>> API_AVAILABLE(macos(10.11), ios(8.0))
>> {
>> YADIFVTContext *s = ctx->priv;
>> -YADIFContext *y = &s->yadif;
>>
>> ff_yadif_uninit(ctx);
>>
>
> This is not yadif_common.
Thanks, will be fixed in the next iteration.
>
> - 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 mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avutil/avassert: Add av_assert_unreachable()
On 13 Jul 2024, at 2:47, Andreas Rheinhardt wrote:
> Marvin Scholz:
>> ---
>> libavutil/avassert.h | 12
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/libavutil/avassert.h b/libavutil/avassert.h
>> index 1895fb7551..cdab912fe4 100644
>> --- a/libavutil/avassert.h
>> +++ b/libavutil/avassert.h
>> @@ -75,4 +75,16 @@
>> */
>> void av_assert0_fpu(void);
>>
>> +/**
>> + * Assert this can not be reached
>> + */
>> +#if AV_HAS_BUILTIN(__builtin_unreachable)
>> +#define av_assert_unreachable() do { \
>> +av_assert2(0); \
>> +__builtin_unreachable();\
>> +} while (0)
>> +#else
>> +#define av_assert_unreachable() av_assert2(0)
>> +#endif
>> +
>> #endif /* AVUTIL_AVASSERT_H */
>>
>> base-commit: 85706f5136cf7c88f95843b2634dd3f7d7d2cb6d
>
> You are not the first one with this idea:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2024-May/328116.html
> But Michael Niedermayer thinks that adding a new macro instead of
> directly reusing av_assert is more complicated.
>
Oh I did not notice that one, thanks…
I definitely think an av_assert_unreachable() is clearer than
av_assert0(!"reached") too, obviously, else I would not propose it.
(Somewhat proven by these two cases fixed by the patch where we use
av_assert1/2(0) variants which then result in the compiler not knowing
these are unreachable cases when the assert is not enabled.)
If this approach is rejected, I can submit a version that uses
av_assert0(!"reached“).
> - 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 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] avutil/hwcontext_videotoolbox: Fix version check
On 10 Jul 2024, at 19:26, James Almer wrote:
> On 7/9/2024 5:43 AM, epira...@gmail.com wrote:
>>
>>
>> On 8 Jul 2024, at 8:30, Zhao Zhili wrote:
>>
>>> From: Zhao Zhili
>>>
>>> ---
>>> libavutil/hwcontext_videotoolbox.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavutil/hwcontext_videotoolbox.c
>>> b/libavutil/hwcontext_videotoolbox.c
>>> index 953155ce32..dd89edfa08 100644
>>> --- a/libavutil/hwcontext_videotoolbox.c
>>> +++ b/libavutil/hwcontext_videotoolbox.c
>>> @@ -588,7 +588,7 @@ static int vt_pixbuf_set_colorspace(void *log_ctx,
>>> } else
>>> CVBufferRemoveAttachment(pixbuf, kCVImageBufferGammaLevelKey);
>>>
>>> -if (__builtin_available(macOS 10.8, iOS 10, *)) {
>>> +if (__builtin_available(macOS 12.0, iOS 15.0, *)) {
>>> CFDictionaryRef attachments = CVBufferCopyAttachments(pixbuf,
>>> kCVAttachmentMode_ShouldPropagate);
>>> if (attachments) {
>>> colorspace =
>>> CVImageBufferCreateColorSpaceFromAttachments(attachments);
>>> --
>>> 2.42.0
>>
>> LGTM. Sorry for breaking this.
>
> http://fate.ffmpeg.org/log.cgi?time=20240710170512&slot=aarch64-osx-clang-1200.0.32.29&log=compile
>
> Looks like it's not enough.
See my patch from yesterday, should fix 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".
___
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] videotoolbox increases min target to macOS 12
On 9 Jul 2024, at 21:44, Helmut K. C. Tessarek wrote: > Thanks for the reply. > > On 2024-07-09 02:16, Gnattu OC via ffmpeg-devel wrote: >> Well the code introduced is to fix certain HDR related bugs and it does not >> "works perfectly” before, it was just broken. > > I was rather talking about being able to compile it. I can compile ffmpeg > without videotoolbox for older deployment targets without any issues. > > It is great to fix videotoolbox, but is it required to use functions/methods > that are only available in newer OS? All the other libraries and ffmpeg > itself can fix bugs without using functions that are not available on "older" > systems. > > If you say it isn't possible, then all is good. I am not asking anyone to > make the impossible possible. > > I am just trying to understaand why videotoolbox is raising the minimum > deploymewnt target all the time, while this is not necessary for anything > else. Don't get me wrong, I am compiling ffmpeg with around 50 3rd party > libraries. None of them requires me to raise the deployment target. Videotoolbox should not have raised the deployment target and I did not notice any change recently that would have done it other than mine accidentally. If you encounter other issues with it, once my fix is merged, do not hesitate to report them here. > >> so that it should at least compile on older OS targets. >> But the end result is that the colorspace is as wrong as before, an older >> version cannot receive the fix to set the correct colorspace. >> >> For this use case I could see that using the (now deprecated) >> `CVBufferGetAttachments` instead on older OS, but I cannot really test that >> because I don’t have device running that old version. > > FYI. I am also compiling on the most recent macOS release but I set the > deployment target via env var: > > export MACOSX_DEPLOYMENT_TARGET=10.13 > > > -- > regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 > Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 > > /* >Thou shalt not follow the NULL pointer for chaos and madness >await thee at its end. > */ > ___ > 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] lavfi/perlin: Fix out of bounds stack buffer write
On 6 Jul 2024, at 11:26, Stefano Sabatini wrote:
> On date Tuesday 2024-07-02 20:38:00 +0200, Marvin Scholz wrote:
>> An incorrect calculation in ff_perlin_init causes a write to the
>> stack array at index 256, which is out of bounds.
>>
>> Fixes: CID1608711
>> ---
>> libavfilter/perlin.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavfilter/perlin.c b/libavfilter/perlin.c
>> index 09bae7ad33..ffad8c1e4e 100644
>> --- a/libavfilter/perlin.c
>> +++ b/libavfilter/perlin.c
>> @@ -129,7 +129,7 @@ int ff_perlin_init(FFPerlin *perlin, double period, int
>> octaves, double persiste
>> for (i = 0; i < 256; i++) {
>> unsigned int random_idx = av_lfg_get(&lfg) % (256-i);
>> uint8_t random_val = random_permutations[random_idx];
>> -random_permutations[random_idx] = random_permutations[256-i];
>> +random_permutations[random_idx] = random_permutations[255-i];
>>
>> perlin->permutations[i] = perlin->permutations[i+256] =
>> random_val;
>> }
>
> Looks good, thanks.
Please push then, I do not have commit access.
> ___
> 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] avutil/hwcontext_videotoolbox: Fix version check
On 8 Jul 2024, at 8:30, Zhao Zhili wrote:
> From: Zhao Zhili
>
> ---
> libavutil/hwcontext_videotoolbox.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavutil/hwcontext_videotoolbox.c
> b/libavutil/hwcontext_videotoolbox.c
> index 953155ce32..dd89edfa08 100644
> --- a/libavutil/hwcontext_videotoolbox.c
> +++ b/libavutil/hwcontext_videotoolbox.c
> @@ -588,7 +588,7 @@ static int vt_pixbuf_set_colorspace(void *log_ctx,
> } else
> CVBufferRemoveAttachment(pixbuf, kCVImageBufferGammaLevelKey);
>
> -if (__builtin_available(macOS 10.8, iOS 10, *)) {
> +if (__builtin_available(macOS 12.0, iOS 15.0, *)) {
> CFDictionaryRef attachments = CVBufferCopyAttachments(pixbuf,
> kCVAttachmentMode_ShouldPropagate);
> if (attachments) {
> colorspace =
> CVImageBufferCreateColorSpaceFromAttachments(attachments);
> --
> 2.42.0
LGTM. Sorry for breaking this.
>
> ___
> 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] videotoolbox increases min target to macOS 12
On 9 Jul 2024, at 8:16, Gnattu OC via ffmpeg-devel wrote: >> On Jul 9, 2024, at 13:47, Helmut K. C. Tessarek wrote: >> >> I'm very sorry to bother the dev list with this, but this is the 2nd time in >> less than a year that the min version of macOS was changed in videotoolbox. >> >> 2023-09-22: macOS 10.13 >> now: macOS 12 >> >> Will ffmpeg soon only compile on the current release of macOS (with >> videtoolbox support)? While I understand that too old OS versions are not >> necessarily the best idea, a lot of people still use older versions. >> Especially when it comes to Intel based static binaries. >> >> I just want to ask what the devs think of this situation. >> I'm not saying that this has to be fixed. (I just removed the videotoolbox >> support from my binaries.) >> >> I'd asked in a forum, but there is none, nor is there another way to ask the >> devs a question. And it is a question to the devs: >> >> Is it feasible that this code raises the minimum depolyment target that >> often, while the rest of ffmpeg just works perfectly fine with lower >> deployment targets? > > Well the code introduced is to fix certain HDR related bugs and it does not > "works perfectly” before, it was just broken. >> >> Cheers, >> K. C. >> >> Here is the error message when compiling ffmpeg for reference: >> >> libavutil/hwcontext_videotoolbox.c:592:39: error: 'CVBufferCopyAttachments' >> is only available on macOS 12.0 or newer >> [-Werror,-Wunguarded-availability-new] >>CFDictionaryRef attachments = CVBufferCopyAttachments(pixbuf, >> kCVAttachmentMode_ShouldPropagate); > > This should be fixed by this patch: > https://patchwork.ffmpeg.org/project/ffmpeg/patch/tencent_386ebee5491311084f93f9136a75c4090...@qq.com/ > > so that it should at least compile on older OS targets. > But the end result is that the colorspace is as wrong as before, an older > version cannot receive the fix to set the correct colorspace. > > For this use case I could see that using the (now deprecated) > `CVBufferGetAttachments` instead on older OS, but I cannot really test that > because I don’t have device running that old version. Yes, I can submit a fix for this soon that makes this work on macOS 10.8+ For now the other patch should be merged to fix the runtime issue. (I am not sure why I did not get any warning about this locally…) >> ^~~ >> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreVideo.framework/Headers/CVBuffer.h:160:59: >> note: 'CVBufferCopyAttachments' has been marked as being introduced in >> macOS 12.0 here, but the deployment target is macOS 10.13.0 >> CV_EXPORT CFDictionaryRef CF_RETURNS_RETAINED CV_NULLABLE >> CVBufferCopyAttachments( CVBufferRef CV_NONNULL buffer, CVAttachmentMode >> attachmentMode ) API_AVAILABLE(macos(12.0), ios(15.0), tvos(15.0), >> watchos(8.0)); >> ^ >> libavutil/hwcontext_videotoolbox.c:592:39: note: enclose >> 'CVBufferCopyAttachments' in a __builtin_available check to silence this >> warning >>CFDictionaryRef attachments = CVBufferCopyAttachments(pixbuf, >> kCVAttachmentMode_ShouldPropagate); >> ^~~ >> 1 error generated. >> >> >> -- >> regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 >> Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 >> >> /* >> Thou shalt not follow the NULL pointer for chaos and madness >> await thee at its end. >> */ >> ___ >> 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 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] Reset password on Patchwork
On 12 Jun 2024, at 1:45, Sean McGovern wrote: > Hi, > > Can someone help me reset my password on Patchwork? I've used the 'Forgot > password ' link several times and never received an email. IIRC patchwork can not send emails, I had the same issue a while ago but Andriy should be able to manually do it for you. > > -- Sean McGovern > ___ > 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] doc/faq: Provide information about git send-email and gmail
On 12 Jun 2024, at 19:46, Michael Niedermayer wrote:
> The 2 links are the clearest i found.
>
> Signed-off-by: Michael Niedermayer
> ---
> doc/faq.texi | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/doc/faq.texi b/doc/faq.texi
> index 477cc60533a..d07ed533dd7 100644
> --- a/doc/faq.texi
> +++ b/doc/faq.texi
> @@ -683,4 +683,9 @@ Do you happen to have a @code{~} character in the samples
> path to indicate a
> home directory? The value is used in ways where the shell cannot expand it,
> causing FATE to not find files. Just replace @code{~} by the full path.
>
> +@section How to setup git send-email?
> +
> +Please see @url{https://git-send-email.io/}.
> +For gmail additionally see
> @url{https://shallowsky.com/blog/tech/email/gmail-app-passwds.html}.
> +
> @bye
Good idea, maybe we should link to https://sr.ht/~emersion/pyonji/ as well
which IMHO
simplifies things a lot when someone is used to a feature-branch workflow.
> --
> 2.45.2
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avutil/hwcontext_videotoolbox: Set proper CVBuffer colorspace
On 23 May 2024, at 18:05, Zhao Zhili wrote:
>> On May 21, 2024, at 09:56, Gnattu OC via ffmpeg-devel
>> wrote:
>>
>>>
>>> On May 20, 2024, at 09:12, Marvin Scholz wrote:
>>>
>>> Fix #10884
>>> ---
>>> libavutil/hwcontext_videotoolbox.c | 54 +-
>>> 1 file changed, 38 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/libavutil/hwcontext_videotoolbox.c
>>> b/libavutil/hwcontext_videotoolbox.c
>>> index 9f82b104c3..4a35bfc7ff 100644
>>> --- a/libavutil/hwcontext_videotoolbox.c
>>> +++ b/libavutil/hwcontext_videotoolbox.c
>>> @@ -530,6 +530,8 @@ CFStringRef av_map_videotoolbox_color_trc_from_av(enum
>>> AVColorTransferCharacteri
>>> static int vt_pixbuf_set_colorspace(void *log_ctx,
>>>CVPixelBufferRef pixbuf, const AVFrame
>>> *src)
>>> {
>>> +CGColorSpaceRef colorspace = NULL;
>>> +CFMutableDictionaryRef attachments = NULL;
>>>CFStringRef colormatrix = NULL, colorpri = NULL, colortrc = NULL;
>>>Float32 gamma = 0;
>>>
>>> @@ -550,37 +552,57 @@ static int vt_pixbuf_set_colorspace(void *log_ctx,
>>>else if (src->color_trc == AVCOL_TRC_GAMMA28)
>>>gamma = 2.8;
>>>
>>> +attachments = CFDictionaryCreateMutable(NULL, 0,
>>> +
>>> &kCFTypeDictionaryKeyCallBacks,
>>> +
>>> &kCFTypeDictionaryValueCallBacks);
>>> +if (!attachments)
>>> +return AVERROR(ENOMEM);
>>> +
>>>if (colormatrix) {
>>> -CVBufferSetAttachment(
>>> -pixbuf,
>>> +CFDictionarySetValue(
>>> +attachments,
>>>kCVImageBufferYCbCrMatrixKey,
>>> -colormatrix,
>>> -kCVAttachmentMode_ShouldPropagate);
>>> +colormatrix);
>>>}
>>>if (colorpri) {
>>> -CVBufferSetAttachment(
>>> -pixbuf,
>>> +CFDictionarySetValue(
>>> +attachments,
>>>kCVImageBufferColorPrimariesKey,
>>> -colorpri,
>>> -kCVAttachmentMode_ShouldPropagate);
>>> +colorpri);
>>>}
>>>if (colortrc) {
>>> -CVBufferSetAttachment(
>>> -pixbuf,
>>> +CFDictionarySetValue(
>>> +attachments,
>>>kCVImageBufferTransferFunctionKey,
>>> -colortrc,
>>> -kCVAttachmentMode_ShouldPropagate);
>>> +colortrc);
>>>}
>>>if (gamma != 0) {
>>>CFNumberRef gamma_level = CFNumberCreate(NULL, kCFNumberFloat32Type,
>>> &gamma);
>>> -CVBufferSetAttachment(
>>> -pixbuf,
>>> +CFDictionarySetValue(
>>> +attachments,
>>>kCVImageBufferGammaLevelKey,
>>> -gamma_level,
>>> -kCVAttachmentMode_ShouldPropagate);
>>> +gamma_level);
>>>CFRelease(gamma_level);
>>>}
>>>
>>> +if (__builtin_available(macOS 10.8, iOS 10, *))
>>> +colorspace =
>>> CVImageBufferCreateColorSpaceFromAttachments(attachments);
>>> +
>>> +if (colorspace) {
>>> +CFDictionarySetValue(
>>> +attachments,
>>> +kCVImageBufferCGColorSpaceKey,
>>> +colorspace);
>>> +CFRelease(colorspace);
>>> +} else
>>> +av_log(log_ctx, AV_LOG_WARNING, "Unable to set proper colorspace
>>> for the CVImageBuffer.\n");
>>
>> This will spam the console on SDR video inputs because they have nothing to
>> be set as the attachment and the colorspace creation will always fail and
>> return nil.
>
> I will just remove the log message and apply the patch this week if no
> objection.
>
I will do some more tests, if you want apply with the log message removed and I
will do a follow up patch
if I find another solution.
>>
>>> +
>>> +CVBufferSetAttachments(
>>> +pixbuf,
>>> +attachments,
>>> +kCVAttachmentMode_ShouldPropagate);
>>> +CFRelease(attachments);
>>> +
>>>return 0;
>>> }
>>>
>>>
>>> base-commit: 463c573e6b6489c588bee90124d5cf92db8ccaaa
>>> --
>>> 2.39.3 (Apple Git-145)
>>> ___
>>> 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 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/6] avcodec/lib*, avformat/tee: Simplify iterating over AVDictionary
On 17 May 2024, at 17:44, Andreas Rheinhardt wrote:
> epira...@gmail.com:
>>
>>
>> On 17 May 2024, at 17:25, Andreas Rheinhardt wrote:
>>
>>> Signed-off-by: Andreas Rheinhardt
>>> ---
>>> libavcodec/libaomenc.c | 4 ++--
>>> libavcodec/libkvazaar.c | 4 ++--
>>> libavcodec/libsvtav1.c | 6 +++---
>>> libavcodec/libx264.c| 4 ++--
>>> libavcodec/libx265.c| 4 ++--
>>> libavformat/tee.c | 4 ++--
>>> 6 files changed, 13 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
>>> index c39853c20f..dec74ebecd 100644
>>> --- a/libavcodec/libaomenc.c
>>> +++ b/libavcodec/libaomenc.c
>>> @@ -970,9 +970,9 @@ static av_cold int aom_init(AVCodecContext *avctx,
>>>
>>> #if AOM_ENCODER_ABI_VERSION >= 23
>>> {
>>> -AVDictionaryEntry *en = NULL;
>>> +const AVDictionaryEntry *en = NULL;
>>>
>>> -while ((en = av_dict_get(ctx->aom_params, "", en,
>>> AV_DICT_IGNORE_SUFFIX))) {
>>> +while ((en = av_dict_iterate(ctx->aom_params, en))) {
>>> int ret = aom_codec_set_option(&ctx->encoder, en->key,
>>> en->value);
>>> if (ret != AOM_CODEC_OK) {
>>> log_encoder_error(avctx, en->key);
>>> diff --git a/libavcodec/libkvazaar.c b/libavcodec/libkvazaar.c
>>> index 0711d9ab38..cd731ae9d0 100644
>>> --- a/libavcodec/libkvazaar.c
>>> +++ b/libavcodec/libkvazaar.c
>>> @@ -111,8 +111,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
>>> if (ctx->kvz_params) {
>>> AVDictionary *dict = NULL;
>>> if (!av_dict_parse_string(&dict, ctx->kvz_params, "=", ",", 0)) {
>>> -AVDictionaryEntry *entry = NULL;
>>> -while ((entry = av_dict_get(dict, "", entry,
>>> AV_DICT_IGNORE_SUFFIX))) {
>>> +const AVDictionaryEntry *entry = NULL;
>>> +while ((entry = av_dict_iterate(dict, entry))) {
>>> if (!api->config_parse(cfg, entry->key, entry->value)) {
>>> av_log(avctx, AV_LOG_WARNING, "Invalid option:
>>> %s=%s.\n",
>>> entry->key, entry->value);
>>> diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
>>> index 9bc165f0cf..2fef8c8971 100644
>>> --- a/libavcodec/libsvtav1.c
>>> +++ b/libavcodec/libsvtav1.c
>>> @@ -210,7 +210,7 @@ static int config_enc_params(EbSvtAv1EncConfiguration
>>> *param,
>>> {
>>> SvtContext *svt_enc = avctx->priv_data;
>>> const AVPixFmtDescriptor *desc;
>>> -AVDictionaryEntry *en = NULL;
>>> +const AVDictionaryEntry av_unused *en = NULL;
>>>
>>> // Update param from options
>>> if (svt_enc->enc_mode >= -1)
>>> @@ -326,7 +326,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
>>> handle_side_data(avctx, param);
>>>
>>> #if SVT_AV1_CHECK_VERSION(0, 9, 1)
>>> -while ((en = av_dict_get(svt_enc->svtav1_opts, "", en,
>>> AV_DICT_IGNORE_SUFFIX))) {
>>> +while ((en = av_dict_iterate(svt_enc->svtav1_opts, en))) {
>>> EbErrorType ret = svt_av1_enc_parse_parameter(param, en->key,
>>> en->value);
>>> if (ret != EB_ErrorNone) {
>>> int level = (avctx->err_recognition & AV_EF_EXPLODE) ?
>>> AV_LOG_ERROR : AV_LOG_WARNING;
>>> @@ -336,7 +336,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
>>> }
>>> }
>>> #else
>>> -if ((en = av_dict_get(svt_enc->svtav1_opts, "", NULL,
>>> AV_DICT_IGNORE_SUFFIX))) {
>>> +if (av_dict_count(svt_enc->svtav1_opts)) {
>>> int level = (avctx->err_recognition & AV_EF_EXPLODE) ?
>>> AV_LOG_ERROR : AV_LOG_WARNING;
>>> av_log(avctx, level, "svt-params needs libavcodec to be compiled
>>> with SVT-AV1 "
>>> "headers >= 0.9.1.\n");
>>> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
>>> index 2715f277f1..29d1a7ccbc 100644
>>> --- a/libavcodec/libx264.c
>>> +++ b/libavcodec/libx264.c
>>> @@ -1385,8 +1385,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
>>> x4->params.b_repeat_headers = 1;
>>>
>>> {
>>> -AVDictionaryEntry *en = NULL;
>>> -while (en = av_dict_get(x4->x264_params, "", en,
>>> AV_DICT_IGNORE_SUFFIX)) {
>>> +const AVDictionaryEntry *en = NULL;
>>> +while (en = av_dict_iterate(x4->x264_params, en)) {
>>
>> Missing pair of braces to make the compiler not warn about assignment in
>> check, no?
>>
>
> I did not change the parentheses in this patch at all as doing so would
> be orthogonal to the patch. We use this style without the additional
> pair of parentheses everywhere and actually add -Wno-parentheses in
> configure (line 7429).
Indeed sorry, I had pulled parts of AVDict out of tree when I did a bunch of
work
on it a while ago to easier test a lot of edge cases and debug things.
Any reason why we silence this, as just adding a pair of braces to make intent
clearer vs accidentally doing it wrong somewhere seems worth it…
Anyway, LGTM then for this patch, sorry for the noise.
>
>>> if ((ret = x264_param_parse(&x4->params, en->key, en->value)) <
>>> 0) {
>>>
Re: [FFmpeg-devel] [PATCH 3/6] avformat/tee: Constify AVDictionaryEntry* pointee where possible
On 17 May 2024, at 17:25, Andreas Rheinhardt wrote:
> This is in preparation for using av_dict_iterate().
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/tee.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/tee.c b/libavformat/tee.c
> index 1cbbb80dbb..87159681ed 100644
> --- a/libavformat/tee.c
> +++ b/libavformat/tee.c
> @@ -158,7 +158,7 @@ static int open_slave(AVFormatContext *avf, char *slave,
> TeeSlave *tee_slave)
> {
> int i, ret;
> AVDictionary *options = NULL, *bsf_options = NULL;
> -AVDictionaryEntry *entry;
> +const AVDictionaryEntry *entry;
> char *filename;
> char *format = NULL, *select = NULL, *on_fail = NULL;
> char *use_fifo = NULL, *fifo_options_str = NULL;
> @@ -172,8 +172,9 @@ static int open_slave(AVFormatContext *avf, char *slave,
> TeeSlave *tee_slave)
> return ret;
>
> #define CONSUME_OPTION(option, field, action) do { \
> -if ((entry = av_dict_get(options, option, NULL, 0))) { \
> -field = entry->value; \
> +AVDictionaryEntry *en = av_dict_get(options, option, NULL, 0); \
> +if (en) { \
> +field = en->value; \
> { action } \
> av_dict_set(&options, option, NULL, 0); \
> } \
> --
> 2.40.1
>
LGTM, thanks!
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
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/6] avcodec/lib*, avformat/tee: Simplify iterating over AVDictionary
On 17 May 2024, at 17:25, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/libaomenc.c | 4 ++--
> libavcodec/libkvazaar.c | 4 ++--
> libavcodec/libsvtav1.c | 6 +++---
> libavcodec/libx264.c| 4 ++--
> libavcodec/libx265.c| 4 ++--
> libavformat/tee.c | 4 ++--
> 6 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
> index c39853c20f..dec74ebecd 100644
> --- a/libavcodec/libaomenc.c
> +++ b/libavcodec/libaomenc.c
> @@ -970,9 +970,9 @@ static av_cold int aom_init(AVCodecContext *avctx,
>
> #if AOM_ENCODER_ABI_VERSION >= 23
> {
> -AVDictionaryEntry *en = NULL;
> +const AVDictionaryEntry *en = NULL;
>
> -while ((en = av_dict_get(ctx->aom_params, "", en,
> AV_DICT_IGNORE_SUFFIX))) {
> +while ((en = av_dict_iterate(ctx->aom_params, en))) {
> int ret = aom_codec_set_option(&ctx->encoder, en->key,
> en->value);
> if (ret != AOM_CODEC_OK) {
> log_encoder_error(avctx, en->key);
> diff --git a/libavcodec/libkvazaar.c b/libavcodec/libkvazaar.c
> index 0711d9ab38..cd731ae9d0 100644
> --- a/libavcodec/libkvazaar.c
> +++ b/libavcodec/libkvazaar.c
> @@ -111,8 +111,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
> if (ctx->kvz_params) {
> AVDictionary *dict = NULL;
> if (!av_dict_parse_string(&dict, ctx->kvz_params, "=", ",", 0)) {
> -AVDictionaryEntry *entry = NULL;
> -while ((entry = av_dict_get(dict, "", entry,
> AV_DICT_IGNORE_SUFFIX))) {
> +const AVDictionaryEntry *entry = NULL;
> +while ((entry = av_dict_iterate(dict, entry))) {
> if (!api->config_parse(cfg, entry->key, entry->value)) {
> av_log(avctx, AV_LOG_WARNING, "Invalid option: %s=%s.\n",
> entry->key, entry->value);
> diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
> index 9bc165f0cf..2fef8c8971 100644
> --- a/libavcodec/libsvtav1.c
> +++ b/libavcodec/libsvtav1.c
> @@ -210,7 +210,7 @@ static int config_enc_params(EbSvtAv1EncConfiguration
> *param,
> {
> SvtContext *svt_enc = avctx->priv_data;
> const AVPixFmtDescriptor *desc;
> -AVDictionaryEntry *en = NULL;
> +const AVDictionaryEntry av_unused *en = NULL;
>
> // Update param from options
> if (svt_enc->enc_mode >= -1)
> @@ -326,7 +326,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
> handle_side_data(avctx, param);
>
> #if SVT_AV1_CHECK_VERSION(0, 9, 1)
> -while ((en = av_dict_get(svt_enc->svtav1_opts, "", en,
> AV_DICT_IGNORE_SUFFIX))) {
> +while ((en = av_dict_iterate(svt_enc->svtav1_opts, en))) {
> EbErrorType ret = svt_av1_enc_parse_parameter(param, en->key,
> en->value);
> if (ret != EB_ErrorNone) {
> int level = (avctx->err_recognition & AV_EF_EXPLODE) ?
> AV_LOG_ERROR : AV_LOG_WARNING;
> @@ -336,7 +336,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
> }
> }
> #else
> -if ((en = av_dict_get(svt_enc->svtav1_opts, "", NULL,
> AV_DICT_IGNORE_SUFFIX))) {
> +if (av_dict_count(svt_enc->svtav1_opts)) {
> int level = (avctx->err_recognition & AV_EF_EXPLODE) ? AV_LOG_ERROR
> : AV_LOG_WARNING;
> av_log(avctx, level, "svt-params needs libavcodec to be compiled
> with SVT-AV1 "
> "headers >= 0.9.1.\n");
> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> index 2715f277f1..29d1a7ccbc 100644
> --- a/libavcodec/libx264.c
> +++ b/libavcodec/libx264.c
> @@ -1385,8 +1385,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
> x4->params.b_repeat_headers = 1;
>
> {
> -AVDictionaryEntry *en = NULL;
> -while (en = av_dict_get(x4->x264_params, "", en,
> AV_DICT_IGNORE_SUFFIX)) {
> +const AVDictionaryEntry *en = NULL;
> +while (en = av_dict_iterate(x4->x264_params, en)) {
Missing pair of braces to make the compiler not warn about assignment in check,
no?
> if ((ret = x264_param_parse(&x4->params, en->key, en->value)) <
> 0) {
> av_log(avctx, AV_LOG_WARNING,
>"Error parsing option '%s = %s'.\n",
> diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
> index c4ce5d..ac1dbc4f97 100644
> --- a/libavcodec/libx265.c
> +++ b/libavcodec/libx265.c
> @@ -495,8 +495,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
> }
>
> {
> -AVDictionaryEntry *en = NULL;
> -while ((en = av_dict_get(ctx->x265_opts, "", en,
> AV_DICT_IGNORE_SUFFIX))) {
> +const AVDictionaryEntry *en = NULL;
> +while ((en = av_dict_iterate(ctx->x265_opts, en))) {
> int parse_ret = ctx->api->param_parse(ctx->params, en->key,
> en->value);
>
> switch (parse_ret) {
> diff --git a/libavformat/tee.c b/libavformat/tee.c
> index 0c0543fa65..1a2a8ead82 100644
> --- a/libavformat/tee.c
> +++ b/libavformat/tee.c
> @@ -313,7 +313,7 @@ static int open_slave(AVForma
Re: [FFmpeg-devel] [PATCH 6/6] fftools, avfilter, avformat: Simplify check for "is dictionary empty?"
On 17 May 2024, at 17:25, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> fftools/ffmpeg.c | 4 ++--
> fftools/ffplay.c | 4 ++--
> fftools/ffprobe.c | 2 +-
> libavfilter/avfilter.c | 4 ++--
> libavformat/aacdec.c | 2 +-
> libavformat/http.c | 8
> libavformat/mpc.c | 2 +-
> libavformat/oggenc.c | 2 +-
> libavformat/wvdec.c| 2 +-
> 9 files changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index 1f50ed6805..c86fd5065e 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -484,8 +484,8 @@ void remove_avoptions(AVDictionary **a, AVDictionary *b)
>
> int check_avoptions(AVDictionary *m)
> {
> -const AVDictionaryEntry *t;
> -if ((t = av_dict_get(m, "", NULL, AV_DICT_IGNORE_SUFFIX))) {
> +const AVDictionaryEntry *t = av_dict_iterate(m, NULL);
> +if (t) {
> av_log(NULL, AV_LOG_FATAL, "Option %s not found.\n", t->key);
> return AVERROR_OPTION_NOT_FOUND;
> }
> diff --git a/fftools/ffplay.c b/fftools/ffplay.c
> index b9d11eecee..5a66bfa38d 100644
> --- a/fftools/ffplay.c
> +++ b/fftools/ffplay.c
> @@ -2694,7 +2694,7 @@ static int stream_component_open(VideoState *is, int
> stream_index)
> if ((ret = avcodec_open2(avctx, codec, &opts)) < 0) {
> goto fail;
> }
> -if ((t = av_dict_get(opts, "", NULL, AV_DICT_IGNORE_SUFFIX))) {
> +if ((t = av_dict_iterate(opts, NULL))) {
> av_log(NULL, AV_LOG_ERROR, "Option %s not found.\n", t->key);
> ret = AVERROR_OPTION_NOT_FOUND;
> goto fail;
> @@ -2862,7 +2862,7 @@ static int read_thread(void *arg)
> if (scan_all_pmts_set)
> av_dict_set(&format_opts, "scan_all_pmts", NULL, AV_DICT_MATCH_CASE);
>
> -if ((t = av_dict_get(format_opts, "", NULL, AV_DICT_IGNORE_SUFFIX))) {
> +if ((t = av_dict_iterate(format_opts, NULL))) {
> av_log(NULL, AV_LOG_ERROR, "Option %s not found.\n", t->key);
> ret = AVERROR_OPTION_NOT_FOUND;
> goto fail;
> diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
> index 5b40dad527..2d38e5dfdc 100644
> --- a/fftools/ffprobe.c
> +++ b/fftools/ffprobe.c
> @@ -3951,7 +3951,7 @@ static int open_input_file(InputFile *ifile, const char
> *filename,
> exit(1);
> }
>
> -if ((t = av_dict_get(opts, "", NULL, AV_DICT_IGNORE_SUFFIX))) {
> +if ((t = av_dict_iterate(opts, NULL))) {
> av_log(NULL, AV_LOG_ERROR, "Option %s for input stream %d
> not found\n",
> t->key, stream->index);
> return AVERROR_OPTION_NOT_FOUND;
> diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
> index 049e4f62ca..2dc8820184 100644
> --- a/libavfilter/avfilter.c
> +++ b/libavfilter/avfilter.c
> @@ -941,7 +941,7 @@ int avfilter_init_dict(AVFilterContext *ctx, AVDictionary
> **options)
> int avfilter_init_str(AVFilterContext *filter, const char *args)
> {
> AVDictionary *options = NULL;
> -AVDictionaryEntry *e;
> +const AVDictionaryEntry *e;
> int ret = 0;
>
> if (args && *args) {
> @@ -954,7 +954,7 @@ int avfilter_init_str(AVFilterContext *filter, const char
> *args)
> if (ret < 0)
> goto fail;
>
> -if ((e = av_dict_get(options, "", NULL, AV_DICT_IGNORE_SUFFIX))) {
> +if ((e = av_dict_iterate(options, NULL))) {
> av_log(filter, AV_LOG_ERROR, "No such option: %s.\n", e->key);
> ret = AVERROR_OPTION_NOT_FOUND;
> goto fail;
> diff --git a/libavformat/aacdec.c b/libavformat/aacdec.c
> index e267886e1a..a8be251815 100644
> --- a/libavformat/aacdec.c
> +++ b/libavformat/aacdec.c
> @@ -119,7 +119,7 @@ static int adts_aac_read_header(AVFormatContext *s)
>
> ff_id3v1_read(s);
> if ((s->pb->seekable & AVIO_SEEKABLE_NORMAL) &&
> -!av_dict_get(s->metadata, "", NULL, AV_DICT_IGNORE_SUFFIX)) {
> +!av_dict_count(s->metadata)) {
> int64_t cur = avio_tell(s->pb);
> ff_ape_parse_tag(s);
> avio_seek(s->pb, cur, SEEK_SET);
> diff --git a/libavformat/http.c b/libavformat/http.c
> index 1a67068a44..ec60bc0b17 100644
> --- a/libavformat/http.c
> +++ b/libavformat/http.c
> @@ -990,7 +990,7 @@ static int parse_set_cookie(const char *set_cookie,
> AVDictionary **dict)
> static int parse_cookie(HTTPContext *s, const char *p, AVDictionary
> **cookies)
> {
> AVDictionary *new_params = NULL;
> -AVDictionaryEntry *e, *cookie_entry;
> +const AVDictionaryEntry *e, *cookie_entry;
> char *eql, *name;
>
> // ensure the cookie is parsable
> @@ -998,7 +998,7 @@ static int parse_cookie(HTTPContext *s, const char *p,
> AVDictionary **cookies)
> return -1;
>
> // if there is no cookie value there is nothing to parse
> -cookie_entry = av_dict_get(new_params, "", NULL, AV_DICT_IGNORE_SUFFIX);
> +cookie_entry = av_dict_iterate(new_params, NULL);
> if (!cookie_entry || !cookie_e
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On 4 May 2024, at 23:25, Andrew Sayers wrote: > On Sat, May 04, 2024 at 09:28:03PM +0200, Michael Niedermayer wrote: >> Hi >> >> On Fri, May 03, 2024 at 03:45:20PM +, Cosmin Stejerean via ffmpeg-devel >> wrote: >> [...] >>> What doesn't exist (yet) is a way to keep people on the exact email based >>> workflow >>> we currently have, and have bi-directional sync with something like github >>> or gitlab. >>> Such a thing could probably be built, but it might be worth first trying to >>> see if those >>> that insist on sticking with the CLI can use one of the existing CLI based >>> workflows. >> >> Such a thing could be quite useful to many more projects than just ffmpeg. >> There are many older projects that use ML based workflows. >> >> I imagine STF might be willing to fund such a thing if it is technically >> feasable. As the goal of STF is about maintainance. And bridging the gap >> between old ML and new browser based workflows allowing developers who >> prefer to work through their web browser to do so. >> >> also, we need to find maintaince related projects worth minimum 150k € >> for 2025 for STF. >> We cant do many of the things we do in 2024 for STF again as they where >> one time things and STF doesnt like sponsoring adding new features. >> >> thx > > It seems like the strongest argument for sticking with the ML is from > experienced maintainers who don't want to jeopardise their existing > workflow; while the strongest argument for switching is from people > itching to try out new workflows. So how about this for a plan... > > Make a repo on SourceHut, not necessarily for FFmpeg itself but for > automated review tools (running fate tests, checking C11 compliance > etc.). Their CI/CD system automatically runs those tests on every > patch, then we manually forward genuine issues to the ML. That would > let experimenters show off new things, and would let maintainers > think through what their workflow would look like in a mixed > environment. Then when we've got enough evidence to make a long-term > plan, we can wind the repo down without too much fuss. I hardly see how SourceHut would improve much of any of the actual struggles we talked about in this thread tbh… FWIW what most people are desiring is better review workflow/tooling than a mail client can not offer (easily) and making it easier for people to contribute by simply pushing a branch to their fork which is for better or worse what a lot of people are familiar with from GitHub. Both of which is nothing SourceHut offers, to my knowledge. So rather than spend efforts on something that only marginally improves upon what is currently used it would IMHO be way more useful to evaluate something like GitLab or Gitea/Forgejo. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On 2 May 2024, at 21:32, Ondřej Fiala wrote:
> On Thu May 2, 2024 at 4:38 PM CEST, Rémi Denis-Courmont wrote:
>> Le torstaina 2. toukokuuta 2024, 17.25.06 EEST Ondřej Fiala a écrit :
>>> On Wed May 1, 2024 at 7:27 AM CEST, Rémi Denis-Courmont wrote:
I don't use Gmail, and using email for review still sucks. No matter how
you slice it, email was not meant for threaded code reviews.
>>>
>>> Email was not meant for a lot of what it's used for today.
>>
>> And Gitlab and Github are meant for what they are used.
>> That's the whole point.
> This argument can actually go in both directions since the Web and web
> browsers weren't meant for performing code review either. If you remember,
> the Web was originally intended for sharing *documents*, which a MR page
> on GitLab definitely isn't.
>
> IMHO, the fact that something was intended for some use case does not imply
> that it's actually good for that use case. My point was that what it was
> meant for does not matter, what's important is if and how well it works
> for that use case.
>
>>> and unlike GitHub allow threads of arbitrary depth.
>>
>> I don't care because *GitHub* is out of the race for other reasons anyway. I
>> have never had a situation whence *Gitlab* refused to add more comments to a
>> thread.
> I said *depth*, not *length*. AFAIK GitLab can't create message threads like:
>
> message
> |- reply
> | |- reply
> | | '- reply
> | '- reply
> '- reply
> '- reply
>
>>> Using such a client with commands for moving between
>>> messages in a a thread etc. makes threaded code review over email quite
>>> usably in my opinion.
>>
>> So how do I ask my mail agent to pull more existing code for context? Or to
>> get back to the code that started a thread?
> Why would you do that in a mail client? You have your personal copy of the
> repo, so you can just import the patch by piping it to `git am` and then
> use any of the wide array of git-supporting *specialized code review software*
> to look at the changes!
How do I see the review comments that way?
>
> Of course, the quality of your toolings matters a lot. If your email client
> can't pipe a bunch of emails to a shell command, it's not fit for being used
> to review git patches. On the other hand, if you possess just some basic shell
> scripting skills, you can make it do pretty cool things.
So I first have to get proficient in some shell scripting gymnastics
(and also switch to a completely different terminal-based mail client)
so I can do proper reviews?
Thats incredibly gatekeeping.
>
> Since you felt that there is no way to see additional context, I put together
> a quick demo[1] showing how easily you can review all files affected by a
> patch
> and look at *all* the context. Of course, you could do a bunch of other
> things to
> adjust the email-based workflow as desired. And don't forget this is just a
> demo;
> I am sure you could come up with something better.
>
> [1] https://paste.c-net.org/HansenWeekends
That seems to download some binary file? I have no idea what it is supposed to
be.
>
> It's just sway, aerc, and a fuzzy picker combined. The command "changes" is
> just:
> changes() {
> while p="$(git diff --name-only origin/master | pick)"; do
> git diff -U999 origin/master "$p"
> done
> }
>
Also while I can use git-send-email, not everyone can. And patches as
attachments are simply awful. Unfortunately I can't dictate that people
don't send patches that way.
>>>
>>> How can anyone use git, but not git send-email? Any decent email provider
>>> has support for external clients over SMTP.
>>
>> Simply put: no, that is simply not true.
>>
>> Not everybody can pick a decent email provider with outbound SMTP and a good
>> reputation. Also not everybody gets to pick their mail agent or their ISP.
>>
>> You are just being unwittingly elistist here.
> I must admit I did not realize how bad some email/internet providers can be
> when writing this, as I have a fairly average setup and never ran into such
> issues.
>
> But the problem with accessibility is not aleviated by switching away from
> email, since those forges aren't universally accessible either. I remember how
> I used to run Pale Moon like 2 years ago. In case you don't know, it's a
> Firefox
> fork maintained by a small team. GitHub didn't run on it. Oh, sorry, you don't
> care about GitHub. But they share the same desig -- hugely complex "web app"
> that only runs on latest version of major browsers. Everyone else is excluded.
> When I wanted to contribute to a project I really cared about, I had to
> download
> mainline Firefox and do it over that. If I cared even a bit less about it, I
> wouldn't bother.
>
> So how is that any different?
How is it different to download a well maintained recent software and open a
website,
in comparison to learn how to setup a (complex) combination of tools just to be
able
to easily contribute?
>
> I think th
Re: [FFmpeg-devel] [PATCH 1/6] avutil/frame: add av_frame_remove_side_data_changed
On 26 Apr 2024, at 14:27, Niklas Haas wrote:
> From: Niklas Haas
>
> Many filters modify certain aspects of frame data, e.g. through resizing
> (vf_*scale* family), color volume mapping (vf_lut*, vf_tonemap*), or
> possibly others.
>
> When this happens, we should strip all frame side data that will no
> longer be correct/relevant after the operation. For example, changing
> the image size should invalidate AV_FRAME_DATA_PANSCAN because the crop
> window (given in pixels) no longer corresponds to the actual image size.
> For another example, tone-mapping filters (e.g. from HDR to SDR) should
> strip all of the dynamic HDR related metadata.
>
> Since there are a lot of similar with basically similar operations, it
> make sense to consolidate this stripping logic into a common helper
> function. I decided to put it into libavutil as it may be useful for API
> users as well, who often have their own internal processing and
> filtering.
> ---
> doc/APIchanges | 3 +++
> libavutil/frame.c | 31 +++
> libavutil/frame.h | 14 ++
> libavutil/version.h | 2 +-
> 4 files changed, 49 insertions(+), 1 deletion(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 0566fcdcc5..26af725528 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -2,6 +2,9 @@ The last version increases of all libraries were on 2024-03-07
>
> API changes, most recent first:
>
> +2024-04-xx - xx - lavu 59.17.100 - frame.h
> + Add av_frame_remove_side_data_changed().
> +
> 2024-04-24 - 8616cfe0890 - lavu 59.16.100 - opt.h
>Add AV_OPT_SERIALIZE_SEARCH_CHILDREN.
>
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index 0775e2abd9..d5482c258e 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.c
> @@ -1015,6 +1015,37 @@ void av_frame_remove_side_data(AVFrame *frame, enum
> AVFrameSideDataType type)
> remove_side_data(&frame->side_data, &frame->nb_side_data, type);
> }
>
> +static const struct {
> +enum AVFrameSideDataType type;
> +int aspect;
> +} side_data_aspects[] = {
> +{ AV_FRAME_DATA_PANSCAN,AV_FRAME_CHANGED_SIZE },
> +{ AV_FRAME_DATA_MOTION_VECTORS, AV_FRAME_CHANGED_SIZE },
> +{ AV_FRAME_DATA_MASTERING_DISPLAY_METADATA,
> AV_FRAME_CHANGED_COLOR_VOLUME },
> +
> +{ AV_FRAME_DATA_SPHERICAL, AV_FRAME_CHANGED_SIZE },
> +{ AV_FRAME_DATA_CONTENT_LIGHT_LEVEL,
> AV_FRAME_CHANGED_COLOR_VOLUME },
> +{ AV_FRAME_DATA_ICC_PROFILE,
> AV_FRAME_CHANGED_COLOR_VOLUME },
> +{ AV_FRAME_DATA_DYNAMIC_HDR_PLUS,
> AV_FRAME_CHANGED_COLOR_VOLUME },
> +{ AV_FRAME_DATA_REGIONS_OF_INTEREST,AV_FRAME_CHANGED_SIZE },
> +{ AV_FRAME_DATA_DETECTION_BBOXES, AV_FRAME_CHANGED_SIZE },
> +{ AV_FRAME_DATA_DOVI_RPU_BUFFER,
> AV_FRAME_CHANGED_COLOR_VOLUME },
> +{ AV_FRAME_DATA_DOVI_METADATA,
> AV_FRAME_CHANGED_COLOR_VOLUME },
> +{ AV_FRAME_DATA_DYNAMIC_HDR_VIVID,
> AV_FRAME_CHANGED_COLOR_VOLUME },
> +{ AV_FRAME_DATA_VIDEO_HINT, AV_FRAME_CHANGED_SIZE },
> +};
> +
> +void av_frame_remove_side_data_changed(AVFrame *frame, int changed_aspects)
> +{
> +if (!changed_aspects)
> +return;
> +
> +for (int i = 0; i < FF_ARRAY_ELEMS(side_data_aspects); i++) {
> +if (changed_aspects & side_data_aspects[i].aspect)
> +av_frame_remove_side_data(frame, side_data_aspects[i].type);
> +}
> +}
> +
> const AVSideDataDescriptor *av_frame_side_data_desc(enum AVFrameSideDataType
> type)
> {
> unsigned t = type;
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index 60bb966f8b..7e07ecf91f 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -983,6 +983,20 @@ AVFrameSideData *av_frame_get_side_data(const AVFrame
> *frame,
> */
> void av_frame_remove_side_data(AVFrame *frame, enum AVFrameSideDataType
> type);
>
> +/**
> + * Flags for stripping side data based on changed aspects.
> + */
> +enum {
> +/* Video only */
> +AV_FRAME_CHANGED_SIZE = 1 << 0, ///< changed dimensions / crop
> +AV_FRAME_CHANGED_COLOR_VOLUME = 1 << 1, ///< changed color volume
> +};
Maybe give the enum a name so you can properly link to it in the docs?
I guess using the enum type instead of int in the fuction parameter
is not really allowed because it can be other values than the enum
has, by combining flags, which I guess is not allowed by the C standard?
> +
> +/**
> + * Remove all relevant side data after a corresponding change to the frame
> + * data, based on the given bitset of frame aspects.
> + */
> +void av_frame_remove_side_data_changed(AVFrame *frame, int changed_aspects);
>
> /**
> * Flags for frame cropping.
> diff --git a/libavutil/version.h b/libavutil/version.h
> index ea289c406f..3b5a2e7aaa 100644
> --- a/libavutil/version.h
> +++ b/libavutil/version.h
> @@ -79,7 +79,7 @@
> */
>
> #define LIBAVUTIL_VERSION_MAJOR 59
>
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On 19 Apr 2024, at 16:50, Niklas Haas wrote: > On Thu, 18 Apr 2024 22:53:51 +0200 Michael Niedermayer > wrote: >> A plugin system moves this patch-management to people who actually >> care, that is the authors of the codecs and (de)muxers. > > A plugin system will only solve this insomuch as plugin authors will > just host their plugin code on GitHub instead of bothering with the > mailing list. > > I think it runs a good risk of basically killing the project. > >> Our productivity as is, is not good, many patches are ignored. >> The people caring about these patches are their Authors and yet they >> are powerless as they must sometimes wait many months for reviews > > So, rather than all of the above, what I think we should do is contract > somebody to set up, manage, host and maintain a GitLab instance for us. > > This would probably be the single most cost effective boost to both > community growth and innovation I can think of, as it will remove > several of the major grievances and barriers to entry with the > ML+pingspam model. I agree with that. IMO extending patchwork while possible is just a stopgap measure and requires quite a bit of effort too that is probably better spent elsewhere. Using Trac to manage patches additionally just adds even more inconsistent places to have patch info that go out of sync with reality like patchwork already does… I am by no means a die hard GitLab fan, quite the contrary, but I still believe it is a vast improvement over the Mailing List workflow and if there are shortcomings in the tooling so that some peoples workflows can continue to work, efforts are probably better spent overcoming these, rather than „beating a dead horse“ (patching Patchwork). > > We can use a system like VLC's auto-merge bot, where any MR that has at > least one developer approval, no unresolved issues, and no activity for > N days gets *automatically* merged. Just to clarify, it does not automatically merge but rather tags them and a maintainer still does the actual merge. > > I'm sure that if we try, we can find an interested party willing to fund > this. (Maybe SPI?) > >> Besides that, developers are leaving for various reasons and they >> are forced to setup full forks not being able to maintain their >> code in any other way. >> IMO A plugin system would improve productivity as everyone could work >> on their own terms. >> No week or month long delays and weekly pinging patches >> No risk about patches being rejected or ignored >> No need to read every other discussion on the ML. One can just >> simply work on their own plugin looking just at the API documentation >> ... >> >> >> >>> * ffchat (expand into realtime chat / zoom) this would bring in more users and developers, and we basically have almost all parts for it already but some people where against it >>> >>> This seems like a user application on top of FFmpeg, not something that >>> should be part of FFmpeg core. Can you explain what modifications in >>> FFmpeg would be necessary for something like this? >> >> ffmpeg, ffplay, ffprobe are also user applications. >> >> >>> * client side / in browser support (expand towards webapps, webpages using ffmpeg client side in the browser) bring in more users and developers, and it will be costly for us if we let others take this area as its important and significant >>> >>> I don't understand this point - don't all major browsers already vendor >>> FFmpeg for decoding? >> >> FFmpeg does more than decoding. >> >> >>> * AI / neural network filters and codecs The future seems to be AI based. Future Filters and Codecs will use neural networks. FFmpeg can be at the forefront, developing these >>> >>> We already have TensorFlow support, no? (vf_sr etc.) What more is >>> needed? >> >> more of that AND more convenience >> >> lets pick a comparission >> to run fate >> you write "make fate" >> if you want to do it with the samples its >> make fate-rsync ; make fate >> >> if you want to use vf_sr, its reading the docs, looking at some scripts >> reading their docs >> and i presume selecting a training set ? creating a model ? >> >> how many people do that ? >> >> thx >> >> [...] >> >> -- >> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB >> >> I have often repented speaking, but never of holding my tongue. >> -- Xenocrates >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". __
Re: [FFmpeg-devel] [PATCH v2 01/27] avcodec/threadprogress: Add new API for frame-threaded progress
On 18 Apr 2024, at 22:40, Andreas Rheinhardt wrote:
> Andreas Rheinhardt:
>> The API is similar to the ThreadFrame API, with the exception
>> that it no longer has an included AVFrame and that it has its
>> own mutexes and condition variables which makes it more independent
>> of pthread_frame.c. One can wait on anything via a ThreadProgress.
>> One just has to ensure that the lifetime of the object containing
>> the ThreadProgress is long enough. This will typically be solved
>> by putting a ThreadProgress in a refcounted structure that is
>> shared between threads.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> Now including its own mutex and condition variable. Hopefully
>> no system has constraints on the number of mutexes and condition
>> variables it supports.
>>
>> libavcodec/threadprogress.c | 73 +
>> libavcodec/threadprogress.h | 91 +
>> 2 files changed, 164 insertions(+)
>> create mode 100644 libavcodec/threadprogress.c
>> create mode 100644 libavcodec/threadprogress.h
>>
>> diff --git a/libavcodec/threadprogress.c b/libavcodec/threadprogress.c
>> new file mode 100644
>> index 00..dd2a4d2336
>> --- /dev/null
>> +++ b/libavcodec/threadprogress.c
>> @@ -0,0 +1,73 @@
>> +/*
>> + * Copyright (c) 2022 Andreas Rheinhardt
>> + *
>> + * This file is part of FFmpeg.
>> + *
>> + * FFmpeg is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU Lesser General Public
>> + * License as published by the Free Software Foundation; either
>> + * version 2.1 of the License, or (at your option) any later version.
>> + *
>> + * FFmpeg is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>> + * Lesser General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU Lesser General Public
>> + * License along with FFmpeg; if not, write to the Free Software
>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
>> USA
>> + */
>> +
>> +#include
>> +#include
>> +
>> +#include "pthread_internal.h"
>> +#include "threadprogress.h"
>> +#include "libavutil/attributes.h"
>> +
>> +DEFINE_OFFSET_ARRAY(ThreadProgress, thread_progress, init,
>> +(offsetof(ThreadProgress, progress_mutex)),
>> +(offsetof(ThreadProgress, progress_cond)));
>> +
>> +av_cold int ff_thread_progress_init(ThreadProgress *pro, int init_mode)
>> +{
>> +atomic_init(&pro->progress, init_mode ? -1 : INT_MAX);
>> +if (!init_mode) {
>> +pro->init = 0;
>> +return 0;
>> +}
>> +return ff_pthread_init(pro, thread_progress_offsets);
>> +}
>> +
>> +av_cold void ff_thread_progress_destroy(ThreadProgress *pro)
>> +{
>> +ff_pthread_free(pro, thread_progress_offsets);
>> +}
>> +
>> +void ff_thread_progress_report(ThreadProgress *pro, int n)
>> +{
>> +if (atomic_load_explicit(&pro->progress, memory_order_relaxed) >= n)
>> +return;
>> +
>> +atomic_store_explicit(&pro->progress, n, memory_order_release);
>> +
>> +pthread_mutex_lock(&pro->progress_mutex);
>> +pthread_cond_broadcast(&pro->progress_cond);
>> +pthread_mutex_unlock(&pro->progress_mutex);
>> +}
>> +
>> +void ff_thread_progress_await(const ThreadProgress *pro_c, int n)
>> +{
>> +/* Casting const away here is safe, because we only read from progress
>> + * and will leave pro_c in the same state upon leaving the function
>> + * as it had at the beginning. */
>> +ThreadProgress *pro = (ThreadProgress*)pro_c;
>> +
>> +if (atomic_load_explicit(&pro->progress, memory_order_acquire) >= n)
>> +return;
>> +
>> +pthread_mutex_lock(&pro->progress_mutex);
>> +while (atomic_load_explicit(&pro->progress, memory_order_relaxed) < n)
>> +pthread_cond_wait(&pro->progress_cond, &pro->progress_mutex);
>> +pthread_mutex_unlock(&pro->progress_mutex);
>> +}
>> diff --git a/libavcodec/threadprogress.h b/libavcodec/threadprogress.h
>> new file mode 100644
>> index 00..786802cbf1
>> --- /dev/null
>> +++ b/libavcodec/threadprogress.h
>> @@ -0,0 +1,91 @@
>> +/*
>> + * Copyright (c) 2022 Andreas Rheinhardt
>> + *
>> + * This file is part of FFmpeg.
>> + *
>> + * FFmpeg is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU Lesser General Public
>> + * License as published by the Free Software Foundation; either
>> + * version 2.1 of the License, or (at your option) any later version.
>> + *
>> + * FFmpeg is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>> + * Lesser General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU Lesser General Public
>> + *
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On 18 Apr 2024, at 22:15, Michael Niedermayer wrote: > On Thu, Apr 18, 2024 at 10:19:50AM +0200, Stefano Sabatini wrote: >> On date Wednesday 2024-04-17 19:21:39 -0700, Aidan wrote: >>> The best option is to figure stuff out. >> [...] >>> I use FFmpeg to download HLS streams from the internet or convert files >>> like probably most people do. FFmpeg is the ultimate way of doing this >>> because there is no better option. >>> >>> But there are issues: >> [...] >> >>> I submitted a patch for a TTML decoder because I thought it would be great. >>> It was completely ignored. >> >> Please ping the patch or send a new one. >> >>> If my patch was seriously bad, then fine. But seriously *no one cared*. >> >> I think contribution management is a serious issue here. >> >> What happens when you send a patch is that if you're lucky someone >> will be interested and put some effort to review and eventually get it >> pushed, which depending on several factors might require several >> interactions. >> >> Sometimes contributors are side-tracked or frustrated and the review >> process is interrupted. Sometimes the reviewer won't reply, and the >> review also might be stuck (in this case you might want to ping the >> patch). >> >> Sometimes there is no qualified or interested developer around, or >> maybe those ones are busy with other things (and it's easy to miss >> a patch, especially if you don't check emails since a few days and you >> got hundreds of backlog emails). >> >> In general, this is done on a best effort basis (read as: most >> developers are volunteers and they might have job/families/stuff to >> tend to), there is no guarantee that a patch might be reviewed in a >> timely fashion. >> >> This is not a problem specific with FFmpeg, but in general with most >> FLOSS projects. >> >> Probably we should find ways to fund such activites, so that a >> developer can spend more time on reviewing work, but this comes with >> other risks/issues (since managing money is also complex of potential >> tensions in a mostly volunteering-based project). >> >> It's also very difficult to track the sent patches, and that's why >> having a Pull-Request process a-la github has been proposed several >> times; we cannot switch to github for several reasons (licensing and >> affilitation issues with platform owner) and handling your own gitlab >> is costly and we lack volunteers at the moment. >> >> We are using patchwork to mitigate the tracking issue: >> https://patchwork.ffmpeg.org/project/ffmpeg/list/ >> >> but that's not really providing an effective workflow. >> >> Personally I find the status tracking confusing, e.g.: >> https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=&submitter=&state=&q=TTML&archive=both&delegate= >> >> I cannot easily figure out what was integrated and what not. > > Would it help if i add a "patch" type to trac.ffmpeg.org ? > > If patches are missed on patchwork or its confusing, then > patch authors could open such a ticket type=patch that points to the > patchwork patch > > as tickets have all the metadata from keywords over priority to component > and do also allow voting. It may help keeping track of patches and also > allow the community to express their preferance with voting. Just stating the obvious here but GitLab/Gitea/Forgejo or similar would solve this without needing absolutely weird workarounds like this… > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > When the tyrant has disposed of foreign enemies by conquest or treaty, and > there is nothing more to fear from them, then he is always stirring up > some war or other, in order that the people may require a leader. -- Plato > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On 18 Apr 2024, at 10:46, Stefano Sabatini wrote: > On date Wednesday 2024-04-17 15:58:32 +0200, Michael Niedermayer wrote: >> Hi all >> >> The pace of inovation in FFmpeg has been slowing down. >> Most work is concentarted nowadays on code refactoring, and adding >> support for new codecs and formats. >> >> Should we >> * make a list of longer term goals >> * vote on them >> * and then together work towards implementing them >> ? >> >> (The idea here is to increase the success of larger efforts >> than adding codecs and refactoring code) >> It would then also not be possible for individuals to object >> to a previously agreed goal. >> And it would add ideas for which we can try to get funding/grants for >> >> (larger scale changes need consensus first that we as a whole want >> them before we would be able to ask for funding/grants for them) >> >> Some ideas and why they would help FFmpeg: >> > [...] >> * client side / in browser support >> (expand towards webapps, webpages using ffmpeg client side in the >> browser) >> bring in more users and developers, and it will be costly for us >> if we let others take this area as its important and significant > > There are already several projects on github, the most prominent one: > https://github.com/ffmpegwasm/ffmpeg.wasm/ > > In general it would be useful to provide libav* bindings to other > languages, for example: > https://github.com/PyAV-Org/PyAV > https://github.com/zmwangx/rust-ffmpeg > > Not sure these should be really moved to FFmpeg though. > > One option I'm currenly exploring is having a python filter enabling > to specify a custom filter implemented in python (needed for custom > ad-hoc logic you don't really want to implement in C since it's not > generic enough) and to enable using python modules when effiency is > not an issue. Lua would probably be a better choice for this from ease of integration and also speed PoV last I checked. IIRC Python had some rather complex threading implications when used in a library. But I agree having something like this in general seems nice for some prototyping and debugging with filters as well. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On 18 Apr 2024, at 9:52, Stefano Sabatini wrote: > On date Wednesday 2024-04-17 17:24:02 +0100, Andrew Sayers wrote: >> On 17/04/2024 14:58, Michael Niedermayer wrote: > [...] >> I've occasionally tried getting into ffmpeg for over a decade now, and have >> lurked here for the past few months as I put in the effort to grok it. >> On behalf of people who could contribute but don't, I'd like to suggest >> ffmpeg focus on *learnability*. >> > >> Whenever I've tried to learn ffmpeg, I've always been rebuffed by >> documentation that seems needlessly hard to use. I understand some of >> these reflect deeper issues - for example there's a reason the words >> "ffmpeg" and "libav" are used ambiguously, even though it makes it >> hard to differentiate between the library and the command-line tool. > >> But other issues seem like quick wins - for example I've lost count of >> all the times I typed two functions into Google, spent hours trying to >> make them work together, then finally realised I was looking at the >> documentation for 3.0 in one tab and 5.0 in the other. Surely you can >> just add a line to the top of the documentation like "click here to see >> the trunk version of this file"? > > Functions are documented in doxygen, so they depend on the major.minor > version, while you seem to refer to the FFmpeg version. Also on the > website we usually only have the latest mainline documentation, so I > don't understand how can you have different versions in different tabs > (unless you didn't update that tab since months/years). Thats not true and same things has happened to me multiple times, thats why I always have to check the URL to make sure the docs are the ones for master or latest release I am working with. For example see this ancient documentation here: https://ffmpeg.org/doxygen/1.2/index.html We generate those for each FFmpeg version afaik, not MAJOR-MINOR of the libraries: https://ffmpeg.org/doxygen/6.0/index.html Maybe Michael can clarify, as I have no way to check how these are actually generated for the website, if this is by branch of some other logic or completely manual. I do agree with OP that it would be VERY helpful to have some note there on old docs or some overview of the different versions at least, so that its clear you are looking at older ones… > > If you mean that we should ship documentatation for the latest > supported releases, in addition to latest mainline, I tend to agree. > >> Here's a small example to demonstrate the larger issue - >> what does it mean for something to be a "context"? >> When I started learning how to write ffmpeg code, I read through the >> docs and saw various things calling themselves "context" structs, but >> never found a link to explain what that meant. If I was a young >> developer, I would probably have just assumed it was standard >> programming jargon I was too dumb to know, and walked away to find >> something more my speed. But I'm old and stubborn and have nothing >> better to do right now, so I kept going... >> >> I tried to learn by going through the examples, but the nearest thing >> to an explanation was e.g. `transcode.c` making up a new type and >> calling it a `FilteringContext`. I ignored the AVClass documentation >> for a long time because the name made me think it was some kind of >> GObject-style C-with-classes thing. It was only when I noticed that >> it says it describes "the class of an AVClass context structure" that >> I realised what I was looking at. And it was only when I convinced >> myself that the documentation for AVOptions was using > >> "AVOptions-enabled struct" to mean the same thing as "AVClass context >> structure" that I felt able to disregard the `FilteringContext`. So >> my current opinion is that "AVOptions-enabled struct", "AVClass >> context structure" and "context structure" are different terms for the >> same thing - but now I've said that publicly, I will no doubt find an >> "SwrClass context structure" or something tomorrow. > > In general, a "context" in the FFmpeg jargon is usually a data > structure providing the context/state/configuration for a given > operation, which can be muxing, demuxing, decoding, encoding, > filtering etc. > > You need to fill the "context" with the configuration parameters and > with the data needed for the specific operation. > > In general, when setting up a context, you also want some facilities > to avoid to repeat logic again and again: > - you want to provide means to send log messages > - you want an interface to query, set, and get options > - you want a "private" internal context, with options/parameters > specific for a particular instance of a generic context. For example > you might want to set specific options which only apply to a given > encoder (these are so-called "private" options) > > This is done through the AVClass structure, which being generic is > used in various parts of FFmpeg. > > The AVOption interface wass added later, so
Re: [FFmpeg-devel] Query from Reuters on XZ, open source, and Microsoft
On 11 Apr 2024, at 5:59, Vittorio Giovara wrote: > On Wed, Apr 10, 2024 at 9:19 PM Michael Niedermayer > wrote: > >> […] >> >> To bring some of the new blood into the project the project needs to >> first understand why they dont. And asking thouse who manage with >> difficulty >> to join could be a biased oppinion. >> > > In my experience this boils down to three points > 1. there is a legit barrier of entry in a large codebase such as ffmpeg, > but over time newcomers can learn about it > 2. the review process can be though and it's easy to miss a ping and > patches get lost, very defeating for a new developer This has honestly been one of the most discouraging things when contributing here. The ML workflow just contributes to make this even worse for me, as it makes it really hard to keep track of things. (Of course everyone is different and I get why some people like the ML-patches workflow, but having experienced both at VLC, I can say for myself I vastly prefer Gitlab-like solutions) > 3. there is net negative help from trolls who spread toxic poison, which is > confusing and uninteresting for the new blood > > 2 out of 3 can be solved technically, while the last one needs a cultural > shift - overall I think we're doing a good job at slowly changing pace and > having a bit of a better structure to solve situations when they arise, but > there is still a lot of work to do Another factor is IMO the general tone here on the ML, let’s just say it is not the most welcoming environment. It doesn’t help that sometimes technical discussion and „politics“ are mixed together so you have no way to escape it when you don’t feel like being dragged down by the state of this community some days… > -- > Vittorio > ___ > 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] Remove .travis.yml
On 17 Apr 2024, at 13:45, Martin Storsjö wrote: > Travis is no longer relevant for attempting to run CI jobs in our > setup. LGTM > --- > .travis.yml | 30 -- > 1 file changed, 30 deletions(-) > delete mode 100644 .travis.yml > > diff --git a/.travis.yml b/.travis.yml > deleted file mode 100644 > index 784b7bdf73..00 > --- a/.travis.yml > +++ /dev/null > @@ -1,30 +0,0 @@ > -language: c > -sudo: false > -os: > - - linux > - - osx > -addons: > - apt: > -packages: > - - nasm > - - diffutils > -compiler: > - - clang > - - gcc > -matrix: > -exclude: > -- os: osx > - compiler: gcc > -cache: > - directories: > -- ffmpeg-samples > -before_install: > - - if [ "$TRAVIS_OS_NAME" == "osx" ]; then brew update; fi > -install: > - - if [ "$TRAVIS_OS_NAME" == "osx" ]; then brew install nasm; fi > -script: > - - mkdir -p ffmpeg-samples > - - ./configure --samples=ffmpeg-samples --cc=$CC > - - make -j 8 > - - make fate-rsync > - - make check -j 8 > -- > 2.39.3 (Apple Git-146) > > ___ > 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] cannot compile the ffmpeg latest on local
On 11 Apr 2024, at 15:59, B-2014 Ariyan Kashyap wrote: > I was trying to compile the ffmpeg in my local using MSYS2 terminal and i > am getting this error > > gcc is unable to create an executable file. > If gcc is a cross-compiler, use the --enable-cross-compile option. > Only do this if you know what cross compiling means. > C compiler test failed. > > If you think configure made a mistake, make sure you are using the latest > version from Git. If the latest version fails, report the problem to the > ffmpeg-u...@ffmpeg.org mailing list or IRC #ffmpeg on irc.libera.chat. > Include the log file "ffbuild/config.log" produced by configure as this > will help > solve the problem. Citing from this very message: „Include the log file "ffbuild/config.log" produced by configure as this will help solve the problem.“ Please actually do that, else it’s all just guesswork. > ___ > 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] 7.0 Name
My choice would be Dijkstra as well. On 2 Apr 2024, at 7:45, AV Preservation by reto.ch (lists) wrote: > Sean McGovern wrote: > >> Not sure if I am allowed to pick, my choice is Dijkstra. > > When I started programming in 1975, Edsger W. Dijkstra was one of my heroes, > which is why I support your proposal, even though I am not an FFmpeg > developer. > > Best regards, Reto > ___ > 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] fftools/ffplay: split filters & show modes cycling into separate keys
On 28 Mar 2024, at 17:46, Ondřej Fiala wrote:
> Just want to make sure, since I am aware of some cases of large commercial
> email
> providers blocking my email provider... did anyone with a gmail address
> receive
> this patch?
>
Yes
> Thanks,
> Ondřej
>
> On Tue Mar 26, 2024 at 3:18 AM CET, Ondřej Fiala wrote:
>> I am forwarding a patch from December that seems to have been overlooked.
>>
>> See the original threads in the archive:
>> https://ffmpeg.org/pipermail/ffmpeg-devel/2023-December/318613.html
>> https://ffmpeg.org/pipermail/ffmpeg-devel/2023-December/318654.html
>>
>> Forwarded message from Ondřej Fiala on Tue Dec 19, 2023 at 3:02 AM:
>> ---
>> It's annoying to have to go through the audio visualization modes when you
>> just want to switch back-and-forth between two video filters. It also makes
>> the code simpler.
>>
>> doc/ffplay.texi | 5 -
>> fftools/ffplay.c | 10 --
>> 2 files changed, 8 insertions(+), 7 deletions(-)
>>
>> diff --git a/doc/ffplay.texi b/doc/ffplay.texi
>> index 93f77eeece..91d138a974 100644
>> --- a/doc/ffplay.texi
>> +++ b/doc/ffplay.texi
>> @@ -241,8 +241,11 @@ Cycle subtitle channel in the current program.
>> @item c
>> Cycle program.
>>
>> +@item d
>> +Cycle show modes.
>> +
>> @item w
>> -Cycle video filters or show modes.
>> +Cycle video filters.
>>
>> @item s
>> Step to the next frame.
>> diff --git a/fftools/ffplay.c b/fftools/ffplay.c
>> index 873ee8cc74..2eb616a88a 100644
>> --- a/fftools/ffplay.c
>> +++ b/fftools/ffplay.c
>> @@ -3370,14 +3370,12 @@ static void event_loop(VideoState *cur_stream)
>> case SDLK_t:
>> stream_cycle_channel(cur_stream, AVMEDIA_TYPE_SUBTITLE);
>> break;
>> +case SDLK_d:
>> +toggle_audio_display(cur_stream);
>> +break;
>> case SDLK_w:
>> -if (cur_stream->show_mode == SHOW_MODE_VIDEO &&
>> cur_stream->vfilter_idx < nb_vfilters - 1) {
>> -if (++cur_stream->vfilter_idx >= nb_vfilters)
>> -cur_stream->vfilter_idx = 0;
>> -} else {
>> +if (++cur_stream->vfilter_idx >= nb_vfilters)
>> cur_stream->vfilter_idx = 0;
>> -toggle_audio_display(cur_stream);
>> -}
>> break;
>> case SDLK_PAGEUP:
>> if (cur_stream->ic->nb_chapters <= 1) {
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat: enable UDP IPv6 multicast interface selection
On 14 Mar 2024, at 10:22, Ignjatović, Lazar wrote:
> avformat: enable UDP IPv6 multicast interface selection
>
> localaddr option now properly works with IPv6 addresses. Properly resolved
> interface index in places where default 0 interface index is used (marked with
> TODO: within udp.c). Added SO_BINDTODEVICE for mcast sockets that are used for
> reading from the network. Need for this arises from the fact that [ffx1::*]
> and
> [ffx2::*] mcast addresses need to have a defined interface for binding to
> avoid
> ambiguity between multiple link-local networks on the same host. Failing to
> set
> this option causes errors on Linux systems for interface and link-local
> scopes.
>
> For mcast addresses, bind to mcast address is attempted as before. In case
> that this fails, which will happen on Windows, socket is bound to
> INADDR_ANY/IN6ADDR_ANY_INIT depending on address family. Actual interface
> selection is performed using udp_set_multicast_interface to point to the
> desired interface for sending/listening.
>
> Utilization of sin6_scope_id field enables usage and adequate resolving of
> IPv6 addresses that utilize zone index (e.g. fe80::1ff:fe23:4567:890a%eth2 )
> This is not fully supported on Windows, thus relying on this field is not done
> on Windows systems.
>
> Closes: #368
>
> Signed-off-by: Lazar Ignjatovic
> ---
> configure | 3 ++
> libavformat/ip.c | 45
> libavformat/ip.h | 6
> libavformat/network.h | 6
> libavformat/udp.c | 80 ++-
> 5 files changed, 132 insertions(+), 8 deletions(-)
>
> diff --git a/configure b/configure
> index c34bdd13f5..77f03948ce 100755
> --- a/configure
> +++ b/configure
> @@ -2256,6 +2256,7 @@ HEADERS_LIST="
> valgrind_valgrind_h
> windows_h
> winsock2_h
> +iphlpapi_h
> "
>
> INTRINSICS_LIST="
> @@ -6408,6 +6409,8 @@ if ! disabled network; then
> check_struct winsock2.h "struct sockaddr" sa_len
> check_type ws2tcpip.h "struct sockaddr_in6"
> check_type ws2tcpip.h "struct sockaddr_storage"
> +check_headers iphlpapi.h && network_extralibs+=" -liphlpapi" ||
> disable iphlpapi_h
> +check_func_headers iphlpapi.h GetBestInterfaceEx
> else
> disable network
> fi
> diff --git a/libavformat/ip.c b/libavformat/ip.c
> index b2c7ef07e5..4f2d998c34 100644
> --- a/libavformat/ip.c
> +++ b/libavformat/ip.c
> @@ -18,6 +18,9 @@
> * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
> */
>
> +#define _DEFAULT_SOURCE
> +#define _SVID_SOURCE
> +
> #include
> #include "ip.h"
> #include "libavutil/avstring.h"
> @@ -159,3 +162,45 @@ void ff_ip_reset_filters(IPSourceFilters *filters)
> filters->nb_include_addrs = 0;
> filters->nb_exclude_addrs = 0;
> }
> +
> +unsigned int ff_ip_resolve_interface_index(struct sockaddr_storage
> *local_addr)
> +{
> +#if HAVE_WINSOCK2_H && HAVE_IPHLPAPI_H
> +DWORD retval;
> +unsigned long iface;
> +
> +if (local_addr == NULL)
> +return 0;
> +
> +retval = GetBestInterfaceEx((struct sockaddr*)local_addr, &iface);
> +if (retval == NO_ERROR)
> +return iface;
> +
> +return 0;
> +#elif !HAVE_WINSOCK2_H
> +struct ifaddrs *ifaddr, *ifa;
> +
> +if (local_addr == NULL)
> +return 0;
> +
> +/* Special case for link-local addresses, relevant interface is stored
> in sin6_scope_id */
> +#if HAVE_STRUCT_SOCKADDR_IN6 && defined(IN6_IS_ADDR_LINKLOCAL)
> +if (local_addr->ss_family == AF_INET6 && IN6_IS_ADDR_LINKLOCAL(&((struct
> sockaddr_in6*)local_addr)->sin6_addr)) {
> +unsigned int interface;
> +interface = ((struct sockaddr_in6*)local_addr)->sin6_scope_id;
> +
> +if (interface != 0)
> +return interface;
> +}
> +#endif
> +if (getifaddrs(&ifaddr) == -1)
> +return 0;
> +
> +for (ifa = ifaddr; ifa != NULL; ifa = ifa->ifa_next) {
> +if (ifa->ifa_addr != NULL && compare_addr((struct
> sockaddr_storage*)ifa->ifa_addr, local_addr) == 0)
> +return if_nametoindex(ifa->ifa_name);
> +}
> +
> +return 0;
> +#endif
> +}
> diff --git a/libavformat/ip.h b/libavformat/ip.h
> index b76cdab91c..4085e96f08 100644
> --- a/libavformat/ip.h
> +++ b/libavformat/ip.h
> @@ -69,4 +69,10 @@ int ff_ip_parse_blocks(void *log_ctx, const char *buf,
> IPSourceFilters *filters)
> */
> void ff_ip_reset_filters(IPSourceFilters *filters);
>
> +/**
> + * Resolves IP address to an associated interface index
> + * @return interface index, 0 as default interface value on error
> + */
> +unsigned int ff_ip_resolve_interface_index(struct sockaddr_storage
> *local_addr);
> +
> #endif /* AVFORMAT_IP_H */
> diff --git a/libavformat/network.h b/libavformat/network.h
> index ca214087fc..2461b651d4 100644
> --- a/libavformat/network.h
> +++ b/libavformat/network.h
> @@ -38,6 +38,10 @@
> #include
> #include
>
> +#if HAVE_IPHLPAPI_H
> +#inclu
Re: [FFmpeg-devel] [PATCH] When the silencedetect filter is run against long files, the output timestamps gradually lose precision as the scan proceeds further into the file. This is because the outpu
On 11 Mar 2024, at 15:26, Andreas Rheinhardt wrote:
> Andreas Rheinhardt:
>> Allan Cady via ffmpeg-devel:
>>> From: "Allan Cady"
>>>
>>> I propose changing the format to "%.6f", which will
>>> give microsecond precision for all timestamps, regardless of
>>> offset. Trailing zeros can be trimmed from the fraction, without
>>> losing precision. If the length of the fixed-precision formatted
>>> timestamp exceeds the length of the allocated buffer
>>> (AV_TS_MAX_STRING_SIZE, currently 32, less one for the
>>> terminating null), then we can fall back to scientific notation, though
>>> this seems almost certain to never occur, because 32 characters would
>>> allow a maximum timestamp value of (32 - 1 - 6 - 1) = 24 characters.
>>> By my calculation, 10^24 seconds is about six orders of magnitude
>>> greater than the age of the universe.
>>>
>>> The fix proposed here follows the following logic:
>>>
>>> 1) Try formatting the number of seconds using "%.6f". This will
>>> always result in a string with six decimal digits in the fraction,
>>> possibly including trailing zeros. (e.g. "897234.73200").
>>>
>>> 2) Check if that string would overflow the buffer. If it would, then
>>> format it using scientific notation ("%.8g").
>>>
>>> 3) If the original fixed-point format fits, then trim any trailing
>>> zeros and decimal point, and return that result.
>>>
>>> Making this change broke two fate tests, filter-metadata-scdet,
>>> and filter-metadata-silencedetect. To correct this, I've modified
>>> tests/ref/fate/filter-metadata-scdet and
>>> tests/ref/fate/filter-metadata-silencedetect to match the
>>> new output.
>>>
>>> Signed-off-by: Allan Cady
>>> ---
>>> libavutil/timestamp.h| 53 +++-
>>> tests/ref/fate/filter-metadata-scdet | 12 ++---
>>> tests/ref/fate/filter-metadata-silencedetect | 2 +-
>>> 3 files changed, 58 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/libavutil/timestamp.h b/libavutil/timestamp.h
>>> index 2b37781eba..2f04f9bb2b 100644
>>> --- a/libavutil/timestamp.h
>>> +++ b/libavutil/timestamp.h
>>> @@ -25,6 +25,7 @@
>>> #define AVUTIL_TIMESTAMP_H
>>>
>>> #include "avutil.h"
>>> +#include
>>>
>>> #if defined(__cplusplus) && !defined(__STDC_FORMAT_MACROS) &&
>>> !defined(PRId64)
>>> #error missing -D__STDC_FORMAT_MACROS / #define __STDC_FORMAT_MACROS
>>> @@ -53,6 +54,32 @@ static inline char *av_ts_make_string(char *buf, int64_t
>>> ts)
>>> */
>>> #define av_ts2str(ts) av_ts_make_string((char[AV_TS_MAX_STRING_SIZE]){0},
>>> ts)
>>>
>>> +/**
>>> + * Strip trailing zeros and decimal point from a string. Performed
>>> + * in-place on input buffer. For local use only by av_ts_make_time_string.
>>> + *
>>> + * e.g.:
>>> + * "752.378000" -> "752.378"
>>> + *"4.0" -> "4"
>>> + * "97300" -> "97300"
>>> + */
>>> +static inline void av_ts_strip_trailing_zeros_and_decimal_point(char *str)
>>> {
>>> +if (strchr(str, '.'))
>>> +{
>>> +int i;
>>> +for (i = strlen(str) - 1; i >= 0 && str[i] == '0'; i--) {
>>> +str[i] = '\0';
>>> +}
>>> +
>>> +// Remove decimal point if it's the last character
>>> +if (i >= 0 && str[i] == '.') {
>>> +str[i] = '\0';
>>> +}
>>> +
>>> +// String was modified in place; no need for return value.
>>> +}
>>> +}
>>> +
>>> /**
>>> * Fill the provided buffer with a string containing a timestamp time
>>> * representation.
>>> @@ -65,8 +92,30 @@ static inline char *av_ts_make_string(char *buf, int64_t
>>> ts)
>>> static inline char *av_ts_make_time_string(char *buf, int64_t ts,
>>> const AVRational *tb)
>>> {
>>> -if (ts == AV_NOPTS_VALUE) snprintf(buf, AV_TS_MAX_STRING_SIZE,
>>> "NOPTS");
>>> -else snprintf(buf, AV_TS_MAX_STRING_SIZE, "%.6g",
>>> av_q2d(*tb) * ts);
>>> +if (ts == AV_NOPTS_VALUE)
>>> +{
>>> +snprintf(buf, AV_TS_MAX_STRING_SIZE, "NOPTS");
>>> +}
>>> +else
>>> +{
>>> +const int max_fraction_digits = 6;
>>> +
>>> +// Convert 64-bit timestamp to double, using rational timebase
>>> +double seconds = av_q2d(*tb) * ts;
>>> +
>>> +int length = snprintf(NULL, 0, "%.*f", max_fraction_digits,
>>> seconds);
>>> +if (length <= AV_TS_MAX_STRING_SIZE - 1)
>>> +{
>>> +snprintf(buf, AV_TS_MAX_STRING_SIZE, "%.*f",
>>> max_fraction_digits, seconds);
>>> +av_ts_strip_trailing_zeros_and_decimal_point(buf);
>>> +}
>>> +else
>>> +{
>>> +snprintf(buf, AV_TS_MAX_STRING_SIZE, "%.8g", seconds);
>>> +}
>>> +
>>> +}
>>> +
>>> return buf;
>>> }
>>>
>>
>> 1. What makes you believe that all users want the new format and that it
>> does not cause undesired behaviour for some (maybe a lot) of them? The
>> number of characters written by the earlier code stayed pretty constant
>> even when the times became
Re: [FFmpeg-devel] Indefinite ban request [RFC] Was: Re: [FFmpeg-trac] #10882(undetermined:new): swscale wastefully scales luma during yuv420p -> yuv422p
On 10 Mar 2024, at 4:00, Michael Niedermayer wrote: > On Sun, Mar 10, 2024 at 02:36:48AM +0100, epira...@gmail.com wrote: >> On 10 Mar 2024, at 2:25, Michael Niedermayer wrote: >> >>> Hi everyone >>> >>> Some members of the CC want to indefinitely ban Balling >>> from trac. And as our doc/community.texi says: >>> "Indefinite bans from the community must be confirmed by the General >>> Assembly, in a majority vote." >>> >>> Thus some CC member wishes to involve the public here >>> (really theres no other option, the GA cannot discuss/vote on what it >>> doesnt know) >>> >>> Also people have asked for more transparency and i strongly agree with >>> transparency. >>> >>> As reference, and to make it possible for the community to discuss >>> this easily without too much google searching. Ive attached the >>> list of all changes in trac done by Balling. >>> >>> I do not and never did support permanently banning contributors. >>> >>> In summary: since 2019 >>> 842 comment0' changed >>> 389 comment1' changed >>> 176 comment2' changed >>> 87 comment3' changed >>> 49 comment4' changed >>> 24 comment5' changed >>> 12 comment6' changed >>> 6 comment7' changed >>> 4 comment8' changed >>> 3 comment9' changed >>>2194 comment' changed >>> 10 component' changed >>> 12 description' changed >>> 29 keywords' changed >>> 37 owner' changed >>> 8 priority' changed >>> 7 reproduced' changed >>> 291 resolution' changed >>> 537 status' changed >>> 32 summary' changed >>> 2 type' changed >>> 11 version' changed >>> >> >> I already have an opinion about this topic due to various things I read from >> him on various OSS projects communication channels, but I am wondering >> how the attached document is helpful for the GA to get an idea of what >> this is about? >> >> Do you expect us to go through all of this list and visit each Trac ticket >> and look at what they wrote there? >> >> Maybe I am missing something here on the purpose of this document. > > Its unbiased information, its simply the full list of changes done by the > user id on trac > One can read a random subset of the comments/changes or fetch the referred > tickets and run some AI over all and ask for a summary > > If one already has formed an oppinion or does not want to vote then one can > also ignore it. Or maybe the community will decide against a vote. „Or maybe the community will decide against a vote.“ How would that even work? Of course you could propose a vote on having a vote but that seems like unnecessary meta-voting… > > I just tried to provide what i can so people have the information if they want > it. > > To me, every contributor is valuable. I want people to work together as a > team. But if people are asking for others to be banned thats a sign > something is not right. > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Rewriting code that is poorly written but fully understood is good. > Rewriting code that one doesnt understand is a sign that one is less smart > than the original author, trying to rewrite it will not make it better. > ___ > 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] Indefinite ban request [RFC] Was: Re: [FFmpeg-trac] #10882(undetermined:new): swscale wastefully scales luma during yuv420p -> yuv422p
On 10 Mar 2024, at 2:25, Michael Niedermayer wrote: > Hi everyone > > Some members of the CC want to indefinitely ban Balling > from trac. And as our doc/community.texi says: > "Indefinite bans from the community must be confirmed by the General > Assembly, in a majority vote." > > Thus some CC member wishes to involve the public here > (really theres no other option, the GA cannot discuss/vote on what it doesnt > know) > > Also people have asked for more transparency and i strongly agree with > transparency. > > As reference, and to make it possible for the community to discuss > this easily without too much google searching. Ive attached the > list of all changes in trac done by Balling. > > I do not and never did support permanently banning contributors. > > In summary: since 2019 > 842 comment0' changed > 389 comment1' changed > 176 comment2' changed > 87 comment3' changed > 49 comment4' changed > 24 comment5' changed > 12 comment6' changed > 6 comment7' changed > 4 comment8' changed > 3 comment9' changed >2194 comment' changed > 10 component' changed > 12 description' changed > 29 keywords' changed > 37 owner' changed > 8 priority' changed > 7 reproduced' changed > 291 resolution' changed > 537 status' changed > 32 summary' changed > 2 type' changed > 11 version' changed > I already have an opinion about this topic due to various things I read from him on various OSS projects communication channels, but I am wondering how the attached document is helpful for the GA to get an idea of what this is about? Do you expect us to go through all of this list and visit each Trac ticket and look at what they wrote there? Maybe I am missing something here on the purpose of this document. > > On Sat, Mar 02, 2024 at 10:23:32PM +0100, Michael Niedermayer wrote: >> The CC has no authority for permanent bans >> "Indefinite bans from the community must be confirmed by the General >> Assembly, in a majority vote." >> >> I checked and it seems there are over 4800 events in trac from Balling, 3783 >> match the word "comment" >> since 2019 >> >> By what rules does the CC deal out warnings and bans ? >> >> I think this needs to be put in writing in the docs because >> currently its pretty much arbitrary. Some people get multiple >> warnings, some people get nothing, some people are suggested to be >> just banned with no prior warning > > > On Sat, Mar 09, 2024 at 11:06:39AM +0100, Jean-Baptiste Kempf wrote: >> Hello, >> >> On Sat, 9 Mar 2024, at 08:30, Anton Khirnov wrote: >>> Quoting Michael Niedermayer (2024-03-06 13:56:39) Balling does have a quite different style in his language. Not sure what is a good term, street style, ghetto style? He used the same style of language towards me 10 days ago: https://trac.ffmpeg.org/ticket/10824#comment:18 >>> >>> This is not a "style", he understands perfectly well what he is doing. >> >> Come on, the guy is a troll. >> We're not talking about a developer from FFmpeg, but an external troll, >> contributing nothing. >> Kick him out. > > -- > 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 > ___ > 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] avutil/dict: Deduplicate freeing dictionary
On 5 Mar 2024, at 16:53, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavutil/dict.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/libavutil/dict.c b/libavutil/dict.c
> index 7f23d5336a..6fb09399ba 100644
> --- a/libavutil/dict.c
> +++ b/libavutil/dict.c
> @@ -145,11 +145,8 @@ int av_dict_set(AVDictionary **pm, const char *key,
> const char *value,
> m->elems[m->count].value = copy_value;
> m->count++;
> } else {
> -if (!m->count) {
> -av_freep(&m->elems);
> -av_freep(pm);
> -}
> -av_freep(©_key);
> +err = 0;
> +goto end;
> }
>
> return 0;
> @@ -157,12 +154,13 @@ int av_dict_set(AVDictionary **pm, const char *key,
> const char *value,
> enomem:
> err = AVERROR(ENOMEM);
> err_out:
> +av_free(copy_value);
> +end:
> if (m && !m->count) {
> av_freep(&m->elems);
> av_freep(pm);
> }
> av_free(copy_key);
> -av_free(copy_value);
> return err;
> }
>
> --
> 2.40.1
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".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] fate rsync switch to git
On 21 Feb 2024, at 15:38, Niklas Haas wrote:
> On Tue, 20 Feb 2024 20:43:30 +0200 Jan Ekström wrote:
>> Do note that the idea was that this would only be for management of
>> the main archive, so it would not affect clients/runners rsync'ing
>> from the main archive.
>>
>> Of course clients which want to sync directly from git could do that,
>> but the idea would be to keep the sync requirements same for FATE
>> clients/runners: if you are only running tests, rsync is enough.
>>
>> As after all, the primary reasons for having the samples in git would
>> be versioning, more concrete known states in a public archive (I would
>> probably not call this a "backup", but it would mean we would have the
>> history in multiple places at least), as well as - if we utilize
>> something like git{lab,hub} - easier workflow to adding new samples by
>> means of f.ex. merge/pull requests.
>>
>> This idea originated from looking at how the dav1d project handled
>> their reference sample suite, which seems to have served them well
>> enough: https://code.videolan.org/videolan/dav1d-test-data
>>
>> Regards,
>> Jan
>
> Is there any reason (besides efficiency hit) not to make the FATE repo
> a `git submodule` of the FFmpeg git repo? That way, commits which depend
> on certain additions to fate-samples can explicitly depend on the
> commits adding those files, developers can more easily see (e.g. via
> `git status`) if the fate samples are out-of-date (or use `git pull
> --recurse-submodules` to automate the process).
I am all for having it in git but do not like the idea of a git submodule
at all as they are a nightmare to work with, sometimes create absolutely
unworkable conflicts when rebasing and other oddities…
(We use submodules for the Icecast project, it was my idea back then and
I regret it…)
>
> It will also make the samples repo historically consistent, e.g. if
> somebody changes a detail about a file in a later commit, older commits
> referencing the unmodified version will continue passing FATE tests. I'm
> not sure if this has ever been a concern in the past, but it may well
> be one in the future.
>
> Worrying about the performance impact of rsync vs git-lfs (or equivalent
> solutions) seems like premature optimization to me; and the ease of
> maintenance, historical consistency, transparency in process, and
> end-user convenience of a git repository seems to far outweigh the
> drawbacks.
> ___
> 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 1/2] avcodec/s302m: enable non-PCM decoding
On 17 Feb 2024, at 13:31, Rémi Denis-Courmont wrote: > Le lauantaina 17. helmikuuta 2024, 13.46.27 EET Gyan Doshi a écrit : >> As a TC member who is part of the disagreement, I believe your >> participation is recused. > > Obviously not. We don't want to get into a situation whence TC members have an > incentive not to participate in regular code reviews just so that they can > participate in the hypothetical making of later related TC decisions. That > would be both dumb and counter-productive. > I agree… > Somebody disagreeing with you does not necessarily mean that they have a > conflict of interest in the subject matter. My understanding of this rule was too that it would be for conflict-of-interest kind of cases, which I fail to see here… > > -- > 雷米‧德尼-库尔蒙 > http://www.remlab.net/ > > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/5] avfilter/vf_signature: Allocate arrays together
On 14 Feb 2024, at 13:03, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavfilter/vf_signature.c | 9 ++---
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/libavfilter/vf_signature.c b/libavfilter/vf_signature.c
> index 4896e8f2c1..eb48bf773d 100644
> --- a/libavfilter/vf_signature.c
> +++ b/libavfilter/vf_signature.c
> @@ -250,14 +250,10 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *picref)
> int64_t* elemsignature;
> uint64_t* sortsignature;
>
> -elemsignature = av_malloc_array(elemcat->elem_count,
> sizeof(int64_t));
> +elemsignature = av_malloc_array(elemcat->elem_count, 2 *
> sizeof(int64_t));
> if (!elemsignature)
> return AVERROR(ENOMEM);
> -sortsignature = av_malloc_array(elemcat->elem_count,
> sizeof(int64_t));
> -if (!sortsignature) {
> -av_freep(&elemsignature);
> -return AVERROR(ENOMEM);
> -}
> +sortsignature = elemsignature + elemcat->elem_count;
Just my 2cents as someone not maintaining this code, so feel free to ignore
completely:
IMHO this makes it harder to understand what is going on, does it provide any
meaningful
benefit?
At the very least I would suggest to add a comment for the sake of whoever
looks a this
code next and tries to grasp what is happening there.
>
> for (j = 0; j < elemcat->elem_count; j++) {
> blocksum = 0;
> @@ -307,7 +303,6 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *picref)
> f++;
> }
> av_freep(&elemsignature);
> -av_freep(&sortsignature);
> }
>
> /* confidence */
> --
> 2.34.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel 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] STF SoWs
On 8 Feb 2024, at 13:32, Nicolas George wrote: > Leo Izen (12024-02-07): >> I don't think this is really a fair statement to make. We have lots of >> potential reviewers subscribed to this list but very few people actually >> review code, and those that do review code are expected to provide some sort >> of technical objection or reason why it shouldn't be merged. A random >> subscriber without commit access posting "Nak" on a patch without explaining >> why isn't grounds to block it. > > A random subscriber cannot do that, but if they are thick as thieves > with the people who managed to gain control of the committees, so that Can you maybe stop crying about that things did not went your way on every topic slightly related to FFmpeg „politics“ on this list? This is getting so annoying… The amount of times I had to read your absurd insinuations about there being some „conspiracy“ to take over the project… > they can be sure the tech will side with them and they can threaten you > if you point that their objections are flimsy a little too clearly, then > they can block your patch with a vague “it does not belong in ffmpeg”, > that does require a lot less effort than reviewing. > > 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] avutil/rational: Document what is to be expected from av_d2q() of doubles representing rational numbers
On 31 Jan 2024, at 20:47, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavutil/rational.h | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavutil/rational.h b/libavutil/rational.h
> index 8cbfc8e0669..c6ac9fb1d91 100644
> --- a/libavutil/rational.h
> +++ b/libavutil/rational.h
> @@ -168,6 +168,10 @@ static av_always_inline AVRational av_inv_q(AVRational q)
> * In case of infinity, the returned value is expressed as `{1, 0}` or
> * `{-1, 0}` depending on the sign.
> *
> + * In general rational numbers with |num| <= 1<<26 && |den| <= 1<<26
> + * can be recovered exactly from their double representation.
> + * (no exceptions where found within 100M random ones)
I think you meant „were“ here instead of „where“?
> + *
> * @param d `double` to convert
> * @param max Maximum allowed numerator and denominator
> * @return `d` in AVRational form
> --
> 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 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] configure doesn't seem to use pkg-config flags?
On 31 Jan 2024, at 13:03, Timo Rothenpieler wrote:
> On 31/01/2024 05:31, Roger Pack wrote:
>> On Thu, Jan 18, 2024 at 6:31 AM Timo Rothenpieler
>> wrote:
>>>
>>>
>>>
>>> On 18/01/2024 04:38, Roger Pack wrote:
Hello.
After compiling libx265 as a "static library" (mingw cross compiling
targeting win64)
$ pkg-config --libs --static x265
-L/home/rdp/new/sandbox/win64_static/build_files/lib -lx265
/usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a -lgcc
I get this failure at configure time:
./configure --enable-libx265 --arch=x86_64 --target-os=mingw32
--cross-prefix=x86_64-w64-mingw32- --pkg-config=pkg-config
--pkg-config-flags=--static
ERROR: x265 not found using pkg-config
config.log (sorry it's verbose, first compile passes, second one fails
linking)
...
require_pkg_config libx265 x265 x265.h x265_api_get
check_pkg_config libx265 x265 x265.h x265_api_get
test_pkg_config libx265 x265 x265.h x265_api_get
pkg-config --exists --print-errors x265
check_func_headers x265.h x265_api_get
-I/home/rdp/new/sandbox/win64_static/build_files/include
-L/home/rdp/new/sandbox/win64_static/build_files/lib -lx265
/usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a -lgcc
test_ld cc -I/home/rdp/new/sandbox/win64_static/build_files/include
-L/home/rdp/new/sandbox/win64_static/build_files/lib -lx265
/usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a -lgcc
test_cc -I/home/rdp/new/sandbox/win64_static/build_files/include
-L/home/rdp/new/sandbox/win64_static/build_files/lib
/usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a
BEGIN /tmp/ffconf.L9GhKESq/test.c
1 #include
2 #include
3 long check_x265_api_get(void) { return (long) x265_api_get; }
4 int main(void) { int ret = 0;
5ret |= ((intptr_t)check_x265_api_get) & 0x;
6 return ret; }
END /tmp/ffconf.L9GhKESq/test.c
x86_64-w64-mingw32-gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1
-D__printf__=__gnu_printf__ -D_WIN32_WINNT=0x0600
-D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -std=c11
-fomit-frame-pointer
-I/home/rdp/new/sandbox/win64_static/build_files/include
-L/home/rdp/new/sandbox/win64_static/build_files/lib
/usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a -c -o
/tmp/ffconf.L9GhKESq/test.o /tmp/ffconf.L9GhKESq/test.c
/tmp/ffconf.L9GhKESq/test.c: In function 'check_x265_api_get':
/tmp/ffconf.L9GhKESq/test.c:3:40: warning: cast from pointer to
integer of different size [-Wpointer-to-int-cast]
3 | long check_x265_api_get(void) { return (long) x265_api_get; }
|^
x86_64-w64-mingw32-gcc: warning:
/usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a: linker input
file unused because linking not done
x86_64-w64-mingw32-gcc -Wl,--nxcompat,--dynamicbase
-Wl,--high-entropy-va -Wl,--as-needed -Wl,--image-base,0x14000
-I/home/rdp/new/sandbox/win64_static/build_files/include
-L/home/rdp/new/sandbox/win64_static/build_files/lib
/usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a -o
/tmp/ffconf.L9GhKESq/test.exe /tmp/ffconf.L9GhKESq/test.o -lx265 -lgcc
/usr/bin/x86_64-w64-mingw32-ld:
/home/rdp/new/sandbox/win64_static/build_files/lib/libx265.a(api.cpp.obj):api.cpp:(.text+0xfb5):
undefined reference to `operator new(unsigned long long)'
/usr/bin/x86_64-w64-mingw32-ld:
/home/rdp/new/sandbox/win64_static/build_files/lib/libx265.a(api.cpp.obj):api.cpp:(.text+0x1303):
undefined reference to `operator delete(void*)'
...
So it seems to be linking it not using the output of pkg-config --libs
--static for linking or something?
>>>
>>> It's passing the pkg-config flags just fine.
>>> The x265 .pc file is just broken and does not state its dependency on
>>> libstdc++
>>
>> x265.pc does list libstdc++
>>
>> $ pkg-config --libs --static x265
>> -L/home/rdp/new/sandbox/win64_static/build_files/lib -lx265
>> /usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a -lgcc
>
> I don't think that's a valid way to specify libs by absolute path.
There is nothing invalid about that, to my knowledge.
> At least configure doesn't think so, it specifically looks for stuff starting
> with "-l" and discards the rest. Try adding -l: to the beginning.
Just adding -l to the beginning does sound invalid though.
You could do -L/usr/lib/gcc/x86_64-w64-mingw32/10-win32/ -lstdc++
But it should work just fine the way it is, I do not think discarding
everything not starting with -l is correct.
>
>
>> When I configure ffmpeg I specify ./configure --pkg-config-flags=--static
>>
>> But it appears to be rearranging the order when configure tries to use it?
>>
>> x86_64
Re: [FFmpeg-devel] [PATCH] liavcodec: add bit-rate support to RoQ video encoder
Typo in commit message: liavcodec should be libavcodec
On 22 Jan 2024, at 20:14, Victor Luchits wrote:
> The bitrate option (-b:v) can now be used to specify the bit rate
> of the video stream of the RoQ encoder.
>
> Original patch by Joseph Fenton aka Chilly Willy
>
> Signed-off-by: Victor Luchits
> ---
> Changelog| 1 +
> libavcodec/roqvideo.h| 1 +
> libavcodec/roqvideodec.c | 16 ++
> libavcodec/roqvideoenc.c | 107 +++
> libavcodec/version.h | 2 +-
> 5 files changed, 117 insertions(+), 10 deletions(-)
>
> diff --git a/Changelog b/Changelog
> index c40b6d08fd..6974312f9d 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -22,6 +22,7 @@ version :
> - ffmpeg CLI -bsf option may now be used for input as well as output
> - ffmpeg CLI options may now be used as -/opt , which is equivalent
>to -opt >
> +- RoQ video bit rate option support
> version 6.1:
> - libaribcaption decoder
> diff --git a/libavcodec/roqvideo.h b/libavcodec/roqvideo.h
> index 2c2e42884d..6d30bcaada 100644
> --- a/libavcodec/roqvideo.h
> +++ b/libavcodec/roqvideo.h
> @@ -43,6 +43,7 @@ typedef struct RoqContext {
> AVFrame *last_frame;
> AVFrame *current_frame;
> int width, height;
> +int key_frame;
> roq_cell cb2x2[256];
> roq_qcell cb4x4[256];
> diff --git a/libavcodec/roqvideodec.c b/libavcodec/roqvideodec.c
> index bfc69a65c9..b4ade3a43b 100644
> --- a/libavcodec/roqvideodec.c
> +++ b/libavcodec/roqvideodec.c
> @@ -70,6 +70,7 @@ static void roqvideo_decode_frame(RoqContext *ri,
> GetByteContext *gb)
> chunk_start = bytestream2_tell(gb);
> xpos = ypos = 0;
> +ri->key_frame = 1;
> if (chunk_size > bytestream2_get_bytes_left(gb)) {
> av_log(ri->logctx, AV_LOG_ERROR, "Chunk does not fit in input
> buffer\n");
> @@ -92,12 +93,14 @@ static void roqvideo_decode_frame(RoqContext *ri,
> GetByteContext *gb)
> switch(vqid) {
> case RoQ_ID_MOT:
> +ri->key_frame = 0;
> break;
> case RoQ_ID_FCC: {
> int byte = bytestream2_get_byte(gb);
> mx = 8 - (byte >> 4) - ((signed char) (chunk_arg >> 8));
> my = 8 - (byte & 0xf) - ((signed char) chunk_arg);
> ff_apply_motion_8x8(ri, xp, yp, mx, my);
> +ri->key_frame = 0;
> break;
> }
> case RoQ_ID_SLD:
> @@ -125,12 +128,14 @@ static void roqvideo_decode_frame(RoqContext *ri,
> GetByteContext *gb)
> vqflg_pos--;
> switch(vqid) {
> case RoQ_ID_MOT:
> +ri->key_frame = 0;
> break;
> case RoQ_ID_FCC: {
> int byte = bytestream2_get_byte(gb);
> mx = 8 - (byte >> 4) - ((signed char) (chunk_arg
> >> 8));
> my = 8 - (byte & 0xf) - ((signed char)
> chunk_arg);
> ff_apply_motion_4x4(ri, x, y, mx, my);
> +ri->key_frame = 0;
> break;
> }
> case RoQ_ID_SLD:
> @@ -214,6 +219,17 @@ static int roq_decode_frame(AVCodecContext *avctx,
> AVFrame *rframe,
> if ((ret = av_frame_ref(rframe, s->current_frame)) < 0)
> return ret;
> +
> +/* Keyframe when no MOT or FCC codes in frame */
> +if (s->key_frame) {
> +av_log(avctx, AV_LOG_VERBOSE, "\nFound keyframe!\n");
> +rframe->pict_type = AV_PICTURE_TYPE_I;
> +avpkt->flags |= AV_PKT_FLAG_KEY;
> +} else {
> +rframe->pict_type = AV_PICTURE_TYPE_P;
> +avpkt->flags &= ~AV_PKT_FLAG_KEY;
> +}
> +
> *got_frame = 1;
> /* shuffle frames */
> diff --git a/libavcodec/roqvideoenc.c b/libavcodec/roqvideoenc.c
> index 0933abf4f9..68ec9ec238 100644
> --- a/libavcodec/roqvideoenc.c
> +++ b/libavcodec/roqvideoenc.c
> @@ -136,6 +136,8 @@ typedef struct RoqEncContext {
> struct ELBGContext *elbg;
> AVLFG randctx;
> uint64_t lambda;
> +uint64_t last_lambda;
> +int lambda_delta;
> motion_vect *this_motion4;
> motion_vect *last_motion4;
> @@ -887,8 +889,9 @@ static int generate_new_codebooks(RoqEncContext *enc)
> return 0;
> }
> -static int roq_encode_video(RoqEncContext *enc)
> +static int roq_encode_video(AVCodecContext *avctx)
> {
> +RoqEncContext *const enc = avctx->priv_data;
> RoqTempData *const tempData = &enc->tmp_data;
> RoqContext *const roq = &enc->common;
> int ret;
> @@ -910,14 +913,14 @@ static int roq_encode_video(RoqEncContext *enc)
> /* Quake 3 can't handle chunks bigger than 65535 bytes */
> if (tempData->mainChunkSize/8 > 65535 && enc->quake3_compat) {
> -if (en
Re: [FFmpeg-devel] [PATCH] libavdevice/avfoundation.m Add missing type AVMediaType for macOS < 10.13.
On 1 Jan 2024, at 15:38, David Bohman wrote:
> This is a build failure in the master branch as a result of commit
> e37b15e26fbc7bc31a86a4a2c7c798e20d4f4c2c:
>
> There is no type AVMediaType prior to macOS 10.13.
> ---
> libavdevice/avfoundation.m | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
> index 6a57163eb7..5fc5cb61c5 100644
> --- a/libavdevice/avfoundation.m
> +++ b/libavdevice/avfoundation.m
> @@ -761,6 +761,10 @@ static int get_audio_config(AVFormatContext *s)
> return 0;
> }
>
> +#if TARGET_OS_OSX && __MAC_OS_X_VERSION_MIN_REQUIRED < 101300
> +typedef NSString *AVMediaType;
> +#endif
AFAICT this is lacking the similar check for iOS
> +
> static NSArray* getDevicesWithMediaType(AVMediaType mediaType) {
> #if ((TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MIN_REQUIRED >= 10)
> || (TARGET_OS_OSX && __MAC_OS_X_VERSION_MIN_REQUIRED >= 101500))
> NSMutableArray *deviceTypes = nil;
> --
> 2.43.0
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel 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] avdevice/avfoundation: replace AVCaptureDevice with new api
On 4 Dec 2023, at 13:47, xufuji456 via ffmpeg-devel wrote:
> Building with iOS platform, the compiler has a warning:
> "'devicesWithMediaType:' is deprecated: first deprecated in iOS 10.0 - Use
> AVCaptureDeviceDiscoverySession instead"
>
> Signed-off-by: xufuji456 <839789...@qq.com>
Thanks for the patch, some remarks inline below:
> ---
> libavdevice/avfoundation.m | 81 +++---
> 1 file changed, 76 insertions(+), 5 deletions(-)
>
> diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
> index 36ad834753..668c726eb7 100644
> --- a/libavdevice/avfoundation.m
> +++ b/libavdevice/avfoundation.m
> @@ -770,8 +770,38 @@ static int avf_read_header(AVFormatContext *s)
> AVCaptureDevice *video_device = nil;
> AVCaptureDevice *audio_device = nil;
> // Find capture device
> -NSArray *devices = [AVCaptureDevice
> devicesWithMediaType:AVMediaTypeVideo];
> -NSArray *devices_muxed = [AVCaptureDevice
> devicesWithMediaType:AVMediaTypeMuxed];
> +NSArray *devices = nil;
> +NSArray *devices_muxed = nil;
> +
> +if (TARGET_OS_IPHONE) {
This should use a SDK guard, like:
#if ((TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MAX_ALLOWED >= 10) ||
(TARGET_OS_OSX && __MAC_OS_X_VERSION_MAX_ALLOWED >= 101500))
(You can check
https://epir.at/2019/10/30/api-availability-and-target-conditionals/ where
I provided a more details about these)
> +if (@available(iOS 10.0, *)) {
This should be extended for other OSes too, the API is not just deprecated on
iOS.
> +AVCaptureDeviceDiscoverySession *captureDeviceDiscoverySession =
> +[AVCaptureDeviceDiscoverySession
> +
> discoverySessionWithDeviceTypes:@[AVCaptureDeviceTypeBuiltInWideAngleCamera]
> + mediaType:AVMediaTypeVideo
> +
> position:AVCaptureDevicePositionUnspecified];
> +devices = [captureDeviceDiscoverySession devices];
> +} else {
> +devices = [AVCaptureDevice
> devicesWithMediaType:AVMediaTypeVideo];
> +}
> +} else {
> +devices = [AVCaptureDevice devicesWithMediaType:AVMediaTypeVideo];
> +}
> +
> +if (TARGET_OS_IPHONE) {
> +if (@available(iOS 10.0, *)) {
> +AVCaptureDeviceDiscoverySession *captureDeviceDiscoverySession =
> +[AVCaptureDeviceDiscoverySession
> +
> discoverySessionWithDeviceTypes:@[AVCaptureDeviceTypeBuiltInWideAngleCamera]
> + mediaType:AVMediaTypeMuxed
> +
> position:AVCaptureDevicePositionUnspecified];
> +devices_muxed = [captureDeviceDiscoverySession devices];
> +} else {
> +devices_muxed = [AVCaptureDevice
> devicesWithMediaType:AVMediaTypeMuxed];
> +}
> +} else {
> +devices_muxed = [AVCaptureDevice
> devicesWithMediaType:AVMediaTypeMuxed];
> +}
>
> ctx->num_video_devices = [devices count] + [devices_muxed count];
>
> @@ -806,7 +836,20 @@ static int avf_read_header(AVFormatContext *s)
> #endif
>
> av_log(ctx, AV_LOG_INFO, "AVFoundation audio devices:\n");
> -devices = [AVCaptureDevice devicesWithMediaType:AVMediaTypeAudio];
> +if (TARGET_OS_IPHONE) {
> +if (@available(iOS 10.0, *)) {
> +AVCaptureDeviceDiscoverySession
> *captureDeviceDiscoverySession =
> +[AVCaptureDeviceDiscoverySession
> +
> discoverySessionWithDeviceTypes:@[AVCaptureDeviceTypeBuiltInWideAngleCamera]
> + mediaType:AVMediaTypeAudio
> +
> position:AVCaptureDevicePositionUnspecified];
> +devices = [captureDeviceDiscoverySession devices];
> +} else {
> +devices = [AVCaptureDevice
> devicesWithMediaType:AVMediaTypeAudio];
> +}
> +} else {
> +devices = [AVCaptureDevice
> devicesWithMediaType:AVMediaTypeAudio];
> +}
> for (AVCaptureDevice *device in devices) {
> const char *name = [[device localizedName] UTF8String];
> int index = [devices indexOfObject:device];
> @@ -930,7 +973,21 @@ static int avf_read_header(AVFormatContext *s)
>
> // get audio device
> if (ctx->audio_device_index >= 0) {
> -NSArray *devices = [AVCaptureDevice
> devicesWithMediaType:AVMediaTypeAudio];
> +NSArray *devices = nil;
> +if (TARGET_OS_IPHONE) {
> +if (@available(iOS 10.0, *)) {
> +AVCaptureDeviceDiscoverySession
> *captureDeviceDiscoverySession =
> +[AVCaptureDeviceDiscoverySession
> +
> discoverySessionWithDeviceTypes:@[AVCaptureDeviceTy
Re: [FFmpeg-devel] [PATCH] avformat/mov: Ignore duplicate ftyp
On 2 Dec 2023, at 0:26, Michael Niedermayer wrote:
> Fixes: switch_1080p_720p.mp4
> Found-by: Dale Curtis
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/mov.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index f7b5ec7a352..fb5d6f49138 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -1222,8 +1222,10 @@ static int mov_read_ftyp(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> int ret = ffio_read_size(pb, type, 4);
> if (ret < 0)
> return ret;
> -if (c->fc->nb_streams)
> -return AVERROR_INVALIDDATA;
> +if (c->fc->nb_streams) {
> +av_log(c->fc, AV_LOG_DEBUG, "Ignoring duplicate FTYP\n");
> +return 0;
> +}
>
Should this be an error when FF_COMPLIANCE_STRICT maybe?
> if (strcmp(type, "qt "))
> c->isom = 1;
> --
> 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 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] [ANNOUNCE] Repeat vote: GA voters list updates
On 14 Nov 2023, at 20:32, Ronald S. Bultje wrote: > On Tue, Nov 14, 2023 at 2:28 PM Nicolas George wrote: > >> but nobody here knows >> > > Unsubstantiated FUD. > > Move on. +1 There is no good in even more discussions right now. If really many people think public ballots are a great idea, this can be brought up later in the GA again, after all the other votes that need to be done right now are over… > > Ronald > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On 9 Nov 2023, at 9:20, Lynne wrote: > Nov 7, 2023, 08:36 by d...@lynne.ee: > >> Oct 29, 2023, 06:57 by d...@lynne.ee: >> >>> Oct 29, 2023, 05:51 by mich...@niedermayer.cc: >>> On Sat, Oct 28, 2023 at 09:23:45PM +0200, Lynne wrote: > Oct 28, 2023, 18:49 by mich...@niedermayer.cc: > >> On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote: >> >>> It's been a while since we've had a release, and we've had >>> a lot of new features in. >>> We did say we would make releases more often, and I think >>> it's about time we have a new release. >>> >>> Anything anyone wants to have merged or should we branch >>> off 6.1 in a few days? >>> >> >> Whats the status of this ? >> I can branch 6.1 anytime >> >> It was just that jb told me >> "6.1 opportunity is gone. >> We're too late on the schedule, and noone had time to work on it, so it >> is wiser to target 7.0 in January" >> >> but now i see on IRC >> make a damn release already >> j-b: drop MiNi from release maintership and nominate >> Lynne >> I pledge to bring back /slap IRC messages to those who fail to >> push the patches they want for release! >> durandal_1707: good point, we should look at doing another 5.1.x >> release and a 6.0.x release. >> >> noone mentioned 5.1.x and 6.0.x to me before >> >> anyway, ill try to make releases from all maintained branches, >> >> and will branch 6.1 as soon as Lynne or others say everything is ready. >> >> thx >> > > It's never too late to make a release. If we do a release now, nothing's > stopping > us from doing a 7.0 and getting back on track with releases every two > months or so, > like the plan was. > > 7.0 is likely to be a pretty big release, with YUVJ removal, (xHE) > AAC+fixes, D3D12 hwdec, > Vulkan encode and Vulkan AV1, and VVC, and IAMF, and MLP work, so it's a > good idea to > have a release before all this lands. > > I think the tree is in a pretty good state ATM, you should go ahead and > branch if you're > comfortable with it as well. > branch made >>> >>> Thanks. I'll get a blog post ready for the transform work, as kierank >>> wanted to post something, >>> and if users can know to who to point fingers to in case it degrades >>> performance on RPI1 devices. >>> >>> > Let's aim for a release by Sunday next week. That should give everyone > enough time to > backport fixes they want in. > I would aim for 1-3 weeks (when code and developers are ready) dont want to aim for a specific day, better pick a day when everything is fine not too many distractions, ... Or is there something that favors us to be before a specific date ? >>> >>> Not really a reason, Sunday is just an optimistic date to aim for. >>> If there are no big fixes to backport to the branch, I think we can target >>> it. >>> >> >> The nlmeans_vulkan patch I just sent is the last patch I'd like to have in >> 6.1. >> Does anyone else have any patches they would like in 6.1? If 6.1 will be cut from master, my tpad fix I sent yesterday should probably be applied first to prevent having a release with broken tpad. >> > > Pushed the 2 patches. > > Michael, do you think you can tag the release late tonight? > No one has said anything yet. > I'll write release notes for the website by then as well. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] doc/t2h: Support texinfo 7.0
On 7 Nov 2023, at 22:44, Frank Plowman wrote: > On 07/11/2023 20:38, epira...@gmail.com wrote: > >> On 7 Nov 2023, at 16:57, Frank Plowman wrote: >> >>> Resolves #10636 (http://trac.ffmpeg.org/ticket/10636) >>> >>> Texinfo 7.0, released in November 2022, changed the names of various >>> functions. Compiling docs with Texinfo 7.0 results in warnings and >>> improperly formatted documentation. More old names appear to have >>> been removed in Texinfo 7.1, released October 2023, which causes docs >>> compilation to fail. >>> >>> This PR addresses the issue by adding logic to switch between the old >>> and new function names depending on the Texinfo version. Texinfo 6.8 >>> produces identical documentation before and after the patch. The change >>> to the CSS makes the documentation generated by Texinfo >= 7.0 appear >>> more similar to that generated by Texinfo <= 6.8. >>> >>> CC >>> https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1938238.html >>> https://bugs.gentoo.org/916104 >>> >>> Signed-off-by: Frank Plowman >>> >> Thanks! >> Just had a quick look and was wondering why your patch touches the >> bootstrap.min.css? > > Texinfo 7.0 produces quite different HTML to Texinfo 6.8. Without that change > to the CSS, enumerated option flags (i.e. Possible values of x are...) render > as white text on a white background with Texinfo 7.0 and are unreadable. The > change removes a style for the selector `.table .table` which causes the > background to turn white. As far as I can tell, it is not actually used > anywhere in files generated by Texinfo 6.8. > Thanks for the clarification, I think it might be a good idea to split this change into a second commit with the explanation you gave in the commit message. That way if it ever causes an issue, it is easier to figure out, as this minified css is nearly unreviewable… > -- > https://www.frankplowman.com/ ___ 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] doc/t2h: Support texinfo 7.0
On 7 Nov 2023, at 16:57, Frank Plowman wrote: > Resolves #10636 (http://trac.ffmpeg.org/ticket/10636) > > Texinfo 7.0, released in November 2022, changed the names of various > functions. Compiling docs with Texinfo 7.0 results in warnings and > improperly formatted documentation. More old names appear to have > been removed in Texinfo 7.1, released October 2023, which causes docs > compilation to fail. > > This PR addresses the issue by adding logic to switch between the old > and new function names depending on the Texinfo version. Texinfo 6.8 > produces identical documentation before and after the patch. The change > to the CSS makes the documentation generated by Texinfo >= 7.0 appear > more similar to that generated by Texinfo <= 6.8. > > CC > https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1938238.html > https://bugs.gentoo.org/916104 > > Signed-off-by: Frank Plowman > Thanks! Just had a quick look and was wondering why your patch touches the bootstrap.min.css? > --- > ___ > 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] avutil/hwcontext_vulkan: fix run on macOS
On 7 Nov 2023, at 12:42, Lynne wrote:
> Nov 7, 2023, 12:25 by quinkbl...@foxmail.com:
>
>> Ping.
>>
>>> 在 2023年10月30日，下午4:17，Zhao Zhili 写道：
>>>
>>> From: Zhao Zhili
>>>
>>> VK_KHR_PORTABILITY_ENUMERATION_EXTENSION_NAME is required on macOS,
>>> and VK_INSTANCE_CREATE_ENUMERATE_PORTABILITY_BIT_KHR flag should
>>> be set.
>>> ---
>>> libavutil/hwcontext_vulkan.c | 9 -
>>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
>>> index 8481427b42..9fbf61ee70 100644
>>> --- a/libavutil/hwcontext_vulkan.c
>>> +++ b/libavutil/hwcontext_vulkan.c
>>> @@ -405,7 +405,6 @@ typedef struct VulkanOptExtension {
>>> } VulkanOptExtension;
>>>
>>> static const VulkanOptExtension optional_instance_exts[] = {
>>> -/* Pointless, here avoid zero-sized structs */
>>> { VK_KHR_PORTABILITY_ENUMERATION_EXTENSION_NAME,
>>> FF_VK_EXT_NO_FLAG},
>>> };
>>>
>>> @@ -784,6 +783,14 @@ static int create_instance(AVHWDeviceContext *ctx,
>>> AVDictionary *opts)
>>> inst_props.pNext = &validation_features;
>>> }
>>>
>>> +for (int i = 0; i < inst_props.enabledExtensionCount; i++) {
>>> +if (!strcmp(VK_KHR_PORTABILITY_ENUMERATION_EXTENSION_NAME,
>>> +inst_props.ppEnabledExtensionNames[i])) {
>>> +inst_props.flags |=
>>> VK_INSTANCE_CREATE_ENUMERATE_PORTABILITY_BIT_KHR;
>>> +break;
>>> +}
>>> +}
>>> +
>>> /* Try to create the instance */
>>> ret = vk->CreateInstance(&inst_props, hwctx->alloc, &hwctx->inst);
>>>
>
> Pong. It is a bit incorrect - from memory,
> VK_INSTANCE_CREATE_ENUMERATE_PORTABILITY_BIT_KHR requires that
> only Vulkan 1.1 features are enabled, while we require 1.3.
> But if it works, sure. Could you ifdef it out everywhere outside of OSX?
I wonder, how is this working given that MoltenVK does not provide Vulkan 1.3
but only 1.2?
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] avformat/hlsenc: Add init_program_date_time so start time can be specified
On 27 Oct 2023, at 5:59, Dave Johansen wrote:
> ---
> doc/muxers.texi | 3 +++
> libavformat/hlsenc.c | 41 +
> 2 files changed, 28 insertions(+), 16 deletions(-)
>
Thanks for the revised patch!
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index f6071484ff..87c19a5cb9 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -1086,6 +1086,9 @@ seeking. This flag should be used with the
> @code{hls_time} option.
> @item program_date_time
> Generate @code{EXT-X-PROGRAM-DATE-TIME} tags.
>
> +@item init_program_date_time
> +Time to start program date time at.
> +
Probably would help to mention the expected format here.
> @item second_level_segment_index
> Makes it possible to use segment indexes as %%d in hls_segment_filename
> expression
> besides date/time values when strftime is on.
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 4ef84c05c1..5dfff6b2b6 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -212,6 +212,8 @@ typedef struct HLSContext {
> int64_t recording_time;
> int64_t max_seg_size; // every segment file max size
>
> +char *init_program_date_time;
> +
> char *baseurl;
> char *vtt_format_options_str;
> char *subtitle_filename;
> @@ -1192,6 +1194,25 @@ static int hls_append_segment(struct AVFormatContext
> *s, HLSContext *hls,
> return 0;
> }
>
> +static double parse_iso8601(const char *ptr) {
> +struct tm program_date_time;
> +int y,M,d,h,m,s;
> +double ms;
> +if (sscanf(ptr, "%d-%d-%dT%d:%d:%d.%lf", &y, &M, &d, &h, &m, &s, &ms) !=
> 7) {
> +return -1;
> +}
> +
> +program_date_time.tm_year = y - 1900;
> +program_date_time.tm_mon = M - 1;
> +program_date_time.tm_mday = d;
> +program_date_time.tm_hour = h;
> +program_date_time.tm_min = m;
> +program_date_time.tm_sec = s;
> +program_date_time.tm_isdst = -1;
> +
> +return mktime(&program_date_time) + (double)(ms / 1000);
> +}
> +
> static int parse_playlist(AVFormatContext *s, const char *url, VariantStream
> *vs)
> {
> HLSContext *hls = s->priv_data;
> @@ -1257,24 +1278,11 @@ static int parse_playlist(AVFormatContext *s, const
> char *url, VariantStream *vs
> }
> }
> } else if (av_strstart(line, "#EXT-X-PROGRAM-DATE-TIME:", &ptr)) {
> -struct tm program_date_time;
> -int y,M,d,h,m,s;
> -double ms;
> -if (sscanf(ptr, "%d-%d-%dT%d:%d:%d.%lf", &y, &M, &d, &h, &m, &s,
> &ms) != 7) {
> +discont_program_date_time = parse_iso8601(ptr);
> +if (discont_program_date_time < 0) {
> ret = AVERROR_INVALIDDATA;
> goto fail;
> }
> -
> -program_date_time.tm_year = y - 1900;
> -program_date_time.tm_mon = M - 1;
> -program_date_time.tm_mday = d;
> -program_date_time.tm_hour = h;
> -program_date_time.tm_min = m;
> -program_date_time.tm_sec = s;
> -program_date_time.tm_isdst = -1;
> -
> -discont_program_date_time = mktime(&program_date_time);
> -discont_program_date_time += (double)(ms / 1000);
> } else if (av_strstart(line, "#", NULL)) {
> continue;
> } else if (line[0]) {
> @@ -2867,7 +2875,7 @@ static int hls_init(AVFormatContext *s)
> char *p = NULL;
> int http_base_proto = ff_is_http_proto(s->url);
> int fmp4_init_filename_len = strlen(hls->fmp4_init_filename) + 1;
> -double initial_program_date_time = av_gettime() / 100.0;
> +double initial_program_date_time = hls->init_program_date_time ?
> parse_iso8601(hls->init_program_date_time) : av_gettime() / 100.0;
As parse_iso8601 parsing user input can fail, it should properly report the
error and fail. Especially given that it does not accept all variations
of ISO-8601 date/time IIUC.
It might be confusing if the user specifies a time, forgets the milliseconds
and it will just silently not use the option at all?
>
> if (hls->use_localtime) {
> pattern = get_default_pattern_localtime_fmt(s);
> @@ -3141,6 +3149,7 @@ static const AVOption options[] = {
> {"split_by_time", "split the hls segment by time which user set by
> hls_time", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_SPLIT_BY_TIME }, 0, UINT_MAX,
> E, "flags"},
> {"append_list", "append the new segments into old hls segment list", 0,
> AV_OPT_TYPE_CONST, {.i64 = HLS_APPEND_LIST }, 0, UINT_MAX, E, "flags"},
> {"program_date_time", "add EXT-X-PROGRAM-DATE-TIME", 0,
> AV_OPT_TYPE_CONST, {.i64 = HLS_PROGRAM_DATE_TIME }, 0, UINT_MAX, E,
> "flags"},
> +{"init_program_date_time", "Time to start program date time at",
> OFFSET(init_program_date_time), AV_OPT_TYPE_STRING, .flags = E},
> {"second_level_segment_index", "include segment index in segment
> filenames when use_localtime", 0, AV_OPT_TY
Re: [FFmpeg-devel] [PATCH 3/5] avfilter/drawutils: simplify xyz format check
On 26 Oct 2023, at 16:05, Niklas Haas wrote: > On Thu, 26 Oct 2023 10:13:03 -0300 James Almer wrote: >> On 10/26/2023 9:23 AM, Nicolas George wrote: >>> Niklas Haas (12023-10-26): From: Niklas Haas --- libavfilter/drawutils.c | 3 --- 1 file changed, 3 deletions(-) >>> >>> Please merge this with patch 1. >> >> This patch reverts patch 1, so merging is basically just dropping both. >> I assume the reason he did things this way is to prevent patch 2 (an >> avutil patch adding new API) from changing the output filter-pixfmts-pad. > > Yes, exactly. But if you want, I can merge the FATE ref change into > patch 2. I just thought this way separates the logic change (bugfix in > drawutils) from the new API addition, which is IMO cleaner. IMO it’s easier to understand with the patches separated. Maybe clarify the commit message a bit though about this being replaced by the new flag in a follow-up commit? Also I am confused about this patch (simplify xyz format check), as the message says „simplify“ but you just remove it? Is it covered already by an existing check in this file not touched by the patch? Then the message should probably be „remove redundant check“ and clarify why it is redundant now? > ___ > 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] trac spam
On 19 Oct 2023, at 21:05, Michael Koch wrote: >> IIRC each regex give -10 so multiple matches give more. > > So far, the search strings contain only combinations of keywords, for example > "concretevictoria". > False positives are almost impossible. > > I could add shorter keywords, for example "concrete" and "victoria". > Then we would get multiple matches, but also a few false positives. > Especially for people from Canada. Keywords would be: > "ottawa", "halifax", "victoria", "moncton", "nanaimo", "vancouver", > "concrete", "excavating", "fabricators", "lawncare", "landscapedesign", > "retainingwalls" > Shall I do that? > > I agree with you that the problem is not trivial. > >> I think the captcha works as intended. It adds cost to the spammer > I doubt its economic for spammers to solve a captcha for having some spam > up for a few hours. > >From my experience looking over Xiph infrastructure, we had a lot of spammers in the past able to solve captchas to post spam on our various services. Captcha only really helped for low-effort automated spam. > It's not only for a few hours. We have the spammer's links in our archives > forever. > http://ffmpeg.org/pipermail/ffmpeg-trac/2023-October/067523.html > Search engines can find the links, and that's what the spammer probably wants. > > Michael > > > ___ > 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] Add init_program_date_time so start time can be specified
On 18 Oct 2023, at 3:14, David Johansen wrote:
> On Tue, Oct 17, 2023 at 7:09 PM wrote:
>
>>
>>
>> On 17 Oct 2023, at 17:51, Dave Johansen wrote:
>>
>>> ---
>>> doc/muxers.texi | 3 +++
>>> libavformat/hlsenc.c | 7 ++-
>>> 2 files changed, 9 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/doc/muxers.texi b/doc/muxers.texi
>>> index f6071484ff..87c19a5cb9 100644
>>> --- a/doc/muxers.texi
>>> +++ b/doc/muxers.texi
>>> @@ -1086,6 +1086,9 @@ seeking. This flag should be used with the
>> @code{hls_time} option.
>>> @item program_date_time
>>> Generate @code{EXT-X-PROGRAM-DATE-TIME} tags.
>>>
>>> +@item init_program_date_time
>>> +Time to start program date time at.
>>> +
>>> @item second_level_segment_index
>>> Makes it possible to use segment indexes as %%d in hls_segment_filename
>> expression
>>> besides date/time values when strftime is on.
>>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>>> index 4ef84c05c1..474322cc21 100644
>>> --- a/libavformat/hlsenc.c
>>> +++ b/libavformat/hlsenc.c
>>> @@ -28,6 +28,8 @@
>>> #include
>>> #endif
>>>
>>> +#include "float.h"
>>> +
>>> #include "libavutil/avassert.h"
>>> #include "libavutil/mathematics.h"
>>> #include "libavutil/avstring.h"
>>> @@ -212,6 +214,8 @@ typedef struct HLSContext {
>>> int64_t recording_time;
>>> int64_t max_seg_size; // every segment file max size
>>>
>>> +double init_program_date_time;
>>> +
>>> char *baseurl;
>>> char *vtt_format_options_str;
>>> char *subtitle_filename;
>>> @@ -2867,7 +2871,7 @@ static int hls_init(AVFormatContext *s)
>>> char *p = NULL;
>>> int http_base_proto = ff_is_http_proto(s->url);
>>> int fmp4_init_filename_len = strlen(hls->fmp4_init_filename) + 1;
>>> -double initial_program_date_time = av_gettime() / 100.0;
>>> +double initial_program_date_time = hls->init_program_date_time ?
>> hls->init_program_date_time : av_gettime() / 100.0;
>>>
>>> if (hls->use_localtime) {
>>> pattern = get_default_pattern_localtime_fmt(s);
>>> @@ -3141,6 +3145,7 @@ static const AVOption options[] = {
>>> {"split_by_time", "split the hls segment by time which user set by
>> hls_time", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_SPLIT_BY_TIME }, 0, UINT_MAX,
>> E, "flags"},
>>> {"append_list", "append the new segments into old hls segment
>> list", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_APPEND_LIST }, 0, UINT_MAX, E,
>> "flags"},
>>> {"program_date_time", "add EXT-X-PROGRAM-DATE-TIME", 0,
>> AV_OPT_TYPE_CONST, {.i64 = HLS_PROGRAM_DATE_TIME }, 0, UINT_MAX, E,
>> "flags"},
>>> +{"init_program_date_time", "Time to start program date time at",
>> OFFSET(init_program_date_time), AV_OPT_TYPE_DOUBLE, {.dbl = 0 }, 0,
>> DBL_MAX, E},
>>
>> This should probably not be mixed into the flags options list.
>>
>> It seems odd to have the user provide a double here instead of a ISO 8601
>> datetime, which is what the spec requires / ends up in the playlist.
>> If you do not want to handle the datetime string parsing, at least it
>> would be good to give a hint what exactly the double value is expected to
>> be here.
>>
>> However usability-wise I would prefer to accept a proper date/time here…
>>
>
> Is there an example of how to accept a string as the option and then do the
> parsing that I could base the code on?
For the option itself, just change the type (of course adjust the struct
variable as well):
{"init_program_date_time", "Time to start program date time at",
OFFSET(init_program_date_time), AV_OPT_TYPE_STRING, .flags = E},
And for parsing maybe have a look at libavformat/dashdec.c around line 191
which does
rudimentary ISO-8601 parsing.
> ___
> 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] Add init_program_date_time so start time can be specified
On 17 Oct 2023, at 17:51, Dave Johansen wrote:
> ---
> doc/muxers.texi | 3 +++
> libavformat/hlsenc.c | 7 ++-
> 2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index f6071484ff..87c19a5cb9 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -1086,6 +1086,9 @@ seeking. This flag should be used with the
> @code{hls_time} option.
> @item program_date_time
> Generate @code{EXT-X-PROGRAM-DATE-TIME} tags.
>
> +@item init_program_date_time
> +Time to start program date time at.
> +
> @item second_level_segment_index
> Makes it possible to use segment indexes as %%d in hls_segment_filename
> expression
> besides date/time values when strftime is on.
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 4ef84c05c1..474322cc21 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -28,6 +28,8 @@
> #include
> #endif
>
> +#include "float.h"
> +
> #include "libavutil/avassert.h"
> #include "libavutil/mathematics.h"
> #include "libavutil/avstring.h"
> @@ -212,6 +214,8 @@ typedef struct HLSContext {
> int64_t recording_time;
> int64_t max_seg_size; // every segment file max size
>
> +double init_program_date_time;
> +
> char *baseurl;
> char *vtt_format_options_str;
> char *subtitle_filename;
> @@ -2867,7 +2871,7 @@ static int hls_init(AVFormatContext *s)
> char *p = NULL;
> int http_base_proto = ff_is_http_proto(s->url);
> int fmp4_init_filename_len = strlen(hls->fmp4_init_filename) + 1;
> -double initial_program_date_time = av_gettime() / 100.0;
> +double initial_program_date_time = hls->init_program_date_time ?
> hls->init_program_date_time : av_gettime() / 100.0;
>
> if (hls->use_localtime) {
> pattern = get_default_pattern_localtime_fmt(s);
> @@ -3141,6 +3145,7 @@ static const AVOption options[] = {
> {"split_by_time", "split the hls segment by time which user set by
> hls_time", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_SPLIT_BY_TIME }, 0, UINT_MAX,
> E, "flags"},
> {"append_list", "append the new segments into old hls segment list", 0,
> AV_OPT_TYPE_CONST, {.i64 = HLS_APPEND_LIST }, 0, UINT_MAX, E, "flags"},
> {"program_date_time", "add EXT-X-PROGRAM-DATE-TIME", 0,
> AV_OPT_TYPE_CONST, {.i64 = HLS_PROGRAM_DATE_TIME }, 0, UINT_MAX, E,
> "flags"},
> +{"init_program_date_time", "Time to start program date time at",
> OFFSET(init_program_date_time), AV_OPT_TYPE_DOUBLE, {.dbl = 0 }, 0, DBL_MAX,
> E},
This should probably not be mixed into the flags options list.
It seems odd to have the user provide a double here instead of a ISO 8601
datetime, which is what the spec requires / ends up in the playlist.
If you do not want to handle the datetime string parsing, at least it would be
good to give a hint what exactly the double value is expected to be here.
However usability-wise I would prefer to accept a proper date/time here…
> {"second_level_segment_index", "include segment index in segment
> filenames when use_localtime", 0, AV_OPT_TYPE_CONST, {.i64 =
> HLS_SECOND_LEVEL_SEGMENT_INDEX }, 0, UINT_MAX, E, "flags"},
> {"second_level_segment_duration", "include segment duration in segment
> filenames when use_localtime", 0, AV_OPT_TYPE_CONST, {.i64 =
> HLS_SECOND_LEVEL_SEGMENT_DURATION }, 0, UINT_MAX, E, "flags"},
> {"second_level_segment_size", "include segment size in segment filenames
> when use_localtime", 0, AV_OPT_TYPE_CONST, {.i64 =
> HLS_SECOND_LEVEL_SEGMENT_SIZE }, 0, UINT_MAX, E, "flags"},
> --
> 2.39.2 (Apple Git-143)
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] doc: add spi.txt
On 17 Oct 2023, at 9:29, Stefano Sabatini wrote: > On date Monday 2023-10-16 06:34:45 +0200, Lynne wrote: >> Oct 16, 2023, 00:50 by mich...@niedermayer.cc: >> >>> This explains how to request refunds and what can be funded by SPI >>> >>> Co-Author: Stefano Sabatini >>> --- >>> doc/spi.txt | 73 + >>> 1 file changed, 73 insertions(+) >>> create mode 100644 doc/spi.txt >>> >>> diff --git a/doc/spi.txt b/doc/spi.txt >>> new file mode 100644 >>> index 00..ff4af8f42b >>> >> >> Again, I think this belongs on the website, not in our codebase. > > Given that this is a sort of internal memo, and that is targeted at > developers rather than final users, I see no value into exposing this > in the website (and we have similar documents - e.g. community.texi - > already in doc). > > OTOH given that this clarifies how donations are spent, there is also > a value into making this more transparent to users/donors, but I don't > see this as blocking (we can publish it here and then move it to the > website once the process has been consolidated). IMO this would be much more discoverable on the website, it would never occur to me to look for such information in the FFmpeg source tree doc folder. > ___ > 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] MAINTAINERS: Add myself as maintainer for Icecast protocol
From: Marvin Scholz --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 90a4013..ef120e4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -497,6 +497,7 @@ Protocols: libssh.c Lukasz Marek mms*.cRonald S. Bultje udp.c Luca Abeni + icecast.c Marvin Scholz libswresample -- 2.1.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] Icecast: always send a content-type
From: Marvin Scholz use a default (audio/mpeg for historical reason) if none. Required since Icecast 2.4.1 Not using AVOption default because this breaks content-type warnings (needs to detect if no type was set by the user) --- libavformat/icecast.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavformat/icecast.c b/libavformat/icecast.c index 7d60e44..7472416 100644 --- a/libavformat/icecast.c +++ b/libavformat/icecast.c @@ -117,6 +117,8 @@ static int icecast_open(URLContext *h, const char *uri, int flags) av_dict_set(&opt_dict, "chunked_post", "0", 0); if (NOT_EMPTY(s->content_type)) av_dict_set(&opt_dict, "content_type", s->content_type, 0); +else +av_dict_set(&opt_dict, "content_type", "audio/mpeg", 0); if (NOT_EMPTY(s->user_agent)) av_dict_set(&opt_dict, "user_agent", s->user_agent, 0); -- 2.1.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] ffserver_config: drop requirement video size being multiple of 16
From: Lukasz Marek
Such strong requirement constraint doesn't allow to use 360p.
Changed to warning when video size is not being multiple of 2.
Signed-off-by: Lukasz Marek
---
ffserver_config.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ffserver_config.c b/ffserver_config.c
index c8180ef..5bb2d29 100644
--- a/ffserver_config.c
+++ b/ffserver_config.c
@@ -895,8 +895,8 @@ static int ffserver_parse_config_stream(FFServerConfig
*config, const char *cmd,
ret = av_parse_video_size(&w, &h, arg);
if (ret < 0)
ERROR("Invalid video size '%s'\n", arg);
-else if ((w % 16) || (h % 16))
-ERROR("Image size must be a multiple of 16\n");
+else if ((w % 2) || (h % 2))
+WARNING("Image size is not a multiple of 2\n");
if (av_dict_set_int(&config->video_conf, "VideoSizeWidth", w, 0) < 0 ||
av_dict_set_int(&config->video_conf, "VideoSizeHeight", h, 0) < 0)
goto nomem;
--
2.1.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] Icecast: always send a content-type
From: Marvin Scholz
use a default (audio/mpeg for historical reason) if none. Required since
Icecast 2.4.1
---
libavformat/icecast.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavformat/icecast.c b/libavformat/icecast.c
index 7d60e44..d7a2d18 100644
--- a/libavformat/icecast.c
+++ b/libavformat/icecast.c
@@ -60,7 +60,7 @@ static const AVOption options[] = {
{ "ice_public", "set if stream is public", OFFSET(public),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, E },
{ "user_agent", "override User-Agent header", OFFSET(user_agent),
AV_OPT_TYPE_STRING, { 0 }, 0, 0, E },
{ "password", "set password", OFFSET(pass), AV_OPT_TYPE_STRING, { 0 }, 0,
0, E },
-{ "content_type", "set content-type, MUST be set if not audio/mpeg",
OFFSET(content_type), AV_OPT_TYPE_STRING, { 0 }, 0, 0, E },
+{ "content_type", "set content-type, MUST be set if not audio/mpeg",
OFFSET(content_type), AV_OPT_TYPE_STRING, { .str = "audio/mpeg" }, 0, 0, E },
{ "legacy_icecast", "use legacy SOURCE method, for Icecast < v2.4",
OFFSET(legacy_icecast), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, E },
{ NULL }
};
@@ -115,8 +115,7 @@ static int icecast_open(URLContext *h, const char *uri, int
flags)
av_dict_set(&opt_dict, "auth_type", "basic", 0);
av_dict_set(&opt_dict, "headers", headers, 0);
av_dict_set(&opt_dict, "chunked_post", "0", 0);
-if (NOT_EMPTY(s->content_type))
-av_dict_set(&opt_dict, "content_type", s->content_type, 0);
+av_dict_set(&opt_dict, "content_type", s->content_type, 0);
if (NOT_EMPTY(s->user_agent))
av_dict_set(&opt_dict, "user_agent", s->user_agent, 0);
--
2.1.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] Icecast: Use 100-continue if possible for proper error handling
From: Marvin Scholz Using 100-continue ffmpeg will only send data if the server confirms it, so if there is an error with auth or mounpoint, this allows that it is properly reported to the user. Else ffmpeg sends data and just quits at some point without an error message. --- libavformat/icecast.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavformat/icecast.c b/libavformat/icecast.c index d7a2d18..d1e467e 100644 --- a/libavformat/icecast.c +++ b/libavformat/icecast.c @@ -116,6 +116,7 @@ static int icecast_open(URLContext *h, const char *uri, int flags) av_dict_set(&opt_dict, "headers", headers, 0); av_dict_set(&opt_dict, "chunked_post", "0", 0); av_dict_set(&opt_dict, "content_type", s->content_type, 0); +av_dict_set(&opt_dict, "send_expect_100", s->legacy_icecast ? "0" : "1", 0); if (NOT_EMPTY(s->user_agent)) av_dict_set(&opt_dict, "user_agent", s->user_agent, 0); -- 2.1.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Fixes for the Icecast protocol
Fixed space vs. tab messup ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Fixes for the Icecast protocol
From: ePirat
Send 100-continue header so we detect errors before sending data
Use a default content-type (content-type is required since Icecast 2.4.1)
---
libavformat/icecast.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavformat/icecast.c b/libavformat/icecast.c
index 7d60e44..b477528 100644
--- a/libavformat/icecast.c
+++ b/libavformat/icecast.c
@@ -60,7 +60,7 @@ static const AVOption options[] = {
{ "ice_public", "set if stream is public", OFFSET(public),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, E },
{ "user_agent", "override User-Agent header", OFFSET(user_agent),
AV_OPT_TYPE_STRING, { 0 }, 0, 0, E },
{ "password", "set password", OFFSET(pass), AV_OPT_TYPE_STRING, { 0 }, 0,
0, E },
-{ "content_type", "set content-type, MUST be set if not audio/mpeg",
OFFSET(content_type), AV_OPT_TYPE_STRING, { 0 }, 0, 0, E },
+{ "content_type", "set content-type, MUST be set if not audio/mpeg",
OFFSET(content_type), AV_OPT_TYPE_STRING, { .str = "audio/mpeg" }, 0, 0, E },
{ "legacy_icecast", "use legacy SOURCE method, for Icecast < v2.4",
OFFSET(legacy_icecast), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, E },
{ NULL }
};
@@ -115,8 +115,8 @@ static int icecast_open(URLContext *h, const char *uri, int
flags)
av_dict_set(&opt_dict, "auth_type", "basic", 0);
av_dict_set(&opt_dict, "headers", headers, 0);
av_dict_set(&opt_dict, "chunked_post", "0", 0);
-if (NOT_EMPTY(s->content_type))
-av_dict_set(&opt_dict, "content_type", s->content_type, 0);
+av_dict_set(&opt_dict, "content_type", s->content_type, 0);
+ av_dict_set(&opt_dict, "send_expect_100", "1", 0);
if (NOT_EMPTY(s->user_agent))
av_dict_set(&opt_dict, "user_agent", s->user_agent, 0);
--
2.1.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavformat/icecast.c Add Icecast protocol
From: ePirat
Fix header.
---
Add Icecast protocol, a convenience wrapper for the HTTP protocol
---
Changelog| 3 +
configure| 1 +
doc/general.texi | 1 +
doc/protocols.texi | 42 ++
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/icecast.c| 209 +++
libavformat/version.h| 4 +-
8 files changed, 260 insertions(+), 2 deletions(-)
create mode 100644 libavformat/icecast.c
diff --git a/Changelog b/Changelog
index 07cf1cf..821525e 100644
--- a/Changelog
+++ b/Changelog
@@ -1,6 +1,9 @@
Entries are sorted chronologically from oldest to youngest within each release,
releases are sorted from youngest to oldest.
+:
+- Icecast protocol
+
version 2.3:
- AC3 fixed-point decoding
- shuffleplanes filter
diff --git a/configure b/configure
index b4ec1e6..a0b2354 100755
--- a/configure
+++ b/configure
@@ -2483,6 +2483,7 @@ gopher_protocol_select="network"
http_protocol_select="tcp_protocol"
httpproxy_protocol_select="tcp_protocol"
https_protocol_select="tls_protocol"
+icecast_protocol_select="http"
librtmp_protocol_deps="librtmp"
librtmpe_protocol_deps="librtmp"
librtmps_protocol_deps="librtmp"
diff --git a/doc/general.texi b/doc/general.texi
index 35db917..9ce0b31 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -1055,6 +1055,7 @@ performance on systems without hardware floating point
support).
@item HLS @tab X
@item HTTP @tab X
@item HTTPS@tab X
+@item Icecast @tab X
@item MMSH @tab X
@item MMST @tab X
@item pipe @tab X
diff --git a/doc/protocols.texi b/doc/protocols.texi
index 1cd96cc..cb75d92 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -293,6 +293,48 @@ The required syntax to play a stream specifying a cookie
is:
ffplay -cookies "nlqptid=nltid=tsn; path=/; domain=somedomain.com;"
http://somedomain.com/somestream.m3u8
@end example
+@section Icecast
+
+Icecast protocol
+
+@table @option
+@item ice_genre
+Set the genre of the stream.
+
+@item ice_name
+Set the name of the stream.
+
+@item ice_description
+Set the description of the stream.
+
+@item ice_url
+Set the stream website url.
+
+@item ice_public
+Set if the stream should be public.
+Default is 0 (not public).
+
+@item ice_password
+Password for the mountpoint.
+
+@item legacy_icecast
+If set to 1, enable support for legacy Icecast (Version < 2.4), using the
SOURCE method
+instead of the PUT method.
+
+@item content_type
+Set a specific content type for the stream.
+This MUST be set if streaming else than audio/mpeg
+
+@item user_agent
+Override the User-Agent header. If not specified the protocol will use a
+string describing the libavformat build. ("Lavf/")
+
+@end table
+
+@example
+icecast://[@var{username}[:@var{password}]@@]@var{server}:@var{port}/@var{mountpoint}
+@end example
+
@section mmst
MMS (Microsoft Media Server) protocol over TCP.
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 9017e06..d2d0d87 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -484,6 +484,7 @@ OBJS-$(CONFIG_HLS_PROTOCOL) += hlsproto.o
OBJS-$(CONFIG_HTTP_PROTOCOL) += http.o httpauth.o urldecode.o
OBJS-$(CONFIG_HTTPPROXY_PROTOCOL)+= http.o httpauth.o urldecode.o
OBJS-$(CONFIG_HTTPS_PROTOCOL)+= http.o httpauth.o urldecode.o
+OBJS-$(CONFIG_ICECAST_PROTOCOL) += icecast.o
OBJS-$(CONFIG_MMSH_PROTOCOL) += mmsh.o mms.o asf.o
OBJS-$(CONFIG_MMST_PROTOCOL) += mmst.o mms.o asf.o
OBJS-$(CONFIG_MD5_PROTOCOL) += md5proto.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 00de817..5599bae 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -347,6 +347,7 @@ void av_register_all(void)
REGISTER_PROTOCOL(HTTP, http);
REGISTER_PROTOCOL(HTTPPROXY,httpproxy);
REGISTER_PROTOCOL(HTTPS,https);
+REGISTER_PROTOCOL(ICECAST, icecast);
REGISTER_PROTOCOL(MMSH, mmsh);
REGISTER_PROTOCOL(MMST, mmst);
REGISTER_PROTOCOL(MD5, md5);
diff --git a/libavformat/icecast.c b/libavformat/icecast.c
new file mode 100644
index 000..77781b2
--- /dev/null
+++ b/libavformat/icecast.c
@@ -0,0 +1,209 @@
+/*
+ * Icecast protocol for Libav
+ * Copyright (c) 2014 Marvin Scholz
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License fo
[FFmpeg-devel] [PATCH] libavformat/icecast.c Add Icecast protocol
From: ePirat
Fix: Last password char was removed by accident.
Code cleanup.
---
Add Icecast protocol, a convenience wrapper for the HTTP protocol
---
Changelog| 3 +
configure| 1 +
doc/general.texi | 1 +
doc/protocols.texi | 42 ++
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/icecast.c| 209 +++
libavformat/version.h| 4 +-
8 files changed, 260 insertions(+), 2 deletions(-)
create mode 100644 libavformat/icecast.c
diff --git a/Changelog b/Changelog
index 07cf1cf..821525e 100644
--- a/Changelog
+++ b/Changelog
@@ -1,6 +1,9 @@
Entries are sorted chronologically from oldest to youngest within each release,
releases are sorted from youngest to oldest.
+:
+- Icecast protocol
+
version 2.3:
- AC3 fixed-point decoding
- shuffleplanes filter
diff --git a/configure b/configure
index b4ec1e6..a0b2354 100755
--- a/configure
+++ b/configure
@@ -2483,6 +2483,7 @@ gopher_protocol_select="network"
http_protocol_select="tcp_protocol"
httpproxy_protocol_select="tcp_protocol"
https_protocol_select="tls_protocol"
+icecast_protocol_select="http"
librtmp_protocol_deps="librtmp"
librtmpe_protocol_deps="librtmp"
librtmps_protocol_deps="librtmp"
diff --git a/doc/general.texi b/doc/general.texi
index 35db917..9ce0b31 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -1055,6 +1055,7 @@ performance on systems without hardware floating point
support).
@item HLS @tab X
@item HTTP @tab X
@item HTTPS@tab X
+@item Icecast @tab X
@item MMSH @tab X
@item MMST @tab X
@item pipe @tab X
diff --git a/doc/protocols.texi b/doc/protocols.texi
index 1cd96cc..cb75d92 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -293,6 +293,48 @@ The required syntax to play a stream specifying a cookie
is:
ffplay -cookies "nlqptid=nltid=tsn; path=/; domain=somedomain.com;"
http://somedomain.com/somestream.m3u8
@end example
+@section Icecast
+
+Icecast protocol
+
+@table @option
+@item ice_genre
+Set the genre of the stream.
+
+@item ice_name
+Set the name of the stream.
+
+@item ice_description
+Set the description of the stream.
+
+@item ice_url
+Set the stream website url.
+
+@item ice_public
+Set if the stream should be public.
+Default is 0 (not public).
+
+@item ice_password
+Password for the mountpoint.
+
+@item legacy_icecast
+If set to 1, enable support for legacy Icecast (Version < 2.4), using the
SOURCE method
+instead of the PUT method.
+
+@item content_type
+Set a specific content type for the stream.
+This MUST be set if streaming else than audio/mpeg
+
+@item user_agent
+Override the User-Agent header. If not specified the protocol will use a
+string describing the libavformat build. ("Lavf/")
+
+@end table
+
+@example
+icecast://[@var{username}[:@var{password}]@@]@var{server}:@var{port}/@var{mountpoint}
+@end example
+
@section mmst
MMS (Microsoft Media Server) protocol over TCP.
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 9017e06..d2d0d87 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -484,6 +484,7 @@ OBJS-$(CONFIG_HLS_PROTOCOL) += hlsproto.o
OBJS-$(CONFIG_HTTP_PROTOCOL) += http.o httpauth.o urldecode.o
OBJS-$(CONFIG_HTTPPROXY_PROTOCOL)+= http.o httpauth.o urldecode.o
OBJS-$(CONFIG_HTTPS_PROTOCOL)+= http.o httpauth.o urldecode.o
+OBJS-$(CONFIG_ICECAST_PROTOCOL) += icecast.o
OBJS-$(CONFIG_MMSH_PROTOCOL) += mmsh.o mms.o asf.o
OBJS-$(CONFIG_MMST_PROTOCOL) += mmst.o mms.o asf.o
OBJS-$(CONFIG_MD5_PROTOCOL) += md5proto.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 00de817..5599bae 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -347,6 +347,7 @@ void av_register_all(void)
REGISTER_PROTOCOL(HTTP, http);
REGISTER_PROTOCOL(HTTPPROXY,httpproxy);
REGISTER_PROTOCOL(HTTPS,https);
+REGISTER_PROTOCOL(ICECAST, icecast);
REGISTER_PROTOCOL(MMSH, mmsh);
REGISTER_PROTOCOL(MMST, mmst);
REGISTER_PROTOCOL(MD5, md5);
diff --git a/libavformat/icecast.c b/libavformat/icecast.c
new file mode 100644
index 000..b473219
--- /dev/null
+++ b/libavformat/icecast.c
@@ -0,0 +1,209 @@
+/*
+ * Icecast protocol for Libav
+ * Copyright (c) 2014 Marvin Scholz
+ *
+ * This file is part of Libav.
+ *
+ * Libav is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * Libav is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[FFmpeg-devel] [PATCH] libavformat/icecast.c Add Icecast protocol
From: ePirat
Fixed things.
---
Add Icecast protocol, a convenience wrapper for the HTTP protocol
---
Changelog| 3 +
configure| 1 +
doc/general.texi | 1 +
doc/protocols.texi | 42 +
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/icecast.c| 228 +++
libavformat/version.h| 4 +-
8 files changed, 279 insertions(+), 2 deletions(-)
create mode 100644 libavformat/icecast.c
diff --git a/Changelog b/Changelog
index 07cf1cf..821525e 100644
--- a/Changelog
+++ b/Changelog
@@ -1,6 +1,9 @@
Entries are sorted chronologically from oldest to youngest within each release,
releases are sorted from youngest to oldest.
+:
+- Icecast protocol
+
version 2.3:
- AC3 fixed-point decoding
- shuffleplanes filter
diff --git a/configure b/configure
index b4ec1e6..a0b2354 100755
--- a/configure
+++ b/configure
@@ -2483,6 +2483,7 @@ gopher_protocol_select="network"
http_protocol_select="tcp_protocol"
httpproxy_protocol_select="tcp_protocol"
https_protocol_select="tls_protocol"
+icecast_protocol_select="http"
librtmp_protocol_deps="librtmp"
librtmpe_protocol_deps="librtmp"
librtmps_protocol_deps="librtmp"
diff --git a/doc/general.texi b/doc/general.texi
index 35db917..9ce0b31 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -1055,6 +1055,7 @@ performance on systems without hardware floating point
support).
@item HLS @tab X
@item HTTP @tab X
@item HTTPS@tab X
+@item Icecast @tab X
@item MMSH @tab X
@item MMST @tab X
@item pipe @tab X
diff --git a/doc/protocols.texi b/doc/protocols.texi
index 1cd96cc..cb75d92 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -293,6 +293,48 @@ The required syntax to play a stream specifying a cookie
is:
ffplay -cookies "nlqptid=nltid=tsn; path=/; domain=somedomain.com;"
http://somedomain.com/somestream.m3u8
@end example
+@section Icecast
+
+Icecast protocol
+
+@table @option
+@item ice_genre
+Set the genre of the stream.
+
+@item ice_name
+Set the name of the stream.
+
+@item ice_description
+Set the description of the stream.
+
+@item ice_url
+Set the stream website url.
+
+@item ice_public
+Set if the stream should be public.
+Default is 0 (not public).
+
+@item ice_password
+Password for the mountpoint.
+
+@item legacy_icecast
+If set to 1, enable support for legacy Icecast (Version < 2.4), using the
SOURCE method
+instead of the PUT method.
+
+@item content_type
+Set a specific content type for the stream.
+This MUST be set if streaming else than audio/mpeg
+
+@item user_agent
+Override the User-Agent header. If not specified the protocol will use a
+string describing the libavformat build. ("Lavf/")
+
+@end table
+
+@example
+icecast://[@var{username}[:@var{password}]@@]@var{server}:@var{port}/@var{mountpoint}
+@end example
+
@section mmst
MMS (Microsoft Media Server) protocol over TCP.
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 9017e06..d2d0d87 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -484,6 +484,7 @@ OBJS-$(CONFIG_HLS_PROTOCOL) += hlsproto.o
OBJS-$(CONFIG_HTTP_PROTOCOL) += http.o httpauth.o urldecode.o
OBJS-$(CONFIG_HTTPPROXY_PROTOCOL)+= http.o httpauth.o urldecode.o
OBJS-$(CONFIG_HTTPS_PROTOCOL)+= http.o httpauth.o urldecode.o
+OBJS-$(CONFIG_ICECAST_PROTOCOL) += icecast.o
OBJS-$(CONFIG_MMSH_PROTOCOL) += mmsh.o mms.o asf.o
OBJS-$(CONFIG_MMST_PROTOCOL) += mmst.o mms.o asf.o
OBJS-$(CONFIG_MD5_PROTOCOL) += md5proto.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 00de817..5599bae 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -347,6 +347,7 @@ void av_register_all(void)
REGISTER_PROTOCOL(HTTP, http);
REGISTER_PROTOCOL(HTTPPROXY,httpproxy);
REGISTER_PROTOCOL(HTTPS,https);
+REGISTER_PROTOCOL(ICECAST, icecast);
REGISTER_PROTOCOL(MMSH, mmsh);
REGISTER_PROTOCOL(MMST, mmst);
REGISTER_PROTOCOL(MD5, md5);
diff --git a/libavformat/icecast.c b/libavformat/icecast.c
new file mode 100644
index 000..38b4788
--- /dev/null
+++ b/libavformat/icecast.c
@@ -0,0 +1,228 @@
+/*
+ * Icecast Protocol Handler
+ * Copyright (c) 2014 Marvin Scholz
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License
[FFmpeg-devel] [PATCH] libavformat/icecast.c Add Icecast protocol
From: ePirat
Fixed Makefile and micro version
---
Add Icecast protocol, a convenience wrapper for the HTTP protocol
---
Changelog| 1 +
configure| 1 +
doc/general.texi | 1 +
doc/protocols.texi | 42 +
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/icecast.c| 230 +++
libavformat/version.h| 4 +-
8 files changed, 279 insertions(+), 2 deletions(-)
create mode 100644 libavformat/icecast.c
diff --git a/Changelog b/Changelog
index 07cf1cf..54bb6ba 100644
--- a/Changelog
+++ b/Changelog
@@ -2,6 +2,7 @@ Entries are sorted chronologically from oldest to youngest
within each release,
releases are sorted from youngest to oldest.
version 2.3:
+- Icecast protocol
- AC3 fixed-point decoding
- shuffleplanes filter
- subfile protocol
diff --git a/configure b/configure
index b4ec1e6..a0b2354 100755
--- a/configure
+++ b/configure
@@ -2483,6 +2483,7 @@ gopher_protocol_select="network"
http_protocol_select="tcp_protocol"
httpproxy_protocol_select="tcp_protocol"
https_protocol_select="tls_protocol"
+icecast_protocol_select="http"
librtmp_protocol_deps="librtmp"
librtmpe_protocol_deps="librtmp"
librtmps_protocol_deps="librtmp"
diff --git a/doc/general.texi b/doc/general.texi
index 35db917..9ce0b31 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -1055,6 +1055,7 @@ performance on systems without hardware floating point
support).
@item HLS @tab X
@item HTTP @tab X
@item HTTPS@tab X
+@item Icecast @tab X
@item MMSH @tab X
@item MMST @tab X
@item pipe @tab X
diff --git a/doc/protocols.texi b/doc/protocols.texi
index 1cd96cc..cb75d92 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -293,6 +293,48 @@ The required syntax to play a stream specifying a cookie
is:
ffplay -cookies "nlqptid=nltid=tsn; path=/; domain=somedomain.com;"
http://somedomain.com/somestream.m3u8
@end example
+@section Icecast
+
+Icecast protocol
+
+@table @option
+@item ice_genre
+Set the genre of the stream.
+
+@item ice_name
+Set the name of the stream.
+
+@item ice_description
+Set the description of the stream.
+
+@item ice_url
+Set the stream website url.
+
+@item ice_public
+Set if the stream should be public.
+Default is 0 (not public).
+
+@item ice_password
+Password for the mountpoint.
+
+@item legacy_icecast
+If set to 1, enable support for legacy Icecast (Version < 2.4), using the
SOURCE method
+instead of the PUT method.
+
+@item content_type
+Set a specific content type for the stream.
+This MUST be set if streaming else than audio/mpeg
+
+@item user_agent
+Override the User-Agent header. If not specified the protocol will use a
+string describing the libavformat build. ("Lavf/")
+
+@end table
+
+@example
+icecast://[@var{username}[:@var{password}]@@]@var{server}:@var{port}/@var{mountpoint}
+@end example
+
@section mmst
MMS (Microsoft Media Server) protocol over TCP.
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 9017e06..d2d0d87 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -484,6 +484,7 @@ OBJS-$(CONFIG_HLS_PROTOCOL) += hlsproto.o
OBJS-$(CONFIG_HTTP_PROTOCOL) += http.o httpauth.o urldecode.o
OBJS-$(CONFIG_HTTPPROXY_PROTOCOL)+= http.o httpauth.o urldecode.o
OBJS-$(CONFIG_HTTPS_PROTOCOL)+= http.o httpauth.o urldecode.o
+OBJS-$(CONFIG_ICECAST_PROTOCOL) += icecast.o
OBJS-$(CONFIG_MMSH_PROTOCOL) += mmsh.o mms.o asf.o
OBJS-$(CONFIG_MMST_PROTOCOL) += mmst.o mms.o asf.o
OBJS-$(CONFIG_MD5_PROTOCOL) += md5proto.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 00de817..5599bae 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -347,6 +347,7 @@ void av_register_all(void)
REGISTER_PROTOCOL(HTTP, http);
REGISTER_PROTOCOL(HTTPPROXY,httpproxy);
REGISTER_PROTOCOL(HTTPS,https);
+REGISTER_PROTOCOL(ICECAST, icecast);
REGISTER_PROTOCOL(MMSH, mmsh);
REGISTER_PROTOCOL(MMST, mmst);
REGISTER_PROTOCOL(MD5, md5);
diff --git a/libavformat/icecast.c b/libavformat/icecast.c
new file mode 100644
index 000..700bd97
--- /dev/null
+++ b/libavformat/icecast.c
@@ -0,0 +1,230 @@
+/*
+ * Icecast Protocol Handler
+ * Copyright (c) 2014 Marvin Scholz
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
[FFmpeg-devel] [PATCH] libavformat/icecast.c Add Icecast protocol
From: ePirat
Fixed license header
---
Add Icecast protocol, a convenience wrapper for the HTTP protocol
---
Changelog| 1 +
configure| 1 +
doc/general.texi | 1 +
doc/protocols.texi | 42 +
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/icecast.c| 230 +++
libavformat/version.h| 4 +-
8 files changed, 279 insertions(+), 2 deletions(-)
create mode 100644 libavformat/icecast.c
diff --git a/Changelog b/Changelog
index 07cf1cf..54bb6ba 100644
--- a/Changelog
+++ b/Changelog
@@ -2,6 +2,7 @@ Entries are sorted chronologically from oldest to youngest
within each release,
releases are sorted from youngest to oldest.
version 2.3:
+- Icecast protocol
- AC3 fixed-point decoding
- shuffleplanes filter
- subfile protocol
diff --git a/configure b/configure
index b4ec1e6..a0b2354 100755
--- a/configure
+++ b/configure
@@ -2483,6 +2483,7 @@ gopher_protocol_select="network"
http_protocol_select="tcp_protocol"
httpproxy_protocol_select="tcp_protocol"
https_protocol_select="tls_protocol"
+icecast_protocol_select="http"
librtmp_protocol_deps="librtmp"
librtmpe_protocol_deps="librtmp"
librtmps_protocol_deps="librtmp"
diff --git a/doc/general.texi b/doc/general.texi
index 35db917..9ce0b31 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -1055,6 +1055,7 @@ performance on systems without hardware floating point
support).
@item HLS @tab X
@item HTTP @tab X
@item HTTPS@tab X
+@item Icecast @tab X
@item MMSH @tab X
@item MMST @tab X
@item pipe @tab X
diff --git a/doc/protocols.texi b/doc/protocols.texi
index 1cd96cc..cb75d92 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -293,6 +293,48 @@ The required syntax to play a stream specifying a cookie
is:
ffplay -cookies "nlqptid=nltid=tsn; path=/; domain=somedomain.com;"
http://somedomain.com/somestream.m3u8
@end example
+@section Icecast
+
+Icecast protocol
+
+@table @option
+@item ice_genre
+Set the genre of the stream.
+
+@item ice_name
+Set the name of the stream.
+
+@item ice_description
+Set the description of the stream.
+
+@item ice_url
+Set the stream website url.
+
+@item ice_public
+Set if the stream should be public.
+Default is 0 (not public).
+
+@item ice_password
+Password for the mountpoint.
+
+@item legacy_icecast
+If set to 1, enable support for legacy Icecast (Version < 2.4), using the
SOURCE method
+instead of the PUT method.
+
+@item content_type
+Set a specific content type for the stream.
+This MUST be set if streaming else than audio/mpeg
+
+@item user_agent
+Override the User-Agent header. If not specified the protocol will use a
+string describing the libavformat build. ("Lavf/")
+
+@end table
+
+@example
+icecast://[@var{username}[:@var{password}]@@]@var{server}:@var{port}/@var{mountpoint}
+@end example
+
@section mmst
MMS (Microsoft Media Server) protocol over TCP.
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 9017e06..4f64c94 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -484,6 +484,7 @@ OBJS-$(CONFIG_HLS_PROTOCOL) += hlsproto.o
OBJS-$(CONFIG_HTTP_PROTOCOL) += http.o httpauth.o urldecode.o
OBJS-$(CONFIG_HTTPPROXY_PROTOCOL)+= http.o httpauth.o urldecode.o
OBJS-$(CONFIG_HTTPS_PROTOCOL)+= http.o httpauth.o urldecode.o
+OBJS-$(CONFIG_ICECAST_PROTOCOL) += icecast.o
OBJS-$(CONFIG_MMSH_PROTOCOL) += mmsh.o mms.o asf.o
OBJS-$(CONFIG_MMST_PROTOCOL) += mmst.o mms.o asf.o
OBJS-$(CONFIG_MD5_PROTOCOL) += md5proto.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 00de817..5599bae 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -347,6 +347,7 @@ void av_register_all(void)
REGISTER_PROTOCOL(HTTP, http);
REGISTER_PROTOCOL(HTTPPROXY,httpproxy);
REGISTER_PROTOCOL(HTTPS,https);
+REGISTER_PROTOCOL(ICECAST, icecast);
REGISTER_PROTOCOL(MMSH, mmsh);
REGISTER_PROTOCOL(MMST, mmst);
REGISTER_PROTOCOL(MD5, md5);
diff --git a/libavformat/icecast.c b/libavformat/icecast.c
new file mode 100644
index 000..700bd97
--- /dev/null
+++ b/libavformat/icecast.c
@@ -0,0 +1,230 @@
+/*
+ * Icecast Protocol Handler
+ * Copyright (c) 2014 Marvin Scholz
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
[FFmpeg-devel] [PATCH] libavformat/icecast.c Add icecast protocol
From: ePirat
Here the actual patch, including the icecast.c, forgot to add it to my local
git.
---
Add Icecast protocol, a convenience wrapper for the HTTP protocol
---
Changelog| 1 +
configure| 1 +
doc/general.texi | 1 +
doc/protocols.texi | 42 +
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/icecast.c| 224 +++
libavformat/version.h| 4 +-
8 files changed, 273 insertions(+), 2 deletions(-)
create mode 100644 libavformat/icecast.c
diff --git a/Changelog b/Changelog
index 07cf1cf..54bb6ba 100644
--- a/Changelog
+++ b/Changelog
@@ -2,6 +2,7 @@ Entries are sorted chronologically from oldest to youngest
within each release,
releases are sorted from youngest to oldest.
version 2.3:
+- Icecast protocol
- AC3 fixed-point decoding
- shuffleplanes filter
- subfile protocol
diff --git a/configure b/configure
index b4ec1e6..a0b2354 100755
--- a/configure
+++ b/configure
@@ -2483,6 +2483,7 @@ gopher_protocol_select="network"
http_protocol_select="tcp_protocol"
httpproxy_protocol_select="tcp_protocol"
https_protocol_select="tls_protocol"
+icecast_protocol_select="http"
librtmp_protocol_deps="librtmp"
librtmpe_protocol_deps="librtmp"
librtmps_protocol_deps="librtmp"
diff --git a/doc/general.texi b/doc/general.texi
index 35db917..9ce0b31 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -1055,6 +1055,7 @@ performance on systems without hardware floating point
support).
@item HLS @tab X
@item HTTP @tab X
@item HTTPS@tab X
+@item Icecast @tab X
@item MMSH @tab X
@item MMST @tab X
@item pipe @tab X
diff --git a/doc/protocols.texi b/doc/protocols.texi
index 1cd96cc..cb75d92 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -293,6 +293,48 @@ The required syntax to play a stream specifying a cookie
is:
ffplay -cookies "nlqptid=nltid=tsn; path=/; domain=somedomain.com;"
http://somedomain.com/somestream.m3u8
@end example
+@section Icecast
+
+Icecast protocol
+
+@table @option
+@item ice_genre
+Set the genre of the stream.
+
+@item ice_name
+Set the name of the stream.
+
+@item ice_description
+Set the description of the stream.
+
+@item ice_url
+Set the stream website url.
+
+@item ice_public
+Set if the stream should be public.
+Default is 0 (not public).
+
+@item ice_password
+Password for the mountpoint.
+
+@item legacy_icecast
+If set to 1, enable support for legacy Icecast (Version < 2.4), using the
SOURCE method
+instead of the PUT method.
+
+@item content_type
+Set a specific content type for the stream.
+This MUST be set if streaming else than audio/mpeg
+
+@item user_agent
+Override the User-Agent header. If not specified the protocol will use a
+string describing the libavformat build. ("Lavf/")
+
+@end table
+
+@example
+icecast://[@var{username}[:@var{password}]@@]@var{server}:@var{port}/@var{mountpoint}
+@end example
+
@section mmst
MMS (Microsoft Media Server) protocol over TCP.
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 9017e06..4f64c94 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -484,6 +484,7 @@ OBJS-$(CONFIG_HLS_PROTOCOL) += hlsproto.o
OBJS-$(CONFIG_HTTP_PROTOCOL) += http.o httpauth.o urldecode.o
OBJS-$(CONFIG_HTTPPROXY_PROTOCOL)+= http.o httpauth.o urldecode.o
OBJS-$(CONFIG_HTTPS_PROTOCOL)+= http.o httpauth.o urldecode.o
+OBJS-$(CONFIG_ICECAST_PROTOCOL) += icecast.o
OBJS-$(CONFIG_MMSH_PROTOCOL) += mmsh.o mms.o asf.o
OBJS-$(CONFIG_MMST_PROTOCOL) += mmst.o mms.o asf.o
OBJS-$(CONFIG_MD5_PROTOCOL) += md5proto.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 00de817..5599bae 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -347,6 +347,7 @@ void av_register_all(void)
REGISTER_PROTOCOL(HTTP, http);
REGISTER_PROTOCOL(HTTPPROXY,httpproxy);
REGISTER_PROTOCOL(HTTPS,https);
+REGISTER_PROTOCOL(ICECAST, icecast);
REGISTER_PROTOCOL(MMSH, mmsh);
REGISTER_PROTOCOL(MMST, mmst);
REGISTER_PROTOCOL(MD5, md5);
diff --git a/libavformat/icecast.c b/libavformat/icecast.c
new file mode 100644
index 000..f17203a
--- /dev/null
+++ b/libavformat/icecast.c
@@ -0,0 +1,224 @@
+/*
+ * Icecast protocol for Libav
+ * Copyright (c) 2014 Marvin Scholz
+ *
+ * This file is part of Libav.
+ *
+ * Libav is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * Libav is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * M
[FFmpeg-devel] [PATCH] libavformat/icecast.c Add icecast protocol
From: ePirat
Add Icecast protocol, a convenience wrapper for the HTTP protocol
---
Changelog| 1 +
configure| 1 +
doc/general.texi | 1 +
doc/protocols.texi | 42 ++
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/version.h| 4 ++--
7 files changed, 49 insertions(+), 2 deletions(-)
diff --git a/Changelog b/Changelog
index 07cf1cf..54bb6ba 100644
--- a/Changelog
+++ b/Changelog
@@ -2,6 +2,7 @@ Entries are sorted chronologically from oldest to youngest
within each release,
releases are sorted from youngest to oldest.
version 2.3:
+- Icecast protocol
- AC3 fixed-point decoding
- shuffleplanes filter
- subfile protocol
diff --git a/configure b/configure
index b4ec1e6..a0b2354 100755
--- a/configure
+++ b/configure
@@ -2483,6 +2483,7 @@ gopher_protocol_select="network"
http_protocol_select="tcp_protocol"
httpproxy_protocol_select="tcp_protocol"
https_protocol_select="tls_protocol"
+icecast_protocol_select="http"
librtmp_protocol_deps="librtmp"
librtmpe_protocol_deps="librtmp"
librtmps_protocol_deps="librtmp"
diff --git a/doc/general.texi b/doc/general.texi
index 35db917..9ce0b31 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -1055,6 +1055,7 @@ performance on systems without hardware floating point
support).
@item HLS @tab X
@item HTTP @tab X
@item HTTPS@tab X
+@item Icecast @tab X
@item MMSH @tab X
@item MMST @tab X
@item pipe @tab X
diff --git a/doc/protocols.texi b/doc/protocols.texi
index 1cd96cc..cb75d92 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -293,6 +293,48 @@ The required syntax to play a stream specifying a cookie
is:
ffplay -cookies "nlqptid=nltid=tsn; path=/; domain=somedomain.com;"
http://somedomain.com/somestream.m3u8
@end example
+@section Icecast
+
+Icecast protocol
+
+@table @option
+@item ice_genre
+Set the genre of the stream.
+
+@item ice_name
+Set the name of the stream.
+
+@item ice_description
+Set the description of the stream.
+
+@item ice_url
+Set the stream website url.
+
+@item ice_public
+Set if the stream should be public.
+Default is 0 (not public).
+
+@item ice_password
+Password for the mountpoint.
+
+@item legacy_icecast
+If set to 1, enable support for legacy Icecast (Version < 2.4), using the
SOURCE method
+instead of the PUT method.
+
+@item content_type
+Set a specific content type for the stream.
+This MUST be set if streaming else than audio/mpeg
+
+@item user_agent
+Override the User-Agent header. If not specified the protocol will use a
+string describing the libavformat build. ("Lavf/")
+
+@end table
+
+@example
+icecast://[@var{username}[:@var{password}]@@]@var{server}:@var{port}/@var{mountpoint}
+@end example
+
@section mmst
MMS (Microsoft Media Server) protocol over TCP.
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 9017e06..4f64c94 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -484,6 +484,7 @@ OBJS-$(CONFIG_HLS_PROTOCOL) += hlsproto.o
OBJS-$(CONFIG_HTTP_PROTOCOL) += http.o httpauth.o urldecode.o
OBJS-$(CONFIG_HTTPPROXY_PROTOCOL)+= http.o httpauth.o urldecode.o
OBJS-$(CONFIG_HTTPS_PROTOCOL)+= http.o httpauth.o urldecode.o
+OBJS-$(CONFIG_ICECAST_PROTOCOL) += icecast.o
OBJS-$(CONFIG_MMSH_PROTOCOL) += mmsh.o mms.o asf.o
OBJS-$(CONFIG_MMST_PROTOCOL) += mmst.o mms.o asf.o
OBJS-$(CONFIG_MD5_PROTOCOL) += md5proto.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 00de817..5599bae 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -347,6 +347,7 @@ void av_register_all(void)
REGISTER_PROTOCOL(HTTP, http);
REGISTER_PROTOCOL(HTTPPROXY,httpproxy);
REGISTER_PROTOCOL(HTTPS,https);
+REGISTER_PROTOCOL(ICECAST, icecast);
REGISTER_PROTOCOL(MMSH, mmsh);
REGISTER_PROTOCOL(MMST, mmst);
REGISTER_PROTOCOL(MD5, md5);
diff --git a/libavformat/version.h b/libavformat/version.h
index 4e28112..053109e 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -30,8 +30,8 @@
#include "libavutil/version.h"
#define LIBAVFORMAT_VERSION_MAJOR 55
-#define LIBAVFORMAT_VERSION_MINOR 48
-#define LIBAVFORMAT_VERSION_MICRO 101
+#define LIBAVFORMAT_VERSION_MINOR 49
+#define LIBAVFORMAT_VERSION_MICRO 0
#define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
LIBAVFORMAT_VERSION_MINOR, \
--
1.8.5.2 (Apple Git-48)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
