Re: [FFmpeg-devel] [PATCH] libavformat/vapoursynth: Update to API version 4, load library at runtime
Am 22.06.24 um 08:27 schrieb Stephen Hutchinson: On 6/21/24 9:37 PM, Stefan Oltmanns via ffmpeg-devel wrote: The current VapourSynth implementation is rarely used, as it links the VapourSynth library at build time, making the resulting build unable to run when VapourSynth is not installed. Therefore barely anyone compiles with VapourSynth activated. How many distros package VapourSynth yet don't enable it in FFmpeg vs. both not packaging it and not enabling it? VapourSynth not being available as a package in the distro's repository is a far more likely reason than linking is. I don't know the extact reason, but VapourSynth is not just a library like avisynth, but an application that uses Python, meaning a lot of dependencies. Additionally VapourSynth can nowadays be installed using pip, so no reason to package it for distros anymore. Switching to dynamic loading would absolutely make the experience on or building for Windows smoother, and would remove the need to rebuild FFmpeg when VapourSynth updates, outside of future API changes the demuxer would need to actively account for. Exactly I changed it, so that it loads the library at runtime when a VapourSynth script should be opened, just like AviSynth does. On Windows the DLL from VapourSynth is not installed in the system directory, but the location is stored in the Registry. Therefore I added some code to read that information from the registry. That function is in the wrong place. I thought that to, should it be in /compat as w32registry.h or something like that? But what exactly should it contain? I could make a function that would be used like get_w32_regsitry_str(HKEY_CURRENT_USER, L"SOFTWARE\\VapourSynth", L"VSScriptDLL"); That would return a utf8 string on success and NULL on failure But that would still contain 3 Windows-specific constants in the function call. Also is it useful to write the literals as utf-8 just for them to be converted to wchar again or should it just take WCHAR and return utf8? Or shoulds the entire function be located in /compat/vapoursynth/w32_vsscript_dll.h as "get_w32_vsscript_dll" or something similar? I copied the two needed header files directly in a vapoursynth.h, removing the need to install VapourSynth on the build machine (VapourSynth is also LGPL 2.1 or later, so no license issue). I updated the configure so that it checks for the ability to load libraries at runtime for VapourSynth, just like AviSynth and activate it if not disabled. Including local copies of the headers in compat/ wasn't acceptable for AviSynth (and were removed as soon as it was no longer necessary for there to be an OS distinction between what headers were being used), it's not going to be acceptable for this either. As distros probably won't package VapourSynth as it can be installed using pip, they probably won't build ffmpeg with VapourSynth support, because they don't have the headers on the build system. Even when someone decides to build ffmpeg for themself with VapourSynth support, it will fail unless they have manually build VapourSynth, because pip won't install any header. That was my motivation to include those headers. Is there a specific rule when it is allowed to include headers for external libaries? And setting it up as autodetect seems like overreach. I don't know if there's any actual written rule about which libraries to autodetect and which ones require explicit enabling, but most of the autodetected ones thus far appear to be OS-level or otherwise foundational libraries, not libraries for a singular media format. I did not find any rule on that. I made it autodetect, because I saw no negative impact (same license and no dependency at runtime). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [RFC]] swscale modernization proposal
Hey,
As some of you know, I got contracted (by STF 2024) to work on improving
swscale, over the course of the next couple of months. I want to share my
current plans and gather feedback + measure sentiment.
## Problem statement
The two issues I'd like to focus on for now are:
1. Lack of support for a lot of modern formats and conversions (HDR, ICtCp,
IPTc2, BT.2020-CL, XYZ, YCgCo, Dolby Vision, ...)
2. Complicated context management, with cascaded contexts, threading, stateful
configuration, multi-step init procedures, etc; and related bugs
In order to make these feasible, some amount of internal re-organization of
duties inside swscale is prudent.
## Proposed approach
The first step is to create a new API, which will (tentatively) live in
. This API will initially start off as a near-copy of the
current swscale public API, but with the major difference that I want it to be
state-free and only access metadata in terms of AVFrame properties. So there
will be no independent configuration of the input chroma location etc. like
there is currently, and no need to re-configure or re-init the context when
feeding it frames with different properties. The goal is for users to be able
to just feed it AVFrame pairs and have it internally cache expensive
pre-processing steps as needed. Finally, avscale_* should ultimately also
support hardware frames directly, in which case it will dispatch to some
equivalent of scale_vulkan/vaapi/cuda or possibly even libplacebo. (But I will
defer this to a future milestone)
After this API is established, I want to start expanding the functionality in
the following manner:
### Phase 1
For basic operation, avscale_* will just dispatch to a sequence of swscale_*
invocations. In the basic case, it will just directly invoke swscale with
minimal overhead. In more advanced cases, it might resolve to a *sequence* of
swscale operations, with other operations (e.g. colorspace conversions a la
vf_colorspace) mixed in.
This will allow us to gain new functionality in a minimally invasive way, and
will let API users start porting to the new API. This will also serve as a good
"selling point" for the new API, allowing us to hopefully break up the legacy
swscale API afterwards.
### Phase 2
After this is working, I want to cleanly separate swscale into two distinct
components:
1. vertical/horizontal scaling
2. input/output conversions
Right now, these operations both live inside the main SwsContext, even though
they are conceptually orthogonal. Input handling is done entirely by the
abstract callbacks lumToYV12 etc., while output conversion is currently
"merged" with vertical scaling (yuv2planeX etc.).
I want to cleanly separate these components so they can live inside independent
contexts, and be considered as semantically distinct steps. (In particular,
there should ideally be no more "unscaled special converters", instead this can
be seen as a special case where there simply is no vertical/horizontal scaling
step)
The idea is for the colorspace conversion layer to sit in between the
input/output converters and the horizontal/vertical scalers. This all would be
orchestrated by the avscale_* abstraction.
## Implementation details
To avoid performance loss from separating "merged" functions into their
constituents, care needs to be taken such that all intermediate data, in
addition to all involved look-up tables, will fit comfortably inside the L1
cache. The approach I propose, which is also (afaict) used by zscale, is to
loop over line segments, applying each operation in sequence, on a small
temporary buffer.
e.g.
hscale_row(pixel *dst, const pixel *src, int img_width)
{
const int SIZE = 256; // or some other small-ish figure, possibly a design
// constant of the API so that SIMD implementations
// can be appropriately unrolled
pixel tmp[SIZE];
for (i = 0; i < img_width; i += SIZE) {
int pixels = min(SIZE, img_width - i);
{ /* inside read input callback */
unpack_input(tmp, src, pixels);
// the amount of separation here will depend on the performance
apply_matrix3x3(tmp, yuv2rgb, pixels);
apply_lut3x1d(tmp, gamma_lut, pixels);
...
}
hscale(dst, tmp, filter, pixels);
src += pixels;
dst += scale_factor(pixels);
}
}
This function can then output rows into a ring buffer for use inside the
vertical scaler, after which the same procedure happens (in reverse) for the
final output pass.
Possibly, we also want to additionally limit the size of a row for the
horizontal scaler, to allow arbitrary large input images.
## Comments / feedback?
Does the above approach seem reasonable? How do people feel about introducing
a new API vs. trying to hammer the existing API into the shape I want it to be?
I've attached an example of what could end up looking like. If
there is broad agreement on this design, I
[FFmpeg-devel] [PATCH] avfilter/af_afade: fix opt_type for nb_samples/ns
The actual value is an int64_t, and is accessed elsewhere as AV_OPT_TYPE_INT64.
Accessing it as INT will likely cause bugs on some 32-bit architectures.
---
libavfilter/af_afade.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavfilter/af_afade.c b/libavfilter/af_afade.c
index 3a45873460..c79271ec92 100644
--- a/libavfilter/af_afade.c
+++ b/libavfilter/af_afade.c
@@ -452,8 +452,8 @@ const AVFilter ff_af_afade = {
#if CONFIG_ACROSSFADE_FILTER
static const AVOption acrossfade_options[] = {
-{ "nb_samples", "set number of samples for cross fade duration",
OFFSET(nb_samples), AV_OPT_TYPE_INT,{.i64 = 44100}, 1, INT32_MAX/10,
FLAGS },
-{ "ns", "set number of samples for cross fade duration",
OFFSET(nb_samples), AV_OPT_TYPE_INT,{.i64 = 44100}, 1, INT32_MAX/10,
FLAGS },
+{ "nb_samples", "set number of samples for cross fade duration",
OFFSET(nb_samples), AV_OPT_TYPE_INT64, {.i64 = 44100}, 1, INT32_MAX/10,
FLAGS },
+{ "ns", "set number of samples for cross fade duration",
OFFSET(nb_samples), AV_OPT_TYPE_INT64, {.i64 = 44100}, 1, INT32_MAX/10,
FLAGS },
{ "duration", "set cross fade duration",
OFFSET(duration), AV_OPT_TYPE_DURATION, {.i64 = 0 }, 0, 6000, FLAGS },
{ "d","set cross fade duration",
OFFSET(duration), AV_OPT_TYPE_DURATION, {.i64 = 0 }, 0, 6000, FLAGS },
{ "overlap", "overlap 1st stream end with 2nd stream start",
OFFSET(overlap), AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, FLAGS },
--
2.45.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] avfilter/af_afade: fix opt_type for nb_samples/ns
Andrew Sayers:
> The actual value is an int64_t, and is accessed elsewhere as
> AV_OPT_TYPE_INT64.
>
> Accessing it as INT will likely cause bugs on some 32-bit architectures.
Whether this works or not will depend upon endianness, not on whether
the architecture is 32-bit (as long as int is 32bits, which is mostly
true for 64-bit architectures).
> ---
> libavfilter/af_afade.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/af_afade.c b/libavfilter/af_afade.c
> index 3a45873460..c79271ec92 100644
> --- a/libavfilter/af_afade.c
> +++ b/libavfilter/af_afade.c
> @@ -452,8 +452,8 @@ const AVFilter ff_af_afade = {
> #if CONFIG_ACROSSFADE_FILTER
>
> static const AVOption acrossfade_options[] = {
> -{ "nb_samples", "set number of samples for cross fade duration",
> OFFSET(nb_samples), AV_OPT_TYPE_INT,{.i64 = 44100}, 1, INT32_MAX/10,
> FLAGS },
> -{ "ns", "set number of samples for cross fade duration",
> OFFSET(nb_samples), AV_OPT_TYPE_INT,{.i64 = 44100}, 1, INT32_MAX/10,
> FLAGS },
> +{ "nb_samples", "set number of samples for cross fade duration",
> OFFSET(nb_samples), AV_OPT_TYPE_INT64, {.i64 = 44100}, 1, INT32_MAX/10,
> FLAGS },
> +{ "ns", "set number of samples for cross fade duration",
> OFFSET(nb_samples), AV_OPT_TYPE_INT64, {.i64 = 44100}, 1, INT32_MAX/10,
> FLAGS },
> { "duration", "set cross fade duration",
> OFFSET(duration), AV_OPT_TYPE_DURATION, {.i64 = 0 }, 0, 6000, FLAGS
> },
> { "d","set cross fade duration",
> OFFSET(duration), AV_OPT_TYPE_DURATION, {.i64 = 0 }, 0, 6000, FLAGS
> },
> { "overlap", "overlap 1st stream end with 2nd stream start",
> OFFSET(overlap), AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, FLAGS },
LGTM. How did you find this?
- 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] avfilter/af_afade: fix opt_type for nb_samples/ns
On Sat, Jun 22, 2024 at 03:20:52PM +0200, Andreas Rheinhardt wrote:
> Andrew Sayers:
> > The actual value is an int64_t, and is accessed elsewhere as
> > AV_OPT_TYPE_INT64.
> >
> > Accessing it as INT will likely cause bugs on some 32-bit architectures.
>
> Whether this works or not will depend upon endianness, not on whether
> the architecture is 32-bit (as long as int is 32bits, which is mostly
> true for 64-bit architectures).
>
> > ---
> > libavfilter/af_afade.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavfilter/af_afade.c b/libavfilter/af_afade.c
> > index 3a45873460..c79271ec92 100644
> > --- a/libavfilter/af_afade.c
> > +++ b/libavfilter/af_afade.c
> > @@ -452,8 +452,8 @@ const AVFilter ff_af_afade = {
> > #if CONFIG_ACROSSFADE_FILTER
> >
> > static const AVOption acrossfade_options[] = {
> > -{ "nb_samples", "set number of samples for cross fade duration",
> > OFFSET(nb_samples), AV_OPT_TYPE_INT,{.i64 = 44100}, 1, INT32_MAX/10,
> > FLAGS },
> > -{ "ns", "set number of samples for cross fade duration",
> > OFFSET(nb_samples), AV_OPT_TYPE_INT,{.i64 = 44100}, 1, INT32_MAX/10,
> > FLAGS },
> > +{ "nb_samples", "set number of samples for cross fade duration",
> > OFFSET(nb_samples), AV_OPT_TYPE_INT64, {.i64 = 44100}, 1, INT32_MAX/10,
> > FLAGS },
> > +{ "ns", "set number of samples for cross fade duration",
> > OFFSET(nb_samples), AV_OPT_TYPE_INT64, {.i64 = 44100}, 1, INT32_MAX/10,
> > FLAGS },
> > { "duration", "set cross fade duration",
> > OFFSET(duration), AV_OPT_TYPE_DURATION, {.i64 = 0 }, 0, 6000,
> > FLAGS },
> > { "d","set cross fade duration",
> > OFFSET(duration), AV_OPT_TYPE_DURATION, {.i64 = 0 }, 0, 6000,
> > FLAGS },
> > { "overlap", "overlap 1st stream end with 2nd stream start",
> > OFFSET(overlap), AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, FLAGS },
>
> LGTM. How did you find this?
It was a side-effect of yet another attempt to understand the codebase -
looking for struct members with more than one associated AVOptionType.
FWIW, the other oddities uncovered were:
* libavformat/rtsp.c treats stimeout as both INT64 and DURATION
(should probably have been caught at the time, but fixing it would likely
break scripts that expect the current CLI behaviour)
* libavdevice/v4l2.c treats list_format as both INT and CONST
(not a bug, but a comment explaining this clever trick would have been nice)
* libavfilter/buffersrc.c lets you set w/h separately or as video_size
(not a bug, and I assume there's a reason for doing it this way)
___
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]] swscale modernization proposal
On Sat, Jun 22, 2024 at 03:13:34PM +0200, Niklas Haas wrote: [...] > > ## Comments / feedback? > > Does the above approach seem reasonable? How do people feel about introducing > a new API vs. trying to hammer the existing API into the shape I want it to > be? > > I've attached an example of what could end up looking like. If > there is broad agreement on this design, I will move on to an implementation. API users seem to have difficulty with this type of big change[[1], and doing the interface before the implementation means there's less reason for developers to switch while you're still looking for feedback. What's the plan to bring them along? [1] https://ffmpeg.org/pipermail/ffmpeg-devel/2024-June/328852.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] [RFC]] swscale modernization proposal
On Sat, 22 Jun 2024 15:23:22 +0100 Andrew Sayers wrote: > On Sat, Jun 22, 2024 at 03:13:34PM +0200, Niklas Haas wrote: > [...] > > > > ## Comments / feedback? > > > > Does the above approach seem reasonable? How do people feel about > > introducing > > a new API vs. trying to hammer the existing API into the shape I want it to > > be? > > > > I've attached an example of what could end up looking like. If > > there is broad agreement on this design, I will move on to an > > implementation. > > API users seem to have difficulty with this type of big change[[1], > and doing the interface before the implementation means there's less > reason for developers to switch while you're still looking for feedback. > > What's the plan to bring them along? Since SwsContext is entirely internal, we can continue providing the current API on top of whatever internal abstractions we arrive at. As a trivial example, sws_scale() can construct a temporary AVFrame based on the provided information, and simply pass that to avscale_frame(). So I don't think legacy API users are at risk, or pressure to switch, unless they want access to *new* functionality. For that, the harder step is moving from sws_scale() to sws_scale_frame(). This is something API users can *already* do. By contrast, moving from sws_scale_frame() to avscale_frame() should hopefully be simple, since it just requires making sure the AVFrame is correctly tagged. Usually, the flow is in the opposite direction - users receive a correctly tagged AVFrame and manually forward this information to the SwsContext. So, most of the time, moving to a fully AVFrame-based API will result in deleting code, rather than adding it. If we wanted to maximize the transition comfort, we should consider re-using the sws_scale_frame() entrypoint directly. The main reason I am hesitant to do this is because sws_scale_frame() is currently tied to the stateful configuration of SwsContext, and mostly ignores the AVFrame metadata. While changing that is possible, it possibly presents a bigger API break than simply introducing a new function. > > [1] https://ffmpeg.org/pipermail/ffmpeg-devel/2024-June/328852.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". ___ 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/8 v3] avutil/stereo3d add a Monoscopic view enum value
We need a way to signal the frame has a single view that doesn't map to any
particular eye, and it should be the default one.
Signed-off-by: James Almer
---
Now updating all the fate test...
The 3D ones will be updated again in the following commits once ffprobe is
adapted to properly handle the view field.
libavutil/stereo3d.c | 3 ++-
libavutil/stereo3d.h | 9 +++--
tests/ref/fate/matroska-spherical-mono | 2 +-
tests/ref/fate/matroska-spherical-mono-remux | 4 ++--
tests/ref/fate/matroska-stereo_mode | 8
tests/ref/fate/matroska-vp8-alpha-remux | 2 +-
tests/ref/fate/mov-spherical-mono| 2 +-
7 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/libavutil/stereo3d.c b/libavutil/stereo3d.c
index 19e81e4124..0c0cad127c 100644
--- a/libavutil/stereo3d.c
+++ b/libavutil/stereo3d.c
@@ -68,9 +68,10 @@ static const char * const stereo3d_type_names[] = {
};
static const char * const stereo3d_view_names[] = {
-[AV_STEREO3D_VIEW_PACKED] = "packed",
+[AV_STEREO3D_VIEW_MONO] = "monoscopic",
[AV_STEREO3D_VIEW_LEFT] = "left",
[AV_STEREO3D_VIEW_RIGHT] = "right",
+[AV_STEREO3D_VIEW_PACKED] = "packed",
};
static const char * const stereo3d_primary_eye_names[] = {
diff --git a/libavutil/stereo3d.h b/libavutil/stereo3d.h
index 00a5c3900e..77340f72b2 100644
--- a/libavutil/stereo3d.h
+++ b/libavutil/stereo3d.h
@@ -143,9 +143,9 @@ enum AVStereo3DType {
*/
enum AVStereo3DView {
/**
- * Frame contains two packed views.
+ * Frame is monoscopic.
*/
-AV_STEREO3D_VIEW_PACKED,
+AV_STEREO3D_VIEW_MONO,
/**
* Frame contains only the left view.
@@ -156,6 +156,11 @@ enum AVStereo3DView {
* Frame contains only the right view.
*/
AV_STEREO3D_VIEW_RIGHT,
+
+/**
+ * Frame contains two packed views.
+ */
+AV_STEREO3D_VIEW_PACKED,
};
/**
diff --git a/tests/ref/fate/matroska-spherical-mono
b/tests/ref/fate/matroska-spherical-mono
index b108596350..aa17e9c624 100644
--- a/tests/ref/fate/matroska-spherical-mono
+++ b/tests/ref/fate/matroska-spherical-mono
@@ -3,7 +3,7 @@
side_data_type=Stereo 3D
type=2D
inverted=0
-view=packed
+view=monoscopic
primary_eye=none
baseline=0
horizontal_disparity_adjustment=0/1
diff --git a/tests/ref/fate/matroska-spherical-mono-remux
b/tests/ref/fate/matroska-spherical-mono-remux
index eec41b77f3..75a9b73a37 100644
--- a/tests/ref/fate/matroska-spherical-mono-remux
+++ b/tests/ref/fate/matroska-spherical-mono-remux
@@ -27,7 +27,7 @@ DISPOSITION:forced=1
side_data_type=Stereo 3D
type=2D
inverted=0
-view=packed
+view=monoscopic
primary_eye=none
baseline=0
horizontal_disparity_adjustment=0/1
@@ -56,7 +56,7 @@ DISPOSITION:forced=0
side_data_type=Stereo 3D
type=2D
inverted=0
-view=packed
+view=monoscopic
primary_eye=none
baseline=0
horizontal_disparity_adjustment=0/1
diff --git a/tests/ref/fate/matroska-stereo_mode
b/tests/ref/fate/matroska-stereo_mode
index 26c325b20e..e35425ae76 100644
--- a/tests/ref/fate/matroska-stereo_mode
+++ b/tests/ref/fate/matroska-stereo_mode
@@ -132,7 +132,7 @@ TAG:DURATION=00:00:10.0
side_data_type=Stereo 3D
type=side by side
inverted=0
-view=packed
+view=monoscopic
primary_eye=none
baseline=0
horizontal_disparity_adjustment=0/1
@@ -152,7 +152,7 @@ TAG:DURATION=00:00:10.0
side_data_type=Stereo 3D
type=top and bottom
inverted=1
-view=packed
+view=monoscopic
primary_eye=none
baseline=0
horizontal_disparity_adjustment=0/1
@@ -170,7 +170,7 @@ TAG:DURATION=00:00:10.0
side_data_type=Stereo 3D
type=interleaved lines
inverted=1
-view=packed
+view=monoscopic
primary_eye=none
baseline=0
horizontal_disparity_adjustment=0/1
@@ -189,7 +189,7 @@ TAG:DURATION=00:00:10.0
side_data_type=Stereo 3D
type=interleaved columns
inverted=1
-view=packed
+view=monoscopic
primary_eye=none
baseline=0
horizontal_disparity_adjustment=0/1
diff --git a/tests/ref/fate/matroska-vp8-alpha-remux
b/tests/ref/fate/matroska-vp8-alpha-remux
index 06bcc4b4ba..814463eeda 100644
--- a/tests/ref/fate/matroska-vp8-alpha-remux
+++ b/tests/ref/fate/matroska-vp8-alpha-remux
@@ -35,7 +35,7 @@ DISPOSITION:still_image=0
side_data_type=Stereo 3D
type=2D
inverted=0
-view=packed
+view=monoscopic
primary_eye=none
baseline=0
horizontal_disparity_adjustment=0/1
diff --git a/tests/ref/fate/mov-spherical-mono
b/tests/ref/fate/mov-spherical-mono
index b108596350..aa17e9c624 100644
--- a/tests/ref/fate/mov-spherical-mono
+++ b/tests/ref/fate/mov-spherical-mono
@@ -3,7 +3,7 @@
side_data_type=Stereo 3D
type=2D
inverted=0
-view=packed
+view=monoscopic
primary_eye=none
baseline=0
horizontal_disparity_adjustment=0/1
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org
[FFmpeg-devel] [PATCH 2/8 v2] avutil/stereo3d: add a Stereo3D type to signal that the packing is defined by the view field
Given that a video stream/frame may have only one view coded, or both packed in
an undefined way, and as the values of AVStereo3DView and AVStereo3DType may
clash (namely if type is AV_STEREO3D_2D, then AV_STEREO3D_VIEW_PACKED would be
invalid, and if it's anything other than it, then only AV_STEREO3D_VIEW_PACKED
would be valid), this commit adds a new type value AV_STEREO3D_VIEW that
signals the user that AVStereo3D.view contains information about the nature of
the stream, with the added constrain that AVStereo3D.view should be ignored if
AVStereo3D.type is anything other than AV_STEREO3D_VIEW.
Signed-off-by: James Almer
---
This is the only way i could think of to work around the fact AVStereo3DType
and AVStereo3DView just can't work well together if we want to keep AVStereo
backwards compatible.
libavutil/stereo3d.c | 1 +
libavutil/stereo3d.h | 11 ++-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/libavutil/stereo3d.c b/libavutil/stereo3d.c
index 0c0cad127c..e8e5030db9 100644
--- a/libavutil/stereo3d.c
+++ b/libavutil/stereo3d.c
@@ -65,6 +65,7 @@ static const char * const stereo3d_type_names[] = {
[AV_STEREO3D_SIDEBYSIDE_QUINCUNX] = "side by side (quincunx subsampling)",
[AV_STEREO3D_LINES] = "interleaved lines",
[AV_STEREO3D_COLUMNS] = "interleaved columns",
+[AV_STEREO3D_VIEW]= "view defined",
};
static const char * const stereo3d_view_names[] = {
diff --git a/libavutil/stereo3d.h b/libavutil/stereo3d.h
index 77340f72b2..e3af519e03 100644
--- a/libavutil/stereo3d.h
+++ b/libavutil/stereo3d.h
@@ -136,6 +136,14 @@ enum AVStereo3DType {
* @endcode
*/
AV_STEREO3D_COLUMNS,
+
+/**
+ * Video may be monoscopic, or stereoscopic where either the
+ * packing is unknown or only one view is present.
+ *
+ * @see AVStereo3DView
+ */
+AV_STEREO3D_VIEW,
};
/**
@@ -207,7 +215,8 @@ typedef struct AVStereo3D {
int flags;
/**
- * Determines which views are packed.
+ * Determines which views are packed. This field should be ignored when
+ * @ref type is set to anything other than AV_STEREO3D_VIEW.
*/
enum AVStereo3DView view;
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/8 v2] avformat/dump: print Stereo3D view only when type is view defined
Signed-off-by: James Almer --- libavformat/dump.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/libavformat/dump.c b/libavformat/dump.c index 61a2c6a29f..33d72b7e18 100644 --- a/libavformat/dump.c +++ b/libavformat/dump.c @@ -259,9 +259,10 @@ static void dump_stereo3d(void *ctx, const AVPacketSideData *sd, int log_level) stereo = (const AVStereo3D *)sd->data; -av_log(ctx, log_level, "%s, view: %s, primary eye: %s", - av_stereo3d_type_name(stereo->type), av_stereo3d_view_name(stereo->view), - av_stereo3d_primary_eye_name(stereo->primary_eye)); +av_log(ctx, log_level, "%s", av_stereo3d_type_name(stereo->type)); +if (stereo->type == AV_STEREO3D_VIEW) +av_log(ctx, log_level, ", view: %s", av_stereo3d_view_name(stereo->view)); +av_log(ctx, log_level, ", primary eye: %s", av_stereo3d_primary_eye_name(stereo->primary_eye)); if (stereo->baseline) av_log(ctx, log_level, ", baseline: %"PRIu32"", stereo->baseline); if (stereo->horizontal_disparity_adjustment.num && stereo->horizontal_disparity_adjustment.den) -- 2.45.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 5/8 v2] fftools/ffprobe: infer AVStereo3D.view when it's not explicit
Signed-off-by: James Almer
---
Better infer it than not printing it, following the logic from 5140d8334e3b.
fftools/ffprobe.c | 6 +-
tests/ref/fate/matroska-stereo_mode | 8
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index d7ba980ff9..397ea848fc 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2542,9 +2542,13 @@ static void print_pkt_side_data(WriterContext *w,
print_int("rotation", rotation);
} else if (sd->type == AV_PKT_DATA_STEREO3D) {
const AVStereo3D *stereo = (AVStereo3D *)sd->data;
+enum AVStereo3DView view = stereo->view;
print_str("type", av_stereo3d_type_name(stereo->type));
print_int("inverted", !!(stereo->flags & AV_STEREO3D_FLAG_INVERT));
-print_str("view", av_stereo3d_view_name(stereo->view));
+if (stereo->type != AV_STEREO3D_VIEW)
+view = (stereo->type == AV_STEREO3D_2D) ?
+ AV_STEREO3D_VIEW_MONO : AV_STEREO3D_VIEW_PACKED;
+print_str("view", av_stereo3d_view_name(view));
print_str("primary_eye",
av_stereo3d_primary_eye_name(stereo->primary_eye));
print_int("baseline", stereo->baseline);
print_q("horizontal_disparity_adjustment",
stereo->horizontal_disparity_adjustment, '/');
diff --git a/tests/ref/fate/matroska-stereo_mode
b/tests/ref/fate/matroska-stereo_mode
index e35425ae76..26c325b20e 100644
--- a/tests/ref/fate/matroska-stereo_mode
+++ b/tests/ref/fate/matroska-stereo_mode
@@ -132,7 +132,7 @@ TAG:DURATION=00:00:10.0
side_data_type=Stereo 3D
type=side by side
inverted=0
-view=monoscopic
+view=packed
primary_eye=none
baseline=0
horizontal_disparity_adjustment=0/1
@@ -152,7 +152,7 @@ TAG:DURATION=00:00:10.0
side_data_type=Stereo 3D
type=top and bottom
inverted=1
-view=monoscopic
+view=packed
primary_eye=none
baseline=0
horizontal_disparity_adjustment=0/1
@@ -170,7 +170,7 @@ TAG:DURATION=00:00:10.0
side_data_type=Stereo 3D
type=interleaved lines
inverted=1
-view=monoscopic
+view=packed
primary_eye=none
baseline=0
horizontal_disparity_adjustment=0/1
@@ -189,7 +189,7 @@ TAG:DURATION=00:00:10.0
side_data_type=Stereo 3D
type=interleaved columns
inverted=1
-view=monoscopic
+view=packed
primary_eye=none
baseline=0
horizontal_disparity_adjustment=0/1
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 6/8 v2] avutil/stereo3d: add a new allocator function that returns a size
av_stereo3d_alloc() is not useful in scenarios where you need to know the
runtime size of AVStereo3D.
Signed-off-by: James Almer
---
libavutil/stereo3d.c | 8
libavutil/stereo3d.h | 8
2 files changed, 16 insertions(+)
diff --git a/libavutil/stereo3d.c b/libavutil/stereo3d.c
index e8e5030db9..c182b18e52 100644
--- a/libavutil/stereo3d.c
+++ b/libavutil/stereo3d.c
@@ -32,6 +32,11 @@ static void get_defaults(AVStereo3D *stereo)
}
AVStereo3D *av_stereo3d_alloc(void)
+{
+return av_stereo3d_alloc_size(NULL);
+}
+
+AVStereo3D *av_stereo3d_alloc_size(size_t *size)
{
AVStereo3D *stereo = av_mallocz(sizeof(AVStereo3D));
if (!stereo)
@@ -39,6 +44,9 @@ AVStereo3D *av_stereo3d_alloc(void)
get_defaults(stereo);
+if (size)
+*size = sizeof(*stereo);
+
return stereo;
}
diff --git a/libavutil/stereo3d.h b/libavutil/stereo3d.h
index e3af519e03..31167c14fa 100644
--- a/libavutil/stereo3d.h
+++ b/libavutil/stereo3d.h
@@ -251,6 +251,14 @@ typedef struct AVStereo3D {
*/
AVStereo3D *av_stereo3d_alloc(void);
+/**
+ * Allocate an AVStereo3D structure and set its fields to default values.
+ * The resulting struct can be freed using av_freep().
+ *
+ * @return An AVStereo3D filled with default values or NULL on failure.
+ */
+AVStereo3D *av_stereo3d_alloc_size(size_t *size);
+
/**
* Allocate a complete AVFrameSideData and add it to the frame.
*
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 7/8 v2] avformat/mov: don't use sizeof(AVStereo3D)
It's not part of the libavutil ABI.
Signed-off-by: James Almer
---
libavformat/isom.h | 1 +
libavformat/mov.c | 10 +-
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/libavformat/isom.h b/libavformat/isom.h
index 35b767a52c..a0498f45e5 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -247,6 +247,7 @@ typedef struct MOVStreamContext {
int32_t *display_matrix;
AVStereo3D *stereo3d;
+size_t stereo3d_size;
AVSphericalMapping *spherical;
size_t spherical_size;
AVMasteringDisplayMetadata *mastering;
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 9b2ce1f167..07c0ec3ec4 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -6332,7 +6332,7 @@ static int mov_read_st3d(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
return 0;
}
-sc->stereo3d = av_stereo3d_alloc();
+sc->stereo3d = av_stereo3d_alloc_size(&sc->stereo3d_size);
if (!sc->stereo3d)
return AVERROR(ENOMEM);
@@ -6695,7 +6695,7 @@ static int mov_read_eyes(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
}
if (!sc->stereo3d) {
-sc->stereo3d = av_stereo3d_alloc();
+sc->stereo3d = av_stereo3d_alloc_size(&sc->stereo3d_size);
if (!sc->stereo3d)
return AVERROR(ENOMEM);
}
@@ -6782,7 +6782,7 @@ static int mov_read_hfov(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
if (!sc->stereo3d) {
-sc->stereo3d = av_stereo3d_alloc();
+sc->stereo3d = av_stereo3d_alloc_size(&sc->stereo3d_size);
if (!sc->stereo3d)
return AVERROR(ENOMEM);
}
@@ -6831,7 +6831,7 @@ static int mov_parse_uuid_spherical(MOVStreamContext *sc,
AVIOContext *pb, size_
else
mode = AV_STEREO3D_2D;
-sc->stereo3d = av_stereo3d_alloc();
+sc->stereo3d = av_stereo3d_alloc_size(&sc->stereo3d_size);
if (!sc->stereo3d)
goto out;
@@ -10032,7 +10032,7 @@ static int mov_read_header(AVFormatContext *s)
if (sc->stereo3d) {
if (!av_packet_side_data_add(&st->codecpar->coded_side_data,
&st->codecpar->nb_coded_side_data,
AV_PKT_DATA_STEREO3D,
- (uint8_t *)sc->stereo3d,
sizeof(*sc->stereo3d), 0))
+ (uint8_t *)sc->stereo3d,
sc->stereo3d_size, 0))
return AVERROR(ENOMEM);
sc->stereo3d = NULL;
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 8/8 v2] avformat/matroskadec: don't use sizeof(AVStereo3D)
It's not part of the libavutil ABI.
Signed-off-by: James Almer
---
libavformat/matroskadec.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 6bc5fa621e..d1a135ed63 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -2253,8 +2253,9 @@ static int mkv_stereo3d_conv(AVStream *st,
MatroskaVideoStereoModeType stereo_mo
STEREOMODE_STEREO3D_MAPPING(STEREO_MODE_CONV, NOTHING)
};
AVStereo3D *stereo;
+size_t size;
-stereo = av_stereo3d_alloc();
+stereo = av_stereo3d_alloc_size(&size);
if (!stereo)
return AVERROR(ENOMEM);
@@ -2262,7 +2263,7 @@ static int mkv_stereo3d_conv(AVStream *st,
MatroskaVideoStereoModeType stereo_mo
stereo->flags = stereo_mode_conv[stereo_mode].flags;
if (!av_packet_side_data_add(&st->codecpar->coded_side_data,
&st->codecpar->nb_coded_side_data,
- AV_PKT_DATA_STEREO3D, stereo,
sizeof(*stereo), 0)) {
+ AV_PKT_DATA_STEREO3D, stereo, size, 0)) {
av_freep(&stereo);
return AVERROR(ENOMEM);
}
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/8 v2] avformat/mov: default to Monoscopic view when parsing eyes box
Signed-off-by: James Almer
---
libavformat/mov.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index f08fec3fb6..9b2ce1f167 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -6546,7 +6546,8 @@ static int mov_read_eyes(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
int size, flags = 0;
int64_t remaining;
uint32_t tag, baseline = 0;
-enum AVStereo3DView view = AV_STEREO3D_VIEW_PACKED;
+enum AVStereo3DType type = AV_STEREO3D_2D;
+enum AVStereo3DView view = AV_STEREO3D_VIEW_MONO;
enum AVStereo3DPrimaryEye primary_eye = AV_PRIMARY_EYE_NONE;
AVRational horizontal_disparity_adjustment = { 0, 1 };
@@ -6596,6 +6597,9 @@ static int mov_read_eyes(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
view = AV_STEREO3D_VIEW_LEFT;
else if (has_right)
view = AV_STEREO3D_VIEW_RIGHT;
+if (view)
+type = AV_STEREO3D_VIEW;
+
break;
}
case MKTAG('h','e','r','o'): {
@@ -6697,6 +6701,7 @@ static int mov_read_eyes(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
}
sc->stereo3d->flags = flags;
+sc->stereo3d->type= type;
sc->stereo3d->view= view;
sc->stereo3d->primary_eye = primary_eye;
sc->stereo3d->baseline= baseline;
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/4] lavc/vp8dsp: R-V V loop_filter
From: sunyuechi C908 X60 vp8_loop_filter8uv_v_c : 13.7 11.7 vp8_loop_filter8uv_v_rvv_i32 :7.76.2 vp8_loop_filter16y_h_c : 12.2 11.2 vp8_loop_filter16y_h_rvv_i32 :9.57.2 vp8_loop_filter16y_v_c : 13.2 12.0 vp8_loop_filter16y_v_rvv_i32 :5.53.7 --- libavcodec/riscv/vp8dsp_init.c | 5 ++- libavcodec/riscv/vp8dsp_rvv.S | 57 ++ 2 files changed, 61 insertions(+), 1 deletion(-) diff --git a/libavcodec/riscv/vp8dsp_init.c b/libavcodec/riscv/vp8dsp_init.c index 94f78cd84b..72191f558b 100644 --- a/libavcodec/riscv/vp8dsp_init.c +++ b/libavcodec/riscv/vp8dsp_init.c @@ -157,7 +157,10 @@ av_cold void ff_vp8dsp_init_riscv(VP8DSPContext *c) c->vp8_h_loop_filter_simple = ff_vp8_h_loop_filter16_simple_rvv##vlen; \ c->vp8_v_loop_filter16y_inner = ff_vp8_v_loop_filter16_inner_rvv##vlen; \ c->vp8_h_loop_filter16y_inner = ff_vp8_h_loop_filter16_inner_rvv##vlen; \ -c->vp8_v_loop_filter8uv_inner = ff_vp8_v_loop_filter8uv_inner_rvv##vlen; +c->vp8_v_loop_filter8uv_inner = ff_vp8_v_loop_filter8uv_inner_rvv##vlen; \ +c->vp8_v_loop_filter16y = ff_vp8_v_loop_filter16_rvv##vlen; \ +c->vp8_h_loop_filter16y = ff_vp8_h_loop_filter16_rvv##vlen; \ +c->vp8_v_loop_filter8uv = ff_vp8_v_loop_filter8uv_rvv##vlen; int flags = av_get_cpu_flags(); diff --git a/libavcodec/riscv/vp8dsp_rvv.S b/libavcodec/riscv/vp8dsp_rvv.S index ed789ec4fd..98ff389b9a 100644 --- a/libavcodec/riscv/vp8dsp_rvv.S +++ b/libavcodec/riscv/vp8dsp_rvv.S @@ -410,6 +410,33 @@ endfunc vsra.vi v24, v24, 1 // (f1 + 1) >> 1; vadd.vv v8, v18, v24 vsub.vv v10, v20, v24 +.else +li t5, 27 +li t3, 9 +li a7, 18 +vwmul.vxv2, v11, t5 +vwmul.vxv6, v11, t3 +vwmul.vxv4, v11, a7 +vsetvlstatic16 \len, \vlen +li a7, 63 +vzext.vf2 v14, v15 // p2 +vzext.vf2 v24, v10 // q2 +vadd.vx v2, v2, a7 +vadd.vx v4, v4, a7 +vadd.vx v6, v6, a7 +vsra.vi v2, v2, 7// a0 +vsra.vi v12, v4, 7 // a1 +vsra.vi v6, v6, 7// a2 +vadd.vv v14, v14, v6 // p2 + a2 +vsub.vv v22, v24, v6 // q2 - a2 +vsub.vv v10, v20, v12// q1 - a1 +vadd.vv v4, v8, v2 // p0 + a0 +vsub.vv v6, v16, v2 // q0 - a0 +vadd.vv v8, v12, v18 // a1 + p1 +vmax.vx v4, v4, zero +vmax.vx v6, v6, zero +vmax.vx v14, v14, zero +vmax.vx v16, v22, zero .endif vmax.vx v8, v8, zero @@ -430,6 +457,17 @@ endfunc vsse8.v v6, (a6), \stride, v0.t vsse8.v v7, (t4), \stride, v0.t .endif +.if !\inner +vnclipu.wi v14, v14, 0 +vnclipu.wi v16, v16, 0 +.ifc \type,v +vse8.v v14, (t0), v0.t +vse8.v v16, (t6), v0.t +.else +vsse8.v v14, (t0), \stride, v0.t +vsse8.v v16, (t6), \stride, v0.t +.endif +.endif .endif .endm @@ -464,6 +502,25 @@ func ff_vp8_v_loop_filter8uv_inner_rvv\vlen, zve32x filter 8, \vlen, v, 1, 1, a1, a2, a3, a4, a5 ret endfunc + +func ff_vp8_v_loop_filter16_rvv\vlen, zve32x +vsetvlstatic8 16, \vlen +filter 16, \vlen, v, 1, 0, a0, a1, a2, a3, a4 +ret +endfunc + +func ff_vp8_h_loop_filter16_rvv\vlen, zve32x +vsetvlstatic8 16, \vlen +filter 16, \vlen, h, 1, 0, a0, a1, a2, a3, a4 +ret +endfunc + +func ff_vp8_v_loop_filter8uv_rvv\vlen, zve32x +vsetvlstatic8 8, \vlen +filter 8, \vlen, v, 1, 0, a0, a2, a3, a4, a5 +filter 8, \vlen, v, 1, 0, a1, a2, a3, a4, a5 +ret +endfunc .endr .macro bilin_load_h dst mn -- 2.45.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/4] lavc/vp8dsp: R-V V loop_filter_simple
From: sunyuechi
C908 X60
vp8_loop_filter_simple_h_c :7.06.0
vp8_loop_filter_simple_h_rvv_i32 :3.22.7
vp8_loop_filter_simple_v_c :7.26.5
vp8_loop_filter_simple_v_rvv_i32 :1.71.2
---
libavcodec/riscv/vp8dsp_init.c | 18 ++-
libavcodec/riscv/vp8dsp_rvv.S | 87 ++
2 files changed, 104 insertions(+), 1 deletion(-)
diff --git a/libavcodec/riscv/vp8dsp_init.c b/libavcodec/riscv/vp8dsp_init.c
index dcb6307d5b..8c5b2c8b04 100644
--- a/libavcodec/riscv/vp8dsp_init.c
+++ b/libavcodec/riscv/vp8dsp_init.c
@@ -49,6 +49,9 @@ VP8_BILIN(16, rvv256);
VP8_BILIN(8, rvv256);
VP8_BILIN(4, rvv256);
+VP8_LF(rvv128);
+VP8_LF(rvv256);
+
av_cold void ff_vp78dsp_init_riscv(VP8DSPContext *c)
{
#if HAVE_RV
@@ -147,9 +150,15 @@ av_cold void ff_vp78dsp_init_riscv(VP8DSPContext *c)
av_cold void ff_vp8dsp_init_riscv(VP8DSPContext *c)
{
#if HAVE_RVV
+int vlenb = ff_get_rv_vlenb();
+
+#define init_loop_filter(vlen) \
+c->vp8_v_loop_filter_simple = ff_vp8_v_loop_filter16_simple_rvv##vlen; \
+c->vp8_h_loop_filter_simple = ff_vp8_h_loop_filter16_simple_rvv##vlen;
+
int flags = av_get_cpu_flags();
-if (flags & AV_CPU_FLAG_RVV_I32 && ff_rv_vlen_least(128)) {
+if (flags & AV_CPU_FLAG_RVV_I32 && vlenb >= 16) {
#if __riscv_xlen >= 64
if (flags & AV_CPU_FLAG_RVV_I64)
c->vp8_luma_dc_wht = ff_vp8_luma_dc_wht_rvv;
@@ -159,6 +168,13 @@ av_cold void ff_vp8dsp_init_riscv(VP8DSPContext *c)
c->vp8_idct_dc_add4y = ff_vp8_idct_dc_add4y_rvv;
if (flags & AV_CPU_FLAG_RVV_I64)
c->vp8_idct_dc_add4uv = ff_vp8_idct_dc_add4uv_rvv;
+
+if (vlenb >= 32) {
+init_loop_filter(256);
+} else {
+init_loop_filter(128);
+}
}
+#undef init_loop_filter
#endif
}
diff --git a/libavcodec/riscv/vp8dsp_rvv.S b/libavcodec/riscv/vp8dsp_rvv.S
index 0cbf1672f7..b5f8bb31b4 100644
--- a/libavcodec/riscv/vp8dsp_rvv.S
+++ b/libavcodec/riscv/vp8dsp_rvv.S
@@ -275,6 +275,93 @@ func ff_vp78_idct_dc_add4uv_rvv, zve64x
ret
endfunc
+.macro filter_fmin len, vlen, a, f1, p0f2, q0f1
+vsetvlstatic16 \len, \vlen
+vsext.vf2 \q0f1, \a
+vmin.vx \p0f2, \q0f1, a7
+vmin.vx \q0f1, \q0f1, t3
+vadd.vi \p0f2, \p0f2, 3
+vadd.vi \q0f1, \q0f1, 4
+vsra.vi \p0f2, \p0f2, 3
+vsra.vi \f1, \q0f1, 3
+vadd.vv \p0f2, \p0f2, v8
+vsub.vv \q0f1, v16, \f1
+vmax.vx \p0f2, \p0f2, zero
+vmax.vx \q0f1, \q0f1, zero
+.endm
+
+.macro filter len, vlen, type, normal, inner, dst, stride, fE, fI, thresh
+.ifc \type,v
+sllia6, \stride, 1
+sub t2, \dst, a6
+add t4, \dst, \stride
+sub t1, \dst, \stride
+vle8.v v1, (t2)
+vle8.v v11, (t4)
+vle8.v v17, (t1)
+vle8.v v22, (\dst)
+.else
+addit1, \dst, -1
+addia6, \dst, -2
+addit4, \dst, 1
+vlse8.v v1, (a6), \stride
+vlse8.v v11, (t4), \stride
+vlse8.v v17, (t1), \stride
+vlse8.v v22, (\dst), \stride
+.endif
+vwsubu.vv v12, v1, v11 // p1-q1
+vwsubu.vv v24, v22, v17// q0-p0
+vnclip.wi v23, v12, 0
+vsetvlstatic16 \len, \vlen
+// vp8_simple_limit(dst + i, stride, flim)
+li a7, 2
+vneg.v v18, v12
+vmax.vv v18, v18, v12
+vneg.v v8, v24
+vmax.vv v8, v8, v24
+vsrl.vi v18, v18, 1
+vmacc.vxv18, a7, v8
+vmsleu.vx v0, v18, \fE
+
+li t5, 3
+li a7, 124
+li t3, 123
+vmul.vx v30, v24, t5
+vsext.vf2 v4, v23
+vzext.vf2 v8, v17 // p0
+vzext.vf2 v16, v22 // q0
+vadd.vv v12, v30, v4
+vsetvlstatic8 \len, \vlen
+vnclip.wi v11, v12, 0
+filter_fmin \len, \vlen, v11, v24, v4, v6
+vsetvlstatic8 \len, \vlen
+vnclipu.wi v4, v4, 0
+vnclipu.wi v6, v6, 0
+
+.ifc \type,v
+vse8.v v4, (t1), v0.t
+vse8.v v6, (\dst), v0.t
+.else
+vsse8.v v4, (t1), \stride, v0.t
+vsse8.v v6, (\dst), \stride, v0.t
+.endif
+
+.endm
+
+.irp vlen,256,128
+func ff_vp8_v_loop_filter16_simple_rvv\vlen, zve32x
+vsetvlstatic8 16, \vlen
+filter 16, \vlen, v, 0, 0, a0, a1, a2, a3,
[FFmpeg-devel] [PATCH 1/4] lavc/vp8dsp: R-V V 256 bilin,epel
From: sunyuechi
X60 new
vp8_put_bilin16_h_c: 42.542.5
vp8_put_bilin16_h_rvv_i32 :4.7 3.2
vp8_put_bilin16_hv_c : 71.571.7
vp8_put_bilin16_hv_rvv_i32 :8.5 7.5
vp8_put_bilin16_v_c: 43.042.7
vp8_put_bilin16_v_rvv_i32 :4.2 3.0
vp8_put_epel16_h4_c: 82.082.0
vp8_put_epel16_h4_rvv_i32 : 12.2 9.7
vp8_put_epel16_h6v6_c : 196.2 196.2
vp8_put_epel16_h6v6_rvv_i32: 31.226.2
vp8_put_epel16_v4_c: 82.282.2
vp8_put_epel16_v4_rvv_i32 : 12.010.0
...
---
libavcodec/riscv/vp8dsp_init.c | 136 +++--
libavcodec/riscv/vp8dsp_rvv.S | 133 +++-
2 files changed, 162 insertions(+), 107 deletions(-)
diff --git a/libavcodec/riscv/vp8dsp_init.c b/libavcodec/riscv/vp8dsp_init.c
index d9e2beb237..dcb6307d5b 100644
--- a/libavcodec/riscv/vp8dsp_init.c
+++ b/libavcodec/riscv/vp8dsp_init.c
@@ -35,13 +35,19 @@ void ff_vp8_idct_dc_add4uv_rvv(uint8_t *dst, int16_t
block[4][16], ptrdiff_t str
VP8_EPEL(16, rvi);
VP8_EPEL(8, rvi);
VP8_EPEL(4, rvi);
-VP8_EPEL(16, rvv);
-VP8_EPEL(8, rvv);
-VP8_EPEL(4, rvv);
+VP8_EPEL(16, rvv128);
+VP8_EPEL(8, rvv128);
+VP8_EPEL(4, rvv128);
+VP8_EPEL(16, rvv256);
+VP8_EPEL(8, rvv256);
+VP8_EPEL(4, rvv256);
-VP8_BILIN(16, rvv);
-VP8_BILIN(8, rvv);
-VP8_BILIN(4, rvv);
+VP8_BILIN(16, rvv128);
+VP8_BILIN(8, rvv128);
+VP8_BILIN(4, rvv128);
+VP8_BILIN(16, rvv256);
+VP8_BILIN(8, rvv256);
+VP8_BILIN(4, rvv256);
av_cold void ff_vp78dsp_init_riscv(VP8DSPContext *c)
{
@@ -58,64 +64,82 @@ av_cold void ff_vp78dsp_init_riscv(VP8DSPContext *c)
c->put_vp8_bilinear_pixels_tab[2][0][0] = ff_put_vp8_pixels4_rvi;
}
#if HAVE_RVV
-if (flags & AV_CPU_FLAG_RVV_I32 && ff_rv_vlen_least(128)) {
-c->put_vp8_bilinear_pixels_tab[0][0][1] = ff_put_vp8_bilin16_h_rvv;
-c->put_vp8_bilinear_pixels_tab[0][0][2] = ff_put_vp8_bilin16_h_rvv;
-c->put_vp8_bilinear_pixels_tab[1][0][1] = ff_put_vp8_bilin8_h_rvv;
-c->put_vp8_bilinear_pixels_tab[1][0][2] = ff_put_vp8_bilin8_h_rvv;
-c->put_vp8_bilinear_pixels_tab[2][0][1] = ff_put_vp8_bilin4_h_rvv;
-c->put_vp8_bilinear_pixels_tab[2][0][2] = ff_put_vp8_bilin4_h_rvv;
+#define init_bilin(vlen) \
+c->put_vp8_bilinear_pixels_tab[0][0][1] = ff_put_vp8_bilin16_h_rvv##vlen; \
+c->put_vp8_bilinear_pixels_tab[0][0][2] = ff_put_vp8_bilin16_h_rvv##vlen; \
+c->put_vp8_bilinear_pixels_tab[1][0][1] = ff_put_vp8_bilin8_h_rvv##vlen; \
+c->put_vp8_bilinear_pixels_tab[1][0][2] = ff_put_vp8_bilin8_h_rvv##vlen; \
+c->put_vp8_bilinear_pixels_tab[2][0][1] = ff_put_vp8_bilin4_h_rvv##vlen; \
+c->put_vp8_bilinear_pixels_tab[2][0][2] = ff_put_vp8_bilin4_h_rvv##vlen; \
+c->put_vp8_bilinear_pixels_tab[0][1][0] = ff_put_vp8_bilin16_v_rvv##vlen; \
+c->put_vp8_bilinear_pixels_tab[0][2][0] = ff_put_vp8_bilin16_v_rvv##vlen; \
+c->put_vp8_bilinear_pixels_tab[1][1][0] = ff_put_vp8_bilin8_v_rvv##vlen; \
+c->put_vp8_bilinear_pixels_tab[1][2][0] = ff_put_vp8_bilin8_v_rvv##vlen; \
+c->put_vp8_bilinear_pixels_tab[2][1][0] = ff_put_vp8_bilin4_v_rvv##vlen; \
+c->put_vp8_bilinear_pixels_tab[2][2][0] = ff_put_vp8_bilin4_v_rvv##vlen; \
+c->put_vp8_bilinear_pixels_tab[0][1][1] = ff_put_vp8_bilin16_hv_rvv##vlen;
\
+c->put_vp8_bilinear_pixels_tab[0][1][2] = ff_put_vp8_bilin16_hv_rvv##vlen;
\
+c->put_vp8_bilinear_pixels_tab[0][2][1] = ff_put_vp8_bilin16_hv_rvv##vlen;
\
+c->put_vp8_bilinear_pixels_tab[0][2][2] = ff_put_vp8_bilin16_hv_rvv##vlen;
\
+c->put_vp8_bilinear_pixels_tab[1][1][1] = ff_put_vp8_bilin8_hv_rvv##vlen; \
+c->put_vp8_bilinear_pixels_tab[1][1][2] = ff_put_vp8_bilin8_hv_rvv##vlen; \
+c->put_vp8_bilinear_pixels_tab[1][2][1] = ff_put_vp8_bilin8_hv_rvv##vlen; \
+c->put_vp8_bilinear_pixels_tab[1][2][2] = ff_put_vp8_bilin8_hv_rvv##vlen; \
+c->put_vp8_bilinear_pixels_tab[2][1][1] = ff_put_vp8_bilin4_hv_rvv##vlen; \
+c->put_vp8_bilinear_pixels_tab[2][1][2] = ff_put_vp8_bilin4_hv_rvv##vlen; \
+c->put_vp8_bilinear_pixels_tab[2][2][1] = ff_put_vp8_bilin4_hv_rvv##vlen; \
+c->put_vp8_bilinear_pixels_tab[2][2][2] = ff_put_vp8_bilin4_hv_rvv##vlen;
-c->put_vp8_bilinear_pixels_tab[0][1][0] = ff_put_vp8_bilin16_v_rvv;
-c->put_vp8_bilinear_pixels_tab[0][2][0] = ff_put_vp8_bilin16_v_rvv;
-c->put_vp8_bilinear_pixels_tab[1][1][0] = ff_put_vp8_bilin8_v_rvv;
-c->put_vp8_bilinear_pixels_tab[1][2][0] = ff_put_vp8_bilin8_v_rvv;
-c->put_vp8_bilinear_pixels_tab[2][1][0] = ff_put_vp8_bilin
[FFmpeg-devel] [PATCH 3/4] lavc/vp8dsp: R-V V loop_filter_inner
From: sunyuechi C908 X60 vp8_loop_filter8uv_inner_v_c : 12.5 11.0 vp8_loop_filter8uv_inner_v_rvv_i32 :7.76.2 vp8_loop_filter16y_inner_h_c : 11.7 10.2 vp8_loop_filter16y_inner_h_rvv_i32 :8.56.5 vp8_loop_filter16y_inner_v_c : 11.5 10.7 vp8_loop_filter16y_inner_v_rvv_i32 :5.03.5 --- libavcodec/riscv/vp8dsp_init.c | 5 +- libavcodec/riscv/vp8dsp_rvv.S | 104 + 2 files changed, 108 insertions(+), 1 deletion(-) diff --git a/libavcodec/riscv/vp8dsp_init.c b/libavcodec/riscv/vp8dsp_init.c index 8c5b2c8b04..94f78cd84b 100644 --- a/libavcodec/riscv/vp8dsp_init.c +++ b/libavcodec/riscv/vp8dsp_init.c @@ -154,7 +154,10 @@ av_cold void ff_vp8dsp_init_riscv(VP8DSPContext *c) #define init_loop_filter(vlen) \ c->vp8_v_loop_filter_simple = ff_vp8_v_loop_filter16_simple_rvv##vlen; \ -c->vp8_h_loop_filter_simple = ff_vp8_h_loop_filter16_simple_rvv##vlen; +c->vp8_h_loop_filter_simple = ff_vp8_h_loop_filter16_simple_rvv##vlen; \ +c->vp8_v_loop_filter16y_inner = ff_vp8_v_loop_filter16_inner_rvv##vlen; \ +c->vp8_h_loop_filter16y_inner = ff_vp8_h_loop_filter16_inner_rvv##vlen; \ +c->vp8_v_loop_filter8uv_inner = ff_vp8_v_loop_filter8uv_inner_rvv##vlen; int flags = av_get_cpu_flags(); diff --git a/libavcodec/riscv/vp8dsp_rvv.S b/libavcodec/riscv/vp8dsp_rvv.S index b5f8bb31b4..ed789ec4fd 100644 --- a/libavcodec/riscv/vp8dsp_rvv.S +++ b/libavcodec/riscv/vp8dsp_rvv.S @@ -275,6 +275,13 @@ func ff_vp78_idct_dc_add4uv_rvv, zve64x ret endfunc +.macro filter_abs dst, diff, fI +vneg.v v8, \diff +vmax.vv \dst, v8, \diff +vmsleu.vx v8, \dst, \fI +vmand.mmv27, v27, v8 +.endm + .macro filter_fmin len, vlen, a, f1, p0f2, q0f1 vsetvlstatic16 \len, \vlen vsext.vf2 \q0f1, \a @@ -300,6 +307,16 @@ endfunc vle8.v v11, (t4) vle8.v v17, (t1) vle8.v v22, (\dst) +.if \normal +sub t3, t2, a6 +sub t0, t1, a6 +add t6, \dst, a6 +add a7, t4, a6 +vle8.v v2, (t3) +vle8.v v15, (t0) +vle8.v v10, (t6) +vle8.v v14, (a7) +.endif .else addit1, \dst, -1 addia6, \dst, -2 @@ -308,9 +325,27 @@ endfunc vlse8.v v11, (t4), \stride vlse8.v v17, (t1), \stride vlse8.v v22, (\dst), \stride +.if \normal +addit5, \dst, -4 +addit0, \dst, -3 +addit6, \dst, 2 +addia7, \dst, 3 +vlse8.v v2, (t5), \stride +vlse8.v v15, (t0), \stride +vlse8.v v10, (t6), \stride +vlse8.v v14, (a7), \stride +.endif .endif vwsubu.vv v12, v1, v11 // p1-q1 vwsubu.vv v24, v22, v17// q0-p0 +.if \normal +vwsubu.vv v30, v1, v17 +vwsubu.vv v20, v11, v22 +vwsubu.vv v28, v1, v15 +vwsubu.vv v4, v2, v15 +vwsubu.vv v6, v10, v11 +vwsubu.vv v2, v14, v10 +.endif vnclip.wi v23, v12, 0 vsetvlstatic16 \len, \vlen // vp8_simple_limit(dst + i, stride, flim) @@ -322,6 +357,25 @@ endfunc vsrl.vi v18, v18, 1 vmacc.vxv18, a7, v8 vmsleu.vx v0, v18, \fE +.if \normal +vneg.v v18, v30 +vmax.vv v30, v18, v30 +vmsleu.vx v27, v30, \fI +filter_abs v18, v28, \fI +filter_abs v18, v4, \fI +filter_abs v18, v6, \fI +filter_abs v18, v2, \fI +filter_abs v20, v20, \fI +vmand.mmv27, v0, v27 // vp8_simple_limit && normal + +vmsgtu.vx v20, v20, \thresh// hev +vmsgtu.vx v3, v30, \thresh +vmor.mm v3, v3, v20 // v3 = hev: > thresh +vzext.vf2 v18, v1 // v18 = p1 +vmand.mmv0, v27, v3 // v0 = normal && hev +vzext.vf2 v20, v11 // v12 = q1 +vmnot.m v3, v3 // v3 = !hv +.endif li t5, 3 li a7, 124 @@ -346,6 +400,37 @@ endfunc vsse8.v v6, (\dst), \stride, v0.t .endif +.if \normal +vmand.mmv0, v27, v3 // vp8_normal_limit & !hv + +.if \inner +vnclip.wi v30, v30, 0 +filter_fmin \len, \vlen, v30, v24, v4, v6 +vad
Re: [FFmpeg-devel] [PATCH] libavformat/vapoursynth: Update to API version 4, load library at runtime
On 6/22/24 6:02 AM, Stefan Oltmanns via ffmpeg-devel wrote: I don't know the extact reason, but VapourSynth is not just a library like avisynth, but an application that uses Python, meaning a lot of dependencies. If we want to be technical, then yes, VapourSynth is just a library, with bindings to integrate it into Python. Lua bindings used to exist in mpv, but were removed several years ago; I don't know if those still exist somewhere externally. Maybe someone's tried writing Ruby or JS bindings for it, crazier things have happened. Python is the thing that provides the ability to execute scripts, not VapourSynth/VSScript[.dll|.so|.dylib] itself. Additionally VapourSynth can nowadays be installed using pip, so no reason to package it for distros anymore. > As distros probably won't package VapourSynth as it can be installed > using pip, they probably won't build ffmpeg with VapourSynth support, > because they don't have the headers on the build system. > Even when someone decides to build ffmpeg for themself with VapourSynth > support, it will fail unless they have manually build VapourSynth, > because pip won't install any header. > That was my motivation to include those headers. Is there a specific > rule when it is allowed to include headers for external libaries? > Distros don't really care about whether something is installable via pip before providing their own packages, and this was even acknowledged by upstream Python/pip with the recent move to the venv/--break-system-packages thing. What a distro decides to package or not package in conjunction with enabling support for it in FFmpeg relates directly to their native repository system. This would also apply to a project like libdovi; if it's going to be provided and enabled in a distro's FFmpeg package, they aren't going to take the stance of 'users will just install it through their Rust environment first' - the distro will have to provide a package for it for the distro's FFmpeg package to enable it. I changed it, so that it loads the library at runtime when a VapourSynth script should be opened, just like AviSynth does. On Windows the DLL from VapourSynth is not installed in the system directory, but the location is stored in the Registry. Therefore I added some code to read that information from the registry. That function is in the wrong place. I thought that to, should it be in /compat as w32registry.h or something like that? > But what exactly should it contain? I could make a function that would be used like get_w32_regsitry_str(HKEY_CURRENT_USER, L"SOFTWARE\\VapourSynth", L"VSScriptDLL"); That would return a utf8 string on success and NULL on failure I would say either unify the logic inside of vs_load_library with the minimum of Windows-specific things still cordoned off behind an ifdef, or move the function (again, still behind an ifdef) to just above where vs_load_library is. It was mainly that putting it inside a big block of header #includes isn't the right place for that. Have you tested whether simply adding the directory VapourSynth.dll and VSScript.dll reside in to the %PATH% gets around the need to read locations from the registry? Without adding it to the %PATH%, you could use Windows' own DLL loading rules to test it (just plop ffmpeg.exe down in the same directory and run it when navigated into that directory). But that would still contain 3 Windows-specific constants in the function call. Also is it useful to write the literals as utf-8 just for them to be converted to wchar again or should it just take WCHAR and return utf8? Or shoulds the entire function be located in /compat/vapoursynth/w32_vsscript_dll.h as "get_w32_vsscript_dll" or something similar? I'm definitely not the person to ask about the text encoding stuff. ___ 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] libavformat/vapoursynth: Update to API version 4, load library at runtime
Am 22.06.24 um 20:23 schrieb Stephen Hutchinson: On 6/22/24 6:02 AM, Stefan Oltmanns via ffmpeg-devel wrote: I don't know the extact reason, but VapourSynth is not just a library like avisynth, but an application that uses Python, meaning a lot of dependencies. If we want to be technical, then yes, VapourSynth is just a library, with bindings to integrate it into Python. Lua bindings used to exist in mpv, but were removed several years ago; I don't know if those still exist somewhere externally. Maybe someone's tried writing Ruby or JS bindings for it, crazier things have happened. Python is the thing that provides the ability to execute scripts, not VapourSynth/VSScript[.dll|.so|.dylib] itself. Technically yes, but a library that is not mostly self-contained like for example libx264, but one with massive dependencies to Python. That's why you might not want to link to VapourSynth even if you have packaged it. Additionally VapourSynth can nowadays be installed using pip, so no reason to package it for distros anymore. > As distros probably won't package VapourSynth as it can be installed > using pip, they probably won't build ffmpeg with VapourSynth support, > because they don't have the headers on the build system. > Even when someone decides to build ffmpeg for themself with VapourSynth > support, it will fail unless they have manually build VapourSynth, > because pip won't install any header. > That was my motivation to include those headers. Is there a specific > rule when it is allowed to include headers for external libaries? > Distros don't really care about whether something is installable via pip before providing their own packages, and this was even acknowledged by upstream Python/pip with the recent move to the venv/--break-system-packages thing. What a distro decides to package or not package in conjunction with enabling support for it in FFmpeg relates directly to their native repository system. This would also apply to a project like libdovi; if it's going to be provided and enabled in a distro's FFmpeg package, they aren't going to take the stance of 'users will just install it through their Rust environment first' - the distro will have to provide a package for it for the distro's FFmpeg package to enable it. What I mean before a distro will include something there needs to be a need for that and a maintainer for that package. If people will just use pip no one will ask for that package to be included in the distro and it's difficult to find someone to maintain it. The pip vs. distro packet manager is in my experience mostly a result of an application that is provided by the distro that has Python dependencies to something like numpy. Later the user wants to install a application with pip, but that has a dependency to a newer numpy version. Then the solutions are what you have described. I changed it, so that it loads the library at runtime when a VapourSynth script should be opened, just like AviSynth does. On Windows the DLL from VapourSynth is not installed in the system directory, but the location is stored in the Registry. Therefore I added some code to read that information from the registry. That function is in the wrong place. I thought that to, should it be in /compat as w32registry.h or something like that? > But what exactly should it contain? I could make a function that would be used like get_w32_regsitry_str(HKEY_CURRENT_USER, L"SOFTWARE\\VapourSynth", L"VSScriptDLL"); That would return a utf8 string on success and NULL on failure I would say either unify the logic inside of vs_load_library with the minimum of Windows-specific things still cordoned off behind an ifdef, or move the function (again, still behind an ifdef) to just above where vs_load_library is. It was mainly that putting it inside a big block of header #includes isn't the right place for that. Ah ok, I see. I made it like this to not have platform-specific code at different places, but if it's preferred at another place, that's fine. Have you tested whether simply adding the directory VapourSynth.dll and VSScript.dll reside in to the %PATH% gets around the need to read locations from the registry? Without adding it to the %PATH%, you could use Windows' own DLL loading rules to test it (just plop ffmpeg.exe down in the same directory and run it when navigated into that directory). Yes, that works and is fallback when no registry entries are found (for portable packages). But when a user has installed VapourSynth and wants to use ffmpeg with it it's quite inconvenient to force him to copy the DLL somewhere else. It might also create a problem: When the version of VSScript.dll does not match the version of the installed Vapoursynth (because it was updated) that could cause a problem. Reading the registry entry to load the VSScript.dll is the way to go as recommended by the VapourSynth auhtor. But that would still contain 3 Window
Re: [FFmpeg-devel] [RFC]] swscale modernization proposal
On Sat, Jun 22, 2024 at 05:10:28PM +0200, Niklas Haas wrote: > On Sat, 22 Jun 2024 15:23:22 +0100 Andrew Sayers > wrote: > > On Sat, Jun 22, 2024 at 03:13:34PM +0200, Niklas Haas wrote: > > [...] > > > > > > ## Comments / feedback? > > > > > > Does the above approach seem reasonable? How do people feel about > > > introducing > > > a new API vs. trying to hammer the existing API into the shape I want it > > > to be? > > > > > > I've attached an example of what could end up looking like. If > > > there is broad agreement on this design, I will move on to an > > > implementation. > > > > API users seem to have difficulty with this type of big change[[1], > > and doing the interface before the implementation means there's less > > reason for developers to switch while you're still looking for feedback. > > > > What's the plan to bring them along? > > Since SwsContext is entirely internal, we can continue providing the > current API on top of whatever internal abstractions we arrive at. As > a trivial example, sws_scale() can construct a temporary AVFrame based > on the provided information, and simply pass that to avscale_frame(). So > I don't think legacy API users are at risk, or pressure to switch, > unless they want access to *new* functionality. > > For that, the harder step is moving from sws_scale() to > sws_scale_frame(). This is something API users can *already* do. By > contrast, moving from sws_scale_frame() to avscale_frame() should > hopefully be simple, since it just requires making sure the AVFrame is > correctly tagged. Usually, the flow is in the opposite direction - users > receive a correctly tagged AVFrame and manually forward this information > to the SwsContext. So, most of the time, moving to a fully AVFrame-based > API will result in deleting code, rather than adding it. > > If we wanted to maximize the transition comfort, we should consider > re-using the sws_scale_frame() entrypoint directly. The main reason I am > hesitant to do this is because sws_scale_frame() is currently tied to > the stateful configuration of SwsContext, and mostly ignores the AVFrame > metadata. While changing that is possible, it possibly presents a bigger > API break than simply introducing a new function. I agree we should keep using the same swscale.h header. It matches the library name thats installed (thats also what the user expects and what (s)he is used to), and its what users #include today. Also its not a audio? scaler so the A is confusing. And sws_scale_frame() should be used obviously if thats as you say does "maximize the transition comfort" Maybe simply adding an option for the library user to set the behavior (favour AVFrame properties vs initial properties) And then eventually deprecate and phase out the initial ones The big advantage here is that we capture all users, noone stays on the old API. And the transition is also simpler, if its just a flag to flip for someone to try the new fully stateless system. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact 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/8 v3] avutil/stereo3d add a Monoscopic view enum value
On 6/22/2024 12:31 PM, James Almer wrote:
We need a way to signal the frame has a single view that doesn't map to any
particular eye, and it should be the default one.
Signed-off-by: James Almer
---
Now updating all the fate test...
The 3D ones will be updated again in the following commits once ffprobe is
adapted to properly handle the view field.
Ok, turns out AVStereo3DView is not by Derek from a few days ago but by
Vittorio from 7 years ago, so of course this change is not ok.
The new value would need to be added last and moved to the beginning
after a major bump.
libavutil/stereo3d.c | 3 ++-
libavutil/stereo3d.h | 9 +++--
tests/ref/fate/matroska-spherical-mono | 2 +-
tests/ref/fate/matroska-spherical-mono-remux | 4 ++--
tests/ref/fate/matroska-stereo_mode | 8
tests/ref/fate/matroska-vp8-alpha-remux | 2 +-
tests/ref/fate/mov-spherical-mono| 2 +-
7 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/libavutil/stereo3d.c b/libavutil/stereo3d.c
index 19e81e4124..0c0cad127c 100644
--- a/libavutil/stereo3d.c
+++ b/libavutil/stereo3d.c
@@ -68,9 +68,10 @@ static const char * const stereo3d_type_names[] = {
};
static const char * const stereo3d_view_names[] = {
-[AV_STEREO3D_VIEW_PACKED] = "packed",
+[AV_STEREO3D_VIEW_MONO] = "monoscopic",
[AV_STEREO3D_VIEW_LEFT] = "left",
[AV_STEREO3D_VIEW_RIGHT] = "right",
+[AV_STEREO3D_VIEW_PACKED] = "packed",
};
static const char * const stereo3d_primary_eye_names[] = {
diff --git a/libavutil/stereo3d.h b/libavutil/stereo3d.h
index 00a5c3900e..77340f72b2 100644
--- a/libavutil/stereo3d.h
+++ b/libavutil/stereo3d.h
@@ -143,9 +143,9 @@ enum AVStereo3DType {
*/
enum AVStereo3DView {
/**
- * Frame contains two packed views.
+ * Frame is monoscopic.
*/
-AV_STEREO3D_VIEW_PACKED,
+AV_STEREO3D_VIEW_MONO,
/**
* Frame contains only the left view.
@@ -156,6 +156,11 @@ enum AVStereo3DView {
* Frame contains only the right view.
*/
AV_STEREO3D_VIEW_RIGHT,
+
+/**
+ * Frame contains two packed views.
+ */
+AV_STEREO3D_VIEW_PACKED,
};
/**
diff --git a/tests/ref/fate/matroska-spherical-mono
b/tests/ref/fate/matroska-spherical-mono
index b108596350..aa17e9c624 100644
--- a/tests/ref/fate/matroska-spherical-mono
+++ b/tests/ref/fate/matroska-spherical-mono
@@ -3,7 +3,7 @@
side_data_type=Stereo 3D
type=2D
inverted=0
-view=packed
+view=monoscopic
primary_eye=none
baseline=0
horizontal_disparity_adjustment=0/1
diff --git a/tests/ref/fate/matroska-spherical-mono-remux
b/tests/ref/fate/matroska-spherical-mono-remux
index eec41b77f3..75a9b73a37 100644
--- a/tests/ref/fate/matroska-spherical-mono-remux
+++ b/tests/ref/fate/matroska-spherical-mono-remux
@@ -27,7 +27,7 @@ DISPOSITION:forced=1
side_data_type=Stereo 3D
type=2D
inverted=0
-view=packed
+view=monoscopic
primary_eye=none
baseline=0
horizontal_disparity_adjustment=0/1
@@ -56,7 +56,7 @@ DISPOSITION:forced=0
side_data_type=Stereo 3D
type=2D
inverted=0
-view=packed
+view=monoscopic
primary_eye=none
baseline=0
horizontal_disparity_adjustment=0/1
diff --git a/tests/ref/fate/matroska-stereo_mode
b/tests/ref/fate/matroska-stereo_mode
index 26c325b20e..e35425ae76 100644
--- a/tests/ref/fate/matroska-stereo_mode
+++ b/tests/ref/fate/matroska-stereo_mode
@@ -132,7 +132,7 @@ TAG:DURATION=00:00:10.0
side_data_type=Stereo 3D
type=side by side
inverted=0
-view=packed
+view=monoscopic
primary_eye=none
baseline=0
horizontal_disparity_adjustment=0/1
@@ -152,7 +152,7 @@ TAG:DURATION=00:00:10.0
side_data_type=Stereo 3D
type=top and bottom
inverted=1
-view=packed
+view=monoscopic
primary_eye=none
baseline=0
horizontal_disparity_adjustment=0/1
@@ -170,7 +170,7 @@ TAG:DURATION=00:00:10.0
side_data_type=Stereo 3D
type=interleaved lines
inverted=1
-view=packed
+view=monoscopic
primary_eye=none
baseline=0
horizontal_disparity_adjustment=0/1
@@ -189,7 +189,7 @@ TAG:DURATION=00:00:10.0
side_data_type=Stereo 3D
type=interleaved columns
inverted=1
-view=packed
+view=monoscopic
primary_eye=none
baseline=0
horizontal_disparity_adjustment=0/1
diff --git a/tests/ref/fate/matroska-vp8-alpha-remux
b/tests/ref/fate/matroska-vp8-alpha-remux
index 06bcc4b4ba..814463eeda 100644
--- a/tests/ref/fate/matroska-vp8-alpha-remux
+++ b/tests/ref/fate/matroska-vp8-alpha-remux
@@ -35,7 +35,7 @@ DISPOSITION:still_image=0
side_data_type=Stereo 3D
type=2D
inverted=0
-view=packed
+view=monoscopic
primary_eye=none
baseline=0
horizontal_disparity_adjustment=0/1
diff --git a/tests/ref/fate/mov-spherical-mono
b/tests/ref/fate/mov-spherical-mono
index b108596350..aa17e9c624 100644
--- a/tests/ref/fate/mov-spherical-mono
+++ b/tests/ref/fate/mov-spherical-mono
@@ -3,7 +3,7 @@
side_data_type=Stereo
Re: [FFmpeg-devel] [PATCH 2/8 v2] avutil/stereo3d: add a Stereo3D type to signal that the packing is defined by the view field
On 6/22/2024 12:31 PM, James Almer wrote:
Given that a video stream/frame may have only one view coded, or both packed in
an undefined way, and as the values of AVStereo3DView and AVStereo3DType may
clash (namely if type is AV_STEREO3D_2D, then AV_STEREO3D_VIEW_PACKED would be
invalid, and if it's anything other than it, then only AV_STEREO3D_VIEW_PACKED
would be valid), this commit adds a new type value AV_STEREO3D_VIEW that
signals the user that AVStereo3D.view contains information about the nature of
the stream, with the added constrain that AVStereo3D.view should be ignored if
AVStereo3D.type is anything other than AV_STEREO3D_VIEW.
Signed-off-by: James Almer
---
This is the only way i could think of to work around the fact AVStereo3DType
and AVStereo3DView just can't work well together if we want to keep AVStereo
backwards compatible.
And this is also not ok given that type == AV_STEREO3D_FRAMESEQUENCE can
(and should) go alongside view == AV_STEREO3D_VIEW_{LEFT,RIGHT}. Plus
the fact AVStereo3DView has been around for a while, so the
inconsistencies (like type 2D and view packed being default) are not new...
I'll look at this a bit more and send a new set.
libavutil/stereo3d.c | 1 +
libavutil/stereo3d.h | 11 ++-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/libavutil/stereo3d.c b/libavutil/stereo3d.c
index 0c0cad127c..e8e5030db9 100644
--- a/libavutil/stereo3d.c
+++ b/libavutil/stereo3d.c
@@ -65,6 +65,7 @@ static const char * const stereo3d_type_names[] = {
[AV_STEREO3D_SIDEBYSIDE_QUINCUNX] = "side by side (quincunx subsampling)",
[AV_STEREO3D_LINES] = "interleaved lines",
[AV_STEREO3D_COLUMNS] = "interleaved columns",
+[AV_STEREO3D_VIEW]= "view defined",
};
static const char * const stereo3d_view_names[] = {
diff --git a/libavutil/stereo3d.h b/libavutil/stereo3d.h
index 77340f72b2..e3af519e03 100644
--- a/libavutil/stereo3d.h
+++ b/libavutil/stereo3d.h
@@ -136,6 +136,14 @@ enum AVStereo3DType {
* @endcode
*/
AV_STEREO3D_COLUMNS,
+
+/**
+ * Video may be monoscopic, or stereoscopic where either the
+ * packing is unknown or only one view is present.
+ *
+ * @see AVStereo3DView
+ */
+AV_STEREO3D_VIEW,
};
/**
@@ -207,7 +215,8 @@ typedef struct AVStereo3D {
int flags;
/**
- * Determines which views are packed.
+ * Determines which views are packed. This field should be ignored when
+ * @ref type is set to anything other than AV_STEREO3D_VIEW.
*/
enum AVStereo3DView view;
___
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/stereo3d: change baseline and horizontal FOV to rationals
This avoids hardcoding any implementation-specific limitiations as
part of the API, and allows for future expandability.
This also allows API users to more conveniently convert the
values into floats without hardcoding specific conversion constants.
The draft implementation of this mechanism for the draft of
AVTransport uses rationals for these particular fields.
The API was committed 2 days ago, so changing these fields now
is within the realms of acceptable.
---
fftools/ffprobe.c| 4 ++--
libavformat/dump.c | 9 +
libavformat/mov.c| 9 ++---
libavutil/stereo3d.h | 8
tests/ref/fate/matroska-spherical-mono | 4 ++--
tests/ref/fate/matroska-spherical-mono-remux | 8
tests/ref/fate/matroska-stereo_mode | 16
tests/ref/fate/matroska-vp8-alpha-remux | 4 ++--
tests/ref/fate/mov-spherical-mono| 4 ++--
9 files changed, 35 insertions(+), 31 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index d7ba980ff9..2da928b7c3 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2546,9 +2546,9 @@ static void print_pkt_side_data(WriterContext *w,
print_int("inverted", !!(stereo->flags & AV_STEREO3D_FLAG_INVERT));
print_str("view", av_stereo3d_view_name(stereo->view));
print_str("primary_eye",
av_stereo3d_primary_eye_name(stereo->primary_eye));
-print_int("baseline", stereo->baseline);
+print_q("baseline", stereo->baseline, '/');
print_q("horizontal_disparity_adjustment",
stereo->horizontal_disparity_adjustment, '/');
-print_int("horizontal_field_of_view",
stereo->horizontal_field_of_view);
+print_q("horizontal_field_of_view",
stereo->horizontal_field_of_view, '/');
} else if (sd->type == AV_PKT_DATA_SPHERICAL) {
const AVSphericalMapping *spherical = (AVSphericalMapping
*)sd->data;
print_str("projection",
av_spherical_projection_name(spherical->projection));
diff --git a/libavformat/dump.c b/libavformat/dump.c
index 61a2c6a29f..ac7d3038ab 100644
--- a/libavformat/dump.c
+++ b/libavformat/dump.c
@@ -262,13 +262,14 @@ static void dump_stereo3d(void *ctx, const
AVPacketSideData *sd, int log_level)
av_log(ctx, log_level, "%s, view: %s, primary eye: %s",
av_stereo3d_type_name(stereo->type),
av_stereo3d_view_name(stereo->view),
av_stereo3d_primary_eye_name(stereo->primary_eye));
-if (stereo->baseline)
-av_log(ctx, log_level, ", baseline: %"PRIu32"", stereo->baseline);
+if (stereo->baseline.num && stereo->baseline.den)
+av_log(ctx, log_level, ", baseline: %d/%d", stereo->baseline.num,
stereo->baseline.den);
if (stereo->horizontal_disparity_adjustment.num &&
stereo->horizontal_disparity_adjustment.den)
av_log(ctx, log_level, ", horizontal_disparity_adjustment: %d/%d",
stereo->horizontal_disparity_adjustment.num,
stereo->horizontal_disparity_adjustment.den);
-if (stereo->horizontal_field_of_view)
-av_log(ctx, log_level, ", horizontal_field_of_view: %"PRIu32"",
stereo->horizontal_field_of_view);
+if (stereo->horizontal_field_of_view.num &&
stereo->horizontal_field_of_view.den)
+av_log(ctx, log_level, ", horizontal_field_of_view: %d/%d",
stereo->horizontal_field_of_view.num,
+ stereo->horizontal_field_of_view.den);
if (stereo->flags & AV_STEREO3D_FLAG_INVERT)
av_log(ctx, log_level, " (inverted)");
diff --git a/libavformat/mov.c b/libavformat/mov.c
index f08fec3fb6..64cd17e770 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -6545,7 +6545,8 @@ static int mov_read_eyes(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
MOVStreamContext *sc;
int size, flags = 0;
int64_t remaining;
-uint32_t tag, baseline = 0;
+uint32_t tag;
+AVRational baseline = av_make_q(0, 0);
enum AVStereo3DView view = AV_STEREO3D_VIEW_PACKED;
enum AVStereo3DPrimaryEye primary_eye = AV_PRIMARY_EYE_NONE;
AVRational horizontal_disparity_adjustment = { 0, 1 };
@@ -6642,7 +6643,8 @@ static int mov_read_eyes(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
avio_skip(pb, 1); // version
avio_skip(pb, 3); // flags
-baseline = avio_rb32(pb);
+baseline.num = avio_rb32(pb);
+baseline.den = 100; // micrometers
break;
}
@@ -6782,7 +6784,8 @@ static int mov_read_hfov(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
return AVERROR(ENOMEM);
}
-sc->stereo3d->horizontal_field_of_view = avio_rb32(pb);
+sc->stereo3d->horizontal_field_of_view.num = avio_rb32(pb);
+sc->stereo3d->horizontal_field_of_view.den = 1000; // thousands of a degree
return 0;
}
diff --git a/libavutil/stereo3d.h b/libavutil/stereo3d.h
index 00a5c39
Re: [FFmpeg-devel] [PATCH] lavu/stereo3d: change baseline and horizontal FOV to rationals
On 6/22/2024 5:11 PM, Lynne via ffmpeg-devel wrote:
This avoids hardcoding any implementation-specific limitiations as
part of the API, and allows for future expandability.
This also allows API users to more conveniently convert the
values into floats without hardcoding specific conversion constants.
The draft implementation of this mechanism for the draft of
AVTransport uses rationals for these particular fields.
The API was committed 2 days ago, so changing these fields now
is within the realms of acceptable.
---
fftools/ffprobe.c| 4 ++--
libavformat/dump.c | 9 +
libavformat/mov.c| 9 ++---
libavutil/stereo3d.h | 8
tests/ref/fate/matroska-spherical-mono | 4 ++--
tests/ref/fate/matroska-spherical-mono-remux | 8
tests/ref/fate/matroska-stereo_mode | 16
tests/ref/fate/matroska-vp8-alpha-remux | 4 ++--
tests/ref/fate/mov-spherical-mono| 4 ++--
9 files changed, 35 insertions(+), 31 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index d7ba980ff9..2da928b7c3 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2546,9 +2546,9 @@ static void print_pkt_side_data(WriterContext *w,
print_int("inverted", !!(stereo->flags &
AV_STEREO3D_FLAG_INVERT));
print_str("view", av_stereo3d_view_name(stereo->view));
print_str("primary_eye",
av_stereo3d_primary_eye_name(stereo->primary_eye));
-print_int("baseline", stereo->baseline);
+print_q("baseline", stereo->baseline, '/');
print_q("horizontal_disparity_adjustment",
stereo->horizontal_disparity_adjustment, '/');
-print_int("horizontal_field_of_view",
stereo->horizontal_field_of_view);
+print_q("horizontal_field_of_view",
stereo->horizontal_field_of_view, '/');
} else if (sd->type == AV_PKT_DATA_SPHERICAL) {
const AVSphericalMapping *spherical = (AVSphericalMapping
*)sd->data;
print_str("projection",
av_spherical_projection_name(spherical->projection));
diff --git a/libavformat/dump.c b/libavformat/dump.c
index 61a2c6a29f..ac7d3038ab 100644
--- a/libavformat/dump.c
+++ b/libavformat/dump.c
@@ -262,13 +262,14 @@ static void dump_stereo3d(void *ctx, const
AVPacketSideData *sd, int log_level)
av_log(ctx, log_level, "%s, view: %s, primary eye: %s",
av_stereo3d_type_name(stereo->type),
av_stereo3d_view_name(stereo->view),
av_stereo3d_primary_eye_name(stereo->primary_eye));
-if (stereo->baseline)
-av_log(ctx, log_level, ", baseline: %"PRIu32"", stereo->baseline);
+if (stereo->baseline.num && stereo->baseline.den)
+av_log(ctx, log_level, ", baseline: %d/%d", stereo->baseline.num,
stereo->baseline.den);
if (stereo->horizontal_disparity_adjustment.num &&
stereo->horizontal_disparity_adjustment.den)
av_log(ctx, log_level, ", horizontal_disparity_adjustment: %d/%d",
stereo->horizontal_disparity_adjustment.num,
stereo->horizontal_disparity_adjustment.den);
-if (stereo->horizontal_field_of_view)
-av_log(ctx, log_level, ", horizontal_field_of_view: %"PRIu32"",
stereo->horizontal_field_of_view);
+if (stereo->horizontal_field_of_view.num &&
stereo->horizontal_field_of_view.den)
+av_log(ctx, log_level, ", horizontal_field_of_view: %d/%d",
stereo->horizontal_field_of_view.num,
+ stereo->horizontal_field_of_view.den);
if (stereo->flags & AV_STEREO3D_FLAG_INVERT)
av_log(ctx, log_level, " (inverted)");
diff --git a/libavformat/mov.c b/libavformat/mov.c
index f08fec3fb6..64cd17e770 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -6545,7 +6545,8 @@ static int mov_read_eyes(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
MOVStreamContext *sc;
int size, flags = 0;
int64_t remaining;
-uint32_t tag, baseline = 0;
+uint32_t tag;
+AVRational baseline = av_make_q(0, 0);
enum AVStereo3DView view = AV_STEREO3D_VIEW_PACKED;
enum AVStereo3DPrimaryEye primary_eye = AV_PRIMARY_EYE_NONE;
AVRational horizontal_disparity_adjustment = { 0, 1 };
@@ -6642,7 +6643,8 @@ static int mov_read_eyes(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
avio_skip(pb, 1); // version
avio_skip(pb, 3); // flags
-baseline = avio_rb32(pb);
+baseline.num = avio_rb32(pb);
+baseline.den = 100; // micrometers
break;
}
@@ -6782,7 +6784,8 @@ static int mov_read_hfov(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
return AVERROR(ENOMEM);
}
-sc->stereo3d->horizontal_field_of_view = avio_rb32(pb);
+sc->stereo3d->horizontal_field_of_view.num = avio_rb32(pb);
+sc->stereo3d->horizontal_field_of_view.den = 1000; // thousands of
Re: [FFmpeg-devel] [PATCH 2/2] avformat/mov: default to Monoscopic view when parsing eyes box
On Fri, Jun 21, 2024 at 10:25:31PM -0300, James Almer wrote: > Signed-off-by: James Almer > --- > libavformat/mov.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) doesnt apply automatically with "git am" with the v2 Applying: avformat/mov: default to Monoscopic view when parsing eyes box error: sha1 information is lacking or useless (libavformat/mov.c). error: could not build fake ancestor Patch failed at 0001 avformat/mov: default to Monoscopic view when parsing eyes box it applies with patch but inability to automatically apply patches could affect tools which try to test patches posted git am --show-current-patch=diff | patch -p1 patching file libavformat/mov.c Hunk #1 succeeded at 6546 with fuzz 2. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is a danger to trust the dream we wish for rather than the science we have, -- Dr. Kenneth Brown 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] lavu/stereo3d: change baseline and horizontal FOV to rationals
On 22/06/2024 22:19, James Almer wrote:
On 6/22/2024 5:11 PM, Lynne via ffmpeg-devel wrote:
This avoids hardcoding any implementation-specific limitiations as
part of the API, and allows for future expandability.
This also allows API users to more conveniently convert the
values into floats without hardcoding specific conversion constants.
The draft implementation of this mechanism for the draft of
AVTransport uses rationals for these particular fields.
The API was committed 2 days ago, so changing these fields now
is within the realms of acceptable.
---
fftools/ffprobe.c | 4 ++--
libavformat/dump.c | 9 +
libavformat/mov.c | 9 ++---
libavutil/stereo3d.h | 8
tests/ref/fate/matroska-spherical-mono | 4 ++--
tests/ref/fate/matroska-spherical-mono-remux | 8
tests/ref/fate/matroska-stereo_mode | 16
tests/ref/fate/matroska-vp8-alpha-remux | 4 ++--
tests/ref/fate/mov-spherical-mono | 4 ++--
9 files changed, 35 insertions(+), 31 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index d7ba980ff9..2da928b7c3 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2546,9 +2546,9 @@ static void print_pkt_side_data(WriterContext *w,
print_int("inverted", !!(stereo->flags &
AV_STEREO3D_FLAG_INVERT));
print_str("view", av_stereo3d_view_name(stereo->view));
print_str("primary_eye",
av_stereo3d_primary_eye_name(stereo->primary_eye));
- print_int("baseline", stereo->baseline);
+ print_q("baseline", stereo->baseline, '/');
print_q("horizontal_disparity_adjustment", stereo-
>horizontal_disparity_adjustment, '/');
- print_int("horizontal_field_of_view", stereo-
>horizontal_field_of_view);
+ print_q("horizontal_field_of_view", stereo-
>horizontal_field_of_view, '/');
} else if (sd->type == AV_PKT_DATA_SPHERICAL) {
const AVSphericalMapping *spherical =
(AVSphericalMapping *)sd->data;
print_str("projection",
av_spherical_projection_name(spherical->projection));
diff --git a/libavformat/dump.c b/libavformat/dump.c
index 61a2c6a29f..ac7d3038ab 100644
--- a/libavformat/dump.c
+++ b/libavformat/dump.c
@@ -262,13 +262,14 @@ static void dump_stereo3d(void *ctx, const
AVPacketSideData *sd, int log_level)
av_log(ctx, log_level, "%s, view: %s, primary eye: %s",
av_stereo3d_type_name(stereo->type),
av_stereo3d_view_name(stereo->view),
av_stereo3d_primary_eye_name(stereo->primary_eye));
- if (stereo->baseline)
- av_log(ctx, log_level, ", baseline: %"PRIu32"", stereo-
>baseline);
+ if (stereo->baseline.num && stereo->baseline.den)
+ av_log(ctx, log_level, ", baseline: %d/%d", stereo-
>baseline.num, stereo->baseline.den);
if (stereo->horizontal_disparity_adjustment.num && stereo-
>horizontal_disparity_adjustment.den)
av_log(ctx, log_level, ", horizontal_disparity_adjustment:
%d/%d",
stereo->horizontal_disparity_adjustment.num, stereo-
>horizontal_disparity_adjustment.den);
- if (stereo->horizontal_field_of_view)
- av_log(ctx, log_level, ", horizontal_field_of_view:
%"PRIu32"", stereo->horizontal_field_of_view);
+ if (stereo->horizontal_field_of_view.num && stereo-
>horizontal_field_of_view.den)
+ av_log(ctx, log_level, ", horizontal_field_of_view: %d/%d",
stereo->horizontal_field_of_view.num,
+ stereo->horizontal_field_of_view.den);
if (stereo->flags & AV_STEREO3D_FLAG_INVERT)
av_log(ctx, log_level, " (inverted)");
diff --git a/libavformat/mov.c b/libavformat/mov.c
index f08fec3fb6..64cd17e770 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -6545,7 +6545,8 @@ static int mov_read_eyes(MOVContext *c,
AVIOContext *pb, MOVAtom atom)
MOVStreamContext *sc;
int size, flags = 0;
int64_t remaining;
- uint32_t tag, baseline = 0;
+ uint32_t tag;
+ AVRational baseline = av_make_q(0, 0);
enum AVStereo3DView view = AV_STEREO3D_VIEW_PACKED;
enum AVStereo3DPrimaryEye primary_eye = AV_PRIMARY_EYE_NONE;
AVRational horizontal_disparity_adjustment = { 0, 1 };
@@ -6642,7 +6643,8 @@ static int mov_read_eyes(MOVContext *c,
AVIOContext *pb, MOVAtom atom)
avio_skip(pb, 1); // version
avio_skip(pb, 3); // flags
- baseline = avio_rb32(pb);
+ baseline.num = avio_rb32(pb);
+ baseline.den = 100; // micrometers
break;
}
@@ -6782,7 +6784,8 @@ static int mov_read_hfov(MOVContext *c,
AVIOContext *pb, MOVAtom atom)
return AVERROR(ENOMEM);
}
- sc->stereo3d->horizontal_field_of_view = avio_rb32(pb);
+ sc->stereo3d->horizontal_field_of_view.num = avio_rb32(pb);
+ sc->stereo3d->horiz
Re: [FFmpeg-devel] [PATCH] lavu/stereo3d: change baseline and horizontal FOV to rationals
On 6/22/2024 6:26 PM, Lynne via ffmpeg-devel wrote:
On 22/06/2024 22:19, James Almer wrote:
On 6/22/2024 5:11 PM, Lynne via ffmpeg-devel wrote:
This avoids hardcoding any implementation-specific limitiations as
part of the API, and allows for future expandability.
This also allows API users to more conveniently convert the
values into floats without hardcoding specific conversion constants.
The draft implementation of this mechanism for the draft of
AVTransport uses rationals for these particular fields.
The API was committed 2 days ago, so changing these fields now
is within the realms of acceptable.
---
fftools/ffprobe.c | 4 ++--
libavformat/dump.c | 9 +
libavformat/mov.c | 9 ++---
libavutil/stereo3d.h | 8
tests/ref/fate/matroska-spherical-mono | 4 ++--
tests/ref/fate/matroska-spherical-mono-remux | 8
tests/ref/fate/matroska-stereo_mode | 16
tests/ref/fate/matroska-vp8-alpha-remux | 4 ++--
tests/ref/fate/mov-spherical-mono | 4 ++--
9 files changed, 35 insertions(+), 31 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index d7ba980ff9..2da928b7c3 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2546,9 +2546,9 @@ static void print_pkt_side_data(WriterContext *w,
print_int("inverted", !!(stereo->flags &
AV_STEREO3D_FLAG_INVERT));
print_str("view", av_stereo3d_view_name(stereo->view));
print_str("primary_eye",
av_stereo3d_primary_eye_name(stereo->primary_eye));
- print_int("baseline", stereo->baseline);
+ print_q("baseline", stereo->baseline, '/');
print_q("horizontal_disparity_adjustment", stereo-
>horizontal_disparity_adjustment, '/');
- print_int("horizontal_field_of_view", stereo-
>horizontal_field_of_view);
+ print_q("horizontal_field_of_view", stereo-
>horizontal_field_of_view, '/');
} else if (sd->type == AV_PKT_DATA_SPHERICAL) {
const AVSphericalMapping *spherical =
(AVSphericalMapping *)sd->data;
print_str("projection",
av_spherical_projection_name(spherical->projection));
diff --git a/libavformat/dump.c b/libavformat/dump.c
index 61a2c6a29f..ac7d3038ab 100644
--- a/libavformat/dump.c
+++ b/libavformat/dump.c
@@ -262,13 +262,14 @@ static void dump_stereo3d(void *ctx, const
AVPacketSideData *sd, int log_level)
av_log(ctx, log_level, "%s, view: %s, primary eye: %s",
av_stereo3d_type_name(stereo->type),
av_stereo3d_view_name(stereo->view),
av_stereo3d_primary_eye_name(stereo->primary_eye));
- if (stereo->baseline)
- av_log(ctx, log_level, ", baseline: %"PRIu32"", stereo-
>baseline);
+ if (stereo->baseline.num && stereo->baseline.den)
+ av_log(ctx, log_level, ", baseline: %d/%d", stereo-
>baseline.num, stereo->baseline.den);
if (stereo->horizontal_disparity_adjustment.num && stereo-
>horizontal_disparity_adjustment.den)
av_log(ctx, log_level, ", horizontal_disparity_adjustment:
%d/%d",
stereo->horizontal_disparity_adjustment.num, stereo-
>horizontal_disparity_adjustment.den);
- if (stereo->horizontal_field_of_view)
- av_log(ctx, log_level, ", horizontal_field_of_view:
%"PRIu32"", stereo->horizontal_field_of_view);
+ if (stereo->horizontal_field_of_view.num && stereo-
>horizontal_field_of_view.den)
+ av_log(ctx, log_level, ", horizontal_field_of_view: %d/%d",
stereo->horizontal_field_of_view.num,
+ stereo->horizontal_field_of_view.den);
if (stereo->flags & AV_STEREO3D_FLAG_INVERT)
av_log(ctx, log_level, " (inverted)");
diff --git a/libavformat/mov.c b/libavformat/mov.c
index f08fec3fb6..64cd17e770 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -6545,7 +6545,8 @@ static int mov_read_eyes(MOVContext *c,
AVIOContext *pb, MOVAtom atom)
MOVStreamContext *sc;
int size, flags = 0;
int64_t remaining;
- uint32_t tag, baseline = 0;
+ uint32_t tag;
+ AVRational baseline = av_make_q(0, 0);
enum AVStereo3DView view = AV_STEREO3D_VIEW_PACKED;
enum AVStereo3DPrimaryEye primary_eye = AV_PRIMARY_EYE_NONE;
AVRational horizontal_disparity_adjustment = { 0, 1 };
@@ -6642,7 +6643,8 @@ static int mov_read_eyes(MOVContext *c,
AVIOContext *pb, MOVAtom atom)
avio_skip(pb, 1); // version
avio_skip(pb, 3); // flags
- baseline = avio_rb32(pb);
+ baseline.num = avio_rb32(pb);
+ baseline.den = 100; // micrometers
break;
}
@@ -6782,7 +6784,8 @@ static int mov_read_hfov(MOVContext *c,
AVIOContext *pb, MOVAtom atom)
return AVERROR(ENOMEM);
}
- sc->stereo3d->horizontal_field_of_view = avio_rb32(pb);
+ sc->stereo3d->horizontal_field_
Re: [FFmpeg-devel] [PATCH 2/2] avformat/mov: default to Monoscopic view when parsing eyes box
On 6/22/2024 6:25 PM, Michael Niedermayer wrote: On Fri, Jun 21, 2024 at 10:25:31PM -0300, James Almer wrote: Signed-off-by: James Almer --- libavformat/mov.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) doesnt apply automatically with "git am" with the v2 Applying: avformat/mov: default to Monoscopic view when parsing eyes box error: sha1 information is lacking or useless (libavformat/mov.c). error: could not build fake ancestor Patch failed at 0001 avformat/mov: default to Monoscopic view when parsing eyes box it applies with patch but inability to automatically apply patches could affect tools which try to test patches posted git am --show-current-patch=diff | patch -p1 patching file libavformat/mov.c Hunk #1 succeeded at 6546 with fuzz 2. Are you sure your tree is clean and up to date? There's no reason for this patch to not apply, standalone or after 1/1 v1 or v2. In any case, this set and the next are withdrawn as i realized i mistakenly assumed AVStereo3DView was a new enum, when it's not. I'll be sending a new set later. thx [...] ___ 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] lavu/stereo3d: change baseline and horizontal FOV to rationals
On 22/06/2024 23:30, James Almer wrote:
On 6/22/2024 6:26 PM, Lynne via ffmpeg-devel wrote:
On 22/06/2024 22:19, James Almer wrote:
On 6/22/2024 5:11 PM, Lynne via ffmpeg-devel wrote:
This avoids hardcoding any implementation-specific limitiations as
part of the API, and allows for future expandability.
This also allows API users to more conveniently convert the
values into floats without hardcoding specific conversion constants.
The draft implementation of this mechanism for the draft of
AVTransport uses rationals for these particular fields.
The API was committed 2 days ago, so changing these fields now
is within the realms of acceptable.
---
fftools/ffprobe.c | 4 ++--
libavformat/dump.c | 9 +
libavformat/mov.c | 9 ++---
libavutil/stereo3d.h | 8
tests/ref/fate/matroska-spherical-mono | 4 ++--
tests/ref/fate/matroska-spherical-mono-remux | 8
tests/ref/fate/matroska-stereo_mode | 16
tests/ref/fate/matroska-vp8-alpha-remux | 4 ++--
tests/ref/fate/mov-spherical-mono | 4 ++--
9 files changed, 35 insertions(+), 31 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index d7ba980ff9..2da928b7c3 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2546,9 +2546,9 @@ static void print_pkt_side_data(WriterContext *w,
print_int("inverted", !!(stereo->flags &
AV_STEREO3D_FLAG_INVERT));
print_str("view", av_stereo3d_view_name(stereo->view));
print_str("primary_eye",
av_stereo3d_primary_eye_name(stereo->primary_eye));
- print_int("baseline", stereo->baseline);
+ print_q("baseline", stereo->baseline, '/');
print_q("horizontal_disparity_adjustment", stereo-
>horizontal_disparity_adjustment, '/');
- print_int("horizontal_field_of_view", stereo-
>horizontal_field_of_view);
+ print_q("horizontal_field_of_view", stereo-
>horizontal_field_of_view, '/');
} else if (sd->type == AV_PKT_DATA_SPHERICAL) {
const AVSphericalMapping *spherical =
(AVSphericalMapping *)sd->data;
print_str("projection",
av_spherical_projection_name(spherical->projection));
diff --git a/libavformat/dump.c b/libavformat/dump.c
index 61a2c6a29f..ac7d3038ab 100644
--- a/libavformat/dump.c
+++ b/libavformat/dump.c
@@ -262,13 +262,14 @@ static void dump_stereo3d(void *ctx, const
AVPacketSideData *sd, int log_level)
av_log(ctx, log_level, "%s, view: %s, primary eye: %s",
av_stereo3d_type_name(stereo->type),
av_stereo3d_view_name(stereo->view),
av_stereo3d_primary_eye_name(stereo->primary_eye));
- if (stereo->baseline)
- av_log(ctx, log_level, ", baseline: %"PRIu32"", stereo-
>baseline);
+ if (stereo->baseline.num && stereo->baseline.den)
+ av_log(ctx, log_level, ", baseline: %d/%d", stereo-
>baseline.num, stereo->baseline.den);
if (stereo->horizontal_disparity_adjustment.num && stereo-
>horizontal_disparity_adjustment.den)
av_log(ctx, log_level, ", horizontal_disparity_adjustment:
%d/%d",
stereo->horizontal_disparity_adjustment.num,
stereo- >horizontal_disparity_adjustment.den);
- if (stereo->horizontal_field_of_view)
- av_log(ctx, log_level, ", horizontal_field_of_view:
%"PRIu32"", stereo->horizontal_field_of_view);
+ if (stereo->horizontal_field_of_view.num && stereo-
>horizontal_field_of_view.den)
+ av_log(ctx, log_level, ", horizontal_field_of_view: %d/%d",
stereo->horizontal_field_of_view.num,
+ stereo->horizontal_field_of_view.den);
if (stereo->flags & AV_STEREO3D_FLAG_INVERT)
av_log(ctx, log_level, " (inverted)");
diff --git a/libavformat/mov.c b/libavformat/mov.c
index f08fec3fb6..64cd17e770 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -6545,7 +6545,8 @@ static int mov_read_eyes(MOVContext *c,
AVIOContext *pb, MOVAtom atom)
MOVStreamContext *sc;
int size, flags = 0;
int64_t remaining;
- uint32_t tag, baseline = 0;
+ uint32_t tag;
+ AVRational baseline = av_make_q(0, 0);
enum AVStereo3DView view = AV_STEREO3D_VIEW_PACKED;
enum AVStereo3DPrimaryEye primary_eye = AV_PRIMARY_EYE_NONE;
AVRational horizontal_disparity_adjustment = { 0, 1 };
@@ -6642,7 +6643,8 @@ static int mov_read_eyes(MOVContext *c,
AVIOContext *pb, MOVAtom atom)
avio_skip(pb, 1); // version
avio_skip(pb, 3); // flags
- baseline = avio_rb32(pb);
+ baseline.num = avio_rb32(pb);
+ baseline.den = 100; // micrometers
break;
}
@@ -6782,7 +6784,8 @@ static int mov_read_hfov(MOVContext *c,
AVIOContext *pb, MOVAtom atom)
return AVERROR(ENOMEM);
}
- sc->stereo3d->horizontal_field_of_view = avio_rb32(
Re: [FFmpeg-devel] [RFC]] swscale modernization proposal
On Sat, Jun 22, 2024 at 3:22 PM Niklas Haas wrote:
> Hey,
>
> As some of you know, I got contracted (by STF 2024) to work on improving
> swscale, over the course of the next couple of months. I want to share my
> current plans and gather feedback + measure sentiment.
>
> ## Problem statement
>
> The two issues I'd like to focus on for now are:
>
> 1. Lack of support for a lot of modern formats and conversions (HDR, ICtCp,
>IPTc2, BT.2020-CL, XYZ, YCgCo, Dolby Vision, ...)
> 2. Complicated context management, with cascaded contexts, threading,
> stateful
>configuration, multi-step init procedures, etc; and related bugs
>
> In order to make these feasible, some amount of internal re-organization of
> duties inside swscale is prudent.
>
> ## Proposed approach
>
> The first step is to create a new API, which will (tentatively) live in
> . This API will initially start off as a near-copy
> of the
> current swscale public API, but with the major difference that I want it
> to be
> state-free and only access metadata in terms of AVFrame properties. So
> there
> will be no independent configuration of the input chroma location etc. like
> there is currently, and no need to re-configure or re-init the context when
> feeding it frames with different properties. The goal is for users to be
> able
> to just feed it AVFrame pairs and have it internally cache expensive
> pre-processing steps as needed. Finally, avscale_* should ultimately also
> support hardware frames directly, in which case it will dispatch to some
> equivalent of scale_vulkan/vaapi/cuda or possibly even libplacebo. (But I
> will
> defer this to a future milestone)
>
> After this API is established, I want to start expanding the functionality
> in
> the following manner:
>
> ### Phase 1
>
> For basic operation, avscale_* will just dispatch to a sequence of
> swscale_*
> invocations. In the basic case, it will just directly invoke swscale with
> minimal overhead. In more advanced cases, it might resolve to a *sequence*
> of
> swscale operations, with other operations (e.g. colorspace conversions a la
> vf_colorspace) mixed in.
>
> This will allow us to gain new functionality in a minimally invasive way,
> and
> will let API users start porting to the new API. This will also serve as a
> good
> "selling point" for the new API, allowing us to hopefully break up the
> legacy
> swscale API afterwards.
>
> ### Phase 2
>
> After this is working, I want to cleanly separate swscale into two distinct
> components:
>
> 1. vertical/horizontal scaling
> 2. input/output conversions
>
> Right now, these operations both live inside the main SwsContext, even
> though
> they are conceptually orthogonal. Input handling is done entirely by the
> abstract callbacks lumToYV12 etc., while output conversion is currently
> "merged" with vertical scaling (yuv2planeX etc.).
>
> I want to cleanly separate these components so they can live inside
> independent
> contexts, and be considered as semantically distinct steps. (In particular,
> there should ideally be no more "unscaled special converters", instead
> this can
> be seen as a special case where there simply is no vertical/horizontal
> scaling
> step)
>
> The idea is for the colorspace conversion layer to sit in between the
> input/output converters and the horizontal/vertical scalers. This all
> would be
> orchestrated by the avscale_* abstraction.
>
> ## Implementation details
>
> To avoid performance loss from separating "merged" functions into their
> constituents, care needs to be taken such that all intermediate data, in
> addition to all involved look-up tables, will fit comfortably inside the L1
> cache. The approach I propose, which is also (afaict) used by zscale, is to
> loop over line segments, applying each operation in sequence, on a small
> temporary buffer.
>
> e.g.
>
> hscale_row(pixel *dst, const pixel *src, int img_width)
> {
> const int SIZE = 256; // or some other small-ish figure, possibly a
> design
> // constant of the API so that SIMD
> implementations
> // can be appropriately unrolled
>
> pixel tmp[SIZE];
> for (i = 0; i < img_width; i += SIZE) {
> int pixels = min(SIZE, img_width - i);
>
> { /* inside read input callback */
> unpack_input(tmp, src, pixels);
> // the amount of separation here will depend on the performance
> apply_matrix3x3(tmp, yuv2rgb, pixels);
> apply_lut3x1d(tmp, gamma_lut, pixels);
> ...
> }
>
> hscale(dst, tmp, filter, pixels);
>
> src += pixels;
> dst += scale_factor(pixels);
> }
> }
>
> This function can then output rows into a ring buffer for use inside the
> vertical scaler, after which the same procedure happens (in reverse) for
> the
> final output pass.
>
> Possibly, we also want to additionally limit the size of a row for the
> horizontal scaler, to allow arbitrary large input images
Re: [FFmpeg-devel] [RFC]] swscale modernization proposal
On Sat, 22 Jun 2024 21:52:42 +0200 Michael Niedermayer wrote: > On Sat, Jun 22, 2024 at 05:10:28PM +0200, Niklas Haas wrote: > > On Sat, 22 Jun 2024 15:23:22 +0100 Andrew Sayers > > wrote: > > > On Sat, Jun 22, 2024 at 03:13:34PM +0200, Niklas Haas wrote: > > > [...] > > > > > > > > ## Comments / feedback? > > > > > > > > Does the above approach seem reasonable? How do people feel about > > > > introducing > > > > a new API vs. trying to hammer the existing API into the shape I want > > > > it to be? > > > > > > > > I've attached an example of what could end up looking like. > > > > If > > > > there is broad agreement on this design, I will move on to an > > > > implementation. > > > > > > API users seem to have difficulty with this type of big change[[1], > > > and doing the interface before the implementation means there's less > > > reason for developers to switch while you're still looking for feedback. > > > > > > What's the plan to bring them along? > > > > Since SwsContext is entirely internal, we can continue providing the > > current API on top of whatever internal abstractions we arrive at. As > > a trivial example, sws_scale() can construct a temporary AVFrame based > > on the provided information, and simply pass that to avscale_frame(). So > > I don't think legacy API users are at risk, or pressure to switch, > > unless they want access to *new* functionality. > > > > For that, the harder step is moving from sws_scale() to > > sws_scale_frame(). This is something API users can *already* do. By > > contrast, moving from sws_scale_frame() to avscale_frame() should > > hopefully be simple, since it just requires making sure the AVFrame is > > correctly tagged. Usually, the flow is in the opposite direction - users > > receive a correctly tagged AVFrame and manually forward this information > > to the SwsContext. So, most of the time, moving to a fully AVFrame-based > > API will result in deleting code, rather than adding it. > > > > If we wanted to maximize the transition comfort, we should consider > > re-using the sws_scale_frame() entrypoint directly. The main reason I am > > hesitant to do this is because sws_scale_frame() is currently tied to > > the stateful configuration of SwsContext, and mostly ignores the AVFrame > > metadata. While changing that is possible, it possibly presents a bigger > > API break than simply introducing a new function. > > I agree we should keep using the same swscale.h header. It matches the library > name thats installed (thats also what the user expects and what (s)he is used > to), > and its what users #include today. > Also its not a audio? scaler so the A is confusing. > > And sws_scale_frame() should be used obviously if thats as you say does > "maximize the transition comfort" > > Maybe simply adding an option for the library user to set the behavior > (favour AVFrame properties vs initial properties) > And then eventually deprecate and phase out the initial ones > > The big advantage here is that we capture all users, noone stays on the old > API. And the transition is also simpler, if its just a flag to flip for > someone > to try the new fully stateless system. This could definitely work. We could then also eventually flip the condition to where the new behavior becomes the default, and you need to set a flag to *disable* it. And eventually deprecate sws_init_context(), sws_setCoefficients() etc. altogether and just have sws_alloc_context() + sws_scale_frame() be the preferred front-ends. I expect the actual amount of work to be similar; rather than taking SwsContext and pulling everything high-level out into AVScaleContext, we start with SwsContext and pull everything low-level out into separate sub-contexts (e.g. one SwsScaleContext for each individual scaling step). > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Complexity theory is the science of finding the exact solution to an > approximation. Benchmarking OTOH is finding an approximation of the exact > ___ > 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]] swscale modernization proposal
On Sun, 23 Jun 2024 00:19:13 +0200 Vittorio Giovara
wrote:
> On Sat, Jun 22, 2024 at 3:22 PM Niklas Haas wrote:
>
> > Hey,
> >
> > As some of you know, I got contracted (by STF 2024) to work on improving
> > swscale, over the course of the next couple of months. I want to share my
> > current plans and gather feedback + measure sentiment.
> >
> > ## Problem statement
> >
> > The two issues I'd like to focus on for now are:
> >
> > 1. Lack of support for a lot of modern formats and conversions (HDR, ICtCp,
> >IPTc2, BT.2020-CL, XYZ, YCgCo, Dolby Vision, ...)
> > 2. Complicated context management, with cascaded contexts, threading,
> > stateful
> >configuration, multi-step init procedures, etc; and related bugs
> >
> > In order to make these feasible, some amount of internal re-organization of
> > duties inside swscale is prudent.
> >
> > ## Proposed approach
> >
> > The first step is to create a new API, which will (tentatively) live in
> > . This API will initially start off as a near-copy
> > of the
> > current swscale public API, but with the major difference that I want it
> > to be
> > state-free and only access metadata in terms of AVFrame properties. So
> > there
> > will be no independent configuration of the input chroma location etc. like
> > there is currently, and no need to re-configure or re-init the context when
> > feeding it frames with different properties. The goal is for users to be
> > able
> > to just feed it AVFrame pairs and have it internally cache expensive
> > pre-processing steps as needed. Finally, avscale_* should ultimately also
> > support hardware frames directly, in which case it will dispatch to some
> > equivalent of scale_vulkan/vaapi/cuda or possibly even libplacebo. (But I
> > will
> > defer this to a future milestone)
> >
> > After this API is established, I want to start expanding the functionality
> > in
> > the following manner:
> >
> > ### Phase 1
> >
> > For basic operation, avscale_* will just dispatch to a sequence of
> > swscale_*
> > invocations. In the basic case, it will just directly invoke swscale with
> > minimal overhead. In more advanced cases, it might resolve to a *sequence*
> > of
> > swscale operations, with other operations (e.g. colorspace conversions a la
> > vf_colorspace) mixed in.
> >
> > This will allow us to gain new functionality in a minimally invasive way,
> > and
> > will let API users start porting to the new API. This will also serve as a
> > good
> > "selling point" for the new API, allowing us to hopefully break up the
> > legacy
> > swscale API afterwards.
> >
> > ### Phase 2
> >
> > After this is working, I want to cleanly separate swscale into two distinct
> > components:
> >
> > 1. vertical/horizontal scaling
> > 2. input/output conversions
> >
> > Right now, these operations both live inside the main SwsContext, even
> > though
> > they are conceptually orthogonal. Input handling is done entirely by the
> > abstract callbacks lumToYV12 etc., while output conversion is currently
> > "merged" with vertical scaling (yuv2planeX etc.).
> >
> > I want to cleanly separate these components so they can live inside
> > independent
> > contexts, and be considered as semantically distinct steps. (In particular,
> > there should ideally be no more "unscaled special converters", instead
> > this can
> > be seen as a special case where there simply is no vertical/horizontal
> > scaling
> > step)
> >
> > The idea is for the colorspace conversion layer to sit in between the
> > input/output converters and the horizontal/vertical scalers. This all
> > would be
> > orchestrated by the avscale_* abstraction.
> >
> > ## Implementation details
> >
> > To avoid performance loss from separating "merged" functions into their
> > constituents, care needs to be taken such that all intermediate data, in
> > addition to all involved look-up tables, will fit comfortably inside the L1
> > cache. The approach I propose, which is also (afaict) used by zscale, is to
> > loop over line segments, applying each operation in sequence, on a small
> > temporary buffer.
> >
> > e.g.
> >
> > hscale_row(pixel *dst, const pixel *src, int img_width)
> > {
> > const int SIZE = 256; // or some other small-ish figure, possibly a
> > design
> > // constant of the API so that SIMD
> > implementations
> > // can be appropriately unrolled
> >
> > pixel tmp[SIZE];
> > for (i = 0; i < img_width; i += SIZE) {
> > int pixels = min(SIZE, img_width - i);
> >
> > { /* inside read input callback */
> > unpack_input(tmp, src, pixels);
> > // the amount of separation here will depend on the performance
> > apply_matrix3x3(tmp, yuv2rgb, pixels);
> > apply_lut3x1d(tmp, gamma_lut, pixels);
> > ...
> > }
> >
> > hscale(dst, tmp, filter, pixels);
> >
> > src += pixels;
> > dst += scale_factor(pixels);
> > }
>
Re: [FFmpeg-devel] [PATCH 1/8 v3] avutil/stereo3d add a Monoscopic view enum value
On Sat, Jun 22, 2024 at 9:57 PM James Almer wrote: > On 6/22/2024 12:31 PM, James Almer wrote: > > We need a way to signal the frame has a single view that doesn't map to > any > > particular eye, and it should be the default one. > > > > Signed-off-by: James Almer > > --- > > Now updating all the fate test... > > > > The 3D ones will be updated again in the following commits once ffprobe > is > > adapted to properly handle the view field. > > Ok, turns out AVStereo3DView is not by Derek from a few days ago but by > Vittorio from 7 years ago, so of course this change is not ok. > The new value would need to be added last and moved to the beginning > after a major bump. > I think it's a good idea fwiw, we chatted about it with Derek, but beside the waiting for the bump, I /believe/ these enum values come straight from the google metadata document so if they get changed we need to make sure that these are properly read/written in the related format. -- Vittorio ___ 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 01/10 v4] avutil/stereo3d: add a Monoscopic view enum value
We need a way to signal the frame has a single view that doesn't map to any
particular eye, and it should be the default one.
Signed-off-by: James Almer
---
libavutil/stereo3d.c | 1 +
libavutil/stereo3d.h | 5 +
2 files changed, 6 insertions(+)
diff --git a/libavutil/stereo3d.c b/libavutil/stereo3d.c
index 19e81e4124..37cf093099 100644
--- a/libavutil/stereo3d.c
+++ b/libavutil/stereo3d.c
@@ -71,6 +71,7 @@ static const char * const stereo3d_view_names[] = {
[AV_STEREO3D_VIEW_PACKED] = "packed",
[AV_STEREO3D_VIEW_LEFT] = "left",
[AV_STEREO3D_VIEW_RIGHT] = "right",
+[AV_STEREO3D_VIEW_MONO] = "monoscopic",
};
static const char * const stereo3d_primary_eye_names[] = {
diff --git a/libavutil/stereo3d.h b/libavutil/stereo3d.h
index 00a5c3900e..9a004d88a1 100644
--- a/libavutil/stereo3d.h
+++ b/libavutil/stereo3d.h
@@ -156,6 +156,11 @@ enum AVStereo3DView {
* Frame contains only the right view.
*/
AV_STEREO3D_VIEW_RIGHT,
+
+/**
+ * Frame is monoscopic.
+ */
+AV_STEREO3D_VIEW_MONO,
};
/**
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 02/10] avutil/stereo3d: add a Stereo3D type to signal that the packing is unspecified
Given that a video stream/frame may have only one or both views coded with
the packing information being unavailable, this commit adds a new type value
AV_STEREO3D_UNSPEC for this purpose.
The most common case for this is container level signaling of Stereo3D video
where the specifics are defined at the bitstream level.
Signed-off-by: James Almer
---
libavutil/stereo3d.c | 1 +
libavutil/stereo3d.h | 6 ++
2 files changed, 7 insertions(+)
diff --git a/libavutil/stereo3d.c b/libavutil/stereo3d.c
index 37cf093099..1f944e9cac 100644
--- a/libavutil/stereo3d.c
+++ b/libavutil/stereo3d.c
@@ -65,6 +65,7 @@ static const char * const stereo3d_type_names[] = {
[AV_STEREO3D_SIDEBYSIDE_QUINCUNX] = "side by side (quincunx subsampling)",
[AV_STEREO3D_LINES] = "interleaved lines",
[AV_STEREO3D_COLUMNS] = "interleaved columns",
+[AV_STEREO3D_UNSPEC] = "unspecified",
};
static const char * const stereo3d_view_names[] = {
diff --git a/libavutil/stereo3d.h b/libavutil/stereo3d.h
index 9a004d88a1..deddecfb36 100644
--- a/libavutil/stereo3d.h
+++ b/libavutil/stereo3d.h
@@ -136,6 +136,12 @@ enum AVStereo3DType {
* @endcode
*/
AV_STEREO3D_COLUMNS,
+
+/**
+ * Video may be monoscopic, or stereoscopic where the
+ * packing is unspecified.
+ */
+AV_STEREO3D_UNSPEC,
};
/**
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 03/10 v3] avformat/mov: default to Monoscopic view when parsing eyes and st3d boxes
Signed-off-by: James Almer
---
libavformat/mov.c | 16 ++--
tests/ref/fate/mov-spherical-mono | 2 +-
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index f08fec3fb6..b0930b2936 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -6298,6 +6298,7 @@ static int mov_read_st3d(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
AVStream *st;
MOVStreamContext *sc;
enum AVStereo3DType type;
+enum AVStereo3DView view = AV_STEREO3D_VIEW_PACKED;
int mode;
if (c->fc->nb_streams < 1)
@@ -6320,6 +6321,7 @@ static int mov_read_st3d(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
switch (mode) {
case 0:
type = AV_STEREO3D_2D;
+view = AV_STEREO3D_VIEW_MONO;
break;
case 1:
type = AV_STEREO3D_TOPBOTTOM;
@@ -6337,6 +6339,7 @@ static int mov_read_st3d(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
return AVERROR(ENOMEM);
sc->stereo3d->type = type;
+sc->stereo3d->view = view;
return 0;
}
@@ -6546,7 +6549,8 @@ static int mov_read_eyes(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
int size, flags = 0;
int64_t remaining;
uint32_t tag, baseline = 0;
-enum AVStereo3DView view = AV_STEREO3D_VIEW_PACKED;
+enum AVStereo3DType type = AV_STEREO3D_2D;
+enum AVStereo3DView view = AV_STEREO3D_VIEW_MONO;
enum AVStereo3DPrimaryEye primary_eye = AV_PRIMARY_EYE_NONE;
AVRational horizontal_disparity_adjustment = { 0, 1 };
@@ -6596,6 +6600,9 @@ static int mov_read_eyes(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
view = AV_STEREO3D_VIEW_LEFT;
else if (has_right)
view = AV_STEREO3D_VIEW_RIGHT;
+if (view)
+type = AV_STEREO3D_UNSPEC;
+
break;
}
case MKTAG('h','e','r','o'): {
@@ -6697,6 +6704,7 @@ static int mov_read_eyes(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
}
sc->stereo3d->flags = flags;
+sc->stereo3d->type= type;
sc->stereo3d->view= view;
sc->stereo3d->primary_eye = primary_eye;
sc->stereo3d->baseline= baseline;
@@ -6818,19 +6826,23 @@ static int mov_parse_uuid_spherical(MOVStreamContext
*sc, AVIOContext *pb, size_
if (av_stristr(buffer, "") && !sc->stereo3d) {
enum AVStereo3DType mode;
+enum AVStereo3DView view = AV_STEREO3D_VIEW_PACKED;
if (av_stristr(buffer, "left-right"))
mode = AV_STEREO3D_SIDEBYSIDE;
else if (av_stristr(buffer, "top-bottom"))
mode = AV_STEREO3D_TOPBOTTOM;
-else
+else {
mode = AV_STEREO3D_2D;
+view = AV_STEREO3D_VIEW_MONO;
+}
sc->stereo3d = av_stereo3d_alloc();
if (!sc->stereo3d)
goto out;
sc->stereo3d->type = mode;
+sc->stereo3d->view = view;
}
/* orientation */
diff --git a/tests/ref/fate/mov-spherical-mono
b/tests/ref/fate/mov-spherical-mono
index b108596350..aa17e9c624 100644
--- a/tests/ref/fate/mov-spherical-mono
+++ b/tests/ref/fate/mov-spherical-mono
@@ -3,7 +3,7 @@
side_data_type=Stereo 3D
type=2D
inverted=0
-view=packed
+view=monoscopic
primary_eye=none
baseline=0
horizontal_disparity_adjustment=0/1
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 04/10] avcodec/h2645_sei: set Monoscopic view for 2D projection
packed view (current default) is obviously not correct. Signed-off-by: James Almer --- libavcodec/h2645_sei.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavcodec/h2645_sei.c b/libavcodec/h2645_sei.c index 7c83747cd0..b30d2c1ca8 100644 --- a/libavcodec/h2645_sei.c +++ b/libavcodec/h2645_sei.c @@ -714,6 +714,7 @@ int ff_h2645_sei_to_frame(AVFrame *frame, H2645SEI *sei, #if CONFIG_H264_SEI case SEI_FPA_H264_TYPE_2D: stereo->type = AV_STEREO3D_2D; +stereo->view = AV_STEREO3D_VIEW_MONO; break; #endif } -- 2.45.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 05/10] avcodec/mjpegdec: set Monoscopic view for 2D projection
Signed-off-by: James Almer
---
libavcodec/mjpegdec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 1481a7f285..ec16186532 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -2019,6 +2019,7 @@ static int mjpeg_decode_app(MJpegDecodeContext *s)
}
if (type == 0) {
s->stereo3d->type = AV_STEREO3D_2D;
+s->stereo3d->view = AV_STEREO3D_VIEW_MONO;
} else if (type == 1) {
switch (layout) {
case 0x01:
@@ -2825,6 +2826,7 @@ the_end:
AVStereo3D *stereo = av_stereo3d_create_side_data(frame);
if (stereo) {
stereo->type = s->stereo3d->type;
+stereo->view = s->stereo3d->view;
stereo->flags = s->stereo3d->flags;
}
av_freep(&s->stereo3d);
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 08/10 v3] avutil/stereo3d: add a new allocator function that returns a size
av_stereo3d_alloc() is not useful in scenarios where you need to know the
runtime size of AVStereo3D.
Signed-off-by: James Almer
---
libavutil/stereo3d.c | 8
libavutil/stereo3d.h | 8
2 files changed, 16 insertions(+)
diff --git a/libavutil/stereo3d.c b/libavutil/stereo3d.c
index 1f944e9cac..0eaa8154d9 100644
--- a/libavutil/stereo3d.c
+++ b/libavutil/stereo3d.c
@@ -32,6 +32,11 @@ static void get_defaults(AVStereo3D *stereo)
}
AVStereo3D *av_stereo3d_alloc(void)
+{
+return av_stereo3d_alloc_size(NULL);
+}
+
+AVStereo3D *av_stereo3d_alloc_size(size_t *size)
{
AVStereo3D *stereo = av_mallocz(sizeof(AVStereo3D));
if (!stereo)
@@ -39,6 +44,9 @@ AVStereo3D *av_stereo3d_alloc(void)
get_defaults(stereo);
+if (size)
+*size = sizeof(*stereo);
+
return stereo;
}
diff --git a/libavutil/stereo3d.h b/libavutil/stereo3d.h
index deddecfb36..a2e480b1ff 100644
--- a/libavutil/stereo3d.h
+++ b/libavutil/stereo3d.h
@@ -248,6 +248,14 @@ typedef struct AVStereo3D {
*/
AVStereo3D *av_stereo3d_alloc(void);
+/**
+ * Allocate an AVStereo3D structure and set its fields to default values.
+ * The resulting struct can be freed using av_freep().
+ *
+ * @return An AVStereo3D filled with default values or NULL on failure.
+ */
+AVStereo3D *av_stereo3d_alloc_size(size_t *size);
+
/**
* Allocate a complete AVFrameSideData and add it to the frame.
*
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 06/10] avcodec/mpeg12dec: set Monoscopic view for 2D projection
Signed-off-by: James Almer --- libavcodec/mpeg12dec.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c index 7485b7c65f..fad79aa018 100644 --- a/libavcodec/mpeg12dec.c +++ b/libavcodec/mpeg12dec.c @@ -2125,6 +2125,7 @@ static void mpeg_decode_user_data(AVCodecContext *avctx, break; case 0x08: s1->stereo3d.type = AV_STEREO3D_2D; +s1->stereo3d.view = AV_STEREO3D_VIEW_MONO; break; case 0x23: s1->stereo3d.type = AV_STEREO3D_SIDEBYSIDE_QUINCUNX; -- 2.45.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 09/10 v3] avformat/mov: don't use sizeof(AVStereo3D)
It's not part of the libavutil ABI.
Signed-off-by: James Almer
---
libavformat/isom.h | 1 +
libavformat/mov.c | 10 +-
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/libavformat/isom.h b/libavformat/isom.h
index 35b767a52c..a0498f45e5 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -247,6 +247,7 @@ typedef struct MOVStreamContext {
int32_t *display_matrix;
AVStereo3D *stereo3d;
+size_t stereo3d_size;
AVSphericalMapping *spherical;
size_t spherical_size;
AVMasteringDisplayMetadata *mastering;
diff --git a/libavformat/mov.c b/libavformat/mov.c
index b0930b2936..650b5c2a40 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -6334,7 +6334,7 @@ static int mov_read_st3d(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
return 0;
}
-sc->stereo3d = av_stereo3d_alloc();
+sc->stereo3d = av_stereo3d_alloc_size(&sc->stereo3d_size);
if (!sc->stereo3d)
return AVERROR(ENOMEM);
@@ -6698,7 +6698,7 @@ static int mov_read_eyes(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
}
if (!sc->stereo3d) {
-sc->stereo3d = av_stereo3d_alloc();
+sc->stereo3d = av_stereo3d_alloc_size(&sc->stereo3d_size);
if (!sc->stereo3d)
return AVERROR(ENOMEM);
}
@@ -6785,7 +6785,7 @@ static int mov_read_hfov(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
if (!sc->stereo3d) {
-sc->stereo3d = av_stereo3d_alloc();
+sc->stereo3d = av_stereo3d_alloc_size(&sc->stereo3d_size);
if (!sc->stereo3d)
return AVERROR(ENOMEM);
}
@@ -6837,7 +6837,7 @@ static int mov_parse_uuid_spherical(MOVStreamContext *sc,
AVIOContext *pb, size_
view = AV_STEREO3D_VIEW_MONO;
}
-sc->stereo3d = av_stereo3d_alloc();
+sc->stereo3d = av_stereo3d_alloc_size(&sc->stereo3d_size);
if (!sc->stereo3d)
goto out;
@@ -10039,7 +10039,7 @@ static int mov_read_header(AVFormatContext *s)
if (sc->stereo3d) {
if (!av_packet_side_data_add(&st->codecpar->coded_side_data,
&st->codecpar->nb_coded_side_data,
AV_PKT_DATA_STEREO3D,
- (uint8_t *)sc->stereo3d,
sizeof(*sc->stereo3d), 0))
+ (uint8_t *)sc->stereo3d,
sc->stereo3d_size, 0))
return AVERROR(ENOMEM);
sc->stereo3d = NULL;
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 07/10] avformat/matroska: set Monoscopic view for 2D projection
Signed-off-by: James Almer --- libavformat/matroska.h | 36 libavformat/matroskadec.c| 6 ++-- libavformat/matroskaenc.c| 8 ++--- tests/ref/fate/matroska-spherical-mono | 2 +- tests/ref/fate/matroska-spherical-mono-remux | 4 +-- tests/ref/fate/matroska-vp8-alpha-remux | 2 +- 6 files changed, 33 insertions(+), 25 deletions(-) diff --git a/libavformat/matroska.h b/libavformat/matroska.h index 719f2ef796..8c4d8dcb99 100644 --- a/libavformat/matroska.h +++ b/libavformat/matroska.h @@ -392,35 +392,41 @@ extern const AVMetadataConv ff_mkv_metadata_conv[]; * as well as WebM compatibility. * * MAP and MKV_ONLY are macros to be provided by the user. - * MAP(MatroskaVideoStereoModeType, AVStereo3DType, AV_STEREO3D_FLAG_*, - * HALF_WIDTH, HALF_HEIGHT, WebM-compatibility) + * MAP(MatroskaVideoStereoModeType, AVStereo3DType, AVStereo3DView, + * AV_STEREO3D_FLAG_*, HALF_WIDTH, HALF_HEIGHT, WebM-compatibility) * is for the stereo modes that have a Stereo3D counterpart. * MKV_ONLY(MatroskaVideoStereoModeType, HALF_WIDTH, HALF_HEIGHT, WebM) * is for those that don't have a Stereo3D counterpart. * */ #define STEREOMODE_STEREO3D_MAPPING(MAP, MKV_ONLY) \ -MAP(MATROSKA_VIDEO_STEREOMODE_TYPE_MONO, AV_STEREO3D_2D, 0, 0, 0, 1) \ -MAP(MATROSKA_VIDEO_STEREOMODE_TYPE_LEFT_RIGHT, AV_STEREO3D_SIDEBYSIDE, 0, 1, 0, 1)\ +MAP(MATROSKA_VIDEO_STEREOMODE_TYPE_MONO, AV_STEREO3D_2D, \ + AV_STEREO3D_VIEW_MONO, 0, 0, 0, 1) \ +MAP(MATROSKA_VIDEO_STEREOMODE_TYPE_LEFT_RIGHT, AV_STEREO3D_SIDEBYSIDE, \ +AV_STEREO3D_VIEW_PACKED, 0, 1, 0, 1) \ MAP(MATROSKA_VIDEO_STEREOMODE_TYPE_BOTTOM_TOP, AV_STEREO3D_TOPBOTTOM, \ -AV_STEREO3D_FLAG_INVERT, 0, 1, 1) \ -MAP(MATROSKA_VIDEO_STEREOMODE_TYPE_TOP_BOTTOM, AV_STEREO3D_TOPBOTTOM, 0, 0, 1, 1)\ +AV_STEREO3D_VIEW_PACKED, AV_STEREO3D_FLAG_INVERT, 0, 1, 1) \ +MAP(MATROSKA_VIDEO_STEREOMODE_TYPE_TOP_BOTTOM, AV_STEREO3D_TOPBOTTOM, \ +AV_STEREO3D_VIEW_PACKED, 0, 0, 1, 1) \ MAP(MATROSKA_VIDEO_STEREOMODE_TYPE_CHECKERBOARD_RL, AV_STEREO3D_CHECKERBOARD, \ -AV_STEREO3D_FLAG_INVERT, 0, 0, 0) \ -MAP(MATROSKA_VIDEO_STEREOMODE_TYPE_CHECKERBOARD_LR, AV_STEREO3D_CHECKERBOARD, 0, 0, 0, 0) \ +AV_STEREO3D_VIEW_PACKED, AV_STEREO3D_FLAG_INVERT, 0, 0, 0) \ +MAP(MATROSKA_VIDEO_STEREOMODE_TYPE_CHECKERBOARD_LR, AV_STEREO3D_CHECKERBOARD, \ +AV_STEREO3D_VIEW_PACKED, 0, 0, 0, 0) \ MAP(MATROSKA_VIDEO_STEREOMODE_TYPE_ROW_INTERLEAVED_RL, AV_STEREO3D_LINES, \ -AV_STEREO3D_FLAG_INVERT, 0, 1, 0) \ -MAP(MATROSKA_VIDEO_STEREOMODE_TYPE_ROW_INTERLEAVED_LR, AV_STEREO3D_LINES, 0, 0, 1, 0) \ +AV_STEREO3D_VIEW_PACKED, AV_STEREO3D_FLAG_INVERT, 0, 1, 0) \ +MAP(MATROSKA_VIDEO_STEREOMODE_TYPE_ROW_INTERLEAVED_LR, AV_STEREO3D_LINES, \ +AV_STEREO3D_VIEW_PACKED, 0, 0, 1, 0) \ MAP(MATROSKA_VIDEO_STEREOMODE_TYPE_COL_INTERLEAVED_RL, AV_STEREO3D_COLUMNS, \ -AV_STEREO3D_FLAG_INVERT, 1, 0, 0) \ -MAP(MATROSKA_VIDEO_STEREOMODE_TYPE_COL_INTERLEAVED_LR, AV_STEREO3D_COLUMNS, 0, 1, 0, 0) \ +AV_STEREO3D_VIEW_PACKED, AV_STEREO3D_FLAG_INVERT, 1, 0, 0) \ +MAP(MATROSKA_VIDEO_STEREOMODE_TYPE_COL_INTERLEAVED_LR, AV_STEREO3D_COLUMNS, \ +AV_STEREO3D_VIEW_PACKED, 0, 1, 0, 0) \ MKV_ONLY(MATROSKA_VIDEO_STEREOMODE_TYPE_ANAGLYPH_CYAN_RED, 0, 0, 0) \ MAP(MATROSKA_VIDEO_STEREOMODE_TYPE_RIGHT_LEFT, AV_STEREO3D_SIDEBYSIDE, \ -AV_STEREO3D_FLAG_INVERT, 1, 0, 1) \ +AV_STEREO3D_VIEW_PACKED, AV_STEREO3D_FLAG_INVERT, 1, 0, 1) \ MKV_ONLY(MATROSKA_VIDEO_STEREOMODE_TYPE_ANAGLYPH_GREEN_MAG, 0, 0, 0) \ MAP(MATROSKA_VIDEO_STEREOMODE_TYPE_BOTH_EYES_BLOCK_LR, AV_STEREO3D_FRAMESEQUENCE, \ -0, 0, 0, 0) \ +AV_STEREO3D_VIEW_PACKED, 0, 0, 0, 0)
[FFmpeg-devel] [PATCH 10/10 v3] avformat/matroskadec: don't use sizeof(AVStereo3D)
It's not part of the libavutil ABI.
Signed-off-by: James Almer
---
libavformat/matroskadec.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index e6437ac68f..f090d8d798 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -2254,8 +2254,9 @@ static int mkv_stereo3d_conv(AVStream *st,
MatroskaVideoStereoModeType stereo_mo
STEREOMODE_STEREO3D_MAPPING(STEREO_MODE_CONV, NOTHING)
};
AVStereo3D *stereo;
+size_t size;
-stereo = av_stereo3d_alloc();
+stereo = av_stereo3d_alloc_size(&size);
if (!stereo)
return AVERROR(ENOMEM);
@@ -2264,7 +2265,7 @@ static int mkv_stereo3d_conv(AVStream *st,
MatroskaVideoStereoModeType stereo_mo
stereo->flags = stereo_mode_conv[stereo_mode].flags;
if (!av_packet_side_data_add(&st->codecpar->coded_side_data,
&st->codecpar->nb_coded_side_data,
- AV_PKT_DATA_STEREO3D, stereo,
sizeof(*stereo), 0)) {
+ AV_PKT_DATA_STEREO3D, stereo, size, 0)) {
av_freep(&stereo);
return AVERROR(ENOMEM);
}
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] aarch64: Add OpenBSD runtime detection of dotprod and i8mm using sysctl
[PATCH] aarch64: Add OpenBSD runtime detection of dotprod and i8mm using sysctl
Signed-off-by: Brad Smith
---
libavutil/aarch64/cpu.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/libavutil/aarch64/cpu.c b/libavutil/aarch64/cpu.c
index 196bdaf6b0..40fcc8d1ff 100644
--- a/libavutil/aarch64/cpu.c
+++ b/libavutil/aarch64/cpu.c
@@ -65,6 +65,41 @@ static int detect_flags(void)
return flags;
}
+#elif defined(__OpenBSD__)
+#include
+#include
+#include
+#include
+
+static int detect_flags(void)
+{
+int flags = 0;
+int mib[2];
+uint64_t isar0;
+uint64_t isar1;
+size_t len;
+
+mib[0] = CTL_MACHDEP;
+mib[1] = CPU_ID_AA64ISAR0;
+len = sizeof(isar0);
+if (sysctl(mib, 2, &isar0, &len, NULL, 0) != -1) {
+if (ID_AA64ISAR0_DP(isar0) >= ID_AA64ISAR0_DP_IMPL)
+flags |= AV_CPU_FLAG_DOTPROD;
+}
+
+mib[0] = CTL_MACHDEP;
+mib[1] = CPU_ID_AA64ISAR1;
+len = sizeof(isar1);
+if (sysctl(mib, 2, &isar1, &len, NULL, 0) != -1) {
+#ifdef ID_AA64ISAR1_I8MM_IMPL
+if (ID_AA64ISAR1_I8MM(isar1) >= ID_AA64ISAR1_I8MM_IMPL)
+flags |= AV_CPU_FLAG_I8MM;
+#endif
+}
+
+return flags;
+}
+
#elif defined(_WIN32)
#include
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v13 06/15] avcodec/vaapi_encode: move the dpb logic from VAAPI to base layer
>From: ffmpeg-devel On Behalf Of Tong
>Wu
>Sent: 2024年6月16日 0:06
>To: FFmpeg development discussions and patches de...@ffmpeg.org>
>Cc: Lynne
>Subject: Re: [FFmpeg-devel] [PATCH v13 06/15] avcodec/vaapi_encode: move
>the dpb logic from VAAPI to base layer
>
>> >> From: ffmpeg-devel On Behalf Of
>> >> Lynne via ffmpeg-devel
>> >> Sent: Monday, June 10, 2024 10:01 AM
>> >> To: FFmpeg development discussions and patches > >> de...@ffmpeg.org>
>> >> Cc: Lynne
>> >> Subject: Re: [FFmpeg-devel] [PATCH v13 06/15] avcodec/vaapi_encode:
>> >> move the dpb logic from VAAPI to base layer
>> >>
>> >> On 07/06/2024 18:48, Lynne wrote:
>> >>> On 07/06/2024 17:22, Wu, Tong1 wrote:
>> > From: ffmpeg-devel On Behalf
>> > Of
>> >> Lynne
>> > via ffmpeg-devel
>> > Sent: Friday, June 7, 2024 11:10 PM
>> > To: ffmpeg-devel@ffmpeg.org
>> > Cc: Lynne
>> > Subject: Re: [FFmpeg-devel] [PATCH v13 06/15]
>> avcodec/vaapi_encode:
>> >> move
>> > the dpb logic from VAAPI to base layer
>> >
>> > On 03/06/2024 11:18, tong1.wu-at-intel@ffmpeg.org wrote:
>> >> From: Tong Wu
>> >>
>> >> Move receive_packet function to base. This requires adding
>> >> *alloc, *issue, *output, *free as hardware callbacks.
>> >> HWBaseEncodePicture is introduced as the base layer structure.
>> >> The related parameters in VAAPIEncodeContext are also extracted
>> >> to HWBaseEncodeContext. Then
>> >> DPB
>> >> management logic can be fully extracted to base layer as-is.
>> >>
>> >> Signed-off-by: Tong Wu
>> >> ---
>> >> libavcodec/Makefile | 2 +-
>> >> libavcodec/hw_base_encode.c | 594
>> >>
>> >> libavcodec/hw_base_encode.h | 124 +
>> >> libavcodec/vaapi_encode.c | 793 +
>> >> ---
>> >> libavcodec/vaapi_encode.h | 102 +---
>> >> libavcodec/vaapi_encode_av1.c | 35 +-
>> >> libavcodec/vaapi_encode_h264.c | 84 ++--
>> >> libavcodec/vaapi_encode_h265.c | 53 ++-
>> >> libavcodec/vaapi_encode_mjpeg.c | 13 +-
>> >> libavcodec/vaapi_encode_mpeg2.c | 33 +-
>> >> libavcodec/vaapi_encode_vp8.c | 18 +-
>> >> libavcodec/vaapi_encode_vp9.c | 24 +-
>> >> 12 files changed, 985 insertions(+), 890 deletions(-)
>> >> create mode 100644 libavcodec/hw_base_encode.c
>> >
>> > This patch doesn't apply,
>> >
>> > error: sha1 information is lacking or useless (libavcodec/
>> > hw_base_encode.c).
>> > error: could not build fake ancestor
>> >
>> > Could you resent the patchset or link me a repo so I can work with it?
>>
>> https://github.com/intel-media-ci/ffmpeg/pull/689 This is the
>> same as
>> v13 please have a try.
>> >>>
>> >>> That worked, thanks.
>> >>
>> >> I don't think the behaviour is correct when the encoding length is
>> >> less than the decode delay. In my old Vulkan code, I had this piece
>> >> of code in the initialization function:
>> >>
>> >>> if (!src) {
>> >>> ctx->end_of_stream = 1;
>> >>> /* Fix timestamps if we hit end-of-stream before the initial
>> >>> * decode delay has elapsed. */
>> >>> if (ctx->input_order < ctx->decode_delay)
>> >>> ctx->dts_pts_diff = ctx->pic_end->pts - ctx->first_pts;
>> >>> return AVERROR_EOF;
>> >>> }
>> >>
>> >> I think a flush function should be added, to be called by each
>> >> encoder, to make sure the timestamps remain correct.
>> >>
>> >
>> > For the current patch set, this piece is in
>> > hw_base_encode_send_frame and
>> works well for vaapi and d3d12 except when the encoding length is
>> equal to the decode delay, which I'll sent a fix later. Do you mean
>> Vulkan cannot integrate into this part and we have to make a callback for it?
>>
>> No, I was just curious. Fair enough, it can be implemented in a later patch.
>>
>> >
>> >> Also, the D3D12VA structures need an FF prefix, e.g.
>> >> D3D12VAEncodeContext -> FFD3D12VAEncodeContext.
>> >
>> > The current VAAPIEncodeContext has existed for a long time. Does it
>> > have
>> any difference for D3D12VAEncodeContext? I mean both
>> VAAPIEncodeContext and D3D12VAEncodeContext are parallel and only
>> referenced in vaapi_encode_*.c (d3d12va_encode_*.c).
>> >
>> > Thanks,
>> > Tong
>>
>> I'm finishing up on the Vulkan test implementation, I'll see to
>> pushing this patch over the weekend.
>
>Sure. Thank you.
>
Kindly ping. Could we push this patch set?
Thanks,
Tong
___
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".
