ons 2024-09-11 klockan 01:08 +0200 skrev martin schitter:
>
>
> On 10.09.24 15:14, Tomas Härdin wrote:
> > > +++ b/libavformat/mxf.c
>
> > > + { {
> > > 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0E,0x04,0x02,0x01,0x02,
> > > 0x1E,0x01,0x00 }, 16, AV_CODEC_ID_DNXUC }, /*
> > > DNxUncompre
On 10/09/2024 15:29, Benjamin Cheng wrote:
On Mon Sep 9, 2024 at 6:37 AM EDT, Lynne via ffmpeg-devel wrote:
This commit adds the common Vulkan video encoding framework.
It makes full use of the asynchronous features of our new common
hardware encoding code, and of Vulkan.
The code is able to han
This commit adds the first Vulkan hardware encoder.
Currently, P, and **B**-frames are supported. This marks the
first implementation to support both.
The encoder has feature-parity with VAAPI.
---
configure |1 +
libavcodec/Makefile |3 +
libavcodec/all
This commit adds the common Vulkan video encoding framework.
It makes full use of the asynchronous features of our new common
hardware encoding code, and of Vulkan.
The code is able to handle anything from H264 to AV1 and MJPEG.
---
configure | 2 +
libavcodec/Makefile|
On 9/10/24 7:45 PM, Andrew Randrianasulu wrote:
I often saw suggestion to use -vf zscale but this is not default, and z.img
upstream seems to be in suspended animation:
https://github.com/sekrit-twc/zimg/issues/207
Because that's not upstream? It moved over a year ago.
https://bitbucket.org/t
On Wed, Sep 11, 2024 at 3:21 AM Michael Niedermayer
wrote:
>
> Hi
>
> On Wed, Sep 11, 2024 at 02:45:59AM +0300, Andrew Randrianasulu wrote:
> > I can't find entry about it in ffmpeg/MAINTAINERS
>
> I do try to maintain swscale. But iam surely happy if others help
> If you have a patch that needs t
From: Fei Wang
Signed-off-by: Fei Wang
---
libavcodec/vaapi_encode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 0058e1e772..16a9a364f0 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -
Does anyone have any thoughts on this? This is a pretty small one-liner.
I also noticed that there is a ff_parse_ntp_time() in utils.c. Maybe this
functionality should be consolidated in one place.
On Wed, Sep 4, 2024, at 5:06 PM, j...@jonb.org wrote:
> From: Jonathan Baudanza
>
> I encountere
Hi
On Wed, Sep 11, 2024 at 02:45:59AM +0300, Andrew Randrianasulu wrote:
> I can't find entry about it in ffmpeg/MAINTAINERS
I do try to maintain swscale. But iam surely happy if others help
If you have a patch that needs to be reviewed or applied i can look at it
>
> bugs meanwhile exist
>
>
I can't find entry about it in ffmpeg/MAINTAINERS
bugs meanwhile exist
https://trac.ffmpeg.org/ticket/3345
https://trac.ffmpeg.org/ticket/7978
I often saw suggestion to use -vf zscale but this is not default, and z.img
upstream seems to be in suspended animation:
https://github.com/sekrit-twc/z
On 10.09.24 15:14, Tomas Härdin wrote:
+++ b/libavformat/mxf.c
+ { {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0E,0x04,0x02,0x01,0x02,0x1E,0x01,0x00
}, 16, AV_CODEC_ID_DNXUC }, /* DNxUncompressed/SMPTE RDD 50 */
Are really all 16 bytes significant?
I have to correct myself agai
On 10.09.24 15:14, Tomas Härdin wrote:
tis 2024-09-10 klockan 16:06 +0200 skrev Martin Schitter:
---
libavformat/mxf.c | 1 +
libavformat/mxfdec.c | 1 +
2 files changed, 2 insertions(+)
Commit message could be better, something like "Add DNxUncompressed
ULs"
O.k. -- this will be "l
On 10.09.2024 20:10, Koushik Dutta wrote:
The crop filter has no effect on scale_cuda:
-vf crop=100:100,scale_cuda=300x300
Hardware frames (AV_PIX_FMT_FLAG_HWACCEL) are expected to use the crop_*
properties,
as seen in the implementation vf_crop.c.
The current workaround is to hwdownload the
The crop filter has no effect on scale_qsv:
-vf crop=100:100,scale_qsv=300x300
Hardware frames (AV_PIX_FMT_FLAG_HWACCEL) are expected to use the crop_*
properties,
as seen in the implementation vf_crop.c.
This patch is slightly different from the previously submitted patches
since qsv supports
The crop filter has no effect on scale_cuda:
-vf crop=100:100,scale_cuda=300x300
Hardware frames (AV_PIX_FMT_FLAG_HWACCEL) are expected to use the crop_*
properties,
as seen in the implementation vf_crop.c.
The current workaround is to hwdownload the full frame
and perform the crop on CPU.
---
The crop filter has no effect on scale_vt:
-vf crop=100:100,scale_vt=300x300
Hardware frames (AV_PIX_FMT_FLAG_HWACCEL) are expected to use the crop_*
properties,
as seen in the implementation vf_crop.c.
The current workaround is to hwdownload the full frame
and perform the crop on CPU.
---
lib
From: Zhao Zhili
With Apple M1 (no i8mm):
put_luma_hv_8_4x4_c: 2.2 ( 1.00x)
put_luma_hv_8_4x4_neon: 0.8 ( 3.00x)
put_luma_hv_8_8x8_c: 7.0 ( 1.00x)
put_luma_hv_8_8x8_neon:
From: Zhao Zhili
put_luma_v_8_4x4_c: 1.0 ( 1.00x)
put_luma_v_8_4x4_neon: 0.0 ( 0.00x)
put_luma_v_8_8x8_c: 3.5 ( 1.00x)
put_luma_v_8_8x8_neon: 0.5 ( 7.00x)
From: Zhao Zhili
b.eq is added by calc_all after each calc.
---
libavcodec/aarch64/h26x/qpel_neon.S | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/aarch64/h26x/qpel_neon.S
b/libavcodec/aarch64/h26x/qpel_neon.S
index 8a372a76be..7868811b3b 100644
--- a/libavcodec/aarch64/h26x/qpel
From 2db025b18be995afea46dea6c15a3caf1d985a82 Mon Sep 17 00:00:00 2001
From: sfan5
Date: Wed, 4 Sep 2024 17:56:05 +0200
Subject: [PATCH v2] lavf/tls_mbedtls: restrict TLSv1.3 verification workaround
to affected version
Now that mbedTLS 3.6.1 is released we know that only 3.6.0 contains this regr
Am 09.09.24 um 12:21 schrieb Anton Khirnov:
Quoting sfan5 (2024-09-04 18:55:37)
From 57b37df52c7d528a1ce926cd7a7d75f62f6b46c6 Mon Sep 17 00:00:00 2001
From: sfan5
Date: Wed, 4 Sep 2024 17:56:05 +0200
Subject: [PATCH] lavf/tls_mbedtls: restrict TLSv1.3 verification workaround to
affected vers
On 9/10/2024 3:39 AM, Anton Khirnov wrote:
Would trigger #10887 before it was fixed, sample cut from the one
attached to the bug.
---
Please put
https://ups.khirnov.net/3dc9efb9d882bbbf05876bfa67d5257fb0ee93065b43dc5512539ac3dfe91208/pir.hevc
to hevc/pir.hevc
Uploaded.
OpenPGP_signature.asc
On Mon Sep 9, 2024 at 6:37 AM EDT, Lynne via ffmpeg-devel wrote:
> This commit adds the first Vulkan hardware encoder.
>
> Currently, P, and **B**-frames are supported. This marks the
> first implementation to support both.
>
> The encoder has feature-parity with VAAPI.
> ---
> configure
On Mon Sep 9, 2024 at 6:37 AM EDT, Lynne via ffmpeg-devel wrote:
> This commit adds the common Vulkan video encoding framework.
> It makes full use of the asynchronous features of our new common
> hardware encoding code, and of Vulkan.
> The code is able to handle anything from H264 to AV1 and MJPE
From: Niklas Haas
The input file is MPEG range, so we should also encode to MPEG range
before comparing against it. This bug was avoided in the past because
YUVJ inputs were automatically converted back to limited range when converting
to a different pixfmt (in the absence of tagging). However, w
On Tue, 10 Sep 2024 15:18:16 +0200 Niklas Haas wrote:
> From: Niklas Haas
>
> Ironically, despite being introduced to make YUVJ unnecessary, the new
> YUV negotiation logic failed to actually negotiate YUVJ formats
> themselves correctly, leading to errors when passing YUVJ frames into
> a filter
tis 2024-09-10 klockan 16:06 +0200 skrev Martin Schitter:
> ---
> libavformat/mxf.c | 1 +
> libavformat/mxfdec.c | 1 +
> 2 files changed, 2 insertions(+)
Commit message could be better, something like "Add DNxUncompressed
ULs"
> diff --git a/libavformat/mxf.c b/libavformat/mxf.c
> index a73
From: Niklas Haas
Ironically, despite being introduced to make YUVJ unnecessary, the new
YUV negotiation logic failed to actually negotiate YUVJ formats
themselves correctly, leading to errors when passing YUVJ frames into
a filter graph. (They were effectively treated like RGB or Grayscale
forma
mån 2024-09-09 klockan 02:04 +0200 skrev Marvin Scholz:
> ---
> libavformat/mxfdec.c | 35 ---
> 1 file changed, 16 insertions(+), 19 deletions(-)
C99 style is fine now? OK then
/Tomas
___
ffmpeg-devel mailing list
ffmpe
tis 2024-09-03 klockan 10:02 +0200 skrev Nicolas Gaullier:
> The time_base was a bad guess.
>
> Currently, fate-time_base test data assumed that overriding the input
> time_base would affect the frame_rate, but this behaviour is not
> documented, so just fix the fate data now that this is fixed.
>
mån 2024-09-09 klockan 01:55 +0200 skrev Marvin Scholz:
> ---
> libavformat/mxfdec.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
Looks OK. Doesn't really change anything
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@f
On 10.09.24 01:19, Marton Balint wrote:
You should split this patch to at least 3 parts for easier review.
Adding the codec ID and description, adding MXF demux support, and
adding the decoder/parser.
O.k. -- I'll try to rearrange the changes into a structured group of
patches.
Right now
---
libavcodec/allcodecs.c | 1 +
libavcodec/codec_desc.c | 7 +
libavcodec/codec_id.h | 1 +
libavcodec/dnxucdec.c | 391
libavcodec/version.c| 2 +-
5 files changed, 401 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/dnxucdec
---
Changelog | 1 +
doc/general_contents.texi | 1 +
libavcodec/Makefile | 1 +
3 files changed, 3 insertions(+)
diff --git a/Changelog b/Changelog
index 7237648..0464bee 100644
--- a/Changelog
+++ b/Changelog
@@ -20,6 +20,7 @@ version :
- Intel QSV-accelerated VVC decodin
---
libavformat/mxf.c| 1 +
libavformat/mxfdec.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/libavformat/mxf.c b/libavformat/mxf.c
index a73e40e..35fb73e 100644
--- a/libavformat/mxf.c
+++ b/libavformat/mxf.c
@@ -61,6 +61,7 @@ const MXFCodecUL ff_mxf_codec_uls[] = {
{ {
0x06,0x
---
libavcodec/dnxuc_parser.c | 124 ++
libavcodec/parsers.c | 1 +
2 files changed, 125 insertions(+)
create mode 100644 libavcodec/dnxuc_parser.c
diff --git a/libavcodec/dnxuc_parser.c b/libavcodec/dnxuc_parser.c
new file mode 100644
index 000..55
On 09.09.24 12:42, Anton Khirnov wrote:
Quoting Martin Schitter (2024-09-08 20:41:38)
I'm still unsure about my solution of adding the codec_id entries and
increasing the lead-position value, as criticized by Andreas Rheinhard,
but I don't see any other way to make it better.
I think you're
Thanks for this careful review.
On 09.09.24 12:56, Anton Khirnov wrote:
Quoting Martin Schitter (2024-09-08 20:41:38)
diff --git a/libavcodec/dnxucdec.c b/libavcodec/dnxucdec.c
new file mode 100644
index 000..455c374
--- /dev/null
+++ b/libavcodec/dnxucdec.c
@@ -0,0 +1,495 @@
+/*
+ * Avid D
On Mon, Sep 9, 2024 at 6:35 PM Anton Khirnov wrote:
> Quoting Zhao Zhili (2024-09-07 19:13:40)
> > From: Zhao Zhili
> >
> > ---
> > libavcodec/hevc/dsp_template.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/hevc/dsp_template.c
> b/libavcodec/hev
On Mon, Sep 9, 2024 at 8:04 PM Zhao Zhili wrote:
>
>
> > On Sep 9, 2024, at 18:35, Anton Khirnov wrote:
> >
> > Quoting Zhao Zhili (2024-09-07 19:13:40)
> >> From: Zhao Zhili
> >>
> >> ---
> >> libavcodec/hevc/dsp_template.c | 4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >
40 matches
Mail list logo
