On Tue, Apr 25, 2017 at 11:04:21PM +0200, Martin Vignali wrote:
> >
> > did you try to make exp int32_t to avoid the 2nd check ?
> >
> > [...]
> >
>
> New patch in attach, with exp (and v) in int32_t
>
> Also fix the sample for me
>
> Martin
> exr.c |4 ++--
> 1 file changed, 2 insertions(
On Wed, Apr 26, 2017 at 10:05:40PM +0200, wm4 wrote:
> On Thu, 27 Apr 2017 01:41:04 +0700
> Muhammad Faiz wrote:
>
> > On Wed, Apr 26, 2017 at 8:53 PM, wm4 wrote:
> > > On Wed, 26 Apr 2017 20:09:58 +0700
> > > Muhammad Faiz wrote:
> > >
> > >> On Wed, Apr 26, 2017 at 5:34 PM, wm4 wrote:
>
Thanks for the review, new fix checks av_dict_set return.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Signed-off-by: Micah Galizia
---
libavformat/http.c | 212 +++--
1 file changed, 155 insertions(+), 57 deletions(-)
diff --git a/libavformat/http.c b/libavformat/http.c
index 293a8a7204..58fc3902ab 100644
--- a/libavformat/http.c
+++ b/libavformat/
This seems to be a regression introduced when filtergraph initialization
related changes were passed. The below commit and its follow up seems to have
caused the issue. I am looking to fix this. Please let us know if you have any
suggestions in mind. Thanks
https://github.com/FFmpeg/FFmpeg/comm
On Wed, 26 Apr 2017, Ronald S. Bultje wrote:
Hi,
On Wed, Apr 26, 2017 at 2:20 PM, Muhammad Faiz wrote:
On Wed, Apr 26, 2017 at 10:34 PM, Ronald S. Bultje
wrote:
> Hi,
>
> On Wed, Apr 26, 2017 at 1:21 AM, Muhammad Faiz wrote:
>
>> On Wed, Apr 26, 2017 at 4:09 AM, wm4 wrote:
>> > On Tue,
Timo,
> Also, the same command line, but with -bf 1 or any higher number causes:
> [h264_nvenc @ 0x2c788c0] EncodePicture failed!: no encode device (1)
>
> This is not a new issue, it is happening ever since. It only happens when
> -hwaccel cuvid is specified.
> It's not an issue with the CUDA F
Thanks, patch looks fine to me now.
While testing, I came across some very weird behavior:
The following commandline:
./ffmpeg -hwaccel cuvid -c:v h264_cuvid -i test.mkv -an -sn -c:v h264_nvenc
-preset slow -qp 22 -bf 0 -f null -
Sometimes, it runs into the following error:
[h264_nvenc @ 0x3f7d
---
libavformat/dashenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 6232c70..fe1d6c2 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -433,7 +433,7 @@ static void format_date_now(char *buf, int size)
On Thu, 27 Apr 2017 01:20:53 +0700
Muhammad Faiz wrote:
> On Wed, Apr 26, 2017 at 10:34 PM, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Wed, Apr 26, 2017 at 1:21 AM, Muhammad Faiz wrote:
> >
> >> On Wed, Apr 26, 2017 at 4:09 AM, wm4 wrote:
> >> > On Tue, 25 Apr 2017 23:52:04 +0700
> >> > Mu
On Thu, 27 Apr 2017 01:41:04 +0700
Muhammad Faiz wrote:
> On Wed, Apr 26, 2017 at 8:53 PM, wm4 wrote:
> > On Wed, 26 Apr 2017 20:09:58 +0700
> > Muhammad Faiz wrote:
> >
> >> On Wed, Apr 26, 2017 at 5:34 PM, wm4 wrote:
> >> > On Wed, 26 Apr 2017 17:16:05 +0700
> >> > Muhammad Faiz wrote:
On 4/26/2017 2:46 AM, Aaron Levinson wrote:
> On 4/24/2017 3:47 PM, James Almer wrote:
>> Free coded_frame, coded_side_data and unref hw_device_ctx to prevent
>> potential leaks.
>>
>> Signed-off-by: James Almer
>> ---
>> libavcodec/options.c | 15 +++
>> 1 file changed, 15 insertions
Signed-off-by: James Almer
---
libavformat/concatdec.c | 86 +++--
1 file changed, 26 insertions(+), 60 deletions(-)
diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index dd52e4d366..97ef41e3fc 100644
--- a/libavformat/concatdec.c
+++ b/
Hi,
On Wed, Apr 26, 2017 at 2:20 PM, Muhammad Faiz wrote:
> On Wed, Apr 26, 2017 at 10:34 PM, Ronald S. Bultje
> wrote:
> > Hi,
> >
> > On Wed, Apr 26, 2017 at 1:21 AM, Muhammad Faiz wrote:
> >
> >> On Wed, Apr 26, 2017 at 4:09 AM, wm4 wrote:
> >> > On Tue, 25 Apr 2017 23:52:04 +0700
> >> > M
On Wed, Apr 26, 2017 at 8:53 PM, wm4 wrote:
> On Wed, 26 Apr 2017 20:09:58 +0700
> Muhammad Faiz wrote:
>
>> On Wed, Apr 26, 2017 at 5:34 PM, wm4 wrote:
>> > On Wed, 26 Apr 2017 17:16:05 +0700
>> > Muhammad Faiz wrote:
>> >
>> >> This should fix Ticket6349
>> >>
>> >> Since 383057f8e744efeaaa36
On Wed, Apr 26, 2017 at 10:34 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Wed, Apr 26, 2017 at 1:21 AM, Muhammad Faiz wrote:
>
>> On Wed, Apr 26, 2017 at 4:09 AM, wm4 wrote:
>> > On Tue, 25 Apr 2017 23:52:04 +0700
>> > Muhammad Faiz wrote:
>> >
>> >> when frame is received, not from other threads.
Just pinging in case this got lost somewhere.
On 21 April 2017 at 00:01, Lucas Cooper wrote:
> Does this need any more work or explanation?
>
> On 19 Apr. 2017 7:32 am, "Lucas Cooper" wrote:
>
>> Michael's right. The problem is that NaN is casted to an int, resulting
>> in rate having undefined
This is a port of libavutil/tests/float_dsp.c
Signed-off-by: James Almer
---
tests/checkasm/Makefile| 1 +
tests/checkasm/checkasm.c | 20 +++
tests/checkasm/checkasm.h | 4 +
tests/checkasm/float_dsp.c | 302 +
tests/fate/checkasm.mak|
On Wed, 26 Apr 2017 11:34:22 -0400
"Ronald S. Bultje" wrote:
> Hi,
>
> On Wed, Apr 26, 2017 at 1:21 AM, Muhammad Faiz wrote:
>
> > On Wed, Apr 26, 2017 at 4:09 AM, wm4 wrote:
> > > On Tue, 25 Apr 2017 23:52:04 +0700
> > > Muhammad Faiz wrote:
> > >
> > >> when frame is received, not from
Hi,
On Wed, Apr 26, 2017 at 1:21 AM, Muhammad Faiz wrote:
> On Wed, Apr 26, 2017 at 4:09 AM, wm4 wrote:
> > On Tue, 25 Apr 2017 23:52:04 +0700
> > Muhammad Faiz wrote:
> >
> >> when frame is received, not from other threads.
> >>
> >> Should fix fate failure with THREADS>=4:
> >> make fate-h
> On Apr 26, 2017, at 2:37 AM, Paul B Mahol wrote:
>
> On 4/26/17, Dave Rice wrote:
>>
>>
>> I'm curious why floats are used for x,y coordinates within a frame rather
>> than integers.
>
> So it the position be set relatively. And for similar results for
> different resolutions.
Having been
On Wed, 26 Apr 2017 20:09:58 +0700
Muhammad Faiz wrote:
> On Wed, Apr 26, 2017 at 5:34 PM, wm4 wrote:
> > On Wed, 26 Apr 2017 17:16:05 +0700
> > Muhammad Faiz wrote:
> >
> >> This should fix Ticket6349
> >>
> >> Since 383057f8e744efeaaa3648a59bc577b25b055835, framequeue may
> >> generate unal
On Wed, Apr 26, 2017 at 05:16:05PM +0700, Muhammad Faiz wrote:
> This should fix Ticket6349
>
> Since 383057f8e744efeaaa3648a59bc577b25b055835, framequeue may
> generate unaligned frame data.
>
> Signed-off-by: Muhammad Faiz
> ---
> libavcodec/libmp3lame.c | 13 +
> 1 file changed,
On Tue, Apr 25, 2017 at 03:07:49PM -0300, James Almer wrote:
> On 4/11/2017 6:11 PM, James Almer wrote:
> > This is a port of libavutil/tests/float_dsp.c
> >
> > Signed-off-by: James Almer
> > ---
> > tests/checkasm/Makefile| 1 +
> > tests/checkasm/checkasm.c | 20 +++
> > tests/checkas
On Wed, Apr 26, 2017 at 5:34 PM, wm4 wrote:
> On Wed, 26 Apr 2017 17:16:05 +0700
> Muhammad Faiz wrote:
>
>> This should fix Ticket6349
>>
>> Since 383057f8e744efeaaa3648a59bc577b25b055835, framequeue may
>> generate unaligned frame data.
>>
>> Signed-off-by: Muhammad Faiz
>> ---
>> libavcodec/
On Wed, Apr 26, 2017 at 07:55:59AM +, Saverio Blasi wrote:
> Hello,
>
> We have recently circulated this new version (see below) of our patch for
> integrating our HEVC Turing codec with FFmpeg. Assuming that there are no
> more requests for changes, we would like to understand what is the t
On Tue, Apr 25, 2017 at 04:37:57PM -0700, Pal Azzo wrote:
> Hi,
>
> I'm having trouble decoding this clusterfuzz report:
> https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=713
>
> Was trying to figure out if 2.8.11 is vulnerable. It's not clear which
> commit was the fix, but it looks like n
On Wed, 26 Apr 2017 17:16:05 +0700
Muhammad Faiz wrote:
> This should fix Ticket6349
>
> Since 383057f8e744efeaaa3648a59bc577b25b055835, framequeue may
> generate unaligned frame data.
>
> Signed-off-by: Muhammad Faiz
> ---
> libavcodec/libmp3lame.c | 13 +
> 1 file changed, 9 ins
On Tue, Apr 25, 2017 at 9:42 PM, Kyle Swanson wrote:
> Hi,
>
> On Sun, Jan 29, 2017 at 11:54 AM, Nicolas George wrote:
>>
>> Le decadi 10 pluviôse, an CCXXV, Muhammad Faiz a écrit :
>> > LGTM
>>
>> Thanks, pushed.
>>
>> Regards,
>>
>> --
>> Nicolas George
>>
>> _
This should fix Ticket6349
Since 383057f8e744efeaaa3648a59bc577b25b055835, framequeue may
generate unaligned frame data.
Signed-off-by: Muhammad Faiz
---
libavcodec/libmp3lame.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/libavcodec/libmp3lame.c b/libavcode
> With this new -bf related issue, I'm not so sure about that anymore though,
> and I'm wondering if something in ffmpeg corrupts memory somewhere, somehow,
> when -bf is set.
Just wanted to let it running in a loop for a while, and apparently adding -t
5, 10, 30, or basically any value of time
Thanks, patch looks fine to me now.
While testing, I came across some very weird behavior:
The following commandline:
./ffmpeg -hwaccel cuvid -c:v h264_cuvid -i test.mkv -an -sn -c:v h264_nvenc
-preset slow -qp 22 -bf 0 -f null -
Sometimes, it runs into the following error:
[h264_nvenc @ 0x3f7d8
Fixes Coverity CID: 1405135
Signed-off-by: Steven Liu
---
libavformat/hlsenc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 3ec0f330fb..b7aafb73da 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -394
Hello,
We have recently circulated this new version (see below) of our patch for
integrating our HEVC Turing codec with FFmpeg. Assuming that there are no more
requests for changes, we would like to understand what is the timeline for
integration within the project.
Thanks a lot,
All the best
34 matches
Mail list logo
