Report the detailed log with buf_size in parse_nal_units to provide
more information when picture could not be found.
Match the behaviour in h264_parser.
Signed-off-by: Linjie Fu
---
libavcodec/hevc_parser.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/hevc_par
Signed-off-by: hwrenx
---
libavcodec/libxavs2.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/libxavs2.c b/libavcodec/libxavs2.c
index 52c50a1..2d29427 100644
--- a/libavcodec/libxavs2.c
+++ b/libavcodec/libxavs2.c
@@ -46,7 +46,6 @@ typedef struct XAVS2EContext {
int min_qp;
Signed-off-by: hwrenx
---
libavcodec/libxavs2.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/libxavs2.c b/libavcodec/libxavs2.c
index 2d29427..0ad9ca9 100644
--- a/libavcodec/libxavs2.c
+++ b/libavcodec/libxavs2.c
@@ -109,8 +109,9 @@ static av_cold int xavs2
On Thu, Jan 10, 2019 at 11:55:34AM +0200, Lauri Kasanen wrote:
> ./ffmpeg_g -f rawvideo -pix_fmt rgb24 -s hd1080 -i /dev/zero -pix_fmt
> yuv420p16be \
> -s 1920x1728 -f null -vframes 100 -v error -nostats -
>
> 9-14 bit funcs get about 6x speedup, 16-bit gets about 15x.
> Fate passes, each format
On Fri, 11 Jan 2019 09:56:15 +0100
Michael Niedermayer wrote:
> > +#ifdef __GNUC__
> > +// GCC does not support vmuluwm yet. Bug open.
>
> this should probably be tested by configure similar to how other
> compiler limitations are tested
We can't really test for it, because there is
On 1/11/19, Carl Eugen Hoyos wrote:
> 2018-12-22 21:32 GMT+01:00, Paul B Mahol :
>> On 12/22/18, Steinar H. Gunderson wrote:
>>> On Sat, Dec 22, 2018 at 09:18:11PM +0100, Paul B Mahol wrote:
Unacceptable, I'm not adding another yuv420p variant.
>>>
>>> Well, if returning YCC as YCC is unacce
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Carl Eugen Hoyos
> Sent: Friday, January 11, 2019 1:14 AM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] Improved the performance of 1 decode +
> N filter graphs and adaptive bitrat
Fix ticket #7663
Signed-off-by: Zhong Li
---
libavcodec/qsvenc.c | 37 +++--
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index e3b5a72..0e8229e 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Friday, January 11, 2019 5:35 AM
> To: FFmpeg development discussions and patches
>
> Subject: Re: [FFmpeg-devel] [PATCH]lavc/qsvenc: Clip the bitrate, Intel limits
> it to 65535k
>
> 2019-01-10
2019-01-11 13:09 GMT+01:00, Zhong Li :
> +//libmfx BRC parameters are 16 bits thus maybe overflow, then
> BRCParamMultiplier is needed
> +target_bitrate_kbps = avctx->bit_rate / 1000;
> +max_bitrate_kbps = avctx->rc_max_rate / 1000;
> +brc_param_multiplier = (FFMAX(target_bitrate_kb
2019-01-11 11:18 GMT+01:00, Wang, Shaofei :
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
>> Carl Eugen Hoyos
>> Sent: Friday, January 11, 2019 1:14 AM
>> To: FFmpeg development discussions and patches
>> Subject: Re: [FFmpeg-devel] [PATCH] Improved the performance of
2019-01-11 5:43 GMT+01:00, Li, Zhong :
>> Which libx264 option is / can be hidden?
> This one:
> #if X264_BUILD >= 144
> { "autovariance-biased", "Auto-variance AQ with bias to dark scenes", 0,
> AV_OPT_TYPE_CONST, {.i64 = X264_AQ_AUTOVARIANCE_BIASED}, INT_MIN, INT_MAX,
> VE, "aq_mode" },
> #en
On 11/01/2019 01:15, Michael Niedermayer wrote:
> Fixes: memleak
> Fixes:
> 12244/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_NUV_fuzzer-5099447273390080
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> ---
> libavcodec/nuv.c | 1
2019-01-10 21:14 GMT+01:00, Tom Tan :
> .rodata directive from GAS assembly produces .rodata as read/write for COFF
> object file by default (object file format for Windows), but read only for
> ELF. This change marks it as read only explicitly for COFF.
>
> The issue happens when building Chromium
On 11/01/2019 06:17, Peter Ross wrote:
> the same algorithm exists in libavcodec/mjpegdec.c, with alpha channel
> support.
> i guess it is trivial enough to be duplicated here.
Is it worth deduplicating? Plenty of image formats have CMYK.
- Derek
___
f
On 10/01/2019 23:34, James Almer wrote:
> -if (!float_near_abs_eps(cdst[i], odst[i], FLT_EPSILON)) {
> +if (!float_near_abs_eps(cdst[i], odst[i], 6.2e-05)) {
Can you elaborate a bit more on this? FLT_EPSILON is used correctly here
as far as I can tell, and it is not clear why it fa
On 11/01/2019 00:07, James Almer wrote:
> Probalby correct. bitrate fields in AVCodecContext are all int64_t, and
> AVCPBProperties fields are usually set to those.
Only semi-related: Is it useful to properly clip the bitrate to INT_MAX/INT_MIN
where we set it currently (behind deprecation guards,
On Fri, Jan 11, 2019 at 1:18 PM Carl Eugen Hoyos wrote:
>
> 2019-01-11 13:09 GMT+01:00, Zhong Li :
> > +//libmfx BRC parameters are 16 bits thus maybe overflow, then
> > BRCParamMultiplier is needed
> > +target_bitrate_kbps = avctx->bit_rate / 1000;
> > +max_bitrate_kbps = avctx->rc_ma
On Fri, Jan 11, 2019 at 2:12 PM Derek Buitenhuis
wrote:
>
> On 10/01/2019 23:34, James Almer wrote:
> > -if (!float_near_abs_eps(cdst[i], odst[i], FLT_EPSILON)) {
> > +if (!float_near_abs_eps(cdst[i], odst[i], 6.2e-05)) {
>
> Can you elaborate a bit more on this? FLT_EPSILON is use
2019-01-11 14:25 GMT+01:00, Hendrik Leppkes :
> On Fri, Jan 11, 2019 at 1:18 PM Carl Eugen Hoyos wrote:
>>
>> 2019-01-11 13:09 GMT+01:00, Zhong Li :
>> > +//libmfx BRC parameters are 16 bits thus maybe overflow, then
>> > BRCParamMultiplier is needed
>> > +target_bitrate_kbps = avctx->bit_
Good catch.Yes,that is possible but possibility is smaller than bitrate
since they are in Bytes. I got it too but finally ignored them to make
things simple. Let me send an update version soon.
Carl Eugen Hoyos 于 2019年1月11日周五 下午9:45写道：
> 2019-01-11 14:25 GMT+01:00, Hendrik Leppkes :
> > On Fri,
2019-01-11 14:05 GMT+01:00, Derek Buitenhuis :
> On 11/01/2019 06:17, Peter Ross wrote:
>> the same algorithm exists in libavcodec/mjpegdec.c, with alpha channel
>> support.
>> i guess it is trivial enough to be duplicated here.
>
> Is it worth deduplicating? Plenty of image formats have CMYK.
Yes
The B predictor for 4-MV macroblocks is only out of bounds when
the A predictor is also out of bounds.
Signed-off-by: Jerome Borsboom
---
This patch set fixes the decoding artifacts in the niceday.wmv file
on the samples server.
libavcodec/vc1_pred.c | 13 +++--
1 file changed, 7 insert
The position of the B MV predicitor candidate is slightly different
for the old WMV3 format that is indicated by RES_RTM_FLAG. This patch
fixes the decoding artifacts in the niceday.wmv sample.
Signed-off-by: Jerome Borsboom
---
libavcodec/vc1.c | 5 -
libavcodec/vc1_pred.c | 7 ++-
2019-01-11 15:36 GMT+01:00, Jerome Borsboom :
> The position of the B MV predicitor candidate is slightly different
> for the old WMV3 format that is indicated by RES_RTM_FLAG. This patch
> fixes the decoding artifacts in the niceday.wmv sample.
Cool!
Please mention / test ticket #6641, there are
Hi!
Attached patch that fixes the sample from ticket #3459 cannot be
factorized with the code in mjpegdec (and psd), the representation is
different.
Please comment, Carl Eugen
From c4f9f6248af4b277695b90bf3d2efdc8687d70d3 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Fri, 11 Jan 2019 15
On 11/01/2019 13:28, Hendrik Leppkes wrote:
> Because the computation accumulates more inaccuarcy then FLT_EPSILON
> allows for. That value is really not of that great use. If you have
> two accurate numbers and do one calculation, it may work, but if you
> do a whole bunch of them, the error accum
On 11/01/2019 14:20, Carl Eugen Hoyos wrote:
> Yes, but they can have different representations in FFmpeg.
I suppose the "correct" fix is to put it in swscale, but noone is going
to want to do that.
> Is this patch ok?
No strong opinion. I doubt anyone will want to patch swscale, so I
suppose it
Paul B Mahol (12019-01-11):
> No, pay me first.
That actually explains a lot of things...
But I wonder: were you not payed by somebody for this unfinished
demuxer?
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing
2019-01-11 16:20 GMT+01:00, Nicolas George :
> Paul B Mahol (12019-01-11):
>> No, pay me first.
>
> That actually explains a lot of things...
>
> But I wonder: were you not payed by somebody for this
> unfinished demuxer?
The original unfinished demuxer was posted to the development
mailing list:
Carl Eugen Hoyos (12019-01-11):
> The original unfinished demuxer was posted to the development
> mailing list:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2010-January/086658.html
Ah, good to know. Still, Paul made efforts to resurrect that patch, I
wonder if these efforts were sponsored, and in
2019-01-11 16:26 GMT+01:00, Nicolas George :
> Carl Eugen Hoyos (12019-01-11):
>> The original unfinished demuxer was posted to the development
>> mailing list:
>> https://ffmpeg.org/pipermail/ffmpeg-devel/2010-January/086658.html
>
> Ah, good to know. Still, Paul made efforts to resurrect that pat
Carl Eugen Hoyos (12019-01-11):
> I believe amount is never published (so far at least afair).
I think it should. I wonder what other people think.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
f
On 11/01/2019 14:54, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch that fixes the sample from ticket #3459 cannot be
> factorized with the code in mjpegdec (and psd), the representation is
> different.
Is there a good reason this is RGB0 instead of RGB24?
Other than that, seems OK, if tested
On 11/01/2019 15:26, Nicolas George wrote:
> Carl Eugen Hoyos (12019-01-11):
>> The original unfinished demuxer was posted to the development
>> mailing list:
>> https://ffmpeg.org/pipermail/ffmpeg-devel/2010-January/086658.html
>
> Ah, good to know. Still, Paul made efforts to resurrect that patc
On Fri, 11 Jan 2019 at 15:31 Nicolas George wrote:
> Carl Eugen Hoyos (12019-01-11):
> > I believe amount is never published (so far at least afair).
>
> I think it should. I wonder what other people think.
>
Are you completely out of your mind?
Regards,
Kieran Kunhya
__
Derek Buitenhuis (12019-01-11):
> Irrelevant to whether a patch is acceptable or not to FFmpeg.
In theory, it is, and it should be.
In practice, I have several times suspected a sponsored work was the
reason behind cutting corners, poor design and future planning, bad
reception of review comments
On 11/01/2019 16:23, Nicolas George wrote:
> Derek Buitenhuis (12019-01-11):
>> Irrelevant to whether a patch is acceptable or not to FFmpeg.
>
> In theory, it is, and it should be.
>
> In practice, I have several times suspected a sponsored work was the
> reason behind cutting corners, poor desi
Derek Buitenhuis (12019-01-11):
> I'm sorry, but this just reeks of "your motives aren't pure enough for
> us to trust you" partisanship, which is, frankly, disgusting.
Maybe not enough people have been obnoxious to you during review for you
to feel the problem. Or maybe you have thicker skin.
>
The position of the second MV predicitor candidate is slightly different
for the old WMV3 format indicated by RES_RTM_FLAG. This patch fixes
decoding of niceday.wmv on the samples server.
Fixes: #6641
Signed-off-by: Jerome Borsboom
---
libavcodec/vc1.c | 5 -
libavcodec/vc1_pred.c | 5
On Fri, 11 Jan 2019, 15:31 Nicolas George Carl Eugen Hoyos (12019-01-11):
> > I believe amount is never published (so far at least afair).
>
> I think it should. I wonder what other people think.
>
I don't see why this declaration is helpful or necessary in any way. Can
you elaborate on why it is
Rationale:
* This requirement should offset a little the incentive to neglect
design, code quality and politeness during the review process when
done for money.
* The review process itself and future maintenance burden cost efforts
to the whole project; knowing that sponsorship has been giv
On 11/01/2019 18:21, Nicolas George wrote:
> Signed-off-by: Nicolas George
> ---
> doc/developer.texi | 10 ++
> 1 file changed, 10 insertions(+)
Rather than repeat myself, I'll refer to my previous mails:
* http://ffmpeg.org/pipermail/ffmpeg-devel/2019-January/238740.html
* htt
>2019-01-05 11:44 GMT+01:00, Anton Fedchin :
>> From: Anton Fedchin
>>
>> after 153b36f there is a possibility to crash when trying to get index of
>> a surface which points to nirvana. it may occurs when a stream starts with
>> non i-frame.
>> ---
>> libavcodec/dxva2.c | 10 ++
>> 1 file
Hi,
On Fri, Jan 11, 2019 at 10:21 AM Nicolas George wrote:
>
> Rationale:
>
> * This requirement should offset a little the incentive to neglect
> design, code quality and politeness during the review process when
> done for money.
>
> * The review process itself and future maintenance burden
On Fri, 11 Jan 2019 at 18:38, Derek Buitenhuis
wrote:
> On 11/01/2019 18:21, Nicolas George wrote:
> > Signed-off-by: Nicolas George
> > ---
> > doc/developer.texi | 10 ++
> > 1 file changed, 10 insertions(+)
>
> Rather than repeat myself, I'll refer to my previous mails:
>
> * htt
On Fri, Jan 11, 2019, at 9:21 AM, Nicolas George wrote:
>
> Signed-off-by: Nicolas George
> ---
> doc/developer.texi | 10 ++
> 1 file changed, 10 insertions(+)
I am against this and completely agree with Derek and Kyle.
___
ffmpeg-devel mailin
Kyle Swanson (12019-01-11):
> Lots of people get paid to work on OSS. It's not a conspiracy, that's
> just the way it is. If someone gets paid to write a patch that does
> something useful, great. They got paid, and FFmpeg is better. If
> someone gets paid to write a patch that's no good, we just d
Hi,
On Fri, Jan 11, 2019 at 11:05 AM Nicolas George wrote:
>
> Kyle Swanson (12019-01-11):
> > Lots of people get paid to work on OSS. It's not a conspiracy, that's
> > just the way it is. If someone gets paid to write a patch that does
> > something useful, great. They got paid, and FFmpeg is be
On Fri, Jan 11, 2019 at 8:05 PM Nicolas George wrote:
>
> On the other hand, I have observed in the past patches that were of poor
> quality and suspected they were the result of sponsorships. I would like
> to know. Would you not?
>
Wanting to know and forcing everyone to tell you are two entire
Thanks Carl. Martin made a better fix when porting this to libav which uses
.rdata as section name instead of .rodata with explicit read-only property.
.rdata is read-only in COFF by default. I updated my patch accordingly, thanks
Martin.
Yes, this applies to 32-bit arm for Windows, the new pat
2019-01-11 8:07 GMT+01:00, Anton Fedchin :
>>2019-01-05 11:44 GMT+01:00, Anton Fedchin :
>>> From: Anton Fedchin
>>>
>>> after 153b36f there is a possibility to crash when trying to get index of
>>> a surface which points to nirvana. it may occurs when a stream starts
>>> with
>>> non i-frame.
>>>
Fixes: Timeout
Fixes:
11873/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-5093495044308992
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/lzw.c | 3 +++
1 file changed, 3 inse
> > Signed-off-by: Nicolas George
> > ---
> > doc/developer.texi | 10 ++
> > 1 file changed, 10 insertions(+)
>
> Rather than repeat myself, I'll refer to my previous mails:
>
> * http://ffmpeg.org/pipermail/ffmpeg-devel/2019-January/238740.html
> * http://ffmpeg.org/pipermail/ff
On Fri, Jan 11, 2019 at 11:16:20AM +0200, Lauri Kasanen wrote:
> On Fri, 11 Jan 2019 09:56:15 +0100
> Michael Niedermayer wrote:
>
> > > +#ifdef __GNUC__
> > > +// GCC does not support vmuluwm yet. Bug open.
> >
> > this should probably be tested by configure similar to how other
> >
Hi,
On Thu, Jan 10, 2019 at 2:41 PM Carl Eugen Hoyos wrote:
> 2019-01-07 18:37 GMT+01:00, Ronald S. Bultje :
> > Hi,
> >
> > On Mon, Jan 7, 2019 at 12:22 PM Lauri Kasanen wrote:
> >
> >> On Mon, 7 Jan 2019 12:02:58 -0500
> >> "Ronald S. Bultje" wrote:
> >>
> >> > Have you considered vp8? It ma
On Fri, Jan 11, 2019 at 04:07:33PM +0800, Linjie Fu wrote:
> Report the detailed log with buf_size in parse_nal_units to provide
> more information when picture could not be found.
>
> Match the behaviour in h264_parser.
>
> Signed-off-by: Linjie Fu
> ---
> libavcodec/hevc_parser.c | 2 +-
> 1
On Fri, Jan 11, 2019 at 01:05:38PM +, Derek Buitenhuis wrote:
> On 11/01/2019 01:15, Michael Niedermayer wrote:
> > Fixes: memleak
> > Fixes:
> > 12244/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_NUV_fuzzer-5099447273390080
> >
> > Found-by: continuous fuzzing process
> > https://githu
58 matches
Mail list logo
