ok
On 5/31/19, Marton Balint wrote:
> Signed-off-by: Marton Balint
> ---
> doc/filters.texi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 4fdcfe919e..e2cbc373d2 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
>
On 5/31/19, Carl Eugen Hoyos wrote:
> Am Do., 30. Mai 2019 um 19:38 Uhr schrieb Nick Renieris :
>
>> diff --git a/libavcodec/tiff.h b/libavcodec/tiff.h
>> index 4b08650108..81913c6b1a 100644
>> --- a/libavcodec/tiff.h
>> +++ b/libavcodec/tiff.h
>> @@ -20,7 +20,7 @@
>>
>> /**
>> * @file
>> - * T
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Saturday, June 1, 2019 6:12 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] avfilter/vf_gblur: add x86 SIMD
Fixes:
13579/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG1_V4L2M2M_fuzzer-5753560726241280
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/v4l2_m2m_dec.c | 4
1 file changed, 4
Hi
Anyone has experience compiling ffmpeg with clang LTO before ? I tried
./configure --cc=clang --cxx=clang++ --enable-lto and it did not work.
Thanks
-Adrian
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffm
Am Sa., 1. Juni 2019 um 17:45 Uhr schrieb Adrian Tong
:
> Anyone has experience compiling ffmpeg with clang LTO before ? I tried
> ./configure --cc=clang --cxx=clang++ --enable-lto and it did not work.
cxx should never be needed.
"did not work" is not a useful problem description...
(clang is de
Hello,
I'm trying to play some realtime video sources (web/IP cam) using WebRTC
in a browser. I'm sending RTP stream via Janus gateway using VP9 codec,
hardware transcoded using ffmpeg.
Everything works fine except random frame corruption happening around
moving objects, portions of frame "
On Wed, Mar 27, 2019 at 2:09 PM Remita Amine wrote:
>
> fixes #7801
>
> Signed-off-by: Remita Amine
This seems to fix switching the cipher suite, and quickly looking at
the gnutls API docs this seems to be the way to do it.
Just tested this with the following as I got a report that opening
Face
On Sat, 1 Jun 2019, Paul B Mahol wrote:
ok
Thanks, applied.
Regards,
Marton
On 5/31/19, Marton Balint wrote:
Signed-off-by: Marton Balint
---
doc/filters.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 4fdcfe919e.
Hi,
On Sat, Jun 1, 2019 at 8:35 PM Alex Protasenko wrote:
>
> Hello,
>
>
> I'm trying to play some realtime video sources (web/IP cam) using WebRTC
> in a browser. I'm sending RTP stream via Janus gateway using VP9 codec,
> hardware transcoded using ffmpeg.
>
> Everything works fine except random
Jan,
Yes, that's the one, the latest draft I believe. The descriptor byte is
the bare minimum required for VP9, which could optionally be followed by
one or two byte serial picture ID (used by receiver to identify
problematic frames in its RTCP feedback to the sender), and some more
opaque s
Hi,
On 01.06.19 19:35, Alex Protasenko wrote:
Hello,
I'm trying to play some realtime video sources (web/IP cam) using
WebRTC in a browser. I'm sending RTP stream via Janus gateway using
VP9 codec, hardware transcoded using ffmpeg.
Everything works fine except random frame corruption happeni
Fixes: Null-dereference READ in av_malloc
Fixes:
15002/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_THP_fuzzer-5643474625363968
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/mjpegdec.c
The reasons are cosmetics and preparation for future patches that will
have even more cases.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/startcode.c | 37 +++--
1 file changed, 19 insertions(+), 18 deletions(-)
diff --git a/libavcodec/startcode.c b/libavcode
ff_startcode_find_candidate_c already checked multiple bytes for zeros at
once if HAVE_FAST_UNALIGNED is true; up until now the other case checked
all bytes one by one. This has been modified: A few bytes are checked
until alignment is reached from which point on several bytes can be
checked at onc
This patch is about improving the startcode search in
libavcodec/startcode.c; this is used by the H.264 and the VC-1 parsers.
(In this context, "startcode" always means the MPEG-1/2/4, H.264/5,
VC-1 startcode 0x00 0x00 0x01, potentially with another leading zero.)
There are currently three things t
Up until now, the bitmasks used to initially find out when one needs
to take a closer look and search for startcodes were rather primitive:
If a block (of four or eight bytes, depending on the system) contained a
zero, it was treated as a target for closer inspection.
This can be improved: Using th
Until now the function ff_startcode_find_candidate_c did not really
search for startcodes (the startcode 0x00 0x00 0x01 (used in
MPEG-1/2/4, VC-1 and H.264/5) is the only startcode meant here). Instead
it searched for zero bytes and returned the earliest position of a zero
byte. This of course led
Up until now ff_startcode_find_candidate_c could overread; it relied on
zero-padding after the buffer in order to function correctly. This has
been changed: No overreads occur any more.
The ultimate goal behind all this is to create a high-performance
function for searching of startcodes that can b
Fixes: Timeout (18sec -> 7sec)
Fixes:
14835/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WCMV_fuzzer-5646714897170432
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/wcmv.c | 3 +++
1 fi
On Wed, 22 May 2019, Andreas Håkon wrote:
Hi,
Patch to generate aligned Teletext PES packets using the MPEG-TS muxer
when the TS header contains data.
The code that generates the PES packets for Teletext data aligns the PES packets
with the boundaries of the TS packets. The strategy used i
21 matches
Mail list logo
