This is robust for some corner case there is incorrect list1 count
in pps header, but it's a P slice and can be decoded well.
Signed-off-by: Decai Lin
---
libavcodec/h264_parse.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/libavcodec/h264_parse.c b/libavcodec/
On Thu, Jan 24, 2019 at 2:01 PM Karthick J wrote:
>
> In streaming mode mp4 trailer is not required for playout.
> ---
> libavformat/dashenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 9c90cf17e5..6299e179c2 1006
On 1/30/2019 10:20 PM, Chris Cunningham wrote:
>>
And this definitely means there's a bug elsewhere. This parser should
have not been used for codecs ids other than GSM and GSM_MS. That's
precisely what this assert() is making sure of.
>>>
>>> I'll take a closer look at how this
On Wed, Jan 30, 2019 at 10:24 PM Carl Eugen Hoyos wrote:
>
> 2019-01-30 11:56 GMT+01:00, Jun Zhao :
> > Remove the pdiff_lut_scale in nlmeans
>
> This sentence is very misleading.
>
> > and this change will avoid
> > using pdiff_lut_scale in the exp table search in nlmean_slice, it's will
> > impr
>
> >> And this definitely means there's a bug elsewhere. This parser should
> >> have not been used for codecs ids other than GSM and GSM_MS. That's
> >> precisely what this assert() is making sure of.
> >>
> >
> > I'll take a closer look at how this parser was selected.
>
Ok, here are full detai
Changes 19sec to 10ms (12559) runtime, 17sec to 177ms (12570)
Fixes: Timeout
Fixes:
12559/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AC3_fuzzer-5666516266123264
Fixes:
12561/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AC3_FIXED_fuzzer-5682923041193984
Fixes:
12570/clusterfuzz-testca
2019-01-30 16:57 GMT+01:00, Yannick Poirier :
> ---
> libavformat/rtsp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> index ceb770a3a4..4899e4e790 100644
> --- a/libavformat/rtsp.c
> +++ b/libavformat/rtsp.c
> @@ -480,7 +480,7 @
On Thu, Jan 17, 2019 at 09:45:04PM +, Derek Buitenhuis wrote:
> On 15/01/2019 21:24, Michael Niedermayer wrote:
> > Heres a better patch which may work with seeking as long as there are only
> > 2 files concatenated
> >
> > i think completely discarding the parts after the concatenation would
From: mptcultist
---
libavformat/mov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 9b9739f788..c222582886 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4933,7 +4933,7 @@ static int mov_read_trun(MOVContext *c, AVIOC
From: mptcultist
fixes an issue where if the video size was very specific, ffmpeg would hang
from not filling the sidx_pts for all streams, due to not reading the last sidx
lump. for #7572
---
libavformat/mov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mo
From: Alexey Safronov
It slightly improves the readability of the code
---
.gitattributes | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.gitattributes b/.gitattributes
index 5a19b963b6..ca7879c8a6 100644
--- a/.gitattributes
+++ b/.gitattributes
@@ -1,2 +1,2 @@
-*.pnm -diff
---
libavformat/rtsp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index ceb770a3a4..4899e4e790 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -480,7 +480,7 @@ static void sdp_parse_line(AVFormatContext *s,
SDPParseState
On 1/30/2019 6:44 PM, Chris Cunningham wrote:
> On Wed, Jan 30, 2019 at 1:40 PM James Almer wrote:
>
>> Parsers can't return negative values, only the output packet size. For
>> the purpose of errors, they usually return the entire untouched packet
>> size.
>>
>
> Understood. Is this documented
On Wed, Jan 30, 2019 at 1:40 PM James Almer wrote:
> Parsers can't return negative values, only the output packet size. For
> the purpose of errors, they usually return the entire untouched packet
> size.
>
Understood. Is this documented somewhere? I noted the comment in
av_paser_parse2(), "/* W
On Mon, Jan 28, 2019 at 12:53:22AM +0100, Michael Niedermayer wrote:
> Fixes: Infinite loop
>
> Found-by: Michael Hanselmann
> Reviewed-by: Michael Hanselmann
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/rtsp.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
will apply p
On Wed, Jan 23, 2019 at 02:10:18AM +0100, Michael Niedermayer wrote:
> We assume that if the compressed size is bigger than if each byte is encoded
> in a single raw packet
> that the data is invalid.
>
> Fixes: Out of memory
> Fixes:
> 12208/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RAS
On 1/30/2019 6:27 PM, chcunningham wrote:
> Return replaces an assert0. libfuzzer generated a testcase that
> triggered this assert (codec=0), causing a crash of chrome's renderer.
> ---
> libavcodec/gsm_parser.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/
chcunningham (12019-01-30):
> Return replaces an assert0. libfuzzer generated a testcase that
> triggered this assert (codec=0), causing a crash of chrome's renderer.
> ---
> libavcodec/gsm_parser.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/gsm_parser.c b
2019-01-30 22:27 GMT+01:00, chcunningham :
> Return replaces an assert0. libfuzzer generated a testcase that
> triggered this assert (codec=0), causing a crash of chrome's renderer.
Wouldn't this indicate a bug somewhere else?
Carl Eugen
___
ffmpeg-dev
Return replaces an assert0. libfuzzer generated a testcase that
triggered this assert (codec=0), causing a crash of chrome's renderer.
---
libavcodec/gsm_parser.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/gsm_parser.c b/libavcodec/gsm_parser.c
index 1054a30ca9.
On Sat, Jan 19, 2019 at 09:12:41PM -0300, James Almer wrote:
> On 1/19/2019 7:54 PM, Michael Niedermayer wrote:
> > On Sat, Jan 19, 2019 at 04:11:07PM -0300, James Almer wrote:
> >> On 1/19/2019 4:08 PM, Michael Niedermayer wrote:
> >>> On Sat, Jan 19, 2019 at 03:53:55PM -0300, James Almer wrote:
>
2019-01-27 20:15 GMT+01:00, Dilshod Mukhtarov :
> New version, which uses integer arithmetics
Patch applied.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
2019-01-27 20:14 GMT+01:00, Dilshod Mukhtarov :
>
> On 27.01.2019 22:51, Carl Eugen Hoyos wrote:
>> 2019-01-27 1:45 GMT+01:00, Carl Eugen Hoyos :
>>> 2019-01-26 18:53 GMT+01:00, Dilshod Mukhtarov :
HI, this is the patch that fixes HIDPI support in gdigrab
+double h_dpr; // Horizonta
2019-01-30 18:08 GMT+01:00, Elliott Balsley :
>
>> The BlackMagic Decklink drivers are not system libraries.
>
> Thank you for clarifying about the headers vs the library, I was
> confused about that at first. The GPL definition of system library
> is hard to understand, but I was mostly basing my
2019-01-30 17:03 GMT+01:00, James Almer :
> On 1/30/2019 12:33 PM, Michael Niedermayer wrote:
>> On Sun, Jan 27, 2019 at 10:38:13PM +0100, Carl Eugen Hoyos wrote:
>>> Attached patch was requested in ticket #7220 iiuc.
>>>
>>> Please review, Carl Eugen
>>
>>> avformat.h |8
>>> format
30.01.19 21:02 - James Almer:
> On 1/30/2019 4:19 PM, jannis_wth wrote:
>> 30.01.19 19:51 James Almer:
>>> On 1/30/2019 3:43 PM, jannis_wth wrote:
Okay, so how about this one?
This functionality is important if you don't know the packet size you
are feeding. It allows you to reconstr
On 30 Jan 2019, at 21:15, Carl Eugen Hoyos wrote:
> 2019-01-30 16:14 GMT+01:00, c0re :
>
>> diff --git a/libavformat/icecast.c b/libavformat/icecast.c
>
> We can only read patches made with "git format-patch".
I think this was just to illustrate how easy it
would be to change the behavior to wo
2019-01-30 19:44 GMT+01:00, no pls :
> From: mptcultist
>
> fixes an issue where if the video size was very specific,
> ffmpeg would hang from not filling the sidx_pts for all
> streams, due to not reading the last sidx lump. for #7572
Please wait for a review from John who has promised to look a
2019-01-30 16:14 GMT+01:00, c0re :
> diff --git a/libavformat/icecast.c b/libavformat/icecast.c
We can only read patches made with "git format-patch".
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/f
Hello Deron,
>
> Either way, why would the default behavior ever be to drop even a single
> frame unless specifically aborted by the user? Seems sloppy, and when half
> second fades at the end are dropped it makes the video ending abrupt. The
> current driver would be useful only in a scenario
On Tue, Jan 29, 2019 at 01:08:38PM +0700, Muhammad Faiz wrote:
> On Tue, Jan 29, 2019 at 5:14 AM Michael Niedermayer
> wrote:
> >
> > On Mon, Jan 28, 2019 at 05:07:38PM +0700, Muhammad Faiz wrote:
> > > Fix inconsistent checksums between gbrap10be and gbrap10le
> > > on fate-filter-pixfmts.
> > >
2019-01-30 20:33 GMT+01:00, Paul B Mahol :
> On 1/30/19, Carl Eugen Hoyos wrote:
>> 2019-01-29 22:47 GMT+01:00, Carl Eugen Hoyos :
>>> Attached patch fixes decoding NO_DATA amr-wb frames.
>>
>> Now with patch.
> Are you sure that reference decoder gives complete silence
> for such frames?
Proba
On 1/30/2019 4:19 PM, jannis_wth wrote:
> 30.01.19 19:51 James Almer:
>> On 1/30/2019 3:43 PM, jannis_wth wrote:
>>> Okay, so how about this one?
>>> This functionality is important if you don't know the packet size you
>>> are feeding. It allows you to reconstruct the size.
>>
>> In what scenario
On 1/29/19 2:21 PM, Marton Balint wrote:
On Tue, 29 Jan 2019, Deron wrote:
Hello,
A little history: Many years back I started using a modified version
of an unaccepted Decklink output patch, updated it to work for me,
and reposted a newer patch. Of course, the patch was not accepted for
m
On 1/30/19, Carl Eugen Hoyos wrote:
> 2019-01-29 22:47 GMT+01:00, Carl Eugen Hoyos :
>> Hi!
>>
>> Attached patch fixes decoding NO_DATA amr-wb frames.
>
> Now with patch.
>
> Carl Eugen
>
Are you sure that reference decoder gives complete silence for such frames?
Please use memset.
_
30.01.19 19:51 James Almer:
> On 1/30/2019 3:43 PM, jannis_wth wrote:
>> Okay, so how about this one?
>> This functionality is important if you don't know the packet size you
>> are feeding. It allows you to reconstruct the size.
>
> In what scenario you can't know the size of the AVPacket you're
Karthick J (12019-01-30):
> ---
> libavformat/tee.c | 1 +
> 1 file changed, 1 insertion(+)
Pushed, thanks.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.or
On 1/30/2019 3:43 PM, jannis_wth wrote:
> 30.01.19 18:30 - James Almer:
>> On 1/30/2019 2:19 PM, Nicolas George wrote:
>>> James Almer (12019-01-30):
compat_decode_consumed doesn't look to have any significance when using
the new API. It's working as an accumulator for all bytes consumed
From: mptcultist
fixes an issue where if the video size was very specific, ffmpeg would hang
from not filling the sidx_pts for all streams, due to not reading the last sidx
lump. for #7572
---
libavformat/mov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mov.
> The BlackMagic Decklink drivers are not system libraries.
Thank you for clarifying about the headers vs the library, I was confused about
that at first. The GPL definition of system library is hard to understand, but
I was mostly basing my opinion on this discussion of NVENC. It relies on t
On 1/30/2019 2:19 PM, Nicolas George wrote:
> James Almer (12019-01-30):
>> compat_decode_consumed doesn't look to have any significance when using
>> the new API. It's working as an accumulator for all bytes consumed from
>> all frames and it's never cleared (sounds like a potential overflow for
>
James Almer (12019-01-30):
> compat_decode_consumed doesn't look to have any significance when using
> the new API. It's working as an accumulator for all bytes consumed from
> all frames and it's never cleared (sounds like a potential overflow for
> that matter in long lasting decoding scenarios l
On 1/30/2019 12:53 PM, jannis_wth wrote:
> This patch fixes the issue discussed in ticket #7708.
>
>
> 0001-avcodec-Allow-to-query-number-of-consumed-bytes-usin.patch
>
> From 756b3b59ac491bdbf01de4f399f5eeb74db8861a Mon Sep 17 00:00:00 2001
> From: user
> Date: Wed, 30 Jan 2019 16:48:58 +0100
On 1/30/2019 12:33 PM, Michael Niedermayer wrote:
> On Sun, Jan 27, 2019 at 10:38:13PM +0100, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch was requested in ticket #7220 iiuc.
>>
>> Please review, Carl Eugen
>
>> avformat.h |8
>> format.c |4 ++--
>> hls.c |2 +-
This patch fixes the issue discussed in ticket #7708.
>From 756b3b59ac491bdbf01de4f399f5eeb74db8861a Mon Sep 17 00:00:00 2001
From: user
Date: Wed, 30 Jan 2019 16:48:58 +0100
Subject: [PATCH 1/1] avcodec: Allow to query number of consumed bytes using
the new API
Currently the only way to get the
On Sun, Jan 27, 2019 at 10:38:13PM +0100, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch was requested in ticket #7220 iiuc.
>
> Please review, Carl Eugen
> avformat.h |8
> format.c |4 ++--
> hls.c |2 +-
> utils.c|4 ++--
> 4 files changed, 9 insertions(
On Tue, 2019-01-22 at 22:06 +0100, Marvin Scholz wrote:
> On 22 Jan 2019, at 20:29, c0re wrote:
>
> > Hi all,
> >
> > Today as I tried to implement transcoding a videofeed to an
> > icecast
> > audio-only stream I have encountered some behavior that, in my
> > opionion, leaves room for improvemen
2019-01-30 11:56 GMT+01:00, Jun Zhao :
> Remove the pdiff_lut_scale in nlmeans
This sentence is very misleading.
> and this change will avoid
> using pdiff_lut_scale in the exp table search in nlmean_slice, it's will
> improve the performance about 12%.
Please mention in the commit message that
2019-01-30 1:53 GMT+01:00, Elliott Balsley :
>
>> It is not Blackmagic who does not want you to distribute FFmpeg
>> with their (proprietary) library, it is us who do not allow distribution
>> of FFmpeg binaries that link against Blackmagic libraries.
The wording here was not ideal:
FFmpeg is by d
2019-01-29 22:47 GMT+01:00, Carl Eugen Hoyos :
> Hi!
>
> Attached patch fixes decoding NO_DATA amr-wb frames.
Now with patch.
Carl Eugen
From 0a8c318c49ec358ad646ed601588154cf7d7da37 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Tue, 29 Jan 2019 22:46:37 +0100
Subject: [PATCH] lavc/amrwb
---
libavformat/tee.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/tee.c b/libavformat/tee.c
index ef3b113a47..89a4ceb280 100644
--- a/libavformat/tee.c
+++ b/libavformat/tee.c
@@ -236,6 +236,7 @@ static int open_slave(AVFormatContext *avf, char *slave,
TeeSlave *tee_slave)
On 1/29/19, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes decoding NO_DATA amr-wb frames.
>
> Please comment, Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
You forgot
Remove the pdiff_lut_scale in nlmeans, and this change will avoid
using pdiff_lut_scale in the exp table search in nlmean_slice, it's will
improve the performance about 12%.
Use the profiling cmd like:
perf stat -a -d -r 5 ./ffmpeg -i input -an -vf nlmeans=s=30 -vframes 10 \
-f null /dev/null
wit
Signed-off-by: Ruiling Song
---
This patch depends on the colorspace patchset I sent before
(https://patchwork.ffmpeg.org/patch/11820/)
Although I am still working on some minor functionality,
hope somebody could give some comments about the overall design.
Ruiling
configure
54 matches
Mail list logo
