September 12, 2021 1:15 PM, "Jean-Baptiste Kempf" wrote:
> Hello folks,
>
> This is a topic that has come regularly on the table, in various discussions
> in the community, in
> IRL, on IRC and on the mailing list; but also when talking with downstreams
> applications and
> distributions...
>
September 27, 2021 9:04 PM, "James Almer" wrote:
> Signed-off-by: James Almer
> ---
> tests/fate/checkasm.mak | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/tests/fate/checkasm.mak b/tests/fate/checkasm.mak
> index cec6d28286..6e7edbe655 100644
> --- a/tests/fate/checkasm.mak
> +++
With the accelerating by means of AVX512, the uyvytoyuv422 can be faster.
Performance data(Less is better):
uyvytoyuv422_avx2 0.27915
uyvytoyuv422_avx5120.16442
Signed-off-by: Wu Jianhua
---
libswscale/x86/rgb2rgb.c | 6 ++
libswscale/x86/rgb_2_rgb.asm | 17
With the accelerating by means of AVX2, the uyvytoyuv422 can be faster
Performance data(Less is better):
uyvytoyuv422_sse20.49381
uyvytoyuv422_avx 0.42981
uyvytoyuv422_avx20.27915
Signed-off-by: Wu Jianhua
---
libswscale/x86/rgb2rgb.c | 6 +
Performance data(Less is better):
shuffle_bytes_avx2 0.94288
shuffle_bytes_avx5120.60049
Signed-off-by: Wu Jianhua
---
libswscale/x86/rgb2rgb.c | 13 +
libswscale/x86/rgb_2_rgb.asm | 8
2 files changed, 21 insertions(+)
diff --git
Performance data(Less is better):
shuffle_bytes_ssse3 3.64654
shuffle_bytes_avx20.94288
Signed-off-by: Wu Jianhua
---
libswscale/x86/rgb2rgb.c | 17 +++--
libswscale/x86/rgb_2_rgb.asm | 11 +++
2 files changed, 26 insertions(+), 2 deletions(-)
diff --git
On 9/27/2021 7:37 PM, Michael Niedermayer wrote:
Fixes: Timeout
Fixes:
39089/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MSNSIREN_fuzzer-6677219854909440
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael
On 27/09/2021 19.16, quietvoid wrote:
Also fixes incorrect parsing of dv_bl_signal_compatibility_id,
which was often set to zero instead of the actual value, for mpegts only.
Signed-off-by: quietvoid
---
libavformat/mpegts.c | 43 +++
1 file changed,
Signed-off-by: James Almer
---
tests/fate/checkasm.mak | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tests/fate/checkasm.mak b/tests/fate/checkasm.mak
index cec6d28286..6e7edbe655 100644
--- a/tests/fate/checkasm.mak
+++ b/tests/fate/checkasm.mak
@@ -18,6 +18,7 @@ FATE_CHECKASM =
Read at most 24 bytes, but in reality only 5 bytes are used for parsing.
The rest of the bytes are reserved in the specification.
Signed-off-by: quietvoid
---
libavformat/mov.c | 50 +--
1 file changed, 9 insertions(+), 41 deletions(-)
diff --git
Also fixes incorrect parsing of dv_bl_signal_compatibility_id,
which was often set to zero instead of the actual value, for mpegts only.
Signed-off-by: quietvoid
---
libavformat/mpegts.c | 43 +++
1 file changed, 3 insertions(+), 40 deletions(-)
diff
Adds handling of dvcC/dvvC block addition mappings.
The parsing creates AVDOVIDecoderConfigurationRecord side data for the video
track.
The configuration block is written when muxing into MKV if DOVI side data is
present for the track.
In version 2.2 of the Dolby ISOM specification, there is
According to specification "Dolby Vision Stream Within the ISO Base Media File
Format Version 2.2"
This only adds support for the "Dolby Vision configuration box".
Other configuration boxes such as "Dolby Vision enhancement layer configuration
box" are not supported.
The new functions will be
Before adts_aac_resync would always bail out after probesize amount
of bytes had been progressed from the start of the input.
Now just query the current position when entering resync, and at most
advance probesize amount of data from that start position.
Fixes #9433
---
libavformat/aacdec.c | 4
Fixes: signed integer overflow: -2145648640 - 3357696 cannot be represented in
type 'int'
Fixes:
38899/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-5358815017566208
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Fixes: Timeout
Fixes:
39089/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MSNSIREN_fuzzer-6677219854909440
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/siren.c | 3 +++
1 file changed,
On Tue, Sep 28, 2021 at 1:34 AM James Almer wrote:
>
> On 9/27/2021 6:31 PM, Jan Ekström wrote:
> > Before adts_aac_resync would always bail out after probesize amount
> > of bytes had been progressed from the start of the input.
> >
> > Add an argument for the start position, and set it to zero
On 9/27/2021 6:31 PM, Jan Ekström wrote:
Before adts_aac_resync would always bail out after probesize amount
of bytes had been progressed from the start of the input.
Add an argument for the start position, and set it to zero when
reading the header (which should happen in the beginning) to
Before adts_aac_resync would always bail out after probesize amount
of bytes had been progressed from the start of the input.
Add an argument for the start position, and set it to zero when
reading the header (which should happen in the beginning) to mimic
previous behavior of going only up to
On Sun, Sep 26, 2021 at 05:22:59PM +, Soft Works wrote:
> Usage example:
>
> ffmpeg -y -loglevel verbose -i "..\fate-suite\apng\o_sample.png"
> -filter_complex
> "split[split1][split2];[split1]palettegen=max_colors=254:use_alpha=1[pal1];[split2][pal1]paletteuse=use_alpha=1"
> -frames:v 1
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 subject "unsubscribe".
On Mon, Sep 27, 2021 at 5:30 PM Michael Niedermayer
wrote:
> On Sun, Sep 26, 2021 at 05:56:36PM +, Soft Works wrote:
> >
> >
> > > -Original Message-
> > > From: ffmpeg-devel On Behalf Of
> > > Michael Niedermayer
> > > Sent: Sunday, 26 September 2021 18:52
> > > To: FFmpeg
On Sun, Sep 26, 2021 at 05:56:36PM +, Soft Works wrote:
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Michael Niedermayer
> > Sent: Sunday, 26 September 2021 18:52
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re:
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Soft Works
> Sent: Monday, 27 September 2021 14:12
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] avfilter/frames: Ensure frames
> are writable when processing in-place
>
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Nicolas George
> Sent: Monday, 27 September 2021 14:10
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] avfilter/frames: Ensure frames
> are writable when processing
Soft Works (12021-09-27):
> With the introduction of subtitle filtering, subsequent video frames
> which are sharing the same data won't be as rare as this happened
> to occur yet.
> Ensuring per-frame uniqueness when data is modified is not only important
> to avoid issues in the future, but a
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Soft Works
> Sent: Monday, 27 September 2021 14:07
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH] avfilter/frames: Ensure frames are
> writable when processing in-place
>
> With the introduction of subtitle
With the introduction of subtitle filtering, subsequent video frames
which are sharing the same data won't be as rare as this happened
to occur yet.
Ensuring per-frame uniqueness when data is modified is not only important
to avoid issues in the future, but a common API requirement anyway.
quietvoid:
>> quietvoid:
>>> Adds handling of dvcC/dvvC block addition mappings.
>>> The parsing creates AVDOVIDecoderConfigurationRecord side data for
>>> the video track.
>>> The configuration block is written when muxing into MKV if DOVI side
>>> data is present for the track.
>>>
>>> In
quietvoid:
Adds handling of dvcC/dvvC block addition mappings.
The parsing creates AVDOVIDecoderConfigurationRecord side data for the video
track.
The configuration block is written when muxing into MKV if DOVI side data is
present for the track.
In version 2.2 of the Dolby ISOM
On Sun, Sep 26, 2021 at 8:48 AM NoHalfBits
wrote:
> Sets vtctx->has_b_frames to 0 if the VideoToolbox compression
> session will not emit B-frames (and, in consequence, no valid
> DTSs). Required for the handling of invalid DTSs in
> 'vtenc_cm_to_avpacket' (line 2018ff) to work correctly and not
On Mon, Sep 20, 2021 at 6:00 PM Jan Ekström wrote:
>
> Compared to v2:
> * aviobuf changes to make a function useful in MP4 null-delimited string
> parsing into AVBPrint.
> ** Extended read_line_to_bprint to be a more generic read_string_to_bprint.
> ** Added a maximum length argument to
On Mon, 2021-09-27 at 10:21 +0200, Andreas Rheinhardt wrote:
> Xiang, Haihao:
> > On Sun, 2021-09-26 at 08:32 +0200, Andreas Rheinhardt wrote:
> > > Since commit 3bbe0c210b05fc6fbd7b1d4bbd8479db7f2cf957, the Payloads
> > > array of every QSVFrame leaks as soon as the frame is reused;
> > > the
Xiang, Haihao:
> On Sun, 2021-09-26 at 08:32 +0200, Andreas Rheinhardt wrote:
>> Since commit 3bbe0c210b05fc6fbd7b1d4bbd8479db7f2cf957, the Payloads
>> array of every QSVFrame leaks as soon as the frame is reused;
>> the leak is small and not very noticeable, but if there is an attempt
>> to use
On Sun, 2021-09-26 at 08:32 +0200, Andreas Rheinhardt wrote:
> Since commit 3bbe0c210b05fc6fbd7b1d4bbd8479db7f2cf957, the Payloads
> array of every QSVFrame leaks as soon as the frame is reused;
> the leak is small and not very noticeable, but if there is an attempt
> to use said array the ensuing
On Mon, Sep 27, 2021 at 8:48 AM Wu, Jianhua wrote:
> Ping.
> Jianhua wrote:
> >
> > Ping.
> >
> > Jianhua wrote:
> > > From: ffmpeg-devel On Behalf Of
> > Wu,
> > > Jianhua
> > > Sent: Tuesday, September 14, 2021 1:02 PM
> > > To: FFmpeg development discussions and patches > >
Ping.
Jianhua wrote:
>
> Ping.
>
> Jianhua wrote:
> > From: ffmpeg-devel On Behalf Of
> Wu,
> > Jianhua
> > Sent: Tuesday, September 14, 2021 1:02 PM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH 1/4] libavfilter/x86/vf_hflip: add
37 matches
Mail list logo
