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
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
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 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
> >
> > 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
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
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.
>>>
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
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
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
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
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
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
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
>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
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
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 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
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
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.
>
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):
> 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 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
__
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 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
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
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):
> 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: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:
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
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
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
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
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
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 ++-
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
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
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: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_
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
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 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 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 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
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 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-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
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 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
> 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
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 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
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
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 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
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
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;
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
58 matches
Mail list logo
