On Wed, 22 Jan 2020, Nicolas George wrote:
Marton Balint (12020-01-16):
It is not supported by every threading implementation, and the only thing we
gain with it is an immediate shutdown of receiving packets on close and
avoiding the poll call before reading the data.
I don't think it is a b
avio_close_dyn_buf() has a bug: When the write pointer does not point to
the end of the written data when calling it (i.e. when one has performed
a seek back to update already written data), it would not add padding to
the end of the buffer, but to the current position, overwriting other
data; furt
The Matroska muxer uses a dynamic buffer to buffer the content of
Clusters before eventually writing them. Up until now, each time a
Cluster was written, the dynamic buffer was closed, i.e. freed; now it
is only reset, saving allocations of the AVIOContext itself, its opaque
as well as most of the
When updating the Tags at the end, the Matroska muxer would twice check
for whether (!mkv->is_live) is true, despite this code being only executed
if it is. Furthermore, a loop iterates over all the streams even when
there is no Tags element to update at all, because the check for whether
there are
On Tue, Jan 21, 2020 at 09:39:03PM +0100, Michael Niedermayer wrote:
> On Tue, Jan 21, 2020 at 04:39:10PM -0300, James Almer wrote:
> > On 1/21/2020 4:30 PM, Michael Niedermayer wrote:
> > > On Tue, Jan 21, 2020 at 07:48:38PM +0100, Anton Khirnov wrote:
> > >> Quoting Michael Niedermayer (2019-12-3
Marton Balint (12020-01-16):
> It is not supported by every threading implementation, and the only thing we
> gain with it is an immediate shutdown of receiving packets on close and
> avoiding the poll call before reading the data.
>
> I don't think it is a big issue if it takes 0.1 sec of delay t
On Wed, Jan 22, 2020 at 06:53:13PM +0100, Andreas Rheinhardt wrote:
> On Wed, Jan 22, 2020 at 6:44 PM Michael Niedermayer
> wrote:
>
> > On Wed, Jan 22, 2020 at 03:42:25PM +0100, Andreas Rheinhardt wrote:
> > > On Tue, Jan 21, 2020 at 11:18 PM Michael Niedermayer
> >
> > > wrote:
> > >
> > > > F
Nicolas George (12020-01-22):
> Andreas Rheinhardt (12020-01-22):
> > Clang with UBSan. It of course works in practice, but we don't know whether
> > future compilers might exploit undefined behaviour in an unintended way, so
> > these theoretical issues should be fixed.
>
> This one is rather cle
On Wed, Jan 22, 2020 at 6:44 PM Michael Niedermayer
wrote:
> On Wed, Jan 22, 2020 at 03:42:25PM +0100, Andreas Rheinhardt wrote:
> > On Tue, Jan 21, 2020 at 11:18 PM Michael Niedermayer
>
> > wrote:
> >
> > > Fixes: Invalid shifts
> > > Fixes: #8140
> > > Fixes: #8146
> > >
> > > Signed-off-by:
Andreas Rheinhardt (12020-01-22):
> by using a multiplication instead. The multiplication can never overflow
> an int because the sin-factor is only an int16_t.
No objection.
> Affected the FATE-tests filter-concat and filter-concat-vfr.
I find that suspect, the change is only theoretical. What
On Wed, Jan 22, 2020 at 03:42:25PM +0100, Andreas Rheinhardt wrote:
> On Tue, Jan 21, 2020 at 11:18 PM Michael Niedermayer
> wrote:
>
> > Fixes: Invalid shifts
> > Fixes: #8140
> > Fixes: #8146
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libswscale/input.c | 8
> > 1 file ch
On Tue, Jan 21, 2020 at 03:50:58PM +0100, Michael Niedermayer wrote:
> Suggested-by: Anton
> Signed-off-by: Michael Niedermayer
> ---
> libavutil/log.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
will apply
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611
Quoting Michael Niedermayer (2020-01-21 21:39:03)
>
> replacing a named constant by a litteral repeated -1 is making the code
> worse. (maintaince and understanding wise)
>
> So from the smell of this thread i dont think we will agree on a public
> API and that also wasnt suggested nor is it need
Quoting Lynne (2020-01-21 21:52:52)
> Jan 21, 2020, 18:22 by an...@khirnov.net:
> >> Its size too? Didn't know that.
> >> I do think its a good idea to be able to append fields to it, so I've
> >> added a av_vk_frame_alloc() function. I've followed what
> >> av_frame_alloc is called, though I'm not
On Wed, Jan 22, 2020 at 4:23 PM Carl Eugen Hoyos wrote:
> Am Mi., 22. Jan. 2020 um 16:21 Uhr schrieb Andreas Rheinhardt
> :
> >
> > On Wed, Jan 22, 2020 at 4:06 PM Carl Eugen Hoyos
> wrote:
> >
> > > Am Mi., 22. Jan. 2020 um 15:57 Uhr schrieb Andreas Rheinhardt
> > > :
> > > >
> > > > when direc
Am Mi., 22. Jan. 2020 um 16:21 Uhr schrieb Andreas Rheinhardt
:
>
> On Wed, Jan 22, 2020 at 4:06 PM Carl Eugen Hoyos wrote:
>
> > Am Mi., 22. Jan. 2020 um 15:57 Uhr schrieb Andreas Rheinhardt
> > :
> > >
> > > when directly accessing a buffer via a pointer to uint8_t cast to a
> > > pointer to uin
On Wed, Jan 22, 2020 at 4:06 PM Carl Eugen Hoyos wrote:
> Am Mi., 22. Jan. 2020 um 15:57 Uhr schrieb Andreas Rheinhardt
> :
> >
> > when directly accessing a buffer via a pointer to uint8_t cast to a
> > pointer to uint64_t/uint32_t. This happened only if HAVE_FAST_UNALIGNED
> > was set, so it wa
by keeping the variable uint32_t which in this situation is the natural
type anyway. This affected the FATE-test filter-paletteuse-sierra2_4a.
Signed-off-by: Andreas Rheinhardt
---
libavfilter/vf_paletteuse.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavfilter/vf
Am Mi., 22. Jan. 2020 um 15:57 Uhr schrieb Andreas Rheinhardt
:
>
> when directly accessing a buffer via a pointer to uint8_t cast to a
> pointer to uint64_t/uint32_t. This happened only if HAVE_FAST_UNALIGNED
> was set, so it was ok, but UBSan nevertheless complained about unaligned
> accesses. So
by using a multiplication instead. The multiplication can never overflow
an int because the sin-factor is only an int16_t.
Affected the FATE-tests filter-concat and filter-concat-vfr.
Signed-off-by: Andreas Rheinhardt
---
libavfilter/asrc_sine.c | 2 +-
1 file changed, 1 insertion(+), 1 deletio
by replacing it with a multiplication. Said multiplication can't
overflow an int32_t because lpc_coefs is limited to 16 bit precision.
Fixes the FACE-test acodec-ra144 as well as part of #8217.
Signed-off-by: Andreas Rheinhardt
---
I am unable to reproduce the division by zero mentioned in ticke
when directly accessing a buffer via a pointer to uint8_t cast to a
pointer to uint64_t/uint32_t. This happened only if HAVE_FAST_UNALIGNED
was set, so it was ok, but UBSan nevertheless complained about unaligned
accesses. So simply use AV_RNxx to read the buffer; this also improves
readability.
T
On Tue, Jan 21, 2020 at 11:18 PM Michael Niedermayer
wrote:
> Fixes: Invalid shifts
> Fixes: #8140
> Fixes: #8146
>
> Signed-off-by: Michael Niedermayer
> ---
> libswscale/input.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libswscale/input.c b/libswscale/in
On Wed, Jan 22, 2020 at 05:53:15AM +0100, Andreas Rheinhardt wrote:
> On Tue, Jan 21, 2020 at 11:24 PM Michael Niedermayer
> wrote:
>
> > Fixes: Invalid shifts
> > Fixes: #8166
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libswscale/swscale.c | 4 ++--
> > 1 file changed, 2 insertions
The reason is that the tested models are in float format. And also
remove fate-filter-dnn_processing-halve_gray_float to make reference
files smaller.
Signed-off-by: Guo, Yejun
---
tests/fate/filter-video.mak| 7 +--
...filter-dnn_processing-halve_first_channel_float | 5
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Martin Storsj?
> Sent: Wednesday, January 22, 2020 8:09 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] fate/filter-video.mak: do not use
> bit-exa
On Wed, Jan 22, 2020 at 06:13:52AM +0100, Andreas Rheinhardt wrote:
> On Tue, Jan 21, 2020 at 11:24 PM Michael Niedermayer
> wrote:
>
> > Fixes: Invalid shifts
> > Fixes: #8320
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libswscale/output.c | 4 ++--
> > 1 file changed, 2 insertions(
On Tue, 21 Jan 2020, Guo, Yejun wrote:
-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
Martin Storsj?
Sent: Tuesday, January 21, 2020 4:38 AM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH] fate/filter-vid
On Tue, Jan 21, 2020 at 8:17 PM Lynne wrote:
> Jan 20, 2020, 08:42 by kavea...@gmail.com:
>
> > Ping
> >
>
> https://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/248836.html
>
>
> I've okayed it, its just not been pushed yet.
> You'll need to add the vectors to the block struct. int16_t [2] will
29 matches
Mail list logo
