Andreas Rheinhardt:
> Only flavors 0..3 seem to exist. E.g. rmdec.c treats any flavor > 3
> as invalid data. Furthermore, we do not know how big the packets to
> create ought to be given that for sipr these values are not read from
> the bitstream, but from a table.
>
> Furthermore, flavor is only
On Thu, 30 Apr 2020, Tao Zhang wrote:
Marton Balint 于2020年4月30日周四 上午4:55写道：
On Thu, 30 Apr 2020, Tao Zhang wrote:
> Marton Balint 于2020年4月30日周四 上午12:03写道：
>>
>>
>>
>> On Wed, 29 Apr 2020, leozhang wrote:
>>
>> > In some applications, it is required to add delay to live streaming.
>>
>>
On 4/27/20, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> doc/filters.texi | 31 ++
> libavfilter/Makefile | 1 +
> libavfilter/af_asubboost.c | 210 +
> libavfilter/allfilters.c | 1 +
> 4 files changed, 243 insertions(+
Marton Balint 于2020年4月30日周四 下午3:26写道：
>
>
>
> On Thu, 30 Apr 2020, Tao Zhang wrote:
>
> > Marton Balint 于2020年4月30日周四 上午4:55写道：
> >>
> >>
> >>
> >> On Thu, 30 Apr 2020, Tao Zhang wrote:
> >>
> >> > Marton Balint 于2020年4月30日周四 上午12:03写道：
> >> >>
> >> >>
> >> >>
> >> >> On Wed, 29 Apr 2020, leozha
Tao Zhang:
> Marton Balint 于2020年4月30日周四 下午3:26写道：
>>
>>
>>
>> On Thu, 30 Apr 2020, Tao Zhang wrote:
>>
>>> Marton Balint 于2020年4月30日周四 上午4:55写道：
On Thu, 30 Apr 2020, Tao Zhang wrote:
> Marton Balint 于2020年4月30日周四 上午12:03写道：
>>
>>
>>
>> On Wed, 29 Apr
Andreas Rheinhardt 于2020年4月30日周四 下午4:23写道：
>
> Tao Zhang:
> > Marton Balint 于2020年4月30日周四 下午3:26写道：
> >>
> >>
> >>
> >> On Thu, 30 Apr 2020, Tao Zhang wrote:
> >>
> >>> Marton Balint 于2020年4月30日周四 上午4:55写道：
>
>
>
> On Thu, 30 Apr 2020, Tao Zhang wrote:
>
> > Marton B
On 29/04/2020 20:58, Michael Niedermayer wrote:
On Wed, Apr 29, 2020 at 12:00:23PM +0100, Josh de Kock wrote:
Signed-off-by: Josh de Kock
---
tools/probetest.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Small fix for compiler warning caused by my earlier change.
LGTM
Thank
Apr 29, 2020, 16:00 by mich...@niedermayer.cc:
> On Tue, Apr 28, 2020 at 07:22:08PM +0200, Lynne wrote:
>
>> Apr 28, 2020, 16:07 by d...@lynne.ee:
>>
>> > Apr 28, 2020, 15:59 by mattias.wad...@gmail.com:
>> >
>> >>
>> >>
>> > Well, I consider CRC checking a part of correctly parsing ogg, so I thin
On Thu, 30 Apr 2020 at 07:22, Roger Pack wrote:
> > > c9153590e5f167e41910d867639eb887164e28d2
> 0001-closed-caption-decoder-accept-and-decode-a-new-codec.patch
> > > From bf29fe5330e83e37cf064b18918185c6b00d9b9f Mon Sep 17 00:00:00 2001
> > > From: rogerdpack
> > > Date: Tue, 28 Apr 2020 05:15:
lance.lmw...@gmail.com (12020-04-30):
> Sorry, the old code will segment fault but the new code will not if error
> happened. so I have no idea what's to compare the output as it's error.
A segfault is better than corrupted data and better than lost data. So
your task is to examine the output file
Apparently the changes from 3c9185bf3a83395d12a987f626dbdb985eac4320
aren't enough; even with that in place, I got errors like this
when trying to build for iOS:
src/libavdevice/avfoundation.m:135:5: error:
'AVCaptureDeviceTransportControlsPlaybackMode' is unavailable: not
available on
> -Original Message-
> From: Guo, Yejun
> Sent: Sunday, April 26, 2020 5:05 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Guo, Yejun
> Subject: [PATCH 2/2] dnn-layer-mathbinary-test: add unit test for minimum
>
> Signed-off-by: Guo, Yejun
> ---
> tests/dnn/dnn-layer-mathbinary-test.c | 5 ++
On Tue, 28 Apr 2020 12:10:33 +
"Zane van Iperen" wrote:
> Signed-off-by: Zane van Iperen
> ---
> Changelog| 1 +
> libavformat/Makefile | 1 +
> libavformat/allformats.c | 1 +
> libavformat/pp_bnk.c | 289
> +++ libavformat/v
On Thu, Apr 30, 2020 at 12:34:02PM +0200, Nicolas George wrote:
> lance.lmw...@gmail.com (12020-04-30):
> > Sorry, the old code will segment fault but the new code will not if error
> > happened. so I have no idea what's to compare the output as it's error.
>
> A segfault is better than corrupted
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/v4l2_m2m_enc.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/libavcodec/v4l2_m2m_enc.c b/libavcodec/v4l2_m2m_enc.c
index 8454e2326c..98b93c61af 100644
--- a/libavcodec/v4l2_m2m_enc.c
+++ b/lib
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/mxfdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index fdd0dd2a88..02a2a6d97a 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -363,7 +363,7 @@ stati
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/mov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 3d6fef685d..03c8801402 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -6827,7 +6827,7 @@ static int mov_rea
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/utils.c | 29 +++--
1 file changed, 3 insertions(+), 26 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index e77090daef..91b271a717 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/mpegts.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index ff3898c3a5..3bd98e5743 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -2180,7 +2180,7 @@ int
lance.lmw...@gmail.com:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavformat/mov.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 3d6fef685d..03c8801402 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/
lance.lmw...@gmail.com:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavformat/mpegts.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> index ff3898c3a5..3bd98e5743 100644
> --- a/libavformat/mpegts.c
> +++ b/
Am 30.04.20 um 12:34 schrieb Martin Storsjö:
> Apparently the changes from 3c9185bf3a83395d12a987f626dbdb985eac4320
> aren't enough; even with that in place, I got errors like this
> when trying to build for iOS:
>
> src/libavdevice/avfoundation.m:135:5: error:
> 'AVCaptureDeviceTransportCont
lance.lmw...@gmail.com:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavcodec/utils.c | 29 +++--
> 1 file changed, 3 insertions(+), 26 deletions(-)
>
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index e77090daef..91b271a717 100644
> --- a/liba
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/mov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 3d6fef6..ad718cd 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -6827,7 +6827,7 @@ static int mov_read_dvcc
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/mpegts.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index ff3898c..0833d62 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -2180,7 +2180,7 @@ int ff_pa
On Thu, Apr 30, 2020 at 03:18:15PM +0200, Andreas Rheinhardt wrote:
> lance.lmw...@gmail.com:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavcodec/utils.c | 29 +++--
> > 1 file changed, 3 insertions(+), 26 deletions(-)
> >
> > diff --git a/liba
This patch adds possibility to use 'periodic-rekey' option with
multi-variant streams to hlsenc muxer. All streams variants
use parameters from the same key_info_file.
There are 2 sets of encryption options that kind of overlaps and add
complexity, so I tried to do the thing without changing too
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/utils.c | 38 ++
1 file changed, 6 insertions(+), 32 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index e77090d..3ae23fc 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@
lance.lmw...@gmail.com:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavformat/mov.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 3d6fef6..ad718cd 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
lance.lmw...@gmail.com:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavformat/mpegts.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> index ff3898c..0833d62 100644
> --- a/libavformat/mpegts.c
> +++ b/libavf
lance.lmw...@gmail.com:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavcodec/utils.c | 38 ++
> 1 file changed, 6 insertions(+), 32 deletions(-)
>
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index e77090d..3ae23fc 100644
> --- a/l
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/utils.c | 38 ++
1 file changed, 6 insertions(+), 32 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index e77090d..1a8ca16 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@
lance.lmw...@gmail.com:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavcodec/utils.c | 38 ++
> 1 file changed, 6 insertions(+), 32 deletions(-)
>
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index e77090d..1a8ca16 100644
> --- a/l
On Sat, 2020-04-18 at 08:25 -0600, John Stebbins wrote:
> Added Changelog entries
> Added doc/bitstream_filters.texi entries
> Added minor version bump patch
> Changed how keyframe detection works in merge
>
>
>
Ping. Of the 4 patches, only the first has received comments in an
earlier version
John Stebbins:
> On Sat, 2020-04-18 at 08:25 -0600, John Stebbins wrote:
>> Added Changelog entries
>> Added doc/bitstream_filters.texi entries
>> Added minor version bump patch
>> Changed how keyframe detection works in merge
>>
>>
>>
>
> Ping. Of the 4 patches, only the first has received comme
> 2020年4月30日 下午9:10，Yaroslav Pogrebnyak 写道：
>
> This patch adds possibility to use 'periodic-rekey' option with
> multi-variant streams to hlsenc muxer. All streams variants
> use parameters from the same key_info_file.
>
> There are 2 sets of encryption options that kind of overlaps and add
On Thu, 30. Apr 05:47, Ming Qian wrote:
>
>
> > On Wed, 29. Apr 16:14, Ming Qian wrote:
> > > Without this setting, bitrate may have no effect
> > > if the default value of bitrate mode is VBR.
> > >
> > > Signed-off-by: Ming Qian
> > > ---
> > > libavcodec/v4l2_m2m_enc.c | 1 +
> > > 1
On Wed, Apr 29, 2020 at 02:49:35PM -0700, Mark Reid wrote:
> On Wed, Apr 29, 2020 at 2:22 PM Michael Niedermayer
> wrote:
>
> > On Wed, Apr 29, 2020 at 11:19:56PM +0200, Michael Niedermayer wrote:
> > > On Tue, Apr 28, 2020 at 08:02:34PM -0700, mindm...@gmail.com wrote:
> > > > From: Mark Reid
>
On Wed, Apr 29, 2020 at 10:05:42PM +0200, Michael Niedermayer wrote:
> On Wed, Apr 29, 2020 at 04:01:29PM +0800, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavformat/utils.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> LG
On Sun, Apr 26, 2020 at 06:24:58PM +0100, Tom Needham wrote:
> This is probably off-topic for this mailing list, but I wasn't sure where
> to post this.
>
> ffmpeg.org seems to be down for me at the moment and all connections are
> timing out, is there any in progress maintenance/issues currently?
On Mon, 27. Apr 16:28, Andriy Gelman wrote:
> Hi Ming,
>
> Thanks for looking over the patch.
>
> On Thu, 09. Apr 07:13, Ming Qian wrote:
> > Lgtm,
> >
> > But if don't prevent enqueue frame buffer of capture port, unlikely to
> > happen this case.
>
> The problem happens when all the capture
Andreas Rheinhardt:
> Mainly reindentation.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/matroskaenc.c | 42 +++
> 1 file changed, 21 insertions(+), 21 deletions(-)
>
> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> index 12
On Thu, 30. Apr 20:59, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavcodec/v4l2_m2m_enc.c | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/libavcodec/v4l2_m2m_enc.c b/libavcodec/v4l2_m2m_enc.c
> index
Andreas Rheinhardt:
> Andreas Rheinhardt:
>> The data of an AVPacket may be a part of the data of an AVBufferRef;
>> Therefore av_grow_packet() doesn't reallocate if the available space in
>> the actual buffer is sufficient for the enlargement. But given that it
>> also zeroes the padding it also n
Andreas Rheinhardt:
> Andreas Rheinhardt:
>> hdsenc already had an explicit function to free all allocations in case
>> of an error, but it was not marked as deinit function, so that it was
>> not called automatically when the AVFormatContext for muxing gets freed.
>>
>> Using an explicit deinit fu
Due to a typo, it was impossible to write 0.595 / -4.5 dB
of ltrt_cmixlev, ltrt_surmixlev, loro_cmixlev, loro_surmixlev.
Without any error 0.841 / -1.5 dB was written to file.
---
libavcodec/ac3enc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/ac3enc.c b/libavcod
On Wed, 29. Apr 02:45, Ming Qian wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of Andriy
> > Gelman
> > Sent: Wednesday, April 29, 2020 1:07 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Andriy Gelman
> > Subject: [EXT] [FFmpeg-devel] [PATCH v5] avcodec/v4l2_m2m_enc: Support
LGTM
On 4/30/20, Piotr Oleszczyk wrote:
> Due to a typo, it was impossible to write 0.595 / -4.5 dB
> of ltrt_cmixlev, ltrt_surmixlev, loro_cmixlev, loro_surmixlev.
> Without any error 0.841 / -1.5 dB was written to file.
> ---
> libavcodec/ac3enc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 de
James Almer:
> Will be reused in the following patch.
>
> Signed-off-by: James Almer
> ---
> Moved the comment for the function to its new place, but otherwise, no
> difference compared to v2.
>
> libavcodec/cbs_h2645.c| 10 ++
> libavcodec/cbs_h265_syntax_template.c |
as per avio_open2 semantics after open_url_keepalive has failed, the options
dictionary will have been modified and needs restoring before attempting a new
connection
Signed-off-by: vectronic
---
libavformat/hls.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavformat/hls.c b/liba
On 4/30/2020 3:08 PM, Andreas Rheinhardt wrote:
> James Almer:
>> Will be reused in the following patch.
>>
>> Signed-off-by: James Almer
>> ---
>> Moved the comment for the function to its new place, but otherwise, no
>> difference compared to v2.
>>
>> libavcodec/cbs_h2645.c| 10
On Thu, Apr 30, 2020 at 7:59 AM Michael Niedermayer
wrote:
> On Wed, Apr 29, 2020 at 02:49:35PM -0700, Mark Reid wrote:
> > On Wed, Apr 29, 2020 at 2:22 PM Michael Niedermayer
>
> > wrote:
> >
> > > On Wed, Apr 29, 2020 at 11:19:56PM +0200, Michael Niedermayer wrote:
> > > > On Tue, Apr 28, 2020
James Almer:
> Fixes ticket #8622
>
> Signed-off-by: James Almer
> ---
> In writing scenarios, it will now ensure bit_equal_to_one is also always
> written when currently defined extension data (like in Buffering Period) is
> present, and not just when unknown extension data is.
>
> libavcodec/
Signed-off-by: Lou Logan
---
After this claim was made in e34e3619a2b kamedo2 did in-depth ABX
testing comparing these encoders:
https://hydrogenaud.io/index.php?topic=111085.0
Result: FFmpeg AAC wasn't as good as libfdk_aac on average.
I know some things have changed since then, "use the fast
On 4/30/2020 3:50 PM, Andreas Rheinhardt wrote:
> James Almer:
>> Fixes ticket #8622
>>
>> Signed-off-by: James Almer
>> ---
>> In writing scenarios, it will now ensure bit_equal_to_one is also always
>> written when currently defined extension data (like in Buffering Period) is
>> present, and no
James Almer:
> On 4/30/2020 3:50 PM, Andreas Rheinhardt wrote:
>> James Almer:
>>> Fixes ticket #8622
>>>
>>> Signed-off-by: James Almer
>>> ---
>>> In writing scenarios, it will now ensure bit_equal_to_one is also always
>>> written when currently defined extension data (like in Buffering Period)
On 4/30/2020 4:15 PM, Andreas Rheinhardt wrote:
> James Almer:
>> On 4/30/2020 3:50 PM, Andreas Rheinhardt wrote:
>>> James Almer:
Fixes ticket #8622
Signed-off-by: James Almer
---
In writing scenarios, it will now ensure bit_equal_to_one is also always
written when c
On 2020-04-28 07:33, Josh de Kock wrote:
On 27/04/2020 07:17, list+ffmpeg-...@jdlh.com wrote:
From: Jim DeLaHunt
This is a complete rewrite of the documentation for the "fps" video
filter. It describes the filter's behaviour more clearly and accurately.
I based the rewrite on reading the sourc
From: Andriy Gelman
A temporary heap array currently stores pids from all streams. It is
used to make sure there are no duplicated pids. However, this array is
not needed because the pids from past streams are stored in the
MpegTSWriteStream structs.
Signed-off-by: Andriy Gelman
---
libavform
From: Andriy Gelman
ts->{tsid,onid} stores the values of
ts->{transport_stream_id,original_network_id}
Signed-off-by: Andriy Gelman
---
libavformat/mpegtsenc.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
inde
This applies the same workaround used elsewhere in the file for handling
overflow of addition.
Signed-off-by: Dale Curtis
---
libavformat/utils.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
no_start_time_overflow.patch
Description: Binary data
___
Aside: This overflow check is used in quite a few places now. I wonder if
it's worth having a function like the following:
int64_t av_no_overflow_add(int64_t a, int64_t b) {
return (a > 0 ? b <= INT64_MAX - a : b >= INT64_MIN - a) ? a + b : a;
}
Better name suggestions welcome... av_maybe_add_t
as per avio_open2 semantics after open_url_keepalive has failed, the options
dictionary
will have been modified and needs restoring before attempting a new connection
vectronic (1):
avformat hls restore options dict when retrying with a new connection
libavformat/hls.c | 4
1 file change
Ping for this patch. Thanks
- dale
On Thu, Apr 23, 2020 at 4:33 PM Dale Curtis wrote:
> This is a patch Chromium has carried for a while, we forgot to send it
> upstream. 7546ac2fee4 made it so that the start_time for mp3 files is
> adjusted for skip_samples. However, this appears incorrect bec
On 2020-04-28 08:50, Carl Eugen Hoyos wrote:
Am Mo., 27. Apr. 2020 um 08:18 Uhr schrieb :
The suggested patch is currently not ok.
Thank you for your review, Carl Eugen. The patch will be the better for
your comments.
My responses interleaved.
…[snip]…
-Convert the video to specified cons
That said, instead of aborting the operation, perhaps it'd make more sense
for library functions to be av_saturated_add(), av_saturated_sub() which
saturate to INT64_MIN/MAX.
- dale
On Thu, Apr 30, 2020 at 1:26 PM Dale Curtis wrote:
> Aside: This overflow check is used in quite a few places now
will apply the patchset 2 and 3.
On Sun, Mar 29, 2020 at 09:08:13AM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavfilter/vf_mix.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/libavfilter/vf_mix.c b/libavfilt
Fixes ticket #8622
Signed-off-by: James Almer
---
libavcodec/cbs_h2645.c| 1 +
libavcodec/cbs_h265.h | 1 +
libavcodec/cbs_h265_syntax_template.c | 85 +--
3 files changed, 70 insertions(+), 17 deletions(-)
diff --git a/libavcodec/cbs_h2
Many places are using their own custom code for handling overflow
around timestamps or other int64_t values. There are enough of these
now that having some common saturated math functions seems sound.
This adds implementations that just use the builtin functions for
recent gcc, clang when availabl
I've sent a follow up patch set implementing saturating operations if
that's something folks are interested in.
- dale
On Thu, Apr 30, 2020 at 2:18 PM Dale Curtis wrote:
> That said, instead of aborting the operation, perhaps it'd make more sense
> for library functions to be av_saturated_add()
Apr 30, 2020, 10:52 by d...@lynne.ee:
> Apr 29, 2020, 16:00 by mich...@niedermayer.cc:
>
>> On Tue, Apr 28, 2020 at 07:22:08PM +0200, Lynne wrote:
>>
>>> Apr 28, 2020, 16:07 by d...@lynne.ee:
>>>
>>> > Apr 28, 2020, 15:59 by mattias.wad...@gmail.com:
>>> >
>>> >>
>>> >>
>>> > Well, I consider CRC
On Tue, Apr 28, 2020 at 12:10:33PM +, Zane van Iperen wrote:
> Signed-off-by: Zane van Iperen
> ---
> Changelog| 1 +
> libavformat/Makefile | 1 +
> libavformat/allformats.c | 1 +
> libavformat/pp_bnk.c | 289 +++
> libavform
Am Fr., 1. Mai 2020 um 00:20 Uhr schrieb Dale Curtis :
>
> Many places are using their own custom code for handling overflow
> around timestamps or other int64_t values. There are enough of these
> now that having some common saturated math functions seems sound.
> This adds implementations that j
On 4/30/2020 8:20 PM, Carl Eugen Hoyos wrote:
> Am Fr., 1. Mai 2020 um 00:20 Uhr schrieb Dale Curtis
> :
>>
>> Many places are using their own custom code for handling overflow
>> around timestamps or other int64_t values. There are enough of these
>> now that having some common saturated math fun
Nicolas George 于2020年4月29日周三 下午9:51写道：
>
> leozhang (12020-04-29):
> > Signed-off-by: leozhang
> > ---
> > doc/muxers.texi| 3 +++
> > libavformat/fifo.c | 19 +++
> > 2 files changed, 22 insertions(+)
> >
> > diff --git a/doc/muxers.texi b/doc/muxers.texi
> > index a74cbc4.
On 4/30/2020 7:19 PM, Dale Curtis wrote:
> Many places are using their own custom code for handling overflow
> around timestamps or other int64_t values. There are enough of these
> now that having some common saturated math functions seems sound.
>
> This adds implementations that just use the bu
On Fri, 1 May 2020 01:09:17 +0200
"Michael Niedermayer" wrote:
> > +size = FFMIN(trk->data_size - ctx->bytes_read,
> > PP_BNK_MAX_READ_SIZE); +
> > +if ((ret = av_get_packet(s->pb, pkt, size)) < 0)
> > +return ret;
> > +
> > +ctx->bytes_read+= ret;
> > +pkt->flags
> 2020年5月1日 上午2:35，vectronic 写道：
>
> as per avio_open2 semantics after open_url_keepalive has failed, the options
> dictionary will have been modified and needs restoring before attempting a
> new connection
>
> Signed-off-by: vectronic
> ---
> libavformat/hls.c | 4
> 1 file changed, 4
On Thu, Apr 30, 2020 at 5:21 PM James Almer wrote:
> On 4/30/2020 7:19 PM, Dale Curtis wrote:
> > Many places are using their own custom code for handling overflow
> > around timestamps or other int64_t values. There are enough of these
> > now that having some common saturated math functions see
A Seek element in a Matroska SeekHead should contain a SeekID and a
SeekPosition element and upon reading, they should be sanitized:
Given that IDs are restricted to 32 bit, longer SeekIDs should be treated
as invalid. Instead currently the lower 32 bits have been used.
For SeekPosition, no check
On Fri, 01 May 2020 00:36:57 +
"Zane van Iperen" wrote:
> On Fri, 1 May 2020 01:09:17 +0200
> "Michael Niedermayer" wrote:
>
> > > +size = FFMIN(trk->data_size - ctx->bytes_read,
> > > PP_BNK_MAX_READ_SIZE); +
> > > +if ((ret = av_get_packet(s->pb, pkt, size)) < 0)
> > > +re
There can be more than one SeekHead in a Matroska file, but most of the
other level 1 elements can only occur once.* Therefore the Matroska
demuxer only allows one entry per ID in its internal list of level 1
elements known to it; the only exception to this are SeekHeads.
The only exception to thi
The Matroska specification allows multiple (level 1) Tags elements per
file, yet our demuxer didn't: While it parsed any amount of Tags
elements it found in front of the Clusters (albeit with warnings because
of duplicate elements), it would treat any Tags element only referenced
via a SeekHead ent
Thank you for the review. Here is a rewrite of the improvement to the fps filter
documentation, based on those comments. Thought it was too wordy before? It
now
has 11% fewer words.
To confirm, no other documentation and no code are affected by this patch.
Comments
On Thu, Apr 30, 2020 at 4:30 AM Kieran Kunhya wrote:
>
> On Thu, 30 Apr 2020 at 07:22, Roger Pack wrote:
>
> > > > c9153590e5f167e41910d867639eb887164e28d2
> > 0001-closed-caption-decoder-accept-and-decode-a-new-codec.patch
> > > > From bf29fe5330e83e37cf064b18918185c6b00d9b9f Mon Sep 17 00:00:00
From: Jim DeLaHunt
Fix unclear wording and spelling mistakes based on review.
Reduce overall word count by 11%. Ready for patch review.
No other docs, and no executable code, are changed.
Signed-off-by: Jim DeLaHunt
---
doc/filters.texi | 157 +--
On 01-05-2020 12:30 am, Lou Logan wrote:
Signed-off-by: Lou Logan
---
After this claim was made in e34e3619a2b kamedo2 did in-depth ABX
testing comparing these encoders:
https://hydrogenaud.io/index.php?topic=111085.0
Result: FFmpeg AAC wasn't as good as libfdk_aac on average.
I know some t
On Fri, 1 May 2020 at 04:59, Roger Pack wrote:
> On Thu, Apr 30, 2020 at 4:30 AM Kieran Kunhya wrote:
> >
> > On Thu, 30 Apr 2020 at 07:22, Roger Pack wrote:
> >
> > > > > c9153590e5f167e41910d867639eb887164e28d2
> > > 0001-closed-caption-decoder-accept-and-decode-a-new-codec.patch
> > > > > Fr
On Thu, Apr 30, 2020 at 9:44 PM Andreas Rheinhardt
wrote:
>
> lance.lmw...@gmail.com:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavformat/mpegts.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavformat/mpegts.c b/libavformat/mpegts.
89 matches
Mail list logo
