lgtm
___
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".
Add a new version of yadif_filter_line performed using packed bytes
instead of the packed words used by the current implementaiton. As
a result this implementation runs almost 2x as fast as the current
fastest SSSE3 implementation.
This implementation is created from scratch based on the C code, w
filter_line is generally vectorized, wheras filter_edge is implemented
in C. Currently we rely on filter_edge to process non-edges in cases
where the width doesn't match the alignment. This causes us to process
non-edge pixels with the slow C implementation vs the faster SSE
implementation.
It is
Reformat some of the code to improve readability and reduce code
duplication. This change is intended to be purely cosmentic and
shouldn't result in any functional changes.
Signed-off-by: Chris Phlipot
---
libavfilter/vf_yadif.c | 11 +--
libavfilter/yadif.h| 3 +--
2 files changed,
Allow the alignment to be determined based on what yadif_filter_line
implementation is used. Currently this is either 1, or 8 depending
on whether the C code or the x86 SSE code is used, but allows for
other future implementations that use a larger alignment.
Adjusting MAX_ALIGN to 32 in the case
If alignment is set to less than 4 filter_edges will produce incorrect
output and not filter the entire edge. To fix this, make sure that
the edge size is at least 3.
Signed-off-by: Chris Phlipot
---
libavfilter/vf_yadif.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/l
On 19 Jul 2022, at 20:31, Amir Mazzarella wrote:
> Ping
>
> On Fri, Jul 8, 2022 at 8:57 PM Amir Mazzarella wrote:
>
>> FFVulkanExtensions enum does not have a value for 0 defined, and bitwise
>> OR on enums is not safe. The function returns uint64_t, so it makes more
>> sense and is safer to d
Fixes: Timeout
Fixes:
49216/clusterfuzz-testcase-minimized-ffmpeg_IO_DEMUXER_fuzzer-6563000529584128
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/mov.c | 2 ++
1 file changed, 2 insertions
Fixes: infinite loop
Fixes:
49223/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HDR_fuzzer-6603308596330496
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/hdrdec.c | 2 +-
1 file changed,
On Tue, Jul 19, 2022 at 2:24 PM Nicolas George wrote:
> Thanks for clarifying. I confess I had more or less guessed. FFmpeg is
> C, and its headers, public or not, as a rule do not contain
> accommodations to be included as is in other languages.
I understand that FFmpeg does not contain accommod
On Tue, Jul 19, 2022 at 05:56:54PM +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> There is an internal ABI between libva.so the libva-XXX.so libraries.
>
> With a recent change, the internal va_fool API was removed breaking the
> ABI. So if libva.so and libva-x11.so are from different versi
Amir Mazzarella (12022-07-19):
> Thank you for your response! A C++ compiler can't do implicit casts like a
> C compiler can, in this instance. This is fine for most of FFmpeg's
> codebase, since these tricks are in C source files, but in this instance it
> is in a header file. If any C++ code incl
On Tue, Jul 19, 2022 at 11:21 PM Amir Mazzarella
wrote:
>
> Thank you for your response! A C++ compiler can't do implicit casts like a
> C compiler can, in this instance. This is fine for most of FFmpeg's
> codebase, since these tricks are in C source files, but in this instance it
> is in a heade
Thank you for your response! A C++ compiler can't do implicit casts like a
C compiler can, in this instance. This is fine for most of FFmpeg's
codebase, since these tricks are in C source files, but in this instance it
is in a header file. If any C++ code includes this header file, even with
extern
Hi. Thanks for the patch.
Amir Mazzarella (12022-07-09):
> Signed-off-by: Amir Mazzarella
> ---
> libavutil/vulkan_loader.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavutil/vulkan_loader.h b/libavutil/vulkan_loader.h
> index 3f1ee6aa46..fa8e5ed171 100644
> ---
Ping
On Fri, Jul 8, 2022 at 9:31 PM Amir Mazzarella wrote:
> Signed-off-by: Amir Mazzarella
> ---
> libavutil/vulkan_loader.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavutil/vulkan_loader.h b/libavutil/vulkan_loader.h
> index 3f1ee6aa46..fa8e5ed171 100644
> -
Ping
On Fri, Jul 8, 2022 at 8:57 PM Amir Mazzarella wrote:
> FFVulkanExtensions enum does not have a value for 0 defined, and bitwise
> OR on enums is not safe. The function returns uint64_t, so it makes more
> sense and is safer to do arithmetic in terms of uint64_t
>
> Signed-off-by: Amir Mazz
Emil Velikov (12022-07-19):
> As you may know the libva* set of libraries share an internal ABI
> between them. In a resent libva commit, the va_fool API was removed.
>
> Thus if one is to mix different versions of libva.so and libva-x11.so
> they will get an error, leading to a crash of the whole
On 7/19/2022 9:57 AM, Anton Khirnov wrote:
Quoting James Almer (2022-07-19 14:51:13)
If this is only >= 122, what will pic_out above contain in older versions?
IIUC it won't do deblocking, so the reconstructed frame won't be exactly
as decoded.
That kinda defeats the purpose, and is also inc
Greetings everyone,
As you may know the libva* set of libraries share an internal ABI
between them. In a resent libva commit, the va_fool API was removed.
Thus if one is to mix different versions of libva.so and libva-x11.so
they will get an error, leading to a crash of the whole stack.
The simp
Thank you for the feedback Anton.
I only care about this value being displayed when calling ffprobe, so does it
make sense to do this in ffprobe.c or could this be added to the existing mov.c
demuxer?
“demuxer-private AV_OPT_FLAG_EXPORT” is new territory for me, so was wondering
if there some
On Tue, 19 Jul 2022 at 17:56, Emil Velikov wrote:
>
> Greetings everyone,
>
Sincere apologies for accidentally sending this out multiple times. I
may have found a bug where `git send-email --dry-run` does not work
correctly.
Thanks
Emil
___
ffmpeg-deve
From: Emil Velikov
Similar to the VAAPI_X11 bits, guard all the VAAPI_DRM parts behind an
disabled.
Cc: Mark Thompson
Signed-off-by: Emil Velikov
---
libavutil/hwcontext_vaapi.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_v
From: Emil Velikov
There is an internal ABI between libva.so and libva-drm.so. So having
mismatched versions can cause all sorts of issues.
We had the breakage between libva.so and libva-x11.so addressed with
earlier commit. There's no point in waiting for things to break wrt
libva-drm.so so pre
From: Emil Velikov
There is an internal ABI between libva.so the libva-XXX.so libraries.
With a recent change, the internal va_fool API was removed breaking the
ABI. So if libva.so and libva-x11.so are from different version, the
whole stack will crash.
Instead we can dlopen() the libva-x11 lib
Greetings everyone,
As you may know the libva* set of libraries share an internal ABI
between them. In a resent libva commit, the va_fool API was removed.
Thus if one is to mix different versions of libva.so and libva-x11.so
they will get an error, leading to a crash of the whole stack.
The simp
From: Emil Velikov
Similar to the VAAPI_X11 bits, guard all the VAAPI_DRM parts behind an
disabled.
Cc: Mark Thompson
Signed-off-by: Emil Velikov
---
libavutil/hwcontext_vaapi.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_v
From: Emil Velikov
There is an internal ABI between libva.so and libva-drm.so. So having
mismatched versions can cause all sorts of issues.
We had the breakage between libva.so and libva-x11.so addressed with
earlier commit. There's no point in waiting for things to break wrt
libva-drm.so so pre
From: Emil Velikov
There is an internal ABI between libva.so the libva-XXX.so libraries.
With a recent change, the internal va_fool API was removed breaking the
ABI. So if libva.so and libva-x11.so are from different version, the
whole stack will crash.
Instead we can dlopen() the libva-x11 lib
On Tue, Jul 19, 2022 at 9:44 AM Shane Warren wrote:
>
> I have been working on getting scte35 pass through working in FFmpeg. I have
> the SIT pid being passed through fine, but I need to adjust the
> pts_adjustment field since I'm doing a live transcode and using vsync 1.
>
> I'm struggling wit
On Tue, 19 Jul 2022 at 12:34, Timo Rothenpieler wrote:
>
> I'm honestly not sure what this is complaining about.
Sorry:
Maybe the my copy/paste was less than east to read?
Maybe because mu copy/paste was from a make -j6 in Docker run from Jenkins?
Maybe the problem is cross-compiling with MinGW?
mån 2022-07-11 klockan 23:44 +0200 skrev Michael Niedermayer:
>
> + { {
> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x02,0x02,0x03,0x09
> ,0x01,0x00 }, 15, AV_CODEC_ID_FFV1 }, /*FFV1 V0 */
> + { {
> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x02,0x02,0x03,0x09
> ,0x02,0
Signed-off-by: James Almer
---
tools/target_dec_fuzzer.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index 06c38a96c1..5831052ba8 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -409,6 +409,8 @@ int LLVMFuzz
Signed-off-by: James Almer
---
tools/target_dec_fuzzer.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index 7d71dd39e3..06c38a96c1 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -406,6 +406,8 @@ int LLVMFuzz
Signed-off-by: James Almer
---
tools/target_dec_fuzzer.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index 1587045e02..7d71dd39e3 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -336,7 +336,
I have been working on getting scte35 pass through working in FFmpeg. I have
the SIT pid being passed through fine, but I need to adjust the pts_adjustment
field since I'm doing a live transcode and using vsync 1.
I'm struggling with finding how to match up an incoming frame of video to a
trans
Quoting James Almer (2022-07-19 14:51:13)
> If this is only >= 122, what will pic_out above contain in older versions?
IIUC it won't do deblocking, so the reconstructed frame won't be exactly
as decoded.
--
Anton Khirnov
___
ffmpeg-devel mailing list
f
On 7/19/2022 9:47 AM, Anton Khirnov wrote:
---
Now tested with x264 118, the oldest supported.
---
libavcodec/libx264.c | 57 +++-
1 file changed, 56 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index e8c1fb2106.
---
Now tested with x264 118, the oldest supported.
---
libavcodec/libx264.c | 57 +++-
1 file changed, 56 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index e8c1fb2106..04e8147276 100644
--- a/libavcodec/libx264.c
+
Quoting James Almer (2022-07-18 14:23:58)
> On 7/18/2022 4:12 AM, Anton Khirnov wrote:
> > ---
> > libavcodec/libx264.c | 52 +++-
> > 1 file changed, 51 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> > ind
From: Niklas Haas
Only if requested, and only if the codec signals support for ICC
profiles. Implementation roughly matches the functionality of the
existing vf_iccgen filter, albeit with some reduced flexibility and no
caching.
Ideally, we'd also only do this on the first frame (e.g. mjpeg, apn
From: Niklas Haas
Implementation for the decode side of the ICC profile API, roughly
matching the behavior of the existing vf_iccdetect filter.
Closes: #9673
Signed-off-by: Niklas Haas
---
libavcodec/decode.c | 61 +
1 file changed, 56 insertions(+)
From: Niklas Haas
Handling this in general code makes more sense than handling it in
individual codec files, because it would be a lot of unnecessary code
duplication for the plenty of formats that support exporting ICC
profiles (jpg, png, tiff, webp, jxl, ...).
encode.c and decode.c will be in
From: Niklas Haas
This functionally already exists, but as pointed out in #9672 and #9673,
requiring users to manually include filters is clumsy, error-prone and
hard to use together with tools like ffplay.
To streamline ICC profile support, add a new AVCodecContext flag to
globally enable readi
From: Niklas Haas
Codecs that can read/write ICC profiles deserve a special capability so
the common logic in encode.c/decode.c can decide whether or not there
needs to be any special handling for ICC profiles. The motivation here
is to be able to use it to decide whether or not an ICC profile ne
From: Niklas Haas
We will need this helper inside libavcodec in the future, so move it
there, leaving behind an #include to the raw source file in its old
location in libvfilter. This approach is inspired by the handling of
vulkan.c, and avoids us needing to expose any of it publicly (or
semi-pub
Changes in v3:
- switch from `int icc_profiles` to a new AV_CODEC_FLAG2 to avoid ABI
break
- rebased onto master and fixed merge conflicts
Changes in v2:
- remove unnecessary import
- fixed assignment-instead-of-equality
- fixed #ifdef -> #if
___
ffm
On 19.07.2022 13:34, Timo Rothenpieler wrote:
On 19.07.2022 09:25, Mark Himsley wrote:
On Sun, 17 Jul 2022 at 12:37, Timo Rothenpieler
wrote:
I will push this series tonight, in about 8 hours from now.
Last chance to delay this by reviewing or raising related concerns.
Just FYI - this broke
On Wed, 06 Jul 2022 15:35:41 +0200 Anton Khirnov wrote:
> Quoting Niklas Haas (2022-06-29 12:12:51)
> > From: Niklas Haas
> >
> > Only if requested, and only if the codec signals support for ICC
> > profiles. Implementation roughly matches the functionality of the
> > existing vf_iccgen filter,
On Mon, Jul 18, 2022 at 08:35:00PM +0200, Tomas Härdin wrote:
> mån 2022-07-11 klockan 23:44 +0200 skrev Michael Niedermayer:
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavformat/mxf.c | 3 +++
> > libavformat/mxf.h | 1 +
> > libavformat/mxfdec.c | 48
> > ++
On Mon, Jul 18, 2022 at 08:29:56PM +0200, Anton Khirnov wrote:
> Quoting James Almer (2022-07-18 20:18:16)
> >
> >
> > On 7/18/2022 3:15 PM, Anton Khirnov wrote:
> > > Quoting James Almer (2022-07-18 14:23:58)
> > >> On 7/18/2022 4:12 AM, Anton Khirnov wrote:
> > >>> ---
> > >>>libavcodec/lib
On 7/19/2022 8:34 AM, Michael Niedermayer wrote:
Fixes: Timeout
Fixes:
49160/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFV1_fuzzer-5672826144686080
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
Fixes: OOM
Fixes:
48911/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_fuzzer-6352002510094336
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/exr.c | 6 --
1 file changed, 4 insert
Fixes: Timeout
Fixes:
49003/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MMVIDEO_fuzzer-5550368423018496
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
tools/target_dec_fuzzer.c | 1 +
1 file chang
Fixes: Timeout
Fixes:
49172/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MWSC_fuzzer-5213749102903296
Signed-off-by: Michael Niedermayer
---
tools/target_dec_fuzzer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index 017c5cf024.
Signed-off-by: Michael Niedermayer
---
libavcodec/mpeg4videoenc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/mpeg4videoenc.c b/libavcodec/mpeg4videoenc.c
index 8f0452de3a..5f83a9dff1 100644
--- a/libavcodec/mpeg4videoenc.c
+++ b/libavcodec/mpeg4videoenc.c
@
Fixes: Timeout
Fixes:
49160/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFV1_fuzzer-5672826144686080
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/ffv1dec.c | 6 +-
1 file changed,
Fixes: signed integer overflow: 2147483647 + 32 cannot be represented in type
'int'
Fixes:
49014/clusterfuzz-testcase-minimized-ffmpeg_dem_ASF_fuzzer-6314973315334144
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niede
On 19.07.2022 09:25, Mark Himsley wrote:
On Sun, 17 Jul 2022 at 12:37, Timo Rothenpieler wrote:
I will push this series tonight, in about 8 hours from now.
Last chance to delay this by reviewing or raising related concerns.
Just FYI - this broke my nightly automated builds - which
cross-comp
The amount of padding samples reported by containers take into account the
extended samplerate in HE-AAC.
Fixes ticket #9671.
Signed-off-by: James Almer
---
libavcodec/aacdec_template.c | 3 ---
tests/ref/fate/audiomatch-afconvert-16000-mono-he-m4a| 2 +-
tests/r
On Sun, 17 Jul 2022 at 12:37, Timo Rothenpieler wrote:
>
> I will push this series tonight, in about 8 hours from now.
> Last chance to delay this by reviewing or raising related concerns.
Just FYI - this broke my nightly automated builds - which
cross-compile on Linux for Windows.
x86_64-w64-mi
On Mon, 2022-07-18 at 15:02 +0200, Anton Khirnov wrote:
> Quoting Xiang, Haihao (2022-07-12 08:27:32)
> > +static int qsv_va_update_config(void *ctx, mfxHDL handle, mfxConfig cfg)
> > +{
> > +#if CONFIG_VAAPI
> > +#if VA_CHECK_VERSION(1, 5, 0)
> > +#define LOCAL_VADISPLAYPCIID VADisplayPCIID
> > +#
> It should be possible to implement a LTC decoder that turns a audio track
> into LTC binary data. If that succeeded and the data is valid then teh track
> would very likely have contained LTC.
I was hoping that would be achievable, thank you Michael. For context, this
site has a pretty good e
63 matches
Mail list logo
