On Fri, Oct 02, 2020 at 11:07:09PM +0200, Michael Niedermayer wrote:
> The MV checks did not consider the width and height of the block, also they
> had some off by 1 errors. This resulted in undefined behavior and crashes.
> This commit instead errors out on these
>
> Fixes: out of array read
> F
On Fri, Oct 02, 2020 at 12:18:49PM +0200, Paul B Mahol wrote:
> Even if such files are invalid, they can be decoded just fine.
> Also stored tiles may have bigger dimensions than displayed ones,
> so do not abort decoding in such cases.
>
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/tiff.c |
That have unused symbols coded in DHT.
Signed-off-by: Paul B Mahol
---
libavcodec/g2meet.c | 10 +-
libavcodec/jpegtables.c | 19 ---
libavcodec/mjpegdec.c | 21 +
3 files changed, 18 insertions(+), 32 deletions(-)
diff --git a/libavcodec/g2meet
That have unused symbols coded in DHT.
Signed-off-by: Paul B Mahol
---
libavcodec/jpegtables.c | 15 ++-
libavcodec/mjpegdec.c | 41 +
2 files changed, 31 insertions(+), 25 deletions(-)
diff --git a/libavcodec/jpegtables.c b/libavcodec/jpegt
On Sat, Oct 03, 2020 at 10:43:04AM +0200, Paul B Mahol wrote:
> On Fri, Oct 02, 2020 at 11:07:09PM +0200, Michael Niedermayer wrote:
> > The MV checks did not consider the width and height of the block, also they
> > had some off by 1 errors. This resulted in undefined behavior and crashes.
> > Thi
Actually names of 2 tables ff_ac3_sample_rate_tab and ff_ac3_channels_tab need
to be changed in order to access them from libavformat.
There would be changes in multiple files in which these tables have been used
currently. Is that fine ?
From: ffmpeg-devel on b
On 10/3/2020 2:30 PM, Nachiket Tarate wrote:
> Actually names of 2 tables ff_ac3_sample_rate_tab and ff_ac3_channels_tab
> need to be changed in order to access them from libavformat.
> There would be changes in multiple files in which these tables have been used
> currently. Is that fine ?
You
On Fri, Oct 02, 2020 at 08:03:28PM +0200, Anton Khirnov wrote:
> ---
> libavfilter/Makefile| 2 +-
> libavfilter/vf_spp.c| 57 -
> libavfilter/vf_spp.h| 3 +-
> tests/fate/filter-video.mak | 4 +--
> 4 files changed, 29 insertions(+),
On Fri, Oct 02, 2020 at 08:03:25PM +0200, Anton Khirnov wrote:
> Do it only when requested with the AV_CODEC_EXPORT_DATA_VIDEO_ENC_PARAMS
> flag.
>
> Drop previous code using the long-deprecated AV_FRAME_DATA_QP_TABLE*
> API. Temporarily disable fate-filter-pp, fate-filter-pp7,
> fate-filter-spp.
Am Sa., 3. Okt. 2020 um 00:24 Uhr schrieb Nicolas Gaullier
:
>
> Because of the dependencies, I had to group all the patches in a serie, but
> they are 3 functional parts :
> * patch 1 is necessary to fix dolby_e pts that will be part of the test in
> patch 8
> * patch 2,3,4,5,6,7,8 : s337m suppo
Am Sa., 3. Okt. 2020 um 00:24 Uhr schrieb Nicolas Gaullier
:
>
> Similar to ff_spdif_probe() with just an additional checking of
> the bit resolution of the container as it may be 16 or 24 for s337m.
Sorry if I miss something:
Why is the new function part of s337m.c?
Carl Eugen
__
On Fri, Oct 02, 2020 at 04:27:47PM +0200, Paul B Mahol wrote:
> On Fri, Oct 02, 2020 at 02:59:15PM +0200, Michael Niedermayer wrote:
> > Fixes: Infinite loop
> > Fixes:
> > 26016/clusterfuzz-testcase-minimized-ffmpeg_IO_DEMUXER_fuzzer-6195663833137152
> >
> > Found-by: continuous fuzzing process
On Fri, Oct 02, 2020 at 04:26:58PM +0200, Paul B Mahol wrote:
> On Fri, Oct 02, 2020 at 02:59:13PM +0200, Michael Niedermayer wrote:
> > Fixes: left shift of negative value -640
> > Fixes:
> > 26044/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DXTORY_fuzzer-5631057602543616
> >
> > Found-by:
Am Sa., 3. Okt. 2020 um 00:25 Uhr schrieb Nicolas Gaullier
:
> Allows user to disable codec auto-detection.
> Probe requests are ignored, including spdif/s337m submux detection in wavdec.
> Note: this option is required to pass-through dolby_e data from a wav file.
I don't think this is correct,
Am Do., 24. Sept. 2020 um 19:35 Uhr schrieb Paul B Mahol :
> +static int ace_probe(const AVProbeData *p)
> +{
> +uint32_t asc;
> +
> +if (AV_RB32(p->buf) != MKBETAG('A','A','C',' '))
> +return 0;
> +if (p->buf_size < 0x44)
> +return 0;
> +asc = AV_RB32(p->buf + 0x40
So you want me to change ff_ac3_sample_rate_tab to avpriv_ac3_sample_rate_tab
and get channel count using av_get_channel_layout_nb_channels(). Is my
understanding correct ?
From: ffmpeg-devel on behalf of James Almer
Sent: Saturday, October 3, 2020 11:04 PM
To:
On 10/3/2020 6:12 PM, Nachiket Tarate wrote:
> So you want me to change ff_ac3_sample_rate_tab to avpriv_ac3_sample_rate_tab
> and get channel count using av_get_channel_layout_nb_channels(). Is my
> understanding correct ?
Yes.
Also please, don't top post in this list. Write below the paragrap
From: ffmpeg-devel on behalf of James Almer
Sent: Sunday, October 4, 2020 3:07 AM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH 2/2] libavcodec/ac3_parser: add avpriv
function to parse EC3SpecificBox (dec3)
On 10/3/2020 6:12 PM, Nachiket Tarat
From: Mark Reid
These conversion appears to be exhibiting the same rounding error as the rgbf32
formats where.
I seperated the rounding value from the 16 and 128 offsets, I think it makes it
a little more clear.
---
libswscale/input.c | 6 ++--
tests/ref/fate/filter-p
19 matches
Mail list logo
