On Tue, Sep 12, 2023, at 15:11, Andreas Rheinhardt wrote:
> Thomas Guillem via ffmpeg-devel:
>> Same than the previous commit but with FF_DECODE_ERROR_DECODE_SLICES
>>
>> Fix the following data-race:
>>
>> WARNING: ThreadSanitizer: data race (pid=55935)
>> Write of size 4 at 0x7b509378 b
On 9/12/2023 9:22 PM, Andreas Rheinhardt wrote:
Andreas Rheinhardt:
It indicates to the reader that said function does not modify
any state.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/av1dec.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/
Andreas Rheinhardt:
> It indicates to the reader that said function does not modify
> any state.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/av1dec.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
> in
On Wed, Sep 13, 2023 at 12:32:28AM +0200, Marvin Scholz wrote:
>
>
> On 13 Sep 2023, at 0:13, Michael Niedermayer wrote:
>
> > Hi all
> >
> > our trac backups died 6 months ago
> > i just noticed as i checked the backups before deleting spam with trac-admin
> > backups are working again
> >
> >
On 13 Sep 2023, at 0:13, Michael Niedermayer wrote:
> Hi all
>
> our trac backups died 6 months ago
> i just noticed as i checked the backups before deleting spam with trac-admin
> backups are working again
>
> failure reason where expired gpg keys
>
> thx
>
> PS: yeah, iam slightly unhappy noo
Hi all
our trac backups died 6 months ago
i just noticed as i checked the backups before deleting spam with trac-admin
backups are working again
failure reason where expired gpg keys
thx
PS: yeah, iam slightly unhappy noone noticed this for 6 months
--
Michael GnuPG fingerprint: 9FF2128B1
On Tue, Sep 12, 2023 at 07:03:33AM +0200, Michael Koch wrote:
> > I guess deleting users requires full admin rights, so i guess, just make a
> > list
> of users which are in need of a deletion and post that and i or less likely
> some other admin will disable/delete them.
>
> Please delete user "
On Tue, Sep 12, 2023 at 02:27:17PM +0200, Andreas Rheinhardt wrote:
> Each of the 16 bytes of a GUID is written as a two-character
> hex value and three hyphens, leading to a length of 35.
> GCC 13 emits a -Wformat-truncation= warning because of this.
>
> Signed-off-by: Andreas Rheinhardt
> ---
>
On Tue, Sep 12, 2023 at 9:25 AM Lynne wrote:
> Sep 12, 2023, 09:43 by andreas.rheinha...@outlook.com:
>
> > Lynne:
> >
> >> For some reason, this was never set, which meant all **raw** AAC in ADTS
> >> streams, except faac, had extra samples at the start.
> >>
> >> Despite this being a standard M
When using multi-threaded decoding, every decoding thread
has its own DBP consisting of H264Pictures and each of these
points to its own AVFrames. They are synced during
update_thread_context via av_frame_ref() and therefore
the threads actually decoding (as well as all the others)
must not modify
Add a pointer parameter that if supplied will be used to return
the updated decode_error_flags. This will allow to fix several
races when using frame-threading; these resulted from AVFrame
that the earlier code updated concurrently being used as source
in an av_frame_ref() call in the decoder's upd
On Tue, Sep 12, 2023 at 01:40:13PM +0200, Thomas Guillem via ffmpeg-devel wrote:
> This will allow to fix data-races when ff_er_frame_end() is called after
> ff_thread_finish_setup()
> ---
> libavcodec/error_resilience.c | 12 ++--
> libavcodec/error_resilience.h | 2 +-
> libavcodec/h263
This patch makes the libkvazaar encoder respect color settings that are
present on the codec context, including color range, primaries, transfer
function and colorspace.
---
libavcodec/libkvazaar.c | 55 +
1 file changed, 55 insertions(+)
diff --git a/libav
On 9/12/2023 1:43 PM, Andreas Rheinhardt wrote:
James Almer:
On 9/11/2023 4:19 PM, Andreas Rheinhardt wrote:
James Almer:
Deprecate AVStream.side_data and its helpers in favor of the AVStream's
codecpar.side_data.
This will considerably simplify the propagation of global side data
to decoders
James Almer:
> On 9/11/2023 4:19 PM, Andreas Rheinhardt wrote:
>> James Almer:
>>> Deprecate AVStream.side_data and its helpers in favor of the AVStream's
>>> codecpar.side_data.
>>>
>>> This will considerably simplify the propagation of global side data
>>> to decoders
>>> and from encoders. Inste
On 9/11/2023 2:45 PM, Andreas Rheinhardt wrote:
James Almer:
This will simplify the propagation of side data to decoders and from encoders.
Global side data will now reside in the AVCodecContext, thus be available
during init(), removing the need to propagate it inside packets.
Global and frame
On 9/11/2023 4:19 PM, Andreas Rheinhardt wrote:
James Almer:
Deprecate AVStream.side_data and its helpers in favor of the AVStream's
codecpar.side_data.
This will considerably simplify the propagation of global side data to decoders
and from encoders. Instead of having to do it inside packets,
Sep 12, 2023, 09:43 by andreas.rheinha...@outlook.com:
> Lynne:
>
>> For some reason, this was never set, which meant all **raw** AAC in ADTS
>> streams, except faac, had extra samples at the start.
>>
>> Despite this being a standard MDCT-based codec with a frame size of 1024,
>> hence a delay of
Andreas Rheinhardt:
> It is undefined behaviour even in cases where it works
> (it works because it is only a const uint8_t* vs. uint8_t* difference).
>
> Instead add a cbuf parameter to pass a const buffer (for writing)
> as well as a parameter indicating whether we are reading or writing;
> retr
Thomas Guillem via ffmpeg-devel:
> Same than the previous commit but with FF_DECODE_ERROR_DECODE_SLICES
>
> Fix the following data-race:
>
> WARNING: ThreadSanitizer: data race (pid=55935)
> Write of size 4 at 0x7b509378 by thread T1 (mutexes: write M608):
> #0 decode_nal_units src/liba
Signed-off-by: Andreas Rheinhardt
---
libavformat/wtvdec.c | 47 ++--
1 file changed, 19 insertions(+), 28 deletions(-)
diff --git a/libavformat/wtvdec.c b/libavformat/wtvdec.c
index 9fe00590c8..e70470f79b 100644
--- a/libavformat/wtvdec.c
+++ b/libavforma
Every code point in the BMP is representable with at most three bytes
in UTF-8 and every code point not in the BMP takes four bytes.
For each of the latter, the encoding of UTF-16 takes as many
bytes; for each of the former, it takes at most 3/2 as many.
Therefore one can decrease the size of the b
Happens when length > INT_MAX / 2; use unsigned for the computation,
but restrict the value to INT_MAX, because avio_get_str16le()
accepts an int as buf_len argument. Notice that it can happen
that the string read by avio_get_str16le() is truncated in this case.
Signed-off-by: Andreas Rheinhardt
get_tag() is not designed with negative length in mind;
in this case, it will allocate a very small buffer
(LEN_PRETTY_GUID + 1) and might call avio_get_str16le()
with a negative maxlen (which relies on these parameters
to be signed).
Signed-off-by: Andreas Rheinhardt
---
libavformat/wtvdec.c |
> -Original Message-
> From: ffmpeg-devel On Behalf Of James
> Almer
> Sent: poniedziałek, 11 września 2023 00:56
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v27 2/2] avcodec/evc_decoder: Provided
> support for EVC decoder
>
> On 8/16/2023 8:11 AM, Dawid Kozins
Each of the 16 bytes of a GUID is written as a two-character
hex value and three hyphens, leading to a length of 35.
GCC 13 emits a -Wformat-truncation= warning because of this.
Signed-off-by: Andreas Rheinhardt
---
Is there actually a reason this is using a different format than
the one used by
Hi,
Sorry for not tending to your patches sooner.
Unfortunately, this patchset is impossible to apply - there seems to be
garbled whitespace in the patch which would require me to manually apply
all the changes.
Can you try sending the patches again in a way that doesn't corrupt
whitespace?
Set the FF_DECODE_ERROR_CONCEALMENT_ACTIVE flags on the AVFrane before
outputing it. Store in in the H264Picture in the meantime, where it
won't be read/write by other threads.
Fix the following data-race:
WARNING: ThreadSanitizer: data race (pid=55134)
Write of size 4 at 0x7b507f78 by thre
Same than the previous commit but with FF_DECODE_ERROR_DECODE_SLICES
Fix the following data-race:
WARNING: ThreadSanitizer: data race (pid=55935)
Write of size 4 at 0x7b509378 by thread T1 (mutexes: write M608):
#0 decode_nal_units src/libavcodec/h264dec.c:742 (ffmpeg+0xb19dd6)
#1 h
This will allow to fix data-races when ff_er_frame_end() is called after
ff_thread_finish_setup()
---
libavcodec/error_resilience.c | 12 ++--
libavcodec/error_resilience.h | 2 +-
libavcodec/h263dec.c | 6 --
libavcodec/h264dec.c | 3 ++-
libavcodec/mpeg12dec.c
Lynne:
> For some reason, this was never set, which meant all **raw** AAC in ADTS
> streams, except faac, had extra samples at the start.
>
> Despite this being a standard MDCT-based codec with a frame size of 1024,
> hence a delay of 1024 samples at the start, all major encoders, excluding
> faac
31 matches
Mail list logo
