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
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
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
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
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
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
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
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
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 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
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.
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
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 "
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
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
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
> -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
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
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
>
21 matches
Mail list logo
