On 07/10/2024 20:09, Niklas Haas wrote:
On Mon, 07 Oct 2024 20:03:06 +0200 Michael Niedermayer
wrote:
On Mon, Oct 07, 2024 at 06:47:24PM +0200, Niklas Haas wrote:
On Mon, 07 Oct 2024 00:15:32 +0200 Michael Niedermayer
wrote:
On Sat, Oct 05, 2024 at 09:23:55PM +0200, Niklas Haas wrote:
Fr
On 02/10/2024 14:05, James Almer wrote:
On 10/2/2024 7:11 AM, Tobias Rapp wrote:
Adds missing ifdef guards to function prototypes depending on
definitions from
dxva.h which are not available in Mingw-w64 version 4.0. The
configure script
already checks for HEVC/VP9 types in dxva.h.
Signed
Adds missing ifdef guards to function prototypes depending on definitions from
dxva.h which are not available in Mingw-w64 version 4.0. The configure script
already checks for HEVC/VP9 types in dxva.h.
Signed-off-by: Tobias Rapp
---
libavcodec/dxva2_internal.h | 4
1 file changed, 4
On 15/09/2024 14:41, Anton Khirnov wrote:
Quoting Antoni Bizoń (2024-09-13 15:20:16)
Hello,
I recently upgraded FFmpeg to version 6.1 in my web application and
encountered a change while running my app's tests. After the upgrade,
ffprobe reported an r_frame_rate of 60/1 instead of the expected
On 13/06/2024 20:16, radu.taraib...@gmail.com wrote:
Update as discussed
The mode options are fine to me, will leave the implementation check and
final push to Michael.
(Only if you update the patch anyway I'd suggest rewording the commit
message to rephrase the "legacy" mode there, too, a
On 13/06/2024 13:21, radu.taraib...@gmail.com wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of Tobias
Rapp
Sent: joi, 13 iunie 2024 12:52
To:ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH v3] area changed: scdet filter
On 12/06/2024 21:51,radu.taraib...@gmail.com
On 12/06/2024 21:51, radu.taraib...@gmail.com wrote:
[...]
diff --git a/doc/filters.texi b/doc/filters.texi
index bfa8ccec8b..53814e003b 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -21797,6 +21797,22 @@ Default value is @code{10.}.
@item sc_pass, s
Set the flag to pass scene chang
On 01/05/2024 18:52, Ville Syrjälä wrote:
[...]
So those should be cherry-picked to the next 6.1 release (assuming
there will be one). Both cherry-pick cleanly, and afterwards the
leak is gone from the 6.1 branch as well.
From the release/6.1 branch it seems that a 6.1.2 release has been
pre
On 25/04/2024 00:42, Marton Balint wrote:
On Mon, 22 Apr 2024, Devin Heitmueller wrote:
Hello,
I suspect this topic has been visited a number of times over the
years, but I figured I should re-raise it.
In the compressed domain, field ordering is represented by the
AVFieldOrder enumeration
On 27/03/2024 14:04, Tobias Rapp wrote:
On 27/03/2024 13:53, Anton Khirnov wrote:
Quoting Tobias Rapp (2024-03-27 13:46:40)
On 27/03/2024 13:06, Stefano Sabatini wrote:
On date Wednesday 2024-03-27 11:51:31 +0100, Tobias Rapp wrote:
Depending on the filters used the filtergraph can produce
On 26/03/2024 13:33, Tobias Rapp wrote:
On 15/03/2024 09:53, Tobias Rapp wrote:
The "RIFF" identifier and chunk size fields should not be included
within the size value.
---
tests/audiogen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/audiogen
On 27/03/2024 13:53, Anton Khirnov wrote:
Quoting Tobias Rapp (2024-03-27 13:46:40)
On 27/03/2024 13:06, Stefano Sabatini wrote:
On date Wednesday 2024-03-27 11:51:31 +0100, Tobias Rapp wrote:
Depending on the filters used the filtergraph can produce trailing data
after feeding it the last
On 27/03/2024 13:06, Stefano Sabatini wrote:
On date Wednesday 2024-03-27 11:51:31 +0100, Tobias Rapp wrote:
Depending on the filters used the filtergraph can produce trailing data
after feeding it the last input frame. Update the example to include the
necessary loop for draining the
Depending on the filters used the filtergraph can produce trailing data
after feeding it the last input frame. Update the example to include the
necessary loop for draining the filtergrap.
Signed-off-by: Tobias Rapp
---
doc/examples/decode_filter_video.c | 19 +++
1 file changed
Depending on the filters used the filtergraph can produce trailing data
after feeding it the last input frame. Update the example to include the
necessary loop for draining the filtergrap.
Signed-off-by: Tobias Rapp
---
doc/examples/decode_filter_audio.c | 19 +++
1 file changed
On 15/03/2024 09:53, Tobias Rapp wrote:
The "RIFF" identifier and chunk size fields should not be included
within the size value.
---
tests/audiogen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/audiogen.c b/tests/audiogen.c
index c43bb70..df1dea6 10
On 21/03/2024 10:40, Marton Balint wrote:
On Thu, 21 Mar 2024, Tobias Rapp wrote:
On 19/03/2024 20:14, Marton Balint wrote:
On Tue, 19 Mar 2024, Michael Niedermayer wrote:
On Sun, Mar 17, 2024 at 08:57:29PM +0100, Marton Balint wrote:
- Only parse the defined masks in
On 19/03/2024 20:14, Marton Balint wrote:
On Tue, 19 Mar 2024, Michael Niedermayer wrote:
On Sun, Mar 17, 2024 at 08:57:29PM +0100, Marton Balint wrote:
- Only parse the defined masks in dwChannelMask, unless
strict_std_compliance
is less than normal. This matches with the behaviour of th
The "RIFF" identifier and chunk size fields should not be included
within the size value.
---
tests/audiogen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/audiogen.c b/tests/audiogen.c
index c43bb70..df1dea6 100644
--- a/tests/audiogen.c
+++ b/tests/audiogen.c
@@ -109
On 14/03/2024 23:04, Marton Balint wrote:
On Thu, 14 Mar 2024, Tobias Rapp wrote:
On 08/03/2024 01:53, Marton Balint wrote:
This makes the wav and pcm demuxer demux bigger packets, which is more
efficient.
[...]
+0, 136000, 136000, 2000, 24000
On 08/03/2024 01:53, Marton Balint wrote:
This makes the wav and pcm demuxer demux bigger packets, which is more
efficient.
Signed-off-by: Marton Balint
---
libavformat/pcm.c | 2 +-
tests/ref/acodec/pcm-s16be| 2 +-
tests/ref/acodec/pcm-s
On 11/03/2024 14:28, Anton Khirnov wrote:
Quoting Martin Storsjö (2024-03-11 13:29:15)
On Mon, 11 Mar 2024, Anton Khirnov wrote:
Quoting Tobias Rapp (2024-03-11 11:12:38)
On 10/03/2024 23:49, Anton Khirnov wrote:
Quoting James Almer (2024-03-10 23:29:27)
On 3/10/2024 7:24 PM, Anton
On 10/03/2024 23:49, Anton Khirnov wrote:
Quoting James Almer (2024-03-10 23:29:27)
On 3/10/2024 7:24 PM, Anton Khirnov wrote:
Quoting Michael Niedermayer (2024-03-10 20:21:47)
On Sun, Mar 10, 2024 at 07:13:18AM +0100, Anton Khirnov wrote:
Quoting Michael Niedermayer (2024-03-10 04:36:29)
w
://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-November/316609.html
If the current GA stays as it is, then i propose the following people
(this list was quickly made and certainly has omisions and possibly errors,
check anything thats important to you!)
[...]
Tobias Rapp(vf_readvitc
On 15/10/2023 04:59, Stefano Sabatini wrote:
On date Sunday 2023-10-15 03:09:14 +0200, Timo Rothenpieler wrote:
Isn't a change like that practically an ABI break, and thus would need to
happen on a major bump?
Yes, but in practice we are not tracking changes in the XML format,
and major bumps
On 17/07/2023 08:47, Tobias Rapp wrote:
On 07/07/2023 14:44, Tobias Rapp wrote:
---
doc/filters.texi | 3 +++
libavfilter/vf_overlay.c | 36 +++-
libavfilter/vf_overlay.h | 1 +
3 files changed, 39 insertions(+), 1 deletion(-)
[...]
Would like
On 07/07/2023 14:44, Tobias Rapp wrote:
---
doc/filters.texi | 3 +++
libavfilter/vf_overlay.c | 36 +++-
libavfilter/vf_overlay.h | 1 +
3 files changed, 39 insertions(+), 1 deletion(-)
[...]
Would like to apply this patch-set in a few days
---
doc/filters.texi | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 3b82edf..b57bb5a 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -18591,28 +18591,28 @@ Set the format for the output video.
It accepts the f
---
tests/fate/filter-video.mak | 2 +-
tests/filtergraphs/overlay_yuv444p10| 5 +
tests/ref/fate/filter-overlay_yuv444p10 | 8
3 files changed, 14 insertions(+), 1 deletion(-)
create mode 100644 tests/filtergraphs/overlay_yuv444p10
create mode 100644 tests/ref/fate/
---
doc/filters.texi | 3 +++
libavfilter/vf_overlay.c | 36 +++-
libavfilter/vf_overlay.h | 1 +
3 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index f17488c..3b82edf 100644
--- a/doc/filters.texi
+++ b/
On 17/05/2023 15:15, Gyan Doshi wrote:
On 2023-05-17 05:22 pm, Tobias Rapp wrote:
Clarify that -sws_flags are only applied to simple filtergraphs as a
default, not complex filtergraphs. Add a reference to the scaler
options.
LGTM
Regards,
Gyan
Applied.
Thanks for review,
Tobias
Clarify that -sws_flags are only applied to simple filtergraphs as a
default, not complex filtergraphs. Add a reference to the scaler
options.
---
doc/ffmpeg.texi | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index a12700e..c0fa90f 1006
On 09/05/2023 22:44, Michael Niedermayer wrote:
On Tue, May 09, 2023 at 08:19:36AM +0200, Anton Khirnov wrote:
Quoting Michael Niedermayer (2023-05-09 00:35:08)
[...]
would anyone be opposed to return 0 from dash_probe() when
both the mime_type and the extension are wrong ?
I would.
probe()
On 09/05/2023 08:19, Anton Khirnov wrote:
Quoting Michael Niedermayer (2023-05-09 00:35:08)
On Mon, May 08, 2023 at 04:05:40PM +0200, Tobias Rapp wrote:
[...]
DASH is usually transferred over HTTP where file extensions are of minor
interest, the relevant type information is in the Mime-Type
On 08/05/2023 14:00, James Almer wrote:
On 5/6/2023 10:25 AM, Michael Niedermayer wrote:
Its unexpected that a .avi or other "standard" file turns into a
playlist.
The goal of this patch is to avoid this unexpected behavior and possible
privacy or security differences.
This is similar to the
On 15/03/2023 15:45, Anton Khirnov wrote:
This encoder leaks and overreads, as can be seen e.g. by running an
encode under valgrind with default encoder parameters. This was known
upstream since at least 2019 (e.g. bitbucket issue #482) but never fixed
until now.
Since upstream does not seem to
On 11/03/2023 18:05, Anton Khirnov wrote:
Since these are external encoders not under our control, we cannot test
the encoded output exactly as is done for internal encoders. We can
still test however that the output is decodable and produces the
expected number of frames with expected dimension
On 19/01/2023 00:20, Prakash wrote:
The problem with int milliseconds is you lose the microseconds precision.
Sometimes there are multiple log lines within the same millisecond.
If you want to do performance profiling like comparing between assembler
and C versions of a routine in my opinion
On 17/01/2023 22:52, Prakash wrote:
libavutil/log: Support for logging timestamps in the log.
Add 'time' flag to the -loglevel option to turn on timestamp logging.
Useful for troubleshooting where time is spent from the log files.
Signed-off-by: Prakash Duggaraju
The commit message seems to be
On 12/01/2023 10:41, Paul B Mahol wrote:
Patches attached, ffmpeg.c should really not ignore initial padding
and trailing padding.
I guess ffprobe.xsd should be updated, too. Did you run FATE?
Regards, Tobias
___
ffmpeg-devel mailing list
ffmpeg-de
On 08/01/2023 15:45, Michael Niedermayer wrote:
On Fri, Jan 06, 2023 at 07:01:06PM +0100, Paul B Mahol wrote:
On Fri, Jan 6, 2023 at 6:25 PM Michael Niedermayer
wrote:
On Thu, Jan 05, 2023 at 11:08:25PM +0100, Paul B Mahol wrote:
On Thu, Jan 5, 2023 at 9:53 PM Michael Niedermayer <
mich...
On 17/05/2022 14:29, ffmpegagent wrote:
Unify file access operations by replacing usages of direct calls to posix
fopen()
v2: Remove changes to fftools for now
v3: Add some additional replacements
v4: Fix and improve commit messages
softworkz (2):
avfilter: use av_fopen_utf8() instead of pla
On 17/05/2022 02:39, ffmpegagent wrote:
Unify file access operations by replacing usages of direct calls to posix
fopen()
As the cover letter will be gone after commit I think it would be a good
idea to add the reason for the change also in the commit messages directly.
Is this in preparatio
On 11/05/2022 09:57, Soft Works wrote:
[...]
I'm not sure how much you had followed, so please excuse in case you
had already read it: the manifest approach does not work on a default
Windows installation.
To activate long path support, the users needs to opt-in to a behavior
that is probably d
On 11/05/2022 01:32, Soft Works wrote:
[...]
The prefixing can be implemented as a function and then be used
in file_open.c.
Other file system related functions like mkdir, rename, rmdir, etc.
are already intercepted in os_support.h, and the prefixing can be
applied there.
Maybe I missed some
On 26/04/2022 09:29, Hendrik Leppkes wrote:
On Tue, Apr 26, 2022 at 9:08 AM Tobias Rapp wrote:
On 23/04/2022 22:56, Nil Admirari wrote:
Newer versions of Windows (Windows 10 1607 and newer) can support path
names longer than MAX_PATH (260 characters). To take advantage of that, an
On 23/04/2022 22:56, Nil Admirari wrote:
Newer versions of Windows (Windows 10 1607 and newer) can support path
names longer than MAX_PATH (260 characters). To take advantage of that, an
application needs to opt in, by including a small manifest as a resource.
Application must be prepared to han
On 31/03/2022 23:30, Marton Balint wrote:
On empty input the awk script was always successful which caused the
filter-refcmp tests to always succeed.
Also fix the command lines for refcmp_metadata compare function because it
needs auto conversion filters, and update reference of test
filter-refc
On 30/03/2022 22:31, Marton Balint wrote:
On empty input the awk script was always successful which caused the
filter-refcmp tests to always succeed.
Also fix the command lines for refcmp_metadata compare function because it
needs auto conversion filters, and update reference of test
filter-refc
On 09/03/2022 19:18, Michael Niedermayer wrote:
Signed-off-by: Michael Niedermayer
---
doc/bitstream_filters.texi | 30
libavcodec/Makefile | 1 +
libavcodec/bitstream_filters.c | 1 +
libavcodec/dv_error_marker_bsf.c | 127 +++
On 08/03/2022 00:17, Michael Niedermayer wrote:
Signed-off-by: Michael Niedermayer
---
doc/bitstream_filters.texi | 15
libavcodec/Makefile | 1 +
libavcodec/bitstream_filters.c | 1 +
libavcodec/dv_error_marker_bsf.c | 117 +++
4
On 12/11/2021 17:32, Anton Khirnov wrote:
Also switch the values definition to the (1 << N) style, which is easier
to read.
---
libavformat/avformat.h | 96 +-
1 file changed, 77 insertions(+), 19 deletions(-)
diff --git a/libavformat/avformat.h b/libav
On 13/10/2021 06:58, Soft Works wrote:
New output looks like this:
Pixel formats:
I = Supported Input format for conversion
.O... = Supported Output format for conversion
..H.. = Hardware accelerated format
...P. = Paletted format
B = Bitstream format
FLAGS NAMENB_COMPONENTS
On 14.09.2021 15:05, Andreas Rheinhardt wrote:
These are internal fields.
Signed-off-by: Andreas Rheinhardt
---
Thanks, Tobias. I guess this version is fine, isn't it?
doc/ffprobe.xsd | 4
fftools/ffprobe.c | 4
2 files changed, 8 deletions(-)
Changes in ffprobe.c and ffprob
On 11.09.2021 08:02, Soft Works wrote:
Signed-off-by: softworkz
---
fftools/ffplay.c | 2 +-
fftools/ffprobe.c | 23 ++-
2 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 46758b9f55..f6a4d242c3 100644
--- a/fftools
On 09.09.2021 17:57, Andreas Rheinhardt wrote:
These are internal fields.
Signed-off-by: Andreas Rheinhardt
---
show_program() is only entered by three tests: mpegts-probe-pmt-merge,
mpegts-probe-program and mpegts-probe-latm. Even mpegts-probe-latm does
not print detailed information about pro
On 14.07.2021 16:57, James Almer wrote:
xmllint (silently) replaces the ' with " when fixing and validating the output
of ffprobe in fate-ffprobe_xsd.
Signed-off-by: James Almer
---
fftools/ffprobe.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fftools/ffprobe.c
On 08.04.2021 08:41, Tobias Rapp wrote:
On 07.04.2021 19:25, Paul B Mahol wrote:
Please ask someone else to apply it.
I can technically commit the patches but would prefer if some second
pair of eyes could take a look. So will apply them in a week from now if
nobody objects.
Applied this
On 30.06.2021 10:20, Tobias Rapp wrote:
On 16.04.2021 10:58, Tobias Rapp wrote:
Adds schema validation for ffprobe XML output so that updating the
ffprobe.xsd file upon changes to ffprobe is not forgotten. This was
suggested by Marton Balint in:
http://ffmpeg.org/pipermail/ffmpeg-devel/2021
On 16.04.2021 10:58, Tobias Rapp wrote:
Adds schema validation for ffprobe XML output so that updating the
ffprobe.xsd file upon changes to ffprobe is not forgotten. This was
suggested by Marton Balint in:
http://ffmpeg.org/pipermail/ffmpeg-devel/2021-March/278428.html
The schema FATE test is
On 18.06.2021 14:50, Timo Rothenpieler wrote:
> [...]
>
> +@item detected(kind)
> +Evaluates the metadata added to frames by various detection filters.
> +Returns -1 if the respective filter has detected what it was looking
for,
> +0 otherwise.
> +
> +Possible values for the @var{kind} parameter
On 27.05.2021 20:09, Marton Balint wrote:
[...]
An alternative approach is to print the meaning of the actually used
flags:
concealment_active="0" decode_slices="0" />
This is the most readable, but maybe too verbose for the default use?
This would match how pixfmt flags are currently p
On 25.05.2021 13:27, Nicolas George wrote:
Michael Niedermayer (12021-05-25):
Signed-off-by: Michael Niedermayer
---
doc/ffprobe.xsd| 1 +
fftools/ffprobe.c | 2 +
tests/ref/fate/exif-image-embedded | 22 ++
tests/ref/fate/exif-image-jpg | 1
On 12.05.2021 15:52, Timo Rothenpieler wrote:
On 12.05.2021 15:19, Samuel Marks wrote:
Started hacking around to make it work. So I changed the `main` to a:
extern int ffprobe(int argc, char **argv);
Then I added a header with a prototype of the same, and started
messing with vcpkg + CMake to
On 09.04.2021 09:58, Tobias Rapp wrote:
On 08.04.2021 11:34, Nicolas George wrote:
Anton Khirnov (12021-04-08):
Does this mean that there are no stability guarantees for metadata
exported by filters?
We can have stability for the components that are good enough to be
stable, and no stability
.
Signed-off-by: Tobias Rapp
---
configure | 3 +++
tests/fate/ffprobe.mak | 6 +
tests/ref/fate/ffprobe_xsd | 57 ++
3 files changed, 66 insertions(+)
create mode 100644 tests/ref/fate/ffprobe_xsd
diff --git a/configure b
On 13.04.2021 08:54, Tobias Rapp wrote:
On 31.03.2021 12:13, Tobias Rapp wrote:
The "packets_and_frames" element has been added to ffprobe.xsd in
0c9f0da0f7656059e9bd41931d250aafddf35ea3 but apparently removing the
check in ffprobe.c has been forgotten.
Signed-off-by: T
On 31.03.2021 12:13, Tobias Rapp wrote:
The "packets_and_frames" element has been added to ffprobe.xsd in
0c9f0da0f7656059e9bd41931d250aafddf35ea3 but apparently removing the
check in ffprobe.c has been forgotten.
Signed-off-by: Tobias Rapp
---
fftools/ffprobe.c | 7 ---
1 fi
On 08.04.2021 11:34, Nicolas George wrote:
Anton Khirnov (12021-04-08):
Does this mean that there are no stability guarantees for metadata
exported by filters?
We can have stability for the components that are good enough to be
stable, and no stability yet for components that need enhancing.
On 07.04.2021 19:25, Paul B Mahol wrote:
Please ask someone else to apply it.
I can technically commit the patches but would prefer if some second
pair of eyes could take a look. So will apply them in a week from now if
nobody objects.
Regards,
Tobias
__
On 26.03.2021 13:58, Tobias Rapp wrote:
Avoids empty "Channel" or "Overall" header lines added to log output
when measurement is restricted to one scope using
"measure_perchannel=none" or "measure_overall=none".
Signed-off-by: Tobias Rapp
---
lib
Remove the unneeded wrapping sequence element. Also the
minOccurs/maxOccurs occurrence inicators on the inner element
definitions can be removed.
Signed-off-by: Tobias Rapp
---
doc/ffprobe.xsd | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/doc
The "packets_and_frames" element has been added to ffprobe.xsd in
0c9f0da0f7656059e9bd41931d250aafddf35ea3 but apparently removing the
check in ffprobe.c has been forgotten.
Signed-off-by: Tobias Rapp
---
fftools/ffprobe.c | 7 ---
1 file changed, 7 deletions(-)
diff --git
On 30.03.2021 19:51, Marton Balint wrote:
[...]
I wonder if a fate test testing the XML output of ffprobe can be
extended to do a validation of the XML via the XSD so this does not gets
forgatten...
I agree that would be great. But I guess we cannot depend on a tool like
xmllint being avai
Using integer format makes the metadata display similar to the log output.
Fix missing "Overall" metadata key name prefix where necessary. Also
replace whitespace in some metadata key names with underscore character
for consistency.
Signed-off-by: Tobias Rapp
---
libavfilter/af_ast
Avoids empty "Channel" or "Overall" header lines added to log output
when measurement is restricted to one scope using
"measure_perchannel=none" or "measure_overall=none".
Signed-off-by: Tobias Rapp
---
libavfilter/af_astats.c | 6 --
1 file change
On 15.03.2021 17:19, Gyan Doshi wrote:
On 2021-03-15 18:54, Tobias Rapp wrote:
In the meanwhile libx264 allows to be configured for including both
8/10 bit
support within a single library. The new libx264 interface was enabled in
2f96190732d15510ba29471fa45d66841c0c3df1.
Signed-off-by
In the meanwhile libx264 allows to be configured for including both 8/10 bit
support within a single library. The new libx264 interface was enabled in
2f96190732d15510ba29471fa45d66841c0c3df1.
Signed-off-by: Tobias Rapp
---
doc/encoders.texi | 4 +---
1 file changed, 1 insertion(+), 3 deletions
On 26.01.2021 16:39, Tomas Härdin wrote:
tis 2021-01-26 klockan 00:34 +0100 skrev Marton Balint:
Maybe they should post patches instead of having workarounds? And I
explained, libavformat MXF muxer will still be identifiable, but the
proper field will be used for identifying the SDK used, not
Co
On 25.01.2021 20:40, emco...@ffastrans.com wrote:
[...]
What you can do instead is to push both identifications, the old one and
the one from the current program into the identification array, this way
the processing chain can be reconstructed. Unforutnately i have never
seen anyone doing thi
On 18.01.2021 23:53, Tomas Härdin wrote:
lör 2021-01-16 klockan 08:43 +0800 skrev lance.lmw...@gmail.com:
On Fri, Jan 15, 2021 at 09:43:58PM +0100, Marton Balint wrote:
On Fri, 15 Jan 2021, Tomas Härdin wrote:
Again, why? If you have a company that maintains a fork of FFmpeg then
compile that
On 08.01.2021 11:01, lance.lmw...@gmail.com wrote:
On Fri, Jan 08, 2021 at 09:09:34AM +0100, Tobias Rapp wrote:
On 08.01.2021 07:32, lance.lmw...@gmail.com wrote:
From: Limin Wang
Please check metadata with below command:
./ffmpeg -i ../fate-suite/mxf/Sony-1.mxf -c:v copy -c:a copy
On 08.01.2021 07:32, lance.lmw...@gmail.com wrote:
From: Limin Wang
Please check metadata with below command:
./ffmpeg -i ../fate-suite/mxf/Sony-1.mxf -c:v copy -c:a copy out.mxf
./ffmpeg -i out.mxf
company_name: FFmpeg
product_name: OP1a Muxer
product_version : 58.6
On 11.11.2020 17:15, Carl Eugen Hoyos wrote:
Not necessarily related: In no way whatsoever does the LGPL mandate
dynamic linking (this was claimed several times lately).
The "License Compliance Checklist" on http://ffmpeg.org/legal.html lists
dynamic linking under point 2.
I know that in theor
On 11.11.2020 06:50, Brian D. Pemberton wrote:
Hi,
I am thinking about writing an app that bundles or includes FFmpeg to do
some video processing. Is this allowed? If so, where can I read about the
constraints or requirements of doing this? Also, is there anything I should
know upfront to prepar
P seems to be
the only required case of it. Maybe Kieran could comment on the requirement
of having maintaining the rationals for CLAP (only works on mov to mov
transmuxing).
I'm no expert, but I think a lot of this just comes from video standards
that stipulate those rational numbers? I'
On 18.04.2019 11:40, Michael Niedermayer wrote:
On Thu, Apr 18, 2019 at 10:30:49AM +0200, Paul B Mahol wrote:
On 4/18/19, Michael Niedermayer wrote:
On Thu, Apr 18, 2019 at 01:19:58AM +0200, Michael Niedermayer wrote:
On Wed, Apr 17, 2019 at 06:16:39PM +0200, Paul B Mahol wrote:
Signed-off-b
On 06.04.2019 02:11, Nikolas Bowe via ffmpeg-devel wrote:
When asetnsamples uses output samples < input samples, remaining samples build
up in the fifo over time.
Fix this by marking the filter as ready again if there are enough samples.
Regression since ef3babb2c70f564dc1634b3f29c6e35a2b2dc239
On 28.03.2019 15:02, Carl Eugen Hoyos wrote:
2019-03-28 15:00 GMT+01:00, Tobias Rapp :
On 28.03.2019 12:00, Carl Eugen Hoyos wrote:
Attached patch also simplifies the release process.
Personally I'd prefer to keep the link to the latest release.
Why? Such a link is already listed
On 28.03.2019 12:00, Carl Eugen Hoyos wrote:
Hi!
Attached patch also simplifies the release process.
Please comment, Carl Eugen
Personally I'd prefer to keep the link to the latest release. There is
already a "Download Snapshot" button on the "Get the Sources" panel.
Regards,
Tobias
_
On 23.03.2019 01:03, ffmpeg-...@ffmpeg.org wrote:
The branch, master has been updated
via 2505968f485fae32d7a68881eff0187f346adb61 (commit)
from b971570feed92970138b9234403d2ef213cf877e (commit)
- Log -
commit 2505
On 27.03.2019 23:13, Allan Cady via ffmpeg-devel wrote:
On Tue, Mar 26, 2019 at 10:07:10PM +, Allan Cady via ffmpeg-devel wrote:
When the silencedetect filter is run against very large files, the
output timestamps gradually lose precision as the scan proceeds
further into the file. This i
On 25.03.2019 18:02, Jean-Baptiste Kempf wrote:
On Mon, 25 Mar 2019, at 08:32, Tobias Rapp wrote:
Most of those hardware libraries are glorified ioctls around the driver and
shipped with the drivers.
And I see this with nVidia, Intel MFX and Decklink (lots of "acquire C++ interface,
set
On 24.03.2019 21:14, Jean-Baptiste Kempf wrote:
On Sun, 24 Mar 2019, at 20:10, Ronald S. Bultje wrote:
The GPL does not mention hardware (instead, they use the word "system
library"). Going from here, I don't consider enterprise-level hardware like
Matrox $$$ priced stuff to be a system library
On 08.03.2019 10:49, Ulf Zibis wrote:
[...]
Can some other developer please give me a practical hint how to deal
with private folders not to appear in GIT patches?
I'm using .git/info/exclude to ignore files that are only found within
my private developing environment.
Regards,
Tobias
_
On 26.02.2019 21:36, Soft Works wrote:
From: Jean-Baptiste Kempf
Sent: Dienstag, 26. Februar 2019 15:01
[...]
I don't think nvcc fit the"normally distributed with the operating system".
I'm not sure if the role of nvcc has been fully understood.
nvcc is some kind of 'pre-compiler' which is
On 22.02.2019 14:57, Nicolas George wrote:
Gyan (12019-02-22):
'-key' will be easier to search for these users as well. It's also a
low-cost arrangement. I trust adept API users will quickly suss out that the
hyphen represents CLI. GUI users won't be entering the key string, only the
value
On 22.02.2019 12:43, Hendrik Leppkes wrote:
On Fri, Feb 22, 2019 at 12:29 PM Nicolas George wrote:
Lou Logan (12019-02-21):
For consistency. Fixes #7740.
Signed-off-by: Lou Logan
I do not think this is correct: the dash is not part of the option name,
it is part of the Unix command-line t
On 21.01.2019 17:43, Paul B Mahol wrote:
On 11/10/18, Paul B Mahol wrote:
Signed-off-by: Paul B Mahol
---
libavfilter/Makefile | 1 +
libavfilter/af_astretch.c | 330 ++
libavfilter/allfilters.c | 1 +
3 files changed, 332 insertions(+)
crea
On 14.01.2019 17:20, Nicolas George wrote:
Tobias Rapp (12019-01-14):
Writing good code requires time. I don't see how being sponsored for
development should have a negative correlation (in general) to the time
invested on a specific topic/patch.
Let us say somebody worked one day
1 - 100 of 490 matches
Mail list logo
