[FFmpeg-devel] [PATCH] avformat/utils: fix seek failed
Rounding min_ts towards +infinity and max_ts towards -infinity can make ts out of the [min_ts, max_ts] range, and then leads to seek failure. For example, max_ts = ts = -25057 time_base = (num = 1, den = 14112000) After rescale, ts = -353604, and max_ts = -353605. --- libavformat/utils.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavformat/utils.c b/libavformat/utils.c index 503e583ad0..69a0f901b2 100644 --- a/libavformat/utils.c +++ b/libavformat/utils.c @@ -2500,10 +2500,10 @@ int avformat_seek_file(AVFormatContext *s, int stream_index, int64_t min_ts, ts = av_rescale_q(ts, AV_TIME_BASE_Q, time_base); min_ts = av_rescale_rnd(min_ts, time_base.den, time_base.num * (int64_t)AV_TIME_BASE, -AV_ROUND_UP | AV_ROUND_PASS_MINMAX); +AV_ROUND_DOWN | AV_ROUND_PASS_MINMAX); max_ts = av_rescale_rnd(max_ts, time_base.den, time_base.num * (int64_t)AV_TIME_BASE, -AV_ROUND_DOWN | AV_ROUND_PASS_MINMAX); +AV_ROUND_UP | AV_ROUND_PASS_MINMAX); stream_index = 0; } -- 2.28.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".
Re: [FFmpeg-devel] [PATCH] avformat/utils: fix seek failed
On Thu, 31 Dec 2020, Zhao Zhili wrote: Rounding min_ts towards +infinity and max_ts towards -infinity can make ts out of the [min_ts, max_ts] range, and then leads to seek failure. For example, I think this is intentional to adhere to the docs of the function: "Seeking will be done so that the point from which all active streams can be presented successfully will be closest to ts and within min/max_ts." If you round down min_ts, you might return a packet with a timestamp less than the original min_ts, which contradicts the documentation. Regards, Marton max_ts = ts = -25057 time_base = (num = 1, den = 14112000) After rescale, ts = -353604, and max_ts = -353605. --- libavformat/utils.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavformat/utils.c b/libavformat/utils.c index 503e583ad0..69a0f901b2 100644 --- a/libavformat/utils.c +++ b/libavformat/utils.c @@ -2500,10 +2500,10 @@ int avformat_seek_file(AVFormatContext *s, int stream_index, int64_t min_ts, ts = av_rescale_q(ts, AV_TIME_BASE_Q, time_base); min_ts = av_rescale_rnd(min_ts, time_base.den, time_base.num * (int64_t)AV_TIME_BASE, -AV_ROUND_UP | AV_ROUND_PASS_MINMAX); +AV_ROUND_DOWN | AV_ROUND_PASS_MINMAX); max_ts = av_rescale_rnd(max_ts, time_base.den, time_base.num * (int64_t)AV_TIME_BASE, -AV_ROUND_DOWN | AV_ROUND_PASS_MINMAX); +AV_ROUND_UP | AV_ROUND_PASS_MINMAX); stream_index = 0; } -- 2.28.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 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/utils: fix seek failed
> On Dec 31, 2020, at 6:51 PM, Marton Balint wrote: > > > > On Thu, 31 Dec 2020, Zhao Zhili wrote: > >> Rounding min_ts towards +infinity and max_ts towards -infinity can >> make ts out of the [min_ts, max_ts] range, and then leads to seek >> failure. For example, > > I think this is intentional to adhere to the docs of the function: > > "Seeking will be done so that the point from which all active streams > can be presented successfully will be closest to ts and within min/max_ts." > > If you round down min_ts, you might return a packet with a timestamp less > than the original min_ts, which contradicts the documentation. > Yes, it’s not comply with the documentation strictly. On the other side, does the documentation have strong guarantee about the rounding error? Rounding error is less of a surprise than seek failure in my opinion. ffmpeg.c seek_to_start() call avformat_seek_file() with max_ts equal to ts. If avformat_seek_file() should be kept as it is, then the caller should be fixed. > Regards, > Marton > > >> >> max_ts = ts = -25057 >> time_base = (num = 1, den = 14112000) >> >> After rescale, ts = -353604, and max_ts = -353605. >> --- >> libavformat/utils.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/libavformat/utils.c b/libavformat/utils.c >> index 503e583ad0..69a0f901b2 100644 >> --- a/libavformat/utils.c >> +++ b/libavformat/utils.c >> @@ -2500,10 +2500,10 @@ int avformat_seek_file(AVFormatContext *s, int >> stream_index, int64_t min_ts, >>ts = av_rescale_q(ts, AV_TIME_BASE_Q, time_base); >>min_ts = av_rescale_rnd(min_ts, time_base.den, >>time_base.num * (int64_t)AV_TIME_BASE, >> -AV_ROUND_UP | AV_ROUND_PASS_MINMAX); >> +AV_ROUND_DOWN | AV_ROUND_PASS_MINMAX); >>max_ts = av_rescale_rnd(max_ts, time_base.den, >>time_base.num * (int64_t)AV_TIME_BASE, >> -AV_ROUND_DOWN | AV_ROUND_PASS_MINMAX); >> +AV_ROUND_UP | AV_ROUND_PASS_MINMAX); >>stream_index = 0; >>} >> -- >> 2.28.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 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 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] API and infrastructure enhancement projects
Hi. I would like to summarize the projects I have had in mind for FFmpeg for some time. I have already evoked some of them here in more or less details. These projects are not directly related to FFmpeg's work of codecs and formats, they are about FFmpeg's infrastructure and API, to make the actual work easier, and to provide a more convenient interface for applications. Before starting to invest work in them, I would like feedback from the community, both FFmpeg core developers and people who develop with FFmpeg's libraries. The projects are: - Global state into structure - Unified string / stream API - Type descriptors - Internal error messages - Event loop To make discussion easier, I will post one new mail per project. Regards, -- Nicolas George signature.asc Description: PGP signature ___ 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] Global state into structure
This mail is about a project I have to make FFmpeg's API and infrastructure more convenient. For a common introduction, see this thread: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-December/274167.html Global mutable state has annoyed developers for a long time. Log callbacks and flags, malloc limits, etc., can only be set once. If an application and a library it depends on both use FFmpeg, the settings will conflict. Recently, the lists of registered codecs, formats, protocols, etc., have been made const, but that cost us the ability to control which components were registered. I want to move all into a structure, maybe AVLibrary (or, more precisely, several structures, one per library, pointing to each-other). Contexts will have a pointer to it, making the access transparent in most cases. Existing applications will continue to work by using a global instance of AVLibrary, but new applications can allocate and their instance explicitly. The benefits I want from this: - Bring back the ability to register only a few codecs / formats / protocols. This is much more robust than a whitelist, because the whitelist must be checked each time, while a component that is not registered cannot be used at all. - Allow applications that want to use different memory allocation functions to register their own. Regards, -- Nicolas George signature.asc Description: PGP signature ___ 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] Unified string / stream API
This mail is about a project I have to make FFmpeg's API and infrastructure more convenient. For a common introduction, see this thread: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-December/274167.html int av_foo_to_string(char *buf, size_t buf_size, AVFoo *foo); int av_bar_to_string(char *buf, AVBar *bar); /**< buf should be at least 42 */ int av_qux_to_string(char **buf, AVQux *qux); /**< av_freep() buf after */ This is annoyingly inconsistent. To make the API more pleasant, a consistent way of returning strings and byte buffers is needed. Unfortunately, only the method with dynamic allocation is generic enough to serve everywhere, but it is also the most expensive and annoying to use. Fact: we have frame and buffer pools. It means we consider that dynamic allocations that happen at least once per frame are worth optimizing, even at the cost of non-trivial code. The AVWriter API is a more elegant and generic version of the AVBPrint API. By default, it works with a buffer on stack but switches to dynamic allocation as soon as needed, with many extra features. The benefits I promise from this: - Factored error handling, with only a single test at the end. - Unified string return API, with the efficiency of static buffers when possible and the power of dynamic allocation when necessary. - The ability to use for byte buffers as well. - On-the-fly filtering, for example escaping or changing the character encoding, without intermediate buffers. - The ability to directly plug with the string objects used by other libraries or languages. Regards, -- Nicolas George signature.asc Description: PGP signature ___ 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] Type descriptors
This mail is about a project I have to make FFmpeg's API and infrastructure more convenient. For a common introduction, see this thread: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-December/274167.html For each simple type, including enumerations like AVColorRange and flat structures like AVReplayGain, have a set of standardized functions for common operations, including probably: - printing; - serializing to string; - parsing from string; - serializing to/from compact binary form; - freeing; - referencing or cloning. These functions will have a standardized name and prototype. They will be grouped in structures that describe a type entirely. Note: this project requires a good unified string API. Regards, -- Nicolas George signature.asc Description: PGP signature ___ 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] Internal error messages
This mail is about a project I have to make FFmpeg's API and
infrastructure more convenient. For a common introduction, see this thread:
https://ffmpeg.org/pipermail/ffmpeg-devel/2020-December/274167.html
The way we currently report errors is fine for command-line tools running in
a terminal, but it does not suit GUI applications at all: they will get a
generic error, translated into a vague string like "invalid argument", while
a more precise error message that tells which argument is invalid and how
will go to the log, and disappear in a black-hole like ~/.xsession-errors or
even /dev/null; at best, the application will have registered a log callback
and display the whole log to the user.
I want to add a new API to return an error all at once, something like this:
if (... failure condition...)
return av_error_set(ctx, AVERROR_INVALIDDATA,
"Syntax error in file ${file} line ${line}",
"file", finename,
"line", av_d2str(line),
NULL);
The complete error message will be stored into a pre-allocated AVErrorStatus
structure in the context, and can be then retrieved by the application
using:
av_error_get(ctx, buf);
and displayed to the user in any convenient way (dialog box, HTTP response,
etc.).
For compatibility, av_log(ctx, ...) will not only print to stderr, but also
keep the last line(s) of log in the AVErrorStatus buffer in ctx, so that
code that still does the good old:
av_log(ctx, AV_LOG_ERROR, "Syntax error in file %s line %d\n",
filename, line);
return AVERROR_INVALIDDATA;
will now work ok with av_error_get().
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
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] Event loop
This mail is about a project I have to make FFmpeg's API and infrastructure more convenient. For a common introduction, see this thread: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-December/274167.html The API to access our protocols, in particular network protocols, is copied from the Unix file descriptor API, basically read() and write(). While this API is very simple and convenient when it works, it works mostly only with simple applications that do with only one input or output at a time. Extra features like timeouts or handling several streams simultaneously are complex to add. Furthermore, timeouts and non-blocking mode are currently done with a periodic polling, which makes the application always active and can prevent embedded devices from going into deep sleep, draining the battery. I want to replace it with an event loop. That means that instead of reading on a protocol context, we would register a callback for when data is available, and then let the loop run. Of course, a compatibility layer will still allow to read directly. Regards, -- Nicolas George signature.asc Description: PGP signature ___ 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] API and infrastructure enhancement projects
Nicolas George (12020-12-31): > Hi. > > I would like to summarize the projects I have had in mind for FFmpeg for > some time. I have already evoked some of them here in more or less details. > > These projects are not directly related to FFmpeg's work of codecs and > formats, they are about FFmpeg's infrastructure and API, to make the actual > work easier, and to provide a more convenient interface for applications. > > Before starting to invest work in them, I would like feedback from the > community, both FFmpeg core developers and people who develop with FFmpeg's > libraries. > > The projects are: > > - Global state into structure https://ffmpeg.org/pipermail/ffmpeg-devel/2020-December/274168.html > > - Unified string / stream API https://ffmpeg.org/pipermail/ffmpeg-devel/2020-December/274169.html > > - Type descriptors https://ffmpeg.org/pipermail/ffmpeg-devel/2020-December/274170.html > > - Internal error messages https://ffmpeg.org/pipermail/ffmpeg-devel/2020-December/274171.html > > - Event loop https://ffmpeg.org/pipermail/ffmpeg-devel/2020-December/274172.html > > To make discussion easier, I will post one new mail per project. Regards, -- Nicolas George signature.asc Description: PGP signature ___ 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] avfilter: add estdif video filter
Signed-off-by: Paul B Mahol
---
TODO: add working >8 depth support
---
doc/filters.texi | 56 ++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_estdif.c | 372 +++
4 files changed, 430 insertions(+)
create mode 100644 libavfilter/vf_estdif.c
diff --git a/doc/filters.texi b/doc/filters.texi
index 01ae540c5c..d5cfb1b4ff 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -11065,6 +11065,62 @@ Flags to local 3x3 coordinates maps like this:
This filter supports the all above options as @ref{commands}.
+@section estdif
+
+Deinterlace the input video ("estdif" stands for "Edge Slope
+Tracing Deinterlacing Filter").
+
+Spatial only filter that uses simple edge slope tracing algorithm
+to interpolate missing lines.
+It accepts the following parameters:
+
+@table @option
+@item mode
+The interlacing mode to adopt. It accepts one of the following values:
+
+@table @option
+@item frame
+Output one frame for each frame.
+@item field
+Output one frame for each field.
+@end table
+
+The default value is @code{field}.
+
+@item parity
+The picture field parity assumed for the input interlaced video. It accepts one
+of the following values:
+
+@table @option
+@item ff
+Assume the top field is first.
+@item bff
+Assume the bottom field is first.
+@item auto
+Enable automatic detection of field parity.
+@end table
+
+The default value is @code{auto}.
+If the interlacing is unknown or the decoder does not export this information,
+top field first will be assumed.
+
+@item deint
+Specify which frames to deinterlace. Accepts one of the following
+values:
+
+@table @option
+@item all
+Deinterlace all frames.
+@item interlaced
+Only deinterlace frames marked as interlaced.
+@end table
+
+The default value is @code{all}.
+@end table
+
+@subsection Commands
+This filter supports same @ref{commands} as options.
+
@section extractplanes
Extract color channel components from input video stream into
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 526da8d69e..7939381616 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -252,6 +252,7 @@ OBJS-$(CONFIG_EQ_FILTER) += vf_eq.o
OBJS-$(CONFIG_EROSION_FILTER)+= vf_neighbor.o
OBJS-$(CONFIG_EROSION_OPENCL_FILTER) += vf_neighbor_opencl.o opencl.o \
opencl/neighbor.o
+OBJS-$(CONFIG_ESTDIF_FILTER) += vf_estdif.o
OBJS-$(CONFIG_EXTRACTPLANES_FILTER) += vf_extractplanes.o
OBJS-$(CONFIG_FADE_FILTER) += vf_fade.o
OBJS-$(CONFIG_FFTDNOIZ_FILTER) += vf_fftdnoiz.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index ce317dfa1c..471844a603 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -237,6 +237,7 @@ extern AVFilter ff_vf_entropy;
extern AVFilter ff_vf_eq;
extern AVFilter ff_vf_erosion;
extern AVFilter ff_vf_erosion_opencl;
+extern AVFilter ff_vf_estdif;
extern AVFilter ff_vf_extractplanes;
extern AVFilter ff_vf_fade;
extern AVFilter ff_vf_fftdnoiz;
diff --git a/libavfilter/vf_estdif.c b/libavfilter/vf_estdif.c
new file mode 100644
index 00..ec2cd42a96
--- /dev/null
+++ b/libavfilter/vf_estdif.c
@@ -0,0 +1,372 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/common.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "video.h"
+
+typedef struct ESTDIFContext {
+const AVClass *class;
+
+int mode; ///< 0 is frame, 1 is field
+int parity; ///< frame field parity
+int deint;///< which frames to deinterlace
+int linesize[4]; ///< bytes of pixel data per line for each plane
+int planewidth[4];///< width of each plane
+int planeheight[4]; ///< height of each plane
+int field;///< which field are we on, 0 or 1
+int eof;
+int nb_planes;
+int nb_threads;
+int max;
+int64_t pts;
+AVFrame *prev;
+
+int *work_line[4];
+} ESTDIFContext;
+
+#define OFFSET(x) offsetof(ESTDIFContext, x)
+#define FLAGS
AV_OPT_FL
Re: [FFmpeg-devel] [PATCH 23/30] avcodec/qdmc: Mark decoder as init-threadsafe
probably ok
On Thu, Dec 31, 2020 at 12:36 AM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
> It already uses ff_thread_once() to initialize its static data.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/qdmc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavcodec/qdmc.c b/libavcodec/qdmc.c
> index 94681a0b6b..a8c930f0e7 100644
> --- a/libavcodec/qdmc.c
> +++ b/libavcodec/qdmc.c
> @@ -736,4 +736,5 @@ AVCodec ff_qdmc_decoder = {
> .decode = qdmc_decode_frame,
> .flush= qdmc_flush,
> .capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_CHANNEL_CONF,
> +.caps_internal= FF_CODEC_CAP_INIT_THREADSAFE,
> };
> --
> 2.25.1
>
> ___
> 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 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] avfilter: add temporal midway equalizer filter
Will apply soon. ___ 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 01/30] avcodec/opustab: Make array static
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/opustab.c | 12 ++--
> libavcodec/opustab.h | 1 -
> 2 files changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/libavcodec/opustab.c b/libavcodec/opustab.c
> index 64070f8299..7276dad793 100644
> --- a/libavcodec/opustab.c
> +++ b/libavcodec/opustab.c
> @@ -950,7 +950,7 @@ const uint16_t ff_celt_qn_exp2[] = {
> 16384, 17866, 19483, 21247, 23170, 25267, 27554, 30048
> };
>
> -const uint32_t ff_celt_pvq_u[1272] = {
> +static const uint32_t celt_pvq_u[1272] = {
> /* N = 0, K = 0...176 */
> 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0,
> @@ -1153,9 +1153,9 @@ const float ff_celt_window2[120] = {
> };
>
> const uint32_t * const ff_celt_pvq_u_row[15] = {
> -ff_celt_pvq_u +0, ff_celt_pvq_u + 176, ff_celt_pvq_u + 351,
> -ff_celt_pvq_u + 525, ff_celt_pvq_u + 698, ff_celt_pvq_u + 870,
> -ff_celt_pvq_u + 1041, ff_celt_pvq_u + 1131, ff_celt_pvq_u + 1178,
> -ff_celt_pvq_u + 1207, ff_celt_pvq_u + 1226, ff_celt_pvq_u + 1240,
> -ff_celt_pvq_u + 1248, ff_celt_pvq_u + 1254, ff_celt_pvq_u + 1257
> +celt_pvq_u +0, celt_pvq_u + 176, celt_pvq_u + 351,
> +celt_pvq_u + 525, celt_pvq_u + 698, celt_pvq_u + 870,
> +celt_pvq_u + 1041, celt_pvq_u + 1131, celt_pvq_u + 1178,
> +celt_pvq_u + 1207, celt_pvq_u + 1226, celt_pvq_u + 1240,
> +celt_pvq_u + 1248, celt_pvq_u + 1254, celt_pvq_u + 1257
> };
> diff --git a/libavcodec/opustab.h b/libavcodec/opustab.h
> index 892126bb23..cdd0456e3c 100644
> --- a/libavcodec/opustab.h
> +++ b/libavcodec/opustab.h
> @@ -152,7 +152,6 @@ extern const uint8_t ff_celt_bit_deinterleave[];
> extern const uint8_t ff_celt_hadamard_order[];
>
> extern const uint16_t ff_celt_qn_exp2[];
> -extern const uint32_t ff_celt_pvq_u[1272];
>
> extern const floatff_celt_postfilter_taps[3][3];
>
>
Lynne has approved the opus/aac/dirac and mlp patches on IRC. I am
therefore apply 1-4, 9-12, 15-20, 23 and 29 later today (10 and 11 with
cosmetic changes requested by Lynne, 29 with the changes requested by
Michael).
- Andreas
___
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] Event loop
> > I want to replace it with an event loop. That means that instead of reading > on a protocol context, we would register a callback for when data is > available, and then let the loop run. > This would be a good idea in general and bring FFmpeg into the early 21st century. As I understand it the hard part is cross-platform event loops (does libev support windows now?) Happy new year! Kieran ___ 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] Type descriptors
On Thu Dec 31 15:35:38 EET 2020, Nicolas George wrote: …For each simple type, including enumerations like AVColorRange and flat structures like AVReplayGain, have a set of standardized functions for common operations, including probably: - printing; - serializing to string; - parsing from string; … These functions will have a standardized name and prototype. They will be grouped in structures that describe a type entirely. Note: this project requires a good unified string API. This relates to one of FFmpeg's imperfections: it writes human-readable text to stdout and stderr in an unpredictable and inconsistent encoding. It should be 100% consistently encoded. I suggest it should be Unicode in UTF-8 code form. One of the places where FFmpeg's inconsistent encoding caused me a problem was when I was operating on a Quicktime video. FFmpeg (or perhaps FFprobe) printed a 4-byte Quicktime tag literally to stdout. The tag's byte sequence was not valid UTF-8. It messed up the output. That tag, being arbitrary binary data, should have been escaped or printed in hex or otherwise represented in valid UTF-8. I suggest that the type descriptor[1] and Unified string / stream API[2] proposals offer a good opportunity to define two separate data types: string of text, and stream of bytes. Define encode functions to transform text into bytes, and decode functions to transform bytes into text. The Python language str, bytes, and codecs architecture[3] is a pretty good model. I suggest that FFmpeg define that strings of text always be stored as UTF-8 code units. An argument could be made for defining strings of text as being in any encoding, as long as every single string instance be clearly labelled with its text encoding. (Specifying that all text is in UTF-8 achieves clear labelling with no code.) I suggest requiring that only validly-encoded data shall be permitted in text strings. FFmpeg code often operates on byte-granularity binary data. These should be defined as data types which are different than "string", because they are not text. FFmpeg generates human-readable output to stdout, to stderr, and to logs. I suggest that all this output be required to be text strings, preferably always in UTF-8. Any arbitrary binary data written to human-readable output must be encoded or escaped somehow, so that it is represented as valid text. [1] https://ffmpeg.org/pipermail/ffmpeg-devel/2020-December/274170.html [2] https://ffmpeg.org/pipermail/ffmpeg-devel/2020-December/274169.html [3] https://docs.python.org/3/howto/unicode.html This is an ambitious project. Good luck with it! --Jim DeLaHunt, Vancouver, Canada ___ 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] Internal error messages
On 31/12/2020 13:36, Nicolas George wrote:
> This mail is about a project I have to make FFmpeg's API and
> infrastructure more convenient. For a common introduction, see this thread:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2020-December/274167.html
>
> The way we currently report errors is fine for command-line tools running in
> a terminal, but it does not suit GUI applications at all: they will get a
> generic error, translated into a vague string like "invalid argument", while
> a more precise error message that tells which argument is invalid and how
> will go to the log, and disappear in a black-hole like ~/.xsession-errors or
> even /dev/null; at best, the application will have registered a log callback
> and display the whole log to the user.
>
> I want to add a new API to return an error all at once, something like this:
>
> if (... failure condition...)
> return av_error_set(ctx, AVERROR_INVALIDDATA,
> "Syntax error in file ${file} line ${line}",
> "file", finename,
> "line", av_d2str(line),
> NULL);
>
> The complete error message will be stored into a pre-allocated AVErrorStatus
> structure in the context, and can be then retrieved by the application
> using:
>
> av_error_get(ctx, buf);
>
> and displayed to the user in any convenient way (dialog box, HTTP response,
> etc.).
>
> For compatibility, av_log(ctx, ...) will not only print to stderr, but also
> keep the last line(s) of log in the AVErrorStatus buffer in ctx, so that
> code that still does the good old:
>
> av_log(ctx, AV_LOG_ERROR, "Syntax error in file %s line %d\n",
>filename, line);
> return AVERROR_INVALIDDATA;
>
> will now work ok with av_error_get().
Finally having proper error support would be very nice; I like this idea a lot.
What I'm a little iffy on is this last part, mostly because a lot of code in
FFmpeg just returns an error without any av_log call, so the current error
buffer in the context will at best be unrelated, or at worst, really misleading
to the user.
Cheers,
- Derek
___
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] Type descriptors
On 31/12/2020 20:15, Jim DeLaHunt wrote: > One of the places where FFmpeg's inconsistent encoding caused me a > problem was when I was operating on a Quicktime video. FFmpeg (or > perhaps FFprobe) printed a 4-byte Quicktime tag literally to stdout. The > tag's byte sequence was not valid UTF-8. It messed up the output. That > tag, being arbitrary binary data, should have been escaped or printed in > hex or otherwise represented in valid UTF-8. We really should simply never be printing 'strings' from files without any soft of validation - I consider this a bug. It's the same reason we don't just dump the User SEI as a string, for example. - Derek ___ 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 v2 06/30] Mark some pointers as const
Signed-off-by: Andreas Rheinhardt
---
Found a few more, in particular the hw_configs lists.
fftools/ffmpeg_opt.c| 86 ++---
libavcodec/aacenctab.c | 4 +-
libavcodec/aacenctab.h | 4 +-
libavcodec/av1dec.c | 2 +-
libavcodec/cbs.c| 2 +-
libavcodec/h2645_parse.c| 4 +-
libavcodec/h264dec.c| 2 +-
libavcodec/hevcdec.c| 2 +-
libavcodec/mjpegdec.c | 2 +-
libavcodec/mpeg12dec.c | 4 +-
libavcodec/mpeg4videodec.c | 2 +-
libavcodec/opustab.c| 2 +-
libavcodec/opustab.h| 2 +-
libavcodec/vc1dec.c | 4 +-
libavcodec/vp8.c| 2 +-
libavcodec/vp9.c| 2 +-
libavfilter/af_afftfilt.c | 2 +-
libavfilter/af_aiir.c | 2 +-
libavfilter/dnn/dnn_backend_native_layers.c | 2 +-
libavfilter/dnn/dnn_backend_native_layers.h | 2 +-
libavfilter/vf_geq.c| 4 +-
libavfilter/vf_qp.c | 4 +-
libavfilter/vf_selectivecolor.c | 2 +-
libavfilter/vf_tonemap_opencl.c | 6 +-
libavformat/utils.c | 2 +-
libavutil/spherical.c | 2 +-
26 files changed, 77 insertions(+), 77 deletions(-)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 242468fc64..c295514401 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -51,49 +51,49 @@
#define SPECIFIER_OPT_FMT_f"%f"
#define SPECIFIER_OPT_FMT_dbl "%lf"
-static const char *opt_name_codec_names[] = {"c", "codec",
"acodec", "vcodec", "scodec", "dcodec", NULL};
-static const char *opt_name_audio_channels[]= {"ac", NULL};
-static const char *opt_name_audio_sample_rate[] = {"ar", NULL};
-static const char *opt_name_frame_rates[] = {"r", NULL};
-static const char *opt_name_frame_sizes[] = {"s", NULL};
-static const char *opt_name_frame_pix_fmts[]= {"pix_fmt", NULL};
-static const char *opt_name_ts_scale[] = {"itsscale", NULL};
-static const char *opt_name_hwaccels[] = {"hwaccel", NULL};
-static const char *opt_name_hwaccel_devices[] = {"hwaccel_device",
NULL};
-static const char *opt_name_hwaccel_output_formats[]=
{"hwaccel_output_format", NULL};
-static const char *opt_name_autorotate[]= {"autorotate", NULL};
-static const char *opt_name_autoscale[] = {"autoscale", NULL};
-static const char *opt_name_max_frames[]= {"frames",
"aframes", "vframes", "dframes", NULL};
-static const char *opt_name_bitstream_filters[] = {"bsf", "absf",
"vbsf", NULL};
-static const char *opt_name_codec_tags[]= {"tag", "atag",
"vtag", "stag", NULL};
-static const char *opt_name_sample_fmts[] = {"sample_fmt", NULL};
-static const char *opt_name_qscale[]= {"q", "qscale",
NULL};
-static const char *opt_name_forced_key_frames[] =
{"forced_key_frames", NULL};
-static const char *opt_name_force_fps[] = {"force_fps", NULL};
-static const char *opt_name_frame_aspect_ratios[] = {"aspect", NULL};
-static const char *opt_name_rc_overrides[] = {"rc_override",
NULL};
-static const char *opt_name_intra_matrices[]= {"intra_matrix",
NULL};
-static const char *opt_name_inter_matrices[]= {"inter_matrix",
NULL};
-static const char *opt_name_chroma_intra_matrices[] =
{"chroma_intra_matrix", NULL};
-static const char *opt_name_top_field_first[] = {"top", NULL};
-static const char *opt_name_presets[] = {"pre", "apre",
"vpre", "spre", NULL};
-static const char *opt_name_copy_initial_nonkeyframes[] = {"copyinkfr", NULL};
-static const char *opt_name_copy_prior_start[] = {"copypriorss",
NULL};
-static const char *opt_name_filters[] = {"filter", "af",
"vf", NULL};
-static const char *opt_name_filter_scripts[]= {"filter_script",
NULL};
-static const char *opt_name_reinit_filters[]= {"reinit_filter",
NULL};
-static const char *opt_name_fix_sub_duration[] = {"fix_sub_duration",
NULL};
-static const char *opt_name_canvas_sizes[] = {"canvas_size",
NULL};
-static const char *opt_name_pass[] = {"pass", NULL};
-static const char *opt_name_passlogfiles[] = {"passlogfile",
NULL};
-static const char *opt_name_max_muxing_queue_size[] =
{"max_muxing_queue_size", NULL};
-static const char *opt_name_muxing_queue_data_threshold[] =
{"muxing_queue_data_threshold", NULL};
-static const char *opt_name_guess_layout_max[]
Re: [FFmpeg-devel] [PATCH v2 06/30] Mark some pointers as const
Jan 1, 2021, 01:35 by andreas.rheinha...@gmail.com: > Signed-off-by: Andreas Rheinhardt > --- > Found a few more, in particular the hw_configs lists. > > fftools/ffmpeg_opt.c| 86 ++--- > libavcodec/aacenctab.c | 4 +- > libavcodec/aacenctab.h | 4 +- > libavcodec/av1dec.c | 2 +- > libavcodec/cbs.c| 2 +- > libavcodec/h2645_parse.c| 4 +- > libavcodec/h264dec.c| 2 +- > libavcodec/hevcdec.c| 2 +- > libavcodec/mjpegdec.c | 2 +- > libavcodec/mpeg12dec.c | 4 +- > libavcodec/mpeg4videodec.c | 2 +- > libavcodec/opustab.c| 2 +- > libavcodec/opustab.h| 2 +- > libavcodec/vc1dec.c | 4 +- > libavcodec/vp8.c| 2 +- > libavcodec/vp9.c| 2 +- > libavfilter/af_afftfilt.c | 2 +- > libavfilter/af_aiir.c | 2 +- > libavfilter/dnn/dnn_backend_native_layers.c | 2 +- > libavfilter/dnn/dnn_backend_native_layers.h | 2 +- > libavfilter/vf_geq.c| 4 +- > libavfilter/vf_qp.c | 4 +- > libavfilter/vf_selectivecolor.c | 2 +- > libavfilter/vf_tonemap_opencl.c | 6 +- > libavformat/utils.c | 2 +- > libavutil/spherical.c | 2 +- > 26 files changed, 77 insertions(+), 77 deletions(-) > LGTM ___ 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".
