On Wed, Jul 24, 2019 at 5:08 PM Gyan wrote:
>
>
>
> On 24-07-2019 01:38 PM, Michael Niedermayer wrote:
> > On Sun, Jul 21, 2019 at 10:31:36PM +0800, Jun Zhao wrote:
> >> From: Jun Zhao
> >>
> >> Document dts_error_threshold option.
> >>
> >> Signed-off-by: Jun Zhao
> >> ---
> >>
On 7/21/19 5:57 PM, Lynne wrote:
> Jul 22, 2019, 12:03 AM by da...@wavpack.com:
>
>> Hi,
>>
>> As I promised late last year, here is a patch to add a WavPack DSD decoder.
>>
>> Thanks!
>>
>> -David Bryant
>>
>> + unsigned char probabilities [MAX_HISTORY_BINS] [256];
>> + unsigned char
Fix ticket: 8037
Signed-off-by: Steven Liu
---
libavformat/hlsenc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 2ade6723f9..51310fb528 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2301,8 +2301,8 @@
On 20/07/2019 00:19, Jarek Samic wrote:
> This filter is the subject of my GSoC project.
>
> This is a video stabilization / deshake filter (name undetermined, feel free
> to discuss) that uses feature
> point matching and RANSAC to determine a camera path, smooths the camera path
> with a
On Fri, Jul 05, 2019 at 01:28:35AM +0200, Michael Niedermayer wrote:
> Fixes: memleak
> Fixes:
> 15528/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_STL_fuzzer-5735993371525120
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>
Fixes: memleak on error path
Fixes:
15984/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5679918412726272
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/mpc.c | 7 +--
1 file
Fixes: null pointer passed as argument 2, which is declared to never be null
Fixes:
16008/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SSA_fuzzer-5650582821404672
(this is a separate issue found in this testcase)
Found-by: continuous fuzzing process
Previous thread:
http://ffmpeg.org/pipermail/ffmpeg-devel/2019-July/246951.html
I added the modifications to the decoder, I ran some tests for performance
and run times are only affected if my flag is enabled.
Decoded 3 different encoded videos 20 times each with and without my debug
flag, here
---
libavcodec/avcodec.h| 1 +
libavcodec/h264dec.c| 37
libavcodec/options_table.h | 1 +
libavutil/Makefile | 2 +
libavutil/frame.h | 6 ++
libavutil/quantization_params.c | 40 +
According to the H.264 specifications, the only NAL units that need to
have four byte startcodes in H.264 Annex B format are SPS/PPS units and
units that start a new access unit. Before af7e953a, the first of these
conditions wasn't upheld as already existing in-band parameter sets
would not
The format of an AVCDecoderConfigurationRecord, the out-of-band
extradata of H.264 in mp4, is as follows: First four bytes containing
version, profile and level, one byte for the length size and one byte
each for the number of SPS, followed by the SPS (each with its own size
field), followed by a
1. Left shifts of negative values are undefined as soon as the sign bit
is involved. Therefore make nal_size an uint32_t and drop the check for
whether it is < 0.
2. The two checks for overreads (whether the length field is contained
in the packet and whether the actual unit is contained in the
Before reading a 16bit size field during parsing of extradata, no check
is performed to make sure that said length field is actually contained
in the extradata. Given that this overread is not dangerous (the extradata
is supposed to be padded), only a comment for it has been added; the error
Currently during parsing the extradata, h264_mp4toannexb checks for
overreads by adding the size of the current unit to the current position
pointer and comparing this to the end position of the extradata. But
pointer comparisons and pointer arithmetic is only defined if it does not
exceed the
On 7/23/2019 9:39 PM, Kieran Kunhya wrote:
>>
>> What was the cause of the slow decoding? Does this actually fix it, or
>> does it just swipe it "under the carpet"?
>> If someone ever found a sample with a different solution, how would they
>> know that they shouldn't just remove this again?
On 7/17/19, Paul B Mahol wrote:
> On 7/15/19, Song, Ruiling wrote:
>>> -Original Message-
>>> From: Song, Ruiling
>>> Sent: Tuesday, July 9, 2019 9:15 AM
>>> To: ffmpeg-devel@ffmpeg.org
>>> Cc: Song, Ruiling
>>> Subject: [PATCH] avfilter/vf_convolution: add x86 SIMD for filter_3x3()
>>>
Michael Niedermayer:
> On Mon, Jul 22, 2019 at 05:27:13AM +0200, Andreas Rheinhardt wrote:
>> 1. Currently during parsing the extradata, h264_mp4toannexb checks for
>> overreads by adding the size of the current unit to the current position
>> pointer and comparing this to the end position of the
There can be at most 31 SPS and 255 PPS in the mp4/Matroska extradata.
Given that each has a size of at most 2^16-1, the length of the output
derived from these parameter sets can never overflow an ordinary 32 bit
integer. So use a simple uint32_t instead of uint64_t and replace the
unnecessary
On Tue, Jul 23, 2019 at 13:49:30 +, Guo, Yejun wrote:
> > Actually, http://git.videolan.org/?p=ffmpeg.git;a=summary is the
> > official repo (or rather its visualization). Github is the secondary
> > repo, a mirror.
>
> thanks Moritz, do you mean that the official repo is not
>
On Sun, Jul 21, 2019 at 02:07:07PM +1000, Peter Ross wrote:
> On Sat, Jul 20, 2019 at 03:51:25PM +0200, Andreas Rheinhardt wrote:
> > Some of the VP3 arrays (namely vp31_intra_y_dequant, vp31_intra_c_dequant
> > and vp31_inter_dequant) are currently declared as array of (const) int8_t
> > despite
On 7/24/19, Fu, Linjie wrote:
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Paul B Mahol
>> Sent: Wednesday, July 24, 2019 17:42
>> To: FFmpeg development discussions and patches > de...@ffmpeg.org>
>> Subject: Re: [FFmpeg-devel]
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Fu, Linjie
> Sent: Saturday, July 20, 2019 00:32
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/phtread_frame: update
>
Theora is forced to be non zero if it is zero and a sample
is asked for, as suggested by reimar
Fixes: Timeout (2min -> 600ms)
Fixes:
15366/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_THEORA_fuzzer-5737849938247680
Found-by: continuous fuzzing process
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Paul B Mahol
> Sent: Wednesday, July 24, 2019 17:42
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
>
Jul 24, 2019, 11:08 AM by mich...@niedermayer.cc:
>
> What did you expect ? IIRC you have asked for whole classes of security
> issues to be not fixed.
>
> Something like that would require a vote and majority of developers.
>
The way I interpret this: "Of course I ignored you, you're mental!",
On Mon, Jul 22, 2019 at 07:07:57AM +0200, Reimar Döffinger wrote:
>
>
> On 22.07.2019, at 01:25, Michael Niedermayer wrote:
>
> > Fixes: Timeout (2min -> 100ms)
> > Fixes:
> > 15366/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_THEORA_fuzzer-5737849938247680
> >
> > Found-by: continuous
Hi,
patch attached.
0001-avfilter-af_dynaudnorm-add-more-descriptive-aliases-.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or
On 7/14/19, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> doc/filters.texi | 44
> libavfilter/Makefile | 1 +
> libavfilter/allfilters.c | 1 +
> libavfilter/asrc_sine.c | 86 ++--
> 4 files changed, 119
From: Nick Renieris
Main image data in DNGs is usually comprised of tiles, each of which is a
Huffman-encoded lossless JPEG.
Tested for ljpeg regressions with:
`ffmpeg -f lavfi -i testsrc=d=1 -vcodec ljpeg test.avi`
`ffmpeg test.avi out.avi`
The modified code in ljpeg_decode_rgb_scan runs
From: Nick Renieris
Used a technique similar to lavc/tdsc.c for invoking the MJPEG decoder.
This commit adds support for:
- DNG tiles
- DNG tile huffman lossless JPEG decoding
- DNG 8-bpp ("packed" as dcraw calls it) decoding
- DNG color scaling [1]
- LinearizationTable tag
- BlackLevel tag
The latest patch is unrelated to the gamma stuff (which in hindsight
isn't accurately implemented, so never mind), it has a regression fix
for z8pf.dng and adds compatibility to the following:
https://www.camerafv5.com/pages/raw-samples.php
https://www.camerafv5.com/pages/nexus6-raw-samples.php
On Tue, Jul 23, 2019 at 04:42:32AM +0200, Lynne wrote:
> Jul 23, 2019, 12:00 AM by mich...@niedermayer.cc:
>
> > On Tue, Jul 23, 2019 at 12:13:51AM +0200, Lynne wrote:
> >
> >> Jul 22, 2019, 10:57 PM by mich...@niedermayer.cc:
> >>
> >> > The dimensions are always 320x200 they are hardcoded in
From: Nick Renieris
Used a technique similar to lavc/tdsc.c for invoking the MJPEG decoder.
This commit adds support for:
- DNG tiles
- DNG tile huffman lossless JPEG decoding
- DNG color scaling [1]
- LinearizationTable tag
- BlackLevel tag
[1]: As specified in the DNG Specification -
> Colors are wrong and I'm pretty sure I know why, that's TODO.
>
Do you plan to implement camera native RGB to CIE XYZ mapping as specified
in DNG Spec 1.4.0.0 Chapter 6 ?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On 7/24/19, Fu, Linjie wrote:
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Gyan
>> Sent: Wednesday, July 24, 2019 12:28
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
>>
Hi,
patch attached.
0001-avcodec-adxenc-add-EOF-header.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Gyan
> Sent: Wednesday, July 24, 2019 12:28
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
> autoscale to disable/enable the default scale
Some example DNGs before/after the gamma correction:
https://i.imgur.com/m3Qgrwb.jpg
https://i.imgur.com/XgggT2h.jpg
These are not full size of course, just screenshots.
Colors are wrong and I'm pretty sure I know why, that's TODO.
Στις Τετ, 24 Ιουλ 2019 στις 12:04 μ.μ., ο/η Nick Renieris
I have a small patch for basic gamma correction, it makes the dark
images look much better.
Should I send it here (if so, just as a single email reply to this?)
or wait until this patchset is merged?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On 24-07-2019 01:38 PM, Michael Niedermayer wrote:
On Sun, Jul 21, 2019 at 10:31:36PM +0800, Jun Zhao wrote:
From: Jun Zhao
Document dts_error_threshold option.
Signed-off-by: Jun Zhao
---
doc/ffmpeg.texi |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git
On Wed, Jul 24, 2019 at 01:39:01AM +0100, Kieran Kunhya wrote:
> >
> > What was the cause of the slow decoding? Does this actually fix it, or
> > does it just swipe it "under the carpet"?
> > If someone ever found a sample with a different solution, how would they
> > know that they shouldn't just
On Wed, Jul 24, 2019 at 01:29:26AM +0200, Reimar Döffinger wrote:
>
>
> On 22.07.2019, at 23:57, Michael Niedermayer wrote:
>
> > The dimensions are always 320x200 they are hardcoded in the demuxer.
> > Hardcode them instead in the decoder.
> >
> > Fixes: Timeout (16sec -> 400ms)
> > Fixes:
=== PROBLEM ===
I was trying to record h264 + aac streams from an RTSP server to mp4 file.
using this command line:
ffmpeg -v verbose -y -i "rtsp:///my_resources" -codec copy -bsf:a
aac_adtstoasc test.mp4
FFmpeg then fail to record audio and output this logs:
[rtsp @ 0xcda1f0] The
On Sun, Jul 21, 2019 at 10:31:36PM +0800, Jun Zhao wrote:
> From: Jun Zhao
>
> Document dts_error_threshold option.
>
> Signed-off-by: Jun Zhao
> ---
> doc/ffmpeg.texi |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> index
On Mon, Jul 22, 2019 at 05:27:13AM +0200, Andreas Rheinhardt wrote:
> 1. Currently during parsing the extradata, h264_mp4toannexb checks for
> overreads by adding the size of the current unit to the current position
> pointer and comparing this to the end position of the extradata. But
> pointer
> -Original Message-
> From: Guo, Yejun
> Sent: Tuesday, July 16, 2019 1:56 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Guo, Yejun
> Subject: [PATCH 4/4] dnn: convert tf.pad to native model in python script, and
> load/execute it in the c code.
>
> since tf.pad is enabled, the conv2d(valid)
On Mon, Jul 22, 2019 at 05:27:12AM +0200, Andreas Rheinhardt wrote:
> There can be at most 31 SPS and 255 PPS in the mp4/Matroska extradata.
> Given that each has a size of at most 2^16-1, the length of the output
> derived from these parameter sets can never overflow an ordinary 32 bit
> integer.
On 7/23/19, David Bryant wrote:
> On 7/23/19 12:47 AM, Paul B Mahol wrote:
>> On 7/23/19, David Bryant wrote:
>>> On 7/21/19 11:23 PM, Paul B Mahol wrote:
On 7/22/19, David Bryant wrote:
> Hi,
>
> As I promised late last year, here is a patch to add a WavPack DSD
> decoder.
Hi,
‐‐‐ Original Message ‐‐‐
On Friday, 28 de June de 2019 10:44, Andreas Håkon
wrote:
> Hi,
> This is a refined version of the initial version for the new “timer” BSF.
> Supersedes: https://patchwork.ffmpeg.org/patch/13699/
Still waiting to receive comments (or acceptance).
Regards.
>Why is "block" not aligned? Does the code for other architectures also use
>unaligned instructions for
>these?
Thank you for reminding me. After checking the struct H264SliceContext and
function call process, 'block' is find out as 16-bit aligned.
There are some refines in this patch, I will
Ensure the address accesed by gssqc1/gslqc1 are 16-bits memory-aligned.
---
libavcodec/mips/simple_idct_mmi.c | 2 +-
libavutil/mips/mmiutils.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/mips/simple_idct_mmi.c
b/libavcodec/mips/simple_idct_mmi.c
On 24.07.2019, at 02:39, Kieran Kunhya wrote:
>>
>> What was the cause of the slow decoding? Does this actually fix it, or
>> does it just swipe it "under the carpet"?
>> If someone ever found a sample with a different solution, how would they
>> know that they shouldn't just remove this again?
52 matches
Mail list logo
