Re: [FFmpeg-devel] [PATCH V2 6/7] libavformat/smoothstreamingenc.c: fix build warning for [-Wformat-truncation=]
> On 25 Feb 2021, at 07:38, Guo, Yejun wrote:
> --- a/libavformat/smoothstreamingenc.c
> +++ b/libavformat/smoothstreamingenc.c
> @@ -501,7 +501,7 @@ static int ism_flush(AVFormatContext *s, int final)
>
> for (i = 0; i < s->nb_streams; i++) {
> OutputStream *os = &c->streams[i];
> -char filename[1024], target_filename[1024], header_filename[1024],
> curr_dirname[1024];
> +char filename[2048], target_filename[2048], header_filename[2048],
> curr_dirname[1024];
> int64_t size;
> int64_t start_ts, duration, moof_size;
> if (!os->packets_written)
IMO some of these allocations are getting a bit too large for the stack
(multi-page stack allocations weaken security measures even if the large
arrays themselves do not overflow).
And no matter what size you put, there’s always a larger filename possible
where it breaks, so it feels like just warning polishing with marginal
real benefit.
Why not use av_asprintf, then at least the problem is actually solved for real?
I don’t see that this code is performance relevant, so the only reason to
put these onto stack is being too lazy to do the memory management, which
I think is a fairly weak argument.
Best regards,
Reimar
___
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] filters/metadata: add CSV output support
This adds a new option to the metadata filter that allows outputting CSV data.
The separator can be set via another option.
Special characters are handled via escaping.
Signed-off-by: Werner Robitza
---
doc/filters.texi | 14
libavfilter/f_metadata.c | 155 ---
2 files changed, 158 insertions(+), 11 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 426cb158da..0b56d73565 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -25134,6 +25134,20 @@ with AV_LOG_INFO loglevel.
@item direct
Reduces buffering in print mode when output is written to a URL set using
@var{file}.
+@item format
+Set the output format for the print mode.
+
+@table @samp
+@item default
+Default output format
+
+@item csv
+Comma-separated output
+@end table
+
+@item csv_sep
+Set the CSV separator (only valid for CSV format). Default is @code{,}. Must be
+one character and cannot be a period (@code{.}).
@end table
@subsection Examples
diff --git a/libavfilter/f_metadata.c b/libavfilter/f_metadata.c
index 598257b15b..45f5eeddcd 100644
--- a/libavfilter/f_metadata.c
+++ b/libavfilter/f_metadata.c
@@ -58,6 +58,11 @@ enum MetadataFunction {
METADATAF_NB
};
+enum MetadataFormat {
+METADATA_FORMAT_DEFAULT,
+METADATA_FORMAT_CSV
+};
+
static const char *const var_names[] = {
"VALUE1",
"VALUE2",
@@ -85,6 +90,9 @@ typedef struct MetadataContext {
AVIOContext* avio_context;
char *file_str;
+int format;
+char *csv_sep;
+
int (*compare)(struct MetadataContext *s,
const char *value1, const char *value2);
void (*print)(AVFilterContext *ctx, const char *msg, ...)
av_printf_format(2, 3);
@@ -114,6 +122,10 @@ static const AVOption filt_name##_options[] = { \
{ "expr", "set expression for expr function", OFFSET(expr_str),
AV_OPT_TYPE_STRING, {.str = NULL }, 0, 0, FLAGS }, \
{ "file", "set file where to print metadata information",
OFFSET(file_str), AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, FLAGS }, \
{ "direct", "reduce buffering when printing to user-set file or pipe",
OFFSET(direct), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, FLAGS }, \
+{ "format", "set output format", OFFSET(format), AV_OPT_TYPE_INT, {.i64 =
0 }, 0, METADATAF_NB-1, FLAGS, "format" }, \
+{ "default", "default format", 0, AV_OPT_TYPE_CONST, {.i64 =
METADATA_FORMAT_DEFAULT }, 0, 0, FLAGS, "format" }, \
+{ "csv", "comma-separated", 0, AV_OPT_TYPE_CONST, {.i64 =
METADATA_FORMAT_CSV }, 0, 0, FLAGS, "format" }, \
+{ "csv_sep", "set CSV separator (only valid for CSV format)",
OFFSET(csv_sep), AV_OPT_TYPE_STRING, {.str=","}, 0, 0, FLAGS }, \
{ NULL } \
}
@@ -202,6 +214,58 @@ static void print_file(AVFilterContext *ctx, const char
*msg, ...)
va_end(argument_list);
}
+static void print_csv_escaped(AVFilterContext *ctx, const char *src)
+{
+MetadataContext *s = ctx->priv;
+
+char meta_chars[] = {s->csv_sep[0], '"', '\n', '\r', '\0'};
+int needs_quoting = !!src[strcspn(src, meta_chars)];
+
+// allocate space for two extra quotes and possibly every char escaped
+char buf[strlen(src) * 2 + 2];
+
+int pos = 0;
+
+if (needs_quoting)
+buf[pos++] = '"';
+
+for (int i = 0; i < strlen(src); i++) {
+if (src[i] == '"')
+buf[pos++] = '\"';
+buf[pos++] = src[i];
+}
+
+if (needs_quoting)
+buf[pos++] = '"';
+
+buf[pos] = '\0';
+
+s->print(ctx, "%s", buf);
+}
+
+static void csv_escape(const char *src, char **dst, const char csv_sep)
+{
+char meta_chars[] = {csv_sep, '"', '\n', '\r', '\0'};
+int needs_quoting = !!src[strcspn(src, meta_chars)];
+
+int pos = 0;
+
+if (needs_quoting)
+*dst[pos++] = '"';
+
+for (int i = 0; i < strlen(src); i++)
+{
+if (src[i] == '"')
+*dst[pos++] = '\"';
+*dst[pos++] = src[i];
+}
+
+if (needs_quoting)
+*dst[pos++] = '"';
+
+*dst[pos] = '\0';
+}
+
static av_cold int init(AVFilterContext *ctx)
{
MetadataContext *s = ctx->priv;
@@ -282,6 +346,33 @@ static av_cold int init(AVFilterContext *ctx)
s->avio_context->direct = AVIO_FLAG_DIRECT;
}
+if (s->format == METADATA_FORMAT_CSV) {
+if (strlen(s->csv_sep) == 0) {
+av_log(ctx, AV_LOG_ERROR,
+ "No CSV separator supplied\n");
+return AVERROR(EINVAL);
+}
+if (strlen(s->csv_sep) > 1) {
+av_log(ctx, AV_LOG_ERROR,
+ "CSV separator must be one character only\n");
+return AVERROR(EINVAL);
+}
+if (s->csv_sep[0] == '.') {
+av_log(ctx, AV_LOG_ERROR,
+ "CSV separator cannot be a single period ('.')\n");
+return AVERROR(EINVAL);
+}
+s->print(
+ctx,
+"%s%s%s%s%s%s%s%s%s\n",
+"frame", s->csv_sep,
+"pts", s->csv_sep,
Re: [FFmpeg-devel] [PATCH] filters/metadata: add CSV output support
On Thu, Feb 25, 2021 at 9:34 AM Werner Robitza wrote: > > This adds a new option to the metadata filter that allows outputting CSV data. > The separator can be set via another option. > Special characters are handled via escaping. Fixed a newline bug and removed unused function. ___ 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] filters/metadata: add CSV output support
On Thu, Feb 25, 2021 at 1:32 AM Paul B Mahol wrote: > On Wed, Feb 24, 2021 at 9:48 PM Werner Robitza > wrote: >> Could please show an example on how to achieve this with ffprobe? > See same thread where I replied or use search. If you are referring to: -vf your_filter,metadata=mode=print That does not work in ffprobe. For instance, using the patch I submitted, I can get easy to parse output like: $ ffmpeg -f lavfi -i testsrc -frames:v 1 -filter:v signalstats,metadata=mode=print:format=csv -f null /dev/null frame,pts,pts_time,key,value 0,0,0,lavfi.signalstats.YMIN,4 … How would I get the same with ffprobe? ___ 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 1/2] avfilter/transform: Stop exporting internal functions
Andreas Rheinhardt (12021-02-25): > And why? There was never a legitimate outside user of these functions. I agree with that. Something that was not part of the API cannot be considered part of the ABI. If some project use these functions, they were explicitly cheating, and they knew it. 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] [PATCH] filters/metadata: add CSV output support
Werner Robitza (12021-02-25): > > This adds a new option to the metadata filter that allows outputting CSV > > data. > > The separator can be set via another option. > > Special characters are handled via escaping. > > Fixed a newline bug and removed unused function. Still duplicating code from ffprobe. 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] [PATCH] filters/metadata: add CSV output support
Werner Robitza (12021-02-25): > If you are referring to: > > -vf your_filter,metadata=mode=print > > That does not work in ffprobe. Of course, since ffprobe does the printing for you. > For instance, using the patch I submitted, I can get easy to parse output > like: Parsing the standard output of any program is bad design and bound to break at some point. Also, I wonder why you chose CSV, which is one of the worse possible formats. 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] [PATCH] filters/metadata: add CSV output support
Werner Robitza (12021-02-24): > I didn't really duplicate anything; this was mostly from scratch. The > case could be made that a function for escaping CSV could be shared. The variable names seemed quite similar. Anyway, duplicating a feature is just as bad as duplicating code. > There are at least two such functions already in the code base. We should not have accepted the second one like that. It does not constitute a precedent. 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] Proposal of two projects for GSoC
Artem Galin 于2021年2月24日周三 下午11:46写道： > > Hello, > > > > Please find the proposal for the following two projects for GSoC this year. > > The FATE project had been proposed earlier already but I don't know why it > didn't happen. > > I previously got the feedback from Thilo Borgmann and would be happy to get > feedback from the community as well. > > > > " > > > > FATE tests for HW acceleration > > > > Description: FFmpeg's FATE regression test system do not include validation > of hardware acceleration. This project is about to include these > hardware-specific regression tests to the FATE system. Since this project > requires access to corresponding hardware, it is not expected to cover the > whole range of hardware accelerators there are but to initialize some > useful tests for available hardware, most likely to include CPU > acceleration on Intel or AMD at least. Access to other hardware can also be > provided during the project, depending on the students requirements. > > > > Expected results: Implement tests for the different hardware decoding, > encoding and transcoding capabilities there are. > > > > Prerequisites: Good C and Makefile coding skills, basic familiarity with > Git. > > > > Qualification Task: TBD > > > > Mentor: Artem G (artem.galin [at] intel [dot] com) > > > > Backup Mentor: TBD > > > > " > > > > > > Title: oneAPI Video Processing Library (oneVPL) for CPU & GPU hardware > accelleration (https://www.oneapi.com/) > > > > Description: Add support for oneVPL > > > > The oneAPI project is developing a common cross-platform API for video > processing, including CPU and GPU hardware acceleration. > > > > At least Intel's MediaSDK (https://github.com/Intel-Media-SDK/MediaSDK < > https://github.com/Intel-Media-SDK/MediaSDK>), providing the currently used > QSV API used for HW acceleration on Intel, will transition to implement the > oneAPI API, called oneVPL (https://github.com/oneapi-src/oneVPL). > > > > Therefore, this project aims to get FFmpeg ready for this new API to ensure > future availability of not only Intel's HW acceleration after the > transition to oneVPL but also for possible other implementations of the > oneAPI from other vendors. > > > > > > Expected results: Implement a oneVPL library wrapper into FFmpeg. > > Validate that media pipelines work with no regressions by supported feature > set and performance. > > > > > > Prerequisites: Good C and Makefile coding skills, basic familiarity with > Git. > > > > Qualification Task: TBD > > > > Mentor: Artem G (artem.galin [at] intel [dot] com) > > > > Backup Mentor: TBD > > > > > > " > > > > Thanks, > > Artem. > ___ > 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". Do you mean you want base on this patch: http://ffmpeg.org/pipermail/ffmpeg-devel/2020-September/269905.html ___ 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] Proposal of two projects for GSoC
On Wed, 24 Feb 2021 at 17:01, Soft Works wrote: > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Artem Galin > > Sent: Wednesday, February 24, 2021 4:40 PM > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: [FFmpeg-devel] Proposal of two projects for GSoC > > > > > > > > Please find the proposal for the following two projects for GSoC this > year. > > > > > > > Title: oneAPI Video Processing Library (oneVPL) for CPU & GPU hardware > > accelleration (https://www.oneapi.com/) > > > > Description: Add support for oneVPL > > > > Hi Artem, > > I hope your doing fine! Your v7 patch for D3D11 QSV is now mostly identical > to my original code (except defaulting to D3D11), and I'm pretty glad about > that outcome. Probably meanwhile you came to understand why I didn't > want to submit the code myself, but I hadn't expected that even Intel is > being ignored here for so long :-( > > That being said, I have two questions regarding oneVPL: > > 1. From all the docs I've read, it was always about limitations of oneVPL >In relation to MediaSDK. Is there a single thing which oneVPL can do >that can't be done with MediaSDK? > > 2. Will MediaSDK be discontinued, renamed or continued to coexist with >oneVPL? > > Thanks and kind regards, > softworkz > > Hi Softworkz, Proposal is forward looking. Stay tuned for more details about oneVPL. Thanks, Artem. > > ___ > 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 v7 8/8] libavfilter/vf_deinterlace_qsv: enabling d3d11va support, added mfxhdlpair
On Wed, 24 Feb 2021 at 17:50, Soft Works wrote: > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Artem Galin > > Sent: Tuesday, November 3, 2020 7:46 PM > > To: ffmpeg-devel@ffmpeg.org > > Cc: Artem Galin > > Subject: [FFmpeg-devel] [PATCH v7 8/8] libavfilter/vf_deinterlace_qsv: > > enabling d3d11va support, added mfxhdlpair > > > > Adding DX11 relevant device type checks and adjusting callback with > proper > > MediaSDK pair type support. > > > > Hi Artem, > > I have a few more notes regarding the patch: > > The switch to using mfxhdlpair will cause a regression in case of > VAAPI/OpenCL > Interop. In hwcontext_opencl.cs, function opencl_map_from_qsv, you need to > cast the MemId to mfxHDLPair for getting the surface id. > > OpenCL interop on Windows is a whole different story, but it's not a small > thing > like the above, so you better handle that at a later time. It's not a > regression > anyway because this functionality doesn't exist yet (for D3D11). > > At the same time, that's another reason for NOT changing the default to > D3D11 > because somebody using QSV<=>OpenCL interop would see his commands > failing when you change the default to D3D11. > > I don't know what others here are thinking (because nobody says anything), > but IMO, a patch that doesn't switch the default impl would have less > impact and probably better chances to get merged. > > Kind regards, > softworkz > > Hi Softworkz, D3D11VA works with more variety of HW configurations and there is no DX9 drop in the patch. Feel free to send your version of the patch with interop fix. Thanks, Artem. > > > ___ > 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] [RFC] Unified string / stream API
We have more and more users demanding a better output for the side information generated by filters and other components than savage log output. That probably means moving the formatted writer features of ffprobe into proper libavutil APIs. But ffprobe only outputs to standard output, a proper API should be capable of writing to a memory buffer or an AVIO context. And it needs to be efficient, as it can happen once per frame or more: no dynamic allocation if it can be avoided. The enhancement I propose below addresses that and more. I am considering working on at least one writer (probably JSON) soon. Please comment. Regards, -- Nicolas George Nicolas George (12020-12-31): > 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. 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] [PATCH] filters/metadata: add CSV output support
On Thu, Feb 25, 2021 at 11:25 AM Nicolas George wrote: > > Werner Robitza (12021-02-25): > > If you are referring to: > > > > -vf your_filter,metadata=mode=print > > > > That does not work in ffprobe. > > Of course, since ffprobe does the printing for you. At the risk of repeating the same question, could you please show a command with ffprobe that achieves the same kind of parsable output that this patch generates? After fiddling around a bit, when I run: ffprobe -loglevel error -f lavfi -i "testsrc,signalstats" -show_entries tags -of csv=nk=0 | head -n 1 I get a line like: packet,tag:lavfi.signalstats.YMIN=16,tag:lavfi.signalstats.YLOW=16,… which is not semantically meaningful, since both keys and values are contained in the individual cells. This makes parsing incredibly more complex than it has to be. > > For instance, using the patch I submitted, I can get easy to parse output > > like: > > Parsing the standard output of any program is bad design and bound to > break at some point. That was just an example on the CLI. The filter has a file option with which you can output to a well-formatted CSV file, so parsing is not an issue there. > Also, I wonder why you chose CSV, which is one of the worse possible > formats. I feel this is only tangential to the discussion, but: It's well-defined, easy to parse by numerous libraries, can be modified easily, and is a de-facto standard for sharing data in certain communities (. It wouldn't even occur to me why you'd want another format for certain kinds of applications. In particular with data that isn't nested, it's much easier to use in data analysis procedures than JSON or others. ___ 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] filters/metadata: add CSV output support
On Thu, Feb 25, 2021 at 11:26 AM Nicolas George wrote: > Werner Robitza (12021-02-24): > > I didn't really duplicate anything; this was mostly from scratch. The > > case could be made that a function for escaping CSV could be shared. > > The variable names seemed quite similar. Anyway, duplicating a feature > is just as bad as duplicating code. Would you accept this patch if this particular function was extracted to an API and re-used by ffprobe? (And potentially segment.c …) ___ 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] filters/metadata: add CSV output support
Werner Robitza (12021-02-25): > After fiddling around a bit, when I run: > > ffprobe -loglevel error -f lavfi -i "testsrc,signalstats" > -show_entries tags -of csv=nk=0 | head -n 1 > > I get a line like: > > packet,tag:lavfi.signalstats.YMIN=16,tag:lavfi.signalstats.YLOW=16,… I doubt ffprobe did output an ellipsis character on its own. For simpler parsing, use a different writer than csv. I would recommend flat. 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] [PATCH] filters/metadata: add CSV output support
Werner Robitza (12021-02-25): > Would you accept this patch if this particular function was extracted > to an API and re-used by ffprobe? (And potentially segment.c …) Yes, but I must warn you that the constraints on a libavutil API are stronger than the constraints on helper functions in ffprobe. This is why I re-started the following discussion: https://ffmpeg.org/pipermail/ffmpeg-devel/2021-February/276855.html You can weigh in. 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] [PATCH] filters/metadata: add CSV output support
On Thu, Feb 25, 2021 at 12:47 PM Nicolas George wrote: > Werner Robitza (12021-02-25): > > After fiddling around a bit, when I run: > > > > ffprobe -loglevel error -f lavfi -i "testsrc,signalstats" > > -show_entries tags -of csv=nk=0 | head -n 1 > > > > I get a line like: > > > > packet,tag:lavfi.signalstats.YMIN=16,tag:lavfi.signalstats.YLOW=16,… > > I doubt ffprobe did output an ellipsis character on its own. That's why I wrote "like" – I am sure you were able to interpret the meaning of the ellipsis in this example. > For simpler parsing, use a different writer than csv. I would recommend > flat. That seems to be a custom format, so parsing is inherently more complex, and there's no support for simply loading this in whatever tool you have for data analysis (Excel, MATLAB, R, Python, …). Hence the usefulness of semantically meaningfully structured CSV. I guess I could live with replacing the "flat" output dots with commas, and the equal sign with another comma, but that's bound to break with some metadata value contents. ___ 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 1/4] avformat/wavenc: Improve unsupported codec error messages
Signed-off-by: Andreas Rheinhardt
---
The actual aim is of course to remove a nonconst AVCodec.
libavformat/wavenc.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/libavformat/wavenc.c b/libavformat/wavenc.c
index b65b8b0940..078b7fcd9a 100644
--- a/libavformat/wavenc.c
+++ b/libavformat/wavenc.c
@@ -159,9 +159,8 @@ static av_cold int peak_init_writer(AVFormatContext *s)
par->codec_id != AV_CODEC_ID_PCM_S16LE &&
par->codec_id != AV_CODEC_ID_PCM_U8 &&
par->codec_id != AV_CODEC_ID_PCM_U16LE) {
-AVCodec *codec =
avcodec_find_decoder(s->streams[0]->codecpar->codec_id);
-av_log(s, AV_LOG_ERROR, "%s codec not supported for Peak Chunk\n",
- codec ? codec->name : "NONE");
+av_log(s, AV_LOG_ERROR, "Codec %s not supported for Peak Chunk\n",
+ avcodec_get_name(par->codec_id));
return -1;
}
@@ -325,9 +324,8 @@ static int wav_write_header(AVFormatContext *s)
/* format header */
fmt = ff_start_tag(pb, "fmt ");
if (ff_put_wav_header(s, pb, s->streams[0]->codecpar, 0) < 0) {
-const AVCodecDescriptor *desc =
avcodec_descriptor_get(s->streams[0]->codecpar->codec_id);
-av_log(s, AV_LOG_ERROR, "%s codec not supported in WAVE format\n",
- desc ? desc->name : "unknown");
+av_log(s, AV_LOG_ERROR, "Codec %s not supported in WAVE format\n",
+ avcodec_get_name(s->streams[0]->codecpar->codec_id));
return AVERROR(ENOSYS);
}
ff_end_tag(pb, fmt);
@@ -553,9 +551,8 @@ static int w64_write_header(AVFormatContext *s)
avio_write(pb, ff_w64_guid_wave, sizeof(ff_w64_guid_wave));
start_guid(pb, ff_w64_guid_fmt, &start);
if ((ret = ff_put_wav_header(s, pb, s->streams[0]->codecpar, 0)) < 0) {
-AVCodec *codec =
avcodec_find_decoder(s->streams[0]->codecpar->codec_id);
-av_log(s, AV_LOG_ERROR, "%s codec not supported\n",
- codec ? codec->name : "NONE");
+av_log(s, AV_LOG_ERROR, "Codec %s not supported\n",
+ avcodec_get_name(s->streams[0]->codecpar->codec_id));
return ret;
}
end_guid(pb, start);
--
2.27.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 2/4] avcodec/libx264: Don't use init_static_data for newer versions
x264 versions >= 153 can support multiple bitdepths; they also don't
export x264_bit_depth any more. The actual check whether a bitdepth
is supported is therefore performed at runtime in x264_encoder_open.
Ergo it is unnecessary to use init_static_data for these versions:
One can already set ff_libx264_encoder.pix_fmts to the value that
X264_init_static always sets it to.
Signed-off-by: Andreas Rheinhardt
---
The actual aim is of course to enable to make ff_libx264_encoder const
after the next major bump if a new libx264 version is used. I am
currently working on this.
libavcodec/libx264.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index ca7cc3a540..212ed7d015 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -1051,19 +1051,17 @@ static const enum AVPixelFormat pix_fmts_8bit_rgb[] = {
};
#endif
+#if X264_BUILD < 153
static av_cold void X264_init_static(AVCodec *codec)
{
-#if X264_BUILD < 153
if (x264_bit_depth == 8)
codec->pix_fmts = pix_fmts_8bit;
else if (x264_bit_depth == 9)
codec->pix_fmts = pix_fmts_9bit;
else if (x264_bit_depth == 10)
codec->pix_fmts = pix_fmts_10bit;
-#else
-codec->pix_fmts = pix_fmts_all;
-#endif
}
+#endif
#define OFFSET(x) offsetof(X264Context, x)
#define VE AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
@@ -1208,7 +1206,11 @@ AVCodec ff_libx264_encoder = {
AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
.priv_class = &x264_class,
.defaults = x264_defaults,
+#if X264_BUILD < 153
.init_static_data = X264_init_static,
+#else
+.pix_fmts = pix_fmts_all,
+#endif
#if X264_BUILD >= 158
.caps_internal= FF_CODEC_CAP_INIT_CLEANUP |
FF_CODEC_CAP_INIT_THREADSAFE,
#else
--
2.27.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 3/4] fftools: Switch to const AVCodec * where possible
The obstacle to do so was in filter_codec_opts: It uses searches
the AVCodec for options via the AV_OPT_SEARCH_FAKE_OBJ method, which
requires using a void * that points to a pointer to a const AVClass.
When using const AVCodec *, one can not simply use a pointer that points
to the AVCodec's pointer to its AVClass, as said pointer is const, too.
This is fixed by using a temporary pointer to the AVClass.
Signed-off-by: Andreas Rheinhardt
---
The actual obstacle in av_opt_find2 is in the fact that the child_next
callback uses a void* for the object. (Is it really intended that any
child_next ever modifies it?)
fftools/cmdutils.c | 7 ---
fftools/cmdutils.h | 2 +-
fftools/ffmpeg.c | 6 +++---
fftools/ffmpeg.h | 4 ++--
fftools/ffmpeg_opt.c | 4 ++--
fftools/ffplay.c | 2 +-
fftools/ffprobe.c| 2 +-
7 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 4eb68d2201..dca6ae3d23 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -2103,7 +2103,7 @@ int check_stream_specifier(AVFormatContext *s, AVStream
*st, const char *spec)
}
AVDictionary *filter_codec_opts(AVDictionary *opts, enum AVCodecID codec_id,
-AVFormatContext *s, AVStream *st, AVCodec
*codec)
+AVFormatContext *s, AVStream *st, const
AVCodec *codec)
{
AVDictionary*ret = NULL;
AVDictionaryEntry *t = NULL;
@@ -2132,6 +2132,7 @@ AVDictionary *filter_codec_opts(AVDictionary *opts, enum
AVCodecID codec_id,
}
while (t = av_dict_get(opts, "", t, AV_DICT_IGNORE_SUFFIX)) {
+const AVClass *priv_class;
char *p = strchr(t->key, ':');
/* check stream specification in opt name */
@@ -2144,8 +2145,8 @@ AVDictionary *filter_codec_opts(AVDictionary *opts, enum
AVCodecID codec_id,
if (av_opt_find(&cc, t->key, NULL, flags, AV_OPT_SEARCH_FAKE_OBJ) ||
!codec ||
-(codec->priv_class &&
- av_opt_find(&codec->priv_class, t->key, NULL, flags,
+((priv_class = codec->priv_class) &&
+ av_opt_find(&priv_class, t->key, NULL, flags,
AV_OPT_SEARCH_FAKE_OBJ)))
av_dict_set(&ret, t->key, t->value, 0);
else if (t->key[0] == prefix &&
diff --git a/fftools/cmdutils.h b/fftools/cmdutils.h
index 1917510589..5da9f4c88f 100644
--- a/fftools/cmdutils.h
+++ b/fftools/cmdutils.h
@@ -414,7 +414,7 @@ int check_stream_specifier(AVFormatContext *s, AVStream
*st, const char *spec);
* @return a pointer to the created dictionary
*/
AVDictionary *filter_codec_opts(AVDictionary *opts, enum AVCodecID codec_id,
-AVFormatContext *s, AVStream *st, AVCodec
*codec);
+AVFormatContext *s, AVStream *st, const
AVCodec *codec);
/**
* Setup AVCodecContext options for avformat_find_stream_info().
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index add5a3e505..5d52d36470 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -688,7 +688,7 @@ void assert_avoptions(AVDictionary *m)
}
}
-static void abort_codec_experimental(AVCodec *c, int encoder)
+static void abort_codec_experimental(const AVCodec *c, int encoder)
{
exit_program(1);
}
@@ -2943,7 +2943,7 @@ static int init_input_stream(int ist_index, char *error,
int error_len)
InputStream *ist = input_streams[ist_index];
if (ist->decoding_needed) {
-AVCodec *codec = ist->dec;
+const AVCodec *codec = ist->dec;
if (!codec) {
snprintf(error, error_len, "Decoder (codec %s) not found for input
stream #%d:%d",
avcodec_get_name(ist->dec_ctx->codec_id), ist->file_index,
ist->st->index);
@@ -3523,7 +3523,7 @@ static int init_output_stream(OutputStream *ost, AVFrame
*frame,
int ret = 0;
if (ost->encoding_needed) {
-AVCodec *codec = ost->enc;
+const AVCodec *codec = ost->enc;
AVCodecContext *dec = NULL;
InputStream *ist;
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 423da071dc..8813eaf2e3 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -307,7 +307,7 @@ typedef struct InputStream {
#define DECODING_FOR_FILTER 2
AVCodecContext *dec_ctx;
-AVCodec *dec;
+const AVCodec *dec;
AVFrame *decoded_frame;
AVFrame *filter_frame; /* a ref of decoded_frame, to be sent to filters */
@@ -470,7 +470,7 @@ typedef struct OutputStream {
AVCodecContext *enc_ctx;
AVCodecParameters *ref_par; /* associated input codec parameters with
encoders options applied */
-AVCodec *enc;
+const AVCodec *enc;
int64_t max_frames;
AVFrame *filtered_frame;
AVFrame *last_frame;
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 1cb601f7c7..85feeb89f2 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -766,13 +766,13 @@ static AVCodec *find_codec_or_die(const char *n
[FFmpeg-devel] [PATCH 4/4] avcodec/avcodec: Add missing deprecation to AVCodecParser.next
The whole old next API has been deprecated in commit
7e8eba2d8755962d9dca5eade57bf8f591a73c0c, yet deprecating the next
pointer has been forgotten (the next pointers of other structures are
below the public API delimiter, but such a delimiter doesn't exist for
AVCodecParser).
Signed-off-by: Andreas Rheinhardt
---
libavcodec/avcodec.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 5df6a8aedc..b0cb91f555 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3512,7 +3512,10 @@ typedef struct AVCodecParser {
const uint8_t *buf, int buf_size);
void (*parser_close)(AVCodecParserContext *s);
int (*split)(AVCodecContext *avctx, const uint8_t *buf, int buf_size);
+#if FF_API_NEXT
+attribute_deprecated
struct AVCodecParser *next;
+#endif
} AVCodecParser;
/**
--
2.27.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 4/4] avcodec/avcodec: Add missing deprecation to AVCodecParser.next
On 2/25/2021 11:05 AM, Andreas Rheinhardt wrote:
The whole old next API has been deprecated in commit
7e8eba2d8755962d9dca5eade57bf8f591a73c0c, yet deprecating the next
pointer has been forgotten (the next pointers of other structures are
below the public API delimiter, but such a delimiter doesn't exist for
AVCodecParser).
Signed-off-by: Andreas Rheinhardt
---
libavcodec/avcodec.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 5df6a8aedc..b0cb91f555 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3512,7 +3512,10 @@ typedef struct AVCodecParser {
const uint8_t *buf, int buf_size);
void (*parser_close)(AVCodecParserContext *s);
int (*split)(AVCodecContext *avctx, const uint8_t *buf, int buf_size);
+#if FF_API_NEXT
+attribute_deprecated
Adding this will make parsers.c start printing deprecation warnings. Can
you add the FF_{ENABLE,DISABLE}_DEPRECATION_WARNINGS wrappers there
while at it?
struct AVCodecParser *next;
+#endif
} AVCodecParser;
/**
___
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 1/2] avfilter/transform: Stop exporting internal functions
On 2/24/2021 9:31 PM, Andreas Rheinhardt wrote: James Almer: On 2/24/2021 11:22 AM, Andreas Rheinhardt wrote: avfilter_transform, avfilter_(add|sub|mult)_matrix are not part of the public API (transform.h is not a public header), yet they are currently exported because of their name. This commit changes this: avfilter_transform is renamed to ff_affine_transform; the other functions are just removed as they have never been used at all. The symbols are exported and have been in four releases so far for this soname. If we plan on making a 4.4 release before the bump, it may be a good idea if we keep the symbols around for the sake of not affecting the ABI, so I'm inclined towards just wrapping them in a LIBAVFILTER_VERSION_MAJOR < 8 check like we do when we remove avpriv ones. And why? There was never a legitimate outside user of these functions. Because it's still exported. But ok, since nobody seems to think it's worth bothering with, this patch should be ok as is. And removing avfilter_all_channel_layouts in d5e5c6862bbc834d5a036a3fa053a7569d84f928 (which also didn't have a legitimate outside user) didn't seem to break anything either. That function and others are mentioned as added in APIChanges yet their removal is not. Sounds like it was handled poorly... Btw: 88d80cb97528d52dac3178cf5393d6095eca6200 broke ABI for x64, because older versions of libavformat exchange a PutBitContext with libavcodec via avpriv_align_put_bits and avpriv_copy_bits. So we can't really make a 4.4 release. That commit could be reverted in the release/4.4 branch. But yeah, it should have not been committed until those two functions were removed, since they tie PutBitContext to the ABI. A crappy situation overall, but it should not prevent us from making one last release before the bump. The amount of additions to the libraries is considerable, and the first release post bump will be missing a lot of old API, so adoption could take a bit, and something newer than 4.3 should be readily available long before that. ___ 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 1/4] avformat/wavenc: Improve unsupported codec error messages
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".
Re: [FFmpeg-devel] [PATCH 1/2] avfilter/transform: Stop exporting internal functions
James Almer: > On 2/24/2021 9:31 PM, Andreas Rheinhardt wrote: >> James Almer: >>> On 2/24/2021 11:22 AM, Andreas Rheinhardt wrote: avfilter_transform, avfilter_(add|sub|mult)_matrix are not part of the public API (transform.h is not a public header), yet they are currently exported because of their name. This commit changes this: avfilter_transform is renamed to ff_affine_transform; the other functions are just removed as they have never been used at all. >>> >>> The symbols are exported and have been in four releases so far for this >>> soname. If we plan on making a 4.4 release before the bump, it may be a >>> good idea if we keep the symbols around for the sake of not affecting >>> the ABI, so I'm inclined towards just wrapping them in a >>> LIBAVFILTER_VERSION_MAJOR < 8 check like we do when we remove avpriv >>> ones. >>> >> >> And why? There was never a legitimate outside user of these functions. > > Because it's still exported. But ok, since nobody seems to think it's > worth bothering with, this patch should be ok as is. > >> And removing avfilter_all_channel_layouts in >> d5e5c6862bbc834d5a036a3fa053a7569d84f928 (which also didn't have a >> legitimate outside user) didn't seem to break anything either. > > That function and others are mentioned as added in APIChanges yet their > removal is not. Sounds like it was handled poorly... > The whole formats API was scheduled to be made private in b74a1da49db5ebed51aceae6cacc2329288a92c1 in May 2012. It was removed in Libav in 1961e46c15c23a041f8d8614a25388a3ee9eff63 (less than a month after its deprecation...) which was merged into FFmpeg in 5916bc46581230c68c946c0b4733cce381eddcbd in June 2012. It was the merge commit that removed avfilter_all_channel_layouts (which is something that Libav never had). None of these three commits added any entry to APIChanges for their removal which was handled poorly; but d5e5c6862bbc834d5a036a3fa053a7569d84f928 was not (it would be wrong to add an APIChanges entry for something that hasn't been public API for years). >> Btw: 88d80cb97528d52dac3178cf5393d6095eca6200 broke ABI for x64, because >> older versions of libavformat exchange a PutBitContext with libavcodec >> via avpriv_align_put_bits and avpriv_copy_bits. So we can't really make >> a 4.4 release. > > That commit could be reverted in the release/4.4 branch. But yeah, it > should have not been committed until those two functions were removed, > since they tie PutBitContext to the ABI. That will break ABI for those people who use a libavformat version >= 88d80cb97528d52dac3178cf5393d6095eca6200 and older than the commits that removed PutBitContext from the ABI. Granted, not a release, but nevertheless. (Of course this problem would not even exist if we disallowed using libraries from different commits together.) > A crappy situation overall, but it should not prevent us from making one > last release before the bump. The amount of additions to the libraries > is considerable, and the first release post bump will be missing a lot > of old API, so adoption could take a bit, and something newer than 4.3 > should be readily available long before that. ___ 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 1/2] avfilter/transform: Stop exporting internal functions
On 2/25/2021 11:44 AM, Andreas Rheinhardt wrote: James Almer: On 2/24/2021 9:31 PM, Andreas Rheinhardt wrote: James Almer: On 2/24/2021 11:22 AM, Andreas Rheinhardt wrote: avfilter_transform, avfilter_(add|sub|mult)_matrix are not part of the public API (transform.h is not a public header), yet they are currently exported because of their name. This commit changes this: avfilter_transform is renamed to ff_affine_transform; the other functions are just removed as they have never been used at all. The symbols are exported and have been in four releases so far for this soname. If we plan on making a 4.4 release before the bump, it may be a good idea if we keep the symbols around for the sake of not affecting the ABI, so I'm inclined towards just wrapping them in a LIBAVFILTER_VERSION_MAJOR < 8 check like we do when we remove avpriv ones. And why? There was never a legitimate outside user of these functions. Because it's still exported. But ok, since nobody seems to think it's worth bothering with, this patch should be ok as is. And removing avfilter_all_channel_layouts in d5e5c6862bbc834d5a036a3fa053a7569d84f928 (which also didn't have a legitimate outside user) didn't seem to break anything either. That function and others are mentioned as added in APIChanges yet their removal is not. Sounds like it was handled poorly... The whole formats API was scheduled to be made private in b74a1da49db5ebed51aceae6cacc2329288a92c1 in May 2012. It was removed in Libav in 1961e46c15c23a041f8d8614a25388a3ee9eff63 (less than a month after its deprecation...) which was merged into FFmpeg in 5916bc46581230c68c946c0b4733cce381eddcbd in June 2012. It was the merge commit that removed avfilter_all_channel_layouts (which is something that Libav never had). None of these three commits added any entry to APIChanges for their removal which was handled poorly; but d5e5c6862bbc834d5a036a3fa053a7569d84f928 was not (it would be wrong to add an APIChanges entry for something that hasn't been public API for years). Btw: 88d80cb97528d52dac3178cf5393d6095eca6200 broke ABI for x64, because older versions of libavformat exchange a PutBitContext with libavcodec via avpriv_align_put_bits and avpriv_copy_bits. So we can't really make a 4.4 release. That commit could be reverted in the release/4.4 branch. But yeah, it should have not been committed until those two functions were removed, since they tie PutBitContext to the ABI. That will break ABI for those people who use a libavformat version >= 88d80cb97528d52dac3178cf5393d6095eca6200 and older than the commits that removed PutBitContext from the ABI. Granted, not a release, but nevertheless. Indeed. People, or rather distros, will want to drop 4.4 libraries on top of 4.3 ones without recompiling or relinking every software that depends on libav*. It's much more valuable to keep compatibility between the two releases than between intermediary commits after 88d80cb975 and 4.4. Like i said, the situation is crappy and has no single perfect solution, but has one being clearly better than the other. (Of course this problem would not even exist if we disallowed using libraries from different commits together.) A crappy situation overall, but it should not prevent us from making one last release before the bump. The amount of additions to the libraries is considerable, and the first release post bump will be missing a lot of old API, so adoption could take a bit, and something newer than 4.3 should be readily available long before that. ___ 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 1/2] avfilter/transform: Stop exporting internal functions
James Almer: > On 2/25/2021 11:44 AM, Andreas Rheinhardt wrote: >> James Almer: >>> On 2/24/2021 9:31 PM, Andreas Rheinhardt wrote: James Almer: > On 2/24/2021 11:22 AM, Andreas Rheinhardt wrote: >> avfilter_transform, avfilter_(add|sub|mult)_matrix are not part of >> the >> public API (transform.h is not a public header), yet they are >> currently >> exported because of their name. This commit changes this: >> avfilter_transform is renamed to ff_affine_transform; the other >> functions are just removed as they have never been used at all. > > The symbols are exported and have been in four releases so far for > this > soname. If we plan on making a 4.4 release before the bump, it may > be a > good idea if we keep the symbols around for the sake of not affecting > the ABI, so I'm inclined towards just wrapping them in a > LIBAVFILTER_VERSION_MAJOR < 8 check like we do when we remove avpriv > ones. > And why? There was never a legitimate outside user of these functions. >>> >>> Because it's still exported. But ok, since nobody seems to think it's >>> worth bothering with, this patch should be ok as is. >>> And removing avfilter_all_channel_layouts in d5e5c6862bbc834d5a036a3fa053a7569d84f928 (which also didn't have a legitimate outside user) didn't seem to break anything either. >>> >>> That function and others are mentioned as added in APIChanges yet their >>> removal is not. Sounds like it was handled poorly... >>> >> >> The whole formats API was scheduled to be made private in >> b74a1da49db5ebed51aceae6cacc2329288a92c1 in May 2012. It was removed in >> Libav in 1961e46c15c23a041f8d8614a25388a3ee9eff63 (less than a month >> after its deprecation...) which was merged into FFmpeg in >> 5916bc46581230c68c946c0b4733cce381eddcbd in June 2012. It was the merge >> commit that removed avfilter_all_channel_layouts (which is something >> that Libav never had). None of these three commits added any entry to >> APIChanges for their removal which was handled poorly; but >> d5e5c6862bbc834d5a036a3fa053a7569d84f928 was not (it would be wrong to >> add an APIChanges entry for something that hasn't been public API for >> years). >> Btw: 88d80cb97528d52dac3178cf5393d6095eca6200 broke ABI for x64, because older versions of libavformat exchange a PutBitContext with libavcodec via avpriv_align_put_bits and avpriv_copy_bits. So we can't really make a 4.4 release. >>> >>> That commit could be reverted in the release/4.4 branch. But yeah, it >>> should have not been committed until those two functions were removed, >>> since they tie PutBitContext to the ABI. >> >> That will break ABI for those people who use a libavformat version >= >> 88d80cb97528d52dac3178cf5393d6095eca6200 and older than the commits that >> removed PutBitContext from the ABI. Granted, not a release, but >> nevertheless. > > Indeed. People, or rather distros, will want to drop 4.4 libraries on > top of 4.3 ones without recompiling or relinking every software that > depends on libav*. It's much more valuable to keep compatibility between > the two releases than between intermediary commits after 88d80cb975 and > 4.4. We have only broken the avpriv API, not the public API. As long as distros compile all libraries from the same snapshot, they will be fine either way. So the "every software that depends on libav*" point is moot. > Like i said, the situation is crappy and has no single perfect solution, > but has one being clearly better than the other. > But this does not mean that I disagree with you here. >> (Of course this problem would not even exist if we disallowed using >> libraries from different commits together.) >> >>> A crappy situation overall, but it should not prevent us from making one >>> last release before the bump. The amount of additions to the libraries >>> is considerable, and the first release post bump will be missing a lot >>> of old API, so adoption could take a bit, and something newer than 4.3 >>> should be readily available long before that. ___ 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 v7 8/8] libavfilter/vf_deinterlace_qsv: enabling d3d11va support, added mfxhdlpair
> -Original Message- > From: ffmpeg-devel On Behalf Of > Artem Galin > Sent: Thursday, February 25, 2021 12:34 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH v7 8/8] libavfilter/vf_deinterlace_qsv: > enabling d3d11va support, added mfxhdlpair > > On Wed, 24 Feb 2021 at 17:50, Soft Works wrote: > > > > > > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > > > Artem Galin > > > Sent: Tuesday, November 3, 2020 7:46 PM > > > To: ffmpeg-devel@ffmpeg.org > > > Cc: Artem Galin > > > Subject: [FFmpeg-devel] [PATCH v7 8/8] libavfilter/vf_deinterlace_qsv: > > > enabling d3d11va support, added mfxhdlpair > > > > > > Adding DX11 relevant device type checks and adjusting callback with > > proper > > > MediaSDK pair type support. > > > > > > > Hi Artem, > > > > I have a few more notes regarding the patch: > > > > The switch to using mfxhdlpair will cause a regression in case of > > VAAPI/OpenCL Interop. In hwcontext_opencl.cs, function > > opencl_map_from_qsv, you need to cast the MemId to mfxHDLPair for > > getting the surface id. > > > > OpenCL interop on Windows is a whole different story, but it's not a > > small thing like the above, so you better handle that at a later time. > > It's not a regression anyway because this functionality doesn't exist > > yet (for D3D11). > > > > At the same time, that's another reason for NOT changing the default > > to > > D3D11 > > because somebody using QSV<=>OpenCL interop would see his commands > > failing when you change the default to D3D11. > > > > I don't know what others here are thinking (because nobody says > > anything), but IMO, a patch that doesn't switch the default impl would > > have less impact and probably better chances to get merged. > > > > Kind regards, > > softworkz > > > > > Hi Softworkz, > > D3D11VA works with more variety of HW configurations and there is no DX9 > drop in the patch. Feel free to send your version of the patch with interop > fix. Hi Artem, " there is no DX9 drop in the patch" > sure, D3D9 is not dropped, but you are changing the default to D3D11, which brings a lot of differences. Command lines that are working today won't work anymore - and not just for a single reason. There's a bunch of cases as I had already laid out earlier. The missing OpenCL+D3D11 interop is just an additional bullet to that list. In addition to that, there are at least two bugs in your v7 patch as I've outlined above. Kind regards, Softworkz ___ 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 4/4] avcodec/avcodec: Add missing deprecation to AVCodecParser.next
The whole old next API has been deprecated in commit
7e8eba2d8755962d9dca5eade57bf8f591a73c0c, yet deprecating the next
pointer has been forgotten (the next pointers of other structures are
below the public API delimiter, but such a delimiter doesn't exist for
AVCodecParser).
Signed-off-by: Andreas Rheinhardt
---
Thanks for the hint. I don't know how I could have overlooked that.
libavcodec/avcodec.h | 3 +++
libavcodec/parsers.c | 2 ++
2 files changed, 5 insertions(+)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 5df6a8aedc..b0cb91f555 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3512,7 +3512,10 @@ typedef struct AVCodecParser {
const uint8_t *buf, int buf_size);
void (*parser_close)(AVCodecParserContext *s);
int (*split)(AVCodecContext *avctx, const uint8_t *buf, int buf_size);
+#if FF_API_NEXT
+attribute_deprecated
struct AVCodecParser *next;
+#endif
} AVCodecParser;
/**
diff --git a/libavcodec/parsers.c b/libavcodec/parsers.c
index f8cfa1cde9..3d944f5222 100644
--- a/libavcodec/parsers.c
+++ b/libavcodec/parsers.c
@@ -79,6 +79,7 @@ extern AVCodecParser ff_xma_parser;
#include "libavcodec/parser_list.c"
#if FF_API_NEXT
+FF_DISABLE_DEPRECATION_WARNINGS
static AVOnce av_parser_next_init = AV_ONCE_INIT;
static void av_parser_init_next(void)
@@ -106,6 +107,7 @@ void av_register_codec_parser(AVCodecParser *parser)
{
ff_thread_once(&av_parser_next_init, av_parser_init_next);
}
+FF_ENABLE_DEPRECATION_WARNINGS
#endif
const AVCodecParser *av_parser_iterate(void **opaque)
--
2.27.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 v2 4/4] avcodec/avcodec: Add missing deprecation to AVCodecParser.next
On 2/25/2021 1:27 PM, Andreas Rheinhardt wrote:
The whole old next API has been deprecated in commit
7e8eba2d8755962d9dca5eade57bf8f591a73c0c, yet deprecating the next
pointer has been forgotten (the next pointers of other structures are
below the public API delimiter, but such a delimiter doesn't exist for
AVCodecParser).
Signed-off-by: Andreas Rheinhardt
---
Thanks for the hint. I don't know how I could have overlooked that.
libavcodec/avcodec.h | 3 +++
libavcodec/parsers.c | 2 ++
2 files changed, 5 insertions(+)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 5df6a8aedc..b0cb91f555 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3512,7 +3512,10 @@ typedef struct AVCodecParser {
const uint8_t *buf, int buf_size);
void (*parser_close)(AVCodecParserContext *s);
int (*split)(AVCodecContext *avctx, const uint8_t *buf, int buf_size);
+#if FF_API_NEXT
+attribute_deprecated
Add the missing four spaces indentation.
LGTM with that change.
struct AVCodecParser *next;
+#endif
} AVCodecParser;
/**
diff --git a/libavcodec/parsers.c b/libavcodec/parsers.c
index f8cfa1cde9..3d944f5222 100644
--- a/libavcodec/parsers.c
+++ b/libavcodec/parsers.c
@@ -79,6 +79,7 @@ extern AVCodecParser ff_xma_parser;
#include "libavcodec/parser_list.c"
#if FF_API_NEXT
+FF_DISABLE_DEPRECATION_WARNINGS
static AVOnce av_parser_next_init = AV_ONCE_INIT;
static void av_parser_init_next(void)
@@ -106,6 +107,7 @@ void av_register_codec_parser(AVCodecParser *parser)
{
ff_thread_once(&av_parser_next_init, av_parser_init_next);
}
+FF_ENABLE_DEPRECATION_WARNINGS
#endif
const AVCodecParser *av_parser_iterate(void **opaque)
___
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/lavfutils.h: Don't include avformat.h
Only lavfutils.c needs avformat.h, not lavfutils.h. Signed-off-by: Andreas Rheinhardt --- libavfilter/lavfutils.c | 1 + libavfilter/lavfutils.h | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/libavfilter/lavfutils.c b/libavfilter/lavfutils.c index f8f8415c80..34051ee61d 100644 --- a/libavfilter/lavfutils.c +++ b/libavfilter/lavfutils.c @@ -19,6 +19,7 @@ */ #include "libavutil/imgutils.h" +#include "libavformat/avformat.h" #include "lavfutils.h" int ff_load_image(uint8_t *data[4], int linesize[4], diff --git a/libavfilter/lavfutils.h b/libavfilter/lavfutils.h index 2d5308f79c..96738cead1 100644 --- a/libavfilter/lavfutils.h +++ b/libavfilter/lavfutils.h @@ -24,7 +24,8 @@ #ifndef AVFILTER_LAVFUTILS_H #define AVFILTER_LAVFUTILS_H -#include "libavformat/avformat.h" +#include +#include "libavutil/pixfmt.h" /** * Load image from filename and put the resulting image in data. -- 2.27.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 3/2] doc/encoders: Add documentation for the GIF encoder
On 21/02/2021 21:02, Moritz Barsnick wrote:
>> +@item global_palette @var{integer}
>> +Writes a palette to the global GIF header whee feasible.
> ^ where
>
Fixed and pushed the set (+1 other small fix).
- 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] avformat/avlanguage: Remove long disabled av_convert_lang_to
1582e306a47977b09fddb029b999f99eb03cd485 slated it for removal with
libavformat major version 58, but it was never removed.
Signed-off-by: Andreas Rheinhardt
---
libavformat/avlanguage.c | 7 ---
libavformat/avlanguage.h | 7 ---
2 files changed, 14 deletions(-)
diff --git a/libavformat/avlanguage.c b/libavformat/avlanguage.c
index f5d2ddf304..c36893c999 100644
--- a/libavformat/avlanguage.c
+++ b/libavformat/avlanguage.c
@@ -763,10 +763,3 @@ const char *ff_convert_lang_to(const char *lang, enum
AVLangCodespace target_cod
return NULL;
}
-
-#if LIBAVFORMAT_VERSION_MAJOR < 58
-const char *av_convert_lang_to(const char *lang, enum AVLangCodespace
target_codespace)
-{
-return ff_convert_lang_to(lang, target_codespace);
-}
-#endif
diff --git a/libavformat/avlanguage.h b/libavformat/avlanguage.h
index 1d72dcb3cb..1901e78407 100644
--- a/libavformat/avlanguage.h
+++ b/libavformat/avlanguage.h
@@ -21,9 +21,6 @@
#ifndef AVFORMAT_AVLANGUAGE_H
#define AVFORMAT_AVLANGUAGE_H
-#include "libavutil/attributes.h"
-#include "libavformat/version.h"
-
/**
* Known language codespaces
*/
@@ -38,9 +35,5 @@ enum AVLangCodespace {
* @return NULL if the provided lang is null or invalid.
*/
const char *ff_convert_lang_to(const char *lang, enum AVLangCodespace
target_codespace);
-#if LIBAVFORMAT_VERSION_MAJOR < 58
-attribute_deprecated
-const char *av_convert_lang_to(const char *lang, enum AVLangCodespace
target_codespace);
-#endif
#endif /* AVFORMAT_AVLANGUAGE_H */
--
2.27.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/avlanguage: Remove long disabled av_convert_lang_to
On Thu, Feb 25, 2021 at 6:33 PM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
> 1582e306a47977b09fddb029b999f99eb03cd485 slated it for removal with
>
typo, 'slated'.
probably ok
libavformat major version 58, but it was never removed.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/avlanguage.c | 7 ---
> libavformat/avlanguage.h | 7 ---
> 2 files changed, 14 deletions(-)
>
> diff --git a/libavformat/avlanguage.c b/libavformat/avlanguage.c
> index f5d2ddf304..c36893c999 100644
> --- a/libavformat/avlanguage.c
> +++ b/libavformat/avlanguage.c
> @@ -763,10 +763,3 @@ const char *ff_convert_lang_to(const char *lang, enum
> AVLangCodespace target_cod
>
> return NULL;
> }
> -
> -#if LIBAVFORMAT_VERSION_MAJOR < 58
> -const char *av_convert_lang_to(const char *lang, enum AVLangCodespace
> target_codespace)
> -{
> -return ff_convert_lang_to(lang, target_codespace);
> -}
> -#endif
> diff --git a/libavformat/avlanguage.h b/libavformat/avlanguage.h
> index 1d72dcb3cb..1901e78407 100644
> --- a/libavformat/avlanguage.h
> +++ b/libavformat/avlanguage.h
> @@ -21,9 +21,6 @@
> #ifndef AVFORMAT_AVLANGUAGE_H
> #define AVFORMAT_AVLANGUAGE_H
>
> -#include "libavutil/attributes.h"
> -#include "libavformat/version.h"
> -
> /**
> * Known language codespaces
> */
> @@ -38,9 +35,5 @@ enum AVLangCodespace {
> * @return NULL if the provided lang is null or invalid.
> */
> const char *ff_convert_lang_to(const char *lang, enum AVLangCodespace
> target_codespace);
> -#if LIBAVFORMAT_VERSION_MAJOR < 58
> -attribute_deprecated
> -const char *av_convert_lang_to(const char *lang, enum AVLangCodespace
> target_codespace);
> -#endif
>
> #endif /* AVFORMAT_AVLANGUAGE_H */
> --
> 2.27.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] Proposal of two projects for GSoC
> -Original Message- > From: ffmpeg-devel On Behalf Of > Artem Galin > Sent: Thursday, February 25, 2021 12:31 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] Proposal of two projects for GSoC > > On Wed, 24 Feb 2021 at 17:01, Soft Works wrote: > > > > > > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > > > Artem Galin > > > Sent: Wednesday, February 24, 2021 4:40 PM > > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org> > > > Subject: [FFmpeg-devel] Proposal of two projects for GSoC > > > > > > > > > > > > > Please find the proposal for the following two projects for GSoC > > > this > > year. > > > > > > > > > > > Title: oneAPI Video Processing Library (oneVPL) for CPU & GPU > > > hardware accelleration (https://www.oneapi.com/) > > > > > > Description: Add support for oneVPL > > > > > > > Hi Artem, > > > > I hope your doing fine! Your v7 patch for D3D11 QSV is now mostly > > identical to my original code (except defaulting to D3D11), and I'm > > pretty glad about that outcome. Probably meanwhile you came to > > understand why I didn't want to submit the code myself, but I hadn't > > expected that even Intel is being ignored here for so long :-( > > > > That being said, I have two questions regarding oneVPL: > > > > 1. From all the docs I've read, it was always about limitations of oneVPL > >In relation to MediaSDK. Is there a single thing which oneVPL can do > >that can't be done with MediaSDK? > > > > 2. Will MediaSDK be discontinued, renamed or continued to coexist with > >oneVPL? > > > > Thanks and kind regards, > > softworkz > > > > > Hi Softworkz, > > Proposal is forward looking. Stay tuned for more details about oneVPL. Hi Artem, Besides details, what benefits does it provide? And > 2. Will MediaSDK be discontinued, renamed or continued to coexist with > >oneVPL? Thanks, softworkz ___ 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 V2 1/7] libavdevice/v4l2.c: fix build warning for [-Wformat-truncation=]
On 2/24/2021 10:38 PM, Guo, Yejun wrote:
Here is the warning message:
src/libavdevice/v4l2.c: In function ‘v4l2_get_device_list’:
src/libavdevice/v4l2.c:1054:58: warning: ‘%s’ directive output may be truncated
writing up to 255 bytes into a region of size 251 [-Wformat-truncation=]
snprintf(device_name, sizeof(device_name), "/dev/%s", entry->d_name);
^~
src/libavdevice/v4l2.c:1054:9: note: ‘snprintf’ output between 6 and 261 bytes
into a destination of size 256
snprintf(device_name, sizeof(device_name), "/dev/%s", entry->d_name);
^~~~
Signed-off-by: Guo, Yejun
---
libavdevice/v4l2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c
index 365bacd771..e11d10d20e 100644
--- a/libavdevice/v4l2.c
+++ b/libavdevice/v4l2.c
@@ -1046,7 +1046,7 @@ static int v4l2_get_device_list(AVFormatContext *ctx,
AVDeviceInfoList *device_l
return ret;
}
while ((entry = readdir(dir))) {
-char device_name[256];
+char device_name[512];
Is there a portable path max constant that would be better for cases
like this, rather than just picking another arbitrary buffer size?
if (!v4l2_is_v4l_dev(entry->d_name))
continue;
___
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/lavfutils.h: Don't include avformat.h
On 2/25/2021 1:35 PM, Andreas Rheinhardt wrote: Only lavfutils.c needs avformat.h, not lavfutils.h. Signed-off-by: Andreas Rheinhardt --- libavfilter/lavfutils.c | 1 + libavfilter/lavfutils.h | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/libavfilter/lavfutils.c b/libavfilter/lavfutils.c index f8f8415c80..34051ee61d 100644 --- a/libavfilter/lavfutils.c +++ b/libavfilter/lavfutils.c @@ -19,6 +19,7 @@ */ #include "libavutil/imgutils.h" +#include "libavformat/avformat.h" #include "lavfutils.h" int ff_load_image(uint8_t *data[4], int linesize[4], diff --git a/libavfilter/lavfutils.h b/libavfilter/lavfutils.h index 2d5308f79c..96738cead1 100644 --- a/libavfilter/lavfutils.h +++ b/libavfilter/lavfutils.h @@ -24,7 +24,8 @@ #ifndef AVFILTER_LAVFUTILS_H #define AVFILTER_LAVFUTILS_H -#include "libavformat/avformat.h" +#include +#include "libavutil/pixfmt.h" Ok if make checkheaders passes. /** * Load image from filename and put the resulting image in data. ___ 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] avcodec/dxtory: Fix undefined shift with negative linesize
On Mon, Feb 22, 2021 at 05:56:31PM +0100, Paul B Mahol wrote: > lgtm will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato 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] [PATCH v7 3/8] libavutil/hwcontext_qsv: enabling d3d11va usage by default, add usage child_device_type argument
> -Original Message- > From: ffmpeg-devel On Behalf Of > Artem Galin > Sent: Tuesday, November 3, 2020 7:46 PM > To: ffmpeg-devel@ffmpeg.org > Cc: Artem Galin > Subject: [FFmpeg-devel] [PATCH v7 3/8] libavutil/hwcontext_qsv: enabling > d3d11va usage by default, add usage child_device_type argument > > Makes selection of d3d11va device type by default and over DirectX 9, which > might break users with older drivers/systems. > DCH driver with Gen6th support should be still fine. > > Decode, encode, transcode have been validated. > > child_device_type option is responsible for d3d11va/dxva2 device selection > > Usage examples: > > DirectX 11 > -init_hw_device qsv:hw,child_device_type=d3d11va > > DirectX 9 is still supported but requires explicit selection -init_hw_device > qsv:hw,child_device_type=dxva2 > Hi Artem, Could you please show a complete command line, demonstrating how to use a D3D9/DXVA2 hardware context with your patch? Something like qsv decoder, scale_qsv and qsv encoder... Thanks, softworkz ___ 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] avcodec/options: deprecate avcodec_get_frame_class()
AVFrame hasn't been a struct defined in libavcodec for a decade now, when
it was moved to libavutil.
Found-by: mkver
Signed-off-by: James Almer
---
libavcodec/avcodec.h | 8
libavcodec/options.c | 2 ++
libavcodec/version.h | 3 +++
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index ddca770cc4..f1380e0c4c 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2770,13 +2770,13 @@ int avcodec_get_context_defaults3(AVCodecContext *s,
const AVCodec *codec);
*/
const AVClass *avcodec_get_class(void);
+#if FF_API_GET_FRAME_CLASS
/**
- * Get the AVClass for AVFrame. It can be used in combination with
- * AV_OPT_SEARCH_FAKE_OBJ for examining options.
- *
- * @see av_opt_find().
+ * @deprecated This function should not be used.
*/
+attribute_deprecated
const AVClass *avcodec_get_frame_class(void);
+#endif
/**
* Get the AVClass for AVSubtitleRect. It can be used in combination with
diff --git a/libavcodec/options.c b/libavcodec/options.c
index ff16e2cbfd..6e904b61d8 100644
--- a/libavcodec/options.c
+++ b/libavcodec/options.c
@@ -312,6 +312,7 @@ const AVClass *avcodec_get_class(void)
return &av_codec_context_class;
}
+#if FF_API_GET_FRAME_CLASS
#define FOFFSET(x) offsetof(AVFrame,x)
static const AVOption frame_options[]={
@@ -338,6 +339,7 @@ const AVClass *avcodec_get_frame_class(void)
{
return &av_frame_class;
}
+#endif
#define SROFFSET(x) offsetof(AVSubtitleRect,x)
diff --git a/libavcodec/version.h b/libavcodec/version.h
index e5a5ec8abc..2962d94df2 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -150,5 +150,8 @@
#ifndef FF_API_DEBUG_MV
#define FF_API_DEBUG_MV (LIBAVCODEC_VERSION_MAJOR < 60)
#endif
+#ifndef FF_API_GET_FRAME_CLASS
+#define FF_API_GET_FRAME_CLASS (LIBAVCODEC_VERSION_MAJOR < 60)
+#endif
#endif /* AVCODEC_VERSION_H */
--
2.30.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".
Re: [FFmpeg-devel] [PATCH] avformat/vividas: Use signed n in read_sb_block()
On Wed, Feb 24, 2021 at 03:23:40PM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2021-02-15 21:31:23)
> > Fixes: OOM
> > Fixes:
> > 27780/clusterfuzz-testcase-minimized-ffmpeg_dem_VIVIDAS_fuzzer-5097985075314688
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavformat/vividas.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavformat/vividas.c b/libavformat/vividas.c
> > index d745770dc4..b172a48b29 100644
> > --- a/libavformat/vividas.c
> > +++ b/libavformat/vividas.c
> > @@ -235,7 +235,7 @@ static uint8_t *read_sb_block(AVIOContext *src,
> > unsigned *size,
> > uint8_t *buf;
> > uint8_t ibuf[8], sbuf[8];
> > uint32_t k2;
> > -unsigned n;
> > +int n;
> >
>
> Why would that be better, when it's assigned a uint32_t?
one (maybe not the only one) issue is
if (avio_read(src, buf+8, n) < n) {
avio_read() returns int and has a int size
so this will not work at all with a unsigned int, not only will it not read
more than INT_MAX it also when it fails with an error fail to treat it as
an error
do you prefer a diferent solution ?
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
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] [PATCH 1/3] avformat/wavenc: Fix leak and segfault on reallocation error
Andreas Rheinhardt:
> Up until now, the wav muxer used a reallocation of the form ptr =
> av_realloc(ptr, size); that leaks upon error. Furthermore, if a
> failed reallocation happened when writing the trailer, a segfault
> would occur due to avio_write(NULL, size) because the muxer only
> prints an error message upon allocation error, but does not return
> the error.
>
> Moreover setting the pointer to the buffer to NULL on error seems to
> be done on purpose in order to record that an error has occured so that
> outputting the peak values is no longer attempted. This behaviour has
> been retained by simply disabling whether peak data should be written
> if an error occurs.
>
> Finally, the reallocation is now done once per peak block and not once
> per peak block per channel; it is also done with av_fast_realloc and not
> with a linear size increase.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/wavenc.c | 53
> 1 file changed, 29 insertions(+), 24 deletions(-)
>
> diff --git a/libavformat/wavenc.c b/libavformat/wavenc.c
> index 1027f107ee..9ef72f6e1c 100644
> --- a/libavformat/wavenc.c
> +++ b/libavformat/wavenc.c
> @@ -50,8 +50,6 @@
> #define RF64_NEVER 0
> #define RF64_ALWAYS 1
>
> -#define PEAK_BUFFER_SIZE 1024
> -
> typedef enum {
> PEAK_OFF = 0,
> PEAK_ON,
> @@ -72,8 +70,9 @@ typedef struct WAVMuxContext {
> int64_t maxpts;
> int16_t *peak_maxpos, *peak_maxneg;
> uint32_t peak_num_frames;
> -uint32_t peak_outbuf_size;
> +unsigned peak_outbuf_size;
> uint32_t peak_outbuf_bytes;
> +unsigned size_increment;
> uint8_t *peak_output;
> int last_duration;
> int write_bext;
> @@ -172,15 +171,15 @@ static av_cold int peak_init_writer(AVFormatContext *s)
> "Writing 16 bit peak for 8 bit audio does not make sense\n");
> return AVERROR(EINVAL);
> }
> +if (par->channels > INT_MAX / (wav->peak_bps * wav->peak_ppv))
> +return AVERROR(ERANGE);
> +wav->size_increment = par->channels * wav->peak_bps * wav->peak_ppv;
>
> wav->peak_maxpos = av_mallocz_array(par->channels,
> sizeof(*wav->peak_maxpos));
> wav->peak_maxneg = av_mallocz_array(par->channels,
> sizeof(*wav->peak_maxneg));
> -wav->peak_output = av_malloc(PEAK_BUFFER_SIZE);
> -if (!wav->peak_maxpos || !wav->peak_maxneg || !wav->peak_output)
> +if (!wav->peak_maxpos || !wav->peak_maxneg)
> goto nomem;
>
> -wav->peak_outbuf_size = PEAK_BUFFER_SIZE;
> -
> return 0;
>
> nomem:
> @@ -188,14 +187,24 @@ nomem:
> return AVERROR(ENOMEM);
> }
>
> -static void peak_write_frame(AVFormatContext *s)
> +static int peak_write_frame(AVFormatContext *s)
> {
> WAVMuxContext *wav = s->priv_data;
> AVCodecParameters *par = s->streams[0]->codecpar;
> +unsigned new_size = wav->peak_outbuf_bytes + wav->size_increment;
> +uint8_t *tmp;
> int c;
>
> -if (!wav->peak_output)
> -return;
> +if (new_size > INT_MAX) {
> +wav->write_peak = PEAK_OFF;
> +return AVERROR(ERANGE);
> +}
> +tmp = av_fast_realloc(wav->peak_output, &wav->peak_outbuf_size,
> new_size);
> +if (!tmp) {
> +wav->write_peak = PEAK_OFF;
> +return AVERROR(ENOMEM);
> +}
> +wav->peak_output = tmp;
>
> for (c = 0; c < par->channels; c++) {
> wav->peak_maxneg[c] = -wav->peak_maxneg[c];
> @@ -209,17 +218,6 @@ static void peak_write_frame(AVFormatContext *s)
> wav->peak_maxpos[c] =
> FFMAX(wav->peak_maxpos[c], wav->peak_maxneg[c]);
>
> -if (wav->peak_outbuf_size - wav->peak_outbuf_bytes <
> -wav->peak_format * wav->peak_ppv) {
> -wav->peak_outbuf_size += PEAK_BUFFER_SIZE;
> -wav->peak_output = av_realloc(wav->peak_output,
> - wav->peak_outbuf_size);
> -if (!wav->peak_output) {
> -av_log(s, AV_LOG_ERROR, "No memory for peak data\n");
> -return;
> -}
> -}
> -
> if (wav->peak_format == PEAK_FORMAT_UINT8) {
> wav->peak_output[wav->peak_outbuf_bytes++] =
> wav->peak_maxpos[c];
> @@ -241,6 +239,8 @@ static void peak_write_frame(AVFormatContext *s)
> wav->peak_maxneg[c] = 0;
> }
> wav->peak_num_frames++;
> +
> +return 0;
> }
>
> static int peak_write_chunk(AVFormatContext *s)
> @@ -254,8 +254,11 @@ static int peak_write_chunk(AVFormatContext *s)
> char timestamp[28];
>
> /* Peak frame of incomplete block at end */
> -if (wav->peak_block_pos)
> -peak_write_frame(s);
> +if (wav->peak_block_pos) {
> +int ret = peak_write_frame(s);
> +if (ret < 0)
> +return ret;
> +}
>
> memset(timestamp, 0, sizeof(timestamp));
> if (!(s->flags & AVFMT_FLAG_BITEXACT)) {
> @@ -386,7 +389,9 @@ static int wav_wri
Re: [FFmpeg-devel] [PATCH] avformat/vividas: Use signed n in read_sb_block()
Michael Niedermayer:
> On Wed, Feb 24, 2021 at 03:23:40PM +0100, Anton Khirnov wrote:
>> Quoting Michael Niedermayer (2021-02-15 21:31:23)
>>> Fixes: OOM
>>> Fixes:
>>> 27780/clusterfuzz-testcase-minimized-ffmpeg_dem_VIVIDAS_fuzzer-5097985075314688
>>>
>>> Found-by: continuous fuzzing process
>>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>>> Signed-off-by: Michael Niedermayer
>>> ---
>>> libavformat/vividas.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavformat/vividas.c b/libavformat/vividas.c
>>> index d745770dc4..b172a48b29 100644
>>> --- a/libavformat/vividas.c
>>> +++ b/libavformat/vividas.c
>>> @@ -235,7 +235,7 @@ static uint8_t *read_sb_block(AVIOContext *src,
>>> unsigned *size,
>>> uint8_t *buf;
>>> uint8_t ibuf[8], sbuf[8];
>>> uint32_t k2;
>>> -unsigned n;
>>> +int n;
>>>
>>
>> Why would that be better, when it's assigned a uint32_t?
>
> one (maybe not the only one) issue is
> if (avio_read(src, buf+8, n) < n) {
>
> avio_read() returns int and has a int size
> so this will not work at all with a unsigned int, not only will it not read
> more than INT_MAX it also when it fails with an error fail to treat it as
> an error
>
> do you prefer a diferent solution ?
>
ffio_read_size? Or just use != instead of INT_MAX
before the call?
- 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] [PATCH] avformat/matroskadec: Add webm file extension
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/matroskadec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index 75f72d330c..3879a54af5 100644
> --- a/libavformat/matroskadec.c
> +++ b/libavformat/matroskadec.c
> @@ -4193,7 +4193,7 @@ static const AVClass webm_dash_class = {
> AVInputFormat ff_matroska_demuxer = {
> .name = "matroska,webm",
> .long_name = NULL_IF_CONFIG_SMALL("Matroska / WebM"),
> -.extensions = "mkv,mk3d,mka,mks",
> +.extensions = "mkv,mk3d,mka,mks,webm",
> .priv_data_size = sizeof(MatroskaDemuxContext),
> .read_probe = matroska_probe,
> .read_header= matroska_read_header,
>
Forgot about this one. Will apply it soon.
- 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".
[FFmpeg-devel] [PATCH] lavu/tx: WIP add x86 assembly
This commit adds sse3 and avx assembly optimizations for 4-point and
8-point transforms only.
The code to recombine them into higher-level transforms is non-functional
currently, so it's not included here. This is just to get some feedback
on possible optimizations.
The 4-point assembly is based on this structure:
https://gist.github.com/cyanreg/665b9c79cbe51df9296a969257f2a16c
The 8-point assembly is based on this structure:
https://gist.github.com/cyanreg/bbf25c8a8dfb910ed3b9ae7663983ca6
They're implemented as macros as they're pasted a few times in
the recombination code.
All code here is faster than both our own current assembly (by around 40%)
and FFTW3 (by around 10% to 40%).
The 8-point core assembly is barely 20 instructions! That's 1 less
than our current code, and saves on a lot of shuffles!
It's 40% faster than FFTW!
The 4-point core assembly is 10 instructions, which is 1 more than
our current code, however it doesn't require any external memory to
load from (a sign mask), which it trades for a shufps (faster),
and also it requires an additional temporary storage register
to reduce latency.
I'll collect the suggestions and implement them when I'm ready
to post the full power-of-two assembly.
>From ad5016d90bc9d7432e31d44011fe2621934de5cb Mon Sep 17 00:00:00 2001
From: Lynne
Date: Fri, 26 Feb 2021 05:47:20 +0100
Subject: [PATCH] lavu/tx: WIP add x86 assembly
This commit adds sse3 and avx assembly optimizations for 4-point and
8-point transforms only.
The code to recombine them into higher-level transforms is non-functional
currently, so it's not included here. This is just to get some feedback
on possible optimizations.
The 4-point assembly is based on this structure:
https://gist.github.com/cyanreg/665b9c79cbe51df9296a969257f2a16c
The 8-point assembly is based on this structure:
https://gist.github.com/cyanreg/bbf25c8a8dfb910ed3b9ae7663983ca6
They're implemented as macros as they're pasted a few times in
the recombination code.
All code here is faster than both our own current assembly (by around 40%)
and FFTW3 (by around 10% to 40%).
The 8-point core assembly is barely 20 instructions! That's 1 less
than our current code, and saves on a lot of shuffles!
It's 40% faster than FFTW!
The 4-point core assembly is 10 instructions, which is 1 more than
our current code, however it doesn't require any external memory to
load from (a sign mask), which it trades for a shufps (faster),
and also it requires an additional temporary storage register
to reduce latency.
I'll collect the suggestions and implement them when I'm ready
to post the full power-of-two assembly.
---
libavutil/tx.c| 2 +
libavutil/tx_priv.h | 2 +
libavutil/x86/Makefile| 2 +
libavutil/x86/tx_float.asm| 171 ++
libavutil/x86/tx_float_init.c | 66 +
5 files changed, 243 insertions(+)
create mode 100644 libavutil/x86/tx_float.asm
create mode 100644 libavutil/x86/tx_float_init.c
diff --git a/libavutil/tx.c b/libavutil/tx.c
index 4a5ec6975f..c0ae4b42ca 100644
--- a/libavutil/tx.c
+++ b/libavutil/tx.c
@@ -169,6 +169,8 @@ av_cold int av_tx_init(AVTXContext **ctx, av_tx_fn *tx, enum AVTXType type,
case AV_TX_FLOAT_MDCT:
if ((err = ff_tx_init_mdct_fft_float(s, tx, type, inv, len, scale, flags)))
goto fail;
+if (ARCH_X86)
+ff_tx_init_float_x86(s, tx);
break;
case AV_TX_DOUBLE_FFT:
case AV_TX_DOUBLE_MDCT:
diff --git a/libavutil/tx_priv.h b/libavutil/tx_priv.h
index e9fba02a35..b5c1cdd8c6 100644
--- a/libavutil/tx_priv.h
+++ b/libavutil/tx_priv.h
@@ -158,4 +158,6 @@ typedef struct CosTabsInitOnce {
AVOnce control;
} CosTabsInitOnce;
+void ff_tx_init_float_x86(AVTXContext *s, av_tx_fn *tx);
+
#endif /* AVUTIL_TX_PRIV_H */
diff --git a/libavutil/x86/Makefile b/libavutil/x86/Makefile
index 5f5242b5bd..d747c37049 100644
--- a/libavutil/x86/Makefile
+++ b/libavutil/x86/Makefile
@@ -3,6 +3,7 @@ OBJS += x86/cpu.o \
x86/float_dsp_init.o\
x86/imgutils_init.o \
x86/lls_init.o \
+x86/tx_float_init.o \
OBJS-$(CONFIG_PIXELUTILS) += x86/pixelutils_init.o \
@@ -14,5 +15,6 @@ X86ASM-OBJS += x86/cpuid.o \
x86/float_dsp.o\
x86/imgutils.o \
x86/lls.o \
+ x86/tx_float.o \
X86ASM-OBJS-$(CONFIG_PIXELUTILS) += x86/pixelutils.o\
diff --git a/libavutil/x86/tx_float.asm b/libavutil/x86/tx_float.asm
ne
[FFmpeg-devel] [PATCH 1/2] aea: make demuxer probing actually work and set title info
Someone forgot to add `i` to the loop.
Also, the format has a 16-char title that we don't currently
check.
Bytestream info from:
https://github.com/dcherednik/atracdenc/blob/master/src/aea.cpp
Patch attached
>From b72c6ead223b393a3a117bd85d41832b2edbb504 Mon Sep 17 00:00:00 2001
From: Lynne
Date: Fri, 26 Feb 2021 06:23:22 +0100
Subject: [PATCH 1/2] aea: make demuxer probing actually work and set title
info
Someone forgot to add `i` to the loop.
Also, the format has a 16-char title that we don't currently
check.
Bytestream info from:
https://github.com/dcherednik/atracdenc/blob/master/src/aea.cpp
---
libavformat/aea.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/libavformat/aea.c b/libavformat/aea.c
index bdeed64254..7d85840f67 100644
--- a/libavformat/aea.c
+++ b/libavformat/aea.c
@@ -46,10 +46,10 @@ static int aea_read_probe(const AVProbeData *p)
*/
for (i = 2048; i + 211 < p->buf_size; i+= 212) {
int bsm_s, bsm_e, inb_s, inb_e;
-bsm_s = p->buf[0];
-inb_s = p->buf[1];
-inb_e = p->buf[210];
-bsm_e = p->buf[211];
+bsm_s = p->buf[i + 0];
+inb_s = p->buf[i + 1];
+inb_e = p->buf[i + 210];
+bsm_e = p->buf[i + 211];
if (bsm_s != bsm_e || inb_s != inb_e)
return 0;
@@ -61,12 +61,19 @@ static int aea_read_probe(const AVProbeData *p)
static int aea_read_header(AVFormatContext *s)
{
+char title[17] = { 0 };
AVStream *st = avformat_new_stream(s, NULL);
if (!st)
return AVERROR(ENOMEM);
+avio_skip(s->pb, 4);
+
+avio_read(s->pb, title, 16);
+if (strlen(title) && strlen(title) < 16)
+av_dict_set(&s->metadata, "title", title, 0);
+
/* Parse the amount of channels and skip to pos 2048(0x800) */
-avio_skip(s->pb, 264);
+avio_skip(s->pb, 244);
st->codecpar->channels = avio_r8(s->pb);
avio_skip(s->pb, 1783);
@@ -90,11 +97,8 @@ static int aea_read_header(AVFormatContext *s)
static int aea_read_packet(AVFormatContext *s, AVPacket *pkt)
{
int ret = av_get_packet(s->pb, pkt, s->streams[0]->codecpar->block_align);
-
-pkt->stream_index = 0;
-if (ret <= 0)
-return AVERROR(EIO);
-
+if (ret >= 0)
+pkt->stream_index = 0;
return ret;
}
--
2.30.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] [PATCH 2/2] aeaenc: add an aea muxer
This allows to (re)mux Sony ATRAC1 files.
Patch attached
>From fd2c5b70c202fd11d48efc5ed4366093351eb0de Mon Sep 17 00:00:00 2001
From: Lynne
Date: Fri, 26 Feb 2021 06:25:41 +0100
Subject: [PATCH 2/2] aeaenc: add an aea muxer
This allows to (re)mux Sony ATRAC1 files.
---
libavformat/Makefile | 1 +
libavformat/aeaenc.c | 107 +++
libavformat/allformats.c | 1 +
3 files changed, 109 insertions(+)
create mode 100644 libavformat/aeaenc.c
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 10fee749c8..aced6edba5 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -80,6 +80,7 @@ OBJS-$(CONFIG_ADTS_MUXER)+= adtsenc.o apetag.o img2.o \
OBJS-$(CONFIG_ADX_DEMUXER) += adxdec.o
OBJS-$(CONFIG_ADX_MUXER) += rawenc.o
OBJS-$(CONFIG_AEA_DEMUXER) += aea.o pcm.o
+OBJS-$(CONFIG_AEA_MUXER) += aeaenc.o rawenc.o
OBJS-$(CONFIG_AFC_DEMUXER) += afc.o
OBJS-$(CONFIG_AIFF_DEMUXER) += aiffdec.o pcm.o isom.o \
mov_chan.o replaygain.o
diff --git a/libavformat/aeaenc.c b/libavformat/aeaenc.c
new file mode 100644
index 00..c25adc15d4
--- /dev/null
+++ b/libavformat/aeaenc.c
@@ -0,0 +1,107 @@
+/*
+ * 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/intreadwrite.h"
+#include "avformat.h"
+#include "rawenc.h"
+
+#define AT1_SU_SIZE 212
+
+typedef struct AEAEncContext {
+uint32_t frame_cnt;
+} AEAEncContext;
+
+static int aea_write_header(AVFormatContext *s)
+{
+AVDictionaryEntry *dtmp;
+AVCodecParameters *par = s->streams[0]->codecpar;
+AVIOContext *pb = s->pb;
+
+if (par->channels != 1 && par->channels != 2) {
+av_log(s, AV_LOG_ERROR, "Unsupported number of channels %i!\n", par->channels);
+return AVERROR(EINVAL);
+}
+
+if (par->sample_rate != 44100) {
+av_log(s, AV_LOG_ERROR, "Unsupported samplerate %i!\n", par->sample_rate);
+return AVERROR(EINVAL);
+}
+
+if (par->block_align != (AT1_SU_SIZE * par->channels)) {
+av_log(s, AV_LOG_ERROR, "Unsupported block align %i!\n", par->block_align);
+return AVERROR(EINVAL);
+}
+
+avio_wl32(pb, 0x800); // magic
+
+dtmp = av_dict_get(s->metadata, "title", NULL, 0);
+if (dtmp) {
+int len = FFMIN(strlen(dtmp->value), 15);
+avio_write(pb, dtmp->value, len);
+for (int i = 0; i < (16 - len); i++)
+avio_w8(pb, 0);
+} else {
+avio_wl64(pb, 0);
+avio_wl64(pb, 0);
+}
+
+avio_skip(pb, 240); // not needed
+
+avio_wl32(pb, 0); // #frames field overwritten when closing
+avio_w8 (pb, par->channels); // Number of channels
+
+/* Skip to 2048 */
+avio_skip(pb, 2048 - avio_tell(pb));
+
+return 0;
+}
+
+static int aea_write_packet(AVFormatContext *s, AVPacket *pkt)
+{
+AEAEncContext *ctx = s->priv_data;
+ctx->frame_cnt++;
+return ff_raw_write_packet(s, pkt);
+}
+
+static int aea_write_trailer(AVFormatContext *s)
+{
+AVIOContext *pb = s->pb;
+AEAEncContext *ctx = s->priv_data;
+
+if ((pb->seekable & AVIO_SEEKABLE_NORMAL) && ctx->frame_cnt > 1) {
+int64_t end = avio_tell(pb);
+
+avio_seek(pb, 260, SEEK_SET);
+avio_wl32(pb, ctx->frame_cnt);
+avio_seek(pb, end, SEEK_SET);
+}
+
+return 0;
+}
+
+AVOutputFormat ff_aea_muxer = {
+.name = "aea",
+.long_name = NULL_IF_CONFIG_SMALL("MD STUDIO audio"),
+.priv_data_size= sizeof(AEAEncContext),
+.extensions= "aea",
+.audio_codec = AV_CODEC_ID_ATRAC1,
+.write_header = aea_write_header,
+.write_packet = aea_write_packet,
+.write_trailer = aea_write_trailer,
+.flags = AVFMT_NOTIMESTAMPS,
+};
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index f837ddabc8..6501a5d2f5 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -44,6 +44,7 @@ extern AVOutputFormat ff_adts_muxer;
extern AVInputFormat ff_adx_demuxer;
extern AVOutputFormat ff_adx_muxer;
extern AVInputFormat ff_aea_demuxer;
+extern AVOutputFormat ff_aea_muxer
Re: [FFmpeg-devel] [PATCH 2/4] avcodec/xpm: Minor speed increase for mod_strcspn() {string, reject}==0
On February 24, 2021 05:56:17 AM Moritz Barsnick wrote:
> On Mon, Feb 22, 2021 at 20:32:14 -0800, Jose Da Silva wrote:
> > -for (i = 0; string && string[i]; i++) {
> > +if (string == 0)
>
> "if (!string)" is the preferred style for pointers.
Works for me. Updated patches reworked for today's date.
> But I don't see the advantage - isn't the loop interrupted immediately
> anyway if string == NULL? (Same for the other loop you changed.)
Yes, ...but... let's now look inside the for loop with string != NULL
If we read 100 character before reaching reject, that is 100 extra tests.
Technically speaking, we could remove this test since the function is
private to xpmdec.c, but if the function is useful enough to be globally
used (instead of private here), it is worth having the extra check as a
safety-check. one_test vs no_test is not a crushing impact on speed, but it
is still better than loopin and testing "i" times.
The other loop is inside the first loop, so this effect is multiplied.
If we attempt to reject, say... ",}" then we test "reject!=0" three times
If we need to search through ten characters in string, that makes it about
thirty tests. Take this outside the for loop, and that is now ten tests.
It is a minor speed improvement, and I thought it was worth resolving these
low hanging fruit first. I wanted to avoid too much churn which is likely
when submitting a larger set of patches :-)
In terms of churn - Hopefully the "if (!string)" was the only catch here.
> Inside the loops, the additional checks for validity of "string"
> seem redundant either way, though:
>
> while ( string && string[i] && string[i] != '\n' )
...well, if we are already paying attention to string&reject in the outside
loops, we might as well go ahead and fix the same/similar things here too.
These are also minor speed improvements, and two fewer if/then/else in the
compiled binary sense too.
Joe
___
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 1/4] avcodec/xpm: Minor speed increase to function hex_char_to_number()
Search for 0 to 9 first as this is 10/16th of possible choices we want,
then search for lowercase 6/16th, or uppercase 6/16th possible choices.
This gives us a minor speed increase similar to xbmdec.c nibble search.
Some modern compilers complain if using "unsigned" without using "int".
Signed-off-by: Jose Da Silva
---
libavcodec/xpmdec.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/libavcodec/xpmdec.c b/libavcodec/xpmdec.c
index 922dfc0f67..5aab46c52d 100644
--- a/libavcodec/xpmdec.c
+++ b/libavcodec/xpmdec.c
@@ -191,17 +191,19 @@ static const ColorEntry color_table[] = {
{ "YellowGreen", 0xFF9ACD32 }
};
-static unsigned hex_char_to_number(uint8_t x)
+static unsigned int hex_char_to_number(uint8_t x)
{
-if (x >= 'a' && x <= 'f')
-x -= 'a' - 10;
-else if (x >= 'A' && x <= 'F')
-x -= 'A' - 10;
-else if (x >= '0' && x <= '9')
-x -= '0';
-else
-x = 0;
-return x;
+int ret = 0;
+
+if (x <= '9') {
+if (x >= '0')
+ret = x - '0';
+} else if (x >= 'a') {
+if (x <= 'f')
+ret = x - ('a' - 10);
+} else if (x >= 'A' && x <= 'F')
+ret = x - ('A' - 10);
+return ret;
}
/*
--
2.30.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] [PATCH 2/4] avcodec/xpm: Minor speed increase for mod_strcspn() {string, reject}==0
Test string==0 once before looping. This avoids testing 'string!=0'
i times inside the for i loop, (plus more checks for comments).
Test reject==0 once before looping. This avoids testing 'reject!=0'
i*[strlen(reject)+1] times inside the for j loop string.
Signed-off-by: Jose Da Silva
---
libavcodec/xpmdec.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/libavcodec/xpmdec.c b/libavcodec/xpmdec.c
index 5aab46c52d..66a9a8008c 100644
--- a/libavcodec/xpmdec.c
+++ b/libavcodec/xpmdec.c
@@ -213,22 +213,24 @@ static size_t mod_strcspn(const char *string, const char
*reject)
{
int i, j;
-for (i = 0; string && string[i]; i++) {
+if (!string)
+return 0;
+for (i = 0; string[i]; i++) {
if (string[i] == '/' && string[i+1] == '*') {
i += 2;
-while ( string && string[i] && (string[i] != '*' || string[i+1] !=
'/') )
+while (string[i] && (string[i] != '*' || string[i+1] != '/'))
i++;
i++;
} else if (string[i] == '/' && string[i+1] == '/') {
i += 2;
-while ( string && string[i] && string[i] != '\n' )
+while (string[i] && string[i] != '\n')
i++;
-} else {
-for (j = 0; reject && reject[j]; j++) {
+} else if (reject) {
+for (j = 0; reject[j]; j++) {
if (string[i] == reject[j])
break;
}
-if (reject && reject[j])
+if (reject[j])
break;
}
}
--
2.30.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] [PATCH 3/4] avcodec/xpm: Minor speed increase for mod_strcspn() use reject pointer
Incrementing pointer *pr once is faster than computing reject[j] for each
time we need it.
Signed-off-by: Jose Da Silva
---
libavcodec/xpmdec.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/libavcodec/xpmdec.c b/libavcodec/xpmdec.c
index 66a9a8008c..7b3d3a7ff5 100644
--- a/libavcodec/xpmdec.c
+++ b/libavcodec/xpmdec.c
@@ -211,7 +211,8 @@ static unsigned int hex_char_to_number(uint8_t x)
*/
static size_t mod_strcspn(const char *string, const char *reject)
{
-int i, j;
+const char *pr;
+int i;
if (!string)
return 0;
@@ -226,11 +227,8 @@ static size_t mod_strcspn(const char *string, const char
*reject)
while (string[i] && string[i] != '\n')
i++;
} else if (reject) {
-for (j = 0; reject[j]; j++) {
-if (string[i] == reject[j])
-break;
-}
-if (reject[j])
+for (pr = reject; *pr && *pr != string[i]; pr++);
+if (*pr)
break;
}
}
--
2.30.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] [PATCH 4/4] avcodec/xpm: Minor speed increase for mod_strcspn() use string pointer
Incrementing pointer *ps once is faster than computing string[i] for each
time we need it.
Bug fix: For the remote possibility of a crazy-long comment section that
overflows int, this fix can also return a value larger than sizeof(int).
Signed-off-by: Jose Da Silva
---
libavcodec/xpmdec.c | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/libavcodec/xpmdec.c b/libavcodec/xpmdec.c
index 7b3d3a7ff5..c7fbd38fe5 100644
--- a/libavcodec/xpmdec.c
+++ b/libavcodec/xpmdec.c
@@ -211,28 +211,27 @@ static unsigned int hex_char_to_number(uint8_t x)
*/
static size_t mod_strcspn(const char *string, const char *reject)
{
-const char *pr;
-int i;
+const char *ps, *pr;
if (!string)
return 0;
-for (i = 0; string[i]; i++) {
-if (string[i] == '/' && string[i+1] == '*') {
-i += 2;
-while (string[i] && (string[i] != '*' || string[i+1] != '/'))
-i++;
-i++;
-} else if (string[i] == '/' && string[i+1] == '/') {
-i += 2;
-while (string[i] && string[i] != '\n')
-i++;
+for (ps = string; *ps; ps++) {
+if (*ps == '/' && *(ps+1) == '*') {
+ps += 2;
+while (*ps && (*ps != '*' || *(ps+1) != '/'))
+ps++;
+ps++;
+} else if (*ps == '/' && *(ps+1) == '/') {
+ps += 2;
+while (*ps && *ps != '\n')
+ps++;
} else if (reject) {
-for (pr = reject; *pr && *pr != string[i]; pr++);
+for (pr = reject; *pr && *pr != *ps; pr++);
if (*pr)
break;
}
}
-return i;
+return (ps - string);
}
static uint32_t color_string_to_rgba(const char *p, int len)
--
2.30.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".
Re: [FFmpeg-devel] [PATCH 2/2] aeaenc: add an aea muxer
Lynne:
> This allows to (re)mux Sony ATRAC1 files.
>
> Patch attached
>
> +#include "libavutil/intreadwrite.h"
> +#include "avformat.h"
> +#include "rawenc.h"
> +
> +#define AT1_SU_SIZE 212
> +
> +typedef struct AEAEncContext {
> +uint32_t frame_cnt;
> +} AEAEncContext;
> +
> +static int aea_write_header(AVFormatContext *s)
> +{
> +AVDictionaryEntry *dtmp;
> +AVCodecParameters *par = s->streams[0]->codecpar;
> +AVIOContext *pb = s->pb;
> +
> +if (par->channels != 1 && par->channels != 2) {
> +av_log(s, AV_LOG_ERROR, "Unsupported number of channels %i!\n",
> par->channels);
> +return AVERROR(EINVAL);
> +}
> +
> +if (par->sample_rate != 44100) {
> +av_log(s, AV_LOG_ERROR, "Unsupported samplerate %i!\n",
> par->sample_rate);
> +return AVERROR(EINVAL);
> +}
> +
> +if (par->block_align != (AT1_SU_SIZE * par->channels)) {
> +av_log(s, AV_LOG_ERROR, "Unsupported block align %i!\n",
> par->block_align);
> +return AVERROR(EINVAL);
> +}
> +
> +avio_wl32(pb, 0x800); // magic
> +
> +dtmp = av_dict_get(s->metadata, "title", NULL, 0);
> +if (dtmp) {
> +int len = FFMIN(strlen(dtmp->value), 15);
> +avio_write(pb, dtmp->value, len);
> +for (int i = 0; i < (16 - len); i++)
> +avio_w8(pb, 0);
> +} else {
> +avio_wl64(pb, 0);
> +avio_wl64(pb, 0);
> +}
How about
int len = 0;
...
if (dtmp) {
len = FFMIN
avio_write(pb, drmp->value, len);
}
ffio_fill(pb, 0, 16 - len);
> +
> +avio_skip(pb, 240); // not needed
> +
skip? For a muxer? There is a danger of producing nondeterministic
output here. Better add these 240 bytes to the ffio_fill I just suggested.
> +avio_wl32(pb, 0); // #frames field overwritten when closing
This could also be done by ffio_fill.
> +avio_w8 (pb, par->channels); // Number of channels
> +
> +/* Skip to 2048 */
> +avio_skip(pb, 2048 - avio_tell(pb));
Same problem as above. Best to just use ffio_fill(pb, 0, 2048 - 265).
> +
> +return 0;
> +}
> +
> +static int aea_write_packet(AVFormatContext *s, AVPacket *pkt)
> +{
> +AEAEncContext *ctx = s->priv_data;
> +ctx->frame_cnt++;
Unnecessary: The muxing code generically sets AVStream.nb_frames. You
can just use ff_raw_write_packet as your write_packet function and can
remove the whole context.
> +return ff_raw_write_packet(s, pkt);
> +}
> +
> +static int aea_write_trailer(AVFormatContext *s)
> +{
> +AVIOContext *pb = s->pb;
> +AEAEncContext *ctx = s->priv_data;
> +
> +if ((pb->seekable & AVIO_SEEKABLE_NORMAL) && ctx->frame_cnt > 1) {
> +int64_t end = avio_tell(pb);
> +
> +avio_seek(pb, 260, SEEK_SET);
> +avio_wl32(pb, ctx->frame_cnt);
> +avio_seek(pb, end, SEEK_SET);
> +}
> +
> +return 0;
> +}
> +
> +AVOutputFormat ff_aea_muxer = {
> +.name = "aea",
> +.long_name = NULL_IF_CONFIG_SMALL("MD STUDIO audio"),
> +.priv_data_size= sizeof(AEAEncContext),
> +.extensions= "aea",
> +.audio_codec = AV_CODEC_ID_ATRAC1,
> +.write_header = aea_write_header,
> +.write_packet = aea_write_packet,
> +.write_trailer = aea_write_trailer,
> +.flags = AVFMT_NOTIMESTAMPS,
> +};
___
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 1/2] aea: make demuxer probing actually work and set title info
Lynne:
> Someone forgot to add `i` to the loop.
> Also, the format has a 16-char title that we don't currently
> check.
>
> Bytestream info from:
> https://github.com/dcherednik/atracdenc/blob/master/src/aea.cpp
>
> Patch attached
>
> @@ -61,12 +61,19 @@ static int aea_read_probe(const AVProbeData *p)
>
> static int aea_read_header(AVFormatContext *s)
> {
> +char title[17] = { 0 };
> AVStream *st = avformat_new_stream(s, NULL);
> if (!st)
> return AVERROR(ENOMEM);
>
> +avio_skip(s->pb, 4);
> +
> +avio_read(s->pb, title, 16);
> +if (strlen(title) && strlen(title) < 16)
> +av_dict_set(&s->metadata, "title", title, 0);
> +
You are not checking that you actually read 16 bytes. Maybe use
ffio_read_len for that. If you do, you can modify the check to
if (title[0] && !title[15])
and you also don't need the extra byte in title and can also avoid
initializing it.
>
> @@ -90,11 +97,8 @@ static int aea_read_header(AVFormatContext *s)
> static int aea_read_packet(AVFormatContext *s, AVPacket *pkt)
> {
> int ret = av_get_packet(s->pb, pkt,
> s->streams[0]->codecpar->block_align);
> -
> -pkt->stream_index = 0;
> -if (ret <= 0)
> -return AVERROR(EIO);
> -
> +if (ret >= 0)
> +pkt->stream_index = 0;
The check is unnecessary.
> return ret;
> }
>
> --
___
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] Proposal of two projects for GSoC
On Thu, 2021-02-25 at 19:05 +0800, Steven Liu wrote: > Artem Galin 于2021年2月24日周三 下午11:46写道： > > > > Hello, > > > > > > > > Please find the proposal for the following two projects for GSoC this year. > > > > The FATE project had been proposed earlier already but I don't know why it > > didn't happen. > > > > I previously got the feedback from Thilo Borgmann and would be happy to get > > feedback from the community as well. > > > > > > > > " > > > > > > > > FATE tests for HW acceleration > > > > > > > > Description: FFmpeg's FATE regression test system do not include validation > > of hardware acceleration. This project is about to include these > > hardware-specific regression tests to the FATE system. Since this project > > requires access to corresponding hardware, it is not expected to cover the > > whole range of hardware accelerators there are but to initialize some > > useful tests for available hardware, most likely to include CPU > > acceleration on Intel or AMD at least. Access to other hardware can also be > > provided during the project, depending on the students requirements. > > > > > > > > Expected results: Implement tests for the different hardware decoding, > > encoding and transcoding capabilities there are. > > > > > > > > Prerequisites: Good C and Makefile coding skills, basic familiarity with > > Git. > > > > > > > > Qualification Task: TBD > > > > > > > > Mentor: Artem G (artem.galin [at] intel [dot] com) > > > > > > > > Backup Mentor: TBD > > > > > > > > " > > > > > > > > > > > > Title: oneAPI Video Processing Library (oneVPL) for CPU & GPU hardware > > accelleration (https://www.oneapi.com/) > > > > > > > > Description: Add support for oneVPL > > > > > > > > The oneAPI project is developing a common cross-platform API for video > > processing, including CPU and GPU hardware acceleration. > > > > > > > > At least Intel's MediaSDK (https://github.com/Intel-Media-SDK/MediaSDK < > > https://github.com/Intel-Media-SDK/MediaSDK>;), providing the currently used > > QSV API used for HW acceleration on Intel, will transition to implement the > > oneAPI API, called oneVPL (https://github.com/oneapi-src/oneVPL). > > > > > > > > Therefore, this project aims to get FFmpeg ready for this new API to ensure > > future availability of not only Intel's HW acceleration after the > > transition to oneVPL but also for possible other implementations of the > > oneAPI from other vendors. > > > > > > > > > > > > Expected results: Implement a oneVPL library wrapper into FFmpeg. > > > > Validate that media pipelines work with no regressions by supported feature > > set and performance. > > > > > > > > > > > > Prerequisites: Good C and Makefile coding skills, basic familiarity with > > Git. > > > > > > > > Qualification Task: TBD > > > > > > > > Mentor: Artem G (artem.galin [at] intel [dot] com) > > > > > > > > Backup Mentor: TBD > > > > > > > > > > > > " > > > > > > > > Thanks, > > > > Artem. > > ___ > > 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". > > Do you mean you want base on this patch: > http://ffmpeg.org/pipermail/ffmpeg-devel/2020-September/269905.html I refreshed the patches and prepared a new patchset since then. The new series will be sent out after the new oneVPL release. We are discussing internally if this is a good proposal for GSOC Thanks Haihao > ___ > 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 V2 6/7] libavformat/smoothstreamingenc.c: fix build warning for [-Wformat-truncation=]
> -Original Message-
> From: ffmpeg-devel On Behalf Of Reimar
> D?ffinger
> Sent: 2021年2月25日 16:22
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH V2 6/7]
> libavformat/smoothstreamingenc.c: fix build warning for
> [-Wformat-truncation=]
>
>
> > On 25 Feb 2021, at 07:38, Guo, Yejun wrote:
> > --- a/libavformat/smoothstreamingenc.c
> > +++ b/libavformat/smoothstreamingenc.c
> > @@ -501,7 +501,7 @@ static int ism_flush(AVFormatContext *s, int
> > final)
> >
> > for (i = 0; i < s->nb_streams; i++) {
> > OutputStream *os = &c->streams[i];
> > -char filename[1024], target_filename[1024],
> header_filename[1024], curr_dirname[1024];
> > +char filename[2048], target_filename[2048],
> > + header_filename[2048], curr_dirname[1024];
> > int64_t size;
> > int64_t start_ts, duration, moof_size;
> > if (!os->packets_written)
>
> IMO some of these allocations are getting a bit too large for the stack
> (multi-page stack allocations weaken security measures even if the large
> arrays
> themselves do not overflow).
> And no matter what size you put, there’s always a larger filename possible
> where it breaks, so it feels like just warning polishing with marginal real
> benefit.
> Why not use av_asprintf, then at least the problem is actually solved for
> real?
> I don’t see that this code is performance relevant, so the only reason to put
> these onto stack is being too lazy to do the memory management, which I
> think is a fairly weak argument.
>
thanks, and get the point that it is a possible security issue.
There's a max len for the filename, and so I use 'filename[1029] etc.' in V1
patch.
But I think the magic number 1029 is weird and so just changed to 2048 in V2.
There's no other reasons to choose 2048.
av_asprintf is a good choice, I'll look at it and send patches in V3.
___
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 v5 0/4] Initial implementation of TTML encoding/muxing
On Mon, Feb 22, 2021, 15:32 Jan Ekström wrote: > On Mon, Feb 22, 2021 at 3:19 PM Jan Ekström wrote: > > > > I've intentionally kept this initial version simple (no styling etc) to > focus > > on the basics. As this goes through review, additional features can be > added > > (I had initial PoC for styling implemented some time around previous > VDD), and > > there is another patch set in my queue which would then add support for > muxing > > TTML into MP4. > > > > Changes from the fourth version: > > - Switched from separate escaping modes back to a single > AV_ESCAPE_MODE_XML, > > with additional flags for single and double quote escaping for > attributes > > (Anton noted that the AV_ESCAPE_FLAG_XML prefix makes it all long > enough, > > so ATTR was left away from these). > > - Added the libavutil minor bump, which was forgotten so far. > > - ff_ass_split_override_codes calls are now checked for errors and a > warning > > or error is logged depending on whether it was an invalid input > error, > > and if AV_EF_EXPLODE was set. In case of invalid input and > AV_EF_EXPLODE, > > a malformed ASS dialog will cause the encoder to fail. By default it > will > > not, which matches the current behavior of all other subtitle > encoders, > > which do not test the return value of ff_ass_split_override_codes at > all, > > and thus just skip malformed parts of an ASS dialog. > > > > Thank you to Anton for giving the idea of the AV_EF_EXPLODE usage. > > - Documented that AV_EF_EXPLODE is now usable for subtitle encoders. > > For the record, if this seems unacceptable I can switch it to a > specifically named AVOption in the subtitle encoder. > > Either way is fine by me, the explode flag was just what was noted as > an alternative first. > > Jan > Ping for this set. Jan > ___ 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".
