Re: [FFmpeg-devel] [RFC PATCH] vf_fps: Requantize pts of CFR videos
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 "debug" here :/ -- Calvin Walton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC PATCH] vf_fps: Requantize pts of CFR videos
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 pts > > values > > are quantized with a large enough error to cause issues. > > > > breaks a 60fps 1/6 timebase input downconverted with -vf fps=30:- > 0.01 > the expected result is identical to -vf fps=30 but > > -i 60fps.mov -bitexact -vf fps=30:-0.01 -t 2 -v 99 fps.flv > the expected output is that either all odd or all even frames are > returned but > its a mix after this patch > I cannot share the input file but this should reproduce with any > 60fps > input i hope. If not say so and ill try to find some other file that > shows this I'll take a look at this. Hopefully I can reproduce it with an artificially created file (if so, I'll make a test). 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. It's possible that the reason you're having a problem with fps=30:-0.01 is that I'm applying the start offset in the wrong position in the conversion; I'll try moving it around. -- Calvin Walton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [RFC PATCH] vf_fps: Requantize pts of CFR videos
This is mostly to avoid oddities in small framerate adjustments when you
have input videos from containers such as matroska, where the pts values
are quantized with a large enough error to cause issues.
An example, when converting from 24/1.001 fps to 24 fps with round=down
from an mkv source (inlink time base is 1/1000, outlink is 1001/24000):
In PTS | Out PTS | Rounded Out PTS
69292 | 1663.008 | 1663
69333 | 1663.992 | 1663
69375 | 1665.000 | 1665
In this example, the fps filter would drop the frame with pts 69292,
then duplicate the frame with pts 69333, an undesirable result.
By first requantizing the input pts to the inlink frame rate, the result
looks much nicer:
In PTS | Req. PTS | Out PTS
69292 | 1661 | 1662
69333 | 1662 | 1663
69375 | 1663 | 1664
(Note that the same rounding mode is used for both conversions,
resulting in the final out pts being a bit lower in this case. With the
normal nearest mode, it would be closer.)
I've verified that in conversions of longer mkv files to "close"
framerates that previously had issues due to quantization, this
significantly reduces the number of incorrectly dropped or duplicated
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.
Signed-off-by: Calvin Walton
---
libavfilter/vf_fps.c | 48 +---
1 file changed, 41 insertions(+), 7 deletions(-)
diff --git a/libavfilter/vf_fps.c b/libavfilter/vf_fps.c
index 99e679441e..d010083a35 100644
--- a/libavfilter/vf_fps.c
+++ b/libavfilter/vf_fps.c
@@ -74,6 +74,7 @@ typedef struct FPSContext {
char *framerate;///< expression that defines the target framerate
int rounding; ///< AVRounding method for timestamps
int eof_action; ///< action performed for last frame in FIFO
+int requantize; ///< whether to requantize timestamps of cfr inputs
/* Set during outlink configuration */
int64_t in_pts_off;///< input frame pts offset for start_time handling
@@ -111,6 +112,8 @@ static const AVOption fps_options[] = {
{ "eof_action", "action performed for last frame", OFFSET(eof_action),
AV_OPT_TYPE_INT, { .i64 = EOF_ACTION_ROUND }, 0, EOF_ACTION_NB-1, V|F,
"eof_action" },
{ "round", "round similar to other frames", 0, AV_OPT_TYPE_CONST, {
.i64 = EOF_ACTION_ROUND }, 0, 0, V|F, "eof_action" },
{ "pass", "pass through last frame",0, AV_OPT_TYPE_CONST, {
.i64 = EOF_ACTION_PASS }, 0, 0, V|F, "eof_action" },
+{ "requantize", "requantize input timestamps in CFR video based on
framerate",
+ OFFSET(requantize), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, V|F },
{ NULL }
};
@@ -177,6 +180,7 @@ static int config_props(AVFilterLink* outlink)
FPSContext *s = ctx->priv;
double var_values[VARS_NB], res;
+AVRational in_time_base;
int ret;
var_values[VAR_SOURCE_FPS]= av_q2d(inlink->frame_rate);
@@ -193,6 +197,18 @@ static int config_props(AVFilterLink* outlink)
outlink->frame_rate = av_d2q(res, INT_MAX);
outlink->time_base = av_inv_q(outlink->frame_rate);
+/* Disable requantization if input video is VFR */
+if (s->requantize && inlink->frame_rate.num == 1 && inlink->frame_rate.den
== 0) {
+av_log(ctx, AV_LOG_INFO, "Not requantizing input timestamps; video is
VFR\n");
+s->requantize = 0;
+}
+
+in_time_base = inlink->time_base;
+if (s->requantize) {
+in_time_base = av_inv_q(inlink->frame_rate);
+av_log(ctx, AV_LOG_VERBOSE, "Requantizing input timestamps to
time_base=%d/%d\n", in_time_base.num, in_time_base.den);
+}
+
/* Calculate the input and output pts offsets for start_time */
if (s->start_time != DBL_MAX && s->start_time != AV_NOPTS_VALUE) {
double first_pts = s->start_time * AV_TIME_BASE;
@@ -201,7 +217,7 @@ static int config_props(AVFilterLink* outlink)
s->start_time);
return AVERROR(EINVAL);
}
-s->in_pts_off = av_rescale_q_rnd(first_pts, AV_TIME_BASE_Q,
inlink->time_base,
+s->in_pts_off = av_rescale_q_rnd(first_pts, AV_TIME_BASE_Q,
in_time_base,
s->rounding | AV_ROUND_PASS_MINMAX);
s->out_pts_off = av_rescale_q_rnd(first_pts, AV_TIME_BASE_Q,
outlink->time_base,
s->rounding | AV_ROUND_PASS_MINMAX);
@@ -220,7 +236,8 @@ static int read_frame(AVFilterContext *ctx, FPSContext *s,
Re: [FFmpeg-devel] Politics
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 > that only fixed the situation in files with single streams. > > I believe that a more general solution is needed to handle working with > multiple "synchronized" streams - i.e. produced from the same demuxer - > where one stream can have large timestamp gaps which others do not. Incidentally, the "fps" filter is probably one of the simplest examples of a filter that does not involve subtitles which would benefit from a "heartbeat" mechanism. Currently in order to be able to output a frame, the fps filter needs to have 2 frames buffered (or alternately, one frame and a timestampped status like EOF). In the case of a long timestamp gap, this means that it will produce no output frames until such time as the next frame is read, meaning that downstream filters will be stalled, and if there are any multi-input filters downstream, one of the inputs might end up with too many frames in its input fifo. If the fps filter could receive periodic activations with an indication that "pts has increased on the input without any new frame available", it could incrementally fill in the gap in realtime, allowing downstream filters to proceed. -- kepstin Calvin Walton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Politics
On Sun, 2021-12-12 at 06:15 +, Soft Works wrote: > Good Morning, > > yesterday, it happened for the 4th and 5th times that another > developer > called my patchset a “hack”. This might be partially a language problem. Ffrom familiarity with the usage in several primarily-English development communitities, the primary meaning of the word "hack" as I interpret it is "doing something in a way that wasn't the original intent of the code". It's not *necessarily* a bad thing. In my opinion, the heartbeat mechanism as it has been designed in this patchset fits that description of a "hack" relative to the current libavfilter design, since it is a fix to a very specific problem on top of an existing system, rather than a design change to fix the underlying system in a way that would correct the problem in general. In general, ffmpeg filters deal very poorly with long timestamp gaps of *any* media type, which can cause stalls or excessive buffering. Moving to the "activate" callback mechanism did a bit to help with this - 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 that only fixed the situation in files with single streams. I believe that a more general solution is needed to handle working with multiple "synchronized" streams - 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 that "some pts has passed without any packets from stream X". -- kepstin Calvin Walton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] libavutil: Don't require __STDC_CONSTANT_MACROS on C++11
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 message in common.h so that it does not trigger when using a C++11 or later compiler. --- libavutil/common.h | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/libavutil/common.h b/libavutil/common.h index b9fbcc4d60..f90de59157 100644 --- a/libavutil/common.h +++ b/libavutil/common.h @@ -26,7 +26,11 @@ #ifndef AVUTIL_COMMON_H #define AVUTIL_COMMON_H -#if defined(__cplusplus) && !defined(__STDC_CONSTANT_MACROS) && !defined(UINT64_C) +/* + * In C++ prior to C++11, some of the C99 defines in stdint.h are omitted unless + * you request to enable them by setting __STDC_CONSTANT_MACROS + */ +#if defined(__cplusplus) && __cplusplus < 201103L && !defined(__STDC_CONSTANT_MACROS) && !defined(UINT64_C) #error missing -D__STDC_CONSTANT_MACROS / #define __STDC_CONSTANT_MACROS #endif -- 2.29.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avdevice/gdigrab: client_only option to discard decorations such as titlebar or borders
On Fri, 2020-06-19 at 10:33 +0200, Sergio Acereda wrote:
> +/**
> + * Fetch titlebar height from handle.
> + *
> + * @param hwnd Handle of the window.
> + * @return titlebar height
> + */
> +static int
> +calc_titlebar_height(HWND hwnd) {
> +TITLEBARINFOEX tinfo;
> +tinfo.cbSize = sizeof(tinfo);
> +SendMessage(hwnd, WM_GETTITLEBARINFOEX, 0, (LPARAM));
> +return tinfo.rcTitleBar.bottom - tinfo.rcTitleBar.top;
> +}
> +
> /**
> * Initializes the gdi grab device demuxer (public device demuxer
> API).
> *
> @@ -284,6 +299,15 @@ gdigrab_read_header(AVFormatContext *s1)
>
> if (hwnd) {
> GetClientRect(hwnd, _rect);
> +if (gdigrab->client_only) {
> +int cxborder = GetSystemMetrics(SM_CXBORDER);
> +int cyborder = GetSystemMetrics(SM_CYBORDER);
> +int titlebar_height = calc_titlebar_height(hwnd);
> +virtual_rect.left += cxborder;
> +virtual_rect.right += -cxborder;
> +virtual_rect.top+= cxborder + titlebar_height;
> +virtual_rect.bottom += -cyborder;
> +}
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
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 1/1] avdevice/gdigrab add use_captureblt option
On Thu, 2020-01-16 at 09:08 +0800, fgodt wrote:
> > By default, this is set to @code{1}, which means that gdigrab will
> > use
> > the CAPTUREBLT flag when grabbing images of a window. With this
> > flag
> > set, gdigrab will capture the entire contents of a window even if
> > it is
> > covered by other windows on the screen.
> >
> > If this option is set to @code{0}, the image captured will match
> > what
> > you see on the screen: the contents of any windows covering the
> > selected window will be visible in the capture.
> >
> > Depending on your Windows version and graphics settings, you may
> > see
> > the mouse cursor flicker 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}.
> >
> Thanks for you suggestion, but there is issue, without the
> CAPTUREBLT
> flag not change any thing for normal window in captured video, the
> worke
> same like use CAPTUREBLT flag. So the can capture window even if it
> is
> covered.
Ah, fun, this is based on a misinterpretation of the windows
documentation:
CAPTUREBLT
Includes any windows that are layered on top of your window in the
resulting image. By default, the image only contains your window.
But according to this StackOverflow response:
https://stackoverflow.com/a/4646999
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#layered-windows
I think we should unconditionally remove the CAPTUREBLT flag, there's
no need for any options or documentation changes.
--
Calvin Walton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 1/1] avdevice/gdigrab add use_captureblt option
On Sat, 2020-01-11 at 17:18 +0800, fgodt...@hotmail.com wrote:
> From: FgoDt
>
> Add use_captureblt option for disable or use CAPTUREBLT flag, when
> useing the bitblt function with CAPTUREBLT may caused the Windows
> mouse cursor flicker. most time we don't need this flag to capture
> window
> I tested on Windows 10 works fine
I have a suggestion for improving the documentation, see below.
Can you please test for me: If you use use_captureblt=0 and
draw_mouse=0 is the mouse cursor visible or not in the recorded video?
> +@item use_captureblt
> +gdigrab use CAPTUREBLT flag to capture window or desktop by default,
> which may make Windows mouse cursor flickering.
> +If not capture layered window you can set value @code{0} disable
> CAPTUREBLT flag, to fix Windows cursor flickering.
> +Default value is @code{1}
> +
> +Note the value @code{1} is essential to capture layered window
@item use_captureblt
By default, this is set to @code{1}, which means that gdigrab will use
the CAPTUREBLT flag when grabbing images of a window. With this flag
set, gdigrab will capture the entire contents of a window even if it is
covered by other windows on the screen.
If this option is set to @code{0}, the image captured will match what
you see on the screen: the contents of any windows covering the
selected window will be visible in the capture.
Depending on your Windows version and graphics settings, you may see
the mouse cursor flicker 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/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 1/1] avdevice/gdigrab: Add use_captureblt option for disable or use CAPTUREBLT flag, when useing the bitblt function with CAPTUREBLT it caused the mouse cursor flicker. mo
On Mon, 2019-12-30 at 12:31 +0100, Marton Balint wrote:
>
> On Mon, 30 Dec 2019, fgodt...@hotmail.com wrote:
>
> > From: FgoDt
>
> > +@item use_captureblt
> > +When use gdigrab to capture window or desktop, the mouse cursor
> > will flicker.
>
> Why? Does this happen with every windows version? This does not seem
> like
> the right fix. In fact, I dont't see how this can work, because mouse
> is
> drawn upon the captured video "manually" in paint_mouse_pointer.
> Could you
> dig deeper what is the main cause of the issue?
I'm guessing that what happens here is that on some OS versions, with
some graphics drivers, the cursor on the *real* display might flicker
while ffmpeg is capturing. I've never actually seen this happen, but if
you have bad/old drivers and have desktop compositing disabled, maybe?
> > +Disable CAPTUREBLT FLAG by set value @code{0} to fix cursor
> > flickering. Default value is @code{1}
> > +
>
> Doesn't this change what is captured when the user captures a single
> window and something is dragged on top? That alone might be a useful
> 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 in that case.
--
Calvin Walton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/ivf: Change the length field to 32 bits
On Tue, 2019-10-01 at 21:41 +0200, Carl Eugen Hoyos wrote: > Am Di., 1. Okt. 2019 um 21:35 Uhr schrieb Raphaël Zumer < > rzu...@tebako.net>: > > On Tue, 2019-10-01 at 20:09 +0100, Derek Buitenhuis wrote: > > > On 01/10/2019 18:25, James Almer wrote: > > > > The value in the unused field will be 0x after this > > > > change > > > > instead of 0, since you're writing 32 bits as duration instead > > > > of > > > > 64 > > > > where the high 32 bits (corresponding to the unused field) are > > > > zeroed. > > > > That means the ivf demuxer prior to this patch will read bogus > > > > duration > > > > values from ivf files created after this patch. > > > > > > > > Just leave the muxer as is. > > > > > > Why not just write zero? > > > > > > It's, to me, worse to leave a bogus 64-bit write to appease bugs > > > in > > > our > > > own demuxer. It's confusing and misleading for any readers of the > > > code. > > > > In that case I would prefer changing the initial written value to 0 > > rather than 0xULL. Writing over the unused bytes > > twice > > to get around an old error is a bit odd as well. > > That may needlessly break non-seekable output. Writing a 0 as the initial 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, the ivf_write_file_header function is here: https://github.com/webmproject/libvpx/blob/v1.8.1/ivfenc.c#L16 ) So we need to make sure that ffmpeg can handle 0 values in this field regardless. -- Calvin Walton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ivfdec/ivfenc: Match behaviour of libvpx and chromium
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. > > Switch ffmpeg to match the behaviour of libvpx & chromium. Just to note (now that I've got fate working on my dev machine again), if this patch is applied, a bunch of the test references will need updates due to the ivf file output changing. I'll include those updates if I do a second patch revision. -- Calvin Walton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ivfdec/ivfenc: Match behaviour of libvpx and chromium
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/libavformat/ivfdec.c b/libavformat/ivfdec.c > > index 40ae464b76..2eaa5164ff 100644 > > --- a/libavformat/ivfdec.c > > +++ b/libavformat/ivfdec.c > > @@ -53,7 +53,8 @@ static int read_header(AVFormatContext *s) > > st->codecpar->height = avio_rl16(s->pb); > > time_base.den = avio_rl32(s->pb); > > time_base.num = avio_rl32(s->pb); > > -st->duration = avio_rl64(s->pb); > > +st->nb_frames = avio_rl32(s->pb); > > The demuxer will report N/A as duration after this. This is intentional, as the container format doesn't have a duration field, only a frame count. I suppose it might be possible to estimate a duration by probing the file to guess the average framerate, and then dividing the frame count by the framerate - but I'm not familiar with how that could be done in the demuxer > > size_t end = avio_tell(pb); > > > > avio_seek(pb, 24, SEEK_SET); > > -avio_wl64(pb, ctx->frame_cnt * ctx->sum_delta_pts / (ctx- > > >frame_cnt - 1)); > > +avio_wl32(pb, ctx->frame_cnt); > > avio_seek(pb, end, SEEK_SET); > > } > > Similarly, old versions of the ivf demuxer will read bogus duration > values after this change. Old versions of the ivf demuxer read bogus duration values for files generated by vpxenc in the case where the timebase is something other than 1/framerate (i think this can happen if a timebase is manually set or if a fractional framerate is used) or if the file is vfr (I'm not sure if vpxenc can generate vfr files). -- Calvin Walton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] ivfdec/ivfenc: Match behaviour of libvpx and chromium
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 0 to the frame count field when initially writing the
header
then seeks back and overwrites it with the real frame count. ffmpeg used to
write
0x - I've changed the behaviour to match libvpx.
References:
https://github.com/webmproject/libvpx/blob/v1.8.1/ivfenc.c#L16
Which is called from:
https://github.com/webmproject/libvpx/blob/v1.8.1/vpxenc.c#L1191 (initial
header)
https://github.com/webmproject/libvpx/blob/v1.8.1/vpxenc.c#L1209 (rewrite with
frame count)
And the chromium parser:
https://chromium.googlesource.com/chromium/src/media/+/1681b9abff73fe0e3d0932aefdab4f039a284d1a/filters/ivf_parser.h
---
libavformat/ivfdec.c | 3 ++-
libavformat/ivfenc.c | 11 ---
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/libavformat/ivfdec.c b/libavformat/ivfdec.c
index 40ae464b76..2eaa5164ff 100644
--- a/libavformat/ivfdec.c
+++ b/libavformat/ivfdec.c
@@ -53,7 +53,8 @@ static int read_header(AVFormatContext *s)
st->codecpar->height = avio_rl16(s->pb);
time_base.den = avio_rl32(s->pb);
time_base.num = avio_rl32(s->pb);
-st->duration = avio_rl64(s->pb);
+st->nb_frames = avio_rl32(s->pb);
+avio_skip(s->pb, 4); // 32 bits unused
st->need_parsing = AVSTREAM_PARSE_HEADERS;
diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
index adf72117e9..85ca6045ba 100644
--- a/libavformat/ivfenc.c
+++ b/libavformat/ivfenc.c
@@ -22,8 +22,7 @@
#include "libavutil/intreadwrite.h"
typedef struct IVFEncContext {
-unsigned frame_cnt;
-uint64_t last_pts, sum_delta_pts;
+uint32_t frame_cnt;
} IVFEncContext;
static int ivf_write_header(AVFormatContext *s)
@@ -53,7 +52,8 @@ static int ivf_write_header(AVFormatContext *s)
avio_wl16(pb, par->height);
avio_wl32(pb, s->streams[0]->time_base.den);
avio_wl32(pb, s->streams[0]->time_base.num);
-avio_wl64(pb, 0xULL);
+avio_wl32(pb, 0); // frame count
+avio_wl32(pb, 0); // unused
return 0;
}
@@ -66,10 +66,7 @@ static int ivf_write_packet(AVFormatContext *s, AVPacket
*pkt)
avio_wl32(pb, pkt->size);
avio_wl64(pb, pkt->pts);
avio_write(pb, pkt->data, pkt->size);
-if (ctx->frame_cnt)
-ctx->sum_delta_pts += pkt->pts - ctx->last_pts;
ctx->frame_cnt++;
-ctx->last_pts = pkt->pts;
return 0;
}
@@ -83,7 +80,7 @@ static int ivf_write_trailer(AVFormatContext *s)
size_t end = avio_tell(pb);
avio_seek(pb, 24, SEEK_SET);
-avio_wl64(pb, ctx->frame_cnt * ctx->sum_delta_pts / (ctx->frame_cnt -
1));
+avio_wl32(pb, ctx->frame_cnt);
avio_seek(pb, end, SEEK_SET);
}
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3] Allow 'concat' filter to support inputs with different frame rates
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 framerate it might cause judder.
This patch checks if all of the video inputs have the same framerate, and
if not it sets the out link to use '1/0' as the frame rate, the value
meaning "unknown/vfr".
A test is added to verify the VFR behaviour. The existing test for CFR
behaviour passes unchanged.
---
Updated version of
https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-March/208251.html
Fixes the missing concat-vfr filtergraph for tests, and adds a newline
to the end of the log message.
libavfilter/avf_concat.c | 15 ++-
tests/fate/filter-video.mak | 4 +-
tests/filtergraphs/concat-vfr| 8 ++
tests/ref/fate/filter-concat-vfr | 224 +++
4 files changed, 249 insertions(+), 2 deletions(-)
create mode 100644 tests/filtergraphs/concat-vfr
create mode 100644 tests/ref/fate/filter-concat-vfr
diff --git a/libavfilter/avf_concat.c b/libavfilter/avf_concat.c
index 1d0c2de290..2791859d8f 100644
--- a/libavfilter/avf_concat.c
+++ b/libavfilter/avf_concat.c
@@ -131,8 +131,21 @@ static int config_output(AVFilterLink *outlink)
outlink->h = inlink->h;
outlink->sample_aspect_ratio = inlink->sample_aspect_ratio;
outlink->format = inlink->format;
+outlink->frame_rate = inlink->frame_rate;
+
+for (seg = 1; seg < cat->nb_segments; seg++) {
+inlink = ctx->inputs[in_no + seg * ctx->nb_outputs];
+if (outlink->frame_rate.num != inlink->frame_rate.num ||
+outlink->frame_rate.den != outlink->frame_rate.den) {
+av_log(ctx, AV_LOG_VERBOSE,
+"Video inputs have different frame rates, output will be
VFR\n");
+outlink->frame_rate = av_make_q(1, 0);
+break;
+}
+}
+
for (seg = 1; seg < cat->nb_segments; seg++) {
-inlink = ctx->inputs[in_no += ctx->nb_outputs];
+inlink = ctx->inputs[in_no + seg * ctx->nb_outputs];
if (!outlink->sample_aspect_ratio.num)
outlink->sample_aspect_ratio = inlink->sample_aspect_ratio;
/* possible enhancement: unsafe mode, do not check */
diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index 60c6be143b..0c6ee72432 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -424,9 +424,11 @@ FATE_FILTER_SAMPLES-$(call ALLYES, VMD_DEMUXER
VMDVIDEO_DECODER FORMAT_FILTER PE
fate-filter-gradfun-sample: tests/data/filtergraphs/gradfun
fate-filter-gradfun-sample: CMD = framecrc -i $(TARGET_SAMPLES)/vmd/12.vmd
-filter_script $(TARGET_PATH)/tests/data/filtergraphs/gradfun -an -frames:v 20
-FATE_FILTER-$(call ALLYES, TESTSRC_FILTER SINE_FILTER CONCAT_FILTER) +=
fate-filter-concat
+FATE_FILTER-$(call ALLYES, TESTSRC_FILTER SINE_FILTER CONCAT_FILTER) +=
fate-filter-concat fate-filter-concat-vfr
fate-filter-concat: tests/data/filtergraphs/concat
fate-filter-concat: CMD = framecrc -filter_complex_script
$(TARGET_PATH)/tests/data/filtergraphs/concat
+fate-filter-concat-vfr: tests/data/filtergraphs/concat-vfr
+fate-filter-concat-vfr: CMD = framecrc -filter_complex_script
$(TARGET_PATH)/tests/data/filtergraphs/concat-vfr
FATE_FILTER-$(call ALLYES, TESTSRC2_FILTER FPS_FILTER MPDECIMATE_FILTER) +=
fate-filter-mpdecimate
fate-filter-mpdecimate: CMD = framecrc -lavfi
testsrc2=r=2:d=10,fps=3,mpdecimate -r 3 -pix_fmt yuv420p
diff --git a/tests/filtergraphs/concat-vfr b/tests/filtergraphs/concat-vfr
new file mode 100644
index 00..e15cb96845
--- /dev/null
+++ b/tests/filtergraphs/concat-vfr
@@ -0,0 +1,8 @@
+testsrc=r=5:n=1:d=2 [v1];
+sine=440:b=2:d=1 [a1];
+testsrc=r=15:n=1:d=1 [v2];
+sine=622:b=2:d=2 [a2];
+testsrc=r=8:n=1:d=1 [v3];
+sine=880:b=2:d=1 [a3];
+
+[v1][a1][v2][a2][v3][a3] concat=v=1:a=1:n=3
diff --git a/tests/ref/fate/filter-concat-vfr b/tests/ref/fate/filter-concat-vfr
new file mode 100644
index 00..0dece67a07
--- /dev/null
+++ b/tests/ref/fate/filter-concat-vfr
@@ -0,0 +1,224 @@
+#tb 0: 1/100
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 320x240
+#sar 0: 1/1
+#tb 1: 1/44100
+#media_type 1: audio
+#codec_id 1: pcm_s16le
+#sample_rate 1: 44100
+#channel_layout 1: 4
+#channel_layout_name 1: mono
+0, 0, 0,0, 230400, 0x88c4d19a
+1, 0, 0, 1024, 2048, 0xb3f10192
+1, 1024, 1024, 1024, 2048, 0xb340fe4e
+1, 2048, 2048, 1024, 2048, 0x0a5f0111
+1, 3072, 3072, 1024, 2048, 0x51be06b8
+1, 4096, 4096, 1024, 2048, 0x71a1ffcb
+1, 5120, 5120, 1024, 2048, 0x7f64f50f
+1, 6144, 6144, 1024, 2048, 0x70a8fa17
+1,
Re: [FFmpeg-devel] [PATCH v3 0/2] libavfilter/vf_fps: Rewrite using activate callback
Ping?
I've been using this patch set in my production system for the past
week. There I've been running some fairly complicated filter pipelines
generated by scripts with good results - it's working reliably (no
stalls/hangs) and has solved my memory usage issue.
Calvin.
On Thu, 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 conditional check
> if (s->status && s->frames_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.
>
> Calvin Walton (2):
> libavfilter/vf_fps: Rewrite using activate callback
> libavfilter/vf_fps: Minor cleanups
>
> libavfilter/vf_fps.c | 392
> ++-
> 1 file changed, 202 insertions(+), 190 deletions(-)
>
--
Calvin Walton <calvin.wal...@kepstin.ca>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v3 0/2] libavfilter/vf_fps: Rewrite using activate callback
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 check
if (s->status && s->frames_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.
Calvin Walton (2):
libavfilter/vf_fps: Rewrite using activate callback
libavfilter/vf_fps: Minor cleanups
libavfilter/vf_fps.c | 392 ++-
1 file changed, 202 insertions(+), 190 deletions(-)
--
2.16.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v3 2/2] libavfilter/vf_fps: Minor cleanups
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 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/libavfilter/vf_fps.c b/libavfilter/vf_fps.c
index cc350243a9..9167a00a13 100644
--- a/libavfilter/vf_fps.c
+++ b/libavfilter/vf_fps.c
@@ -147,16 +147,14 @@ static av_cold void uninit(AVFilterContext *ctx)
"%d frames duplicated.\n", s->frames_in, s->frames_out, s->drop,
s->dup);
}
-static int config_props(AVFilterLink* link)
+static int config_props(AVFilterLink* outlink)
{
-AVFilterContext *ctx = link->src;
-AVFilterLink *inlink = ctx->inputs[0];
-FPSContext *s = ctx->priv;
+AVFilterContext *ctx= outlink->src;
+AVFilterLink*inlink = ctx->inputs[0];
+FPSContext *s = ctx->priv;
-link->time_base = av_inv_q(s->framerate);
-link->frame_rate= s->framerate;
-link->w = link->src->inputs[0]->w;
-link->h = link->src->inputs[0]->h;
+outlink->time_base = av_inv_q(s->framerate);
+outlink->frame_rate = s->framerate;
/* Calculate the input and output pts offsets for start_time */
if (s->start_time != DBL_MAX && s->start_time != AV_NOPTS_VALUE) {
@@ -168,7 +166,7 @@ static int config_props(AVFilterLink* link)
}
s->in_pts_off = av_rescale_q_rnd(first_pts, AV_TIME_BASE_Q,
inlink->time_base,
s->rounding | AV_ROUND_PASS_MINMAX);
-s->out_pts_off = av_rescale_q_rnd(first_pts, AV_TIME_BASE_Q,
link->time_base,
+s->out_pts_off = av_rescale_q_rnd(first_pts, AV_TIME_BASE_Q,
outlink->time_base,
s->rounding | AV_ROUND_PASS_MINMAX);
s->next_pts = s->out_pts_off;
av_log(ctx, AV_LOG_VERBOSE, "Set first pts to (in:%"PRId64"
out:%"PRId64") from start time %f\n",
--
2.16.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v3 1/2] libavfilter/vf_fps: Rewrite using activate callback
The old version of the filter had a problem where it would queue up
all of the duplicate frames required to fill a timestamp gap in a
single call to filter_frame. In problematic files - I've hit this in
webcam streams with large gaps due to network issues - this will queue
up a potentially huge number of frames. (I've seen it trigger the Linux
OOM-killer on particularly large pts gaps.)
This revised version of the filter using the activate callback will
generate at most 1 frame each time it is called.
---
libavfilter/vf_fps.c | 384 ++-
1 file changed, 199 insertions(+), 185 deletions(-)
diff --git a/libavfilter/vf_fps.c b/libavfilter/vf_fps.c
index dbafd2c35a..cc350243a9 100644
--- a/libavfilter/vf_fps.c
+++ b/libavfilter/vf_fps.c
@@ -2,6 +2,7 @@
* Copyright 2007 Bobby Bingham
* Copyright 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"
+#include "libavutil/avassert.h"
#include "libavutil/mathematics.h"
#include "libavutil/opt.h"
-#include "libavutil/parseutils.h"
-
-#define FF_INTERNAL_FIELDS 1
-#include "framequeue.h"
#include "avfilter.h"
+#include "filters.h"
#include "internal.h"
-#include "video.h"
enum EOFAction {
EOF_ACTION_ROUND,
@@ -49,18 +45,27 @@ enum EOFAction {
typedef struct FPSContext {
const AVClass *class;
-AVFifoBuffer *fifo; ///< store frames until we get two successive
timestamps
-
-/* timestamps in input timebase */
-int64_t first_pts; ///< pts of the first frame that arrived on this
filter
-
double start_time; ///< pts, in seconds, of the expected first frame
AVRational framerate; ///< target framerate
int rounding; ///< AVRounding method for timestamps
int eof_action; ///< action performed for last frame in FIFO
+/* Set during outlink configuration */
+int64_t in_pts_off;///< input frame pts offset for start_time handling
+int64_t out_pts_off; ///< output frame pts offset for start_time
handling
+
+/* Runtime state */
+int status;///< buffered input status
+int64_t status_pts;///< buffered input status timestamp
+
+AVFrame *frames[2]; ///< buffered frames
+int frames_count; ///< number of buffered frames
+
+int64_t next_pts; ///< pts of the next frame to output
+
/* statistics */
+int cur_frame_out; ///< number of times current frame has been
output
int frames_in; ///< number of frames on input
int frames_out;///< number of frames on output
int dup; ///< number of frames duplicated
@@ -91,31 +96,51 @@ static av_cold int init(AVFilterContext *ctx)
{
FPSContext *s = ctx->priv;
-if (!(s->fifo = av_fifo_alloc_array(2, sizeof(AVFrame*
-return AVERROR(ENOMEM);
-
-s->first_pts= AV_NOPTS_VALUE;
+s->status_pts = AV_NOPTS_VALUE;
+s->next_pts = AV_NOPTS_VALUE;
av_log(ctx, AV_LOG_VERBOSE, "fps=%d/%d\n", s->framerate.num,
s->framerate.den);
return 0;
}
-static void flush_fifo(AVFifoBuffer *fifo)
+/* Remove the first frame from the buffer, returning it */
+static AVFrame *shift_frame(AVFilterContext *ctx, FPSContext *s)
{
-while (av_fifo_size(fifo)) {
-AVFrame *tmp;
-av_fifo_generic_read(fifo, , sizeof(tmp), NULL);
-av_frame_free();
+AVFrame *frame;
+
+/* Must only be called when there are frames in the buffer */
+av_assert1(s->frames_count > 0);
+
+frame = s->frames[0];
+s->frames[0] = s->frames[1];
+s->frames[1] = NULL;
+s->frames_count--;
+
+/* Update statistics counters */
+s->frames_out += s->cur_frame_out;
+if (s->cur_frame_out > 1) {
+av_log(ctx, AV_LOG_DEBUG, "Duplicated frame with pts %"PRId64" %d
times\n",
+ frame->pts, s->cur_frame_out - 1);
+s->dup += s->cur_frame_out - 1;
+} else if (s->cur_frame_out == 0) {
+av_log(ctx, AV_LOG_DEBUG, "Dropping frame with pts %"PRId64"\n",
+ frame->pts);
+s->drop++;
}
+s->cur_frame_out = 0;
+
+return frame;
}
static av_cold void uninit(AVFilterContext *ctx)
{
FPSContext *s = ctx->priv;
-if (s->fifo) {
-s->drop += av_fifo_size(s->fifo) / sizeof(AVFrame*);
-flush_fifo(s->fifo);
-av_fifo_freep(>fifo);
+
+AVFrame *frame;
+
+while (s->frames_count > 0) {
+frame = shift_frame(ctx,
Re: [FFmpeg-devel] [PATCH v2 2/3] libavfilter/vf_fps: Rewrite using activate callback
I've found one minor problem with this patch. The actual functionality is correct, as best I can tell, but the stats collection (dropped/duplicated frames) will under-report dropped frames in my testing. I'm going to rework the stats collection code a bit, but I expect this to be a 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 the duplicate frames required to fill a timestamp gap in a > single call to filter_frame. In problematic files - I've hit this in > webcam streams with large gaps due to network issues - this will > queue > up a potentially huge number of frames. (I've seen it trigger the > Linux > OOM-killer on particularly large pts gaps.) > > This revised version of the filter using the activate callback will > generate at most 1 frame each time it is called. > --- > libavfilter/vf_fps.c | 383 ++--- > -- > 1 file changed, 199 insertions(+), 184 deletions(-) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 1/3] libavfilter/vf_fps: Add tests for start_time option
--- 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/fate/filter-fps-start-fill diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak index e3e128cf67..07572143a8 100644 --- a/tests/fate/filter-video.mak +++ b/tests/fate/filter-video.mak @@ -425,7 +425,7 @@ fate-filter-concat: CMD = framecrc -filter_complex_script $(TARGET_PATH)/tests/d FATE_FILTER-$(call ALLYES, TESTSRC2_FILTER FPS_FILTER MPDECIMATE_FILTER) += fate-filter-mpdecimate fate-filter-mpdecimate: CMD = framecrc -lavfi testsrc2=r=2:d=10,fps=3,mpdecimate -r 3 -pix_fmt yuv420p -FATE_FILTER-$(call ALLYES, FPS_FILTER TESTSRC2_FILTER) += fate-filter-fps-up fate-filter-fps-up-round-down fate-filter-fps-up-round-up fate-filter-fps-down fate-filter-fps-down-round-down fate-filter-fps-down-round-up fate-filter-fps-down-eof-pass +FATE_FILTER-$(call ALLYES, FPS_FILTER TESTSRC2_FILTER) += fate-filter-fps-up fate-filter-fps-up-round-down fate-filter-fps-up-round-up fate-filter-fps-down fate-filter-fps-down-round-down fate-filter-fps-down-round-up fate-filter-fps-down-eof-pass fate-filter-fps-start-drop fate-filter-fps-start-fill fate-filter-fps-up: CMD = framecrc -lavfi testsrc2=r=3:d=2,fps=7 fate-filter-fps-up-round-down: CMD = framecrc -lavfi testsrc2=r=3:d=2,fps=7:round=down fate-filter-fps-up-round-up: CMD = framecrc -lavfi testsrc2=r=3:d=2,fps=7:round=up @@ -433,6 +433,8 @@ fate-filter-fps-down: CMD = framecrc -lavfi testsrc2=r=7:d=3.5,fps=3 fate-filter-fps-down-round-down: CMD = framecrc -lavfi testsrc2=r=7:d=3.5,fps=3:round=down fate-filter-fps-down-round-up: CMD = framecrc -lavfi testsrc2=r=7:d=3.5,fps=3:round=up fate-filter-fps-down-eof-pass: CMD = framecrc -lavfi testsrc2=r=7:d=3.5,fps=3:eof_action=pass +fate-filter-fps-start-drop: CMD = framecrc -lavfi testsrc2=r=7:d=3.5,fps=3:start_time=1.5 +fate-filter-fps-start-fill: CMD = framecrc -lavfi testsrc2=r=7:d=1.5,setpts=PTS+14,fps=3:start_time=1.5 FATE_FILTER_SAMPLES-$(call ALLYES, MOV_DEMUXER FPS_FILTER QTRLE_DECODER) += fate-filter-fps-cfr fate-filter-fps fate-filter-fps-r fate-filter-fps-cfr: CMD = framecrc -i $(TARGET_SAMPLES)/qtrle/apple-animation-variable-fps-bug.mov -r 30 -vsync cfr -pix_fmt yuv420p diff --git a/tests/ref/fate/filter-fps-start-drop b/tests/ref/fate/filter-fps-start-drop new file mode 100644 index 00..cfa1c40997 --- /dev/null +++ b/tests/ref/fate/filter-fps-start-drop @@ -0,0 +1,11 @@ +#tb 0: 1/3 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 320x240 +#sar 0: 1/1 +0, 5, 5,1, 115200, 0x2d0ba5a4 +0, 6, 6,1, 115200, 0xc95a675e +0, 7, 7,1, 115200, 0xf040bf35 +0, 8, 8,1, 115200, 0x5635daa5 +0, 9, 9,1, 115200, 0x0caf7172 +0, 10, 10,1, 115200, 0xc8ce7fb1 diff --git a/tests/ref/fate/filter-fps-start-fill b/tests/ref/fate/filter-fps-start-fill new file mode 100644 index 00..c5efb42a8f --- /dev/null +++ b/tests/ref/fate/filter-fps-start-fill @@ -0,0 +1,11 @@ +#tb 0: 1/3 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 320x240 +#sar 0: 1/1 +0, 5, 5,1, 115200, 0x3744b3ed +0, 6, 6,1, 115200, 0x3744b3ed +0, 7, 7,1, 115200, 0x201b9db1 +0, 8, 8,1, 115200, 0x75e1a17b +0, 9, 9,1, 115200, 0xb73857e2 +0, 10, 10,1, 115200, 0x02b6ab21 -- 2.16.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 3/3] libavfilter/vf_fps: Minor cleanups
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 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/libavfilter/vf_fps.c b/libavfilter/vf_fps.c
index 74500f59c9..0ca4f8563f 100644
--- a/libavfilter/vf_fps.c
+++ b/libavfilter/vf_fps.c
@@ -137,16 +137,14 @@ static av_cold void uninit(AVFilterContext *ctx)
"%d frames duplicated.\n", s->frames_in, s->frames_out, s->drop,
s->dup);
}
-static int config_props(AVFilterLink* link)
+static int config_props(AVFilterLink* outlink)
{
-AVFilterContext *ctx = link->src;
-AVFilterLink *inlink = ctx->inputs[0];
-FPSContext *s = ctx->priv;
+AVFilterContext *ctx= outlink->src;
+AVFilterLink*inlink = ctx->inputs[0];
+FPSContext *s = ctx->priv;
-link->time_base = av_inv_q(s->framerate);
-link->frame_rate= s->framerate;
-link->w = link->src->inputs[0]->w;
-link->h = link->src->inputs[0]->h;
+outlink->time_base = av_inv_q(s->framerate);
+outlink->frame_rate = s->framerate;
/* Calculate the input and output pts offsets for start_time */
if (s->start_time != DBL_MAX && s->start_time != AV_NOPTS_VALUE) {
@@ -158,7 +156,7 @@ static int config_props(AVFilterLink* link)
}
s->in_pts_off = av_rescale_q_rnd(first_pts, AV_TIME_BASE_Q,
inlink->time_base,
s->rounding | AV_ROUND_PASS_MINMAX);
-s->out_pts_off = av_rescale_q_rnd(first_pts, AV_TIME_BASE_Q,
link->time_base,
+s->out_pts_off = av_rescale_q_rnd(first_pts, AV_TIME_BASE_Q,
outlink->time_base,
s->rounding | AV_ROUND_PASS_MINMAX);
s->next_pts = s->out_pts_off;
av_log(ctx, AV_LOG_VERBOSE, "Set first pts to (in:%"PRId64"
out:%"PRId64") from start time %f\n",
--
2.16.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 0/3] libavfilter/vf_fps: Rewrite using activate callback
Second revision of the patch set, incorporating feedback from Nicolas George. This also fixes the start_time option, which didn't work at all in the v1 patch set. I've added some tests based on the behaviour of the old version of the filter, and adapted the new version to pass them. 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 | 391 ++- tests/fate/filter-video.mak | 4 +- tests/ref/fate/filter-fps-start-drop | 11 + tests/ref/fate/filter-fps-start-fill | 11 + 4 files changed, 227 insertions(+), 190 deletions(-) create mode 100644 tests/ref/fate/filter-fps-start-drop create mode 100644 tests/ref/fate/filter-fps-start-fill -- 2.16.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 2/3] libavfilter/vf_fps: Rewrite using activate callback
The old version of the filter had a problem where it would queue up
all of the duplicate frames required to fill a timestamp gap in a
single call to filter_frame. In problematic files - I've hit this in
webcam streams with large gaps due to network issues - this will queue
up a potentially huge number of frames. (I've seen it trigger the Linux
OOM-killer on particularly large pts gaps.)
This revised version of the filter using the activate callback will
generate at most 1 frame each time it is called.
---
libavfilter/vf_fps.c | 383 ++-
1 file changed, 199 insertions(+), 184 deletions(-)
diff --git a/libavfilter/vf_fps.c b/libavfilter/vf_fps.c
index dbafd2c35a..74500f59c9 100644
--- a/libavfilter/vf_fps.c
+++ b/libavfilter/vf_fps.c
@@ -2,6 +2,7 @@
* Copyright 2007 Bobby Bingham
* Copyright 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"
+#include "libavutil/avassert.h"
#include "libavutil/mathematics.h"
#include "libavutil/opt.h"
-#include "libavutil/parseutils.h"
-
-#define FF_INTERNAL_FIELDS 1
-#include "framequeue.h"
#include "avfilter.h"
+#include "filters.h"
#include "internal.h"
-#include "video.h"
enum EOFAction {
EOF_ACTION_ROUND,
@@ -49,17 +45,25 @@ enum EOFAction {
typedef struct FPSContext {
const AVClass *class;
-AVFifoBuffer *fifo; ///< store frames until we get two successive
timestamps
-
-/* timestamps in input timebase */
-int64_t first_pts; ///< pts of the first frame that arrived on this
filter
-
double start_time; ///< pts, in seconds, of the expected first frame
AVRational framerate; ///< target framerate
int rounding; ///< AVRounding method for timestamps
int eof_action; ///< action performed for last frame in FIFO
+/* Set during outlink configuration */
+int64_t in_pts_off;///< input frame pts offset for start_time handling
+int64_t out_pts_off; ///< output frame pts offset for start_time
handling
+
+/* Runtime state */
+int status;///< buffered input status
+int64_t status_pts;///< buffered input status timestamp
+
+AVFrame *frames[2]; ///< buffered frames
+int frames_count; ///< number of buffered frames
+
+int64_t next_pts; ///< pts of the next frame to output
+
/* statistics */
int frames_in; ///< number of frames on input
int frames_out;///< number of frames on output
@@ -91,31 +95,42 @@ static av_cold int init(AVFilterContext *ctx)
{
FPSContext *s = ctx->priv;
-if (!(s->fifo = av_fifo_alloc_array(2, sizeof(AVFrame*
-return AVERROR(ENOMEM);
-
-s->first_pts= AV_NOPTS_VALUE;
+s->status_pts = AV_NOPTS_VALUE;
+s->next_pts = AV_NOPTS_VALUE;
av_log(ctx, AV_LOG_VERBOSE, "fps=%d/%d\n", s->framerate.num,
s->framerate.den);
return 0;
}
-static void flush_fifo(AVFifoBuffer *fifo)
+/* Remove the first frame from the buffer, returning it */
+static AVFrame *shift_frame(FPSContext *s)
{
-while (av_fifo_size(fifo)) {
-AVFrame *tmp;
-av_fifo_generic_read(fifo, , sizeof(tmp), NULL);
-av_frame_free();
-}
+AVFrame *frame;
+
+/* Must only be called when there are frames in the buffer */
+av_assert1(s->frames_count > 0);
+
+frame = s->frames[0];
+s->frames[0] = s->frames[1];
+s->frames[1] = NULL;
+s->frames_count--;
+
+return frame;
}
static av_cold void uninit(AVFilterContext *ctx)
{
FPSContext *s = ctx->priv;
-if (s->fifo) {
-s->drop += av_fifo_size(s->fifo) / sizeof(AVFrame*);
-flush_fifo(s->fifo);
-av_fifo_freep(>fifo);
+
+AVFrame *frame;
+
+/* Free any remaining buffered frames. This only happens if a downstream
+ * filter has asked us to stop, so don't count them as dropped. */
+av_log(ctx, AV_LOG_DEBUG, "Discarding %d buffered frame(s) at exit.\n",
+s->frames_count);
+while (s->frames_count > 0) {
+frame = shift_frame(s);
+av_frame_free();
}
av_log(ctx, AV_LOG_VERBOSE, "%d frames in, %d frames out; %d frames
dropped, "
@@ -124,198 +139,198 @@ static av_cold void uninit(AVFilterContext *ctx)
static int config_props(AVFilterLink* link)
{
-FPSContext *s = link->src->priv;
+AVFilterContext *ctx = link->src;
+AVFilterLink *inlink = ctx->inputs[0];
+FPSContext *s = ctx->priv;
link->time_base = av_inv_q(s
Re: [FFmpeg-devel] [PATCH 2/2] libavfilter/vf_fps: Rewrite using activate callback
+/* Schedule us to perform 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 <calvin.wal...@kepstin.ca> ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] libavfilter/vf_fps: Rewrite using activate callback
Hi Nicolas, On Sun, 2018-02-18 at 19:01 +0100, Nicolas George wrote: > > Thanks for the patch. It was something I had in my TODO list for a > long > time. The code looks very good. Here are a few comments below. Of > course > open to discussion. Thanks for the review. I'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 start_time option too.) -- Calvin Walton <calvin.wal...@kepstin.ca> ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] libavfilter/vf_fps: Rewrite using activate callback
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" option, since I haven't figured out what it's supposed > to > do. At this point I'm fairly confident that the behaviour matches the existing filter, and that I've gotten the eof_action behaviour correct as well. Cheers! Calvin. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 0/2] libavfilter/vf_fps: Rewrite using activate callback
I've run into some problems with the current fps filter memory usage, because of how it buffers all of the frames needed to fill in large timestamp gaps, rather than generate them on the fly. In order to fix this, I have rewritten the fps filter to use the newer "activate" api. I 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 | 398 +- tests/fate/filter-video.mak | 10 +- tests/ref/fate/filter-fps-down| 15 ++ tests/ref/fate/filter-fps-down-eof-pass | 16 ++ tests/ref/fate/filter-fps-down-round-down | 15 ++ tests/ref/fate/filter-fps-down-round-up | 16 ++ tests/ref/fate/filter-fps-up | 17 ++ tests/ref/fate/filter-fps-up-round-down | 16 ++ tests/ref/fate/filter-fps-up-round-up | 17 ++ 9 files changed, 351 insertions(+), 169 deletions(-) create mode 100644 tests/ref/fate/filter-fps-down create mode 100644 tests/ref/fate/filter-fps-down-eof-pass create mode 100644 tests/ref/fate/filter-fps-down-round-down create mode 100644 tests/ref/fate/filter-fps-down-round-up create mode 100644 tests/ref/fate/filter-fps-up create mode 100644 tests/ref/fate/filter-fps-up-round-down create mode 100644 tests/ref/fate/filter-fps-up-round-up ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] libavfilter/vf_fps: Add more fate tests
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/filter-fps-down-eof-pass | 16 tests/ref/fate/filter-fps-down-round-down | 15 +++ tests/ref/fate/filter-fps-down-round-up | 16 tests/ref/fate/filter-fps-up | 17 + tests/ref/fate/filter-fps-up-round-down | 16 tests/ref/fate/filter-fps-up-round-up | 17 + 8 files changed, 121 insertions(+), 1 deletion(-) create mode 100644 tests/ref/fate/filter-fps-down create mode 100644 tests/ref/fate/filter-fps-down-eof-pass create mode 100644 tests/ref/fate/filter-fps-down-round-down create mode 100644 tests/ref/fate/filter-fps-down-round-up create mode 100644 tests/ref/fate/filter-fps-up create mode 100644 tests/ref/fate/filter-fps-up-round-down create mode 100644 tests/ref/fate/filter-fps-up-round-up diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak index 221ae81fdc..e3e128cf67 100644 --- a/tests/fate/filter-video.mak +++ b/tests/fate/filter-video.mak @@ -108,7 +108,6 @@ FATE_FILTER-$(call ALLYES, AVDEVICE TESTSRC_FILTER FORMAT_FILTER CONCAT_FILTER S fate-filter-lavd-scalenorm: tests/data/filtergraphs/scalenorm fate-filter-lavd-scalenorm: CMD = framecrc -f lavfi -graph_file $(TARGET_PATH)/tests/data/filtergraphs/scalenorm -i dummy - FATE_FILTER-$(call ALLYES, FRAMERATE_FILTER TESTSRC2_FILTER) += fate-filter-framerate-up fate-filter-framerate-down fate-filter-framerate-up: CMD = framecrc -lavfi testsrc2=r=2:d=10,framerate=fps=10 -t 1 fate-filter-framerate-down: CMD = framecrc -lavfi testsrc2=r=2:d=10,framerate=fps=1 -t 1 @@ -426,6 +425,15 @@ fate-filter-concat: CMD = framecrc -filter_complex_script $(TARGET_PATH)/tests/d FATE_FILTER-$(call ALLYES, TESTSRC2_FILTER FPS_FILTER MPDECIMATE_FILTER) += fate-filter-mpdecimate fate-filter-mpdecimate: CMD = framecrc -lavfi testsrc2=r=2:d=10,fps=3,mpdecimate -r 3 -pix_fmt yuv420p +FATE_FILTER-$(call ALLYES, FPS_FILTER TESTSRC2_FILTER) += fate-filter-fps-up fate-filter-fps-up-round-down fate-filter-fps-up-round-up fate-filter-fps-down fate-filter-fps-down-round-down fate-filter-fps-down-round-up fate-filter-fps-down-eof-pass +fate-filter-fps-up: CMD = framecrc -lavfi testsrc2=r=3:d=2,fps=7 +fate-filter-fps-up-round-down: CMD = framecrc -lavfi testsrc2=r=3:d=2,fps=7:round=down +fate-filter-fps-up-round-up: CMD = framecrc -lavfi testsrc2=r=3:d=2,fps=7:round=up +fate-filter-fps-down: CMD = framecrc -lavfi testsrc2=r=7:d=3.5,fps=3 +fate-filter-fps-down-round-down: CMD = framecrc -lavfi testsrc2=r=7:d=3.5,fps=3:round=down +fate-filter-fps-down-round-up: CMD = framecrc -lavfi testsrc2=r=7:d=3.5,fps=3:round=up +fate-filter-fps-down-eof-pass: CMD = framecrc -lavfi testsrc2=r=7:d=3.5,fps=3:eof_action=pass + FATE_FILTER_SAMPLES-$(call ALLYES, MOV_DEMUXER FPS_FILTER QTRLE_DECODER) += fate-filter-fps-cfr fate-filter-fps fate-filter-fps-r fate-filter-fps-cfr: CMD = framecrc -i $(TARGET_SAMPLES)/qtrle/apple-animation-variable-fps-bug.mov -r 30 -vsync cfr -pix_fmt yuv420p fate-filter-fps-r: CMD = framecrc -i $(TARGET_SAMPLES)/qtrle/apple-animation-variable-fps-bug.mov -r 30 -vf fps -pix_fmt yuv420p diff --git a/tests/ref/fate/filter-fps-down b/tests/ref/fate/filter-fps-down new file mode 100644 index 00..eb8b368985 --- /dev/null +++ b/tests/ref/fate/filter-fps-down @@ -0,0 +1,15 @@ +#tb 0: 1/3 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 320x240 +#sar 0: 1/1 +0, 0, 0,1, 115200, 0x0c1062d6 +0, 1, 1,1, 115200, 0x278d887e +0, 2, 2,1, 115200, 0x75e1a17b +0, 3, 3,1, 115200, 0x686b77e7 +0, 4, 4,1, 115200, 0x1fc2d693 +0, 5, 5,1, 115200, 0x2d0ba5a4 +0, 6, 6,1, 115200, 0x40426f99 +0, 7, 7,1, 115200, 0xc705ccd9 +0, 8, 8,1, 115200, 0x5635daa5 +0, 9, 9,1, 115200, 0x7161ef8f diff --git a/tests/ref/fate/filter-fps-down-eof-pass b/tests/ref/fate/filter-fps-down-eof-pass new file mode 100644 index 00..0b6725f037 --- /dev/null +++ b/tests/ref/fate/filter-fps-down-eof-pass @@ -0,0 +1,16 @@ +#tb 0: 1/3 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 320x240 +#sar 0: 1/1 +0, 0, 0,1, 115200, 0x0c1062d6 +0, 1, 1,1, 115200, 0x278d887e +0, 2, 2,1, 115200, 0x75e1a17b +0, 3, 3,1, 115200, 0x686b77e7 +0, 4, 4,1, 115200, 0x1fc2d693 +0, 5, 5,1, 115200, 0x2d0ba5a4
[FFmpeg-devel] [PATCH 2/2] libavfilter/vf_fps: Rewrite using activate callback
The old version of the filter had a problem where it would queue up
all of the duplicate frames required to fill a timestamp gap in a
single call to filter_frame. In problematic files - I've hit this in
webcam streams with large gaps due to network issues - this will queue
up a potentially huge number of frames. (I've seen it trigger the Linux
OOM-killer on particularly large pts gaps.)
This revised version of the filter using the activate callback will
generate at most 1 frame each time it is called, and respects output
links having the frame_wanted_out set to a negative number to indicate
that they don't want frames.
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" option, since I haven't figured out what it's supposed to
do.
---
libavfilter/vf_fps.c | 398 +--
1 file changed, 230 insertions(+), 168 deletions(-)
diff --git a/libavfilter/vf_fps.c b/libavfilter/vf_fps.c
index dbafd2c35a..16e432db0b 100644
--- a/libavfilter/vf_fps.c
+++ b/libavfilter/vf_fps.c
@@ -2,6 +2,7 @@
* Copyright 2007 Bobby Bingham
* Copyright 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"
+#include "libavutil/avassert.h"
#include "libavutil/mathematics.h"
#include "libavutil/opt.h"
-#include "libavutil/parseutils.h"
-
-#define FF_INTERNAL_FIELDS 1
-#include "framequeue.h"
#include "avfilter.h"
+#include "filters.h"
#include "internal.h"
-#include "video.h"
enum EOFAction {
EOF_ACTION_ROUND,
@@ -49,17 +45,24 @@ enum EOFAction {
typedef struct FPSContext {
const AVClass *class;
-AVFifoBuffer *fifo; ///< store frames until we get two successive
timestamps
-
-/* timestamps in input timebase */
-int64_t first_pts; ///< pts of the first frame that arrived on this
filter
-
+/* Options */
double start_time; ///< pts, in seconds, of the expected first frame
-
AVRational framerate; ///< target framerate
int rounding; ///< AVRounding method for timestamps
int eof_action; ///< action performed for last frame in FIFO
+/* Set during outlink configuration */
+int64_t start_pts; ///< pts of the expected first frame
+
+/* Runtime state */
+int status;///< buffered input status
+int64_t status_pts;///< buffered input status timestamp
+
+AVFrame *frames[2]; ///< buffered frames
+int frames_count; ///< number of buffered frames
+
+int64_t next_pts; ///< pts of the next frame to output
+
/* statistics */
int frames_in; ///< number of frames on input
int frames_out;///< number of frames on output
@@ -91,31 +94,46 @@ static av_cold int init(AVFilterContext *ctx)
{
FPSContext *s = ctx->priv;
-if (!(s->fifo = av_fifo_alloc_array(2, sizeof(AVFrame*
-return AVERROR(ENOMEM);
+/* Pass INT64_MIN/MAX through unchanged to avoid special cases for
AV_NOPTS_VALUE */
+s->rounding = s->rounding | AV_ROUND_PASS_MINMAX;
-s->first_pts= AV_NOPTS_VALUE;
+s->start_pts= AV_NOPTS_VALUE;
+s->status_pts = AV_NOPTS_VALUE;
+s->next_pts = AV_NOPTS_VALUE;
av_log(ctx, AV_LOG_VERBOSE, "fps=%d/%d\n", s->framerate.num,
s->framerate.den);
return 0;
}
-static void flush_fifo(AVFifoBuffer *fifo)
+/* Remove the first frame from the buffer, returning it */
+static AVFrame *shift_frame(FPSContext *s)
{
-while (av_fifo_size(fifo)) {
-AVFrame *tmp;
-av_fifo_generic_read(fifo, , sizeof(tmp), NULL);
-av_frame_free();
-}
+AVFrame *frame;
+
+/* Must only be called when there are frames in the buffer */
+av_assert1(s->frames_count > 0);
+
+frame = s->frames[0];
+s->frames[0] = s->frames[1];
+s->frames[1] = NULL;
+s->frames_count--;
+
+return frame;
}
static av_cold void uninit(AVFilterContext *ctx)
{
FPSContext *s = ctx->priv;
-if (s->fifo) {
-s->drop += av_fifo_size(s->fifo) / sizeof(AVFrame*);
-flush_fifo(s->fifo);
-av_fifo_freep(>fifo);
+
+AVFrame *frame;
+
+/* Free any remaining buffered frames. This only happens if a downstream
+ * filter has asked us to stop, so don't count them as dropped. */
+av_log(ctx, AV_LOG_DEBUG, "Discarding %d buffered frame(s) at exit.\n",
+s->frames_count);
+while (s->frames_count > 0) {
+frame = shift_frame(s);
+
[FFmpeg-devel] [PATCH v2] librsvgdec: Fix frame clearing code
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 paint using the CLEAR compositing operator, which fills every channel with 0 values (setting a source colour is not required). --- libavcodec/librsvgdec.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) Updated based on feedback - instead of setting a transparent paint colour, I'm just using the CLEAR operator which is hard-coded to transparent black, and might have an optimized fast path. diff --git a/libavcodec/librsvgdec.c b/libavcodec/librsvgdec.c index e57070f8e4..6697785026 100644 --- a/libavcodec/librsvgdec.c +++ b/libavcodec/librsvgdec.c @@ -82,8 +82,10 @@ static int librsvg_decode_frame(AVCodecContext *avctx, void *data, int *got_fram crender = cairo_create(image); -cairo_set_source_rgba(crender, 0.0, 0.0, 0.0, 1.0f); -cairo_paint_with_alpha(crender, 0.0f); +cairo_save(crender); +cairo_set_operator(crender, CAIRO_OPERATOR_CLEAR); +cairo_paint(crender); +cairo_restore(crender); cairo_scale(crender, dimensions.width / (double)unscaled_dimensions.width, dimensions.height / (double)unscaled_dimensions.height); ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] librsvgdec: Fix frame clearing code
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 by clearing the frame using the SOURCE blend mode, which will replace whatever is in the buffer with transparent black. Referencing the cairo FAQ, https://www.cairographics.org/FAQ/#clear_a_surface --- libavcodec/librsvgdec.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) It would probably be nice to get this into 3.4 branch as well? diff --git a/libavcodec/librsvgdec.c b/libavcodec/librsvgdec.c index e57070f8e4..e16cb6247d 100644 --- a/libavcodec/librsvgdec.c +++ b/libavcodec/librsvgdec.c @@ -82,8 +82,11 @@ static int librsvg_decode_frame(AVCodecContext *avctx, void *data, int *got_fram crender = cairo_create(image); -cairo_set_source_rgba(crender, 0.0, 0.0, 0.0, 1.0f); -cairo_paint_with_alpha(crender, 0.0f); +cairo_save(crender); +cairo_set_source_rgba(crender, 0.0, 0.0, 0.0, 0.0f); +cairo_set_operator(crender, CAIRO_OPERATOR_SOURCE); +cairo_paint(crender); +cairo_restore(crender); cairo_scale(crender, dimensions.width / (double)unscaled_dimensions.width, dimensions.height / (double)unscaled_dimensions.height); ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] Allow 'concat' filter to support inputs with different frame rates
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/fate/filter-concat-vfr | 224 > > +++ > > 3 files changed, 241 insertions(+), 2 deletions(-) > > create mode 100644 tests/ref/fate/filter-concat-vfr > > seem to fail on x86-32 > > make: *** No rule to make target `tests/data/filtergraphs/concat- > vfr', needed by `fate-filter-concat-vfr'. Stop. > make: *** Waiting for unfinished jobs Oops, I missed a 'git add' for the file with the new filter graph. I have a couple of other fixes pending (to e.g. add missing newlines to log output), so I'll resend an updated patch. Calvin. -- Calvin Walton <calvin.wal...@kepstin.ca> ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] Allow 'concat' filter to support inputs with different frame rates
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 framerate it might cause judder.
This patch checks if all of the video inputs have the same framerate, and
if not it sets the out link to use '1/0' as the frame rate, the value
meaning "unknown/vfr".
A test is added to verify the VFR behaviour. The existing test for CFR
behaviour passes unchanged.
---
libavfilter/avf_concat.c | 15 ++-
tests/fate/filter-video.mak | 4 +-
tests/ref/fate/filter-concat-vfr | 224 +++
3 files changed, 241 insertions(+), 2 deletions(-)
create mode 100644 tests/ref/fate/filter-concat-vfr
diff --git a/libavfilter/avf_concat.c b/libavfilter/avf_concat.c
index 56e4179..2258663 100644
--- a/libavfilter/avf_concat.c
+++ b/libavfilter/avf_concat.c
@@ -133,8 +133,21 @@ static int config_output(AVFilterLink *outlink)
outlink->h = inlink->h;
outlink->sample_aspect_ratio = inlink->sample_aspect_ratio;
outlink->format = inlink->format;
+outlink->frame_rate = inlink->frame_rate;
+
+for (seg = 1; seg < cat->nb_segments; seg++) {
+inlink = ctx->inputs[in_no + seg * ctx->nb_outputs];
+if (outlink->frame_rate.num != inlink->frame_rate.num ||
+outlink->frame_rate.den != outlink->frame_rate.den) {
+av_log(ctx, AV_LOG_VERBOSE,
+"Video inputs have different frame rates, output will be
VFR");
+outlink->frame_rate = av_make_q(1, 0);
+break;
+}
+}
+
for (seg = 1; seg < cat->nb_segments; seg++) {
-inlink = ctx->inputs[in_no += ctx->nb_outputs];
+inlink = ctx->inputs[in_no + seg * ctx->nb_outputs];
if (!outlink->sample_aspect_ratio.num)
outlink->sample_aspect_ratio = inlink->sample_aspect_ratio;
/* possible enhancement: unsafe mode, do not check */
diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index c57c9c7..5a814e2 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -358,9 +358,11 @@ FATE_FILTER_SAMPLES-$(call ALLYES, VMD_DEMUXER
VMDVIDEO_DECODER FORMAT_FILTER PE
fate-filter-gradfun-sample: tests/data/filtergraphs/gradfun
fate-filter-gradfun-sample: CMD = framecrc -i $(TARGET_SAMPLES)/vmd/12.vmd
-filter_script $(TARGET_PATH)/tests/data/filtergraphs/gradfun -an -frames:v 20
-FATE_FILTER-$(call ALLYES, TESTSRC_FILTER SINE_FILTER CONCAT_FILTER) +=
fate-filter-concat
+FATE_FILTER-$(call ALLYES, TESTSRC_FILTER SINE_FILTER CONCAT_FILTER) +=
fate-filter-concat fate-filter-concat-vfr
fate-filter-concat: tests/data/filtergraphs/concat
fate-filter-concat: CMD = framecrc -filter_complex_script
$(TARGET_PATH)/tests/data/filtergraphs/concat
+fate-filter-concat-vfr: tests/data/filtergraphs/concat-vfr
+fate-filter-concat-vfr: CMD = framecrc -filter_complex_script
$(TARGET_PATH)/tests/data/filtergraphs/concat-vfr
FATE_FILTER-$(call ALLYES, TESTSRC2_FILTER FPS_FILTER MPDECIMATE_FILTER) +=
fate-filter-mpdecimate
fate-filter-mpdecimate: CMD = framecrc -lavfi
testsrc2=r=2:d=10,fps=3,mpdecimate -r 3 -pix_fmt yuv420p
diff --git a/tests/ref/fate/filter-concat-vfr b/tests/ref/fate/filter-concat-vfr
new file mode 100644
index 000..0dece67
--- /dev/null
+++ b/tests/ref/fate/filter-concat-vfr
@@ -0,0 +1,224 @@
+#tb 0: 1/100
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 320x240
+#sar 0: 1/1
+#tb 1: 1/44100
+#media_type 1: audio
+#codec_id 1: pcm_s16le
+#sample_rate 1: 44100
+#channel_layout 1: 4
+#channel_layout_name 1: mono
+0, 0, 0,0, 230400, 0x88c4d19a
+1, 0, 0, 1024, 2048, 0xb3f10192
+1, 1024, 1024, 1024, 2048, 0xb340fe4e
+1, 2048, 2048, 1024, 2048, 0x0a5f0111
+1, 3072, 3072, 1024, 2048, 0x51be06b8
+1, 4096, 4096, 1024, 2048, 0x71a1ffcb
+1, 5120, 5120, 1024, 2048, 0x7f64f50f
+1, 6144, 6144, 1024, 2048, 0x70a8fa17
+1, 7168, 7168, 1024, 2048, 0x0dad072a
+1, 8192, 8192, 1024, 2048, 0x5e810c51
+0, 20, 20,0, 230400, 0x0d77c977
+1, 9216, 9216, 1024, 2048, 0xbe5bf462
+1, 10240, 10240, 1024, 2048, 0xbcd9faeb
+1, 11264, 11264, 1024, 2048, 0x0d5bfe9c
+1, 12288, 12288, 1024, 2048, 0x97d80297
+1, 13312, 13312, 1024, 2048, 0xba0f0894
+1, 14336, 14336, 1024, 2048, 0xcc22f291
+1, 15360, 15360, 1024, 2048, 0x11a9fa03
+1, 16384, 16384, 1024, 2048, 0x9a920378
+1, 17408, 17408, 1024, 2048, 0x901b0525
Re: [FFmpeg-devel] [PATCH] Allow 'concat' filter to support inputs with different frame rates
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 different frame rates, would it be > > better to use the '1/0' value, or should it attempt to calculate a > > common framerate that's a multiple of all inputs? (e.g. for 24fps and > > 30fps inputs, it could pick 120fps). > > > > There's already a TODO listed in the filter code about determining a > > common timebase rather than using AV_TIME_BASE - if I'm doing the work > > to find a common framerate, I could probably do this at the same time. > > If the inputs have different frame rates, then concat will be outputting > variable frame rate, not constant with a common divisor. Therefore 1/0 > is better I think. > > OTOH, printing a message when this happens would probably be useful, and > in that case, printing the common possible frame rate would be nice. But > is is not urgent. On Wed, 2017-03-08 at 20:26 +0100, wm4 wrote: > I really think if there's no common framerate, it should not pretend > there is one. Thus setting 1/0 doesn't seem too bad. Thanks for the feedback Nicolas & wm4. I'll take a look at doing this in a v2 later this evening. Calvin -- Calvin Walton <calvin.wal...@kepstin.ca> ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Allow 'concat' filter to support inputs with different frame rates
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. > > > > The simplest fix is to just set the out links to have '1/0' as the frame > > rate, the value meaning "unknown/vfr". Note that this changes the > > I do not think that setting it to 1/0 is the correct fix for this issue. > Unless I am mistaken, the frame rate is available on all inputs when the > corresponding code is called: I think the correct fix would be to check > if all inputs have the same. 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 different frame rates, would it be better to use the '1/0' value, or should it attempt to calculate a common framerate that's a multiple of all inputs? (e.g. for 24fps and 30fps inputs, it could pick 120fps). There's already a TODO listed in the filter code about determining a common timebase rather than using AV_TIME_BASE - if I'm doing the work to find a common framerate, I could probably do this at the same time. Calvin. -- Calvin Walton <calvin.wal...@kepstin.ca> ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Allow 'concat' filter to support inputs with different frame rates
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 framerate it might cause judder.
The simplest fix is to just set the out links to have '1/0' as the frame
rate, the value meaning "unknown/vfr". Note that this changes the filter
chain to use AV_TB on the output rather than converting the timebase to
match the listed framerate.
A test is added to verify the VFR behaviour. The change of output timebase
means the existing concat test needs to be updated with new pts values.
---
libavfilter/avf_concat.c | 1 +
tests/fate/filter-video.mak | 4 +-
tests/ref/fate/filter-concat | 42
tests/ref/fate/filter-concat-vfr | 224 +++
4 files changed, 249 insertions(+), 22 deletions(-)
create mode 100644 tests/ref/fate/filter-concat-vfr
diff --git a/libavfilter/avf_concat.c b/libavfilter/avf_concat.c
index 56e4179..a7967a2 100644
--- a/libavfilter/avf_concat.c
+++ b/libavfilter/avf_concat.c
@@ -133,6 +133,7 @@ static int config_output(AVFilterLink *outlink)
outlink->h = inlink->h;
outlink->sample_aspect_ratio = inlink->sample_aspect_ratio;
outlink->format = inlink->format;
+outlink->frame_rate = av_make_q(1, 0);
for (seg = 1; seg < cat->nb_segments; seg++) {
inlink = ctx->inputs[in_no += ctx->nb_outputs];
if (!outlink->sample_aspect_ratio.num)
diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index c57c9c7..5a814e2 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -358,9 +358,11 @@ FATE_FILTER_SAMPLES-$(call ALLYES, VMD_DEMUXER
VMDVIDEO_DECODER FORMAT_FILTER PE
fate-filter-gradfun-sample: tests/data/filtergraphs/gradfun
fate-filter-gradfun-sample: CMD = framecrc -i $(TARGET_SAMPLES)/vmd/12.vmd
-filter_script $(TARGET_PATH)/tests/data/filtergraphs/gradfun -an -frames:v 20
-FATE_FILTER-$(call ALLYES, TESTSRC_FILTER SINE_FILTER CONCAT_FILTER) +=
fate-filter-concat
+FATE_FILTER-$(call ALLYES, TESTSRC_FILTER SINE_FILTER CONCAT_FILTER) +=
fate-filter-concat fate-filter-concat-vfr
fate-filter-concat: tests/data/filtergraphs/concat
fate-filter-concat: CMD = framecrc -filter_complex_script
$(TARGET_PATH)/tests/data/filtergraphs/concat
+fate-filter-concat-vfr: tests/data/filtergraphs/concat-vfr
+fate-filter-concat-vfr: CMD = framecrc -filter_complex_script
$(TARGET_PATH)/tests/data/filtergraphs/concat-vfr
FATE_FILTER-$(call ALLYES, TESTSRC2_FILTER FPS_FILTER MPDECIMATE_FILTER) +=
fate-filter-mpdecimate
fate-filter-mpdecimate: CMD = framecrc -lavfi
testsrc2=r=2:d=10,fps=3,mpdecimate -r 3 -pix_fmt yuv420p
diff --git a/tests/ref/fate/filter-concat b/tests/ref/fate/filter-concat
index 022697e..101be47 100644
--- a/tests/ref/fate/filter-concat
+++ b/tests/ref/fate/filter-concat
@@ -1,4 +1,4 @@
-#tb 0: 1/5
+#tb 0: 1/100
#media_type 0: video
#codec_id 0: rawvideo
#dimensions 0: 320x240
@@ -9,7 +9,7 @@
#sample_rate 1: 44100
#channel_layout 1: 4
#channel_layout_name 1: mono
-0, 0, 0,1, 230400, 0x88c4d19a
+0, 0, 0,0, 230400, 0x88c4d19a
1, 0, 0, 1024, 2048, 0xb3f10192
1, 1024, 1024, 1024, 2048, 0xb340fe4e
1, 2048, 2048, 1024, 2048, 0x0a5f0111
@@ -19,7 +19,7 @@
1, 6144, 6144, 1024, 2048, 0x70a8fa17
1, 7168, 7168, 1024, 2048, 0x0dad072a
1, 8192, 8192, 1024, 2048, 0x5e810c51
-0, 1, 1,1, 230400, 0x0d77c977
+0, 20, 20,0, 230400, 0x0d77c977
1, 9216, 9216, 1024, 2048, 0xbe5bf462
1, 10240, 10240, 1024, 2048, 0xbcd9faeb
1, 11264, 11264, 1024, 2048, 0x0d5bfe9c
@@ -29,7 +29,7 @@
1, 15360, 15360, 1024, 2048, 0x11a9fa03
1, 16384, 16384, 1024, 2048, 0x9a920378
1, 17408, 17408, 1024, 2048, 0x901b0525
-0, 2, 2,1, 230400, 0x242629d7
+0, 40, 40,0, 230400, 0x242629d7
1, 18432, 18432, 1024, 2048, 0x74b2003f
1, 19456, 19456, 1024, 2048, 0xa20ef3ed
1, 20480, 20480, 1024, 2048, 0x44cef9de
@@ -38,7 +38,7 @@
1, 23552, 23552, 1024, 2048, 0xcab6f9e5
1, 24576, 24576, 1024, 2048, 0x67f8f608
1, 25600, 25600, 1024, 2048, 0x8d7f03fa
-0, 3, 3,1, 230400, 0x62cdc018
+0, 60, 60,0, 230400, 0x62cdc018
1, 26624, 26624, 1024, 2048, 0x3e1e0566
1, 27648, 27648, 1024, 2048, 0x2cfe0308
1, 28672,
Re: [FFmpeg-devel] [PATCH] avfilter: add midequalizer filter
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 effect using two video streams.
> +
> +This filter accepts the following option:
> +
> +@table @option
> +@item planes
> +Set which planes to process. Default is @code{15}, which is all
> available planes.
> +@end table
>
Speaking as a user, it would be great if you can include some
information in the docs about what this filter does, or why someone
would want to use it. Something as simple as:
"Midway Image Equalization adjusts a pair of images to have the same
histogram, while maintaining their dynamics as much as possible. It's
useful for e.g. matching exposures from a pair of stereo cameras"
would help here.
Some help on how to actually use it (maybe with an example) would be
great too. For example, if the filter works by having a reference input
and an input which gets modified, it would also be good to say which
input is which. Something along the lines of:
"This input has two inputs and two outputs. The first input is used as
a reference, it is passed through unchanged. The second input has its
contrast adjusted to match that of the first input and the result is
returned on the second output."
but of course adjusted to match what the code actually does!
I don't have any comments on the code itself.
Calvin.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add space after commas in HTTP/RTSP auth header
On Thu, 2015-10-01 at 13:56 +0300, Andrey Utkin wrote: > This fixes access to Grandstream cameras, which return 401 to ffmpeg > otherwise. > VLC sends Authorization: header with spaces between parameters, and > it > is known to work with Grandstream devices and broad range of other > HTTP > and RTSP servers, so author considers switching to such behaviour > safe. > Just for record - RFC 2617 (HTTP Auth) does not specify the need in > spaces, so this is not a bug of FFmpeg. For those curious about the updated versions of the HTTP/1.1 specs, the current HTTP Auth RFC 7235 uses the # (list) ABNF from RFC 7230 section 7, which specifies the separator as "," surrounded by OWS (optional whitespace). Section 3.2.3 says: The OWS rule is used where zero or more linear whitespace octets might appear. For protocol elements where optional whitespace is preferred to improve readability, a sender SHOULD generate the optional whitespace as a single SP; otherwise, a sender SHOULD NOT generate optional whitespace except as needed to white out invalid or unwanted protocol elements during in-place message filtering. So in this case, 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 idea regardless. -- Calvin Walton <calvin.wal...@kepstin.ca> ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] some thoughts on the website and warnings
On Sat, 2015-09-19 at 12:36 -0400, Ganesh Ajjanagadde wrote: > Regarding the large array of platforms, as can be seen from the > patches I have submitted over the past few weeks, one long term goal > I > have is getting to a "nearly -Werror" state at least on the most > recent clang/gcc. Already notice that most warnings are from older > compilers, non clang/gcc, windows, etc, which in many cases give us > nothing (since newer ones anyway warn for the good ones). > Nevertheless, these are occasionally useful. > > Latest clang/gcc are on the order of 100 warnings, and I think with > some more work, this can be brought down to 10 (for the most annoying > ones). If this happens, it should help us in treating warnings on > latest clang/gcc more seriously than before. Among these two, I have > been far more impressed with clang than gcc. > > This might stir the flames, but who knows: maybe in a year we can > seriously consider -Werror for a certain set of "core platforms" > (which can be voted upon; recall the leadership committee etc). By a > "platform" I mean a complete environment: set of configure flags, > compiler flags, compiler versions, etc. As someone who has done some distro packaging and occasionally tries to get old packages compiling on newer systems, I just have a note to this: Please never enable "-Werror" by default in a release version of a package - where that'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't seen on the developer's system. Thanks. -- Calvin Walton <calvin.wal...@kepstin.ca> ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] WAV demuxer: Document the ignore_length option.
---
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
understand:
ffmpeg -i http://www.ted.com/talks/subtitles/id/1/lang/en talk1-en.srt
@end example
+@section wav
+
+WAV demuxer.
+
+This demuxer accepts the following option:
+@table @option
+
+@item ignore_length
+Ignore the length field in the WAV file header.
+
+Some tools, when generating extremely long or streaming WAV files, may set the
+length field to an incorrect or invalid value.
+
+If you set the @option{ignore_length} option to 1, FFmpeg will ignore the
+length field in the WAV header, and treat all of the data in the file after
+the header as a continuous stream of audio data. If the file contains non-audio
+data after the audio (e.g. ID3 tags), it will be treated as audio data and
+cause audible artifacts or decoding errors.
+
+The default, 0, respects the length field.
+
+@end table
+
@c man end DEMUXERS
--
2.5.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [RFC] Exporting the alpha mode from decoders
On Fri, 2015-02-06 at 13:51 +, Vittorio Giovara wrote: On Fri, Feb 6, 2015 at 11:32 AM, wm4 nfx...@googlemail.com wrote: This is a proposal for an API extension. Currently, some pixel formats support alpha, but whether the alpha component contains something useful or just garbage is not part of the pixel format definition. This applies at least to packed RGB formats, where the 4th component is either alpha or garbage depending on the context. One possible solution is duplicating all these pixel formats, so you'd have e.g. AV_PIX_FMT_RGBA and AV_PIX_FMT_RGBX. But I think we all agree that we don't want more pixel formats. The other solution, which I want to advocate here, is adding a field to AVFrame that indicates the alpha mode. Something like: The problem looks interesting. I am not sure samples with premultiplied alpha exist (or what swscale does in that case). Another approach could be to expand avframe-flag, in order to signal when alpha channel contains garbage, rather than introducing a new field. The premultiplied alpha case is probably pretty rare, but I can think of one particular time it might come up - If you are writing an application that uses cairo to draw image frames via an Image Surface, and want to encode them to a video with ffmpeg. The pixel format used in the cairo 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, premultiplied alpha. -- Calvin Walton calvin.wal...@kepstin.ca ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFMPEG : Redirecting Matroska muxed data to socket
On Wed, 2014-10-29 at 11:26 +0530, Parth Shah wrote: Hi all, I am using FFMPEG library to mux H.264 and AAC frames to Matroska (.mkv) file. I can do that both using command line and C program. Now, instead of writing the muxed matroska data into file I want to write these muxed data directly on to socket or pipe. My actual goal is to write a C program that send muxed data to socket and server will receive this muxed data. I tried using protocol tcp. They are working with the matroska format. So, My C program is able to send muxed data successfully over socket and server is able to receive this muxed data. But when I apply ffprobe command over the received file, I am getting duration and bitrate field N/A. and when I tried to play this file with vlc i am unable to seek the file and getting garbage duration. When ffmpeg writes matroska directly to a file, it writes all of the data for the media streams out, then seeks back to the start of the file to fill in the duration field. But you're sending the matroska over a tcp stream - effectively a live stream. As a result, ffmpeg can't go back and update these fields once the file is completely written; so they're left unset. This isn't normally a problem - it means that players will not show the correct duration while playing the file, but seeking should still work (and does in e.g. 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 calvin.wal...@kepstin.ca ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Mention in the documentation that fieldmatch needs cfr input
On Sat, 2014-10-25 at 12:22 +, Carl Eugen Hoyos wrote:
Clément Bœsch u at pkh.me writes:
+The filter only works for constant frame rate input. If your
input
+has mixed telecined and progressive content with changing
framerate,
+try the at ref{pullup} filter.
Well I don't mind much but then... how is pullup making
any difference here actually
Just to sum it up:
pullup works fine and is fast for all samples I have seen,
it definitely misses many merging opportunities if the
horizontal motion is very low (meaning some frames with
artefacts remain for every real-world input).
fieldmatch is very slow, it is apparently able to
produce perfect output for badly cut input with constant
(telecined) framerate but it fails completely for mixed
content (as found on many DVD's).
Imo, fps=3/1001,fieldmatch,decimate should fix this
but decimate unfortunately does not drop the frame that
fps inserted but a random (?) frame.
(Or fieldmatch finds matches in progressive input?)
For content that was in mpeg2 with field flags set appropriate for
display on an interlaced TV - which basically accounts for all DVD
content - mplayer had a 'softpulldown' filter that used these flags to
turn the video stream from mixed progressive+telecined+interlaced
content with variable framerate (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 calvin.wal...@kepstin.ca
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] Don't use CMOV in MMX code
On Fri, 2014-09-12 at 14:53 -0700, Daniel Kang wrote: All processors supporing mmx2 also support cmov, so if a test for mmx2 succeeds, we can use cmov. Since I originally thought mmx = cmov (and apparently am wrong) is there official documentation supporting this? As an example, here's the /proc/cpuinfo contents for my AMD K6 box. You'll note that on the flags line it does have 'mmx', but does not have 'cmov'. (It also doesn't have 3dnow; that was introduced in later chips in the K6 series.) I'm actually looking into getting FATE running on this box right now, we'll see how that goes. processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 7 model name : AMD-K6tm w/ multimedia extensions stepping: 0 cpu MHz : 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 address sizes : 32 bits physical, 32 bits virtual power management: -- Calvin Walton calvin.wal...@kepstin.ca ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
