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 fr
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
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
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.
>
itial value is 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,
> addition, 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 i
er on 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/listi
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
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 ef
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 fr
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.
> >
>
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 wi
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 fr
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
On Tue, 2014-08-19 at 07:44 -0600, Roger Pack wrote:
> OK I was able to reproduce the problem.
> Patch looks good, see attached, FWIW.
> Thanks!
> -roger-
I suppose this was probably my fault originally; it was my first time
programming the win32 api. ;)
Thanks for the fix.
--
C
: 266.603
cache size : 64 KB
fdiv_bug: no
f00f_bug: no
coma_bug: no
fpu : 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
a
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 that
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 p
07 Bobby Bingham
* Copyright 2012 Robert Nagy
* Copyright 2012 Anton Khirnov
+ * Copyright 2018 Calvin Walton
*
* This file is part of FFmpeg.
*
@@ -28,17 +29,12 @@
#include
#include
-#include "libavutil/common.h"
-#include "libavutil/fifo.h"
+#include &q
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 +++
tests/ref/fate/fil
have 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
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
7;m going 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
another step */
> > +ff_filter_set_ready(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
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
2012 Anton Khirnov
+ * Copyright 2018 Calvin Walton
*
* 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 "libavutil/mathema
The third 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
---
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 tests/ref/
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 +++
relatively 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
2012 Anton Khirnov
+ * Copyright 2018 Calvin Walton
*
* 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 "libavutil/mathema
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 +++
== 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
, 2018-02-22 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
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 mess
mplayer - it sounds like you might be hitting a
vlc bug if seeking doesn't work there).
To fix the received file, you'll just have to remux the mkv, e.g. by
doing
ffmpeg -i received.mkv -c copy remuxed.mkv
--
Calvin Walton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
merate (in NTSC, mixed 24/1001 frames/s and
60/1001 fields/s) into a telecined+interlaced video with constant
framerate (60/1001 fields/s).
I wonder if something similar would be useful in ffmpeg, to provide a
constant fps stream that a detelecine filter could use as input.
--
Calvin Walton
__
ffmpeg interface would probably have to dlload() it rather than
link to it.
Of course, the current openh264 codec only does h264 baseline (not
even main, let alone high...), making it of very limited use for
anything at all.
--
Calvin Walton
___
ff
On Tue, 2015-01-27 at 14:20 +0100, Clément Bœsch wrote:
> On Sun, Jan 25, 2015 at 07:55:22PM +0100, Clément Bœsch wrote:
> > ---
> > doc/filters.texi| 31 +
> > libavfilter/Makefile| 1 +
> > libavfilter/allfilters.c| 1 +
> > libavfilter/vf_paletteuse.c | 282
> >
sing ", " 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 idea regardless.
--
Calvin Walton
quot;video_size" and "framerate" respectively on the input
format. This will work automatically.
--
Calvin Walton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
---
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
unders
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) warning that wasn'
image surfaces is one of the
following:
http://cairographics.org/manual/cairo-Image-Surfaces.html#cairo-format-t
The most common 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, premu
;
> +}
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
i.e. produced 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
tha
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. But
&g
ed
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
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, where the p
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
49 matches
Mail list logo
