Andreas,
On Sun, 21. Jul 10:47, Andreas Rheinhardt wrote:
> Andriy Gelman:
> > From: Andriy Gelman
> >
> > Fixes #7799
> >
> > Currently, the mp4toannexb filter always inserts extradata at the start
> > of each IRAP unit. This can lead to duplication of parameter sets if the
> > demuxed packet
The documentation of av_write_frame explicitly states that the function
does not take ownership of the packets sent to it; while av_write_frame
does not directly unreference the packets after having written them, it
nevertheless modifies the packet in various ways:
1. The timestamps might be
ff_write_chained essentially duplicated the functionality of
av_packet_rescale_ts. This has been changed.
Signed-off-by: Andreas Rheinhardt
---
libavformat/mux.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/libavformat/mux.c b/libavformat/mux.c
index
If writing an uncoded frame fails at the preparatory steps of
av_[interleaved_]write_frame, the frame would be either not freed
at all in case of av_write_frame or would leak when the fake packet
would be unreferenced like an ordinary packet.
There is also a memleak when the output format is not
write_packet currently saves the original timestamps of the packet it got
and restores them in case writing fails. This is unnecessary as none of
write_packet's callers make any use of these timestamps at all. So
remove this and add a general comment to the function that timestamps
may be
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Thilo Borgmann
> Sent: Monday, August 12, 2019 3:55 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH V3] fate: add a case for ticket #3229
>
> Am 12.08.19 um 08:13 schrieb Zhong Li:
> >
Signed-off-by: Andreas Rheinhardt
---
libavformat/mux.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavformat/mux.c b/libavformat/mux.c
index efe2e94f40..5b67a793ac 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -1330,8 +1330,8 @@ int
1. When set_parameters was removed from AVOutputFormat in 2fb75019, it
was forgotten to remove the comment pertaining to it. Said comment now
appeared to apply to interleave_packet; it is of course nonsense and has
been replaced by an accurate description.
2. The description of
Signed-off-by: Andreas Rheinhardt
---
libavformat/mux.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/libavformat/mux.c b/libavformat/mux.c
index 2728c62de5..4089382ffd 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -921,13 +921,13 @@ int
There is no reason for these functions to modify the given packets at
all.
Signed-off-by: Andreas Rheinhardt
---
libavformat/audiointerleave.c | 2 +-
libavformat/audiointerleave.h | 2 +-
libavformat/gxfenc.c | 5 +++--
libavformat/internal.h| 2 +-
libavformat/mux.c
1. When an error happened in ff_interleave_add_packet during
interleaving a packet for output, said packet would not be unreferenced
in ff_interleave_add_packet, but would be zeroed in
av_interleaved_write_frame, which results in a memleak.
2. When no error happened in ff_interleave_add_packet
If no error occurs and this AVPacketList is used at all, its packet
substructure will be overwritten and its next pointer explicitly set, so
every field will still be initialized even when using av_malloc.
Signed-off-by: Andreas Rheinhardt
---
libavformat/mux.c | 2 +-
1 file changed, 1
It is unnecessary to call prepare_input_packet if there is no packet as
it doesn't do anything, except when the currently inactive code guarded
by !FF_API_COMPUTE_PKT_FIELDS2 || !FF_API_LAVF_AVCTX becomes active:
Then attempting to access pkt->stream_index will crash.
Signed-off-by: Andreas
If ff_interleave_add_packet failed, the content of the newly created
packet new_pkt would leak.
Also, it is unnecessary to zero-initialize a packet that will be put
into av_new_packet lateron as the latter already initializes the packet.
Therefore this has been removed, too.
Signed-off-by:
In the common case that the input packet was already refcounted,
ff_interleave_add_packet would allocate a new AVPacketList, use
av_packet_ref to create a new reference to the buffer for the
AVPacketList's packet, interleave the packet and finally unreference
the original input packet.
This commit
> -Original Message-
> From: Aman Gupta [mailto:a...@tmm1.net] On Behalf Of Aman Gupta
> Sent: Tuesday, August 13, 2019 09:05
> To: ffmpeg-devel@ffmpeg.org
> Cc: s...@jkqxz.net; Fu, Linjie ; Aman Gupta
>
> Subject: [PATCH v2 2/2] vaapi_encode: fix VBR mode generating low bitrates
>
>
On Mon, Aug 12, 2019 at 11:03:24PM +0200, Marton Balint wrote:
>
>
> On Mon, 12 Aug 2019, lance.lmw...@gmail.com wrote:
>
> >From: Limin Wang
> >
> >Signed-off-by: Limin Wang
> >---
> >libavfilter/f_select.c | 3 ++-
> >tests/ref/fate/filter-metadata-scenedetect | 16
From: Limin Wang
Signed-off-by: Limin Wang
---
libavfilter/f_select.c | 6 +-
tests/ref/fate/filter-metadata-scenedetect | 16
2 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/libavfilter/f_select.c b/libavfilter/f_select.c
index
From: Limin Wang
Signed-off-by: Limin Wang
---
libavfilter/f_select.c | 5 -
tests/ref/fate/filter-metadata-scenedetect | 16
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/libavfilter/f_select.c b/libavfilter/f_select.c
index
On 12.08.2019, at 21:53, Michael Niedermayer wrote:
> On Sun, Aug 11, 2019 at 08:30:51PM +0200, Reimar Döffinger wrote:
>> On 08.08.2019, at 10:36, Michael Niedermayer wrote:
>>
>>> This provides an alternative to retry counters.
>>> Useful if there is no reasonable maximum number of
From: Limin Wang
Signed-off-by: Limin Wang
---
libavfilter/f_select.c | 5 -
tests/ref/fate/filter-metadata-scenedetect | 16
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/libavfilter/f_select.c b/libavfilter/f_select.c
index
From: Aman Gupta
This is a regression from 2562dd9e7831743ba6dc5680501fb7d26a2ec62c
which surfaces a pathological bug in some Intel hardware encoders,
causing very low bitrates to be generated whenever VBR mode is used.
/cc intel/intel-vaapi-driver#480
Signed-off-by: Aman Gupta
---
From: Aman Gupta
On some Intel chips, sending VAEncMiscParameterTypeRateControl multiple
times causes the encoder to produce very low bitrates that do not match
the requested rate controls.
This is a regression as of af532c921575eb8ee805cc2c64a914f6302442e1. Prior
to that global params were
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of James Darnley
> Sent: Monday, August 5, 2019 9:39 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH 0/7] Import some x264asm patches from
> x264
>
> Here are a few
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Andreas Rheinhardt
> Sent: Monday, August 12, 2019 9:15 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Andreas Rheinhardt
> Subject: [FFmpeg-devel] [PATCH] avfilter/vf_convolution: Fix build failures
From: Aman Gupta
This is a regression from 2562dd9e7831743ba6dc5680501fb7d26a2ec62c
which surfaces a pathological bug in the Intel Broxton/CherryView
hardware encoders, causing very low bitrates to be generated
whenever VBR mode is used.
/cc intel/intel-vaapi-driver#480
Signed-off-by: Aman
From: Aman Gupta
The hardware encoder on these chipsets produces very low bitrates
in VBR mode if it receives VAEncMiscParameterTypeRateControl more than once.
/cc intel/intel-vaapi-driver#480
Signed-off-by: Aman Gupta
---
libavcodec/vaapi_encode.c | 8 +++-
Am Fr., 2. Aug. 2019 um 17:24 Uhr schrieb ckerchne
:
>
> A bug exist with the gcc compilers for Power in versions 6.x and 7.x
> (verified with 6.3 and 7.4). It was fixed in version 8.x (verified with
> 8.3). I was using a Power 9 ppc64le machine for building and testing.
> This is to address
On 8/12/2019 5:31 PM, Michael Niedermayer wrote:
> On Mon, Aug 12, 2019 at 09:21:59PM +0200, Vittorio Giovara wrote:
>> On Mon, Aug 12, 2019 at 9:19 PM Michael Niedermayer
>> wrote:
>>
>>> Signed-off-by: Michael Niedermayer
>>> ---
>>> libavcodec/decode.c | 2 +-
>>> 1 file changed, 1
> 在 2019年8月12日，20:29，myp...@gmail.com 写道：
>
> On Sun, Aug 11, 2019 at 4:43 PM Steven Liu wrote:
>>
>>
>>
>>> 在 2019年8月8日，19:32，Jun Zhao 写道：
>>>
>>> From: tomajsjiang
>>>
>>> Add new API ffio_realloc_buf for AVIO buffer realloc.
>>>
>>> Signed-off-by: Zhongxing Jiang
>>> ---
>>>
Andreas Rheinhardt:
> The option tables of the various fftools (in particular ffprobe) are
> arrays of OptionDef; said type contains a union of a pointer to void and
> a function pointer of type int (*)(void *, const char *, const char *)
> as well as a size_t. Some entries (namely the common
On Mon, Aug 12, 2019 at 02:40:02PM +0800, Guo, Yejun wrote:
> example command line to verify it:
> ./ffmpeg -i input.stream -vf addroi=0:0:iw/3:ih/3:-0.8 -c:v libvpx -b:v 2M
> tmp.webm
>
> Signed-off-by: Guo, Yejun
> ---
> libavcodec/libvpxenc.c | 177
>
On Mon, 12 Aug 2019, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
libavfilter/f_select.c | 3 ++-
tests/ref/fate/filter-metadata-scenedetect | 16
2 files changed, 10 insertions(+), 9 deletions(-)
diff --git
Michael Niedermayer (12019-08-10):
> Fixes: left shift of negative value -961533698048
> Fixes:
> 16242/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFWAVESYNTH_fuzzer-5738550670131200
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
On Mon, 12 Aug 2019, Michael Niedermayer wrote:
On Fri, May 31, 2019 at 10:28:15PM +0200, Marton Balint wrote:
On Thu, 30 May 2019, Michael Niedermayer wrote:
Fixes: Ticket7880
Signed-off-by: Michael Niedermayer
---
libavcodec/qtrle.c| 42 +++
On Mon, Aug 12, 2019 at 09:21:59PM +0200, Vittorio Giovara wrote:
> On Mon, Aug 12, 2019 at 9:19 PM Michael Niedermayer
> wrote:
>
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/decode.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git
On Mon, Aug 12, 2019 at 12:48:51PM +0530, Abhinav Rao wrote:
> Hello, everyone. I'm Abhinav Rao, a second-year undergrad from India. I
> have some experience in working with C and Assembly, and would like to
> contribute to FFmpeg. It would be great if someone could guide me to any
> resource(s)
On Sun, Aug 11, 2019 at 08:30:51PM +0200, Reimar Döffinger wrote:
> On 08.08.2019, at 10:36, Michael Niedermayer wrote:
>
> > This provides an alternative to retry counters.
> > Useful if there is no reasonable maximum number of iterations and
> > no ordering that naturally avoids loops.
>
>
On Mon, Aug 12, 2019 at 01:46:55PM +0200, Vittorio Giovara wrote:
> On Thu, Aug 8, 2019 at 10:28 PM Vittorio Giovara
> wrote:
>
> > Some broken apps generate files that have a fake box named 'hoov'
> > instead of a proper 'moov' one. This is speculation but it seems like
> > this box contains
On Mon, Aug 12, 2019 at 11:25:59AM -0700, Juan De León wrote:
> Pinging,
> Any other opinions?
About adding a reserved[128] ?
i think storing the size somewhere is probably better (less memory, and
not having an arbitrary limit which could theoretically be hit one day)
thx
[...]
--
Michael
On Mon, Aug 12, 2019 at 9:19 PM Michael Niedermayer
wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/decode.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index 6c31166ec2..09a509d659 100644
> ---
Fixes: Timeout (42sec -> 379 ms)
Fixes:
16323/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LOCO_fuzzer-5679178099195904
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/loco.c | 2 ++
1
On Wed, Jul 31, 2019 at 10:52:34AM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> tools/target_dec_fuzzer.c | 2 ++
> 1 file changed, 2 insertions(+)
will apply
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Take away the
Fixes: Timeout (14sec -> 133ms)
Fixes:
14843/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_NUV_fuzzer-5661969614372864
Fixes:
16257/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_NUV_fuzzer-5769175464673280
(35sec ->0.5sec)
Found-by: continuous fuzzing process
Fixes: Timeout (12sec -> 32ms)
Fixes:
16078/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CINEPAK_fuzzer-5695832885559296
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/cinepak.c | 3 +++
Fixes: Timeout (31sec -> 22sec)
Fixes:
16217/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FLIC_fuzzer-5658084189405184
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/flicvideo.c | 9
Fixes: Ticket7880
Signed-off-by: Michael Niedermayer
---
libavcodec/qtrle.c| 44 +++
tests/ref/fate/qtrle-8bit | 1 +
2 files changed, 41 insertions(+), 4 deletions(-)
diff --git a/libavcodec/qtrle.c b/libavcodec/qtrle.c
index 2c29547e5a..ab620cdb55
Signed-off-by: Michael Niedermayer
---
libavcodec/decode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 6c31166ec2..09a509d659 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -435,7 +435,7 @@ static int
Fixes: Timeout (12sec ->2sec)
Fixes:
16125/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MSRLE_fuzzer-5650846364205056
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
tools/target_dec_fuzzer.c | 1 +
Fixes: Timeout (13sec ->1sec)
Fixes:
16122/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SANM_fuzzer-5724944247291904
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
tools/target_dec_fuzzer.c | 1 +
On Fri, May 31, 2019 at 10:28:15PM +0200, Marton Balint wrote:
>
>
> On Thu, 30 May 2019, Michael Niedermayer wrote:
>
> >Fixes: Ticket7880
> >
> >Signed-off-by: Michael Niedermayer
> >---
> >libavcodec/qtrle.c| 42 +++
> >tests/ref/fate/qtrle-8bit |
Pinging,
Any other opinions?
On Sat, Aug 10, 2019 at 2:22 AM Nicolas George wrote:
> Lynne (12019-08-10):
> > >> +typedef struct AVEncodeInfoBlock{
> > >> +/**
> > >> + * Distance in luma pixels from the top-left corner of the
> visible frame
> > >> + * to the top-left corner of the
Hi Paul
On Mon, Aug 05, 2019 at 11:50:04AM +0200, Paul B Mahol wrote:
> Hi,
>
> I here hereby request from lead FFmpeg entity to give me subscription to
> ffmpeg-security mailing list.
I am not sure who or what a "lead FFmpeg entity" is, But as iam being
highlighted
on IRC by you in relation
From: Limin Wang
Signed-off-by: Limin Wang
---
libavfilter/vsrc_mptestsrc.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/libavfilter/vsrc_mptestsrc.c b/libavfilter/vsrc_mptestsrc.c
index 4a2db18..14e66fd 100644
---
On Mon, Aug 12, 2019 at 03:05:32PM +0200, Moritz Barsnick wrote:
> On Mon, Aug 12, 2019 at 19:21:45 +0800, lance.lmw...@gmail.com wrote:
> > +Set the max number frames generated for each tests:
>
> Grammar nit:
> Set the maximum number of frames generated for each test
>
> (Note:
> - use the
A bug exist with the gcc compilers for Power in versions 6.x and 7.x
(verified with 6.3 and 7.4). It was fixed in version 8.x (verified with
8.3). I was using a Power 9 ppc64le machine for building and testing.
It appears the compiler is generating the wrong code for little endian
machines
From: Limin Wang
Signed-off-by: Limin Wang
---
tests/fate/filter-video.mak | 4 +
tests/ref/fate/filter-metadata-freezedetect | 251
2 files changed, 255 insertions(+)
create mode 100644 tests/ref/fate/filter-metadata-freezedetect
diff --git
From: Limin Wang
Signed-off-by: Limin Wang
---
doc/filters.texi | 3 +++
libavfilter/vsrc_mptestsrc.c | 29 +
2 files changed, 20 insertions(+), 12 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index e081cdc..902e5bf 100644
---
> Am 12.08.2019 um 16:21 schrieb ckerchne :
>
> How do I get someone to look at this patch?
>
>> A bug exist with the gcc compilers for Power in versions 6.x and 7.x
>> (verified with 6.3 and 7.4). It was fixed in version 8.x (verified
>> with 8.3). I was using a Power 9 ppc64le machine for
How do I get someone to look at this patch?
A bug exist with the gcc compilers for Power in versions 6.x and 7.x
(verified with 6.3 and 7.4). It was fixed in version 8.x (verified
with 8.3). I was using a Power 9 ppc64le machine for building and
testing.
This is to address ticket #7124.
It
Hi Michael,
> > + if (scale->force_divisible_by > 1) {
> > + w = ceil(w / (float)scale->force_divisible_by) *
> > scale->force_divisible_by;
> > + h = ceil(h / (float)scale->force_divisible_by) *
> > scale->force_divisible_by;
>
> you dont need float
This patch adds a new option to the scale filter which ensures that the
output resolution is divisible by the given integer when used together
with `force_original_aspect_ratio`. This works similar to using `-n` in
the `w` and `h` options.
This option respects the value set for
On Mon, Aug 12, 2019 at 2:56 PM Moritz Barsnick wrote:
> On Sun, Aug 11, 2019 at 15:57:46 +0200, Nicolas George wrote:
> > > +c->hashes = av_malloc_array(1, sizeof(c->hashes));
> > > +if (!c->hashes)
> > > +return AVERROR(ENOMEM);
> > > +res = av_hash_alloc(>hashes[0],
On Mon, Aug 12, 2019 at 19:21:45 +0800, lance.lmw...@gmail.com wrote:
> +Set the max number frames generated for each tests:
Grammar nit:
Set the maximum number of frames generated for each test
(Note:
- use the complete word maximum
- "test", "not tests", when using "for each" singular
-
On Sun, Aug 11, 2019 at 15:57:46 +0200, Nicolas George wrote:
> > +c->hashes = av_malloc_array(1, sizeof(c->hashes));
> > +if (!c->hashes)
> > +return AVERROR(ENOMEM);
> > +res = av_hash_alloc(>hashes[0], c->hash_name);
> > +if (res < 0) {
> > +av_freep(>hashes);
>
On Sun, Aug 11, 2019 at 4:43 PM Steven Liu wrote:
>
>
>
> > 在 2019年8月8日，19:32，Jun Zhao 写道：
> >
> > From: tomajsjiang
> >
> > Add new API ffio_realloc_buf for AVIO buffer realloc.
> >
> > Signed-off-by: Zhongxing Jiang
> > ---
> > libavformat/avio_internal.h |9 +
> >
On Thu, Aug 8, 2019 at 10:28 PM Vittorio Giovara
wrote:
> Some broken apps generate files that have a fake box named 'hoov'
> instead of a proper 'moov' one. This is speculation but it seems like
> this box contains data to be modified later (eg as file grows in size,
> data gets re-written) and
On 12/08/2019 12:35, Дмитрий Овчинников wrote:
Yes, it is possible, but it is required to implement separate patch with
selector dx9, dx11, vulkan. We could do it when this one is committed.
I will double check with opencl interop and will comeback.
There is no standardized OpenCL/Vulkan
Hi,
patch attached.
0001-avfilter-add-sierpinski-video-source.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
From: Limin Wang
Signed-off-by: Limin Wang
---
doc/filters.texi | 3 +++
libavfilter/vsrc_mptestsrc.c | 27 +++
2 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index e081cdc7bc..d3d468b445 100644
---
From: Limin Wang
Signed-off-by: Limin Wang
---
tests/fate/filter-video.mak | 4 +
tests/ref/fate/filter-metadata-freezedetect | 251
2 files changed, 255 insertions(+)
create mode 100644 tests/ref/fate/filter-metadata-freezedetect
diff --git
On Sun, Aug 11, 2019 at 05:02:47PM +0200, Michael Niedermayer wrote:
> On Sun, Aug 11, 2019 at 09:29:14AM +1000, Peter Ross wrote:
> > On Tue, Aug 06, 2019 at 11:30:02PM +0200, Michael Niedermayer wrote:
> > > Fixes: Timeout (23sec -> 71ms)
> > > Fixes:
> > >
Yes, it is possible, but it is required to implement separate patch with
selector dx9, dx11, vulkan. We could do it when this one is committed.
I will double check with opencl interop and will comeback.
___
ffmpeg-devel mailing list
LGTM
On Mon, Aug 12, 2019 at 2:19 AM Michael Niedermayer
wrote:
> Fixes: Timeout (81sec -> 0.2sec)
> Fixes:
> 16169/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FOURXM_fuzzer-5662570416963584
>
> Found-by: continuous fuzzing process
>
These functions can be used to print a variable number of strings consecutively
to the IO context. Unlike av_bprintf, no temporary buffer is necessary.
Signed-off-by: Marton Balint
---
doc/APIchanges| 3 +++
libavformat/avio.h| 17 +
libavformat/aviobuf.c | 6
Am 12.08.19 um 08:13 schrieb Zhong Li:
> Signed-off-by: Zhong Li
> ---
> https://patchwork.ffmpeg.org/patch/13725/ introduces a regression but not
> found by fate, so add it.
> Test clip produced by:
> ffmpeg -i tickets/3229/bad.avi -vframes 3 -c:v copy
> /fate-suite/mjpeg/mjpeg_field_order.avi
Hi Marton,
‐‐‐ Original Message ‐‐‐
On Sunday, 11 de August de 2019 22:14, Marton Balint wrote:
> > > +/* For VBR we select the highest multiple of frame duration
> > > which is less than 100 ms. */
> >
> > Don't you think it's a good idea to use the parameter "pcr_period"
Hello, everyone. I'm Abhinav Rao, a second-year undergrad from India. I
have some experience in working with C and Assembly, and would like to
contribute to FFmpeg. It would be great if someone could guide me to any
resource(s) that would help me get acquainted with the codebase.
Thank you,
example command line to verify it:
./ffmpeg -i input.stream -vf addroi=0:0:iw/3:ih/3:-0.8 -c:v libvpx -b:v 2M
tmp.webm
Signed-off-by: Guo, Yejun
---
libavcodec/libvpxenc.c | 177 +
1 file changed, 177 insertions(+)
diff --git
On Wed, Jul 31, 2019 at 10:52:32AM +0200, Michael Niedermayer wrote:
> This should reduces the number of uninteresting timeouts encountered
>
> Signed-off-by: Michael Niedermayer
> ---
> tools/target_dec_fuzzer.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
will apply with
Signed-off-by: Zhong Li
---
https://patchwork.ffmpeg.org/patch/13725/ introduces a regression but not found
by fate, so add it.
Test clip produced by:
ffmpeg -i tickets/3229/bad.avi -vframes 3 -c:v copy
/fate-suite/mjpeg/mjpeg_field_order.avi
tests/fate/video.mak| 3 +++
On Sat, Aug 03, 2019 at 04:07:22PM +0200, Tomas Härdin wrote:
> lör 2019-08-03 klockan 01:49 +0200 skrev Michael Niedermayer:
> > -uint32_t x, y, src_x, src_y;
> > +uint32_t x, y, src_y;
> > +int width = hnm->width;
> >
> > for (y = 0; y < hnm->height; y++) {
> > +
82 matches
Mail list logo
