[FFmpeg-devel] [PATCH] avcodec/h2645_sei: allow building h2645_sei without
Hello, This is my first time sending a patch here, please let me know if I got the process wrong. I was building a minimal libav for WebAssembly with Emscripten, with only H264 and AAC. It fails unless I also enable other configs that would increase code size. Seems like someone forgot to guard a call with a config macro. This patch adds it, just like the other occurrences in this same file. Everything works fine after that. Thanks! 0001-avcodec-h2645_sei-allow-building-h2645_sei-without-C.patch Description: Binary data ___ ffmpeg-devel mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
Re: [FFmpeg-devel] [Patch] Linker error for __ff_aom_uninit_film_grain_params
Hello, I've sent a different patch fixing this same issue at "[FFmpeg-devel] [PATCH] avcodec/h2645_sei: allow building h2645_sei without". Instead of adding an extra file to the build, it seems that a ifdef config was missing. There are other calls to ff_aom that are guarded by a similar ifdef in the same file. > On 12 May 2025, at 08:49, Sebastian Koerner > wrote: > > Correction: Sorry, the log is from arm64, but the text says x86. It happens > to many non-linux platforms. > > Also note that Hunk #1 of the patch is obviously junk. > Should be just the one dependency to aom_film_grain.o > > --- ffmpeg-7.1.1/libavcodec/Makefile.org2025-05-12 11:48:13.0 > +0200 > +++ ffmpeg-7.1.1/libavcodec/Makefile2025-05-12 11:48:58.0 +0200 > @@ -108,7 +108,7 @@ > h2645data.o h2645_parse.o > h2645_vui.o > OBJS-$(CONFIG_H264PRED)+= h264pred.o > OBJS-$(CONFIG_H264QPEL)+= h264qpel.o > -OBJS-$(CONFIG_H264_SEI)+= h264_sei.o h2645_sei.o > +OBJS-$(CONFIG_H264_SEI)+= h264_sei.o h2645_sei.o > aom_film_grain.o > OBJS-$(CONFIG_HEVCPARSE) += h2645data.o h2645_parse.o > h2645_vui.o > OBJS-$(CONFIG_HEVC_SEI)+= h2645_sei.o aom_film_grain.o \ > dynamic_hdr_vivid.o > > > > From: ffmpeg-devel on behalf of Sebastian > Koerner > Sent: Monday, May 12, 2025 1:41 PM > To: [email protected] > Subject: [FFmpeg-devel] [Patch] Linker error for > __ff_aom_uninit_film_grain_params > > Summary of the bug: > > When building ffmpeg 7.1.1 from source on macosx x86-64 and selecting only > h264 one can observe a linker error around __ff_aop_uninit_film_grain_params > > > Undefined symbols for architecture arm64: > "_ff_aom_uninit_film_grain_params", referenced from: > _ff_h2645_sei_reset in h2645_sei.o > ld: symbol(s) not found for architecture arm64 > > How to reproduce: > > configure ffmpeg 7.1.1 for H.264 only, like > > --enable-shared --disable-static --disable-programs --disable-doc > --disable-everything --enable-decoder=h264 --enable-parser=h264 > --disable-bzlib --disable-iconv --disable-lzma --disable-xlib --disable-zlib > --disable-libxcb --disable-vaapi > > > Patch > > --- ffmpeg-7.1.1/libavcodec/Makefile.org2025-05-12 11:48:13.0 > +0200 > +++ ffmpeg-7.1.1/libavcodec/Makefile2025-05-12 11:48:58.0 +0200 > @@ -1,5 +1,5 @@ > NAME = avcodec > -DESC = FFmpeg codec library > +DESC = FFmpeg codec libriary > > HEADERS = ac3_parser.h \ > adts_parser.h \ > @@ -108,7 +108,7 @@ > h2645data.o h2645_parse.o > h2645_vui.o > OBJS-$(CONFIG_H264PRED)+= h264pred.o > OBJS-$(CONFIG_H264QPEL)+= h264qpel.o > -OBJS-$(CONFIG_H264_SEI)+= h264_sei.o h2645_sei.o > +OBJS-$(CONFIG_H264_SEI)+= h264_sei.o h2645_sei.o > aom_film_grain.o > OBJS-$(CONFIG_HEVCPARSE) += h2645data.o h2645_parse.o > h2645_vui.o > OBJS-$(CONFIG_HEVC_SEI)+= h2645_sei.o aom_film_grain.o \ > dynamic_hdr_vivid.o > ___ > ffmpeg-devel mailing list > [email protected] > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > [email protected] with subject "unsubscribe". > ___ > ffmpeg-devel mailing list > [email protected] > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > [email protected] with subject "unsubscribe". ___ ffmpeg-devel mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
[FFmpeg-devel] LibRaw inclusion request
LibRaw is a library for reading RAW files obtained from digital photo cameras (CRW/CR2, NEF, RAF, DNG, and others) libraw inclusion in ffmpeg would allow time laps video to be made directly from the RAW output of the following cameras and also from cameras that produce RAW video frames: http://www.libraw.org LibRaw 0.16-Release changes (since 0.15.x): Support for new cameras: Baumer TXG14 Blackmagic Cinema Canon EOS 70D, C500, S120, G16 Fujifilm X-M1, X-A1, XE2, XQ1 Hasselblad Lunar, Stellar Leica C, X VARIO Nikon D5200, P7800, D5300, D610, Df, 1 AW1 Nokia Lumia 1020, 1520 Olympus E-P5,E-M1, STYLUS1 OmniVision OV5647 (Raspberry Pi) Panasonic LF1, GX7, GF6, GM1 Pentax K-50, K-500, Q7,K-3 Richon GR Samsung NX300, NX1100, NX2000, Galaxy NX (EK-GN120) ___ ffmpeg-devel mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: remove the mixed declarations and code warning flag
On 16-02-04 at 15:48, Rostislav Pehlivanov wrote:
[..]
> This will essentially help bring the project to near 21st century age
> and finally allow for developers to save on line numbers by NOT having
> to define the variable around which a for loop needs to iterate (e.g.
> have for (int i = 0; i < N; i++) loops instead of having to define 'i'
> at the start of the function like a normal variable), as well as more of
> the syntactic sugar C99 permits.
Just being pedantic, but -Wdeclaration-after-statement does not warn on
any of those, see attached test file which compiles without errors with
-Wall -Wpedantic -Werror -Wdeclaration-after-statement (at least on
modern clang and gcc). No comment on the actual change.
--
Simon Thelen
int main()
{
int a = 0;
for (int i = 0; i < 10; i++) {
int j = 5;
a += j + i;
}
if (a != 0) {
int b = 5;
b--;
}
return 0;
}
___
ffmpeg-devel mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Complete rewrite of the "fps" video filter section. More accurate.
From: Jim DeLaHunt
This is a complete rewrite of the documentation for the "fps" video
filter. It describes the filter's behaviour more clearly and accurately.
I based the rewrite on reading the source code in vf_fps.c closely.
No code, or other documentation files, are touched by this change.
Signed-off-by: Jim DeLaHunt
---
doc/filters.texi | 167 ++-
1 file changed, 149 insertions(+), 18 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 71a6787289..bd4a1ad2a9 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -11139,27 +11139,34 @@ format=pix_fmts=yuv420p|yuv444p|yuv410p
@anchor{fps}
@section fps
-Convert the video to specified constant frame rate by duplicating or dropping
-frames as necessary.
+Generate a video, having the specified constant frame rate, from the frames of
+the input video, by copying or duplicating or dropping input frames based on
+their input presentation time stamps (PTSs). The output video has new PTSs.
You
+can choose the method for rounding from input PTS to output PTS.
It accepts the following parameters:
@table @option
@item fps
-The desired output frame rate. The default is @code{25}.
+The output frame rate, as a number of frames per second. This value can be an
+integer, real, or rational number, or an abbreviation. The default is
@code{25}.
@item start_time
-Assume the first PTS should be the given value, in seconds. This allows for
-padding/trimming at the start of stream. By default, no assumption is made
-about the first frame's expected PTS, so no padding or trimming is done.
-For example, this could be set to 0 to pad the beginning with duplicates of
-the first frame if a video stream starts after the audio stream or to trim any
-frames with a negative PTS.
+The time, in seconds from the start of the input stream, which is converted to
+an input starting PTS value and an output starting PTS value.
+If set, @var{fps} drops input frames
+which have PTS values less than the input starting PTS. If not set, the input
+and output starting PTS values are zero, but @var{fps} drops no input frames
based
+on PTS.
+(See details below.)
@item round
-Timestamp (PTS) rounding method.
+Rounding method to use when calculating output Presentation Timestamp
+(PTS) integer values from input PTS values. If the calculated output PTS value
+is not exactly an integer, then the method determines which of the two
+neighbouring integer values to choose.
-Possible values are:
+Possible method names are:
@table @option
@item zero
round towards 0
@@ -11170,43 +11177,167 @@ round towards -infinity
@item up
round towards +infinity
@item near
-round to nearest
+round to nearest (and if exactly at midpoint, away from 0)
@end table
The default is @code{near}.
@item eof_action
-Action performed when reading the last frame.
+Action which @var{fps} takes with the final input frame. The input video passes
+in an ending input PTS, which @var{fps} converts to an ending output PTS.
+@var{fps} drops any input frames with a PTS at or after this ending PTS.
Possible values are:
@table @option
@item round
-Use same timestamp rounding method as used for other frames.
+Use same rounding method as for other frames, to convert the ending input PTS
+to output PTS.
+
@item pass
-Pass through last frame if input duration has not been reached yet.
+Round the ending input PTS using @code{up}. This can have the effect of passing
+through one last input frame.
@end table
+
The default is @code{round}.
@end table
-Alternatively, the options can be specified as a flat string:
+Alternatively, the options may be specified as a flat string:
@var{fps}[:@var{start_time}[:@var{round}]].
+@var{fps} generates an output video with integer Presentation Time Stamp (PTS)
+values which increment by one each output frame, and with a time base set to
+the inverse of the given frame rate. @var{fps} copies, duplicates, or drops
+input frames, in sequence, to the output video. It does so according to their
+input PTS values, as converted to seconds (via the input time base), then
+rounded to output PTS values.
+
+@var{fps} sets output PTS values in terms of a time line which starts at
+zero. The integer PTS value multipled by the output time base gives a point
+in seconds of that output frame on that timeline. If the @var{start_time}
+parameter is not set, or is zero, the first output frame's PTS value is zero.
+Otherwise, the first PTS value is the output starting PTS value calculated
+from the @var{start_time} parameter.
+
+@var{fps} interprets input PTS values in terms of the same time line. It
+multiplies the input PTS value by the input time base time, to get a frame
+position in seconds on the time line. It rounds that position to an integer
+output PTS value. For example, if the input video has a frame rate
+of 30 fps, a time base of 1/30 seconds, and its first frame has a
+PTS of 300, the
[FFmpeg-devel] [PATCH v2] doc/filters.texi: complete rewrite of fps filter doc, v2.
Thank you for the review. Here is a rewrite of the improvement to the fps filter documentation, based on those comments. Thought it was too wordy before? It now has 11% fewer words. To confirm, no other documentation and no code are affected by this patch. Comments? —Jim DeLaHunt, software engineer, Vancouver, Canada ___ ffmpeg-devel mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] doc/filters.texi: complete rewrite of fps filter doc, v2.
From: Jim DeLaHunt
Fix unclear wording and spelling mistakes based on review.
Reduce overall word count by 11%. Ready for patch review.
No other docs, and no executable code, are changed.
Signed-off-by: Jim DeLaHunt
---
doc/filters.texi | 157 +--
1 file changed, 138 insertions(+), 19 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index d19fd346ae..0d7d15c448 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -11194,25 +11194,30 @@ format=pix_fmts=yuv420p|yuv444p|yuv410p
@anchor{fps}
@section fps
-Convert the video to specified constant frame rate by duplicating or dropping
-frames as necessary.
+Make a new video from the frames and presentation time stamps (PTSs) of the
+input. The new video has a specified constant frame rate, and new PTSs. It
+generally keeps frames from the old video, but might repeat or drop some
frames.
+You can choose the method for rounding from input PTS to output PTS. This
+affects which frames @var{fps} keeps, repeats, or drops.
It accepts the following parameters:
@table @option
@item fps
-The desired output frame rate. The default is @code{25}.
+The output frame rate, in frames per second. May be an integer, real, or
+rational number, or an abbreviation. The default is @code{25}.
@item start_time
-Assume the first PTS should be the given value, in seconds. This allows for
-padding/trimming at the start of stream. By default, no assumption is made
-about the first frame's expected PTS, so no padding or trimming is done.
-For example, this could be set to 0 to pad the beginning with duplicates of
-the first frame if a video stream starts after the audio stream or to trim any
-frames with a negative PTS.
+A time, in seconds from the start of the input stream, which @var{fps}
converts
+to an input starting PTS and an output starting PTS. If set,
+@var{fps} drops input frames which have PTSs less than the input starting
+PTS. If not set, the input and output starting PTSs are zero, but
+@var{fps} drops no input frames based on PTS. (See details below.)
@item round
-Timestamp (PTS) rounding method.
+Rounding method to use when calculating output PTSs from input PTSs.
+If the calculated output PTS is not exactly an integer, then the value
+determines which neighbouring integer value @var{fps} selects.
Possible values are:
@table @option
@@ -11225,43 +11230,157 @@ round towards -infinity
@item up
round towards +infinity
@item near
-round to nearest
+round to nearest (midpoints round away from 0)
@end table
The default is @code{near}.
@item eof_action
-Action performed when reading the last frame.
+Action which @var{fps} takes with the final input frame. The input video passes
+in a final input PTS, which @var{fps} converts to an output PTS limit.
+@var{fps} drops any input frames with a PTS at or after this limit.
Possible values are:
@table @option
@item round
-Use same timestamp rounding method as used for other frames.
+Use same rounding method as for other frames.
+
@item pass
-Pass through last frame if input duration has not been reached yet.
+Round the ending input PTS using @code{up}. This might make @ref{fps} include
+one last input frame.
@end table
+
The default is @code{round}.
@end table
-Alternatively, the options can be specified as a flat string:
+Alternatively, the options may be specified as a flat string:
@var{fps}[:@var{start_time}[:@var{round}]].
-See also the @ref{setpts} filter.
+@var{fps} makes an output video with consecutive integer PTSs, and with a
+time base set to the inverse of the given frame rate. @var{fps} keeps,
repeats,
+or drops input frames, in sequence, to the output video. It does so according
+to their input PTSs, as converted to seconds (via the input time base),
+then rounded to output PTSs.
+
+@var{fps} sets output PTSs in terms of a timeline which starts at
+zero. For any output frame, the integer PTS multiplied by the time base
+gives a value in seconds on that timeline. If the @var{start_time}
+parameter is not set, or is zero, the first output frame's PTS is zero.
+Otherwise, the first PTS is the output starting PTS calculated
+from the @var{start_time} parameter.
+
+@var{fps} interprets input PTSs in terms of the same timeline. It
+multiplies each input frame's PTS by the input time base, to get a value
+in seconds on the timeline. It rounds that value to an integer output PTS.
+For example, if the input video has a frame rate of 30 fps, a time base
+of 1/30 seconds, and a first frame with a PTS of 300, then @var{fps} treats
that
+first frame as occurring 10 seconds (= 300 * 1/30) after the start of the
video,
+even though it is the first frame.
+
+Setting a @code{start_time} value allows for padding/trimming at the
+start of the input. For example, you can set @code{start_time} to 0, to pad
the
+beginning with repeats of the first frame if a video stream starts after
+the audio stream,
