On Wed, 20 Sep 2017 18:55:40 -0700
Jorge Ramirez-Ortiz wrote:
> This patchset enhances Alexis Ballier's original patch and validates
> it using Qualcomm's Venus hardware (driver recently landed upstream
> [1]).
Pushed to master.
___
ffmpeg-
Hey Ronald,
Was this able to solve the issue for you?
On Mon, Jul 24, 2017 at 6:27 AM, Kevin Mark wrote:
> Hi Ronald,
>
> On Wed, Jul 19, 2017 at 3:44 AM, Ronald S. Bultje wrote:
>> But my grep (Mac) has no -P option... I'd encourage you to keep things
>> simple and use a non-\n delimiter betwe
On 23 September 2017 at 00:46, Rostislav Pehlivanov
wrote:
> On 12 April 2017 at 23:26, Rostislav Pehlivanov
> wrote:
>
> >
> >
> Here's the latest version, which I consider to be non-WIP now.
> I plan to push it tomorrow morning if there are no objections.
>
This commit implement a psychoacous
On 9/22/2017 10:01 PM, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/snowenc.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/snowenc.c b/libavcodec/snowenc.c
> index bb113d0a2b..f5497f958c 100644
> --- a/libavc
Signed-off-by: Michael Niedermayer
---
libavcodec/snowenc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/snowenc.c b/libavcodec/snowenc.c
index bb113d0a2b..f5497f958c 100644
--- a/libavcodec/snowenc.c
+++ b/libavcodec/snowenc.c
@@ -50,7 +50,7 @@ FF_ENA
Signed-off-by: Michael Niedermayer
---
libavcodec/flacenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/flacenc.c b/libavcodec/flacenc.c
index 3575f5391d..170c3caf48 100644
--- a/libavcodec/flacenc.c
+++ b/libavcodec/flacenc.c
@@ -268,7 +268,7 @@ static av_cold
On 12 April 2017 at 23:26, Rostislav Pehlivanov wrote:
>
>
Here's the latest version, which I consider to be non-WIP now.
I plan to push it tomorrow morning if there are no objections.
From 62dcd1e7e4db391c30c3893fde82bc205ebb7bfe Mon Sep 17 00:00:00 2001
From: Rostislav Pehlivanov
Date: Sat, 23
Hello,
in attach a patch
with a port to asm of the predictor part of this patch :
https://github.com/openexr/openexr/pull/229/commits/4198128397c033d4f69e5cc0833195da500c31cf
Tested on OSX, pass fate test for me
Check asm also pass for me
Results with reorder simd disable :
SSSE3 : 94.5s
103675
On Thu, Sep 21, 2017 at 6:25 PM, Hendrik Leppkes
wrote:
>On Thu, Sep 21, 2017 at 11:54 PM, Joseph Van Riper
> wrote:
>>
>> I would normally not want to request of an open source team a fast
response
>> to something like this, but I sense some urgency to resolving this issue
>> for the folks who ha
Fixes: runtime error: signed integer overflow: -1562477869 + -691460395 cannot
be represented in type 'int'
Fixes: 3196/clusterfuzz-testcase-minimized-4528307146063872
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niede
Fixes: runtime error: shift exponent 42 is too large for 32-bit type 'unsigned
int'
Fixes: 3410/clusterfuzz-testcase-minimized-5313377960198144
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/
Fixes: runtime error: signed integer overflow: 16748560 + 2143729712 cannot be
represented in type 'int'
Fixes: 3202/clusterfuzz-testcase-minimized-4988291642294272
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niederma
On 9/22/2017 2:06 PM, Mateusz wrote:
> W dniu 2017-09-22 o 17:47, James Almer pisze:
>> On 9/22/2017 12:23 PM, Mateusz wrote:
>>> New version of the patch -- now it uses the same logic independent of the
>>> target bitdepth.
>>>
>>> For x86_64 it is much faster than current code (with perfect qual
W dniu 2017-09-22 o 17:47, James Almer pisze:
> On 9/22/2017 12:23 PM, Mateusz wrote:
>> New version of the patch -- now it uses the same logic independent of the
>> target bitdepth.
>>
>> For x86_64 it is much faster than current code (with perfect quality), for
>> x86_32 it is fast
>> if you ad
On 9/22/2017 12:23 PM, Mateusz wrote:
> New version of the patch -- now it uses the same logic independent of the
> target bitdepth.
>
> For x86_64 it is much faster than current code (with perfect quality), for
> x86_32 it is fast
> if you add to configure: --extra-cflags="-msse2"
> (for x86_32
New version of the patch -- now it uses the same logic independent of the
target bitdepth.
For x86_64 it is much faster than current code (with perfect quality), for
x86_32 it is fast
if you add to configure: --extra-cflags="-msse2"
(for x86_32 with default configure options it is slower than cu
LGTM
-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
kaustubh.ra...@imgtec.com
Sent: Thursday, September 21, 2017 1:46 PM
To: ffmpeg-devel@ffmpeg.org
Cc: Kaustubh Raste
Subject: [FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc uni-w copy mc msa
LGTM
-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
kaustubh.ra...@imgtec.com
Sent: Thursday, September 21, 2017 7:30 PM
To: ffmpeg-devel@ffmpeg.org
Cc: Kaustubh Raste
Subject: [FFmpeg-devel] [PATCH] avcodec/mips: Improve avc chroma horiz mc ms
LGTM
-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
kaustubh.ra...@imgtec.com
Sent: Thursday, September 21, 2017 7:03 PM
To: ffmpeg-devel@ffmpeg.org
Cc: Kaustubh Raste
Subject: [FFmpeg-devel] [PATCH] avcodec/mips: Unrolled loops avc intra msa
On Thu, Sep 21, 2017 at 11:57:16AM +, Manojkumar Bhosale wrote:
> LGTM
applied
[]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
signature.asc
De
On Thu, Sep 21, 2017 at 12:01:45PM +, Manojkumar Bhosale wrote:
> LGTM
applied
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
signature.asc
Description: Digital
Am 04.09.2017 um 14:59 schrieb Yogender Gupta:
Taken care of all comments except the documentation.
applied
Will send out a separate patch for both the CUDA filters documentation.
ok
smime.p7s
Description: S/MIME Cryptographic Signature
___
ffm
On Mon, Sep 18, 2017 at 02:54:58AM +0200, Michael Niedermayer wrote:
> Fixes: runtime error: signed integer overflow: 161 * 13872281 cannot be
> represented in type 'int'
>
> Fixes: 3295/clusterfuzz-testcase-minimized-4738998142500864
>
> Found-by: continuous fuzzing process
> https://github.co
On Tue, Sep 19, 2017 at 01:04:52AM +0200, Michael Niedermayer wrote:
> Fixes: runtime error: signed integer overflow: 2147392585 + 524288 cannot be
> represented in type 'int'
> Fixes: 3348/clusterfuzz-testcase-minimized-4809500517203968
>
> Found-by: continuous fuzzing process
> https://github.
On Thu, Sep 21, 2017 at 6:30 PM, Paul B Mahol wrote:
> On 9/21/17, Umair Khan wrote:
>> Hi Ronald,
>>
>> On Mon, Sep 11, 2017 at 10:27 PM, Ronald S. Bultje
>> wrote:
>>> Hi Umair,
>>>
>>> On Mon, Sep 11, 2017 at 4:06 AM, Umair Khan wrote:
>>>
On Sun, Sep 10, 2017 at 10:30 PM, Paul B Mahol
On Fri, 8 Sep 2017 21:08:13 +0200
Błażej Szczygieł wrote:
> VDPAUHWContext struct is used internally, so allocate required amount
> of memory. Also move hwctx->reset as it was prior to
> 7e4ba776a2240d40124d5540ea6b2118fa2fe26a to make sure that buffer
> overflow doesn't happen if application al
Hi Timo,
As for the deprecation of libnpp, I suggest to keeping it. We use it a lot! In
addition, we have some improvements for the current scale_npp... however,
before publishing it it's necesssary to solve the question of the linking with
libnpp.
Regarding the static linking with libnpp, I h
- add "-asyncbufsize" option to async:
- refactor async.c
- remove READ_BACK_CAPACITY and the 3rd arg of ring_init()
- replace some magicnums with symconst macros
---
doc/protocols.texi | 6 ++
libavformat/async.c | 18 +++---
2 files changed, 17 insertions(+), 7 deletions(-)
28 matches
Mail list logo
