Ping.
Is the below a viable scheme or are there concerns to consider in this
initial design stage?
Thanks and all the best,
Dee
On Tue, Oct 15, 2024 at 8:55 AM Diederick C. Niehorster
wrote:
>
> Hi All,
>
> I want to pick up a discussion i started last week
> (https://ffmpeg.org/pipermail/ffmpe
On 10/21/2024 8:51 PM, James Almer wrote:
On 10/21/2024 10:02 PM, martin schitter wrote:
I know -- it's trivial to choose this way, but there has to be some
common agreement or docu, how it should be done, otherwise we run
circles.
I didn't participate in earlier rounds, but at least my opini
On 10/21/2024 10:02 PM, martin schitter wrote:
On 22.10.24 00:31, James Almer wrote:
On 10/21/2024 8:40 PM, martin schitter wrote:
On 21.10.24 22:44, James Almer wrote:
That's not good...
[...]
Whenever and however I change it, there will allways be somebody who
doesn't like it. !:(
My
On 22.10.24 00:31, James Almer wrote:
On 10/21/2024 8:40 PM, martin schitter wrote:
On 21.10.24 22:44, James Almer wrote:
That's not good...
[...]
Whenever and however I change it, there will allways be somebody who
doesn't like it. !:(
My point is, it's not a good idea to commit code th
From: Evgeny Pavlov
Signed-off-by: Evgeny Pavlov
---
doc/filters.texi | 238 +++
1 file changed, 238 insertions(+)
diff --git a/doc/filters.texi b/doc/filters.texi
index 428986a1e9..7d75ebfa3e 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -
Co-authored-by: Evgeny Pavlov
v3: cleanup code
---
libavcodec/amfenc.c | 520 +--
libavcodec/amfenc.h | 29 +--
libavcodec/amfenc_av1.c | 8 +-
libavcodec/amfenc_h264.c | 6 +-
libavcodec/amfenc_hevc.c | 6 +-
5 files changed, 132 insertions(+
From: Evgeny Pavlov
This commit adds two AMF filters: vpp_amf & sr_amf.
Both filters are using AMF hardware acceleration.
vpp_amf supports simple scaling algorithms & color conversion.
sr_amf supports advanced scaling algorithms such as FSR & can
be used for upscaling only.
---
configure
Adds hwcontext_amf, which allows to use shared AMF
context for the encoder, decoder and AMF-based filters,
without copy to the host memory.
It will also allow you to use some optimisations in
the interaction of components (for example, SAV) and make a more
manageable and optimal setup for using GPU
From: Evgeny Pavlov
Added AMF based h264, hevc, av1 decoders.
Co-authored-by: Dmitrii Ovchinnikov
v2: added encoder reinitialisation
v3: use AMF_SURFACE_UNKNOWN to int decoder(ctx->output_format before)
---
configure | 3 +
libavcodec/Makefile| 7 +-
libavcodec/allcodecs.c
On 22.10.24 00:32, Michael Niedermayer wrote:
I see you added these in the previous patch of the series, i guess its ok then
exactly! :)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsu
On 22.10.24 00:30, Michael Niedermayer wrote:
adding them in the middle will change the numbers of the following and break ABI
sadly
you have to add them at the end
If you apply the whole patch set, they are all as one group at the end!
I just did my best to not increase the utterly chaot
On Tue, Oct 22, 2024 at 12:30:42AM +0200, Michael Niedermayer wrote:
> On Mon, Oct 21, 2024 at 09:57:16PM +0200, Martin Schitter wrote:
> > ---
> > libavutil/pixdesc.c | 48
> > libavutil/pixfmt.h | 6 ++
> > libswscale/input.c | 99 ++
On 10/21/2024 8:40 PM, martin schitter wrote:
On 21.10.24 22:44, James Almer wrote:
That's not good...
[...]
Whenever and however I change it, there will allways be somebody who
doesn't like it. !:(
My point is, it's not a good idea to commit code that's not tested.
Assuming that's wha
On Mon, Oct 21, 2024 at 09:57:16PM +0200, Martin Schitter wrote:
> ---
> libavutil/pixdesc.c | 48
> libavutil/pixfmt.h | 6 ++
> libswscale/input.c | 99
> libswscale/utils.c | 4 ++
> tests
On Mon, Oct 21, 2024 at 07:32:20PM +0200, AndreaMastroberti wrote:
> ---
> doc/filters.texi | 14 +++
> libavfilter/ssim.h| 6 +
> libavfilter/version.h | 4 +-
> libavfilter/vf_ssim.c | 277 --
> 4 files changed, 291 insertions(+), 10 deletions(-)
On 21.10.24 23:50, James Almer wrote:
On 10/21/2024 5:44 PM, James Almer wrote:
On 10/21/2024 4:57 PM, Martin Schitter wrote:
+ break;
+ case MKTAG('y','2','1','0'):
+ ret = fmt_frame(avctx, frame, avpkt,
AV_PIX_FMT_YUV422P10LE, 20, unpack_y210);
Y210 has no pi
On 10/21/2024 5:44 PM, James Almer wrote:
On 10/21/2024 4:57 PM, Martin Schitter wrote:
+ break;
+ case MKTAG('y','2','1','0'):
+ ret = fmt_frame(avctx, frame, avpkt,
AV_PIX_FMT_YUV422P10LE, 20, unpack_y210);
Y210 has no pixel format, and it's packed, not planar,
On 21.10.24 22:44, James Almer wrote:
That's not good...
[...]
Whenever and however I change it, there will allways be somebody who
doesn't like it. !:(
This time I spend a lot of time to modify the code as close as possible
to requests asked by one previous reviewer, who insisted, that
On 10/21/2024 4:57 PM, Martin Schitter wrote:
---
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/dnxucdec.c | 338 +
3 files changed, 340 insertions(+)
create mode 100644 libavcodec/dnxucdec.c
diff --git a/libavcodec/Mak
---
tests/Makefile | 1 +
tests/fate/dnxuc.mak| 40 +
tests/ref/fate/dnxuc-cb-rgb-10 | 8 ++
tests/ref/fate/dnxuc-cb-rgb-12 | 8 ++
tests/ref/fate/dnxuc-cb-rgb-8 | 8 ++
tests/ref/fate/dnxuc-cb-rgb-flo
In case of RGB content wrapped in MXF containers we can not use
CDCIDescriptor fields for the video level detection.
The corresponding information in RGBA Descriptors uses a significant
differnt structure. As a workaround we pick the first found channel
depth info value of the RGBALayout array and
---
Changelog | 2 ++
doc/general_contents.texi | 1 +
2 files changed, 3 insertions(+)
diff --git a/Changelog b/Changelog
index 7963e09..75b8e15 100644
--- a/Changelog
+++ b/Changelog
@@ -3,6 +3,8 @@ releases are sorted from youngest to oldest.
version :
- yasm support droppe
---
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/dnxucdec.c | 338 +
3 files changed, 340 insertions(+)
create mode 100644 libavcodec/dnxucdec.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index dd5d0de..e13b127 10
---
libswscale/input.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/libswscale/input.c b/libswscale/input.c
index f9d7c39..ba7e3c4 100644
--- a/libswscale/input.c
+++ b/libswscale/input.c
@@ -1447,6 +1447,30 @@ static av_always_inline void planar_rgbf3
---
libavutil/pixdesc.c | 48 +++
libavutil/pixfmt.h | 6 ++
libswscale/input.c | 100 +++
libswscale/utils.c | 6 +-
tests/ref/fate/imgutils | 8 +++
tests/ref/fate/sws-pixdesc-query |
---
libavutil/pixdesc.c | 48
libavutil/pixfmt.h | 6 ++
libswscale/input.c | 99
libswscale/utils.c | 4 ++
tests/ref/fate/imgutils | 8 +++
tests/ref/fate/sws-pixdesc-query | 14 +
---
libavutil/pixdesc.c | 46
libavutil/pixfmt.h | 8 +++
libswscale/input.c | 90
libswscale/utils.c | 4 ++
tests/ref/fate/imgutils | 8 +++
tests/ref/fate/sws-pixdesc-query | 14
This is a reworked 11th version of my DNxUncompressed decoder contribution.
I added many new pixel formats and swscale input support variants for all
those payload types that do not need any format specific unpacking.
Most pixel format variants found in the specification are now supported.
Unfort
---
libavutil/pixdesc.c | 11 +++
libavutil/pixfmt.h | 2 ++
libswscale/input.c | 22 ++
libswscale/utils.c | 1 +
tests/ref/fate/imgutils | 2 ++
tests/ref/fate/sws-pixdesc-query | 2 ++
6 files change
ffmpeg has existing support for MLV raw video files; libavformat/mlvdec.c.
Since this was added, MLV has been extended to support LJ92 compressed
image data. These patches build on lossless DNG support in 7.2-dev to
enable handling LJ92 MLV via existing libavcodec/mjpegdec.c code.
I can provide M
On Sun, Oct 20, 2024 at 11:33 PM Jan Ekström wrote:
>
> This tests utilizes an MPEG-TS sample from FATE suite, yet is
> marked as not requiring samples.
>
> This fixes running `make fate` without SAMPLES being set.
>
> Reported-by: Sebastian Ramacher
> ---
Superceded by the earlier patch sent by
On Mon, Oct 21, 2024 at 9:05 PM Jan Ekström wrote:
>
> On Mon, Oct 7, 2024 at 2:05 AM Emily via ffmpeg-devel
> wrote:
> >
> > From: Emily
> >
> > ---
> > In the NixOS FFmpeg package, we run `make check` without downloading
> > the entire FATE suite. The FFmpeg 7.1 update broke this, seemingly
>
On Mon, Oct 7, 2024 at 2:05 AM Emily via ffmpeg-devel
wrote:
>
> From: Emily
>
> ---
> In the NixOS FFmpeg package, we run `make check` without downloading
> the entire FATE suite. The FFmpeg 7.1 update broke this, seemingly
> because of an undeclared FATE sample dependency.
>
> This package is m
---
doc/filters.texi | 14 +++
libavfilter/ssim.h| 6 +
libavfilter/version.h | 4 +-
libavfilter/vf_ssim.c | 277 --
4 files changed, 291 insertions(+), 10 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 2eb4a380fb..df5c3a9305
On 10/21/2024 2:03 PM, Zhao Zhili wrote:
From: Zhao Zhili
-u and -q doesn't work together for diff on macOS.
Lovely.
---
tests/fate-run.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index f8d67de25a..c371bd1c3c 100755
--- a/t
From: Zhao Zhili
-u and -q doesn't work together for diff on macOS.
---
tests/fate-run.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index f8d67de25a..c371bd1c3c 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -519,7 +519,7
On 10/21/2024 10:26 AM, James Almer wrote:
The current calculation was a no-op, setting the entire array to 0.
Use the shift value from the dest descriptor, as the source one is planar with
no shifts whatsoever.
Disregard this patch, i tested i wrong.
OpenPGP_signature.asc
Description: OpenP
Le 16/10/2024 à 22:53, Michael Niedermayer a écrit :
what are you testing?
the new code is faster than the old code.
There is something not right here, the range coder based implementation
i posted now is 5% faster then the range coder based one i posted earlier today
thats overall speed meassure
The current calculation was a no-op, setting the entire array to 0.
Use the shift value from the dest descriptor, as the source one is planar with
no shifts whatsoever.
Signed-off-by: James Almer
---
libswscale/swscale_unscaled.c | 17 +++--
1 file changed, 3 insertions(+), 14 deleti
Signed-off-by: James Almer
---
tests/fate-run.sh | 13 +++
tests/fate/pixfmt.mak | 60 +--
tests/ref/fate/pixfmt-gbrp10be| 2 ++
tests/ref/fate/pixfmt-gbrp10le| 2 ++
tests/ref/fate/pixfmt-gbrp12be| 2 ++
tests/ref/fate/pi
> On Sep 25, 2024, at 22:45, Zhao Zhili wrote:
>
> From: Zhao Zhili
>
> For example, the default surface configuration on macOS is:
> VK_FORMAT_A2B10G10R10_UNORM_PACK32 + VK_COLOR_SPACE_PASS_THROUGH_EXT
>
> With HDR10 content and swapchain_colorspace_hint, the surface
> configuration updated
> On Sep 18, 2024, at 14:56, Zhao Zhili wrote:
>
> From: Zhao Zhili
>
> ---
> sample:
> 8054b4b8e62c0171476b40206d044590 Hierarchical.bit
> https://drive.google.com/file/d/1U5WGWeSsMFiEkhsl_vL4NiMma-LLh02t/view?usp=sharing
>
> Put Hierarchical.bit under $(TARGET_SAMPLES)/vvc
Ping.
>
> t
42 matches
Mail list logo
