On Thu, Jul 4, 2019 at 12:42 AM Lynne wrote:
>
> NAK for reasons said on IRC
For everyones benefit, why don't you actually formulate your reasons
here instead of asking people to piece them together from some chat
history, that way people can actually understand or respond to them.
I, for one, co
I am OK with Alex Kravchenko taking the official ownership of AMF integration.
I am still involved in AMD AMF implementation and monitor FFmpeg changes.
Mikhail Mironov
From: ffmpeg-devel on behalf of Alexander
Kravchenko
Sent: Wednesday, July 3, 2019 6:53 PM
To: ffmpeg-devel@ffmpeg.o
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 88b0109f22..a66e4fc338 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -138,6 +138,7 @@ Codecs:
aacenc*, aaccoder.c Rostislav Pehlivanov
alacenc.c J
Fixes: out of array access
Fixes:
15484/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HYMT_fuzzer-5765377054736384
Fixes:
15559/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HYMT_fuzzer-5710295743332352
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/
Fixes: null pointer dereference
Fixes:
15464/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HYMT_fuzzer-5681391150301184
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/huffyuvdec.c | 3 ---
NAK for reasons said on IRC
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
On Tue, 02 Jul 2019 17:19:02 +0300
Alexander Kravchenko wrote:
>
LGTM, but please try and get git send-email working. Your client is
still doing binary attachments.
--phil
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailm
Am Mi., 3. Juli 2019 um 21:24 Uhr schrieb Michael Niedermayer
:
>
> On Tue, Jul 02, 2019 at 11:40:52AM +0200, Carl Eugen Hoyos wrote:
> > Hi!
> >
> > Attached patch intends to fix ticket #7985.
> >
> > Please comment, Carl Eugen
>
> > vc2enc_dwt.c |2 +-
> > 1 file changed, 1 insertion(+), 1 d
On Mon, Jul 01, 2019 at 11:04:43PM +0200, Andreas Rheinhardt wrote:
> For audio packets with dts != AV_NOPTS_VALUE the dts the dts was
> converted twice to the muxer's timebase during streamcopy, once as a
> normal packet and once specifically as an audio packet. This has been
> changed.
>
> Signe
On Tue, Jul 02, 2019 at 02:19:37PM +0200, Alfred E. Heggestad wrote:
> this patch fixes a compiler warning if CONFIG_AC3_PARSER is
> not defined. The label 'end' is removed and all the code
> use the label 'err' instead.
What compiler warning (this should be in the commit message)
"goto err" in t
On Tue, Jul 02, 2019 at 11:40:52AM +0200, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch intends to fix ticket #7985.
>
> Please comment, Carl Eugen
> vc2enc_dwt.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> dad3681a3b8ddce4b2a1aa81795d042b99069117
> 0001-lavc-vc2enc_dwt-Av
On Wed, Jul 3, 2019 at 12:51 AM vincenluo(罗永林)
wrote:
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
Great find, your patch is absolutely correct.
Pushing soon, thank you.
--
Vittorio
_
Am 03.07.19 um 16:52 schrieb Nicolas George:
> The features you add here seem useful, but I wonder: have you considered
> the option of making them a single function with a parameter to select
> the format? That may make it easier to add new formats later, and have
> them supported by any componen
Am 03.07.19 um 16:49 schrieb Ulf Zibis:
> Am 03.07.19 um 10:52 schrieb Michael Niedermayer:
> -#define av_ts2timestr(ts, tb)
> av_ts_make_time_string((char[AV_TS_MAX_STRING_SIZE]){0}, ts, tb)
> +#define av_ts2timestr(ts, tb)
> av_ts_make_time_string((char[AV_TS_MAX_STRING_SIZE]){
This patch adds a new option to the scale filter which ensures that the
output resolution is divisible by the given integer similar to using -n
in the `w` and `h` options. But this works even if the
`force_original_aspect_ratio` is used.
The use case for this is to set a fixed target resolution us
On Wed, 3 Jul 2019 18:04:26 +0200
Paul B Mahol wrote:
> On 7/3/19, Lars Kiesow wrote:
> > Hi Paul,
> >
> >> > { "force_original_aspect_ratio", "decrease or increase w/h
> >> > if necessary to keep the original AR",
> >> > OFFSET(force_original_aspect_ratio), AV_OPT_TYPE_INT, { .i64 =
> >>
On 7/3/19, Lars Kiesow wrote:
> Hi Paul,
>
>> > { "force_original_aspect_ratio", "decrease or increase w/h if
>> > necessary to keep the original AR",
>> > OFFSET(force_original_aspect_ratio), AV_OPT_TYPE_INT, { .i64 = 0},
>> > 0, 2, FLAGS, "force_oar" },
>> > +{ "force_divisible_by", "en
Hi Paul,
> > { "force_original_aspect_ratio", "decrease or increase w/h if
> > necessary to keep the original AR",
> > OFFSET(force_original_aspect_ratio), AV_OPT_TYPE_INT, { .i64 = 0},
> > 0, 2, FLAGS, "force_oar" },
> > +{ "force_divisible_by", "enforce that the output resolution is
> >
On 7/3/19, Lars Kiesow wrote:
> This patch adds a new option to the scale filter which ensures that the
> output resolution is divisible by the given integer similar to using -n
> in the `w` and `h` options. But this works even if the
> `force_original_aspect_ratio` is used.
>
> The use case for t
This patch adds a new option to the scale filter which ensures that the
output resolution is divisible by the given integer similar to using -n
in the `w` and `h` options. But this works even if the
`force_original_aspect_ratio` is used.
The use case for this is to set a fixed target resolution us
On 7/3/19, Lars Kiesow wrote:
> This patch adds a new option to the scale filter which ensures that the
> output resolution is divisible by the given integer similar to using -n
> in the `w` and `h` options. But this works even if the
> `force_original_aspect_ratio` is used.
>
> The use case for t
On 03.07.2019, at 09:28, Olivier MAIGNIAL wrote:
> Hello, thanks for review,
>
> 1) Can you give some reason about why we shouldn't use errno? I think it is
> more clear to accept the full int32 range, even if min/max int32 values are
> very unlikely to be used.
It is a global variable, with al
This patch adds a new option to the scale filter which ensures that the
output resolution is divisible by the given integer similar to using -n
in the `w` and `h` options. But this works even if the
`force_original_aspect_ratio` is used.
The use case for this is to set a fixed target resolution us
Ulf Zibis (12019-07-03):
> From 5d62406366560cfab5711120c514a77867bd8c2e Mon Sep 17 00:00:00 2001
> From: Ulf Zibis
> Date: 29.06.2019, 17:52:06
>
> avutil/timestamp: added av_ts2us() and 2 new print formats
The features you add here seem useful, but I wonder: have you considered
the option of m
Am 03.07.19 um 10:52 schrieb Michael Niedermayer:
>
-#define av_ts2timestr(ts, tb)
av_ts_make_time_string((char[AV_TS_MAX_STRING_SIZE]){0}, ts, tb)
+#define av_ts2timestr(ts, tb)
av_ts_make_time_string((char[AV_TS_MAX_STRING_SIZE]){'\0'}, ts, tb)
+
+/**
+ * Fil
The patch should be applied on top of the Replay ADPCM patches.
Regards
Cameron
On Mon, 1 Jul 2019 at 15:07, Michael Niedermayer
wrote:
> On Sun, Jun 30, 2019 at 12:00:43AM +0100, Cameron Cawley wrote:
> > ---
> > libavformat/rpl.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
I've added documentation for the extension of aphasemeter filter.
Also, I'm not sure that "phasing" is the right word to describe the
detection.
From 1e356929e878a2081add102b77a9560647232ef8 Mon Sep 17 00:00:00 2001
From: Romane Lafon
Date: Wed, 3 Jul 2019 15:15:16 +0200
Subject: [PATCH] avfilter/
On 03/07/2019 08:41, Reimar Döffinger wrote:
> Of course another question might be if it might make sense to replace all
> memcpy uses with it.
I would expect this may break some compiler optimizations around
memcpy (like __builtin_memcpy, or direct inlining), no?
- Derek
___
On Wed, Jul 3, 2019 at 10:46 AM Michael Niedermayer
wrote:
>
> On Wed, Jul 03, 2019 at 09:41:41AM +0200, Reimar Döffinger wrote:
> >
> >
> > On 03.07.2019, at 08:29, Michael Niedermayer wrote:
> >
> > > On Tue, Jul 02, 2019 at 08:42:43PM -0300, James Almer wrote:
> > >> On 7/2/2019 5:56 PM, Micha
Hi,
here is my attempt to fix this bug:
https://trac.ffmpeg.org/ticket/7966
I am wondering if track_duration should include
the last duration or not.
I tried to include duration in the calculation
of track_duration here:
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 46
On Tue, Jul 02, 2019 at 12:28:53AM +0200, Ulf Zibis wrote:
> Thanks Michael for your review, answers inline ...
>
> Am 01.07.19 um 17:16 schrieb Michael Niedermayer:
> >> timestamp.h | 78
> >>
> >> 1 file changed, 73 insertions(+),
On Wed, Jul 03, 2019 at 09:41:41AM +0200, Reimar Döffinger wrote:
>
>
> On 03.07.2019, at 08:29, Michael Niedermayer wrote:
>
> > On Tue, Jul 02, 2019 at 08:42:43PM -0300, James Almer wrote:
> >> On 7/2/2019 5:56 PM, Michael Niedermayer wrote:
> >>> Signed-off-by: Michael Niedermayer
> >>> ---
On 03.07.2019, at 08:29, Michael Niedermayer wrote:
> On Tue, Jul 02, 2019 at 08:42:43PM -0300, James Almer wrote:
>> On 7/2/2019 5:56 PM, Michael Niedermayer wrote:
>>> Signed-off-by: Michael Niedermayer
>>> ---
>>> doc/APIchanges | 3 +++
>>> libavutil/mem.h | 13 +
>>> l
Hello, thanks for review,
1) Can you give some reason about why we shouldn't use errno? I think it is
more clear to accept the full int32 range, even if min/max int32 values are
very unlikely to be used.
2) The RFC 4566 don't give any limit on fmtp parameters values. In addition
I can't find a spe
34 matches
Mail list logo
