On Wed, 2021-12-22 at 21:57 -0500, Calvin Walton wrote:
>
> If you could provide the logs from the fps filter at 'verbose' log
> level for the initial segment of the file (first ~1 second of so)
> that
> would provide helpful information.
I said "verbose", but I meant &q
On Wed, 2021-12-22 at 23:04 +0100, Michael Niedermayer wrote:
> On Wed, Dec 22, 2021 at 11:20:26AM -0500, Calvin Walton wrote:
> > This is mostly to avoid oddities in small framerate adjustments
> > when you
> > have input videos from containers such as matroska, whe
ted
frames.
The potential downside of this change is that if an input file is
probed as CFR but is actually VFR, then the results will be poor
(you'll get unnecessarily dropped frames or added judder). A new
option, "requantize", is added to allow disabling this behaviour in
those cases.
S
On Mon, 2021-12-13 at 14:32 -0500, Calvin Walton wrote:
> like, for example, I rewrote the "fps" filter to use the activate
> callback to handle filling in large timestamp gaps a frame at a time
> rather than buffering a ton of frames all at once and causing OOM. Bu
uced from the same demuxer -
where one stream can have large timestamp gaps which others do not.
IMO, this probably requires going all the way back to the demuxer
level, since the demuxer is the only part of ffmpeg that knows for sure
that "so
Prior to C++11, some of the C99 macros in stdint.h were not defined
unless __STDC_CONSTANT_MACROS was defined before including the header.
C++11 updated this so that the C99 macros are unconditionally defined -
__STDC_CONSTANT_MACROS is no longer required.
Update the conditional on the error
This seems fine - my only comment is that you need to test this with
high DPI support (display scale values >100%) on both native high-dpi
applications and legacy (scaled by windows) applications to ensure the
correct adjustments are being applied where needed.
--
Calvin Walton
What that actually means is that CAPTUREBLT includes windows with the
"WS_EX_LAYERED" window style that overlap the window, not *any* window.
Layered windows are described in:
https://docs.microsoft.com/en-us/windows/win32/winmsg/window-features#layer
your screen while capturing with this
option set to @code{1}. If that happens, you can disable CAPTUREBLT by
setting this option to @code{0}.
--
Calvin Walton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/f
but the documentation as is would be totally misleading.
Yes, this definitely needs to be clarified in docs.
Another thing to check: If the cursor is included in the captured image
when the CAPTUREBLT flag is disabled, then you should make ffmpeg skip
adding the cursor itself in that case.
--
Ca
consistent with the behaviour of
libvpx.
libvpx writes 0 initially:
https://github.com/webmproject/libvpx/blob/v1.8.1/vpxenc.c#L1191
then updates afterwards with the length (if output is seekable):
https://github.com/webmproject/libvpx/blob/v1.8.1/vpxenc.c#L1209
(for reference, the ivf_write_f
On Tue, 2019-10-01 at 13:56 -0400, Calvin Walton wrote:
> The ffmpeg code read and wrote a 64bit duration field (in timebase
> units) in the ivf
> header, where the libvpx and chromium code instead use a 32bit frame
> count field, and
> then 32bits of unused (reserved?) space.
>
On Tue, 2019-10-01 at 15:26 -0300, James Almer wrote:
> On 10/1/2019 2:56 PM, Calvin Walton wrote:
> > libavformat/ivfdec.c | 3 ++-
> > libavformat/ivfenc.c | 11 ---
> > 2 files changed, 6 insertions(+), 8 deletions(-)
> >
> > diff --git a/libavforma
The ffmpeg code read and wrote a 64bit duration field (in timebase units) in
the ivf
header, where the libvpx and chromium code instead use a 32bit frame count
field, and
then 32bits of unused (reserved?) space.
Switch ffmpeg to match the behaviour of libvpx & chromium.
Note that libvpx writes
Right now, the concat filter does not set the frame_rate value on any of
the out links. As a result, the default ffmpeg behaviour kicks in - to
copy the framerate from the first input to the outputs.
If a later input is higher framerate, this results in dropped frames; if
a later input is lower
at 14:10 -0500, Calvin Walton wrote:
> This revision of the patch fixes statistics by counting the number of
> times each frame has been output, rather than trying to guess at the
> time each frame is output whether it was a duplicate or drop.
>
> I ended up leaving the conditional ch
mes_count == 0) {
at the bottom of the activate function. I think I agree that the
condition will always be true, based on the code flow, but the if
statement documents the condition just as well as an assert would, and
it's not like the EOF handling is in a hot path where we'd want to
compile out the check.
Ca
Since the config_props function now references both the input and output
links, rename the 'link' variable to 'outlink'.
Fix up some mismatching indentation.
Don't bother setting the width and height on the outlink; the filter
framework does that for us.
---
libavfilter/vf_fps.c | 16
Khirnov
+ * Copyright 2018 Calvin Walton <calvin.wal...@kepstin.ca>
*
* This file is part of FFmpeg.
*
@@ -28,17 +29,12 @@
#include
#include
-#include "libavutil/common.h"
-#include "libavutil/fifo.h"
+#include "libavutil/avassert.h"
#include
minor change.
I'll post the updated patch later this week, so please let me know if
you have any other changes I should incorporate.
Calvin.
On Mon, 2018-02-19 at 19:54 -0500, Calvin Walton wrote:
> The old version of the filter had a problem where it would queue up
> all of the duplicate
---
tests/fate/filter-video.mak | 4 +++-
tests/ref/fate/filter-fps-start-drop | 11 +++
tests/ref/fate/filter-fps-start-fill | 11 +++
3 files changed, 25 insertions(+), 1 deletion(-)
create mode 100644 tests/ref/fate/filter-fps-start-drop
create mode 100644
Since the config_props function now references both the input and output
links, rename the 'link' variable to 'outlink'.
Fix up some mismatching indentation.
Don't bother setting the width and height on the outlink; the filter
framework does that for us.
---
libavfilter/vf_fps.c | 16
patch just has some formatting fixes to make the config_props
function easier to read.
Calvin Walton (3):
libavfilter/vf_fps: Add tests for start_time option
libavfilter/vf_fps: Rewrite using activate callback
libavfilter/vf_fps: Minor cleanups
libavfilter/vf_fps.c | 391
Khirnov
+ * Copyright 2018 Calvin Walton <calvin.wal...@kepstin.ca>
*
* This file is part of FFmpeg.
*
@@ -28,17 +29,12 @@
#include
#include
-#include "libavutil/common.h"
-#include "libavutil/fifo.h"
+#include "libavutil/avassert.h"
#include
dy(ctx, 100);
> > +return 0;
> > +}
>
> I do not like the use of EAGAIN for this. It may conflict with strange
> error codes returned by other filters. It should not happen, but it
> could. I would advice to define a specific error code for this file
> only, like FFERROR_REDO in libavformat/internal.h. Or, even better, add
> "int *again" as an extra argument to write_frame() and return the
> condition like that.
I like the solution with adding an extra return argument to the
function to keep this status separate from the error return codes. I'll
make this change.
--
Calvin Walton <calvin.wal...@kepstin.ca>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
oing to spend some time going over it now.
I've noticed in my testing that I completely forgot to hook up the
'start_time' option, so expect a patch respin fixing that and
addressing your comments as well.
(I'll look at writing some tests for the start_time option too.)
--
Calvin Walton <cal
Oops, I forgot to remove this bit from the changelog:
On Fri, 2018-02-16 at 15:02 -0500, Calvin Walton wrote:
> TODO: This is still a work in progress. It may have different
> behaviour
> in some cases from the old fps filter. I have not yet implemented the
> "eof_action" o
also added some additional fate tests to check for regressions
in the filter. They pass with both the current fps filter and my new
one.
Calvin Walton (2):
libavfilter/vf_fps: Add more fate tests
libavfilter/vf_fps: Rewrite using activate callback
libavfilter/vf_fps.c
These tests cover specific rounding behaviour, to ensure that I don't
introduce any regressions with the rewritten "activate" callback based
fps filter.
---
tests/fate/filter-video.mak | 10 +-
tests/ref/fate/filter-fps-down| 15 +++
right 2012 Robert Nagy
* Copyright 2012 Anton Khirnov
+ * Copyright 2018 Calvin Walton <calvin.wal...@kepstin.ca>
*
* This file is part of FFmpeg.
*
@@ -28,17 +29,12 @@
#include
#include
-#include "libavutil/common.h"
-#include "libavutil/fifo.h"
+#incl
The existing code attempts to clear the frame by painting in OVER
mode with transparent black - which is a no-op. As a result if you
have many input frames (e.g. you're using a sequence of svg files),
you'll start to see new frames drawn over old frames as memory gets
re-used.
Switch the code to
The existing code attempts to clear the frame by painting in OVER mode
with transparent black - which is, of course, a no-op. As a result if
you have many input frames (e.g. you're using a sequence of svg files),
you'll start to see new frames drawn over old frames as memory gets
re-used.
Fix
On Sat, 2017-03-11 at 14:28 +0100, Michael Niedermayer wrote:
> On Thu, Mar 09, 2017 at 03:27:16PM -0500, Calvin Walton wrote:
> > ---
> > libavfilter/avf_concat.c | 15 ++-
> > tests/fate/filter-video.mak | 4 +-
> > tests/ref/f
Right now, the concat filter does not set the frame_rate value on any of
the out links. As a result, the default ffmpeg behaviour kicks in - to
copy the framerate from the first input to the outputs.
If a later input is higher framerate, this results in dropped frames; if
a later input is lower
On Wed, 2017-03-08 at 20:35 +0100, Nicolas George wrote:
> L'octidi 18 ventôse, an CCXXV, Calvin Walton a écrit :
> > Hmm. Setting it to the same as the input value if all inputs match
> > shouldn't be too hard, I think.
> >
> > In the actual case of inputs with d
On Wed, 2017-03-08 at 19:27 +0100, Nicolas George wrote:
> L'octidi 18 ventôse, an CCXXV, Calvin Walton a écrit :
> >
> > If a later input is higher framerate, this results in dropped frames; if
> > a later input is lower framerate it might cause judder.
> >
> >
Right now, the concat filter does not set the frame_rate value on any of
the out links. As a result, the default ffmpeg behaviour kicks in - to
copy the framerate from the first input to the outputs.
If a later input is higher framerate, this results in dropped frames; if
a later input is lower
Hi, just a quick note below...
On Thu, 2017-02-02 at 14:40 +0100, Paul B Mahol wrote:
>
> +++ b/doc/filters.texi
> @@ -9643,6 +9643,17 @@ Macroblock size. Default @code{16}.
> Search parameter. Default @code{7}.
> @end table
>
> +@section midequalizer
> +
> +Apply Midway Image Equalization
ase, using ", " as the separator appears to be preferred
but not required by the RFCs. But it certainly doesn't require that the
space is present! I agree that this isn't really an FFmpeg bug, but
switching to use ", " is probably a good i
hat's defined as whatever version you recommend
arbitrary users pick up.
There's nothing worse than having some piece of software that's worked
for ages fail to compile just because the system you're building it on
now happens to produce an (often trivial) warni
---
doc/demuxers.texi | 23 +++
1 file changed, 23 insertions(+)
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index 34bfc9b..fe9b7b1 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -522,4 +522,27 @@ Example: convert the captions to a format most players
types to use are RGB24 (which is a native-endian
32bit RGB type where the extra 8 bits are unused) and ARGB32, which
has, you guessed it, premultiplied alpha.
--
Calvin Walton calvin.wal...@kepstin.ca
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
file, you'll just have to remux the mkv, e.g. by
doing
ffmpeg -i received.mkv -c copy remuxed.mkv
--
Calvin Walton calvin.wal...@kepstin.ca
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
similar would be useful in ffmpeg, to provide a
constant fps stream that a detelecine filter could use as input.
--
Calvin Walton calvin.wal...@kepstin.ca
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
: yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr cx8 mmx
bogomips: 533.42
clflush size: 32
cache_alignment : 32
address sizes : 32 bits physical, 32 bits virtual
power management:
--
Calvin Walton calvin.wal
45 matches
Mail list logo
