lgtm. Will apply in a few days.
___
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".
On Fri, Mar 11, 2022 at 05:16:09PM +0100, Andreas Rheinhardt wrote:
> lance.lmw...@gmail.com:
> > On Fri, Mar 11, 2022 at 03:04:32PM +0100, Andreas Rheinhardt wrote:
> >> lance.lmw...@gmail.com:
> >>> On Wed, Mar 02, 2022 at 09:58:31PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
18035 -> 4018 dezicycles (Tested with LOGOS.DFA, gcc 7, 3950X)
Signed-off-by: Michael Niedermayer
---
libavcodec/dfa.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/libavcodec/dfa.c b/libavcodec/dfa.c
index 0cf3641a38..ab78d66763 100644
--- a/libavcodec/dfa.
Fixes: Timeout
Fixes:
45170/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MJPEGB_fuzzer-5874820431085568
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/mjpegbdec.c | 1 +
1 file changed,
Fixes: Timeout
Fixes:
45351/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DFA_fuzzer-5768895011618816
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 changed,
From: Pierre-Anthony Lemieux
---
libavformat/imfdec.c | 20 ++--
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c
index ac212b05e1..a19e431df3 100644
--- a/libavformat/imfdec.c
+++ b/libavformat/imfdec.c
@@ -904,14 +904,6
From: Pierre-Anthony Lemieux
---
libavformat/concatdec.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index 0603c6e254..cfe1329105 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@ -8
From: Pierre-Anthony Lemieux
---
libavformat/Makefile | 1 +
libavformat/tests/.gitignore | 1 +
libavformat/tests/seek_utils.c | 57 ++
tests/fate/libavformat.mak | 5 +++
4 files changed, 64 insertions(+)
create mode 100644 libavformat/tests/
From: Pierre-Anthony Lemieux
Refactors a function used by avformat/concat and avformat/imf.
---
libavformat/internal.h | 20
libavformat/seek.c | 10 ++
2 files changed, 30 insertions(+)
diff --git a/libavformat/internal.h b/libavformat/internal.h
index f24c687
From: Pierre-Anthony Lemieux
---
libavformat/imfdec.c | 93 ++--
1 file changed, 29 insertions(+), 64 deletions(-)
diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c
index f208b262c3..ac212b05e1 100644
--- a/libavformat/imfdec.c
+++ b/libavformat/im
From: Pierre-Anthony Lemieux
The IMF demuxer did not implement AVInputFormat::read_seek2(), resulting in
inefficient input seeking.
Addresses https://trac.ffmpeg.org/ticket/9648
Byte- and frame-seeking are not supported.
---
libavformat/imfdec.c | 129 ++---
From: Pierre-Anthony Lemieux
---
libavformat/imfdec.c | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c
index 3ce850b75a..b98af020d2 100644
--- a/libavformat/imfdec.c
+++ b/libavformat/imfdec.c
Awesome, thanks!
On Thu, Mar 10, 2022 at 9:45 PM Paul B Mahol wrote:
>
>
> On Thu, Mar 10, 2022 at 7:41 PM Victoria Zhislina
> wrote:
>
>> Paul and all, do you have any chances to view my patch from Feb,19? I
>> assume I'\ve fixed all you've kindly pointed out and even more. Please
>> correct m
lance.lmw...@gmail.com:
> On Fri, Mar 11, 2022 at 03:04:32PM +0100, Andreas Rheinhardt wrote:
>> lance.lmw...@gmail.com:
>>> On Wed, Mar 02, 2022 at 09:58:31PM +0800, lance.lmw...@gmail.com wrote:
From: Limin Wang
Fix below error message when timecode packet is written.
"Applic
Currently priming the zlib decompressor involves compressing
data directly after having decompressed it and decompressing
it again in order to set the "dictionary" and to initialize
the adler32-checksum. Yet this is wasteful and can be simplified
by synthetizing the compressed data via non-compress
On Fri, Mar 11, 2022 at 03:04:32PM +0100, Andreas Rheinhardt wrote:
> lance.lmw...@gmail.com:
> > On Wed, Mar 02, 2022 at 09:58:31PM +0800, lance.lmw...@gmail.com wrote:
> >> From: Limin Wang
> >>
> >> Fix below error message when timecode packet is written.
> >> "Application provided duration: -9
Signed-off-by: Andreas Rheinhardt
---
libavcodec/flashsv.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/libavcodec/flashsv.c b/libavcodec/flashsv.c
index 00f77f4902..5f0bc0c6df 100644
--- a/libavcodec/flashsv.c
+++ b/libavcodec/flashsv.c
@@ -44,7 +44,7 @@
#
All 5/5 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".
The muxer seems to have had one seemingly accidental use of
LIBAVCODEC_IDENT, while LIBAVFORMAT_IDENT probably is the
relevant one (which is used multiple times in the same file).
Signed-off-by: Martin Storsjö
---
libavformat/movenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -
lance.lmw...@gmail.com:
> On Wed, Mar 02, 2022 at 09:58:31PM +0800, lance.lmw...@gmail.com wrote:
>> From: Limin Wang
>>
>> Fix below error message when timecode packet is written.
>> "Application provided duration: -9223372036854775808 / timestamp:
>> -9223372036854775808 is out of range for mov
On Fri, Mar 11, 2022 at 2:43 PM Xiang, Haihao
wrote:
>
> On Fri, 2022-03-11 at 09:35 +0100, Hendrik Leppkes wrote:
> > On Fri, Mar 11, 2022 at 9:18 AM Xiang, Haihao
> > wrote:
> > > diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
> > > index 8ab96bad25..e0e820f164 10064
On Wed, Mar 02, 2022 at 09:58:31PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Fix below error message when timecode packet is written.
> "Application provided duration: -9223372036854775808 / timestamp:
> -9223372036854775808 is out of range for mov/mp4 format"
>
> try to repro
This avoids unnecessary rebuilds of most source files if only the
list of enabled components has changed, but not the other properties
of the build, set in config.h.
---
Patchwork notified me that the previous round failed building
libavdevice/alsa.c due to missing an include of the new header.
I
On Wed, Mar 9, 2022 at 10:36 AM Michael Niedermayer
wrote:
> On Wed, Mar 09, 2022 at 01:30:30AM +0100, Mark Gaiser wrote:
> > On Wed, Mar 9, 2022 at 12:45 AM Michael Niedermayer <
> mich...@niedermayer.cc>
> > wrote:
> >
> > > On Tue, Mar 08, 2022 at 01:49:22PM +0100, Mark Gaiser wrote:
> > > > O
On Fri, 2022-03-11 at 09:35 +0100, Hendrik Leppkes wrote:
> On Fri, Mar 11, 2022 at 9:18 AM Xiang, Haihao
> wrote:
> > diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
> > index 8ab96bad25..e0e820f164 100644
> > --- a/libavutil/hwcontext_d3d11va.c
> > +++ b/libavutil/hwco
On Fri, 11 Mar 2022 12:18:13 +0100 Andreas Rheinhardt
wrote:
> 1. This is not how should work with an AVBPrint -- you are throwing the
> small-string optimization away here.
Noted, though consider: many ICC profiles used in practice are small
enough to fit inside the 1000 byte buffer. Especially
On Fri, 11 Mar 2022 12:05:13 +0100 Andreas Rheinhardt
wrote:
> Niklas Haas:
> > On Fri, 11 Mar 2022 11:17:42 +0100 Niklas Haas wrote:
> >> Oops. `-c copy` doesn't actually test the PNG writing code. Need to use
> >> `-c png` instead. Fixed in v2.
> >
> > Hmm, actually, even this doesn't work. I
Commit e050959103f375e6494937fa28ef2c4d2d15c9ef implemented passing in
modifiers by using the PRIME_2 memory type, which only exists in v2 of
the library.
To still support v1 of the library, conditionally compile using
VA_CHECK_VERSION() for both the new code and the old code before
the commit.
--
This avoids unnecessary rebuilds of most source files if only the
list of enabled components has changed, but not the other properties
of the build, set in config.h.
---
configure | 17 +++--
fftools/ffplay.c | 1 +
libavcodec/8svx.c
---
doc/APIchanges | 6 ++
1 file changed, 6 insertions(+)
diff --git a/doc/APIchanges b/doc/APIchanges
index ccc4f24b28..365a9747c9 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -14,6 +14,12 @@ libavutil: 2021-04-27
API changes, most recent first:
+2022-*-* - xx - all
---
fftools/cmdutils.c | 1 +
fftools/ffprobe.c | 1 +
libavfilter/Makefile| 1 +
libavfilter/avfilter.c | 1 +
libavfilter/avfilter.h | 2 +-
libavfilter/version.h | 13 ++--
libavfilter/version_major.h | 42 +
---
fftools/cmdutils.c | 1 +
fftools/ffprobe.c | 1 +
libswscale/Makefile| 1 +
libswscale/swscale.h | 2 +-
libswscale/utils.c | 1 +
libswscale/version.h | 9 ++---
libswscale/version_major.h | 35 +++
7 file
---
fftools/cmdutils.c| 1 +
fftools/ffprobe.c | 1 +
libswresample/Makefile| 1 +
libswresample/swresample.c| 1 +
libswresample/swresample.h| 2 +-
libswresample/version.h | 3 ++-
libswresample/version_major.h | 31
---
fftools/cmdutils.c | 1 +
fftools/ffprobe.c | 1 +
libpostproc/Makefile| 1 +
libpostproc/postprocess.c | 1 +
libpostproc/postprocess.h | 2 +-
libpostproc/version.h | 3 ++-
libpostproc/version_major.h | 31 +++
7 files c
---
fftools/cmdutils.c | 1 +
fftools/ffprobe.c | 1 +
libavdevice/Makefile| 1 +
libavdevice/avdevice.c | 1 +
libavdevice/avdevice.h | 2 +-
libavdevice/version.h | 10 ++
libavdevice/version_major.h | 37 +++
---
fftools/cmdutils.c| 1 +
fftools/ffprobe.c | 1 +
libavdevice/pulse_audio_dec.c | 1 +
libavdevice/pulse_audio_enc.c | 1 +
libavformat/Makefile | 1 +
libavformat/avformat.h| 2 +-
libavformat/avio.h| 2 +-
libavformat/flacenc.c
This avoids including version.h in all source files, avoiding
unnecessary rebuilds when the version number is bumped. Only
version_major.h is included by the main header, which defines
availability of e.g. FF_API_* macros, and which is bumped much
less often.
---
fftools/cmdutils.c |
On Wed, 23 Feb 2022, Martin Storsjö wrote:
When updating the ffmpeg source, one quite often ends up in a situation
where practically all of the codebase (or all of a library) gets rebuilt,
due to updates to headers that are included in most files.
In some cases, full rebuilds are warranted of c
Niklas Haas:
> From: Niklas Haas
>
> encode_zbuf is mostly a mirror image of decode_zbuf. Other than that,
> the code is pretty straightforward. Special care needs to be taken to
> avoid writing more than 79 characters of the profile description (the
> maximum supported).
>
> Also add a FATE tra
Niklas Haas:
> On Fri, 11 Mar 2022 11:17:42 +0100 Niklas Haas wrote:
>> Oops. `-c copy` doesn't actually test the PNG writing code. Need to use
>> `-c png` instead. Fixed in v2.
>
> Hmm, actually, even this doesn't work. I can comment out the iCCP
> writing code and the iCCP chunk still gets writ
On Fri, 11 Mar 2022 11:17:42 +0100 Niklas Haas wrote:
> Oops. `-c copy` doesn't actually test the PNG writing code. Need to use
> `-c png` instead. Fixed in v2.
Hmm, actually, even this doesn't work. I can comment out the iCCP
writing code and the iCCP chunk still gets written, somehow. Even thou
From: Niklas Haas
encode_zbuf is mostly a mirror image of decode_zbuf. Other than that,
the code is pretty straightforward. Special care needs to be taken to
avoid writing more than 79 characters of the profile description (the
maximum supported).
Also add a FATE transcode test to ensure that th
From: Niklas Haas
encode_zbuf is mostly a mirror image of decode_zbuf. Other than that,
the code is pretty straightforward. Special care needs to be taken to
avoid writing more than 79 characters of the profile description (the
maximum supported).
Also add a FATE transcode test to ensure that th
From: Mark Thompson
The block size can be dependent on the profile and entrypoint selected.
It defaults to 16x16, with codecs able to override this choice with their
own function.
Signed-off-by: Fei Wang
---
libavcodec/vaapi_encode.c | 16
libavcodec/vaapi_encode.h
From: Linjie Fu
Use GPB frames to replace regular P/B frames if backend driver does not
support it.
- GPB:
Generalized P and B picture. Regular P/B frames replaced by B
frames with previous-predict only, L0 == L1. Normal B frames
still have 2 different ref_lists and allow bi-predicti
From: Mark Thompson
max_14bit_constraint_flag should be set if the bit depth is not greater than
14 (currently always true).
one_picture_only_flag should not be set because we don't support the still
picture profiles.
general_profile_compatibility_flag should be set according to
general_profil
From: Mark Thompson
Signed-off-by: Fei Wang
---
libavcodec/vaapi_encode_h265.c | 114 +++--
1 file changed, 108 insertions(+), 6 deletions(-)
diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index e486e64eb9..11eca5989b 100644
--- a/libav
On Fri, Mar 11, 2022 at 9:18 AM Xiang, Haihao
wrote:
> diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
> index 8ab96bad25..e0e820f164 100644
> --- a/libavutil/hwcontext_d3d11va.c
> +++ b/libavutil/hwcontext_d3d11va.c
> @@ -525,6 +525,13 @@ static void d3d11va_device_unin
On Wed, 2021-10-20 at 06:53 +, Soft Works wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Jean-Baptiste Kempf
> > Sent: Wednesday, October 20, 2021 8:01 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH v6 00/10] make QSV works with the
> >
From: Haihao Xiang
This allows user to build FFmpeg against Intel oneVPL. oneVPL 2.6
is the required minimum version when building Intel oneVPL code.
It will fail to run configure script if both libmfx and libvpl are
enabled.
It is recommended to use oneVPL for new work, even for currently avai
From: Haihao Xiang
In oneVPL, MFXLoad() and MFXCreateSession() are required to create a
workable mfx session[1]
Add AccelerationMode config filter for D3D9/D3D11 session (galinart)
The default device is changed to d3d11va for oneVPL when both d3d11va
and dxva2 are enabled on Microsoft Windows
From: Haihao Xiang
OPAQUE memory isn't supported for MFX_VERSION >= 2.0[1][2]. This is in
preparation for oneVPL support
[1]:
https://spec.oneapi.io/versions/latest/elements/oneVPL/source/VPL_intel_media_sdk.html#msdk-full-name-feature-removals
[2]: https://github.com/oneapi-src/oneVPL
---
lib
From: Haihao Xiang
Multi-frame encode isn't supported for MFX_VERSION >= 2.0[1][2]. This is
in preparation for oneVPL support
[1]:
https://spec.oneapi.io/versions/latest/elements/oneVPL/source/VPL_intel_media_sdk.html#msdk-full-name-feature-removals
[2]: https://github.com/oneapi-src/oneVPL
---
From: Haihao Xiang
Audio isn't supported for MFX_VERSION >= 2.0[1][2]. This is in
preparation for oneVPL support
[1]:
https://spec.oneapi.io/versions/latest/elements/oneVPL/source/VPL_intel_media_sdk.html#msdk-full-name-feature-removals
[2]: https://github.com/oneapi-src/oneVPL
---
libavcodec/
From: Haihao Xiang
MFX_RATECONTROL_LA_EXT isn't supported for MFX_VERSION >= 2.0[1][2].
This is in preparation for oneVPL support
[1]:
https://spec.oneapi.io/versions/latest/elements/oneVPL/source/VPL_intel_media_sdk.html#msdk-full-name-feature-removals
[2]: https://github.com/oneapi-src/oneVPL
From: Haihao Xiang
User plugin isn't supported for MFX_VERSION >= 2.0[1][2]. This is in
preparation for oneVPL Support
[1]:
https://spec.oneapi.io/versions/latest/elements/oneVPL/source/VPL_intel_media_sdk.html#msdk-full-name-feature-removals
[2]: https://github.com/oneapi-src/oneVPL
---
libav
From: Haihao Xiang
The following Cflags has been added to libmfx.pc, so mfx/ prefix is no
longer needed when including mfx headers in FFmpeg.
Cflags: -I${includedir} -I${includedir}/mfx
Some old versions of libmfx have the following Cflags in libmfx.pc
Cflags: -I${includedir}
We may add -
From: Haihao Xiang
The data structures for VP9 in mfxvp9.h is wrapped by
MFX_VERSION_NEXT, which means those data structures have never been used
in a public release. Actually MFX_CODEC_VP9 and other VP9 stuffs is
added in mfxstructures.h. In addition, mfxdefs.h is included in
mfxvp9.h, so we may
From: Haihao Xiang
Intel's oneVPL is a successor to MediaSDK, but removed some obsolete
features of MediaSDK[1]. Some early versions of oneVPL still uses libmfx
as library name[2], however some of obsolete features, including OPAQUE
memory, multi-frame encode, user plugins and LA_EXT rate control
From: Haihao Xiang
The oneAPI Video Processing Library (oneVPL) is a single interface for
encode, decode and video processing[1][2]. oneVPL is a successor to Intel(R)
Media
SDK, but removed obsolete features. Intel(R) Media SDK lifetime comes to an
end now, new features for new Intel Gen platfor
From: Wu Jianhua
This commit includes addition, average, subtract, negation, extremity,
difference, darken, lighten, exclusion and phoenix blend modes.
Use the commands below to test: (href: https://trac.ffmpeg.org/wiki/Blend)
I. make an image for test
ffmpeg -f lavfi -i color=s=256x256,geq=r='
61 matches
Mail list logo
