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
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;
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
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
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(+)
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
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
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".
>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
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.
>
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 --
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
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
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
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
>>>
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
> >
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 +
>
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
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
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
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
___
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
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
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,
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
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
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
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
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
>
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
>>>
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, 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.
>>
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
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
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,
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.
>
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
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
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
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--;
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
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
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:
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)
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
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 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
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
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
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 ++-
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;
>> +
>
>
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
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
> +++
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
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 =
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
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
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
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
---
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
---
60 matches
Mail list logo
