On 1/11/2019 12:17 PM, Derek Buitenhuis wrote:
> 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,
Hello,
This fixes an erroneous reference and missing links in the API documentation.
Best regards,
Nicolas Granger
---
libavcodec/avcodec.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 4414853e84..64ba039be2 100644
On Sat, Jan 12, 2019 at 06:25:57PM +0200, Lauri Kasanen wrote:
> On Sat, 12 Jan 2019 14:52:07 +0100
> Michael Niedermayer wrote:
>
> > On Sat, Jan 12, 2019 at 10:47:50AM +0200, Lauri Kasanen wrote:
> > > ./ffmpeg_g -f rawvideo -pix_fmt rgb24 -s hd1080 -i /dev/zero -pix_fmt
> > > yuv420p16be \
>
On 1/12/19, Nicolas George wrote:
> Hendrik Leppkes (12019-01-11):
>> Its everyones right to keep their finances private. Would I be forced
>> to disclose my hourly wages and then determine how long I worked on a
>> patch, just because I did it during my day job? Thats not going to
>> happen.
>>
Signed-off-by: Michael Niedermayer
---
libavcodec/prosumer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/prosumer.c b/libavcodec/prosumer.c
index 3fa9986a38..9143bb1bf4 100644
--- a/libavcodec/prosumer.c
+++ b/libavcodec/prosumer.c
@@ -38,7 +38,7 @@ typedef
Signed-off-by: Michael Niedermayer
---
libavcodec/prosumer.c | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/libavcodec/prosumer.c b/libavcodec/prosumer.c
index 505de71980..3fa9986a38 100644
--- a/libavcodec/prosumer.c
+++ b/libavcodec/prosumer.c
@@
if 0 is encountered in the LUT then decompress() will continue to output 0
bytes but never read more data.
Without a specification it is impossible to say if this is invalid or a feature.
None of the valid prosumer files tested cause a 0 to be read, so it is likely
not a intended feature.
Fixes:
Fixes: Assertion failure
Fixes:
11898/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-5759794191794176
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/tiff.c | 2 +-
1 file
Kyle Swanson (12019-01-11):
> If someone sends a bad patch, we have no obligation to merge it.
Except if they push it themselves after a few hours without review (or
after being rude to somebody to made a review requiring more work).
The disclosure (and review) requirement is especially
Hendrik Leppkes (12019-01-11):
> Its everyones right to keep their finances private. Would I be forced
> to disclose my hourly wages and then determine how long I worked on a
> patch, just because I did it during my day job? Thats not going to
> happen.
>
> To take a line from your post:
> Are
On 11/19/18, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> doc/filters.texi | 27
> libavfilter/Makefile | 1 +
> libavfilter/allfilters.c | 1 +
> libavfilter/vf_maskfun.c | 279 +++
> 4 files changed, 308 insertions(+)
>
2019-01-11 1:07 GMT+01:00, James Almer :
> On 1/10/2019 6:27 PM, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> I don't know how urgent this is and how easily this can be triggered
>> with AVCPBProperties but we had issues with bitrates > INT32MAX in the
>> past, so looking at this code before realizing the
2019-01-11 16:36 GMT+01:00, Derek Buitenhuis :
> On 11/01/2019 14:54, Carl Eugen Hoyos wrote:
>> 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
On Sat, 12 Jan 2019 14:52:07 +0100
Michael Niedermayer wrote:
> On Sat, Jan 12, 2019 at 10:47:50AM +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
2019-01-11 7:17 GMT+01:00, Peter Ross :
> On Fri, Jan 11, 2019 at 03:23:49AM +0100, Carl Eugen Hoyos wrote:
>> 2019-01-11 2:55 GMT+01:00, Carl Eugen Hoyos :
>> > Hi!
>> >
>> > Attached patch fixes ticket #6797, please comment.
>>
>> New patch with 16bit support attached.
>>
>> Please comment, Carl
2019-01-11 15:36 GMT+01:00, Jerome Borsboom :
> The B predictor for 4-MV macroblocks is only out of bounds when
> the A predictor is also out of bounds.
Patch applied.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
2019-01-12 16:46 GMT+01:00, Michael Niedermayer :
> On Sat, Jan 12, 2019 at 04:07:42PM +0100, Carl Eugen Hoyos wrote:
>> 2019-01-04 20:22 GMT+01:00, Michael Niedermayer :
>>
>> > +static void scaledown(uint8_t *dst, const uint8_t *src, int w)
>> > +{
>> > +int x;
>> > +for (x = 0; x < w -
2019-01-12 16:14 GMT+01:00, Jerome Borsboom :
> 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
> ---
On Sat, Jan 12, 2019 at 04:07:42PM +0100, Carl Eugen Hoyos wrote:
> 2019-01-04 20:22 GMT+01:00, Michael Niedermayer :
>
> > +static void scaledown(uint8_t *dst, const uint8_t *src, int w)
> > +{
> > +int x;
> > +for (x = 0; x < w - 7; x+=8) {
> > +dst[x + 0] = src[2*x + 0];
> > +
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
---
This revision removes a spurious whitespace that was left
2019-01-12 1:46 GMT+01:00, Ronald S. Bultje :
> 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
2019-01-04 20:22 GMT+01:00, Michael Niedermayer :
> +static void scaledown(uint8_t *dst, const uint8_t *src, int w)
> +{
> +int x;
> +for (x = 0; x < w - 7; x+=8) {
> +dst[x + 0] = src[2*x + 0];
> +dst[x + 1] = src[2*x + 2];
> +dst[x + 2] = src[2*x + 4];
> +
On Fri, Jan 04, 2019 at 02:46:29AM +0100, Michael Niedermayer wrote:
> Found-by: jamrial
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/tests/rangecoder.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
i intend to apply this soon unless there are more comments, i did not
On Fri, Jan 04, 2019 at 08:22:36PM +0100, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 2 * 2132811760 cannot be represented in type
> 'int'
> Fixes:
> 11156/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-6237685933408256
>
> Found-by: continuous fuzzing process
>
On Fri, Jan 04, 2019 at 08:22:35PM +0100, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes:
> 11067/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_GDV_fuzzer-5686623711264768
>
> Before change: Executed
> clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_GDV_fuzzer-5686623711264768
> in
On Tue, Dec 25, 2018 at 11:15:22PM +0100, Michael Niedermayer wrote:
> Otherwise it is left to the value from the previous iteration
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/exr.c | 1 +
> 1 file changed, 1 insertion(+)
will apply
[...]
--
Michael GnuPG fingerprint:
On Tue, Dec 25, 2018 at 11:15:21PM +0100, Michael Niedermayer wrote:
> Fixes: Out of memory
> Fixes:
> 11582/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_fuzzer-5730204559867904
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>
On Sat, Jan 12, 2019 at 10:47:50AM +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
./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 tested with an image to video conversion.
Only POWER8 includes 32-bit
On Sat, 12 Jan 2019 01:03:09 +0100
Michael Niedermayer wrote:
> 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.
30 matches
Mail list logo
