On 10-12-2019 03:12 am, Michael Niedermayer wrote:
On Sun, Dec 08, 2019 at 04:47:17PM +0530, Gyan wrote:
Makes commit msgs less ambiguous.
Regards,
Gyan
Makefile | 10 +-
scale_eval.c |2 +-
vf_scale.c |2 +-
vf_scale_cuda.c |2 +-
vf_scale_npp.c
I opened a ticket in https://trac.ffmpeg.org/ticket/8420
my patch may be not absolutely right, but this problem should get your
attention, thank you
At 2019-12-03 20:57:44, "Martin Storsjö" wrote:
>On Thu, 28 Nov 2019, manuelyuan wrote:
>
>> There are many UGC videos with dynamic frame rates,
Besides improved readability it also zeroes the padding which has been
forgotten here.
Signed-off-by: Andreas Rheinhardt
---
libavformat/iff.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/libavformat/iff.c b/libavformat/iff.c
index 2a3729f97e..9cee31a86b 10
Signed-off-by: Andreas Rheinhardt
---
libavformat/flvenc.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index 872050a74f..862082dd2d 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -908,14 +908,10 @@ sta
The packet a demuxer receives is freshly initialized, hence it is
unnecessary to reset any flags on them (as none are set), yet apc did
this.
Signed-off-by: Andreas Rheinhardt
---
libavformat/apc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavformat/apc.c b/libavformat/apc.c
index 835
Ping
On Wed, Dec 4, 2019 at 10:13 PM Jun Zhao wrote:
>
> V4: - changed the option enforced_encryption type from int to bool.
> tks Michael & Moritz's comments.
> - add range info in the docs. tks Gyan's comments.
>
> V3: - add more details for linger options. tks Andriy Gelman's comment
These values may be returned from libtls (even in the case of blocking
file descriptors) when we need to read/write more TLS record data in
order to read/write application data.
The URLProtocol documentation says AVERROR(EAGAIN) should be returned
in these cases.
Signed-off-by: Michael Forney
--
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Zhong Li
> Sent: Sunday, December 8, 2019 16:32
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc: add Tiles encode support
> for HEVC
>
> Linjie Fu 于2019年11月26日周二
On 12/3/2019 5:00 PM, James Almer wrote:
> On 12/3/2019 5:19 AM, Michael Niedermayer wrote:
>> On Mon, Dec 02, 2019 at 01:18:36PM -0300, James Almer wrote:
>>> Signed-off-by: James Almer
>>> ---
>>
>>> This is meant to be squashed with patch 2/3, otherwise it will write
>>> duplicate
>>> compatib
While CBS itself uses size_t for sizes, it relies on other APIs that use
int for their sizes; in particular, AVBuffer uses int for their size
parameters and so does GetBitContext with their number of bits. While
CBS aims to be a safe API, the checks it employed were not sufficient to
prevent overfl
On Sun, Nov 10, 2019 at 05:07:28AM +0100, Andreas Rheinhardt wrote:
> ff_id3v2_parse_priv_dict() uses av_dict_set() with the flags
> AV_DICT_DONT_STRDUP_KEY and AV_DICT_DONT_STRDUP_VAL. In this case both
> key and value are freed on error (and owned by the destination
> dictionary on success), so t
On Sat, Nov 16, 2019 at 12:10:52AM +0100, Michael Niedermayer wrote:
> Fixes: signed integer overflow: -9223372036854775808 - 17 cannot be
> represented in type 'long'
> Fixes:
> 18768/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5674385247830016
>
> Found-by: continuous fuzzing process
On Thu, Nov 14, 2019 at 10:56:35PM +0100, Michael Niedermayer wrote:
> On Thu, Nov 14, 2019 at 09:46:23PM +0800, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libswscale/swscale_unscaled.c | 2 ++
> > 1 file changed, 2 insertions(+)
>
> probab
Trailing zeroes are already discarded when splitting a fragment, which
makes the code to remove them when decomposing slices dead code.
Signed-off-by: Andreas Rheinhardt
---
This of course presupposes that the fragment has been split via
cbs_h2645_split_fragment(). And the current code is buggy e
Slices that end after their header (meaning slices after the header
without any data before the rbsp_stop_one_bit or possibly without any
rbsp_stop_one_bit at all) are invalid and are now dropped. This ensures
that one doesn't run into two asserts in cbs_h2645_write_slice_data().
Signed-off-by: An
They are spec-incompliant.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs_mpeg2.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index e42c602476..b57551c92a 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -245,6 +
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs_vp9.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/libavcodec/cbs_vp9.c b/libavcodec/cbs_vp9.c
index ea7747182e..807d066690 100644
--- a/libavcodec/cbs_vp9.c
+++ b/libavcodec/cbs_vp9.c
@@ -581,9 +581,11 @@ static
On Sat, Nov 02, 2019 at 05:05:57PM +0100, Michael Niedermayer wrote:
> Fixes: out of array access
> Fixes:
> 18499/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AGM_fuzzer-5749038406434816
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmp
cbs_h2645_assemble_fragment() asserted that every unit of the fragment
that should be written contain data; yet this is also asserted
generically in ff_cbs_write_fragment_data(). So drop the redundant
assert.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs_h2645.c | 5 -
1 file changed,
Up until now, the various functions for assembling fragments did not
check for overflow in the computation of the size of the output fragment
or whether the size they allocate actually fits into an int (as it must
given that the AVBuffer API is based on size fields of type int).
In order to optimi
On Thu, Nov 14, 2019 at 05:34:06PM +0100, Michael Niedermayer wrote:
> Fixes: memleaks
> Fixes:
> 18429/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMALOSSLESS_fuzzer-6210814364614656
> Fixes:
> 18722/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMALOSSLESS_fuzzer-5680535690543104
>
>
On Thu, Nov 14, 2019 at 05:34:07PM +0100, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 2119056926 - -134217728 cannot be represented
> in type 'int'
> Fixes:
> 18728/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-5747539563511808
>
> Found-by: continuous fuzzing pro
On Tue, Nov 12, 2019 at 11:51:30PM +0100, Michael Niedermayer wrote:
> Fixes: NULL pointer dereference
> Fixes:
> 18689/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_XMA1_fuzzer-5715114640015360
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/project
On Thu, Nov 14, 2019 at 05:34:08PM +0100, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 2147483188 + 2048 cannot be represented in
> type 'int'
> Fixes:
> 18741/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TRUESPEECH_fuzzer-5748950460268544
>
> Found-by: continuous fuzzing pr
On Sun, Dec 08, 2019 at 04:47:17PM +0530, Gyan wrote:
> Makes commit msgs less ambiguous.
>
> Regards,
> Gyan
> Makefile | 10 +-
> scale_eval.c |2 +-
> vf_scale.c |2 +-
> vf_scale_cuda.c |2 +-
> vf_scale_npp.c |2 +-
> vf_scale_vaapi.c |2 +-
lör 2019-12-07 klockan 01:06 +0800 skrev Zhao Zhili:
> This is a micro-optimization. Saving almost 200 reallocations makes
> it
> worth a try.
> ---
> fix commit message typo: relocations -> reallocations
>
> libavfilter/formats.c | 35 +--
> 1 file changed, 21 ins
Michael Niedermayer (12019-12-09):
> mixing unsigned and signed int of course works if one is aware of
> * what is signed, what is unsigned
> * exact semantics of expressions mixing them
> * does not miss any corner cases
I think it is reasonable to demand from FFmpeg developers that they know
eno
On Mon, Dec 09, 2019 at 12:36:11AM +0100, Nicolas George wrote:
> Michael Niedermayer (12019-12-09):
> > One problem with unsigned is that in expressions you cannot have negative
> > values, nor can you compare to negative values without casting to signed.
> > That has some risk for producing unexp
On Mon, Dec 09, 2019 at 04:27:06PM +, Kieran O Leary wrote:
> On Sun, 8 Dec 2019, 22:50 Michael Niedermayer,
> wrote:
>
> > Version 3 is since 2013 (FFmpeg 2.1) non experimental so should be widely
> > supported
> >
>
> This was recently raised at the No Time To Wait conference in Budapest,
On Sun, Dec 08, 2019 at 08:18:40AM +, Fu, Linjie wrote:
> Hi,
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Michael Niedermayer
> > Sent: Sunday, December 8, 2019 07:20
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: [FFmpeg-deve
On Mon, Dec 9, 2019 at 5:01 AM Clément Bœsch wrote:
>
> On Sun, Dec 08, 2019 at 11:08:31PM +0200, Martin Storsjö wrote:
> > On Sun, 8 Dec 2019, Clément Bœsch wrote:
> >
> > > On Wed, Dec 04, 2019 at 05:24:46PM -0600, Sebastian Pop wrote:
> > > > Hi Clément,
> > > >
> > > > please find attached the
On Sun, Dec 08, 2019 at 02:36:38PM +0100, Carl Eugen Hoyos wrote:
> Hi!
>
> I gave a talk at NTTW4 in Budapest last week and participated (late)
> in the community day.
> I request reimbursement for travel and accommodation, together € 78,-
> and will prepare the usual paperwork for SPI.
>
> Than
On 09/12/2019 17:27, Kieran O Leary wrote:
This was recently raised at the No Time To Wait conference in
Budapest, so it would be great to see version three as the default!
Actually it was triggered by NTTW4.
(Thanks Michael for addressing this)
It should be noted though, that Michael also re
On Sun, 8 Dec 2019, 22:50 Michael Niedermayer,
wrote:
> Version 3 is since 2013 (FFmpeg 2.1) non experimental so should be widely
> supported
>
This was recently raised at the No Time To Wait conference in Budapest, so
it would be great to see version three as the default!
Best,
Kieran O'Leary
On Thu, Dec 5, 2019, at 00:22, Jean-Baptiste Kempf wrote:
> will do our next meeting, Monday 9 December 2019, at 17:00
> Berlin/Paris/Brussels time.
>
> The time is selected so that people in China and in South America can join us.
>
> It will be online, with live comments/discussion on IRC.
Se
Invents a new option "discard_fragments" for the MP4/Quicktime/MOV decoder.
If the option is not set, nothing changes at all. If it is set, old fragments
are discarded as far as possible on each call to switch_root. For pure audio
streams, the memory usage is now constant. For video streams, the
Il dom 8 dic 2019, 14:37 Carl Eugen Hoyos ha scritto:
> Hi!
>
> I gave a talk at NTTW4 in Budapest last week and participated (late)
> in the community day.
> I request reimbursement for travel and accommodation, together € 78,-
> and will prepare the usual paperwork for SPI.
>
LGTM, thanks.
>
Hi ffmpeg
Recently I want to use dash format to serve a real-time stream video in C
language.
I want to encode the video in memory and copy it out for some purpose.
I use an example code here:
https://gist.github.com/AlexVestin/15b90d72f51ff7521cd7ce4b70056dff
The example code is fine for mp4 for
On 08-12-2019 04:47 pm, Gyan wrote:
Makes commit msgs less ambiguous.
Plan to push tomorrow.
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffm
> -Ursprüngliche Nachricht-
> Von: ffmpeg-devel Im Auftrag von Moritz
> Barsnick
> Gesendet: Montag, 9. Dezember 2019 13:16
> An: FFmpeg development discussions and patches
> Betreff: [SCISYS Possible Spam] Re: [FFmpeg-devel] [PATCH v4] Patch for
> memory optimization with QuickTime/MP4
On Mon, Dec 09, 2019 at 13:15:40 +0100, Moritz Barsnick wrote:
> > +case AVMEDIA_TYPE_SUBTITLE:
> > +/* Freeing VIDEO tables leads to corrupted video when
> > writing to eg. MKV */
> > +av_freep(&st->index_entries);
> > +st->nb_index_entr
On Mon, Dec 9, 2019 at 2:54 AM James Almer wrote:
> On 12/8/2019 6:31 PM, Michael Niedermayer wrote:
> > This allows writing empty slices
>
> Are empty slices valid in mpeg2 to begin with? Or is that the result of
> invalid/truncated data exclusively?
>
> It's invalid data, unless data partitioni
On Mon, Dec 09, 2019 at 10:22:15 +, Jörg Beckmann wrote:
Just some formal stuff:
> Subject: Patch for memory optimization with QuickTime/MP4
This subject should be created by the actual patch, because, they way
you submitted it, it will be used for pushing.
Or you create your patch with "gi
On Sun, Dec 08, 2019 at 11:08:31PM +0200, Martin Storsjö wrote:
> On Sun, 8 Dec 2019, Clément Bœsch wrote:
>
> > On Wed, Dec 04, 2019 at 05:24:46PM -0600, Sebastian Pop wrote:
> > > Hi Clément,
> > >
> > > please find attached the updated patch addressing all your comments.
> > > Let me know if t
The last patch mail seems to be lost in space. Therefore here the next try .
Cheers,
Jörg
This patch invents a new option "discard_fragments" for the MP4/Quicktime/MOV
decoder. If the option is not set, nothing changes at all. If it is set, old
fragments are discarded as far as possible on eac
45 matches
Mail list logo
