Draft #1. For testing reasons, the patch turns on vfr mode
by default so it can be tested more quickly. The seeking
issues described below are problematic enough that this
behavior would be reversed when actually committed, unless
it can be satisfactorily resolved before then.
Currently has only
On 9/10/24 7:45 PM, Andrew Randrianasulu wrote:
I often saw suggestion to use -vf zscale but this is not default, and z.img
upstream seems to be in suspended animation:
https://github.com/sekrit-twc/zimg/issues/207
Because that's not upstream? It moved over a year ago.
https://bitbucket.org/t
On 7/29/24 12:43 AM, Stephen Hutchinson wrote:
These consts are only used in the switch(planar) case located in
avisynth_create_stream_video and nowhere else in the demuxer,
so move them into that function directly.
Signed-off-by: Stephen Hutchinson
---
libavformat/avisynth.c | 22
On 7/29/24 12:43 AM, Stephen Hutchinson wrote:
As part of this, the mutexes are no longer necessary, and
avisynth_read_close needs to check that avs->avs_library.library
still exists before it attempts to call avisynth_context_destroy
and dlclose.
Signed-off-by: Stephen Hutchin
On 7/19/24 12:56 PM, Stephen Hutchinson wrote:
Signed-off-by: Stephen Hutchinson
---
Changes compared to v1:
* Adjusted for patch #1's inclusion of dlclose
libavformat/avisynth.c | 4
1 file changed, 4 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
On 7/19/24 12:56 PM, Stephen Hutchinson wrote:
The atexit() handler in the avisynth demuxer was added because
there was a conflict in AvxSynth that arose due to their use
of C++ global objects, particularly in relation to having
added a logging function relying on log4cpp.
This conflict was
On 7/28/24 11:59 AM, Stephen Hutchinson wrote:
On 7/28/24 9:38 AM, Ramiro Polla wrote:
@@ -1134,6 +1089,7 @@ static av_cold int
avisynth_read_close(AVFormatContext *s)
return AVERROR_UNKNOWN;
avisynth_context_destroy(s->priv_data);
+ dlclose(avs_library.library);
Ma
These consts are only used in the switch(planar) case located in
avisynth_create_stream_video and nowhere else in the demuxer,
so move them into that function directly.
Signed-off-by: Stephen Hutchinson
---
libavformat/avisynth.c | 22 +++---
1 file changed, 11 insertions(+), 11
As part of this, the mutexes are no longer necessary, and
avisynth_read_close needs to check that avs->avs_library.library
still exists before it attempts to call avisynth_context_destroy
and dlclose.
Signed-off-by: Stephen Hutchinson
---
libavformat/avisynth.c |
On 7/28/24 9:38 AM, Ramiro Polla wrote:
@@ -1134,6 +1089,7 @@ static av_cold int avisynth_read_close(AVFormatContext *s)
return AVERROR_UNKNOWN;
avisynth_context_destroy(s->priv_data);
+dlclose(avs_library.library);
Maybe it's best to wrap this around an if (avs_library.lib
On 7/19/24 12:56 PM, Stephen Hutchinson wrote:
The atexit() handler in the avisynth demuxer was added because
there was a conflict in AvxSynth that arose due to their use
of C++ global objects, particularly in relation to having
added a logging function relying on log4cpp.
This conflict was
On 7/18/24 10:53 AM, Stefan Oltmanns via ffmpeg-devel wrote:
The AviSynth patch to remove it by Stephen Hutchinson does not introduce
it somewhere else. It is now only called directly at the start in case a
needed function cannot be loaded from the DLL.
From what I read dlclose is only needed
Signed-off-by: Stephen Hutchinson
---
Changes compared to v1:
* Adjusted for patch #1's inclusion of dlclose
libavformat/avisynth.c | 4
1 file changed, 4 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 26747671c0..b01263e010 100644
--- a/libavf
scripts on Unix-like OSes, the fact that the
atexit handler was no longer necessary was overlooked.
Signed-off-by: Stephen Hutchinson
---
Changes compared to v1:
* Added missing dlclose invocation to read_close
libavformat/avisynth.c | 46 +-
1 file changed, 1
On 7/7/24 1:46 PM, Stephen Hutchinson wrote:
On 7/7/24 9:50 AM, Andreas Rheinhardt wrote:
avisynth_context_destroy() is currently always called while holding the
lock (i.e. avisynth_mutex). Is this even necessary? It is clear that
avisynth_load_library() (and the check for whether it should be
Signed-off-by: Stephen Hutchinson
---
After asking about this and testing with AviSynth+ 3.7.3 and
AviSynth 2.6, it would appear that this isn't necessary.
If it was to handle an edge case and said case reappears,
it can be re-evaluated then.
libavformat/avisynth.c | 4
1 file chang
On 7/7/24 9:50 AM, Andreas Rheinhardt wrote:
avisynth_context_destroy() is currently always called while holding the
lock (i.e. avisynth_mutex). Is this even necessary? It is clear that
avisynth_load_library() (and the check for whether it should be called)
need the lock, but does anything else
scripts on Unix-like OSes, the fact that the
atexit handler was no longer necessary was overlooked.
Signed-off-by: Stephen Hutchinson
---
libavformat/avisynth.c | 45 --
1 file changed, 45 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat
On 6/22/24 6:02 AM, Stefan Oltmanns via ffmpeg-devel wrote:
I don't know the extact reason, but VapourSynth is not just a library
like avisynth, but an application that uses Python, meaning a lot of
dependencies.
If we want to be technical, then yes, VapourSynth is just a library,
with bindings
On 6/21/24 9:37 PM, Stefan Oltmanns via ffmpeg-devel wrote:
The current VapourSynth implementation is rarely used, as it links the
VapourSynth library at build time, making the resulting build unable to
run when VapourSynth is not installed. Therefore barely anyone compiles
with VapourSynth activ
On 7/16/23 1:12 AM, Stephen Hutchinson wrote:
AVISYNTH_INTERFACE_VERSION 10 fell in-between the releases of
3.7.2 and 3.7.3, and is required to be able to read the channel
layout information.
---
configure | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure b
On 7/16/23 1:12 AM, Stephen Hutchinson wrote:
---
libavformat/avisynth.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index b426ac343e..027e8c63f6 100644
--- a/libavformat/avisynth.c
+++ b/libavformat/avisynth.c
@@ -62,6 +62,7
AVISYNTH_INTERFACE_VERSION 10 fell in-between the releases of
3.7.2 and 3.7.3, and is required to be able to read the channel
layout information.
---
configure | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index dab3fb9036..a85122921e 100755
--- a/co
---
libavformat/avisynth.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index b426ac343e..027e8c63f6 100644
--- a/libavformat/avisynth.c
+++ b/libavformat/avisynth.c
@@ -62,6 +62,7 @@ typedef struct AviSynthLibrary {
AVSC_DECLARE_FU
AviSynth+ 3.7.3 adds the ability to define audio
channel layouts, and adding it to the libavformat
demuxer is trivial.
Bumps the minimum required version of the AviSynth+
headers to 3.7.3.
Stephen Hutchinson (2):
avisynth: pass audio channel layout
configure: bump minimum AviSynth+ header
On 8/25/22 3:46 AM, Steinar Apalnes wrote:
tor. 25. aug. 2022 kl. 02:11 skrev Stephen Hutchinson :
On 8/24/22 1:04 PM, Steinar Apalnes wrote:
tir. 8. feb. 2022 kl. 12:03 skrev Stephen Hutchinson :
* Field Order
* Chroma Location
* Color Transfer Characteristics
* Color Range
* Color
On 8/30/22 8:23 PM, Stephen Hutchinson wrote:
Signed-off-by: Stephen Hutchinson
---
libavformat/avisynth.c | 348 -
1 file changed, 174 insertions(+), 174 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 7bb2977383
On 8/30/22 8:23 PM, Stephen Hutchinson wrote:
Signed-off-by: Stephen Hutchinson
---
libavformat/avisynth.c | 52 ++
1 file changed, 52 insertions(+)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index d978e6ec40..7bb2977383 100644
--- a
On 8/30/22 8:23 PM, Stephen Hutchinson wrote:
Initialized to 1:1, but if the script sets these properties, it
will be set to those instead (0:0 disables it, apparently).
Signed-off-by: Stephen Hutchinson
---
libavformat/avisynth.c | 8
1 file changed, 8 insertions(+)
diff --git a
Signed-off-by: Stephen Hutchinson
---
libavformat/avisynth.c | 348 -
1 file changed, 174 insertions(+), 174 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 7bb2977383..b426ac343e 100644
--- a/libavformat/avisynth.c
+++ b
Signed-off-by: Stephen Hutchinson
---
libavformat/avisynth.c | 52 ++
1 file changed, 52 insertions(+)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index d978e6ec40..7bb2977383 100644
--- a/libavformat/avisynth.c
+++ b/libavformat
Initialized to 1:1, but if the script sets these properties, it
will be set to those instead (0:0 disables it, apparently).
Signed-off-by: Stephen Hutchinson
---
libavformat/avisynth.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
wrong than the already existing properties
do, which is what prompted adding the ability to switch frame property
reading on and off.
Stephen Hutchinson (3):
avformat/avisynth: read _SARNum/_SARDen from frame properties
avformat/avisynth: implement avisynth_flags option
avformat/avisynth
On 8/30/22 7:17 PM, Andreas Rheinhardt wrote:
{ "avisynth_flags", "set flags related to reading frame properties from
script (AviSynth+ v3.7.1 or higher)", OFFSET(flags), AV_OPT_TYPE_FLAGS,
{.i64 = 1}, 0, 1, AV_OPT_FLAG_DECODING_PARAM, "flags" },
This is wrong. It should be
{ "avisynth_flags", "
On 8/28/22 8:41 PM, Andreas Rheinhardt wrote:
This will make frameprops a global on-off which overrides everything
else even if some of the "else" stuff has been enabled explicitly. Worse
yet, if you want to disable everything except exactly one field, you
have to leave frameprops enabled and dis
Signed-off-by: Stephen Hutchinson
---
libavformat/avisynth.c | 50 +++---
1 file changed, 27 insertions(+), 23 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 99173a8d51..4e7395c22b 100644
--- a/libavformat/avisynth.c
+++ b
Signed-off-by: Stephen Hutchinson
---
libavformat/avisynth.c | 98 ++
1 file changed, 51 insertions(+), 47 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index ff4435758e..99173a8d51 100644
--- a/libavformat/avisynth.c
+++ b
Signed-off-by: Stephen Hutchinson
---
libavformat/avisynth.c | 112 +
1 file changed, 58 insertions(+), 54 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 945ce0e245..ff4435758e 100644
--- a/libavformat/avisynth.c
+++ b
Signed-off-by: Stephen Hutchinson
---
libavformat/avisynth.c | 82 ++
1 file changed, 43 insertions(+), 39 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 65d8448e89..945ce0e245 100644
--- a/libavformat/avisynth.c
+++ b
Signed-off-by: Stephen Hutchinson
---
libavformat/avisynth.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index c76b50421c..65d8448e89 100644
--- a/libavformat/avisynth.c
+++ b/libavformat
Signed-off-by: Stephen Hutchinson
---
libavformat/avisynth.c | 32 ++--
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 5d726d70a5..c76b50421c 100644
--- a/libavformat/avisynth.c
+++ b/libavformat
Allows turning the reading of frame properties entirely on and off.
Defaults to reading frame properties.
Signed-off-by: Stephen Hutchinson
---
libavformat/avisynth.c | 355 +
1 file changed, 179 insertions(+), 176 deletions(-)
diff --git a/libavformat
in.
Signed-off-by: Stephen Hutchinson
---
libavformat/avisynth.c | 27 ---
1 file changed, 24 insertions(+), 3 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index d978e6ec40..d503c7ed40 100644
--- a/libavformat/avisynth.c
+++ b/libavformat
Initialized to 1:1, but if the script sets these properties, it
will be set to those instead (0:0 disables it, apparently).
Signed-off-by: Stephen Hutchinson
---
libavformat/avisynth.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
requires
user opt-in with the -read_frameprop_sar boolean option.
And that then lead to fleshing out the others into their
own options, and a mass frameprop on/off setting.
Stephen Hutchinson (9):
avformat/avisynth: read _SARNum/_SARDen from frame properties
avformat/avisynth: add
On 8/24/22 1:04 PM, Steinar Apalnes wrote:
tir. 8. feb. 2022 kl. 12:03 skrev Stephen Hutchinson :
* Field Order
* Chroma Location
* Color Transfer Characteristics
* Color Range
* Color Primaries
* Matrix Coefficients
The existing TFF/BFF detection is retained as a fallback for
older versions
On 8/7/22 9:25 PM, Stephen Hutchinson wrote:
The AviSynth C API requires using avs_release_video_frame
whenever avs_get_frame has been used, but the recent addition
of frameprop reading to the demuxer was missing this in
avisynth_create_stream_video.
---
libavformat/avisynth.c | 1 +
1 file
---
libavformat/avisynth.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 5605fbefc4..3d9fa2be50 100644
--- a/libavformat/avisynth.c
+++ b/libavformat/avisynth.c
@@ -751,10 +751,10 @@ static int avisynth_create_stre
Fixes deprecation warning
---
libavformat/avisynth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 98b4d68a57..5605fbefc4 100644
--- a/libavformat/avisynth.c
+++ b/libavformat/avisynth.c
@@ -753,7 +753,7 @@ static int avis
The AviSynth C API requires using avs_release_video_frame
whenever avs_get_frame has been used, but the recent addition
of frameprop reading to the demuxer was missing this in
avisynth_create_stream_video.
---
libavformat/avisynth.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/
Stephen Hutchinson (3):
avformat/avisynth: add missing avs_release_video_frame
avformat/avisynth: use ch_layout.nb_channels for channel count
avformat/avisynth: cosmetics after nb_channels change
libavformat/avisynth.c | 9 +
1 file changed, 5 insertions(+), 4 deletions
On 6/13/22 2:55 PM, Hendrik Leppkes wrote:
This seems unrelated to this patch, which is about removing the
MAX_PATH limit. The code previously converted UTF-8 to ANSI, and still
does so now, just without the MAX_PATH limit.
Further improvements tangential to this topic can, and should, be
applied
On 6/11/22 1:01 PM, nil-admir...@mailo.com wrote:
Why not use the AviSynth mechanism that allows to supply a UTF-8 string?
https://github.com/AviSynth/AviSynthPlus/blob/c377916aa4146d2f4386852d91dc177d49103c16/avs_core/core/parser/script.cpp#L477-L481
Was not aware such a mechanism exists.
Co
Thus far I've avoided jumping into this because I genuinely do not care
about Windows' code page shenanigans or what-all, but because this seems
to be zeroing in on one thing in particular...
On 4/25/22 5:03 AM, nil-admir...@mailo.com wrote:
If you were to look at the code, you would've seen tha
On 2/27/22 3:03 PM, Stephen Hutchinson wrote:
If _FieldBased, _Matrix, _ColorRange, or _ChromaLocation haven't
been set, that absence would be interpreted as 0, leading to those
being set to case 0 instead of default. There is no case 0 for
_Primaries and _Transfer, so those were corr
ff-by: Stephen Hutchinson
---
libavformat/avisynth.c | 184 ++---
1 file changed, 101 insertions(+), 83 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 318588ff52..8ba2bdead2 100644
--- a/libavformat/avisynth.c
+++ b/libavformat/avisy
On 2/19/22 7:09 PM, Stephen Hutchinson wrote:
It's just a simple index.
Addresses Coverity issue 1500290
Signed-off-by: Stephen Hutchinson
---
libavformat/avisynth.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisy
On 2/19/22 4:41 PM, Stephen Hutchinson wrote:
Since the check got simplified and stdbool was no longer necessary
to include, neither is that variable. Silences a warning.
Signed-off-by: Stephen Hutchinson
---
libavformat/avisynth.c | 1 -
1 file changed, 1 deletion(-)
diff --git a
It's just a simple index.
Addresses Coverity issue 1500290
Signed-off-by: Stephen Hutchinson
---
libavformat/avisynth.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 03489f180f..318588ff52 100644
--- a/libavf
On 2/19/22 5:45 PM, Andreas Rheinhardt wrote:
Stephen Hutchinson:
Addresses Coverity issue 1500290
Signed-off-by: Stephen Hutchinson
---
libavformat/avisynth.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index
On 2/19/22 3:39 PM, Andreas Rheinhardt wrote:
+if (frameprop = true) {
+
+frame = avs_library.avs_get_frame(avs->clip, framedata);
framedata is completely uninitialized here. I presume it should be zero
(for the first frame)? (This is Coverity issue 1500290.)
I don't remember wh
Addresses Coverity issue 1500290
Signed-off-by: Stephen Hutchinson
---
libavformat/avisynth.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 03489f180f..cfb7b2a783 100644
--- a/libavformat/avisynth.c
+++ b/libavformat
Since the check got simplified and stdbool was no longer necessary
to include, neither is that variable. Silences a warning.
Signed-off-by: Stephen Hutchinson
---
libavformat/avisynth.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index
On 2/16/22 7:49 PM, Stephen Hutchinson wrote:
Trying to be clever about determining between interface version 8
and 8.1 ended up with pre-8.1 versions of AviSynth+ segfaulting.
The amount of time between interface version 8.1 and 9 is small,
so just restrict the frameprop awareness to version 9
On 2/17/22 5:19 PM, Helmut K. C. Tessarek wrote:
It's definitely not working, since I don't ship any dylibs. I always thought
3.5.1 li9nked a static lib, but I checked. It does not.
Even if I wanted to I couldn't ship any dylibs, since I can't build
AviSynthPlus on macOS 10.14.
It's really t
On 2/16/22 1:25 PM, Helmut K. C. Tessarek wrote:
On 2022-02-16 02:37, Stephen Hutchinson wrote:
There is another option, basically what Gyan suggested earlier: grab the
release build of 3.7.1, fetch the extra headers from the Github repo,
then copy either all the contents of the tarball's
Trying to be clever about determining between interface version 8
and 8.1 ended up with pre-8.1 versions of AviSynth+ segfaulting.
The amount of time between interface version 8.1 and 9 is small,
so just restrict the frameprop awareness to version 9 and call it
a day.
---
libavformat/avisynth.c |
On 2/16/22 12:10 AM, Helmut K. C. Tessarek wrote:
On 2022-02-15 22:50, Stephen Hutchinson wrote:
Those errors would indicate you're not on the 3.7 branch, because if the
filesystem submodule isn't present, it doesn't emit those errors, it
stops dead because of the missing
On 2/15/22 8:33 PM, Helmut K. C. Tessarek wrote:
Unfortunately this didn't work.
Building the new AviSynthPlus results in the following errors:
Those errors would indicate you're not on the 3.7 branch, because if the
filesystem submodule isn't present, it doesn't emit those errors, it
stops
On 2/15/22 5:02 PM, Helmut K. C. Tessarek wrote:
What is the solution?
I am compiling ffmpeg with AviSynthPlus-3.5.1 and my configure just errored
out with
ERROR: avisynth/avisynth_c.h avisynth/avs/version.h not found
Which makes sense because I don't have a version.h
Do I have to use the la
On 2/14/22 6:56 AM, Gyan Doshi wrote:
On 2022-02-14 05:04 am, Stephen Hutchinson wrote:
On 2/8/22 6:02 AM, Stephen Hutchinson wrote:
The headers from version 3.7.1 are needed in order to support
parsing of frame properties. avs/version.h has been generated
as part of the AviSynth+ build
On 2/8/22 6:02 AM, Stephen Hutchinson wrote:
The headers from version 3.7.1 are needed in order to support
parsing of frame properties. avs/version.h has been generated
as part of the AviSynth+ build process for a long time, but was
never installed with the includes until version 3.7.1a
On 2/8/22 6:02 AM, Stephen Hutchinson wrote:
* Field Order
* Chroma Location
* Color Transfer Characteristics
* Color Range
* Color Primaries
* Matrix Coefficients
The existing TFF/BFF detection is retained as a fallback for
older versions of AviSynth that can't access frame properties
On 2/8/22 6:02 AM, Stephen Hutchinson wrote:
From: emcodem
AviSynth works on frame-based video by default, which can
be either progressive or interlaced. Some filters can break
frames into half-height fields, at which point it considers
the clip to be field-based (avs_is_field_based can be
On 2/8/22 6:02 AM, Stephen Hutchinson wrote:
AviSynth+ 3.6.0 introduced support for frame properties, allowing
various metadata to be passed between filters or read out by
client programs. Using this, FFmpeg can read Color Range, Transfer
Characteristics, Matrix, Color Primaries, Chroma
been sufficient,
but a version check mechanism might be useful in the future.
This does not change the version compatibility with the library
itself; previous 3.x versions of AviSynth+ as well as AviSynth 2.6
can still be used with the demuxer.
Signed-off-by: Stephen Hutchinson
---
configure | 4
nt to detect them.
Signed-off-by: Stephen Hutchinson
---
libavformat/avisynth.c | 263 +++--
1 file changed, 250 insertions(+), 13 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 1e862a6a85..8bc39869a3 100644
--- a/libavformat/avisy
detect the field order of a typical video clip,
the frame needs to have been weaved back together already,
so avs_is_field_based should actually report 'false' when
checked.
Signed-off-by: Stephen Hutchinson
---
libavformat/avisynth.c | 11 ---
1 file changed, 4 insertions(+), 7
n non-frameprop-aware versions of AviSynth.
Stephen Hutchinson (2):
avisynth: use AviSynth+'s frame properties to set various fields
configure: check avisynth header version
emcodem (1):
avisynth: corrected interlace detection
configure | 4 +-
libavformat/avisyn
On 8/8/2021 12:31 AM, Gyan Doshi wrote:
On 2021-08-06 11:34 pm, James Almer wrote:
From: Matthieu Patou
Suggested-by: ffm...@fb.com
Signed-off-by: James Almer
---
fftools/cmdutils.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdu
Fixes http://trac.ffmpeg.org/ticket/9219
---
libavformat/isom_tags.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/isom_tags.c b/libavformat/isom_tags.c
index 1666b9d4a5..e2e589b658 100644
--- a/libavformat/isom_tags.c
+++ b/libavformat/isom_tags.c
@@ -312,6 +312,8 @@ const AVC
On 5/24/2021 11:03 AM, emcodem wrote:
Sorry for the delay on this, should have corrected it much earlier.
There was some confusion in the interlaced analysis. From 3rdparty decoders
perspective, a clip
can only be interlaced when it is NOT field_based. This is because in a
field_based clip, the
On 3/10/2021 2:48 PM, Marton Balint wrote:
On Tue, 9 Mar 2021, Stephen Hutchinson wrote:
On 3/9/2021 3:47 PM, Michael Niedermayer wrote:
Hi all
I will branch release/4.4 soon
then like always leave some time for testing, bugfixes, ... and then
make FFmeg 4.4 from release/4.4, its too
avs_is_color_space provides a generic way of checking whether the
video is RGB, and has been available through AVSC_API since 2.6.
This means that GetProcAddress doesn't have to run on every frame.
---
libavformat/avisynth.c | 27 +--
1 file changed, 5 insertions(+), 22 del
On 3/10/2021 2:48 PM, Marton Balint wrote:
On Tue, 9 Mar 2021, Stephen Hutchinson wrote:
On 3/9/2021 3:47 PM, Michael Niedermayer wrote:
Hi all
I will branch release/4.4 soon
then like always leave some time for testing, bugfixes, ... and then
make FFmeg 4.4 from release/4.4, its too long
On 3/10/2021 2:48 PM, Marton Balint wrote:
On Tue, 9 Mar 2021, Stephen Hutchinson wrote:
On 3/9/2021 3:47 PM, Michael Niedermayer wrote:
Hi all
I will branch release/4.4 soon
then like always leave some time for testing, bugfixes, ... and then
make FFmeg 4.4 from release/4.4, its too long
On 3/9/2021 3:47 PM, Michael Niedermayer wrote:
Hi all
I will branch release/4.4 soon
then like always leave some time for testing, bugfixes, ... and then
make FFmeg 4.4 from release/4.4, its too long since 4.3
These three AviSynth demuxer patches should probably go in before 4.4:
http://ffmp
From: emcodem
Fixes Trac ticket #8757
Signed-off-by: Stephen Hutchinson
---
Resubmitting with my signed-off so that it's clear that
I've given final approval and it shows up in Patchwork.
libavformat/avisynth.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/l
---
libavformat/avisynth.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index f029a0e842..4cd6d6bc90 100644
--- a/libavformat/avisynth.c
+++ b/libavformat/avisynth.c
@@ -42,6 +42,13 @@
#define AVISYNTH_LIB A
---
Open for bikeshedding, as I'm not too sure of
the names, but I didn't want to use anything
too close to regular AV_CODEC_ID* defines.
libavformat/avisynth.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.
On 1/17/21 1:23 PM, emco...@ffastrans.com wrote:
On 2021-01-17 09:02, wrote Stephen Hutchinson:
Comment bikeshedding aside, LGTM, but the avs_is* API usage added here
needs to be reflected in the AVSC_DECLARE_FUNC and LOAD_AVS_FUNC blocks.
If those parts of the API are present in 2.5, the
On 1/16/21 7:26 PM, emco...@ffastrans.com wrote:
The purpose of this is to tell ffmpeg which field order the returned
clip of the avisynth .avs script decided to finally deliver, which is
handy in an automated environment.
Interlacing is generally a very hard topic in avisynth, the huge comment
On 6/9/20 7:56 PM, Stephen Hutchinson wrote:
avs_is_color_space provides a generic way of checking whether the
video is RGB, and has been available since 2.6. This means that
GetProcAddress doesn't have to run on every frame.
---
Also should probably be applied to the 4.3 branch as
avs_is_color_space provides a generic way of checking whether the
video is RGB, and has been available since 2.6. This means that
GetProcAddress doesn't have to run on every frame.
---
Also should probably be applied to the 4.3 branch as well.
libavformat/avisynth.c | 27 +
On 3/24/2020 2:40 PM, Stephen Hutchinson wrote:
On 3/12/20 7:38 PM, Stephen Hutchinson wrote:
AviSynth+ now supports non-Windows OSes, making AvxSynth
obsolete. Since we no longer support AviSynth 2.5 (which is
essentially what AvxSynth is), remove AvxSynth support and
replace it with AviSynth
On 3/24/2020 2:39 PM, Stephen Hutchinson wrote:
Related to this are the following changes:
* Mention the two methods that AviSynth+ provides for installing
just the headers.
* Expand on users installing AviSynth on their system a little
more.
---
This is the only patch that needed changes
On 3/24/2020 2:40 PM, Stephen Hutchinson wrote:
On 3/12/20 7:38 PM, Stephen Hutchinson wrote:
---
libavformat/avisynth.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 43b65badc9..2c08ace8db 100644
--- a
On 3/12/20 7:38 PM, Stephen Hutchinson wrote:
---
libavformat/avisynth.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 43b65badc9..2c08ace8db 100644
--- a/libavformat/avisynth.c
+++ b/libavformat/avisynth.c
On 3/12/20 7:37 PM, Stephen Hutchinson wrote:
---
compat/avisynth/avisynth_c.h | 1264 -
compat/avisynth/avs/capi.h| 94 --
compat/avisynth/avs/config.h | 70 -
compat/avisynth/avs/types.h | 57
On 3/12/20 7:38 PM, Stephen Hutchinson wrote:
AviSynth+ now supports non-Windows OSes, making AvxSynth
obsolete. Since we no longer support AviSynth 2.5 (which is
essentially what AvxSynth is), remove AvxSynth support and
replace it with AviSynth+.
As a result, the USING_AVISYNTH defines can
1 - 100 of 209 matches
Mail list logo
