On 4/4/2019 5:52 PM, Carl Eugen Hoyos wrote:
2019-04-05 2:45 GMT+02:00, Allan Cady via ffmpeg-devel
Try for example:
$ make SAMPLES=fate-suite fate-xtea
$ make SAMPLES=fate-suite fate-h264
$ make fate-acodec-flac
$ make fate-vsynth1
and also
$ make SAMPLES=fate-suite fate-list
Excellent,
2019-04-05 2:45 GMT+02:00, Allan Cady via ffmpeg-devel
:
> Is it possible to run just a single FATE test against local code while doing
> development, rather than running the entire test suite, to speed up the
> iteration cycle?
Try for example:
$ make SAMPLES=fate-suite fate-xtea
$ make
On 4/4/2019 9:45 PM, Allan Cady via ffmpeg-devel wrote:
> Is it possible to run just a single FATE test against local code while doing
> development, rather than running the entire test suite, to speed up the
> iteration cycle? I expect it is, but I don't see how explained in the
>
Is it possible to run just a single FATE test against local code while doing
development, rather than running the entire test suite, to speed up the
iteration cycle? I expect it is, but I don't see how explained in the
documentation. Would appreciate a clue if this is possible.
Thanks.
Fixes: negation of -2147483648 cannot be represented in type 'int'; cast to an
unsigned type to negate this value to itself
Fixes:
13999/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AGM_fuzzer-5644405991538688
Found-by: continuous fuzzing process
On 4/3/2019 7:17 PM, Hendrik Leppkes wrote:
> The transcode() helper function will already prepend the TARGET_PATH to
> the sample path, if its a relative path. This avoids an issue on
> Windows, where the relative path check could fail.
> ---
> tests/fate/ffmpeg.mak | 2 +-
> 1 file changed, 1
On Thu, Apr 04, 2019 at 10:55:03AM -0400, Andriy Gelman wrote:
> From: Andriy Gelman
>
> This commit replaces packet assignment operator with av_packet_move_ref when
> there
> is a packet ownership transfer.
> ---
>
> Aims to address a TODO in libavformat/utils.c about using av_packet_mov_ref
On 4/2/2019 9:49 PM, Sam John via ffmpeg-devel wrote:
> ---
> doc/encoders.texi | 46 ++
> 1 file changed, 46 insertions(+)
>
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index 94337d009c..a669ac3739 100644
> --- a/doc/encoders.texi
> +++
On 03-04-2019 06:19 AM, Sam John via ffmpeg-devel wrote:
---
doc/encoders.texi | 46 ++
1 file changed, 46 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 94337d009c..a669ac3739 100644
--- a/doc/encoders.texi
+++
---
libavformat/matroskaenc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index b9f99c4463..1a06103c5d 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -694,8 +694,10 @@ static int
On Thu, Apr 04, 2019 at 04:10:35PM +0800, Linjie Fu wrote:
> Use the profile constraint flags to determine the exact va_profile for
> HEVC_REXT.
>
> Directly cast PTLCommon to H265RawProfileTierLevel, and use
> ff_h265_get_profile
> to get the exact profile.
>
> Signed-off-by: Linjie Fu
> ---
Jun Zhao:
> From: Jun Zhao
>
> Fix memory leak after write trailer for #7827, only store a audio
> packet whose buffer has size greater than zero in cur_audio_pkt.
>
> Thanks to Andreas Rheinhardt for the suggestions.
>
> Signed-off-by: Jun Zhao
> ---
> libavformat/matroskaenc.c |3 ++-
>
Audio packets with size zero, but with side-data currently lead to
memleaks, in the Matroska muxer, because they are not properly freed:
They are currently put into an AVPacket in the MatroskaMuxContext to
ensure that the necessary audio is always available for a new cluster,
but are only written
From: Jun Zhao
Fix memory leak after write trailer for #7827, only store a audio
packet whose buffer has size greater than zero in cur_audio_pkt.
Thanks to Andreas Rheinhardt for the suggestions.
Signed-off-by: Jun Zhao
---
libavformat/matroskaenc.c |3 ++-
1 files changed, 2
From: Andriy Gelman
This commit replaces packet assignment operator with av_packet_move_ref when
there
is a packet ownership transfer.
---
Aims to address a TODO in libavformat/utils.c about using av_packet_mov_ref
instead of assignment operator.
libavformat/utils.c | 28
Hi Baptiste,
Am Mi., 3. Apr. 2019 um 11:23 Uhr schrieb Baptiste Coudurier <
baptiste.coudur...@gmail.com>:
> ---
> libavformat/mxf.h| 1 +
> libavformat/mxfenc.c | 197 ---
> 2 files changed, 147 insertions(+), 51 deletions(-)
>
> diff --git
On 4/1/19 11:17 AM, Octavio Alvarez wrote:
> On 4/1/19 7:41 AM, Carl Eugen Hoyos wrote:
>>> The patch is untested, but it looks fairly straightforward.
>>
>> How can this patch be tested?
>
> ffmpeg -y -r 30 -f x11grab -show_region 1 -draw_mouse 0 -s 350x614
> -follow_mouse 10 -i :0.0+0,0 -r 30
On Thu, Apr 4, 2019 at 3:05 PM Andreas Rheinhardt via ffmpeg-devel
wrote:
>
> And I think that this memleak in mkv_write_trailer() has a twin in
> mkv_write_packet(): Audio frames are not written directly, but rather
> put into storage in cur_audio_pkt via av_packet_ref(). But if the
> preceding
And I think that this memleak in mkv_write_trailer() has a twin in
mkv_write_packet(): Audio frames are not written directly, but rather
put into storage in cur_audio_pkt via av_packet_ref(). But if the
preceding audio packet was a zero size packet (but possibly with
side-data), then the preceding
On 04-04-2019 02:37 AM, Michael Niedermayer wrote:
doc/ffmpeg.texi |5 +
fftools/ffmpeg.c | 47 +--
fftools/ffmpeg.h |3 +++
fftools/ffmpeg_opt.c |5 +
4 files changed, 58 insertions(+), 2 deletions(-)
Hendrik Leppkes:
> On Thu, Apr 4, 2019 at 11:25 AM Jun Zhao wrote:
>>
>> From: Jun Zhao
>>
>> Fix memory leak after write trailer for #7827
>>
>> Signed-off-by: Jun Zhao
>> ---
>> libavformat/matroskaenc.c |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git
On Thu, Apr 4, 2019 at 5:43 PM Hendrik Leppkes wrote:
>
> On Thu, Apr 4, 2019 at 11:25 AM Jun Zhao wrote:
> >
> > From: Jun Zhao
> >
> > Fix memory leak after write trailer for #7827
> >
> > Signed-off-by: Jun Zhao
> > ---
> > libavformat/matroskaenc.c |2 +-
> > 1 files changed, 1
On Thu, Apr 4, 2019 at 11:25 AM Jun Zhao wrote:
>
> From: Jun Zhao
>
> Fix memory leak after write trailer for #7827
>
> Signed-off-by: Jun Zhao
> ---
> libavformat/matroskaenc.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/libavformat/matroskaenc.c
On Wed, Apr 03, 2019 at 10:14:22AM +0200, Paul B Mahol wrote:
> On 4/3/19, Michael Niedermayer wrote:
> > Fixes: out of array access
> > Fixes:
> > 13997/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AGM_fuzzer-5701427252428800
> >
> > Found-by: continuous fuzzing process
> >
On Wed, Mar 06, 2019 at 02:47:37PM +0100, Lynne wrote:
> 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
On Thu, Apr 4, 2019 at 3:12 PM Peter Belkner wrote:
>
> On 04.04.2019 08:49, myp...@gmail.com wrote:
>
> On Thu, Apr 4, 2019 at 2:33 PM Peter Belkner wrote:
>
> This patch does not improve or fix something instead it is meant for
> easily reproducing issue 7827 (as requested, cf.
>
From: Jun Zhao
Fix memory leak after write trailer for #7827
Signed-off-by: Jun Zhao
---
libavformat/matroskaenc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index b9f99c4..22ba93a 100644
---
On Wed, Jan 09, 2019 at 05:26:53PM -0500, Leo Izen wrote:
> ---
> fftools/ffmpeg.c | 19 ++-
> 1 file changed, 14 insertions(+), 5 deletions(-)
Does this behave as intended when there is also an audio stream ?
also a fate test should be added
thx
[...]
--
Michael GnuPG
Use the profile constraint flags to determine the exact va_profile for
HEVC_REXT.
Directly cast PTLCommon to H265RawProfileTierLevel, and use ff_h265_get_profile
to get the exact profile.
Signed-off-by: Linjie Fu
---
[v2]: use constraint flags to determine the exact profile, expose the
On 04.04.2019 08:49, myp...@gmail.com wrote:
On Thu, Apr 4, 2019 at 2:33 PM Peter Belkner wrote:
This patch does not improve or fix something instead it is meant for
easily reproducing issue 7827 (as requested, cf.
https://trac.ffmpeg.org/ticket/7827). I've to admit that I don't know
how to
On Thu, Apr 4, 2019 at 2:33 PM Peter Belkner wrote:
>
> This patch does not improve or fix something instead it is meant for
> easily reproducing issue 7827 (as requested, cf.
> https://trac.ffmpeg.org/ticket/7827). I've to admit that I don't know
> how to produce a patch by "git format-patch"
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Wednesday, March 13, 2019 8:18 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v2 2/6] lavu/frame: Expand ROI
> documentation
>
> Clarify and add
On Thu, Apr 4, 2019 at 5:21 AM Michael Niedermayer
wrote:
>
> On Thu, Mar 28, 2019 at 09:23:29PM +0800, Jun Zhao wrote:
> > From: Jun Zhao
> >
> > Use %.12g replace %.f when save AMF NUMBER(double) type to
> > metadata. And update fate ref.
> >
> > before this fix, we get FLV metadata like:
> >
This patch does not improve or fix something instead it is meant for
easily reproducing issue 7827 (as requested, cf.
https://trac.ffmpeg.org/ticket/7827). I've to admit that I don't know
how to produce a patch by "git format-patch" instead it was made by "git
diff > muxing.patch".
diff
34 matches
Mail list logo
