Add support for VUYX, YUYV422, Y210, XV30, P012, Y212, XV36.
The added formats work with qsv acceleration and will not have
impact on d3d11va acceleration(-hwaccel d3d11va) since so far
these formats are still not supported by using d3d11va acceleration.
Signed-off-by: Tong Wu
---
libavutil/hwc
Add support for VUYX, YUYV422, Y210, XV30, P012, Y212, XV36.
The added formats work with qsv acceleration and will not have
impact on dxva2 acceleration(-hwaccel dxva2) since so far
these formats are still not supported by using dxva2 acceleration.
Signed-off-by: Tong Wu
---
libavutil/hwcontext_
Make 8-bit, 10-bit, 12-bit YUV 4:2:2 video sources as well as YUV 4:4:4
video sources supported by d3d11va and dxva2 just like what VAAPI does.
Sign-off-by: Tong Wu
---
libavcodec/qsv.c | 4
libavutil/hwcontext_qsv.c | 4
2 files changed, 8 deletions(-)
diff --git a/libavcode
Patch attached.
From c9ec824211cccb745b3a4ab014d6be726c8ef1b9 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Tue, 31 Jan 2023 10:18:17 +0100
Subject: [PATCH] avcodec: add media100_to_mjpegb bitstream filter and use it
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile
In the write_header function of the ASS encoder, extradata is
searched for a substring using the strstr function. strstr expects a
null terminated C string as its first parameter, but extradata is
(notionally) not one of these, meaning that the calls to strstr only
happen to work because (presumabl
Paul B Mahol:
> -static int media100_decode_frame(AVCodecContext *avctx,
> - AVFrame *frame, int *got_frame,
> - AVPacket *avpkt)
> +static int filter(AVBSFContext *ctx, AVPacket *avpkt)
> {
> -Media100Context *ctx = avctx->priv_d
Michael Niedermayer:
> Fixes: OOM
> Fixes:
> 54572/clusterfuzz-testcase-minimized-ffmpeg_dem_LAF_fuzzer-4974038870523904
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/lafdec.c |
Michael Niedermayer:
> Fixes: memleak
>
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/lafdec.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/libavformat/lafdec.c b/libavformat/lafdec.c
> index b78ec3649c..f6d2d5f235 100644
> --- a/libavformat/lafdec.c
> +++ b/l
Paul B Mahol:
> +///< Which substream of substreams carry 16-channel presentation
> +uint8_t extended_substream_info;
> +
> +///< Which substream of substreams carry 2/6/8-channel presentation
> +uint8_t substream_info;
> +
Sure about the '<' in ///https://ffmpeg.org/mailma
On 1/31/23, Andreas Rheinhardt wrote:
> Paul B Mahol:
>> +///< Which substream of substreams carry 16-channel presentation
>> +uint8_t extended_substream_info;
>> +
>> +///< Which substream of substreams carry 2/6/8-channel presentation
>> +uint8_t substream_info;
>> +
>
>
Use it to propagate AVPacket.opaque[_ref] to corresponding AVFrame
fields. This is a more convenient alternative to reordered_opaque.
---
doc/APIchanges| 3 +++
libavcodec/avcodec.h | 9 +
libavcodec/decode.c | 12 ++--
libavcodec/decode.h | 3 ++-
libavcodec/libdav
It is only used in libavcodec, where it's been superseded by
AV_CODEC_CAP_COPY_OPAQUE.
---
libavcodec/avcodec.h| 5 +
libavcodec/codec.h | 6 +++---
libavcodec/decode.c | 4
libavcodec/encode.c | 4
libavcodec/libda
The hardware is old and not relevant today. The decoders also have many
special quirks and are effectively unmaintained.
---
Philip confirmed on IRC that he no longer has the hardware for
maintaining this and does not believe it is relevant today.
---
Changelog | 1 +
MAINTAINERS
> On Jan 18, 2023, at 22:31, Tim Angus wrote:
>
> When writing a subtitle SSA/ASS subtitle file, the
> AVCodecParameters::extradata buffer is written directly to the output,
> potentially including a null terminating character, which is sometimes
> present. The result is the output having a nul
On Wed, 18 Jan 2023, Anton Khirnov wrote:
Quoting Martin Storsjö (2023-01-15 23:47:41)
The construct of using offsetof on a (potentially anonymous) struct
defined within the offsetof expression, while supported by all
current compilers, has been declared explicitly undefined by the
C standards
On Mon, 23 Jan 2023, Derek Buitenhuis wrote:
On 1/17/2023 9:31 AM, Martin Storsjö wrote:
Only warn if the advanced_editlist option is enabled (it is enabled
by default though) so we don't print one warning for each track, and
demote the warning to AV_LOG_LEVEL_VERBOSE; this message does get
gen
This replaces and obsoletes the earlier version of this patch, which had a bug.
Thanks to Marton Balint for spotting it.
This fixes https://trac.ffmpeg.org/ticket/10148, it ensures that each IDR frame
is prefixed with SPS/PPS.
Tested manually, with inputs containing AUDs (x264's aud=1 mode) and
Quoting Paul B Mahol (2023-01-31 11:18:52)
> Patch attached.
>
> From c9ec824211cccb745b3a4ab014d6be726c8ef1b9 Mon Sep 17 00:00:00 2001
> From: Paul B Mahol
> Date: Tue, 31 Jan 2023 10:18:17 +0100
> Subject: [PATCH] avcodec: add media100_to_mjpegb bitstream filter and use it
>
> Signed-off-by: P
input_image is freed by the time the output packet is constructed, so we
need to store copies in VAAPIEncodePicture.
---
Is this better?
---
libavcodec/vaapi_encode.c | 22 +-
libavcodec/vaapi_encode.h | 4
2 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/l
Make mf_close safe to call multiple times; it currently isn't
called more than once, but for clarity, make it safe to call
more than once.
If there are failures in ff_instantiate_mf, that function
calls uninit_com_mf() on its own. Make sure that the second
call to uninit_com_mf from ff_free_mf (fr
On 31/01/2023 12:37, "zhilizhao(赵志立)" wrote:
+/* extradata may or may not be null terminated; in the case where
+ * it is, avoid copying a null into the middle of the buffer */
+while (header_size > 0 && par->extradata[header_size - 1] == '\0')
+header_size--;
On 31/01/2023 11:13, Tim Angus wrote:
In the write_header function of the ASS encoder, extradata is
searched for a substring using the strstr function. strstr expects a
null terminated C string as its first parameter, but extradata is
(notionally) not one of these, meaning that the calls to strst
Quoting Nicolas George (2023-01-30 13:40:06)
> Anton Khirnov (12023-01-30):
> > This hack is used to limit the visibility of some AVFilterLink fields to
> > only certain files. Replace it with the same pattern that is used e.g.
> > in lavf AVStream/FFstream and avoid exposing these internal fields
Anton Khirnov (12023-01-31):
> I find this a significant improvement in code quality, making it easier
> to maintain.
You can say that, you do not maintain it.
> Making it obvious which field is private and which is public is a
> feature, not a bug.
Then I do not want this feature. Making people
On 1/31/23, Nicolas George wrote:
> Anton Khirnov (12023-01-31):
>> I find this a significant improvement in code quality, making it easier
>> to maintain.
>
> You can say that, you do not maintain it.
>
>> Making it obvious which field is private and which is public is a
>> feature, not a bug.
>
Quoting Nicolas George (2023-01-31 15:03:34)
> Anton Khirnov (12023-01-31):
> > I find this a significant improvement in code quality, making it easier
> > to maintain.
>
> You can say that, you do not maintain it.
Do you?
You keep implying in your emails that you are the authority on lavfi,
but
Anton Khirnov (12023-01-31):
> Do you?
>
> You keep implying in your emails that you are the authority on lavfi,
> but I see no objective support for this claim. MAINTAINERS only lists
> you as the maintainer for graphdump.c and two filters.
> And taken e.g. by the number of commits touching libav
Paul B Mahol (12023-01-31):
> No, you do not. Calling your libavfilter framework code "complex" is disgrace
> to really complex code in non-framework part of libavfilter or else in
> FFmpeg libraries.
>
> libavfilter framework needs serious overhaul.
> It have numerous limitations and other stuff
On 1/31/23, Nicolas George wrote:
> Paul B Mahol (12023-01-31):
>> No, you do not. Calling your libavfilter framework code "complex" is
>> disgrace
>> to really complex code in non-framework part of libavfilter or else in
>> FFmpeg libraries.
>>
>> libavfilter framework needs serious overhaul.
>>
sön 2023-01-29 klockan 11:36 -0500 skrev Dave Rice:
>
>
> > On Jan 20, 2023, at 10:17 AM, Tomas Härdin wrote:
> >
> > ons 2023-01-18 klockan 15:15 +0100 skrev Jerome Martinez:
> > > On 18/01/2023 14:40, Tomas Härdin wrote:
> > > > Creating a new subthread because I just noticed something
> > >
On 1/31/23, Paul B Mahol wrote:
> On 1/31/23, Andreas Rheinhardt wrote:
>> Paul B Mahol:
>>> +///< Which substream of substreams carry 16-channel presentation
>>> +uint8_t extended_substream_info;
>>> +
>>> +///< Which substream of substreams carry 2/6/8-channel presentation
>>> +
Anton Khirnov:
> Gcc flag -fsemantic-interposition, which is on by default with current
> gcc versions, makes the compiler assume exported symbols can be
> interposed by the linker, which prevents various kinds of optimization.
>
> Since we do not support such interposition and disable it with
> -
Quoting Nicolas George (2023-01-31 15:31:44)
> Anton Khirnov (12023-01-31):
> > Do you?
> >
> > You keep implying in your emails that you are the authority on lavfi,
> > but I see no objective support for this claim. MAINTAINERS only lists
> > you as the maintainer for graphdump.c and two filters.
Improved patch attached.
From ef7436580ce401917abab5114ff2ff8a1fdd9d61 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Tue, 31 Jan 2023 10:18:17 +0100
Subject: [PATCH] avcodec: add media100_to_mjpegb bitstream filter and use it
Signed-off-by: Paul B Mahol
---
configure
On 1/30/23 11:53, Leo Izen wrote:
On 1/27/23 07:18, Leo Izen wrote:
libjxl only accepts 16-bit buffers with its API, but it can
accept 9-bit to 15-bit input via a 16-bit buffer, provided the flag
is set declaring the buffer to be of the respective significant depth.
Likewise, it can only provid
Passes FATE
/Tomas
From 485b779b06085ca0b51eaf33a56f6ddade05b3c1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Tue, 31 Jan 2023 16:33:21 +0100
Subject: [PATCH] sws/utils.c: Do not uselessly call initFilter() when
unscaling
---
libswscale/utils.c | 62
Anton Khirnov (12023-01-31):
> I still see no objective facts supporting your claim of exclusive
> maintainership over the entirety of lavfi generic code and public API.
The fact is very simple: I am the only one who understand how this code
works.
> So to avoid any further pointless bickering, I
As ACC decoder but with HE and HEv2 disabled.
Signed-off-by: Kristofer Björkström
---
Changelog| 1 +
configure| 1 +
libavcodec/Makefile | 3 +++
libavcodec/aacdec.c | 21 +
libavcodec/aacdec_template.c | 8 ++
Nicolas George (12023-01-31):
> > * it prevents filterlink internals from being visible in a
> > public header, where they have no business being
> > * it is a step towards hiding more of lavfi internals from public
> > headers
> > * the same pattern is already and ever more widely used in the
On Tue, 31 Jan 2023, at 13:17, Anton Khirnov wrote:
> The hardware is old and not relevant today. The decoders also have many
> special quirks and are effectively unmaintained.
Yes. LGTM.
--
Jean-Baptiste Kempf - President
+33 672 704 734
___
ffmpeg-de
On 1/29/23, Paul B Mahol wrote:
> Patches attached
>
will apply soon
___
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
Jan 31, 2023, 17:34 by kristofer.bjorkst...@axis.com:
> As ACC decoder but with HE and HEv2 disabled.
>
> Signed-off-by: Kristofer Björkström
> ---
> Changelog| 1 +
> configure| 1 +
> libavcodec/Makefile | 3 +++
> libavcodec/aacdec.c
Quoting Paul B Mahol (2023-01-31 18:11:10)
> On 1/29/23, Paul B Mahol wrote:
> > Patches attached
> >
>
> will apply soon
needs FATE tests
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmp
Kristofer Björkström:
> As ACC decoder but with HE and HEv2 disabled.
>
> Signed-off-by: Kristofer Björkström
> ---
> Changelog| 1 +
> configure| 1 +
> libavcodec/Makefile | 3 +++
> libavcodec/aacdec.c | 21 +
>
On Tue, Jan 31, 2023 at 12:21:24PM +0100, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Fixes: OOM
> > Fixes:
> > 54572/clusterfuzz-testcase-minimized-ffmpeg_dem_LAF_fuzzer-4974038870523904
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/pro
Michael Niedermayer:
> On Tue, Jan 31, 2023 at 12:21:24PM +0100, Andreas Rheinhardt wrote:
>> Michael Niedermayer:
>>> Fixes: OOM
>>> Fixes:
>>> 54572/clusterfuzz-testcase-minimized-ffmpeg_dem_LAF_fuzzer-4974038870523904
>>>
>>> Found-by: continuous fuzzing process
>>> https://github.com/google/o
On Tue, Jan 31, 2023 at 12:25:25PM +0100, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Fixes: memleak
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavformat/lafdec.c | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/libavformat/lafdec.c b/libavformat
Nicolas George:
> Nicolas George (12023-01-31):
>>> * it prevents filterlink internals from being visible in a
>>> public header, where they have no business being
>>> * it is a step towards hiding more of lavfi internals from public
>>> headers
>>> * the same pattern is already and ever more w
Andreas Rheinhardt (12023-01-31):
> Details please.
I was not going to spend time explaining unless I had assurance it was
because the issue of requiring changes in the internal implementation
and developers habits just to hide some fields was taken into account.
Coming from somebody else, I would
FFmpeg doesn't support tv-range RGB pixel data, so if we see a cICP
chunk that marks its RGB data as tv-range, we should print a warning
instead of setting it to AVCOL_RANGE_MPEG and having things possibly
mess up later down the line.
Signed-off-by: Leo Izen
---
libavcodec/pngdec.c | 6 --
1
Nicolas George:
> Andreas Rheinhardt (12023-01-31):
>> Details please.
>
> I was not going to spend time explaining unless I had assurance it was
> because the issue of requiring changes in the internal implementation
> and developers habits just to hide some fields was taken into account.
> Comin
>From x86inc:
> On AMD cpus <=K10, an ordinary ret is slow if it immediately follows either
> a branch or a branch target. So switch to a 2-byte form of ret in that case.
> We can automatically detect "follows a branch", but not a branch target.
> (SSSE3 is a sufficient condition to know that your
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".
On Di, 2023-01-31 at 14:14 +0100, Anton Khirnov wrote:
> input_image is freed by the time the output packet is constructed, so we
> need to store copies in VAAPIEncodePicture.
> ---
> Is this better?
> ---
> libavcodec/vaapi_encode.c | 22 +-
> libavcodec/vaapi_encode.h | 4 ++
Feb 1, 2023, 03:00 by hen...@gramner.com:
> lgtm
>
Thanks, pushed.
___
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 su
Add support to the PNG decoder and encoder to support sBIT chunks.
Leo Izen (2):
avcodec/pngdec: support sBIT chunks
avcodec/pngenc: write sBIT chunks
libavcodec/pngdec.c | 57 +
libavcodec/pngenc.c | 7 ++
2 files changed, 64 insertions(+)
-
Add support for reading sBIT chunks, which mark the significant
bit depth of the PNG file. This passes the metadata using the field
bits_per_raw_sample of AVCodecContext.
Signed-off-by: Leo Izen
---
libavcodec/pngdec.c | 57 +
1 file changed, 57 insert
Add support for writing sBIT chunks, which mark the significant
bit depth of the PNG file. This obtains the metadata using the field
bits_per_raw_sample of AVCodecContext.
Signed-off-by: Leo Izen
---
libavcodec/pngenc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavcodec/pngenc
Quoting Nicolas George (2023-01-30 13:59:44)
> > +static unsigned
> > +find_linklabel(AVFilterGraphSegment *seg, const char *label,
> > + int output, size_t idx_chain, size_t idx_filter,
> > + AVFilterParams **pp)
> > +{
> > +for (; idx_chain < seg->nb_chains; idx_ch
Andreas Rheinhardt (12023-02-01):
> PS: Upon rethinking, it is not only b) that contains undefined
> behaviour; it is b)-d) as well as the current code. The reason is that
> the type of AVFilterLink as seen in the files with FF_INTERNAL_FIELDS is
> not compatible with the type of AVFilterLink from
60 matches
Mail list logo