The function was re-written in asm, this code is heavily derived from the
original code, the algorithm remains unchanged, the implementation is
optimized. Would you agree to adding the copyright from swscale.c:
* Copyright (C) 2001-2011 Michael Niedermayer
to this file, having both copyrights? Th
On Fri, Nov 6, 2020 at 2:29 AM Mark Thompson wrote:
>
> On 05/11/2020 15:53, Hendrik Leppkes wrote:
> > ---
> > Changelog | 1 +
> > configure | 7 +
> > libavcodec/Makefile| 2 +
> > libavcodec/av1dec.c| 25 +-
> > libavcodec/dxva2.c | 10 +-
> >
Thanks for the reply, Steven!
Regarding JEEB’s comment, the suggestion was to add an api to the *libaom*
library, not to ffmpeg. I do agree with the rationale, but when such an api
would be available for ffmpeg to use is quite uncertain. In the meanwhile,
I believe it is reasonable to add in this
> 2020年11月6日 下午4:42,Bohan Li 写道:
>
> Thanks for the reply, Steven!
>
> Regarding JEEB’s comment, the suggestion was to add an api to the *libaom*
> library, not to ffmpeg. I do agree with the rationale, but when such an api
> would be available for ffmpeg to use is quite uncertain. In the m
Andreas Rheinhardt:
> During init the mts2 decoder allocates several VLCs and then several
> buffers in a loop; if one of the latter allocations fails, only the VLCs
> are freed, not any buffers that might already have been successfully
> allocated. This commit fixes this by setting the
> FF_CODEC_
Andreas Rheinhardt:
> Instead allocate it together with the buffer that it mirrors.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/sonic.c | 16
> 1 file changed, 4 insertions(+), 12 deletions(-)
>
> diff --git a/libavcodec/sonic.c b/libavcodec/sonic.c
> index bca1eca
---
Changelog | 1 +
configure | 7 +
libavcodec/Makefile| 2 +
libavcodec/av1dec.c| 25 +-
libavcodec/dxva2.c | 10 +-
libavcodec/dxva2_av1.c | 504 +
libavcodec/hwaccels.h | 3 +
libavcodec/version.h | 2
On Fri, Nov 6, 2020 at 11:39 AM Hendrik Leppkes wrote:
>
> ---
> Changelog | 1 +
> configure | 7 +
> libavcodec/Makefile| 2 +
> libavcodec/av1dec.c| 25 +-
> libavcodec/dxva2.c | 10 +-
> libavcodec/dxva2_av1.c | 504 +++
On Fri, Nov 6, 2020 at 11:46 AM Steven Liu wrote:
>
>
>
> > 2020年11月6日 下午4:42,Bohan Li 写道:
> >
> > Thanks for the reply, Steven!
> >
> > Regarding JEEB’s comment, the suggestion was to add an api to the *libaom*
> > library, not to ffmpeg. I do agree with the rationale, but when such an api
> >
On Mon, Nov 02, 2020 at 10:07:42AM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> tests/fate/filter-video.mak | 3 +++
> tests/ref/fate/filter-unsharp-yuv420p10 | 25 +
> 2 files changed, 28 insertions(+)
> cre
On 6/11/20 11:51 am, Zane van Iperen wrote:
On 6/11/20 9:11 am, Michael Niedermayer wrote:
The reverted code split at block_align boundaries, but there was already code
which splits at a hardcoded 4096 sample boundary.
reverting this seemed like the easiest fix but this is a RFC in case ano
On Fri, Nov 6, 2020 at 11:42 AM Hendrik Leppkes wrote:
>
> On Fri, Nov 6, 2020 at 11:39 AM Hendrik Leppkes wrote:
> >
> > ---
> > Changelog | 1 +
> > configure | 7 +
> > libavcodec/Makefile| 2 +
> > libavcodec/av1dec.c| 25 +-
> > libavcodec/dxva2.c
Is incorrect behaviour. Was covering for an encoder bug where it produced frames
of the wrong size.
Fixes: out of array write
Fixes:
26821/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ADPCM_SWF_fuzzer-5764465137811456
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/
SWF File Format Specification, Version 19 says this is 1 raw
sample + 4095 nibbles.
https://www.adobe.com/content/dam/acom/en/devnet/pdf/swf-file-format-spec.pdf
Signed-off-by: Zane van Iperen
---
libavcodec/adpcmenc.c | 2 +-
tests/ref/acodec/adpcm-swf | 8 ++---
On Wed, Nov 04, 2020 at 14:08:23 +, Joakim Tjernlund wrote:
> > No it doesn't. It forces them to upgrade away from a known vulnerable
> > old Chromium version to one that does not have the issue.
>
> I was referring to what is out/released now. Eventually all SW will upgrade
> for one reason o
On Fri, 2020-11-06 at 15:05 +0100, Moritz Barsnick wrote:
>
> On Wed, Nov 04, 2020 at 14:08:23 +, Joakim Tjernlund wrote:
> > > No it doesn't. It forces them to upgrade away from a known vulnerable
> > > old Chromium version to one that does not have the issue.
> >
> > I was referring to what
Thanks a lot for the comment, Jan and Steven! Yes I very much agree that
the number of options is quite large and this is not a great path to go
for. But for the moment I still suggest that we apply this patch, while
proposing to libaom for a key & value api.
This option gives users the option to
On Wed, Nov 04, 2020 at 10:44:56PM +0100, Marton Balint wrote:
>
>
> On Wed, 4 Nov 2020, Michael Niedermayer wrote:
>
> > we have "millisecond" based formats, rounded timestamps
> > we have "exact" cases, maybe the timebase being 1 packet/frame per tick
> > we have "high precission" where the ti
On Thu, Nov 05, 2020 at 04:48:31PM +0100, Matthias Neugebauer wrote:
> Am 04.11.2020 um 19:24 schrieb Michael Niedermayer :
> >
> > Is this FFmpeg specific or why is the X- prefix preferred over adding
> > this to nut.txt ?
> >
> > thx
>
> No, side data such as the display matrix is commonly use
---
libavformat/avidec.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/libavformat/avidec.c b/libavformat/avidec.c
index 578cf68ce1..7e527e15ee 100644
--- a/libavformat/avidec.c
+++ b/libavformat/avidec.c
@@ -110,6 +110,15 @@ static const char avi_headers[][8] = {
stati
At high frame rate, the message "Starting new cluster due to timestamp"
happens too often. Moving to debug to reduce the warning log
---
libavformat/matroskaenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 233c472
Thierry Foucu:
> At high frame rate, the message "Starting new cluster due to timestamp"
> happens too often. Moving to debug to reduce the warning log
> ---
> libavformat/matroskaenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/matroskaenc.c b/libavforma
Signed-off-by: Paul B Mahol
---
doc/filters.texi| 49 +
libavfilter/Makefile| 1 +
libavfilter/af_speechnorm.c | 422
libavfilter/allfilters.c| 1 +
4 files changed, 473 insertions(+)
create mode 100644 libavfilter/af_speechno
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mobiclip.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/mobiclip.c b/libavcodec/mobiclip.c
index 9fa88e84a0..42d33cf6a5 100644
--- a/libavcodec/mobiclip.c
+++ b/libavcodec/mobiclip.c
@@ -539,11 +539,11 @@ s
At the end of its decode function, the decoder sets *got_frame to 1 and
then checks whether ret is < 0; if so, it is returned, otherwise
avpkt->size is. But it is impossible for ret to be < 0 here and if it
were, it would be nonsense to set *got_frame to 1 before this. Therefore
just return avpkt->
On Tue, 03. Nov 00:25, Andriy Gelman wrote:
> On Thu, 08. Oct 23:40, Andriy Gelman wrote:
> > On Sat, 11. Jul 11:29, Omar Emara wrote:
> > > This patch adds a select_region option to the xcbgrab input device.
> > > If set to 1, the user will be prompted to select the grabbing area
> > > graphically
Any update? Can we push it to the head?
Thanks,
Mohammad
On Mon, Oct 26, 2020 at 11:53 AM Mohammad Izadi wrote:
> Thank you, Jan! I hope you feel better soon.
>
>
>
> On Sun, Oct 25, 2020 at 5:49 PM Jan Ekström wrote:
>
>> On Wed, Oct 14, 2020 at 2:54 AM Mohammad Izadi
>> wrote:
>> >
>> > Fro
27 matches
Mail list logo