2019-03-06 12:22 GMT+01:00, Lynne :
> The CRC flag is only signalled once every few minutes but CRC is still
> always present so the patch uses the file version instead.
> CRC on 24-bit files wants non-padded samples so skip such files.
> Some corrupt samples may have been output before the final
On Thu, Feb 28, 2019 at 12:49:00AM +0100, Michael Niedermayer wrote:
> Fixes: Undefined shift
> Fixes:
> 12911/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SCPR_fuzzer-5677102915911680
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
On Wed, Mar 6, 2019 at 3:55 PM Carl Eugen Hoyos wrote:
>
> 2019-03-06 4:18 GMT+01:00, Jun Zhao :
> > 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
2019-03-06 12:31 GMT+01:00, myp...@gmail.com :
> On Wed, Mar 6, 2019 at 3:55 PM Carl Eugen Hoyos wrote:
>>
>> 2019-03-06 4:18 GMT+01:00, 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
1. add MaxMBPS checking for level idc setting to align with AVC spec
AnnexA table A-1/A-6 level limits.
2. update h264 level fate test.
Signed-off-by: Decai Lin
---
libavcodec/h264_levels.c | 5 +
libavcodec/h264_levels.h | 1 +
libavcodec/h264_metadata_bsf.c | 14
> Not sure if this justifies not adding the new code to PutBitContext: it
> doesn't
> have to work for all situations, only for the encoder that initially uses
> it.
>
>
Like the current patch, works on big and little endian, i will try to
rewrite this patch using a start of a new
On 3/6/2019 10:33 AM, Carl Eugen Hoyos wrote:
> 2019-03-06 14:22 GMT+01:00, James Almer :
>> On 3/6/2019 5:06 AM, Carl Eugen Hoyos wrote:
>>> 2019-03-04 22:06 GMT+01:00, James Almer :
>>>
+static const enum AVPixelFormat pix_fmt[][3] = {
+[DAV1D_PIXEL_LAYOUT_I400] = {
The CRC flag is only signalled once every few minutes but CRC is still
always present so the patch uses the file version instead.
CRC on 24-bit files wants non-padded samples so skip such files.
Some corrupt samples may have been output before the final check
depending on the -max_samples setting.
On 3/6/2019 5:07 AM, Carl Eugen Hoyos wrote:
> 2019-03-05 19:26 GMT+01:00, James Almer :
>> On 3/5/2019 3:19 PM, Vittorio Giovara wrote:
>
>>> +if (p->mastering_display) {
>>> +AVMasteringDisplayMetadata *mastering =
>>> av_mastering_display_metadata_create_side_data(frame);
>>> +
On 3/6/2019 8:22 AM, Lynne wrote:
> The CRC flag is only signalled once every few minutes but CRC is still
> always present so the patch uses the file version instead.
> CRC on 24-bit files wants non-padded samples so skip such files.
> Some corrupt samples may have been output before the final
On 3/6/2019 5:06 AM, Carl Eugen Hoyos wrote:
> 2019-03-04 22:06 GMT+01:00, James Almer :
>
>> +static const enum AVPixelFormat pix_fmt[][3] = {
>> +[DAV1D_PIXEL_LAYOUT_I400] = { AV_PIX_FMT_GRAY8, AV_PIX_FMT_GRAY10,
>> AV_PIX_FMT_GRAY12 },
>> +[DAV1D_PIXEL_LAYOUT_I420] = {
On Wed, Mar 6, 2019 at 2:18 PM Carl Eugen Hoyos wrote:
>
> 2019-03-06 12:22 GMT+01:00, Lynne :
> > The CRC flag is only signalled once every few minutes but CRC is still
> > always present so the patch uses the file version instead.
> > CRC on 24-bit files wants non-padded samples so skip such
2019-03-06 14:22 GMT+01:00, James Almer :
> On 3/6/2019 5:06 AM, Carl Eugen Hoyos wrote:
>> 2019-03-04 22:06 GMT+01:00, James Almer :
>>
>>> +static const enum AVPixelFormat pix_fmt[][3] = {
>>> +[DAV1D_PIXEL_LAYOUT_I400] = { AV_PIX_FMT_GRAY8, AV_PIX_FMT_GRAY10,
>>> AV_PIX_FMT_GRAY12 },
>>>
6 Mar 2019, 11:22 by d...@lynne.ee:
> The CRC flag is only signalled once every few minutes but CRC is still
> always present so the patch uses the file version instead.
> CRC on 24-bit files wants non-padded samples so skip such files.
> Some corrupt samples may have been output before the final
On 3/6/19, Carl Eugen Hoyos wrote:
> 2019-03-04 23:58 GMT+01:00, James Darnley :
>> Prepare for checkasm test.
>> ---
>> libavcodec/v210dec.c | 13 +
>> libavcodec/v210dec.h | 1 +
>> 2 files changed, 10 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavcodec/v210dec.c
2019-03-04 23:58 GMT+01:00, James Darnley :
> Prepare for checkasm test.
> ---
> libavcodec/v210dec.c | 13 +
> libavcodec/v210dec.h | 1 +
> 2 files changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/v210dec.c b/libavcodec/v210dec.c
> index ddc5dbe8be..28cf00d320
Thanks for reviewing and making this happen.
Regards,
Joep
On Wed, Mar 6, 2019 at 6:38 AM Jeyapal, Karthick
wrote:
>
> On 3/5/19 8:07 PM, joepadmiraal wrote:
> > ---
> > libavformat/dashenc.c | 20 ++--
> > 1 file changed, 18 insertions(+), 2 deletions(-)
> >
> > diff --git
2019-03-05 19:26 GMT+01:00, James Almer :
> On 3/5/2019 3:19 PM, Vittorio Giovara wrote:
>> +if (p->mastering_display) {
>> +AVMasteringDisplayMetadata *mastering =
>> av_mastering_display_metadata_create_side_data(frame);
>> +if (!mastering)
>> +return
2019-03-04 22:06 GMT+01:00, James Almer :
> +static const enum AVPixelFormat pix_fmt[][3] = {
> +[DAV1D_PIXEL_LAYOUT_I400] = { AV_PIX_FMT_GRAY8, AV_PIX_FMT_GRAY10,
> AV_PIX_FMT_GRAY12 },
> +[DAV1D_PIXEL_LAYOUT_I420] = { AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV420P10,
> AV_PIX_FMT_YUV420P12 },
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Carl Eugen Hoyos
> Sent: Wednesday, March 6, 2019 3:49 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] libavcodec/vp8dec: fix the multi-thread
>
2019-02-21 2:37 GMT+01:00, Fāng-ruì Sòng :
> Sorry if this doesn't attach to the correct thread as I didn't
> subscribe to this list and don't know the Message-ID of the thread.
The thread works fine here with gmail but your patch was corrupted,
you have to attach it.
Carl Eugen
2019-03-06 9:25 GMT+01:00, Wang, Shaofei :
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
>> Carl Eugen Hoyos
>> Sent: Wednesday, March 6, 2019 3:49 PM
>> To: FFmpeg development discussions and patches
>> Subject: Re: [FFmpeg-devel]
1. organize fragmented information according to the tracks.
2. do NOT skip the last boxes of fragmented info.
ticket #7572
To reproduce #7572, need to revert commit
aa25198f1b925a464bdfa83a98476f08d26c9209 first. That commit works for ticket
7572 luckily. However, #7572 has a deeper reason.
2019-03-05 8:43 GMT+01:00, Jing SUN :
> +enabled libsvthevc&& require_pkg_config libsvthevc SvtHevcEnc
> svt-hevc/EbApi.h EbInitHandle
What funny optional dependencies does this library have that
justifies requiring pkg_config?
Carl Eugen
___
Hi
I needed to be able to use the write_data_type callback when reading data from
the mpegts muxer, to make my application aware of key frames in the data so I
added support. I used the matroska implementation as a reference.
If this is accepted, I will format this as a proper patch after
On Wed, Mar 6, 2019 at 3:57 PM Oliver Collyer wrote:
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 0ce22ec4fa..7087f82ce1 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -3357,6 +3357,12 @@ typedef struct AVCodecContext {
> * - encoding: unused
>
> Would it be an alternative to add an option that allows to force
> the packet size?
I like the idea. I guess the options are:
1. Set packet size + Use old version (fixed 8192 buffer) to estimate
parameter if not set by user.
2. Set packet size + Use new version (adaptive buffer) to estimate
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
Marton, Michael, thanks for your feedback.
I've updated the patch based on your comments.
> I can see that you are increasing linearly, maybe doubling the bufsize
> with each step is better, although in this case it probably does not
> matter too much.
> On the other hand, the maximum 8K seems
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
> to perform the FATE tests, let me know.
Could this get committed
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 after any changes necessary following
feedback.
To use this feature you would need to:
On 2019-03-06 10:11, Paul B Mahol wrote:
> On 3/6/19, Carl Eugen Hoyos wrote:
>> 2019-03-04 23:58 GMT+01:00, James Darnley :
>>> Prepare for checkasm test.
>>> ---
>>> libavcodec/v210dec.c | 13 +
>>> libavcodec/v210dec.h | 1 +
>>> 2 files changed, 10 insertions(+), 4 deletions(-)
>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>> index 0ce22ec4fa..7087f82ce1 100644
>> --- a/libavcodec/avcodec.h
>> +++ b/libavcodec/avcodec.h
>> @@ -3357,6 +3357,12 @@ typedef struct AVCodecContext {
>> * - encoding: unused
>> */
>> int discard_damaged_percentage;
>>
Hi
I want to use ff_extract_extradata_bsf to get extradata from a h.264 frame.
Here is the code.
AVPacket *avpkt; // there is valid data.
AVBSFContext *ctx = NULL;
ret = av_bsf_alloc(_extract_extradata_bsf, );
ret = ff_extract_extradata_bsf.init(ctx);
ret =
On 3/6/2019 4:04 PM, Yufei He wrote:
> Hi
>
> I want to use ff_extract_extradata_bsf to get extradata from a h.264 frame.
>
> Here is the code.
>
> AVPacket *avpkt; // there is valid data.
> AVBSFContext *ctx = NULL;
> ret = av_bsf_alloc(_extract_extradata_bsf, );
> ret =
>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>> index 0ce22ec4fa..7087f82ce1 100644
>> --- a/libavcodec/avcodec.h
>> +++ b/libavcodec/avcodec.h
>> @@ -3357,6 +3357,12 @@ typedef struct AVCodecContext {
>> * - encoding: unused
>> */
>> int discard_damaged_percentage;
>>
Hi
I want to use ff_extract_extradata_bsf to get extradata from a h.264 frame.
Here is the code.
AVPacket *avpkt; // There is valid data.
AVBSFContext *ctx = NULL;
ret = av_bsf_alloc(_extract_extradata_bsf, );
ret = ff_extract_extradata_bsf.init(ctx);
ret =
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.
>From e1f4410f35d3d7f774a0de59ab72764033d14900 Mon Sep 17 00:00:00 2001
From: Lynne
Date: Wed, 6 Mar 2019 17:04:04 +
Subject: [PATCH]
---
tests/checkasm/Makefile | 1 +
tests/checkasm/checkasm.c | 3 ++
tests/checkasm/checkasm.h | 1 +
tests/checkasm/v210dec.c | 76 +++
4 files changed, 81 insertions(+)
create mode 100644 tests/checkasm/v210dec.c
diff --git a/tests/checkasm/Makefile
---
tests/checkasm/Makefile | 1 +
tests/checkasm/checkasm.c | 3 ++
tests/checkasm/checkasm.h | 1 +
tests/checkasm/v210dec.c | 77 +++
4 files changed, 82 insertions(+)
create mode 100644 tests/checkasm/v210dec.c
diff --git a/tests/checkasm/Makefile
On 2019-03-06 20:31, James Darnley wrote:
> ...
Wrong patch and wrong reference. Please ignore this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Prepare for checkasm test.
---
libavcodec/v210dec.c | 16 ++--
libavcodec/v210dec.h | 1 +
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/libavcodec/v210dec.c b/libavcodec/v210dec.c
index ddc5dbe8be..6db662538e 100644
--- a/libavcodec/v210dec.c
+++
On Mon, Mar 4, 2019 at 6:19 AM Guo, Yejun wrote:
>
> Signed-off-by: Guo, Yejun
> ---
> configure | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
lgtm. This is a remnant from when vp8 was the only codec in the library.
___
ffmpeg-devel
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 using arrray syntax, I think, correct s->planewidth[p] instead
linesize should be used.
See my proposed patch.
-Ulf
>From
On 06/03/2019 08:21, Decai Lin wrote:
> 1. add MaxMBPS checking for level idc setting to align with AVC spec
>AnnexA table A-1/A-6 level limits.
> 2. update h264 level fate test.
>
> Signed-off-by: Decai Lin
> ---
> libavcodec/h264_levels.c | 5 +
> libavcodec/h264_levels.h
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Tuesday, March 05, 2019 8:26 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 4/5] vaapi_encode: Add ROI support
>
> On 28/02/2019 06:33, Guo,
From: Andriy Gelman
Reduces buffering latency with low bitrate streams, where
8192 bytes can mean several seconds.
---
libavformat/mpegts.c | 60 +++-
1 file changed, 37 insertions(+), 23 deletions(-)
diff --git a/libavformat/mpegts.c
On Wed, Mar 6, 2019 at 4:14 PM Carl Eugen Hoyos wrote:
> 2019-02-21 2:37 GMT+01:00, Fāng-ruì Sòng >:
> > Sorry if this doesn't attach to the correct thread as I didn't
> > subscribe to this list and don't know the Message-ID of the thread.
>
> The thread works fine here with gmail but your
Sorry, wrong signed-off-by line..
(isn't using my usual mail client mutt and i get very sick of the
webmail...)
On Thu, Mar 7, 2019 at 11:36 AM Fāng-ruì Sòng wrote:
> On Wed, Mar 6, 2019 at 4:14 PM Carl Eugen Hoyos
> wrote:
>
>> 2019-02-21 2:37 GMT+01:00, Fāng-ruì Sòng <
>>
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:
On Thu, Mar 7, 2019 at 9:39 AM 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
>
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.
---
libavcodec/libaomenc.c | 71
On 3/6/2019 9:56 PM, Sam John wrote:
> 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
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:
On Wed, Mar 6, 2019 at 9:15 PM Carl Eugen Hoyos wrote:
>
> 2019-03-06 12:31 GMT+01:00, myp...@gmail.com :
> > On Wed, Mar 6, 2019 at 3:55 PM Carl Eugen Hoyos
wrote:
> >>
> >> 2019-03-06 4:18 GMT+01:00, Jun Zhao :
>
> >> > +// accumulation of 8-bits uint_8 (uint8_t *src) into 32-bits
> >> >
Prepare for checkasm test.
---
libavcodec/v210dec.c | 16 ++--
libavcodec/v210dec.h | 1 +
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/libavcodec/v210dec.c b/libavcodec/v210dec.c
index ddc5dbe8be..fd8a6b0d78 100644
--- a/libavcodec/v210dec.c
+++
On Wed, 6 Mar 2019, Andriy Gelman wrote:
From: Andriy Gelman
Reduces buffering latency with low bitrate streams, where
8192 bytes can mean several seconds.
---
libavformat/mpegts.c | 60 +++-
1 file changed, 37 insertions(+), 23 deletions(-)
diff
Thanks for the feedback. You are right, I can use VPERMQ to free up a
register. I can also remove the PAND mask by doing PSLLD/PSRLD. That
eliminates the need for an x86-64 block.
I tried the naive 'unrolled' version with no permute, and it was much slower,
about the same as the AVX/SSSE3
---
libavcodec/v210dec.c | 10 +-
libavcodec/x86/v210-init.c | 8 +
libavcodec/x86/v210.asm| 63 --
3 files changed, 64 insertions(+), 17 deletions(-)
diff --git a/libavcodec/v210dec.c b/libavcodec/v210dec.c
index ddc5dbe8be..26954c0df3
59 matches
Mail list logo
