Fixes: Timeout
Fixes:
10385/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFV1_fuzzer-5689206987292672
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/ffv1dec_template.c | 5 +
1 file
> 在 2018年8月15日，上午2:37，Pedro Arthur 写道：
>
> Patch pushed.
How should i test it?
bash generate_datasets.sh
(py3k) [root@onvideo sr]# ls
logdir/srcnn_batch_32_lr_1e-3_decay_adam/train/model_100*
logdir/srcnn_batch_32_lr_1e-3_decay_adam/train/model_100.ckpt.data-0-of-1
> 在 2018年10月8日，上午10:55，lance.lmw...@gmail.com 写道：
>
> From: Limin Wang
>
> ---
> libavcodec/libdavs2.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/libdavs2.c b/libavcodec/libdavs2.c
> index aa14782..91ad7a4 100644
> --- a/libavcodec/libdavs2.c
> +++
1. Old logic meaned: everywhere, except Windows, ffmpeg has to use HW
acceleration, but on Windows ffmpeg has to use (unavailable) software
encode by default
2. Software encode is available only if you provide corresponding
software MediaSDK library, which isn't provided with ffmpeg. More
From: Limin Wang
---
libavcodec/libdavs2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/libdavs2.c b/libavcodec/libdavs2.c
index aa14782..91ad7a4 100644
--- a/libavcodec/libdavs2.c
+++ b/libavcodec/libdavs2.c
@@ -88,7 +88,7 @@ static int
From: root
---
libavformat/tcp.c | 16
libavutil/dns_cache.c | 28 +++-
libavutil/dns_cache.h | 6 +++---
3 files changed, 30 insertions(+), 20 deletions(-)
diff --git a/libavformat/tcp.c b/libavformat/tcp.c
index d2de743..6515309 100644
---
2018-10-08 21:59 GMT+02:00, Timo Rothenpieler :
>>> So, to be able to use these hardware compatible formats, we need
>>> definitions for them in ffmpeg. Right now, I need this for nvdec,
>>> but Vulkan also uses the same format definitions.
>>
>> Sorry if this was already done and I forgot but
2018-10-08 23:15 GMT+02:00, Daniel Molkentin :
> On 08.10.2018 21:00, Carl Eugen Hoyos wrote:
>> 2018-10-08 9:21 GMT+02:00, Moritz Barsnick :
>>
>>> Adding options (and changing output line format?) might also warrant a
>>> micro-version bump of lavfi
>>
>> It does.
>> Even more so for the changed
On 08.10.2018 21:00, Carl Eugen Hoyos wrote:
> 2018-10-08 9:21 GMT+02:00, Moritz Barsnick :
>
>> Adding options (and changing output line format?) might also warrant a
>> micro-version bump of lavfi
> It does.
> Even more so for the changed output line...
If you point me to where it needs bumping,
So, to be able to use these hardware compatible formats, we need
definitions for them in ffmpeg. Right now, I need this for nvdec,
but Vulkan also uses the same format definitions.
Sorry if this was already done and I forgot but please explain why
you cannot use YUV444P16 for this use-case.
If
2018-10-07 18:03 GMT+02:00, Omer Iqbal :
> I am developing a video streaming mobile application. In order to support
> multiple orientations, I am currently using h.264's SEI Display Orientation
> message in my H.264 bitstream. (For more context, my bitstream is
> transported over RTMP and
On 08/10/2018 19:52, Carl Eugen Hoyos wrote:
> Please also mention ticket #7083 in the commit message.
>
> Sorry for my other mail, thank you for testing again!
Added locally, thanks.
Wasn't aware of that bug; could have saved me 30 mins of printf debugging.
- Derek
2018-10-08 9:21 GMT+02:00, Moritz Barsnick :
> Adding options (and changing output line format?) might also warrant a
> micro-version bump of lavfi
It does.
Even more so for the changed output line...
Carl Eugen
___
ffmpeg-devel mailing list
2018-10-08 17:36 GMT+02:00, Derek Buitenhuis :
> If we don't copy this value first, it is seen as 0 by
> h264_slice_header_init,
> due to zero-allocation of the new context, triggering an old hack that
> multiplied the denominator by 2 for files produced by old x264 versions, but
> only if more
On 10/8/2018 3:45 PM, Derek Buitenhuis wrote:
> On 08/10/2018 19:23, Carl Eugen Hoyos wrote:
>> I cannot reproduce ticket #7475 (it says "framerate num 30 den 1"
>> no matter how many threads I use, tested with up to 8), and - more
>> related to this patch - the sample from ticket #7475 reaches
On 08/10/2018 19:23, Carl Eugen Hoyos wrote:
> I cannot reproduce ticket #7475 (it says "framerate num 30 den 1"
> no matter how many threads I use, tested with up to 8), and - more
> related to this patch - the sample from ticket #7475 reaches neither
> line 358 nor line 400 in h264_slice.c here
2018-10-08 12:53 GMT+02:00, tugouxp <13824125...@163.com>:
> did the doby ac3 decoder/encoder on ffmpeg implementation
> need licencesed on commercial use?
You are only allowed to distribute binaries based on FFmpeg
if you follow the GPL or the LGPL, both require that you allow
your users to
2018-10-08 16:12 GMT+02:00, Martin Vignali :
> Resend previous patch (from July)
I didn't test but the patchset looks very useful to me, thank you!
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
2018-10-08 17:36 GMT+02:00, Derek Buitenhuis :
> If we don't copy this value first, it is seen as 0 by
> h264_slice_header_init,
> due to zero-allocation of the new context, triggering an old hack that
> multiplied the denominator by 2 for files produced by old x264 versions, but
> only if more
2018-10-07 19:50 GMT+02:00, Philip Langdale :
> Currently, ffmpeg defines a set of YUV444P formats for use where
> the bits-per-pixel are between 8 and 16 bits. In these formats,
> the bits are packed in the MSBs of the 16 bits of available storage.
>
> On the other hand, all the hardware vendors
Hello,
Patch in attach port inline asm shuffle 2103 func (mmx/mmxext) to external
asm
and remove the inline asm version
Martin
0001-swscale-x86-rgb2rgb-port-shuffle2103-to-external-asm.patch
Description: Binary data
___
ffmpeg-devel mailing list
If we don't copy this value first, it is seen as 0 by h264_slice_header_init,
due to zero-allocation of the new context, triggering an old hack that
multiplied the denominator by 2 for files produced by old x264 versions, but
only if more than one thread was used.
Fixes #7475.
Signed-off-by:
>
> also there are 2 divisions in this that you can trivially eliminate
> /255 and /65535 (extra precission beyond IEEE float/double could change
> these)
>
> also the whole could be done with fewer floats and no extra complexity
> for example:
> int64_t tmp2 = 16843009LL * i;
>
On Mon, 8 Oct 2018 11:55:09 +0200
Hendrik Leppkes wrote:
> On Mon, Oct 8, 2018 at 10:40 AM Timo Rothenpieler
> wrote:
> >
> >
> > I don't think it's YUVJ all over again, as it was the exact same bit
> > layout than normal YUV, while this one is actually different.
> >
>
> Its also the same
Hello,
Resend previous patch (from July)
001 : use scantable in prores_data instead of a duplicate one.
Doesn't seems to make speed loss (tested with timer and with -benchmark)
002 :
use for the frame header, primaries, transfert, colorspace like in
proresenc_ks
avoid color shift on some
>On 10/8/18, 4:24 PM, "tugouxp" <13824125...@163.com> wrote:
>
>hi folks:
>
>
> did the doby ac3 decoder/encoder on ffmpeg implementation need licencesed
> on commercial use? i am not a lawyer and i search tons of materials on
> google, but more confused than before.
>so, can i get the
hi folks:
did the doby ac3 decoder/encoder on ffmpeg implementation need licencesed on
commercial use? i am not a lawyer and i search tons of materials on google, but
more confused than before.
so, can i get the answer clearly in here for this question?
thanks for everyones help.
On Mon, Oct 8, 2018 at 10:40 AM Timo Rothenpieler wrote:
>
>
> I don't think it's YUVJ all over again, as it was the exact same bit
> layout than normal YUV, while this one is actually different.
>
Its also the same bit layout as YUV444P16, with one piece of
additional metadata tacked on top -
On 10/7/18, Marton Balint wrote:
> Fixes Coverity CID 1416352.
>
> Signed-off-by: Marton Balint
> ---
> libavfilter/af_asetnsamples.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
OK
___
ffmpeg-devel mailing list
On 08/10/2018 09:24, Marton Balint wrote:
On Sun, 7 Oct 2018, Philip Langdale wrote:
Currently, ffmpeg defines a set of YUV444P formats for use where
the bits-per-pixel are between 8 and 16 bits. In these formats,
the bits are packed in the MSBs of the 16 bits of available storage.
On the
On Sun, 7 Oct 2018, Philip Langdale wrote:
Currently, ffmpeg defines a set of YUV444P formats for use where
the bits-per-pixel are between 8 and 16 bits. In these formats,
the bits are packed in the MSBs of the 16 bits of available storage.
On the other hand, all the hardware vendors have
On Sun, Oct 07, 2018 at 23:19:56 +0200, Daniel Molkentin wrote:
> +Sets the display scale for the loudness. Valid parameters are @code{absolute}
> +(in LUFS) or @code{relative} (LU) relative to the target. This only affects
> the
> +video output, not the summary or continous log output.
On Sun, Oct 07, 2018 at 23:19:55 +0200, Daniel Molkentin wrote:
> +continous log output.
^ continuous
(Sorry, I probably missed this first time round.)
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On Sun, Oct 07, 2018 at 23:19:54 +0200, Daniel Molkentin wrote:
> +enum {
> +GAUGE_TYPE_MOMENTARY = 0,
> +GAUGE_TYPE_SHORTTERM = 1,
> +};
> +{ "gauge", "set gauge display type", OFFSET(gauge_type),
> AV_OPT_TYPE_INT, {.i64 = 0 }, 0, INT_MAX, V|F, "gaugetype" },
min and max range
On Sun, Oct 7, 2018 at 7:51 PM Philip Langdale wrote:
>
> Currently, ffmpeg defines a set of YUV444P formats for use where
> the bits-per-pixel are between 8 and 16 bits. In these formats,
> the bits are packed in the MSBs of the 16 bits of available storage.
>
> On the other hand, all the
35 matches
Mail list logo
