---
doc/APIchanges | 3 ++-
libavfilter/vf_signature.c | 4 ++--
libavformat/avformat.h | 22 ++
libavformat/img2dec.c | 10 +-
libavformat/segment.c | 4 ++--
libavformat/utils.c | 2 +-
libavformat/version_major.h | 2 +-
li
Resolves an integer overflow with the frame_pts option (issue 11194).
Signed-off-by: Filip Mašić
---
doc/APIchanges | 3 +++
libavformat/avformat.h | 7 +--
libavformat/img2enc.c | 6 ++
libavformat/utils.c| 12 +---
libavformat/version.h | 2 +-
5 files changed
All the mentioned issues are fixed in v9.
Thanks for your accurate review!
martin
On 23.09.24 00:24, Marton Balint wrote:
+ for(y = 0; y < frame->height; y++){
+ for(x = 0; x < frame->width; x++){
You might want to push variable declarations to the loop initializer
expression, li
---
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..b6c1f17 100644
--- a/libavformat/mxf.c
+++ b/libavformat/mxf.c
@@ -61,6 +61,7 @@ const MXFCodecUL ff_mxf_codec_uls[] = {
{ {
0x06,0x
> Its not possible for a decoder to save memory by scaling references.
> Decoding would simply break.
> Only way of saving memory while decoding is to simply get rid of output
> frames as soon as possible.
Maybe I didn't explain myself well, but if I set a breakpoint and step over
the code while l
From: Zhao Zhili
It's similar to av_get_frame_filename2 but with int64_t number
support. Make av_get_frame_filename* a wrapper over
ff_get_frame_filename.
---
libavformat/internal.h | 16
libavformat/utils.c| 11 ---
2 files changed, 24 insertions(+), 3 deletions(-)
> On Sep 23, 2024, at 18:18, Filip Mašić wrote:
>
> ---
> doc/APIchanges | 3 ++-
> libavfilter/vf_signature.c | 4 ++--
> libavformat/avformat.h | 22 ++
> libavformat/img2dec.c | 10 +-
> libavformat/segment.c | 4 ++--
> libavformat/ut
On 23/09/2024 12:56, Víctor Manuel Jáquez Leal wrote:
While running this command
./ffmpeg_g -loglevel debug -hwaccel vulkan -init_hw_device vulkan=vk:0,debug=1
-hwaccel_output_format vulkan -i input.y4m -vf 'format=nv12,hwupload' -c:v
h264_vulkan -quality 2 output.mp4 -y
It hit this validatio
> We don't really leverage these extra functions of NVDEC because it
> breaks many assumptions about hwaccels, which are meant to be exact
> decoders.
Yeah I understand that, and expected this kind of feedback. Do you envision
a
way for hwaccels (perhaps in the future) to support some additional l
I understand that the r_frame_rate is the lowest framerate with which all
timestamps can be represented accurately. And I know it is just a guess. But
why did the logic behind the calculation change?
Changes between 6.0 and 6.1:
--- a/libavformat/demux.c
+++ b/libavformat/demux.c
@@ -2864,15 +287
On Mon, 2024-09-23 at 06:37 +0200, Anton Khirnov wrote:
> Quoting fei.w.wang-at-intel@ffmpeg.org (2024-09-18 09:10:30)
> > static void export_frame_params(VVCContext *s, const
> > VVCFrameContext *fc)
> > {
> > AVCodecContext *c = s->avctx;
> > const VVCSPS *sps = fc->ps.sps;
> >
From: Zhao Zhili
w_avg_8_2x2_c: 0.0 ( 0.00x)
w_avg_8_2x2_neon:0.0 ( 0.00x)
w_avg_8_4x4_c: 0.2 ( 1.00x)
w_avg_8_4x4_neon:0.0 ( 0.00x)
From: Zhao Zhili
dmvr_8_12x20_c: 2.2 ( 1.00x)
dmvr_8_12x20_neon: 0.5 ( 4.50x)
dmvr_8_20x12_c: 2.0 ( 1.00x)
dmvr_8_20x12_neon: 0.2 ( 8.00x)
From: Zhao Zhili
dmvr_hv_8_12x20_c: 8.0 ( 1.00x)
dmvr_hv_8_12x20_neon:1.2 ( 6.62x)
dmvr_hv_8_20x12_c: 8.0 ( 1.00x)
dmvr_hv_8_20x12_neon:0.9 ( 8.37x)
---
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/dnxucdec.c | 391 +
3 files changed, 393 insertions(+)
create mode 100644 libavcodec/dnxucdec.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 76366b3..87a9cc1 10
---
libavcodec/Makefile | 1 +
libavcodec/dnxuc_parser.c | 124 ++
libavcodec/parsers.c | 1 +
3 files changed, 126 insertions(+)
create mode 100644 libavcodec/dnxuc_parser.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 936fc34..
---
Changelog | 1 +
doc/general_contents.texi | 1 +
2 files changed, 2 insertions(+)
diff --git a/Changelog b/Changelog
index 49a16da..13e2ac0 100644
--- a/Changelog
+++ b/Changelog
@@ -19,6 +19,7 @@ version :
- Cropping metadata parsing and writing in Matroska and MP4/MOV de/m
---
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
Patchset for DNxUncomprressed decoder.
v9 includes changes to fix issues mentioned in Marton Balints review.
---
libavcodec/codec_desc.c | 7 +++
libavcodec/codec_id.h | 1 +
libavcodec/version.c| 2 +-
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/libavcodec/codec_desc
While running this command
./ffmpeg_g -loglevel debug -hwaccel vulkan -init_hw_device vulkan=vk:0,debug=1
-hwaccel_output_format vulkan -i input.y4m -vf 'format=nv12,hwupload' -c:v
h264_vulkan -quality 2 output.mp4 -y
It hit this validation error:
Validation Error: [ VUID-vkCmdEncodeVideoKHR-N
While running this command
./ffmpeg_g -loglevel debug -hwaccel vulkan -init_hw_device vulkan=vk:0,debug=1
-hwaccel_output_format vulkan -i input.y4m -vf 'format=nv12,hwupload' -c:v
h264_vulkan -quality 2 output.mp4 -y
It hit this validation error:
Validation Error: [ VUID-vkCmdEncodeVideoKHR-N
> On Sep 21, 2024, at 05:39, Martin Storsjö wrote:
>
> From: Jan Ekström
>
> Co-authored-by: Ruslan Chernenko
> Co-authored-by: Martin Storsjö
> ---
> This is a touched up version of Jan and Ruslan's patches for
> AV1 hwaccel via videotoolbox; I tried to polish the code a little
> by not ov
Anton Khirnov (12024-09-23):
> That is all av_buffersink_get_*() except type and frame_rate, for which
> AVFrame does not currently have fields.
NAK: an API that requires an allocated AVFrame to retrieve the
parameters is significantly worst than the existing.
--
Nicolas George
___
From: Zhao Zhili
It's similar to av_get_frame_filename2 but with int64_t number
support. Make av_get_frame_filename* a wrapper over
ff_get_frame_filename.
Co-authored-by: Filip Mašić
---
libavformat/internal.h | 16
libavformat/utils.c| 11 ---
2 files changed, 24
On Mon, Sep 23, 2024 at 4:45 PM Kieran Kunhya via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:
> On Mon, Sep 23, 2024 at 3:27 PM Anton Khirnov wrote:
> >
> > Quoting Antoni Bizoń (2024-09-23 10:09:51)
> > > I understand that the r_frame_rate is the lowest framerate with which
> > > all timestam
Anton Khirnov (12024-09-23):
> I fail to see
…
> how that is a problem, since you need an allocated AVFrame
> to use the buffersink API anyway.
Not at the same point in code.
> Not to mention that even if one allocates a dedicated AVFrame for the
> parameters, the cost is trivial
Anton Khirnov (12024-09-23):
> This way, av_buffersink_get_frame_flags() can replace almost all
> av_buffersink_get_*(), including some future parameters we will want to
> export.
> ---
> doc/APIchanges | 1 +
> libavfilter/buffersink.c | 47
> l
Anton Khirnov (12024-09-23):
> ---
> fftools/ffplay.c | 20 +---
> 1 file changed, 17 insertions(+), 3 deletions(-)
What an enhancement!
--
“I dont see why” isn't an argument.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
htt
From: Zhao Zhili
---
libavformat/img2enc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavformat/img2enc.c b/libavformat/img2enc.c
index 526a11e5ee..41638d92b8 100644
--- a/libavformat/img2enc.c
+++ b/libavformat/img2enc.c
@@ -160,13 +160,13 @@ static int write_
Quoting Nicolas George (2024-09-23 17:56:47)
> Anton Khirnov (12024-09-23):
> > That is all av_buffersink_get_*() except type and frame_rate, for which
> > AVFrame does not currently have fields.
>
> NAK: an API that requires an allocated AVFrame to retrieve the
> parameters is significantly worst
Signed-off-by: James Almer
---
Untested, as i can't find a sample that triggers this code.
libavcodec/hevc/cabac.c | 3 ++-
libavcodec/hevc/ps.c| 18 +-
libavcodec/hevc/ps.h| 1 +
3 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/libavcodec/hevc/cabac.c b/
Quoting James Almer (2024-09-23 18:35:35)
> Signed-off-by: James Almer
> ---
> Untested, as i can't find a sample that triggers this code.
>
> libavcodec/hevc/cabac.c | 3 ++-
> libavcodec/hevc/ps.c| 18 +-
> libavcodec/hevc/ps.h| 1 +
> 3 files changed, 16 insertions(+
On 9/23/2024 2:07 PM, Anton Khirnov wrote:
Quoting James Almer (2024-09-23 18:35:35)
Signed-off-by: James Almer
---
Untested, as i can't find a sample that triggers this code.
libavcodec/hevc/cabac.c | 3 ++-
libavcodec/hevc/ps.c| 18 +-
libavcodec/hevc/ps.h| 1 +
On Mon, Sep 23, 2024 at 6:07 AM Zhao Zhili wrote:
>
>
>
> > On Sep 21, 2024, at 05:39, Martin Storsjö wrote:
> >
> > From: Jan Ekström
> >
> > Co-authored-by: Ruslan Chernenko
> > Co-authored-by: Martin Storsjö
> > ---
> > This is a touched up version of Jan and Ruslan's patches for
> > AV1 hw
> On Sep 14, 2024, at 18:45, Anton Khirnov wrote:
>
> ---
> tests/fate/hevc.mak | 10 ++
> tests/ref/fate/hevc-mv-switch | 172 ++
> 2 files changed, 182 insertions(+)
> create mode 100644 tests/ref/fate/hevc-mv-switch
Fate break on macOS.
https://git
> On Sep 24, 2024, at 01:24, Cameron Gutman wrote:
>
> On Mon, Sep 23, 2024 at 6:07 AM Zhao Zhili wrote:
>>
>>
>>
>>> On Sep 21, 2024, at 05:39, Martin Storsjö wrote:
>>>
>>> From: Jan Ekström
>>>
>>> Co-authored-by: Ruslan Chernenko
>>> Co-authored-by: Martin Storsjö
>>> ---
>>> This
Quoting Zhao Zhili (2024-09-23 19:49:40)
>
>
> > On Sep 14, 2024, at 18:45, Anton Khirnov wrote:
> >
> > ---
> > tests/fate/hevc.mak | 10 ++
> > tests/ref/fate/hevc-mv-switch | 172 ++
> > 2 files changed, 182 insertions(+)
> > create mode 100644 tests/
From: Fei Wang
This support alpha encode for HEVC introduced by Apple:
https://developer.apple.com/videos/play/wwdc2019/506/
Currently, it only support RGBA video memory as input. RGB and alpha
channel will be encoded in different layers with 4:2:0 color format.
And set texture to shared to all
From: Fei Wang
Once the '-mse' option enabled, MSE/PSNR of each frame will be shown in
VERBOSE debug level log.
Signed-off-by: Fei Wang
---
doc/encoders.texi| 4 +
libavcodec/qsvenc.c | 162 +++
libavcodec/qsvenc.h | 12 +++
libavcodec/q
From: Fei Wang
Sliding window bitrate control will provide a more stable bitrate when
use CBR bitrate control mode.
Signed-off-by: Fei Wang
---
doc/encoders.texi| 9 +
libavcodec/qsvenc.c | 25 +
libavcodec/qsvenc.h | 11 +++
libavcode
From: Fei Wang
Screen Content Tool provides Intra Block Copy and Palette Mode when encoding.
Signed-off-by: Fei Wang
---
doc/encoders.texi | 6 ++
libavcodec/qsvenc.c | 43 +
libavcodec/qsvenc.h | 9 -
libavcodec/qsvenc_av1.c
From: Fei Wang
Signed-off-by: Fei Wang
---
Changelog| 4
libavcodec/version.h | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/Changelog b/Changelog
index 49a16da7ca..3f9bfcdd4e 100644
--- a/Changelog
+++ b/Changelog
@@ -26,6 +26,10 @@ version :
- stream s
Why should this be an option, as opposed to always being on when
available?
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-
On Mon, 2024-09-23 at 09:21 +0200, Anton Khirnov wrote:
> Why should this be an option, as opposed to always being on when
> available?
hevc_qsv also support encode RGBA by using regular Main 444 profile
which will discard Alpha channel. So it's better to use an option to
distinguish them.
Thanks
I don't mind; whatever gets this merged the fastest is best for me. I
wasn't aware there was an internal header, and I don't know why any of the
av_get_frame_filename functions are exposed. I'll add some comments
regardless:
1. Even though the function was previously externally documented as takin
Quoting Antoni Bizoń (2024-09-23 10:09:51)
> I understand that the r_frame_rate is the lowest framerate with which
> all timestamps can be represented accurately. And I know it is just a
> guess. But why did the logic behind the calculation change?
Because you're most likely using a codec like H.2
On 9/23/2024 1:22 AM, Anton Khirnov wrote:
Quoting James Almer (2024-09-23 04:17:46)
On 9/22/2024 3:00 PM, Anton Khirnov wrote:
The HEVC decoder will start setting stereoscopic view position (left or
right) based on 3D Reference Displays Info SEI message in future
commits. This information shou
Quoting Wang, Fei W (2024-09-23 10:40:14)
> On Mon, 2024-09-23 at 06:37 +0200, Anton Khirnov wrote:
> > Quoting fei.w.wang-at-intel@ffmpeg.org (2024-09-18 09:10:30)
> > > static void export_frame_params(VVCContext *s, const
> > > VVCFrameContext *fc)
> > > {
> > > AVCodecContext *c = s->
Hello,
I'm interested in implementing uncompressed MP4 parsing according to the
newly released ISO/IEC 23001-17:2024. Would anyone be interested in further
discussing this with me?
Thanks,
Devon Sookhoo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.
On Mon, Sep 23, 2024 at 3:27 PM Anton Khirnov wrote:
>
> Quoting Antoni Bizoń (2024-09-23 10:09:51)
> > I understand that the r_frame_rate is the lowest framerate with which
> > all timestamps can be represented accurately. And I know it is just a
> > guess. But why did the logic behind the calcul
This way, av_buffersink_get_frame_flags() can replace almost all
av_buffersink_get_*(), including some future parameters we will want to
export.
---
doc/APIchanges | 1 +
libavfilter/buffersink.c | 47
libavfilter/buffersink.h | 16 --
---
fftools/ffmpeg_filter.c | 96 ++---
1 file changed, 42 insertions(+), 54 deletions(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 81c4911b03..b4c0876fa6 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -197,13 +
---
libavdevice/lavfi.c | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/libavdevice/lavfi.c b/libavdevice/lavfi.c
index 3b77a7396a..ef7d1fef1a 100644
--- a/libavdevice/lavfi.c
+++ b/libavdevice/lavfi.c
@@ -102,6 +102,7 @@ av_cold static int lavf
So the caller does not need to call av_buffersink_get_time_base()
separately.
---
doc/APIchanges | 3 +++
doc/examples/transcode.c | 1 -
fftools/ffmpeg_filter.c | 2 --
fftools/ffplay.c | 10 ++
libavdevice/lavfi.c | 4 ++--
libavfilter/buffersink.c | 21 ++
---
fftools/ffplay.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 4ea48e11bb..ef45f12906 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -2702,6 +2702,7 @@ static int stream_component_open(VideoState *is
---
tools/uncoded_frame.c | 37 ++---
1 file changed, 22 insertions(+), 15 deletions(-)
diff --git a/tools/uncoded_frame.c b/tools/uncoded_frame.c
index a17d406417..39818963d0 100644
--- a/tools/uncoded_frame.c
+++ b/tools/uncoded_frame.c
@@ -153,6 +153,13 @@ int m
That is all av_buffersink_get_*() except type and frame_rate, for which
AVFrame does not currently have fields.
---
doc/APIchanges | 12 +++-
libavfilter/buffersink.c| 4
libavfilter/buffersink.h| 19 ++-
libavfilter/version_major.h | 1 +
4 file
Quoting Kieran Kunhya via ffmpeg-devel (2024-09-23 16:45:30)
> On Mon, Sep 23, 2024 at 3:27 PM Anton Khirnov wrote:
> >
> > Quoting Antoni Bizoń (2024-09-23 10:09:51)
> > > I understand that the r_frame_rate is the lowest framerate with which
> > > all timestamps can be represented accurately. And
On 22/09/2024 20:40, nihil-admirari via ffmpeg-devel wrote:
From: nihil-admirari <50202386+nihil-admir...@users.noreply.github.com>
Fixes build issue for Win32 targets
---
libavcodec/vulkan_encode_h264.c | 2 +-
libavcodec/vulkan_encode_h265.c | 2 +-
2 files changed, 2 insertions(+), 2 dele
> On Sep 19, 2024, at 21:46, nicolas.d...@gmail.com wrote:
>
> From: Nicolas Jorge Dato
>
> When in listener mode and writing, now libsrt supports multiple clients
> configured with the max_clients parameter.
>
> When max_clients=1 (default), it behaves as before.
> When max_clientes > 1, aft
This commit also fixes the issue that the call to ff_sws_init_range_convert()
from sws_init_swscale() was not setting up the arch-specific optimizations.
---
libswscale/aarch64/swscale.c | 5 -
libswscale/loongarch/swscale_init_loongarch.c | 1 -
libswscale/riscv/swscale.c
There is an issue with the constants used in YUV to YUV range conversion,
where the upper bound is not respected when converting to mpeg range.
With this patchset, the constants are calculated at runtime, depending on
the bit depth. This approach also allows us to more easily understand how
the co
There is an issue with the constants used in YUV to YUV range conversion,
where the upper bound is not respected when converting to mpeg range.
With this commit, the constants are calculated at runtime, depending on
the bit depth. This approach also allows us to more easily understand how
the cons
This commit also reduces the number of times ff_sws_init_scale() gets
called (only once per bit depth), and the number of times randomize_buffers()
gets called (only if the function must be checked).
Benchmarks are only performed on bit depths 8 and 16 (since they are
different functions, and not
chrRangeFromJpeg16_1920_c:3893.0 ( 1.00x)
chrRangeFromJpeg16_1920_sse2: 3249.0 ( 1.20x)
chrRangeFromJpeg16_1920_avx2: 1636.0 ( 2.38x)
chrRangeToJpeg16_1920_c: 7731.0 ( 1.00x)
chrRangeToJpeg16_19
chrRangeFromJpeg8_1920_c: 3874.8 ( 1.00x)
chrRangeFromJpeg8_1920_sse2: 1493.8 ( 2.59x)
chrRangeFromJpeg8_1920_avx2: 741.8 ( 5.22x)
chrRangeToJpeg8_1920_c: 5232.8 ( 1.00x)
chrRangeToJpeg8_192
Reduce input sizes to 8 (to test that the function works with widths
smaller than the vector length) and 1920 (raising the largest input
size to improve benchmark results).
---
tests/checkasm/sw_range_convert.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tests/check
---
tests/checkasm/sw_range_convert.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tests/checkasm/sw_range_convert.c
b/tests/checkasm/sw_range_convert.c
index df27b6c81e..e97388d14a 100644
--- a/tests/checkasm/sw_range_convert.c
+++ b/tests/checkasm/sw_range_convert.c
@@ -62,6 +62,7 @@ s
---
tests/checkasm/sw_gbrp.c | 15 ---
tests/checkasm/sw_range_convert.c | 8 ++--
tests/checkasm/sw_scale.c | 11 ---
3 files changed, 10 insertions(+), 24 deletions(-)
diff --git a/tests/checkasm/sw_gbrp.c b/tests/checkasm/sw_gbrp.c
index d843730f3e..74
---
libswscale/loongarch/swscale_init_loongarch.c | 32 +--
libswscale/swscale.c | 8 ++---
libswscale/x86/swscale.c | 12 +++
3 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/libswscale/loongarch/swscale_init_loong
---
tests/checkasm/sw_range_convert.c | 48 +++
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/tests/checkasm/sw_range_convert.c
b/tests/checkasm/sw_range_convert.c
index e3e5096729..01c4549e53 100644
--- a/tests/checkasm/sw_range_convert.c
+++ b/tests
These conditions are already checked for in the main init function.
---
libswscale/aarch64/swscale.c | 2 --
libswscale/loongarch/swscale_init_loongarch.c | 4
libswscale/riscv/swscale.c| 3 +--
libswscale/swscale.c | 2 +-
libswsc
We are already setting the range, so we can use regular YUV pixel
formats instead of YUVJ.
---
tests/checkasm/sw_range_convert.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tests/checkasm/sw_range_convert.c
b/tests/checkasm/sw_range_convert.c
index 1f04988097..8c8a
A55 A76
chrRangeFromJpeg16_1920_c: 28848.5 6325.2
chrRangeFromJpeg16_1920_neon: 8433.0 ( 3.42x) 3365.8 ( 1.88x)
chrRangeToJpeg16_1920_c: 36558.7 9479.0
chrRangeToJpeg16_1920_neon: 9395.5 ( 3.89x) 4083.8 ( 2.32x)
l
A55 A76
chrRangeFromJpeg8_1920_c: 28842.4 6346.5
chrRangeFromJpeg8_1920_neon: 5310.9 ( 5.43x) 2264.2 ( 2.80x)
chrRangeToJpeg8_1920_c: 36520.7 9514.0
chrRangeToJpeg8_1920_neon: 6033.2 ( 6.05x) 2645.5 ( 3.60x)
lumRan
Drop patch 2/4 for now. It needs more polish.
See patch v2
https://ffmpeg.org/pipermail/ffmpeg-devel/2024-September/333800.html
> On Sep 22, 2024, at 01:41, Zhao Zhili wrote:
>
> From: Zhao Zhili
>
> apply_bdof_8_8x16_c:18.7 ( 1.00x)
> apply_bdof_8_8x16_ne
From: Zhao Zhili
It's similar to av_get_frame_filename2 but with int64_t number
support. Make av_get_frame_filename* a wrapper over
ff_get_frame_filename.
Co-authored-by: Filip Mašić
---
libavformat/internal.h | 16
libavformat/utils.c| 11 ---
2 files changed, 24
> On Sep 23, 2024, at 22:25, Filip Mašić wrote:
>
> I don't mind; whatever gets this merged the fastest is best for me. I
> wasn't aware there was an internal header, and I don't know why any of the
> av_get_frame_filename functions are exposed. I'll add some comments
> regardless:
>
> 1. Even
On Di, 2024-09-24 at 00:53 +0300, Andrew Randrianasulu wrote:
> I tried to trivially add qsv/mediacodec decode to cinelerra-gg, but
> discovered that I can't use it like vaapi/vdpau/cuda because (?)
> qsv/mediacodec not listed in
>
> ffmpeg/libavcodec/hwconfig.h
> and (for h264) in
> ffmpeg/libavc
On Mon, Sep 23, 2024 at 08:30:09PM +0100, Kieran Kunhya via ffmpeg-devel wrote:
> > On Mon, Sep 23, 2024 at 4:45 PM Kieran Kunhya via ffmpeg-devel
> > wrote:
> >>
> >> On Mon, Sep 23, 2024 at 3:27 PM Anton Khirnov wrote:
> >> >
> >> > Quoting Antoni Bizoń (2024-09-23 10:09:51)
> >> > > I underst
On Mon, Sep 23, 2024 at 12:43 PM Zhao Zhili wrote:
>
>
>
> > On Sep 24, 2024, at 01:24, Cameron Gutman wrote:
> >
> > On Mon, Sep 23, 2024 at 6:07 AM Zhao Zhili wrote:
> >>
> >>
> >>
> >>> On Sep 21, 2024, at 05:39, Martin Storsjö wrote:
> >>>
> >>> From: Jan Ekström
> >>>
> >>> Co-authored-by
---
MAINTAINERS| 7 +--
doc/developer.texi | 2 +-
doc/fate.texi | 2 +-
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 036066d..04a4a05 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -61,8 +61,11 @@ API tests
On 24.09.24 00:31, Michael Niedermayer wrote:
Btw.: the fate info and the "webserver"-entry one line above use
(S:...)-entries, which aren't mentioned as a possible variant in the
descriptive top section of MAINTAINERS. Shouldn't these be (T:...)-
or (W: ...)-entries or the (S: ...) kind be
On Mon, Sep 23, 2024 at 09:56:52PM +0200, Anton Khirnov wrote:
> Quoting Kieran Kunhya via ffmpeg-devel (2024-09-23 21:30:09)
> > > On Mon, Sep 23, 2024 at 4:45 PM Kieran Kunhya via ffmpeg-devel
> > > wrote:
[...]
> > I think the OP is correct here that the behaviour makes no sense. If
> > someth
On Fri, Aug 23, 2024 at 03:43:54PM -0400, Neal Gompa wrote:
> On Wed, Aug 14, 2024 at 11:11 AM Michael Niedermayer
> wrote:
> >
> > Hi all
> >
> > Are there any upcoming LTS releases that want to/could include FFmpeg 7.1 ?
> > If so please reply here and list the date before which we would have to
On Mon, Sep 23, 2024 at 8:56 PM Anton Khirnov wrote:
>
> Quoting Kieran Kunhya via ffmpeg-devel (2024-09-23 21:30:09)
> > > On Mon, Sep 23, 2024 at 4:45 PM Kieran Kunhya via ffmpeg-devel
> > > wrote:
> > >>
> > >> On Mon, Sep 23, 2024 at 3:27 PM Anton Khirnov wrote:
> > >> >
> > >> > Quoting An
I tried to trivially add qsv/mediacodec decode to cinelerra-gg, but
discovered that I can't use it like vaapi/vdpau/cuda because (?)
qsv/mediacodec not listed in
ffmpeg/libavcodec/hwconfig.h
and (for h264) in
ffmpeg/libavcodec/h264dec.c
so on decoding I get (in termux, cingg compiled with system
Fixes: Use of uninitialized value
Fixes:
71350/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ILBC_fuzzer-6322020827070464
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/ilbcdec.c | 2 +-
Fixes: Use of uninitialized memory
Fixes:
71546/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EATGQ_fuzzer-5607656650244096
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/eatgq.c | 3 ++-
Fixes: Use of uninitialized memory
Fixes:
71444/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-5448597561212928
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/mxfdec.c | 3 ++-
1 file
Signed-off-by: Michael Niedermayer
---
libavcodec/eatgq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/eatgq.c b/libavcodec/eatgq.c
index d326c053907..190c57f1c00 100644
--- a/libavcodec/eatgq.c
+++ b/libavcodec/eatgq.c
@@ -156,7 +156,6 @@ static int tgq_decode_m
This does not replicate on my setup, thus this is a blind fix based on ossfuzz
trace
Fixes: use of uninitialized value
Fixes:
71747/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5427736120721408
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master
Fixes: Use of uninitialized value
Fixes:
71551/clusterfuzz-testcase-minimized-ffmpeg_dem_QCP_fuzzer-4647386712965120
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/qcp.c | 3 ++-
1 file chan
Fixes: undefined behavior
Fixes:
71747/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5427736120721408
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/get_bits.h | 2 +-
1 file
Quoting Kieran Kunhya via ffmpeg-devel (2024-09-23 21:30:09)
> > On Mon, Sep 23, 2024 at 4:45 PM Kieran Kunhya via ffmpeg-devel
> > wrote:
> >>
> >> On Mon, Sep 23, 2024 at 3:27 PM Anton Khirnov wrote:
> >> >
> >> > Quoting Antoni Bizoń (2024-09-23 10:09:51)
> >> > > I understand that the r_fram
On 9/23/2024 3:41 PM, Anton Khirnov wrote:
Quoting Zhao Zhili (2024-09-23 19:49:40)
On Sep 14, 2024, at 18:45, Anton Khirnov wrote:
---
tests/fate/hevc.mak | 10 ++
tests/ref/fate/hevc-mv-switch | 172 ++
2 files changed, 182 insertions(+)
create mod
Hi,
> Could we somehow get the AVFrame pointer in your custom callback data
> or the VmafMetadata data? When all of the expected metadata is written
> then you'll know you're ready to forward the frame through the
> filtergraph. Doing it this way hopefully avoids a lot of the code and
> traversing
> On Mon, Sep 23, 2024 at 4:45 PM Kieran Kunhya via ffmpeg-devel
> wrote:
>>
>> On Mon, Sep 23, 2024 at 3:27 PM Anton Khirnov wrote:
>> >
>> > Quoting Antoni Bizoń (2024-09-23 10:09:51)
>> > > I understand that the r_frame_rate is the lowest framerate with which
>> > > all timestamps can be repr
On Fri, Sep 20, 2024 at 12:27:19PM +0200, Martin Schitter wrote:
> v2 adds the address as a second (L: ...)-entry
> to the Fate info in MAINTAINERS.
>
> I'm not sure if this is correct because I couldn't find other lines,
> where the same kind of entry gets used twice.
>
> Btw.: the fate info a
> On Sep 18, 2024, at 21:11, Zhao Zhili wrote:
>
> From: Zhao Zhili
>
> Since c0666d8b, rgb24toyv12 is broken for width non-aligned to 16.
> Add a simple wrapper to handle the non-aligned part.
>
> Signed-off-by: Zhao Zhili
> Co-authored-by: johzzy
> ---
> v2: test width 2 and 540
>
> li
100 matches
Mail list logo
