Re: [FFmpeg-devel] [PATCH 00/26] Major library version bump
On Wed, Jan 18, 2023 at 06:23:43PM -0300, James Almer wrote: > On 1/18/2023 4:28 PM, Anton Khirnov wrote: > > Quoting James Almer (2023-01-16 14:38:14) > > > It's been a while since the last bump, so it's time to do some cleaning > > > and > > > remove deprecated APIs. This will also give us an "Open ABI season" in > > > which we > > > can do breaking changes (like changing public struct offsets, public enum > > > values, adding fields to structs that have their size tied to the ABI, > > > etc) for > > > a few weeks. > > > > Last time this open season lasted something like half a year and only > > ended when I arbitrarily said it did. > > > > So I'd suggest to decide right now how long will the instability period > > last (6 weeks should be enough for everybody) and write the end date at > > the top of doc/APIchanges. > > > > Another thing I'm not entirely happy about is versioning during the bump > > and instability. While the remove-then-bump approach does make bisection > > easier, it also creates commits that lie about their ABI version. > > Does it really matter? All the patches will be pushed at the same time, > meaning one git fetch will give you a stable state pre bump and the next > will be right after it. > I think it's a bit farfetched to expect someone to pick a random commit in > the middle of the bump and try to use the resulting compiled libraries with > some program that was linked to some earlier version libraries. > > > > > I wonder if we couldn't come up with a better soltion. One thing that > > comes to mind is setting the major version to 0 until the instability > > period ends. > > This could have several undesired effects, mainly for users looking at that > define and not really expecting such value (There are several projects > supporting more than one ffmpeg release and "MAJOR <= xx" checks are > commonplace). API/ABI is defined by major minor patchlevel these do have reasonable agreed upon meaning i think. I dont think code pushed to master should break the promise the verions make. If it breaks it, it should not be pushed. Not with VERY good reason, anything could have some rare exception if theres a very good reason for the expcetion ... A user or a script should always be able to checkout a version from master and its major:minor:patchlevel versions should work as one would expect I dont see why any exception is needed A new major API will start with a new major version and 0 in minor obviously now nothing at that time will depend on that major API version. And once some other libs or apps depend on the new major API they at the same time will require a minimum minor version and that minir version obviously will be after the instability period because you cant really depend on unstable API/ABI. So nothing would break from anything in that 0..X minor version range because nothing should depend on that and after X things are after the instability period. But we can still even in the instability period use the minor version for our own inter lib dependancies and handle that in a somewhat clean way by bumping minor when it is appropriate PS: iam not sure i fully understood the reason behind why versions should be set to "wrong" values during some period, so as always i might be missing something thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong. 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] [avcodec/amfenc: 10 bit support v2 2/3] avcodec/amfenc: Fixes the color information in the output.
On Wed, Sep 07, 2022 at 03:41:21PM +0200, OvchinnikovDmitrii wrote:
> From: Michael Fabian 'Xaymar' Dirks
>
>
> added 10 bit support for amf hevc.
>
> before:
>
> command - ffmpeg.exe -hide_banner -y -hwaccel d3d11va -hwaccel_output_format
> d3d11 -i test_10bit_file.mkv -an -c:v h264_amf res.dx11_hw_h264.mkv
> output - Format of input frames context (p010le) is not supported by AMF.
> command - ffmpeg.exe -hide_banner -y -hwaccel d3d11va -hwaccel_output_format
> d3d11 -i test_10bit_file -an -c:v hevc_amf res.dx11_hw_hevc.mkv
> output - Format of input frames context (p010le) is not supported by AMF.
>
> after:
>
> command - ffmpeg.exe -hide_banner -y -hwaccel d3d11va -hwaccel_output_format
> d3d11 -i test_10bit_file -an -c:v h264_amf res.dx11_hw_h264.mkv
> output - 8bit file
> command - ffmpeg.exe -hide_banner -y -hwaccel d3d11va -hwaccel_output_format
> d3d11 -i test_10bit_file -an -c:v hevc_amf res.dx11_hw_hevc.mkv
> output - 10bit file
>
> v2 - lost line returned in ff_amf_pix_fmts
>
> ---
> libavcodec/amfenc.c | 2 ++
> libavcodec/amfenc.h | 1 +
> libavcodec/amfenc_h264.c | 46 -
> libavcodec/amfenc_hevc.c | 55 +++-
> 4 files changed, 102 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
> index a033e1220e..efff9b5ae8 100644
> --- a/libavcodec/amfenc.c
> +++ b/libavcodec/amfenc.c
> @@ -60,6 +60,7 @@ const enum AVPixelFormat ff_amf_pix_fmts[] = {
> #if CONFIG_DXVA2
> AV_PIX_FMT_DXVA2_VLD,
> #endif
> + AV_PIX_FMT_P010,
> AV_PIX_FMT_NONE
mismatching indention
> };
>
> @@ -72,6 +73,7 @@ static const FormatMap format_map[] =
> {
> { AV_PIX_FMT_NONE, AMF_SURFACE_UNKNOWN },
> { AV_PIX_FMT_NV12, AMF_SURFACE_NV12 },
> +{ AV_PIX_FMT_P010, AMF_SURFACE_P010 },
> { AV_PIX_FMT_BGR0, AMF_SURFACE_BGRA },
> { AV_PIX_FMT_RGB0, AMF_SURFACE_RGBA },
> { AV_PIX_FMT_GRAY8, AMF_SURFACE_GRAY8 },
> diff --git a/libavcodec/amfenc.h b/libavcodec/amfenc.h
> index 1ab98d2f78..c5ee9d7e35 100644
> --- a/libavcodec/amfenc.h
> +++ b/libavcodec/amfenc.h
> @@ -21,6 +21,7 @@
>
> #include
>
> +#include
> #include
> #include
>
> diff --git a/libavcodec/amfenc_h264.c b/libavcodec/amfenc_h264.c
> index eaf7f974f3..7a0198e6a8 100644
> --- a/libavcodec/amfenc_h264.c
> +++ b/libavcodec/amfenc_h264.c
> @@ -138,6 +138,9 @@ static av_cold int amf_encode_init_h264(AVCodecContext
> *avctx)
> AMFRate framerate;
> AMFSize framesize =
> AMFConstructSize(avctx->width, avctx->height);
> int deblocking_filter = (avctx->flags &
> AV_CODEC_FLAG_LOOP_FILTER) ? 1 : 0;
> +amf_int64color_depth;
> +amf_int64color_profile;
> +enum AVPixelFormat pix_fmt;
>
> if (avctx->framerate.num > 0 && avctx->framerate.den > 0) {
> framerate = AMFConstructRate(avctx->framerate.num,
> avctx->framerate.den);
> @@ -195,10 +198,51 @@ static av_cold int amf_encode_init_h264(AVCodecContext
> *avctx)
> AMF_ASSIGN_PROPERTY_RATIO(res, ctx->encoder,
> AMF_VIDEO_ENCODER_ASPECT_RATIO, ratio);
> }
>
> -/// Color Range (Partial/TV/MPEG or Full/PC/JPEG)
> +// Color Metadata
> +/// Color Range (Support for older Drivers)
> if (avctx->color_range == AVCOL_RANGE_JPEG) {
> AMF_ASSIGN_PROPERTY_BOOL(res, ctx->encoder,
> AMF_VIDEO_ENCODER_FULL_RANGE_COLOR, 1);
> +} else {
> +AMF_ASSIGN_PROPERTY_BOOL(res, ctx->encoder,
> AMF_VIDEO_ENCODER_FULL_RANGE_COLOR, 0);
> +}
> +/// Color Space & Depth
> +pix_fmt = avctx->hw_frames_ctx ?
> ((AVHWFramesContext*)avctx->hw_frames_ctx->data)->sw_format
> +: avctx->pix_fmt;
> +color_depth = AMF_COLOR_BIT_DEPTH_8;
> +if (pix_fmt == AV_PIX_FMT_P010) {
> +color_depth = AMF_COLOR_BIT_DEPTH_10;
> +}
the surrounding code all used if A=X else A=Y and this does A=X if A=Y
later the same code is repeated and both parts split up
> +color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_UNKNOWN;
> +switch (avctx->colorspace) {
> +case AVCOL_SPC_SMPTE170M:
> +if (avctx->color_range == AVCOL_RANGE_JPEG) {
> +color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_FULL_601;
> +} else {
> +color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_601;
> +}
> +break;
> +case AVCOL_SPC_BT709:
> +if (avctx->color_range == AVCOL_RANGE_JPEG) {
> +color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_FULL_709;
> +} else {
> +color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_709;
> +}
> +break;
> +case AVCOL_SPC_BT2020_NCL:
> +case AVCOL_SPC_BT2020_CL:
> +if (avctx->color_range == AVCOL_RANGE_JPEG) {
> +
Re: [FFmpeg-devel] [PATCH 00/26] Major library version bump
Quoting James Almer (2023-01-19 13:18:28) > On 1/19/2023 4:26 AM, Anton Khirnov wrote: > > Quoting James Almer (2023-01-18 22:23:43) > >> On 1/18/2023 4:28 PM, Anton Khirnov wrote: > >>> Quoting James Almer (2023-01-16 14:38:14) > It's been a while since the last bump, so it's time to do some cleaning > and > remove deprecated APIs. This will also give us an "Open ABI season" in > which we > can do breaking changes (like changing public struct offsets, public enum > values, adding fields to structs that have their size tied to the ABI, > etc) for > a few weeks. > >>> > >>> Last time this open season lasted something like half a year and only > >>> ended when I arbitrarily said it did. > >>> > >>> So I'd suggest to decide right now how long will the instability period > >>> last (6 weeks should be enough for everybody) and write the end date at > >>> the top of doc/APIchanges. > >>> > >>> Another thing I'm not entirely happy about is versioning during the bump > >>> and instability. While the remove-then-bump approach does make bisection > >>> easier, it also creates commits that lie about their ABI version. > >> > >> Does it really matter? All the patches will be pushed at the same time, > >> meaning one git fetch will give you a stable state pre bump and the next > >> will be right after it. > >> I think it's a bit farfetched to expect someone to pick a random commit > >> in the middle of the bump and try to use the resulting compiled > >> libraries with some program that was linked to some earlier version > >> libraries. > > > > I agree that it's probably not a big practical problem, but it is ugly > > and goes against our claims of git master being stable. > > > >>> I wonder if we couldn't come up with a better soltion. One thing that > >>> comes to mind is setting the major version to 0 until the instability > >>> period ends. > >> > >> This could have several undesired effects, mainly for users looking at > >> that define and not really expecting such value (There are several > >> projects supporting more than one ffmpeg release and "MAJOR <= xx" > >> checks are commonplace). > > > > IMO users who don't expect such a value shouldn't be linking against > > unstable API/ABI anyway. We could also set the major version to > > something really big, like 999. We'll have to change deprecation macros, > > but that should be straightforward. > > > >> Also, if we are going to code the instability period in some form into > >> the codebase, might as well make it so it starts with the first removal > >> commit, or immediately before it, so what you described above is no > >> longer a concern. > > > > I'd rather say the two concerns merge into one, but it's not going away. > > There's currently very little user indication that API/ABI are unstable > > for several months. > > How about making minor == 0 mean unstable? Some projects like GCC do it > like this, for example. Said version would not guarantee anything at all > and should not be linked against. Then once the period ends after the > major bump, it's bumped to 1, and the usual "new API, minor bump" rule > kicks in. > This also means that any API addition that takes place during the > unstable period doesn't get it's own version, and they will all strictly > speaking be introduced by minor 1. We'd have to watch this carefully, many developers don't pay attention to major bumps or instability periods and just bump minor anyway. We should also print a warning in configure that tells the user their build is unstable. Otherwise I'm ok with this. > As for your concern about first removing then bumping meaning we're > lying about the ABI, the first commit in the set could maybe rollback > minor to 0, then apply the removals, and finally the major bump in the > last commit. It will that way be considered unstable for the whole thing. Works for me. -- Anton Khirnov ___ 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/vf_cropdetect: add ability to change limit/reset at runtime
>On 17/01/2023 19:11, Paul B Mahol wrote:
>> On 1/17/23, Jeffrey Chapuis wrote:
>>> I'm getting there, don't give up on me.
>>>
>>> Now 'limit_upscaled' become the variable used in filter_frame() and
>>> 'limit' is never change, unless by user
>>> We only have to update 'limit_upscaled' if 'limit' really changes.
>>
>> probably ok
>
>>-if (s->limit < 1.0)
>>-s->limit *= (1 << desc->comp[0].depth) - 1;
>>+s->bitdepth = desc->comp[0].depth;
>>+s->limit_upscaled = s->limit;
>>+if (s->limit_upscaled < 1.0)
>>+s->limit_upscaled *= (1 << s->bitdepth) - 1;
>
>Is it better like this? we avoid a double assignment.
>
>-if (s->limit < 1.0)
>-s->limit *= (1 << desc->comp[0].depth) - 1;
>+s->bitdepth = desc->comp[0].depth;
>+
>+if (s->limit_upscaled < 1.0)
>+s->limit_upscaled = s->limit * (1 << s->bitdepth) - 1;
>+else
>+s->limit_upscaled = s->limit;
>
>The full patch without this change is in the previous reply
>(https://ffmpeg.org/pipermail/ffmpeg-devel/2023-January/305806.html),
>let me know if there is other change to make with formatting/renaming.
>I really appreciate your patience with this patch.
Full patch attached without obvious errors from my previous proposal.From 361168539b5af3f237db9478ac6ccb40ff0c67a1 Mon Sep 17 00:00:00 2001
From: Ashyni
Date: Thu, 12 Jan 2023 17:36:34 +0100
Subject: [PATCH] avfilter/vf_cropdetect: add ability to change limit at
runtime
fix: https://trac.ffmpeg.org/ticket/9851
Signed-off-by: Ashyni
---
doc/filters.texi | 12 +
libavfilter/vf_cropdetect.c| 45 +---
tests/ref/fate/filter-metadata-cropdetect | 60 +++---
tests/ref/fate/filter-metadata-cropdetect1 | 14 ++---
tests/ref/fate/filter-metadata-cropdetect2 | 14 ++---
5 files changed, 95 insertions(+), 50 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index be70a2396..96965f406 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10587,6 +10587,18 @@ ffmpeg -flags2 +export_mvs -i file.mp4 -vf
cropdetect=mode=mvedges,metadata=mode
@end example
@end itemize
+@subsection Commands
+
+This filter supports the following commands:
+@table @option
+@item limit
+
+The command accepts the same syntax of the corresponding option.
+
+If the specified expression is not valid, it is kept at its current
+value.
+@end table
+
@anchor{cue}
@section cue
diff --git a/libavfilter/vf_cropdetect.c b/libavfilter/vf_cropdetect.c
index 7e985fb27..724047f86 100644
--- a/libavfilter/vf_cropdetect.c
+++ b/libavfilter/vf_cropdetect.c
@@ -39,6 +39,7 @@ typedef struct CropDetectContext {
const AVClass *class;
int x1, y1, x2, y2;
float limit;
+float limit_upscaled;
int round;
int skip;
int reset_count;
@@ -48,6 +49,7 @@ typedef struct CropDetectContext {
int mode;
int window_size;
int mv_threshold;
+int bitdepth;
float low, high;
uint8_t low_u8, high_u8;
uint8_t *filterbuf;
@@ -207,8 +209,12 @@ static int config_input(AVFilterLink *inlink)
av_image_fill_max_pixsteps(s->max_pixsteps, NULL, desc);
+s->bitdepth = desc->comp[0].depth;
+
if (s->limit < 1.0)
-s->limit *= (1 << desc->comp[0].depth) - 1;
+s->limit_upscaled = s->limit * ((1 << s->bitdepth) - 1);
+else
+s->limit_upscaled = s->limit;
s->x1 = inlink->w - 1;
s->y1 = inlink->h - 1;
@@ -243,7 +249,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*frame)
int w, h, x, y, shrink_by, i;
AVDictionary **metadata;
int outliers, last_y;
-int limit = lrint(s->limit);
+int limit_upscaled = lrint(s->limit_upscaled);
+char limit_str[22];
const int inw = inlink->w;
const int inh = inlink->h;
@@ -278,7 +285,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*frame)
#define FIND(DST, FROM, NOEND, INC, STEP0, STEP1, LEN) \
outliers = 0;\
for (last_y = y = FROM; NOEND; y = y INC) {\
-if (checkline(ctx, frame->data[0] + STEP0 * y, STEP1, LEN, bpp) >
limit) {\
+if (checkline(ctx, frame->data[0] + STEP0 * y, STEP1, LEN, bpp) >
limit_upscaled) {\
if (++outliers > s->max_outliers) { \
DST = last_y;\
break;\
@@ -423,21 +430,46 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*frame)
SET_META("lavfi.cropdetect.x", x);
SET_META("lavfi.cropdetect.y", y);
+snprintf(limit_str, sizeof(limit_str), "%f", s->limit);
+av_dict_set(metadata, "lavfi.cropdetect.limit", limit_str, 0);
+
av_log(ctx, AV_LOG_INFO,
- "x1:%d x2:%d y1:%d y2:%d w:%d h:%d x:%d y:%d pts:%"PRId64" t:%f
crop=%d:%d:%d:%d\n",
+ "x1:%d x2:%d y1:%d y2:%d w:%d h:%d x:%d y:%d pts:%"PRId64" t:%f
limit:%f crop=%d:%d:%d:%d\n",
s->x1, s->x2, s->y1, s->y2, w, h, x, y, frame->pts,
frame->pts ==
Re: [FFmpeg-devel] [PATCH 00/26] Major library version bump
On 1/19/2023 4:26 AM, Anton Khirnov wrote: Quoting James Almer (2023-01-18 22:23:43) On 1/18/2023 4:28 PM, Anton Khirnov wrote: Quoting James Almer (2023-01-16 14:38:14) It's been a while since the last bump, so it's time to do some cleaning and remove deprecated APIs. This will also give us an "Open ABI season" in which we can do breaking changes (like changing public struct offsets, public enum values, adding fields to structs that have their size tied to the ABI, etc) for a few weeks. Last time this open season lasted something like half a year and only ended when I arbitrarily said it did. So I'd suggest to decide right now how long will the instability period last (6 weeks should be enough for everybody) and write the end date at the top of doc/APIchanges. Another thing I'm not entirely happy about is versioning during the bump and instability. While the remove-then-bump approach does make bisection easier, it also creates commits that lie about their ABI version. Does it really matter? All the patches will be pushed at the same time, meaning one git fetch will give you a stable state pre bump and the next will be right after it. I think it's a bit farfetched to expect someone to pick a random commit in the middle of the bump and try to use the resulting compiled libraries with some program that was linked to some earlier version libraries. I agree that it's probably not a big practical problem, but it is ugly and goes against our claims of git master being stable. I wonder if we couldn't come up with a better soltion. One thing that comes to mind is setting the major version to 0 until the instability period ends. This could have several undesired effects, mainly for users looking at that define and not really expecting such value (There are several projects supporting more than one ffmpeg release and "MAJOR <= xx" checks are commonplace). IMO users who don't expect such a value shouldn't be linking against unstable API/ABI anyway. We could also set the major version to something really big, like 999. We'll have to change deprecation macros, but that should be straightforward. Also, if we are going to code the instability period in some form into the codebase, might as well make it so it starts with the first removal commit, or immediately before it, so what you described above is no longer a concern. I'd rather say the two concerns merge into one, but it's not going away. There's currently very little user indication that API/ABI are unstable for several months. How about making minor == 0 mean unstable? Some projects like GCC do it like this, for example. Said version would not guarantee anything at all and should not be linked against. Then once the period ends after the major bump, it's bumped to 1, and the usual "new API, minor bump" rule kicks in. This also means that any API addition that takes place during the unstable period doesn't get it's own version, and they will all strictly speaking be introduced by minor 1. As for your concern about first removing then bumping meaning we're lying about the ABI, the first commit in the set could maybe rollback minor to 0, then apply the removals, and finally the major bump in the last commit. It will that way be considered unstable for the whole thing. ___ 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/vf_cropdetect: add ability to change limit/reset at runtime
On 17/01/2023 19:11, Paul B Mahol wrote: > On 1/17/23, Jeffrey Chapuis wrote: >> I'm getting there, don't give up on me. >> >> Now 'limit_upscaled' become the variable used in filter_frame() and >> 'limit' is never change, unless by user >> We only have to update 'limit_upscaled' if 'limit' really changes. > > probably ok >-if (s->limit < 1.0) >-s->limit *= (1 << desc->comp[0].depth) - 1; >+s->bitdepth = desc->comp[0].depth; >+s->limit_upscaled = s->limit; >+if (s->limit_upscaled < 1.0) >+s->limit_upscaled *= (1 << s->bitdepth) - 1; Is it better like this? we avoid a double assignment. -if (s->limit < 1.0) -s->limit *= (1 << desc->comp[0].depth) - 1; +s->bitdepth = desc->comp[0].depth; + +if (s->limit_upscaled < 1.0) +s->limit_upscaled = s->limit * (1 << s->bitdepth) - 1; +else +s->limit_upscaled = s->limit; The full patch without this change is in the previous reply (https://ffmpeg.org/pipermail/ffmpeg-devel/2023-January/305806.html), let me know if there is other change to make with formatting/renaming. I really appreciate your patience with this patch. ___ 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] GSoC 2023
On Tue, Jan 17, 2023 at 11:22 PM Nuo Mi wrote: > > > On Mon, Jan 16, 2023 at 10:58 PM Jean-Baptiste Kempf > wrote: > >> On Mon, 16 Jan 2023, at 14:53, Nuo Mi wrote: >> > Seems too hurried for this time. Maybe next time >> >> I disagree: we can do (and should do) a small task for VVC dec in GSoC >> 2023, like a fringe feature, not from the mainline. >> > Hi jb, > Thank you for the suggestion. I love this idea. Let me prepare the > description. > > >> >> jb >> >> -- >> Jean-Baptiste Kempf - President >> +33 672 704 734 >> ___ >> 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". >> > Hi jb, Thilo, How about this? Description: VVC is the successor to the well-known codec HEVC. The whole video industry has high anticipation for VVC. The goal of the ffvvc project is to provide a VVC decoder for FFmpeg. We invite you to join us in improving ffvvc. Depending on your background, you will help add ALF/SAO/Predict assembly code or new features/tests for ffvvc. Expected results: 500+ lines of code merged into the ffvvc project. Prerequisites: Good C and Assembly code, basic familiarity with Git, and knowledge of codecs. Difficulty: Hard Qualification Task: Fix any issue on https://github.com/ffvvc/FFmpeg/issues or any patch merged by ffvvc. Mentor: Nuo Mi (nuomi2021 at gmail dot com) Duration: 350 hours Hi All, It's more than welcome if somebody can do the co-mentor. Please reply to this if you are interested. Thank you. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avfilter: add VA-API variants of the stack filters
From: Haihao Xiang
Include hstack_vaapi, vstack_vaapi and xstack_vaapi. They may accept
input streams with different sizes. libva2 (VA-API 1.0+) is required.
Example:
$ ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -i input.h265
-filter_complex
"[0:v][0:v]hstack_vaapi" -c:v h264_vaapi out.h264
$ ffmpeg \
-hwaccel vaapi -hwaccel_output_format vaapi -i input.h264 \
-hwaccel vaapi -hwaccel_output_format vaapi -i input.h264 \
-hwaccel vaapi -hwaccel_output_format vaapi -i input.h264 \
-hwaccel vaapi -hwaccel_output_format vaapi -i input.h264 \
-filter_complex
"[0:v][1:v][2:v][3:v]xstack_vaapi=inputs=4:fill=0x00:layout=0_0_1920x1080|w0_0_1920x1080|0_h0_1920x1080|w0_h0_1920x1080"
\
-c:v hevc_vaapi out.h265
Signed-off-by: Haihao Xiang
---
Changelog| 1 +
configure| 3 +
doc/filters.texi | 81 +
libavfilter/Makefile | 3 +
libavfilter/allfilters.c | 3 +
libavfilter/version.h| 2 +-
libavfilter/vf_stack_vaapi.c | 574 +++
7 files changed, 666 insertions(+), 1 deletion(-)
create mode 100644 libavfilter/vf_stack_vaapi.c
diff --git a/Changelog b/Changelog
index 5c01e8365e..a6c0a08433 100644
--- a/Changelog
+++ b/Changelog
@@ -29,6 +29,7 @@ version :
- corr video filter
- adrc audio filter
- afdelaysrc audio filter
+- hstack_vaapi, vstack_vaapi and xstack_vaapi filters
version 5.1:
diff --git a/configure b/configure
index 6e88c32223..a4620b1005 100755
--- a/configure
+++ b/configure
@@ -3765,6 +3765,9 @@ xfade_opencl_filter_deps="opencl"
yadif_cuda_filter_deps="ffnvcodec"
yadif_cuda_filter_deps_any="cuda_nvcc cuda_llvm"
yadif_videotoolbox_filter_deps="metal corevideo videotoolbox"
+hstack_vaapi_filter_deps="vaapi_1"
+vstack_vaapi_filter_deps="vaapi_1"
+xstack_vaapi_filter_deps="vaapi_1"
# examples
avio_list_dir_deps="avformat avutil"
diff --git a/doc/filters.texi b/doc/filters.texi
index be70a2396b..89c8420f7f 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -14915,6 +14915,7 @@ Set the scaling dimension: @code{2} for @code{hq2x},
@code{3} for
Default is @code{3}.
@end table
+@anchor{hstack}
@section hstack
Stack input videos horizontally.
@@ -24366,6 +24367,7 @@ Example:
ffmpeg -i ref.mpg -vf vmafmotion -f null -
@end example
+@anchor{vstack}
@section vstack
Stack input videos vertically.
@@ -24847,6 +24849,7 @@ minimum values, and @code{1} maximum values.
This filter supports all above options as @ref{commands}, excluding option
@code{inputs}.
+@anchor{xstack}
@section xstack
Stack video inputs into custom layout.
@@ -26663,6 +2,84 @@ tonemap_vaapi=format=p010:t=bt2020-10
@end example
@end itemize
+@section hstack_vaapi
+Stack input videos horizontally.
+
+This is the VA-API variant of the @ref{hstack} filter, each input stream may
+have different height, this filter will scale down/up each input stream while
+keeping the orignal aspect.
+
+It accepts the following options:
+
+@table @option
+@item inputs
+See @ref{hstack}.
+
+@item shortest
+See @ref{hstack}.
+
+@item height
+Set height of output. If set to 0, this filter will set height of output to
+height of the first input stream. Default value is 0.
+@end table
+
+@section vstack_vaapi
+Stack input videos vertically.
+
+This is the VA-API variant of the @ref{vstack} filter, each input stream may
+have different width, this filter will scale down/up each input stream while
+keeping the orignal aspect.
+
+It accepts the following options:
+
+@table @option
+@item inputs
+See @ref{vstack}.
+
+@item shortest
+See @ref{vstack}.
+
+@item width
+Set width of output. If set to 0, this filter will set width of output to
+width of the first input stream. Default value is 0.
+@end table
+
+@section xstack_vaapi
+Stack video inputs into custom layout.
+
+This is the VA-API variant of the @ref{xstack} filter, each input stream may
+have different size, this filter will scale down/up each input stream to the
+given output size, or the size of the first input stream.
+
+It accepts the following options:
+
+@table @option
+@item inputs
+See @ref{xstack}.
+
+@item shortest
+See @ref{xstack}.
+
+@item layout
+See @ref{xstack}.
+Moreover, this permits the user to supply output size for each input stream.
+@example
+xstack_vaapi=inputs=4:layout=0_0_1920x1080|0_h0_1920x1080|w0_0_1920x1080|w0_h0_1920x1080
+@end example
+
+@item grid
+See @ref{xstack}.
+
+@item grid_tile_size
+Set output size for each input stream when @option{grid} is set. If this option
+is not set, this filter will set output size by default to the size of the
+first input stream. For the syntax of this option, check the
+@ref{video size syntax,,"Video size" section in the ffmpeg-utils
manual,ffmpeg-utils}.
+
+@item fill
+See @ref{xstack}.
+@end table
+
@c man end VAAPI VIDEO FILTERS
@chapter Video Sources
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 211ff4daaa..a6f32b0e3e 100644
---
Re: [FFmpeg-devel] [PATCH] libavutil/log: Support for logging timestamps in the log
On 19/01/2023 00:20, Prakash wrote: The problem with int milliseconds is you lose the microseconds precision. Sometimes there are multiple log lines within the same millisecond. If you want to do performance profiling like comparing between assembler and C versions of a routine in my opinion there are better ways to do that than using log timestamps. But I also have nothing against adding more positions after the decimal point, if you prefer that. The usecase I see for log timestamps is more to find out whether a warning message appeared at the begin, middle, or end of the transcoding process. I can definitely move the timestamp as the first field of the log line. Let me fix the patch file. -Prakash. Regards, Tobias ___ 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".
