From: softworkz
Signed-off-by: softworkz
---
libavformat/asfdec_f.c | 168 ++---
1 file changed, 108 insertions(+), 60 deletions(-)
diff --git a/libavformat/asfdec_f.c b/libavformat/asfdec_f.c
index 95cab8b960..d50682b901 100644
--- a/libavformat/asfdec_f.c
From: softworkz
Signed-off-by: softworkz
---
libavformat/asfdec_f.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/asfdec_f.c b/libavformat/asfdec_f.c
index cb396cccfe..95cab8b960 100644
--- a/libavformat/asfdec_f.c
+++ b/libavformat/asfdec_f.c
@@ -324,7 +324,7
From: softworkz
Signed-off-by: softworkz
---
libavformat/asfdec_f.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/asfdec_f.c b/libavformat/asfdec_f.c
index fae15d9b05..cb396cccfe 100644
--- a/libavformat/asfdec_f.c
+++ b/libavformat/asfdec_f.c
@@ -978,6 +978,7 @@ static int as
From: softworkz
Signed-off-by: softworkz
---
libavformat/asfdec_f.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavformat/asfdec_f.c b/libavformat/asfdec_f.c
index 91c3874ac7..fae15d9b05 100644
--- a/libavformat/asfdec_f.c
+++ b/libavformat/asfdec_f.c
@@ -1191,7 +119
From: softworkz
such as:
- bugprone-macro-parentheses
- wextra-semi-stmt
Signed-off-by: softworkz
---
libavformat/asfdec_f.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/libavformat/asfdec_f.c b/libavformat/asfdec_f.c
index 81a29f99d5..91c3874a
From: softworkz
Signed-off-by: softworkz
---
libavformat/asfdec_f.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/libavformat/asfdec_f.c b/libavformat/asfdec_f.c
index cb7da2d679..81a29f99d5 100644
--- a/libavformat/asfdec_f.c
+++ b/libavformat/asfdec_f.c
@@ -281,
From: softworkz
These three are closely related and can't be separated easily:
In get_tag, the code was adding 22 bytes (in order to allow
it to hold 64bit numbers as string) to the value len for creating
creating a buffer. This was unnecessarily imposing a
size-constraint on the value_len param
From: softworkz
The value_len is an uint32 not an int32 per spec. That
value must not be truncated, neither by casting to int, nor by any
conditional checks, because at the end of get_tag, this value is
needed to move forward in parsing. When the len value gets
modified, the parsing may break.
S
From: softworkz
unsupported values
get_value had a return type of int, which means that reading
QWORDS (case 4) was broken due to truncation of the result from
avio_rl64().
Signed-off-by: softworkz
---
libavformat/asfdec_f.c | 57 +++---
1 file changed, 43
From: softworkz
The spec allows attachment sizes of up to UINT32_MAX while
we can handle only sizes up to INT32_MAX (in downstream
code)
The debug.assert in get_tag didn't really address this,
and truncating the value_len in calling methods cannot
be used because the length value is required in
The spec allows attachment sizes of up to UINT32_MAX while we can handle
only sizes up to INT32_MAX (in downstream code)
The debug.assert in get_tag didn't really address this, and truncating the
value_len in calling methods cannot be used because the length value is
required in order to continue
> -Original Message-
> From: ffmpeg-devel On Behalf Of Martin
> Storsjö
> Sent: Friday, May 20, 2022 11:13 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using av_fopen_utf8
>
> Provide a header based inline reimplementation of it.
>
> Using av_fop
From: Matt Oliver
Was "[PATCH] libx264: Do not explicitly set X264_API_IMPORTS"
Setting X264_API_IMPORTS only affects msvc builds and it breaks
linking to static builds (although is required for shared builds).
This flag is set by x264 in its pkgconfig as required since build
158 (a615f027ed172e
---
libavfilter/af_arnndn.c | 2 +-
libavfilter/opencl.c | 2 +-
libavfilter/vf_curves.c | 2 +-
libavfilter/vf_dnn_classify.c | 2 +-
libavfilter/vf_dnn_detect.c | 2 +-
libavfilter/vf_fieldhint.c| 2 +-
libavfilter/vf_lut3d.c| 4 ++--
libavfilter/vf_nnedi.c
Since every DLL can use an individual CRT on Windows, having
an exported function that opens a FILE* won't work if that
FILE* is going to be used from a different DLL (or from user
application code).
Internally within the libraries, the issue can be worked around
by duplicating the function in all
Provide a header based inline reimplementation of it.
Using av_fopen_utf8 doesn't work outside of the libraries when built
with MSVC as shared libraries (in the default configuration, where
each DLL gets a separate statically linked CRT).
---
fftools/ffmpeg_opt.c | 3 +-
fftools/fopen_utf8.h | 7
Relevant questions from the patch submission checklist:
Explanation why it changes things like it does:
Sometimes input data may have custom headers that ffmpeg is not expected to
understand. It seems to me, this is why `-skip_initial_bytes` exists. From
the documentation it sounds like this option
Firstly, I'm sorry about those patches without changes mentioned.
As changes, there was just a whitespace that I removed.
I'm not used at all to sending matches through mailing list. And Patchwork
failed to apply my patches, so I resend it trying to see if the way I sent the
patch was wrong.
I
On Fri, 20 May 2022, Trystan Mata wrote:
From 2bdef1bdb93efa40b7d3fe21270f9f23465bee90 Mon Sep 17 00:00:00 2001
From: Trystan Mata
Date: Fri, 20 May 2022 14:26:49 +0200
Subject: [PATCH] avcodec/mfenc: Dynamically load MFPlat.DLL
Allow builds of FFmpeg with MediaFoundation to work under N editi
From 2bdef1bdb93efa40b7d3fe21270f9f23465bee90 Mon Sep 17 00:00:00 2001
From: Trystan Mata
Date: Fri, 20 May 2022 14:26:49 +0200
Subject: [PATCH] avcodec/mfenc: Dynamically load MFPlat.DLL
Allow builds of FFmpeg with MediaFoundation to work under N editions of
Windows which are without MediaFounda
Allow builds of FFmpeg with MediaFoundation to work under N editions of
Windows which are without MediaFoundation by default.
Signed-off-by: Trystan Mata
---
configure | 4 +-
libavcodec/mf_utils.c | 26 +++--
libavcodec/mf_utils.h | 16 ++--
libavcodec/mfenc.c| 91
On 2022-05-20 12:16 pm, Paul B Mahol wrote:
lgtm
Pushed as 9ab20b1614194280b862d98dfcdb7b1bcff03329
Thanks,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link abo
> -Original Message-
> From: ffmpeg-devel On Behalf Of nil-
> admir...@mailo.com
> Sent: Friday, May 20, 2022 7:52 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2 1/2] avutil/wchar_filename,
> file_open: Support long file names on Windows
>
> > Yes, that's true
> Yes, that's true. But there are hundreds of other things someone could
> define which makes compilation fail.
Doesn't mean that yet another such thing should be added by incorrectly
redefining structs already defined correctly by system headers.
> Probably you didn't spot it. It's already there
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Derek Buitenhuis
> Sent: Friday, May 20, 2022 6:55 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2] avcodec/libx264: allow to
> disable definition of X264_API_IMPORTS macro
>
> On 5/20/2022 5:51 PM, Martin
On Fri, 20 May 2022 12:28:15 +0200 Michael Niedermayer
wrote:
> On Wed, May 18, 2022 at 08:27:48PM +0200, Michael Niedermayer wrote:
> > On Wed, May 18, 2022 at 08:23:38PM +0200, Michael Niedermayer wrote:
> > > On Wed, May 18, 2022 at 11:18:17AM -0400, Leo Izen wrote:
> > > > This commit moves s
Leo Izen:
> On 5/20/22 12:01, Andreas Rheinhardt wrote:
>> Leo Izen:
>>> This commit moves some of the functionality from avfilter/colorspace
>>> into avutil/csp and exposes it as a public API so it can be used by
>>> libavcodec and/or libavformat. It also converts those structs from
>>> double val
On 5/20/2022 5:51 PM, Martin Storsjö wrote:
> Maybe just drop support for older versions when on Windows? That should
> cover those cases (even if ffmpeg is built with msvc but x264 with mingw,
> or vice versa) quite well, while still not bothering other platforms at
> all.
Yeah, that seems rea
On Fri, 20 May 2022, Derek Buitenhuis wrote:
On 5/20/2022 5:37 PM, Soft Works wrote:
But if Matt's patch would be agreeable, then that would surely be
the best outcome.
I can rebase and resubmit his patch if you would find it agreeable.
Ah - that was not clear to me.
If Ubuntu LTS does inde
On 5/20/2022 5:37 PM, Soft Works wrote:
> But if Matt's patch would be agreeable, then that would surely be
> the best outcome.
>
> I can rebase and resubmit his patch if you would find it agreeable.
Ah - that was not clear to me.
If Ubuntu LTS does indeed ship such an old x264, the fallback di
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Derek Buitenhuis
> Sent: Friday, May 20, 2022 6:23 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2] avcodec/libx264: allow to
> disable definition of X264_API_IMPORTS macro
>
> On 5/20/2022 4:23 PM, softw
On Fri, May 20, 2022 at 6:23 PM Derek Buitenhuis
wrote:
>
> On 5/20/2022 4:23 PM, softworkz wrote:
> > A better fix would eventually be this one:
> > http://ffmpeg.org/pipermail/ffmpeg-devel/2021-October/287426.html
> >
> > But there has been disagreement and the issue stalled.
>
> I did not see a
On Fri, 20 May 2022 08:53:35 -0300 James Almer wrote:
>
>
> On 5/20/2022 7:28 AM, Michael Niedermayer wrote:
> > On Wed, May 18, 2022 at 08:27:48PM +0200, Michael Niedermayer wrote:
> >> On Wed, May 18, 2022 at 08:23:38PM +0200, Michael Niedermayer wrote:
> >>> On Wed, May 18, 2022 at 11:18:17AM
On 5/20/2022 4:23 PM, softworkz wrote:
> A better fix would eventually be this one:
> http://ffmpeg.org/pipermail/ffmpeg-devel/2021-October/287426.html
>
> But there has been disagreement and the issue stalled.
I did not see a single person disagree with Matt's patch? If someone did,
I missed it.
On 5/20/22 12:01, Andreas Rheinhardt wrote:
Leo Izen:
This commit moves some of the functionality from avfilter/colorspace
into avutil/csp and exposes it as a public API so it can be used by
libavcodec and/or libavformat. It also converts those structs from
double values to AVRational to make re
On 5/20/22 11:50, Anton Khirnov wrote:
The commit message claims it will be used in lavc and lavf. Seems to me
like a strong sign that it really should be public.
As far as I'm concerned, avpriv should not exist at all.
The intention of this patch is a precursor to using it in avcodec.
S
Leo Izen:
> This commit moves some of the functionality from avfilter/colorspace
> into avutil/csp and exposes it as a public API so it can be used by
> libavcodec and/or libavformat. It also converts those structs from
> double values to AVRational to make regression testing easier and
> more cons
This commit moves some of the functionality from avfilter/colorspace
into avutil/csp and exposes it as a public API so it can be used by
libavcodec and/or libavformat. It also converts those structs from
double values to AVRational to make regression testing easier and
more consistent.
---
libavfi
This patch is a work in progress example for swapping these
structs from doubles to AVRationals.
There's two main discussions here to be had
- Is this API to be exposed as avpriv_ or av_?
- Should these structs use AVRational or double values?
I don't believe a consensus has been reached on this
Quoting James Almer (2022-05-20 13:53:35)
> >
> > 3. avpriv_ vs av_
> > avpriv is evil, it combines the pain of ABI/API compatibility while the
> > public cant use it
>
> Not making it public allows us to not commit to a fixed design *now*.
> Unless there's a clear need for this to be p
From: softworkz
When MSVC is used, the definition of X264_API_IMPORTS is
required for shared linking to libx264.dll, but it must
not be defined in case of statically linking to libx264.
Defining DISABLE_X264_API_IMPORTS allows to disable the
definition of X264_API_IMPORTS for those cases.
This
---
Fixed 2pass breakage.
Sent a separate patchset adding tests for 2pass
---
fftools/ffmpeg.c | 84
1 file changed, 21 insertions(+), 63 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 0e62c39522..9b69a5a2c9 100644
--- a/fftoo
Hi,
On Fri, May 20, 2022 at 9:11 AM Michael Niedermayer
wrote:
> On Fri, May 20, 2022 at 07:26:56AM -0400, Ronald S. Bultje wrote:
> > On Fri, May 20, 2022 at 6:28 AM Michael Niedermayer <
> mich...@niedermayer.cc>
> > > 1. exactly representing values
> >
> > This isn't actually what I meant whe
Allow builds of FFmpeg with MediaFoundation to work under N editions of
Windows which are without MediaFoundation by default.
Signed-off-by: Trystan Mata
---
configure | 4 +-
libavcodec/mf_utils.c | 26 ++--
libavcodec/mf_utils.h | 16 ++--
libavcodec/mfenc.c| 92 +
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Derek Buitenhuis
> Sent: Friday, May 20, 2022 3:13 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] avcodec/libx264: don't define
> X264_API_IMPORTS when compiling static
>
> On 5/20/2022 2:06 PM, Soft Works
On Fri, May 20, 2022 at 08:53:35AM -0300, James Almer wrote:
>
>
> On 5/20/2022 7:28 AM, Michael Niedermayer wrote:
> > On Wed, May 18, 2022 at 08:27:48PM +0200, Michael Niedermayer wrote:
> > > On Wed, May 18, 2022 at 08:23:38PM +0200, Michael Niedermayer wrote:
> > > > On Wed, May 18, 2022 at 1
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Derek Buitenhuis
> Sent: Friday, May 20, 2022 2:50 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] avcodec/libx264: don't define
> X264_API_IMPORTS when compiling static
>
> On 5/20/2022 1:07 PM, Soft Works
On 5/20/2022 2:06 PM, Soft Works wrote:
>> As per Thilo's explanation, I think this is a more appropraite fix:
>>
>> http://ffmpeg.org/pipermail/ffmpeg-devel/2021-October/287426.html
>
> You say you think this is a more appropriate fix "as per Timo's explanation"
> because of the following mes
Hi Ronald
On Fri, May 20, 2022 at 07:26:56AM -0400, Ronald S. Bultje wrote:
> Hi Michael,
>
> On Fri, May 20, 2022 at 6:28 AM Michael Niedermayer
> wrote:
>
> > 1. exactly representing values
> >
>
> This isn't actually what I meant when I made the argument. If the spec says
> "0.137", I'd exp
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Derek Buitenhuis
> Sent: Friday, May 20, 2022 3:00 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] avcodec/libx264: don't define
> X264_API_IMPORTS when compiling static
>
> On 5/20/2022 1:54 PM, Soft Works
On 5/20/2022 1:54 PM, Soft Works wrote:
> Still wrong. Because I had posted that link.
No, not wrong. I was alluding to:
http://ffmpeg.org/pipermail/ffmpeg-devel/2022-May/296605.html - and not the
link.
In any case, thanks for the needlessly aggressive email.
- Derek
__
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Derek Buitenhuis
> Sent: Friday, May 20, 2022 2:51 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] avcodec/libx264: don't define
> X264_API_IMPORTS when compiling static
>
> On 5/20/2022 1:49 PM, Derek Buit
On 5/20/2022 1:49 PM, Derek Buitenhuis wrote:
> As per Thilo's explanation, I think this is a more appropraite fix:
Apologies, I meant to type *Timo*.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmp
On 5/20/2022 1:07 PM, Soft Works wrote:
> I'm working with regular Visual Studio projects, though.
> Even dependencies like libx264 are compiled in their own
> VS projects.
> There's no MSYS2, no make, no pkg-conf involved.
Things should not be added to FFmpeg in support of
non-standard build syst
On 5/20/22 06:28, Michael Niedermayer wrote:
2. someone said, you need to pick a denominator when doing float -> rational
av_d2q() will pick the best denominator for you.
av_d2q() requires you to pass a maximum denominator, which essentially
determines precision of the conversion. You s
> -Original Message-
> From: ffmpeg-devel On Behalf Of Timo
> Rothenpieler
> Sent: Friday, May 20, 2022 1:38 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] avcodec/libx264: don't define
> X264_API_IMPORTS when compiling static
>
> On 20/05/2022 12:39, Soft Works
On 5/20/2022 7:28 AM, Michael Niedermayer wrote:
On Wed, May 18, 2022 at 08:27:48PM +0200, Michael Niedermayer wrote:
On Wed, May 18, 2022 at 08:23:38PM +0200, Michael Niedermayer wrote:
On Wed, May 18, 2022 at 11:18:17AM -0400, Leo Izen wrote:
This commit moves some of the functionality fr
On 20/05/2022 12:39, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of Timo
Rothenpieler
Sent: Friday, May 20, 2022 12:18 PM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] avcodec/libx264: don't define
X264_API_IMPORTS when compiling static
On 20/0
Hi Michael,
On Fri, May 20, 2022 at 6:28 AM Michael Niedermayer
wrote:
> 1. exactly representing values
>
This isn't actually what I meant when I made the argument. If the spec says
"0.137", I'd expect to be able to git grep the source code for "0.137" and
find where it's defined. This is lost
> -Original Message-
> From: ffmpeg-devel On Behalf Of Timo
> Rothenpieler
> Sent: Friday, May 20, 2022 12:18 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] avcodec/libx264: don't define
> X264_API_IMPORTS when compiling static
>
> On 20/05/2022 00:52, softworkz
On Wed, May 18, 2022 at 08:27:48PM +0200, Michael Niedermayer wrote:
> On Wed, May 18, 2022 at 08:23:38PM +0200, Michael Niedermayer wrote:
> > On Wed, May 18, 2022 at 11:18:17AM -0400, Leo Izen wrote:
> > > This commit moves some of the functionality from avfilter/colorspace
> > > into avutil/csp
Anton Khirnov:
> jpeg2000 will be chosen by default, there is no reason to prescribe it
> explicitly. No other test does so.
> ---
> tests/fate/vcodec.mak | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/tests/fate/vcodec.mak b/tests/fate/vcodec.mak
> index 3c9b7f1ff7..
On 20/05/2022 00:52, softworkz wrote:
From: softworkz
The definition of X264_API_IMPORTS is required for shared linking
(when MSVC is used) but it must not be defined in case of static
builds as is stated in x264.h:
This doesn't seem right. It's about shared or static linking of libx264
itse
---
tests/fate-run.sh | 12
tests/fate/vcodec.mak | 7 +--
tests/ref/vsynth/vsynth1-ffv1-2pass | 4
tests/ref/vsynth/vsynth2-ffv1-2pass | 4
tests/ref/vsynth/vsynth3-ffv1-2pass | 4
tests/ref/vsynth/vsynth_lena
Use the global stream index rather than an unrelated variable in the
filename.
Broken in 6d5d9246042.
---
fftools/ffmpeg_opt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 47e8b9b7bd..c719bc2d0a 100644
--- a/fftools/ffmpeg_o
enc_dec() performs two ffmpeg runs - the first one encoding a source
file into a specified output format, the second one decoding previously
encoded file.
The arguments to this function currently have confusing names - e.g.
dec_opt contains _output_ (i.e. encoding) options for the second
(decoding
jpeg2000 will be chosen by default, there is no reason to prescribe it
explicitly. No other test does so.
---
tests/fate/vcodec.mak | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/tests/fate/vcodec.mak b/tests/fate/vcodec.mak
index 3c9b7f1ff7..c19fb8633a 100644
--- a/tests/f
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Derek Buitenhuis
> Sent: Friday, May 20, 2022 10:50 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] avcodec/libx264: don't define
> X264_API_IMPORTS when compiling static
>
> On 5/19/2022 11:52 PM, softwork
On 5/19/2022 11:52 PM, softworkz wrote:
> This commit adds a check for the definition of _LIB which indicates
> static linking.
Doesn't this indiate that FFmpeg is being compiled statically, and not
necessarily that x264 is? Googling also seems to indicate that this
definition is no longer availab
Michael Niedermayer:
> The code is only called if size is > 0 so buf should not be NULL
>
> Helps: CID610554
>
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/matroskadec.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
70 matches
Mail list logo
