v2 set LGTM. I verified with ATSC and DVD sources. Thank you.
On Thu, Feb 8, 2024 at 9:08 AM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> It does not use the AVFormatContext at all.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/rcwtenc.c | 8 +++-
> 1 file
DVD subtitle palettes, which are natively YUV, are
currently carried as a hex string in their respective subtitle streams and
have no concept of colorspace tagging. In fact, the convention is to convert
them to RGB prior to storage. Common players will only render the palettes
properly if they are
Please ignore v9, I screwed up the email subject (contents are the same). Sorry
folks.
Addresses all prior feedback to my knowledge. Hopefully this has a chance for
7.0,
as I am starting to believe there are not great alternatives to this demuxer
out there.
Thank you to all the reviewers for
Please ignore, see v10.
On Fri, Feb 9, 2024 at 1:17 AM Marth64 wrote:
> Thank you to all the reviewers for your time.
>
> [Remaining Questions]
>
> Andreas R:
> > This makes this code add an AVStream to the child AVFormatContext. This
> > is not how it is supposed to be. You may not add
Thank you to all the reviewers for your time.
[Remaining Questions]
Andreas R:
> This makes this code add an AVStream to the child AVFormatContext. This
> is not how it is supposed to be. You may not add AVStreams behind an
> input AVFormatContext's back.
The intent here is that I need to tell
The point of this patch is to provide a consolidation of the code
that deals with creating the extradata as well as the RGB conversion.
That can then (1) enable usable palette support for DVD demuxer if it is merged
and (2) start the process of consolidating the related conversions in
MOV
On Fri, Feb 9, 2024 at 2:16 AM Kieran Kunhya wrote:
> On Thu, 8 Feb 2024 at 06:01, Nuo Mi wrote:
>
> > On Thu, Feb 8, 2024 at 6:55 AM Kieran Kunhya wrote:
> >
> > > On Wed, 7 Feb 2024 at 22:06, Paul B Mahol wrote:
> > >
> > > > On Wed, Feb 7, 2024 at 10:13 PM Kieran Kunhya
> wrote:
> > > >
>
On Wed, Feb 07, 2024 at 02:54:23PM +, Derek Buitenhuis wrote:
> Hi,
>
> On 1/23/2024 7:22 PM, Michael Niedermayer wrote:
> > What is blocking? (IMHO)
> > * regressions (unless its non possible to fix before release)
> > * crashes
> > * security issues
> > * data loss
> > * privacy issues
> >
On 08/02/2024 21:50, Lynne wrote:
> Feb 8, 2024, 22:16 by p...@frankplowman.com:
>
>> From: Frank Plowman
>>
>> Depending on where exactly decode_nal_unit failed, it is possible that
>> fc->ref holds a VVCFrame which has had ff_vvc_unref_frame called on it
>> and not yet had ref_frame called
From my understanding, to use larger group multipliers, one needs to
utilize vlse64 (8x8) vlse128 (16x16).
However, due to the use in tests of
ptr = img2 + y * WIDTH + x;
d2 = call_ref(NULL, img1, ptr, WIDTH, h);
d1 = call_new(NULL, img1, ptr, WIDTH, h);
will get: pix_abs_1_0_rvv_i32 (fatal
Hi.
On Thu, Feb 8, 2024 at 7:13 AM James Zern wrote:
>
> Hi,
>
> On Wed, Feb 7, 2024 at 8:04 AM Dariusz Marcinkiewicz via ffmpeg-devel
> wrote:
> >
> > This exposes VP8E_SET_SCREEN_CONTENT_MODE option from libvpx.
> >
>
> For the subject use '(libavcodec|avcodec|lavc)/libvpxenc: ...' to
>
This exposes VP8E_SET_SCREEN_CONTENT_MODE option from libvpx and makes
us retry encode if screen_content_mode == 2 and no output was produced
by encoder.
Co-authored-by: Erik Språng
Signed-off-by: Dariusz Marcinkiewicz
---
doc/encoders.texi | 3 +++
libavcodec/libvpxenc.c | 57
Feb 8, 2024, 22:16 by p...@frankplowman.com:
> From: Frank Plowman
>
> Depending on where exactly decode_nal_unit failed, it is possible that
> fc->ref holds a VVCFrame which has had ff_vvc_unref_frame called on it
> and not yet had ref_frame called on it. In this case, fc->ref most of
> the
From: Frank Plowman
Depending on where exactly decode_nal_unit failed, it is possible that
fc->ref holds a VVCFrame which has had ff_vvc_unref_frame called on it
and not yet had ref_frame called on it. In this case, fc->ref most of
the fields of fc->ref are NULL and attempting to call
On Thu, 08 Feb 2024 13:33:51 +0100 Andreas Rheinhardt
wrote:
> Sorry for not answering earlier.
> My intention is to allow users who only want to deal with the common
> case of a cartesian product to continue to do so, but to also support
> other usecases.
> The public function would look like
>
v3: also try simplifying custom layout to unspecified layout
Signed-off-by: Marton Balint
---
libavformat/mov_chan.c | 101 +++--
1 file changed, 56 insertions(+), 45 deletions(-)
diff --git a/libavformat/mov_chan.c b/libavformat/mov_chan.c
index
Feb 8, 2024, 20:05 by jamr...@gmail.com:
> On 2/8/2024 3:52 PM, Sean McGovern wrote:
>
>> Hi developers,
>>
>> On Wed, Feb 7, 2024, 23:30 Jean-Baptiste Kempf wrote:
>>
>>> Hello,
>>>
>>> On Thu, 8 Feb 2024, at 01:36, Cosmin Stejerean via ffmpeg-devel wrote:
>>>
> There were simply no
Feb 8, 2024, 20:07 by connorbwor...@gmail.com:
> DXV files seem to misnomer DXT5 and really encode DXT4 with
> premultiplied alpha. At least, this is what Resolume alley does.
>
> To check, encode some input with alpha as "Normal Quality, With Alpha"
> in Alley, then decode the output with this
Le keskiviikkona 7. helmikuuta 2024, 2.01.23 EET flow gg a écrit :
> I think in most cases it is like this, but specifically for this function,
> using Reduction only once would be slower.
>
> The currently submitted version roughly takes:
> pix_abs_0_0_rvv_i32: 136.2
>
> The version that uses
On Tue, 30 Jan 2024, Marton Balint wrote:
Existing code could have caused wrong channel order signalling or reduced
channel count if a channel designation appeared multiple times. This is
actually an old bug, but the conversion to the new channel layout API made it
visible, because now the
DXV files seem to misnomer DXT5 and really encode DXT4 with
premultiplied alpha. At least, this is what Resolume alley does.
To check, encode some input with alpha as "Normal Quality, With Alpha"
in Alley, then decode the output with this change -- results are true
to the original input compared
This function should convert premultiplied alpha to straight, but does the
opposite.
Signed-off-by: Connor Worley
---
libavcodec/texturedsp.c | 9 ++---
tests/ref/fate/dds-dxt2 | 2 +-
tests/ref/fate/dds-dxt4 | 2 +-
3 files changed, 8 insertions(+), 5 deletions(-)
diff --git
On 2/8/2024 3:52 PM, Sean McGovern wrote:
Hi developers,
On Wed, Feb 7, 2024, 23:30 Jean-Baptiste Kempf wrote:
Hello,
On Thu, 8 Feb 2024, at 01:36, Cosmin Stejerean via ffmpeg-devel wrote:
There were simply no objections to moving to C11.
The C17 plan came about later because it has
Hi developers,
On Wed, Feb 7, 2024, 23:30 Jean-Baptiste Kempf wrote:
> Hello,
>
> On Thu, 8 Feb 2024, at 01:36, Cosmin Stejerean via ffmpeg-devel wrote:
> >> There were simply no objections to moving to C11.
> >> The C17 plan came about later because it has important bugfixes.
> >> It doesn't
On Thu, 8 Feb 2024 at 06:01, Nuo Mi wrote:
> On Thu, Feb 8, 2024 at 6:55 AM Kieran Kunhya wrote:
>
> > On Wed, 7 Feb 2024 at 22:06, Paul B Mahol wrote:
> >
> > > On Wed, Feb 7, 2024 at 10:13 PM Kieran Kunhya wrote:
> > >
> > > > $subj
> > > >
> > > > As discussed at FOSDEM.
> > > >
> > >
> >
Nicolas,
since you disregarded our previous warnings and keep sending offensive
and inflammatory messages to our mailing list, the CC has decided to
suspect your mailing list posting privileges for three days.
We sincerely hope you will reflect on your behaviour and stop pushing
these spurious
On Thu, Feb 8, 2024 at 5:37 AM Derek Buitenhuis
wrote:
>
> Hello,
>
> On 2/8/2024 6:02 AM, Pierre-Anthony Lemieux wrote:
> > The suggested approach is that interested individuals email me, no
> > later than Feb 10 at 23:59 UTC, a completed SOW using the template at
> > [2].
>
> I feel obliged to
Paul,
since you disregarded our previous warnings and keep sending messages
violating our code of conduct to our mailing list and IRC channel, the
CC has decided to suspend your posting privileges in both for one week.
We sincerely hope you will reflect on your behaviour and contribute to
FFmpeg
Nuo Mi:
> Fixes: fuzzer timeout
> Fixes:
> 65253/clusterfuzz-testcase-minimized-ffmpeg_BSF_VVC_MP4TOANNEXB_fuzzer-4972412487467008
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
>
Fixes: fuzzer timeout
Fixes:
65253/clusterfuzz-testcase-minimized-ffmpeg_BSF_VVC_MP4TOANNEXB_fuzzer-4972412487467008
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/bsf/vvc_mp4toannexb.c | 12
The rcwt muxer uses several counters for how much data
it has already cached: One byte counter and one counter
for how many complete blocks (of three bytes each).
These counters can become inconsistent when the muxer is
fed incomplete blocks as the muxer presumes that it is
about to write a new
It does not use the AVFormatContext at all.
Signed-off-by: Andreas Rheinhardt
---
libavformat/rcwtenc.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/libavformat/rcwtenc.c b/libavformat/rcwtenc.c
index 084de6e205..7d57fcaf1e 100644
--- a/libavformat/rcwtenc.c
+++
Resetting the counter of used elements is enough as nothing is
ever read from the currently unused elements.
Signed-off-by: Andreas Rheinhardt
---
libavformat/rcwtenc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavformat/rcwtenc.c b/libavformat/rcwtenc.c
index d0e469ce65..084de6e205
The rcwt muxer uses several counters for how much data
it has already cached: One byte counter and one counter
for how many complete blocks (of three bytes each).
These counters can become inconsistent when the muxer is
fed incomplete blocks as the muxer presumes that it is
about to write a new
Hello,
On 2/8/2024 6:02 AM, Pierre-Anthony Lemieux wrote:
> The suggested approach is that interested individuals email me, no
> later than Feb 10 at 23:59 UTC, a completed SOW using the template at
> [2].
I feel obliged to point out that the GA vote Michael called n this ends
on 11 Feb,after
Issue found through Coverity CID1457948
Signed-off-by: Michael Niedermayer
---
libavfilter/v360.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/libavfilter/v360.h b/libavfilter/v360.h
index 5d797ab828b..a984d470acc 100644
--- a/libavfilter/v360.h
+++
It seems we do not have a named identifier for the maximum planes of pixel
formats
Signed-off-by: Michael Niedermayer
---
libavutil/pixfmt.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index 9c87571f49e..67422f02d02 100644
---
On 8 Feb 2024, at 13:32, Nicolas George wrote:
> Leo Izen (12024-02-07):
>> I don't think this is really a fair statement to make. We have lots of
>> potential reviewers subscribed to this list but very few people actually
>> review code, and those that do review code are expected to provide
Leo Izen (12024-02-07):
> I don't think this is really a fair statement to make. We have lots of
> potential reviewers subscribed to this list but very few people actually
> review code, and those that do review code are expected to provide some sort
> of technical objection or reason why it
On Mon, 05 Feb 2024 19:37:48 +0100 Niklas Haas wrote:
> On Mon, 05 Feb 2024 19:04:30 +0100 Andreas Rheinhardt
> wrote:
> > This presumes the relevant states to be a cartesian product. Which need
> > not be true. A callback would be better; this would also allow to base
> > the list on other
Ping.
Will merge at the end of the week if no objections.
___
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
Rémi Denis-Courmont:
>
>
> Le 7 février 2024 23:19:41 GMT+02:00, James Almer a écrit
> :
>> On 2/7/2024 6:10 PM, Cosmin Stejerean via ffmpeg-devel wrote:
>>>
>>>
On Feb 7, 2024, at 11:27 AM, Lynne wrote:
>>
>> As a compromise, we could start requiring C11 now, and C17 in
42 matches
Mail list logo
