From: Andriy Gelman
Reduces buffering latency with low bitrate streams, where
8192 bytes can mean several seconds.
---
libavformat/mpegts.c | 59 +++-
1 file changed, 36 insertions(+), 23 deletions(-)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts
The following are the newly added options:
arnr_max_frames, arnr_strength, aq_mode, denoise_noise_level,
denoise_block_size,
rc_undershoot_pct, rc_overshoot_pct, minsection_pct, maxsection_pct,
frame_parallel,
enable_cdef, and enable_global_motion.
Also added macros for compiling for aom 1.0.0.
On Fri, 2019-03-08 at 15:40 +0800, Zhong Li wrote:
> Using MSDK parser can improve qsv decoder pass rate in some cases
> (E.g:
> sps declares a wrong level_idc, smaller than it should be).
> And it is necessary for adding new qsv decoders such as MJPEG and VP9
> since current parser can't provide e
On Thu, Mar 07, 2019 at 09:31:19PM -0500, Andriy Gelman wrote:
> From: Andriy Gelman
>
> Reduces buffering latency with low bitrate streams, where
> 8192 bytes can mean several seconds.
> ---
> libavformat/mpegts.c | 59 +++-
> 1 file changed, 36 insertion
On Fri, Mar 08, 2019 at 10:26:03AM +0100, Andreas Rheinhardt wrote:
> The earlier code had three flaws:
>
> 1. The case of an unknown-sized element inside a finite-sized element
> (which is against the specifications) was not caught.
>
> 2. The error message wasn't helpful: It compared the length
On 3/8/2019 6:25 AM, Andreas Rheinhardt wrote:
> It is only necessary to zero the initial allocated memory used to store
> the size of laced frames if the block used Xiph lacing. Otherwise no
> unintialized data was ever used, so use av_malloc instead of av_mallocz.
>
> Also use the correct type f
On 3/8/2019 6:25 AM, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/matroskadec.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index 0e3a6890c1..de27d63b17 100644
> --- a/libavformat/matroska
On 3/8/2019 6:25 AM, Andreas Rheinhardt wrote:
> and drop the redundant checks contained in ebml_read_uint and
> ebml_read_sint.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/matroskadec.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/libavformat/mat
On Fri, Mar 08, 2019 at 10:25:59AM +0100, Andreas Rheinhardt wrote:
> When the new incremental parser was introduced, the old parser was
> kept, because the new parser was unable to handle the way SSA packets
> are put into Matroska. But since 2014 (since
> c7d8dbad14ed5fa3c217a4fc1790021d6c0b6416)
On Fri, 8 Mar 2019 at 18:07, Carl Eugen Hoyos wrote:
> 2019-03-08 15:04 GMT+01:00, Tomas Härdin :
> > tor 2019-03-07 klockan 14:42 + skrev Matthew Fearnley:
> >> This consists mostly of the following changes:
> >> - add newly supported pixel formats (RGB555LE, RGB565LE, BGR0)
> >> - select th
2019-03-08 11:36 GMT+01:00, Jing SUN :
> +static void free_buffer(SvtContext *svt_enc)
> +{
> +EB_H265_ENC_INPUT *in_data =
> (EB_H265_ENC_INPUT *)svt_enc->in_buf.pBuffer;
Is the cast necessary?
Or actually: Can't in_data be whatever doesn't produce
a warning?
> +
> +if (in_data)
> +
On Fri, Mar 8, 2019 at 4:39 AM Jing SUN wrote:
> From: Jing Sun
>
> base on patch by Huang, Zhengxu from https://github.com/intel/SVT-HEVC
>
> V4: - Fix the build error with new API in PR#52
> - Fix the encoding hang issue by API change in PR#52
> - Fix the last frame dropping issue
>
On Fri, Mar 08, 2019 at 14:11:30 +0100, Ulf Zibis wrote:
> >> Can some other developer please give me a practical hint how to deal
> >> with private folders not to appear in GIT patches?
[...]
> Are there other possibilities which are directly project-bounded?
Hoe about not committing them in the
fre 2019-03-08 klockan 20:28 +0100 skrev Carl Eugen Hoyos:
> > 2019-03-08 20:10 GMT+01:00, Matthew McKenna :
> > On 3/8/2019 1:36 PM, Tomas Härdin wrote:
> > > fre 2019-03-08 klockan 19:04 +0100 skrev Carl Eugen Hoyos:
> > > > > > > > 2019-03-08 14:20 GMT+01:00, Tomas Härdin :
> > > >
> > > > > Th
2019-03-08 20:10 GMT+01:00, Matthew McKenna :
> On 3/8/2019 1:36 PM, Tomas Härdin wrote:
>> fre 2019-03-08 klockan 19:04 +0100 skrev Carl Eugen Hoyos:
>>> 2019-03-08 14:20 GMT+01:00, Tomas Härdin :
>>>
This adds some HEVC demux tests for mxfdec.c for the
Canon XF705 samples provided by Ma
On 3/8/2019 1:36 PM, Tomas Härdin wrote:
fre 2019-03-08 klockan 19:04 +0100 skrev Carl Eugen Hoyos:
2019-03-08 14:20 GMT+01:00, Tomas Härdin :
This adds some HEVC demux tests for mxfdec.c for the
Canon XF705 samples provided by Matthew McKenna.
I suspect the thing that's most valuable here is
fre 2019-03-08 klockan 19:04 +0100 skrev Carl Eugen Hoyos:
> 2019-03-08 14:20 GMT+01:00, Tomas Härdin :
>
> > This adds some HEVC demux tests for mxfdec.c for the
> > Canon XF705 samples provided by Matthew McKenna.
> > I suspect the thing that's most valuable here is that the
> > codec probing wo
2019-03-08 15:04 GMT+01:00, Tomas Härdin :
> tor 2019-03-07 klockan 14:42 + skrev Matthew Fearnley:
>> This consists mostly of the following changes:
>> - add newly supported pixel formats (RGB555LE, RGB565LE, BGR0)
>> - select the ZMBV format (c->fmt) and bytes per pixel (c->bypp) based on
>>
2019-03-08 14:20 GMT+01:00, Tomas Härdin :
> This adds some HEVC demux tests for mxfdec.c for the
> Canon XF705 samples provided by Matthew McKenna.
> I suspect the thing that's most valuable here is that the
> codec probing works correctly, which it seems to do.
This email is missing the additio
2019-03-08 18:45 GMT+01:00, Michael Niedermayer :
> On Fri, Mar 08, 2019 at 06:33:30PM +0100, Carl Eugen Hoyos wrote:
>> 2019-03-08 17:38 GMT+01:00, Michael Niedermayer :
>> > Fixes: Timeout (34sec -> 12sec)
>>
>> Am I correct that this is the speedup for an invalid input file?
>> Is there a measur
7 Mar 2019, 21:18 by mich...@niedermayer.cc:
> On Wed, Mar 06, 2019 at 07:09:52PM +0100, Lynne wrote:
>
>> A lot of files have CRC included.
>> The CRC only covers 34 bytes at most from the frame but it should still be
>> enough for some amount of error detection.
>>
>> mpegaudiodec_template.c
On Fri, Mar 08, 2019 at 06:33:30PM +0100, Carl Eugen Hoyos wrote:
> 2019-03-08 17:38 GMT+01:00, Michael Niedermayer :
> > Fixes: Timeout (34sec -> 12sec)
>
> Am I correct that this is the speedup for an invalid input file?
> Is there a measurable effect on valid files?
This should speed up valid
2019-03-08 17:38 GMT+01:00, Michael Niedermayer :
> Fixes: Timeout (34sec -> 12sec)
Am I correct that this is the speedup for an invalid input file?
Is there a measurable effect on valid files?
> Fixes:
> 13398/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFV1_fuzzer-5664106709778432
>
> Fou
Fixes: Timeout (34sec -> 12sec)
Fixes:
13398/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFV1_fuzzer-5664106709778432
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/ffv1dec_template.c |
Fixes: Timeout (29sec -> 4sec)
Fixes:
13150/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DIRAC_fuzzer-5690185671507968
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/diracdec.c | 5 -
> > +AVCodec ff_vp9_qsv_decoder = {
> > +.name = "vp9_qsv",
> > +.long_name = NULL_IF_CONFIG_SMALL("VP9 video (Intel
> Quick
> > Sync Video acceleration)"),
> > +.priv_data_size = sizeof(QSVOtherContext),
> > +.type = AVMEDIA_TYPE_VIDEO,
> > +.id
Signed-off-by: Zhong Li
---
Changelog | 1 +
configure | 1 +
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c| 1 +
libavcodec/qsvdec_other.c | 28 +++-
5 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/Changelog
VP9 decoder is supported on Intel kabyLake+ platforms with MSDK Version 1.19+
Signed-off-by: Zhong Li
---
Changelog | 2 +-
configure | 6 ++
libavcodec/allcodecs.c| 1 +
libavcodec/qsv.c | 5 +
libavcodec/qsvdec_other.c | 31 +
Signed-off-by: Zhong Li
---
libavcodec/qsv.c | 4 ++--
libavcodec/qsv_internal.h | 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
index 224bc00ce4..711fd3df1e 100644
--- a/libavcodec/qsv.c
+++ b/libavcodec/qsv.c
@@ -158,7 +158,7 @
Signed-off-by: Zhong Li
---
configure | 10 +-
libavcodec/qsvdec.c | 28 +---
libavcodec/qsvdec.h | 3 ---
3 files changed, 6 insertions(+), 35 deletions(-)
diff --git a/configure b/configure
index bf40c1dcb9..eaa56c07cf 100755
--- a/configure
+++ b/con
Using MSDK parser can improve qsv decoder pass rate in some cases (E.g:
sps declares a wrong level_idc, smaller than it should be).
And it is necessary for adding new qsv decoders such as MJPEG and VP9
since current parser can't provide enough information.
Actually using MFXVideoDECODE_DecodeHeader
Signed-off-by: Zhong Li
---
libavcodec/qsv.c | 18 ++
libavcodec/qsv_internal.h | 2 ++
2 files changed, 20 insertions(+)
diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
index bb0d79588c..224bc00ce4 100644
--- a/libavcodec/qsv.c
+++ b/libavcodec/qsv.c
@@ -196,6 +196,24
Replace current parser with MFXVideoDECODE_DecodeHeader(),
and add MJPEG/VP9 decoders.
V2: Fix hevc 10bit decoding regression
V3: 1. Disable VP9 if not defined in libmfx header file
2. Avoid to use vp9 plugin but init it direct
3. Avoid a dangerous static definition
Zhong Li (6):
lavc/q
7 Mar 2019, 21:22 by mich...@niedermayer.cc:
> On Thu, Mar 07, 2019 at 07:26:32PM +0100, Lynne wrote:
>
>> By default now, if AV_EF_CRCCHECK or AV_EF_IGNORE_ERR are enabled the decoder
>> will skip the chunk and carry on with the next one. This should make the
>>
>> decoder able to decode
tor 2019-03-07 klockan 14:42 + skrev Matthew Fearnley:
> This consists mostly of the following changes:
> - add newly supported pixel formats (RGB555LE, RGB565LE, BGR0)
> - select the ZMBV format (c->fmt) and bytes per pixel (c->bypp) based on
> avctx->pix_fmt
> - multiply widths/x-values by
Just like commit 6829a079444e10818a847e153121fb458cc5c0a8,
surface size larger than requirement should not be treated as error.
Signed-off-by: Zhong Li
---
libavutil/hwcontext_qsv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontex
ons 2019-03-06 klockan 15:05 +0100 skrev Carl Eugen Hoyos:
> 2019-03-06 14:38 GMT+01:00, Tomas Härdin :
>
> > I have generated new samples, sourced with test pattern,
> > some as short as 1 second, about 1.2 megabytes per file.
> > If real-life clips are required, or if the expectation is for me
>
Am 08.03.19 um 10:59 schrieb Tobias Rapp:
> On 08.03.2019 10:49, Ulf Zibis wrote:
>> [...]
>> Can some other developer please give me a practical hint how to deal
>> with private folders not to appear in GIT patches?
>
> I'm using .git/info/exclude to ignore files that are only found within
> my p
Signed-off-by: Guo, Yejun
---
libavcodec/libvpxenc.c | 150 +
1 file changed, 150 insertions(+)
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index c823b8a..2984c7a 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of James Zern
> Sent: Friday, March 08, 2019 9:53 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH V3] avcodec/libvpxenc: add VP8
> sup
[Apols for sending this again, but I realised the subject didn't describe the
change, which was unhelpful)
This patch makes it possible to do stuff like write a custom in-memory TS
segmenter, which was what I needed it for.
> Hi
>
> I needed to be able to use the write_data_type callback when
On 08/03/2019 00:57, Carl Eugen Hoyos wrote:
2019-03-06 15:57 GMT+01:00, Oliver Collyer :
Hi
I needed the dynamic resolution changing feature of NVENC to be accessible
through the ffmpeg libraries for a hobby project, so I added support and
here is a patch.
I will format this as a proper patch
On 3/8/19, myp...@gmail.com wrote:
> On Fri, Mar 8, 2019 at 5:26 PM Paul B Mahol wrote:
>>
>> On 3/8/19, Jun Zhao wrote:
>> > From: Jun Zhao
>> >
>> > accumulation of 8-bits uint_8 (uint8_t *src) into 32-bits (uint32_t *ii)
>> > data type, it will have a risk of an integral value becoming large
On 08.03.2019 10:49, Ulf Zibis wrote:
[...]
Can some other developer please give me a practical hint how to deal
with private folders not to appear in GIT patches?
I'm using .git/info/exclude to ignore files that are only found within
my private developing environment.
Regards,
Tobias
_
Hi Michael,
Am 08.03.19 um 00:53 schrieb Michael Niedermayer:
> On Thu, Mar 07, 2019 at 12:52:32AM +0100, Ulf Zibis wrote:
>> diff --git a/.gitignore b/.gitignore
>> index 0e57cb0..7819c84 100644
>> --- a/.gitignore
>> +++ b/.gitignore
>> @@ -36,3 +36,5 @@
>> /lcov/
>> /src
>> /mapfile
>> +/nbp
Am 08.03.19 um 00:53 schrieb Michael Niedermayer:
> On Thu, Mar 07, 2019 at 12:52:32AM +0100, Ulf Zibis wrote:
>> Hi,
>>
>> I think there is a bug in vf_fillborders.c 16 bit routines.
>>
>> When using memset or memcopy, I think, correct linesize instead
>> s->planewidth[p] should be used.
>> When
From: Jing Sun
base on patch by Huang, Zhengxu from https://github.com/intel/SVT-HEVC
V4: - Fix the build error with new API in PR#52
- Fix the encoding hang issue by API change in PR#52
- Fix the last frame dropping issue
- Fix the invalid parameter causing segmentation fault issue
On Fri, Mar 8, 2019 at 5:26 PM Paul B Mahol wrote:
>
> On 3/8/19, Jun Zhao wrote:
> > From: Jun Zhao
> >
> > accumulation of 8-bits uint_8 (uint8_t *src) into 32-bits (uint32_t *ii)
> > data type, it will have a risk of an integral value becoming larger than
> > the 32-bits integer capacity and
On 05/03/2019 07:43, Jing SUN wrote:
> From: Jing Sun
>
> base on patch by Huang, Zhengxu from https://github.com/intel/SVT-HEVC
>
> V4: - Fix the build error with new API in PR#52
> - Fix the encoding hang issue by API change in PR#52
> - Fix the last frame dropping issue
> - Fix th
When the new incremental parser was introduced, the old parser was
kept, because the new parser was unable to handle the way SSA packets
are put into Matroska. But since 2014 (since
c7d8dbad14ed5fa3c217a4fc1790021d6c0b6416) this is no longer needed, so
that the old parser can be completely removed.
The check introduced in 9326117bf63b04a466d9e787224e56ba8cdbb215 had
the unintended consequence of introducing an error message after one
has reached the end of the last cluster if there is another element
after the last cluster (and if the last cluster was not an unknown-size
encoded cluster). Thi
Up until now, the SimpleBlock was treated specially: It basically had
its own EBML category and it was also included in the BlockGroup EBML
syntax (although a SimpleBlock must not exist in a BlockGroup according
to the Matroska specifications). The latter fact also meant that
a MatroskaBlock's buff
The earlier code had three flaws:
1. The case of an unknown-sized element inside a finite-sized element
(which is against the specifications) was not caught.
2. The error message wasn't helpful: It compared the length of the child
with the offset of the end of the parent and claimed that the firs
Before this commit, the Matroska muxer would read a block when required
to do so, parse the block, create and return the necessary AVPackets and
yet keep the blocks (in a dynamically allocated list), although they
aren't used at all any more. This has been changed. There is no list any
more and the
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskadec.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 6c796e8a4a..0f04389a4e 100644
--- a/libavformat/matroskadec.c
+++ b/li
and drop the redundant checks contained in ebml_read_uint and
ebml_read_sint.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskadec.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 88e80b2fda..55a153d9
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskadec.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 0e76fd828d..d899ee5744 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -1171,7 +1171,6 @@ static
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskadec.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 0e3a6890c1..de27d63b17 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -322,7 +322,6 @@ typed
regarding the length of a cluster's size field.
The earlier code relied on the length of clusters always being coded on
eight bytes (as is current Matroska muxer behaviour). But there is no
need to rely on this and this commit changes it.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matros
It is only necessary to zero the initial allocated memory used to store
the size of laced frames if the block used Xiph lacing. Otherwise no
unintialized data was ever used, so use av_malloc instead of av_mallocz.
Also use the correct type for the allocations.
Signed-off-by: Andreas Rheinhardt
-
On 3/8/19, Jun Zhao wrote:
> From: Jun Zhao
>
> accumulation of 8-bits uint_8 (uint8_t *src) into 32-bits (uint32_t *ii)
> data type, it will have a risk of an integral value becoming larger than
> the 32-bits integer capacity and resulting in an integer overflow. For
> this risk, add a checking
On Fri, Mar 08, 2019 at 12:11:47AM +0100, Martin Vignali wrote:
> >> Can you check that and fix it?
> >>
> >>
> >
> Patch in attach fix for me vsynth3 interlace prores test :
> make fate-vsynth3-prores_int;make fate-vsynth3-prores_444_int
>
> Pass fate test for me (os x X86_64) with and without
>
From: Jun Zhao
fix mixed declarations and code in C90 after last change
Signed-off-by: Jun Zhao
---
libavfilter/vf_nlmeans.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/libavfilter/vf_nlmeans.c b/libavfilter/vf_nlmeans.c
index 8d47f9d..7497df2 100644
--- a/libavf
From: Jun Zhao
accumulation of 8-bits uint_8 (uint8_t *src) into 32-bits (uint32_t *ii)
data type, it will have a risk of an integral value becoming larger than
the 32-bits integer capacity and resulting in an integer overflow. For
this risk, add a checking with warning message.
Signed-off-by: J
64 matches
Mail list logo
