> 2020年5月22日 下午1:42，rcombs 写道：
>
> This reduces the number of requests that have to be made during startup.
> ---
> libavformat/dashdec.c | 41 ++---
> 1 file changed, 26 insertions(+), 15 deletions(-)
>
> diff --git a/libavformat/dashdec.c b/libavformat/dash
On 5/22/20, Mark Reid wrote:
> On Thu, May 21, 2020 at 8:14 AM Paul B Mahol wrote:
>
>> Probably ok, except code style.
>> Please keep code style consistent across files.
>>
>
> Thanks a lot for the feedback. I see a few inconsistently named variables,
> maybe I used too many spaces in places. C
Quoting Nicolas George (2020-05-21 17:10:00)
> Anton Khirnov (12020-05-21):
> > This is wrong. We should not fix warnings, we should fix bugs. Warnings
> > suggest there may be a bug, but not all warnings are correct.
> >
> > In this case, I believe the warnings is invalid and there is no problem
Quoting Andreas Rheinhardt (2020-05-22 03:24:31)
> Signed-off-by: Andreas Rheinhardt
> ---
> Was the earlier behaviour actually a bug (I think so) or is this new
> behaviour something that should be explicitly documented?
>
> Btw, the stream and packet side-data APIs differ in two more ways:
> av
This reduces the number of requests that have to be made during startup.
---
libavformat/dashdec.c | 41 ++---
1 file changed, 26 insertions(+), 15 deletions(-)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index ec2aadcee3..1bd070c7cb 100644
--- a
This can be useful in chained demuxers, where the header size is known.
---
libavformat/format.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/libavformat/format.c b/libavformat/format.c
index c47490c8eb..7309b0019b 100644
--- a/libavformat/format.c
+++ b/libavformat/fo
This is useful for chained demuxers, to avoid reading past the end of a shared
initialization segment and into the first data segment unnecessarily.
---
libavformat/isom.h | 1 +
libavformat/mov.c | 10 +-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/libavformat/isom.h
pushed
--
Anton Khirnov
___
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".
pushed
--
Anton Khirnov
___
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 22/05/2020 10:43, Lynne wrote:
> The Xiph foundation never standardized either Daala nor its mapping in Ogg,
> and all files that were created are undecodable without knowledge of the
> git hash.
>
> Patch attached.
+1 from me.
Why was a parser for a WIP/Research codebase/codec pushed anyway
On Sun, May 17, 2020 at 3:52 PM Jun Zhao wrote:
>
> From: Jun Zhao
>
> Now we just use one ADTS raw frame to calculate the bit rate, it's
> lead to a larger error when get the duration from bit rate, the
> improvement cumulate Nth ADTS frames to get the average bit rate.
>
> e,g used the command
The Xiph foundation never standardized either Daala nor its mapping in Ogg,
and all files that were created are undecodable without knowledge of the
git hash.
Patch attached.
>From 0cb4c5ca4d8bfc52309b1f6382145344d1b7e183 Mon Sep 17 00:00:00 2001
From: Lynne
Date: Fri, 22 May 2020 10:30:41 +010
Hi,
I heard that, security fix is already there on the master branch[*] and will
most likely be backported to the coming release 4.2.3, together with many other
fixes.
I have following queries.
1. In master branch ffversion.h version remains as "#define FFMPEG_VERSION
"n4.2.1"", even
They add considerable complexity to frame-threading implementation,
which includes an unavoidably leaking error path, while the advantages
of this option to the users are highly dubious.
It should be always possible and desirable for the callers to make their
get_buffer2() implementation thread-sa
On 4/10/2020 11:07 AM, Derek Buitenhuis wrote:
> On 10/04/2020 00:09, James Almer wrote:
>> EAGAIN is returned when input is provided but can't be consumed. The
>> filtering
>> process is unaffected in this case, and the function will be able to consume
>> new input after retrieving filtered packe
probably ok
On 4/17/20, one...@oneric.de wrote:
> On Fri, Apr 17, 2020 at 02:15:17 +0200, Oneric wrote:
>> From 51deab727958c5d64ae526f67063cdf141a01d46 Mon Sep 17 00:00:00 2001
>> From: Oneric
>> Date: Fri, 17 Apr 2020 00:38:53 +0200
>> Subject: [PATCH] avcodec/ass: explicitly set ScaledBorderA
---
libavcodec/decode.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index f3327d74af..dbecdf3f46 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -586,6 +586,7 @@ static int decode_receive_frame_internal(AVCodec
On 5/21/2020 5:06 AM, Martin Storsjö wrote:
> This fixes test failures in fate-cbs-hevc-* in certain configurations
> since c53f9f436440be4e18.
> ---
> Not sure if this is what was intended, but the current code doesn't
> work at least.
> ---
> libavcodec/cbs_h265_syntax_template.c | 2 +-
> 1 fil
On 5/21/2020 9:15 AM, Martin Storsjö wrote:
> Move the copying of the frame to vos_data further up in the function,
> so that when writing the actual frame data for the first frame, it's
> clear that the stream really is in annex b format, for the cases where
> we create extradata from the first fr
On 5/22/2020 1:56 PM, Anton Khirnov wrote:
> ---
> libavcodec/decode.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index f3327d74af..dbecdf3f46 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -586
On 5/20/2020 6:12 PM, Martin Storsjö wrote:
> This was a mistake in my own additions in
> 050b72ab5ef318605b305aa6cb920e8b52f1002e.
> ---
> libavcodec/mfenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/mfenc.c b/libavcodec/mfenc.c
> index dd8188dae3..e62ae
May 22, 2020, 15:04 by an...@khirnov.net:
> They add considerable complexity to frame-threading implementation,
> which includes an unavoidably leaking error path, while the advantages
> of this option to the users are highly dubious.
>
> It should be always possible and desirable for the callers
On Fri, May 22, 2020 at 02:32:07PM -0300, James Almer wrote:
> On 5/22/2020 1:56 PM, Anton Khirnov wrote:
> > ---
> > libavcodec/decode.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> > index f3327d74af..dbecdf3f
On Fri, May 22, 2020 at 10:02:40AM +, Narayanaswamy, Raghu wrote:
> Hi,
>
>
>
> I heard that, security fix is already there on the master branch[*] and will
> most likely be backported to the coming release 4.2.3, together with many
> other fixes.
>
>
>
> I have following queries.
>
>
On Thu, May 21, 2020 at 09:42:18PM +0200, Carl Eugen Hoyos wrote:
> Am Mi., 20. Mai 2020 um 22:21 Uhr schrieb Michael Niedermayer
> :
> >
> > On Wed, May 20, 2020 at 08:48:41PM +0530, Gautam Ramakrishnan wrote:
> > > On Tue, Apr 21, 2020 at 3:41 AM Michael Niedermayer
> > > wrote:
> > > >
> > > >
On 5/22/2020 4:22 PM, Michael Niedermayer wrote:
> On Fri, May 22, 2020 at 02:32:07PM -0300, James Almer wrote:
>> On 5/22/2020 1:56 PM, Anton Khirnov wrote:
>>> ---
>>> libavcodec/decode.c | 8
>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/libavcodec/decode.c b
On Thu, May 21, 2020 at 12:05:47PM -0700, Dale Curtis wrote:
> On Thu, May 21, 2020 at 12:37 AM Michael Niedermayer
> wrote:
>
> > gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
> > used with ccache on a x86-64
> >
>
> Huh, I guess there's no early abort for conditionals in a preprocessor
> statement w
On Thu, May 21, 2020 at 10:05:57PM +0200, Carl Eugen Hoyos wrote:
> Hi!
>
> When receiving jpeg frames via rtp, libavformat currently writes a
> wrong JFIF version (2.01 instead of 1.02), see also 85ca012ba68.
> Attached patch fixes the version.
>
> Please comment, Carl Eugen
> rtpdec_jpeg.c |
On Thu, 21 May 2020, myp...@gmail.com wrote:
On Tue, May 19, 2020 at 2:43 AM Marton Balint wrote:
On Mon, 11 May 2020, Marton Balint wrote:
> This will be used for AVCodecContext->profile. By specifying constants in the
> encoders we won't have to use the common AVCodecContext options ta
On Sat, 16 May 2020, Marton Balint wrote:
Signed-off-by: Marton Balint
---
doc/ffmpeg.texi | 2 ++
fftools/ffmpeg.c | 4
fftools/ffmpeg.h | 3 ++-
fftools/ffmpeg_opt.c | 5 +++--
4 files changed, 11 insertions(+), 3 deletions(-)
Ping, will apply soon.
Thanks,
Marton
diff -
On Thu, May 21, 2020 at 05:12:31PM +0200, Paul B Mahol wrote:
> LGTM
>
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjam
On Fri, May 22, 2020 at 06:17:14PM +0200, Paul B Mahol wrote:
> probably ok
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Any man who breaks a law that conscience tells him is unjust and willingly
accepts the penalty by staying in jail in orde
May 22, 2020, 23:42 by d...@lynne.ee:
> Posting this again.
>
> 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 be
Am Sa., 23. Mai 2020 um 00:43 Uhr schrieb Lynne :
>
> Posting this again.
>
> 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.
Should a warning be
From: Limin Wang
Signed-off-by: Limin Wang
---
doc/indevs.texi | 16 ++--
libavdevice/lavfi.c | 19 +--
2 files changed, 27 insertions(+), 8 deletions(-)
diff --git a/doc/indevs.texi b/doc/indevs.texi
index 6f5afaf..a1bd9e1 100644
--- a/doc/indevs.texi
+++ b/doc
From: Limin Wang
Signed-off-by: Limin Wang
---
doc/ffmpeg.texi | 15
fftools/ffmpeg.h| 2 ++
fftools/ffmpeg_filter.c | 20
fftools/ffmpeg_opt.c| 20
libavfilter/graphdump.c | 63 +
Posting this again.
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
Posting this again.
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.
Patch attached.
>From 2d7f310482e204d28c1408144b432b3f8e8dc866 Mon Sep 17 00:00:00 2001
From: Lynne
Date: Wed, 6 Mar 2019
Posting this again.
By default now, if AV_EF_CRCCHECK or AV_EF_IGNORE_ERR are enabled the decoder
will skip the chunk and carry on with the next one. This should make the
decoder able to decode more corrupt files because the functions which decode
individual chunks will very likely error out if f
Andreas Rheinhardt:
> If the write_id3v2 option is set, the aiff muxer would write id3v2 tags
> if there is global metadata or if there are attached pics to write.
> Chapters are ignored in this check that precedes writing id3v2 tags.
> Yet 47ac344970f1d6ef149c4b8a883b68cdb15112c2 added support for
Andreas Rheinhardt:
> Andreas Rheinhardt:
>> In order to parse a number from a string, the WebM DASH manifest muxer
>> would duplicate (via heap-allocation) the part of the string that
>> contains the number, then read the number via atoi() and then free the
>> duplicate again. This has been replac
Andreas Rheinhardt:
> Andreas Rheinhardt:
>> Since commit c5324d92c5f206dcdc2cf93ae237eaa7c1ad0a40 all custom
>> interleave_packet() functions always return clean packets (even on
>> error), so that unreferencing manually can be removed.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavform
Andreas Rheinhardt:
> Andreas Rheinhardt:
>> by storing s->streams[i] in a pointer instead of constantly using
>> s->streams[i]->...
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavformat/segment.c | 17 -
>> 1 file changed, 8 insertions(+), 9 deletions(-)
>>
>> diff --git
Andreas Rheinhardt:
> Andreas Rheinhardt:
>> AVStream.request_probe as well as AVStream.mux_ts_offset are below the
>> separator of public and private fields, so that a further "NOT PART OF
>> PUBLIC API" is redundant.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> I initially also wanted to re
44 matches
Mail list logo
