Also, test modifying colorspace properties and the default_mode
passthrough which is used here to create a file that has no default
track at all.
Signed-off-by: Andreas Rheinhardt
---
tests/fate/matroska.mak | 8 +++
tests/ref/fate/matroska-spherical-mono-remux | 66 +++
Am Fr., 1. Mai 2020 um 01:31 Uhr schrieb James Almer :
>
> 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
Am Fr., 1. Mai 2020 um 06:05 Uhr schrieb :
>
> From: Jim DeLaHunt
>
> Fix unclear wording and spelling mistakes based on review.
> Reduce overall word count by 11%.
This is heavily misleading and definitely not ok.
> Ready for patch review.
>
> No other docs, and no executable code, are changed
On Sat, Apr 04, 2020 at 08:25:31AM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> doc/encoders.texi | 8
> libavcodec/mpeg12enc.c | 22 +-
> libavcodec/mpegvideo.h | 1 +
> 3 files changed, 26 insertions(+), 5 de
Carl Eugen Hoyos (12020-05-01):
> > -The desired output frame rate. The default is @code{25}.
> > +The output frame rate, in frames per second. May be an integer, real, or
> > +rational number, or an abbreviation. The default is @code{25}.
> I seriously wonder who really profits from this change bu
Am Fr., 1. Mai 2020 um 02:46 Uhr schrieb Dale Curtis :
>
> 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
On Wed, Apr 08, 2020 at 08:45:09AM +0200, Andreas Rheinhardt wrote:
> lance.lmw...@gmail.com:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavformat/dashenc.c | 26 +-
> > 1 file changed, 9 insertions(+), 17 deletions(-)
> >
> > diff --git a/liba
Carl Eugen Hoyos (12020-05-01):
> This patch is not ok, please split it.
What benefit would it serve?
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mail
On Fri, Apr 03, 2020 at 09:03:06PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavformat/concat.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/libavformat/concat.c b/libavformat/concat.c
> index ea3bc1dfde..cfe14760eb 100644
> ---
On Wed, Apr 08, 2020 at 10:10:44AM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> doc/utils.texi | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/doc/utils.texi b/doc/utils.texi
> index 05a2f81626..ca599f145b 100644
> --- a/doc/ut
On Fri, 1 May 2020, lance.lmw...@gmail.com wrote:
On Sat, Apr 04, 2020 at 08:25:31AM +0800, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
doc/encoders.texi | 8
libavcodec/mpeg12enc.c | 22 +-
libavcodec/mpegvideo.h | 1 +
On Fri, May 01, 2020 at 12:32:44PM +0200, Marton Balint wrote:
>
>
> On Fri, 1 May 2020, lance.lmw...@gmail.com wrote:
>
> > On Sat, Apr 04, 2020 at 08:25:31AM +0800, lance.lmw...@gmail.com wrote:
> > > From: Limin Wang
> > >
> > > Signed-off-by: Limin Wang
> > > ---
> > > doc/encoders.texi
Rav1e currently uses the time base given to it only for ratecontrol... where
the inverse is taken and used as a framerate. So, do what we do in other
wrappers
and use the framerate if we can.
Signed-off-by: Derek Buitenhuis
---
Notably, this leaves pkt->pts still broken (it was broken before, to
On 5/1/2020 6:36 AM, Carl Eugen Hoyos wrote:
> Am Fr., 1. Mai 2020 um 01:31 Uhr schrieb James Almer :
>>
>> 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
On Fri, 1 May 2020, lance.lmw...@gmail.com wrote:
On Fri, May 01, 2020 at 12:32:44PM +0200, Marton Balint wrote:
On Fri, 1 May 2020, lance.lmw...@gmail.com wrote:
> On Sat, Apr 04, 2020 at 08:25:31AM +0800, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin W
Fixes: out of array write
Fixes: Regression since f619e1ec66b89215582eff4404b681b760540b4f
Signed-off-by: Michael Niedermayer
---
libavformat/oggdec.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavformat/oggdec.c b/libavformat/oggdec.c
index a9034ea61c..7dd48af66c 100644
--- a/l
Signed-off-by: Michael Niedermayer
---
libavformat/oggdec.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/libavformat/oggdec.c b/libavformat/oggdec.c
index c591bafddd..a9034ea61c 100644
--- a/libavformat/oggdec.c
+++ b/libavformat/oggdec.c
@@ -297,
On Thu, 30 Apr 2020, Tao Zhang wrote:
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:
On Fri, May 01, 2020 at 03:22:32PM +0200, Marton Balint wrote:
>
>
> On Fri, 1 May 2020, lance.lmw...@gmail.com wrote:
>
> > On Fri, May 01, 2020 at 12:32:44PM +0200, Marton Balint wrote:
> > >
> > >
> > > On Fri, 1 May 2020, lance.lmw...@gmail.com wrote:
> > >
> > > > On Sat, Apr 04, 2020 at
On Thu, Apr 30, 2020, at 21:00, Lou Logan wrote:
> -This encoder is the default AAC encoder, natively implemented into FFmpeg.
> Its
> -quality is on par or better than libfdk_aac at the default bitrate of
> 128kbps.
> -This encoder also implements more options, profiles and samplerates than
> -o
Jean-Baptiste Kempf (12020-05-01):
> Is it not true that the encoder implements more options, profiles and
> samplerates?
But even if it is true, does it belong in the introductory part of the
documentation? The many options will be visible in the list of options
anyway. This paragraph looks more
On Fri, 1 May 2020, lance.lmw...@gmail.com wrote:
On Fri, May 01, 2020 at 03:22:32PM +0200, Marton Balint wrote:
On Fri, 1 May 2020, lance.lmw...@gmail.com wrote:
> On Fri, May 01, 2020 at 12:32:44PM +0200, Marton Balint wrote:
> >
> >
> > On Fri, 1 May 2020, lance.lmw...@gmail.com wrote
The discard needs to be checked on a stream even after the first packet is
read. The first packet has already been read as part of calling
avformat_find_stream_info. This means that setting AVStream->discard on a
stream after having determined the stream info for the HLS package had no
effect a
On Thu, 30 Apr 2020, Steven Liu wrote:
2020年4月30日 上午12:29，Marton Balint 写道：
On Sat, 18 Apr 2020, Marton Balint wrote:
Sequence numbers of segments should be unique, if an encoder is using shorter
than 1 second segments and it is restarted, then future segments will be using
already us
On Wed, 29 Apr 2020, Marton Balint wrote:
On Sat, 18 Apr 2020, Marton Balint wrote:
Fixes problems when non-rational options were set using rational
expressions,
causing rounding errors and the option range limits not to be enforced
properly.
ffmpeg -f lavfi -i "sine=r=96000/2"
This ca
After opening an HLS package with avformat_open_input() and then getting stream
info with avformat_find_stream_info() I was then setting some of the input
streams
to be discarded via avStream->discard = AVDISCARD_ALL.
However subsequent calls to av_read_frame() were returning packets from the
st
On Tue, 28 Apr 2020, Marton Balint wrote:
On Sun, 26 Apr 2020, James Almer wrote:
On 4/26/2020 5:34 AM, Marton Balint wrote:
void avcodec_flush_buffers(AVCodecContext *avctx)
{
AVCodecInternal *avci = avctx->internal;
@@ -2117,7 +2001,7 @@ void avcodec_flush_buffers(AVCodecContext
On Sun, 26 Apr 2020, James Almer wrote:
On 4/25/2020 3:55 PM, Marton Balint wrote:
Signed-off-by: Marton Balint
---
fftools/ffmpeg_opt.c | 57 +++-
1 file changed, 3 insertions(+), 54 deletions(-)
diff --git a/fftools/ffmpeg_opt.c b/fftools/f
On Thu, 30 Apr 2020, Andriy Gelman wrote:
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
On Thu, 30 Apr 2020, Andriy Gelman wrote:
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(-)
LGTM, thanks.
Marton
On Wed, 29 Apr 2020, vectronic wrote:
Signed-off-by: vectronic
---
doc/ffprobe.xsd | 1 +
fftools/ffprobe.c | 2 ++
tests/ref/fate/concat-demuxer-extended-lavf-mxf | 2 +-
tests/ref/fate/concat-demuxer-ex
When extra data is updated using AV_PKT_DATA_NEW_EXTRADATA, the data is
written plus extra space is reserved for the max possible size extradata.
But when extradata is written during mkv_write_header, no extra space is
reserved. So the side data update overwrites whatever follows the
extradata in t
John Stebbins:
> When extra data is updated using AV_PKT_DATA_NEW_EXTRADATA, the data is
> written plus extra space is reserved for the max possible size extradata.
> But when extradata is written during mkv_write_header, no extra space is
> reserved. So the side data update overwrites whatever fol
On Fri, May 1, 2020 at 6:12 AM James Almer wrote:
> On 5/1/2020 6:36 AM, Carl Eugen Hoyos wrote:
> >
> > The macro exists to avoid separate patches?
>
> No, it exists to not require configure checks just to enable a path for
> gcc/clang and another for other compilers.
>
Since consensus seems to
Signed-off-by: Dale Curtis
---
libavutil/common.h | 10 ++
1 file changed, 10 insertions(+)
sat_math_builtin_v0.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-dev
On 5/1/2020 2:09 PM, John Stebbins wrote:
> When extra data is updated using AV_PKT_DATA_NEW_EXTRADATA, the data is
> written plus extra space is reserved for the max possible size extradata.
> But when extradata is written during mkv_write_header, no extra space is
> reserved. So the side data upd
On 5/1/2020 2:23 PM, Dale Curtis wrote:
> On Fri, May 1, 2020 at 6:12 AM James Almer wrote:
>
>> On 5/1/2020 6:36 AM, Carl Eugen Hoyos wrote:
>>>
>>> The macro exists to avoid separate patches?
>>
>> No, it exists to not require configure checks just to enable a path for
>> gcc/clang and another
James Almer:
> On 5/1/2020 2:09 PM, John Stebbins wrote:
>> When extra data is updated using AV_PKT_DATA_NEW_EXTRADATA, the data is
>> written plus extra space is reserved for the max possible size extradata.
>> But when extradata is written during mkv_write_header, no extra space is
>> reserved. S
On Fri, May 1, 2020 at 10:32 AM James Almer wrote:
> On 5/1/2020 2:23 PM, Dale Curtis wrote:
> > On Fri, May 1, 2020 at 6:12 AM James Almer wrote:
> >
> >> On 5/1/2020 6:36 AM, Carl Eugen Hoyos wrote:
> >>>
> >>> The macro exists to avoid separate patches?
> >>
> >> No, it exists to not require
Rebased.
On Fri, May 1, 2020 at 10:24 AM Dale Curtis wrote:
> Signed-off-by: Dale Curtis
> ---
> libavutil/common.h | 10 ++
> 1 file changed, 10 insertions(+)
>
sat_math_builtin_v1.patch
Description: Binary data
___
ffmpeg-devel mailing li
On Fri, 2020-05-01 at 19:22 +0200, Andreas Rheinhardt wrote:
> John Stebbins:
> > When extra data is updated using AV_PKT_DATA_NEW_EXTRADATA, the
> > data is
> > written plus extra space is reserved for the max possible size
> > extradata.
> > But when extradata is written during mkv_write_header,
John Stebbins (12020-05-01):
> The test case is a TS file with aac audio. It TS files, it is
> certainly possible for stream parameters to change on the fly. But, if
> the extradata changes, there's really no way to handle it in mkv since
> this data is global in mkv. So perhaps a better solution
John Stebbins:
> On Fri, 2020-05-01 at 19:22 +0200, Andreas Rheinhardt wrote:
>> John Stebbins:
>>> When extra data is updated using AV_PKT_DATA_NEW_EXTRADATA, the
>>> data is
>>> written plus extra space is reserved for the max possible size
>>> extradata.
>>> But when extradata is written during
Am Fr., 1. Mai 2020 um 19:41 Uhr schrieb Dale Curtis :
>
> On Fri, May 1, 2020 at 10:32 AM James Almer wrote:
>
> > On 5/1/2020 2:23 PM, Dale Curtis wrote:
> > > On Fri, May 1, 2020 at 6:12 AM James Almer wrote:
> > >
> > >> On 5/1/2020 6:36 AM, Carl Eugen Hoyos wrote:
> > >>>
> > >>> The macro e
On Fri, 2020-05-01 at 14:27 -0300, James Almer wrote:
> On 5/1/2020 2:09 PM, John Stebbins wrote:
> > When extra data is updated using AV_PKT_DATA_NEW_EXTRADATA, the
> > data is
> > written plus extra space is reserved for the max possible size
> > extradata.
> > But when extradata is written durin
John Stebbins:
> On Fri, 2020-05-01 at 14:27 -0300, James Almer wrote:
>> On 5/1/2020 2:09 PM, John Stebbins wrote:
>>> When extra data is updated using AV_PKT_DATA_NEW_EXTRADATA, the
>>> data is
>>> written plus extra space is reserved for the max possible size
>>> extradata.
>>> But when extradat
On Fri, 2020-05-01 at 19:53 +0200, Nicolas George wrote:
> John Stebbins (12020-05-01):
> > The test case is a TS file with aac audio. It TS files, it is
> > certainly possible for stream parameters to change on the fly. But,
> > if
> > the extradata changes, there's really no way to handle it in
Am Fr., 1. Mai 2020 um 19:24 Uhr schrieb Dale Curtis :
>
> Signed-off-by: Dale Curtis
> ---
> libavutil/common.h | 10 ++
> 1 file changed, 10 insertions(+)
Imo, this is guaranteed to break x86 compilation with some unusual
toolchain.
I looked carefully at all occurrences of AV_GCC_VERSI
John Stebbins (12020-05-01):
> If the parameters change on the fly, some part of the audio stream is
> going to be unplayable. Either the part after the change will be
> unplayable if you ignore extradata changes, or everything preceeding
> the last extradata change will be unplayable if you rewr
On Fri, 2020-05-01 at 19:55 +0200, Andreas Rheinhardt wrote:
> John Stebbins:
> > On Fri, 2020-05-01 at 19:22 +0200, Andreas Rheinhardt wrote:
> > > John Stebbins:
> > > > When extra data is updated using AV_PKT_DATA_NEW_EXTRADATA, the
> > > > data is
> > > > written plus extra space is reserved fo
On Fri, 2020-05-01 at 20:03 +0200, Andreas Rheinhardt wrote:
> John Stebbins:
> > On Fri, 2020-05-01 at 14:27 -0300, James Almer wrote:
> > > On 5/1/2020 2:09 PM, John Stebbins wrote:
> > > > When extra data is updated using AV_PKT_DATA_NEW_EXTRADATA, the
> > > > data is
> > > > written plus extra
On Fri, 2020-05-01 at 20:10 +0200, Nicolas George wrote:
> John Stebbins (12020-05-01):
> > If the parameters change on the fly, some part of the audio stream
> > is
> > going to be unplayable. Either the part after the change will be
> > unplayable if you ignore extradata changes, or everything
>
On 5/1/2020 3:07 PM, Carl Eugen Hoyos wrote:
> Am Fr., 1. Mai 2020 um 19:24 Uhr schrieb Dale Curtis
> :
>>
>> Signed-off-by: Dale Curtis
>> ---
>> libavutil/common.h | 10 ++
>> 1 file changed, 10 insertions(+)
>
> Imo, this is guaranteed to break x86 compilation with some unusual
> too
On Fri, May 1, 2020, at 6:56 AM, Jean-Baptiste Kempf wrote:
>
> Is it not true that the encoder implements more options, profiles and
> samplerates?
ffaacenc has 1 additional AVoption compared to libfdk_aac; if that
means anything.
ffaacenc supports 1 additional sample rate (7350) compared to
li
John Stebbins (12020-05-01):
> Well, current code in aac_adtstoasc silently ignores any changes. It
> only generates extradata from the initial packet. It's not checked in
> subsequent packets.
>
> So this would have to be "fixed" in aac_adtstoasc as well if you want
> to add error logging.
Pro
On Fri, May 1, 2020 at 10:57 AM Carl Eugen Hoyos wrote:
> Could you confirm that you attached the wrong patch?
>
No, I sent the patches without completing the rebase. Sorry.
- dale
sat_math_v4.patch
Description: Binary data
___
ffmpeg-devel mailing
On Fri, May 1, 2020 at 11:22 AM James Almer wrote:
> On 5/1/2020 3:07 PM, Carl Eugen Hoyos wrote:
> > Am Fr., 1. Mai 2020 um 19:24 Uhr schrieb Dale Curtis <
> dalecur...@chromium.org>:
> >>
> >> Signed-off-by: Dale Curtis
> >> ---
> >> libavutil/common.h | 10 ++
> >> 1 file changed, 10
I needed this fix to make [Shinobi](https://github.com/ShinobiCCTV/Shinobi)
works with recent chinese cameras.
We can read that FFmpeg is perfectly following the [RTSP
specs](https://tools.ietf.org/html/rfc2326#page-58) :
`Transports are comma separated, listed in order of preference. Paramete
On 01/05/2020 17:46, Lynne wrote:
> May 1, 2020, 12:31 by derek.buitenh...@gmail.com:
>
>> Rav1e currently uses the time base given to it only for ratecontrol... where
>> the inverse is taken and used as a framerate. So, do what we do in other
>> wrappers
>> and use the framerate if we can.
>>
>>
On Fri, May 01, 2020 at 06:47:54PM +0200, Lynne wrote:
> May 1, 2020, 14:16 by mich...@niedermayer.cc:
>
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavformat/oggdec.c | 25 +
> > 1 file changed, 17 insertions(+), 8 deletions(-)
> >
> > diff --git a/libavformat/o
On Fri, 2020-05-01 at 20:28 +0200, Nicolas George wrote:
> John Stebbins (12020-05-01):
> > Well, current code in aac_adtstoasc silently ignores any
> > changes. It
> > only generates extradata from the initial packet. It's not checked
> > in
> > subsequent packets.
> >
> > So this would have to
Am Fr., 1. Mai 2020 um 20:22 Uhr schrieb James Almer :
>
> On 5/1/2020 3:07 PM, Carl Eugen Hoyos wrote:
> > Am Fr., 1. Mai 2020 um 19:24 Uhr schrieb Dale Curtis
> > :
> >>
> >> Signed-off-by: Dale Curtis
> >> ---
> >> libavutil/common.h | 10 ++
> >> 1 file changed, 10 insertions(+)
> >
On 5/1/2020 4:27 PM, Carl Eugen Hoyos wrote:
> Am Fr., 1. Mai 2020 um 20:22 Uhr schrieb James Almer :
>>
>> On 5/1/2020 3:07 PM, Carl Eugen Hoyos wrote:
>>> Am Fr., 1. Mai 2020 um 19:24 Uhr schrieb Dale Curtis
>>> :
Signed-off-by: Dale Curtis
---
libavutil/common.h | 10 +
Am Fr., 1. Mai 2020 um 21:34 Uhr schrieb James Almer :
>
> On 5/1/2020 4:27 PM, Carl Eugen Hoyos wrote:
> > Am Fr., 1. Mai 2020 um 20:22 Uhr schrieb James Almer :
> >>
> >> On 5/1/2020 3:07 PM, Carl Eugen Hoyos wrote:
> >>> Am Fr., 1. Mai 2020 um 19:24 Uhr schrieb Dale Curtis
> >>> :
>
>
Am Fr., 1. Mai 2020 um 21:13 Uhr schrieb John Stebbins
:
>
> On Fri, 2020-05-01 at 20:28 +0200, Nicolas George wrote:
> > John Stebbins (12020-05-01):
> > > Well, current code in aac_adtstoasc silently ignores any
> > > changes. It
> > > only generates extradata from the initial packet. It's not
On 5/1/2020 4:37 PM, Carl Eugen Hoyos wrote:
> Am Fr., 1. Mai 2020 um 21:34 Uhr schrieb James Almer :
>>
>> On 5/1/2020 4:27 PM, Carl Eugen Hoyos wrote:
>>> Am Fr., 1. Mai 2020 um 20:22 Uhr schrieb James Almer :
On 5/1/2020 3:07 PM, Carl Eugen Hoyos wrote:
> Am Fr., 1. Mai 2020 um 19:
John Stebbins:
> On Fri, 2020-05-01 at 20:28 +0200, Nicolas George wrote:
>> John Stebbins (12020-05-01):
>>> Well, current code in aac_adtstoasc silently ignores any
>>> changes. It
>>> only generates extradata from the initial packet. It's not checked
>>> in
>>> subsequent packets.
>>>
>>> So t
Am Fr., 1. Mai 2020 um 21:42 Uhr schrieb James Almer :
>
> On 5/1/2020 4:37 PM, Carl Eugen Hoyos wrote:
> > Am Fr., 1. Mai 2020 um 21:34 Uhr schrieb James Almer :
> >>
> >> On 5/1/2020 4:27 PM, Carl Eugen Hoyos wrote:
> >>> Am Fr., 1. Mai 2020 um 20:22 Uhr schrieb James Almer :
>
> On 5/1
On Fri, May 1, 2020 at 12:37 PM Carl Eugen Hoyos wrote:
> >
> > So ICC on Linux defines __GNUC__ >= 5 yet doesn't support these builtins?
>
> No, but yes, this is the effect.
>
Does this patch work instead on the ICC compiler? GCC 4.2+ have support for
__has_builtin() which shouldn't be masquera
On Fri, May 1, 2020 at 12:50 PM Dale Curtis wrote:
> On Fri, May 1, 2020 at 12:37 PM Carl Eugen Hoyos
> wrote:
>
>> >
>> > So ICC on Linux defines __GNUC__ >= 5 yet doesn't support these
>> builtins?
>>
>> No, but yes, this is the effect.
>>
>
> Does this patch work instead on the ICC compiler?
On Thu, Apr 30, 2020 at 05:39:43PM -0700, Dale Curtis wrote:
> 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 enoug
On Fri, 1 May 2020, abalam wrote:
I needed this fix to make [Shinobi](https://github.com/ShinobiCCTV/Shinobi)
works with recent chinese cameras.
We can read that FFmpeg is perfectly following the [RTSP
specs](https://tools.ietf.org/html/rfc2326#page-58) :
`Transports are comma separated,
Andreas Rheinhardt (12020-05-01):
> I'd rather opt to only warn in such a case unless strict_std_compliance
> is >= FF_COMPLIANCE_STRICT. And maybe we should also discard all future
> packets from this stream until we get one with side data matching the
> CodecPrivate one?
It is not a matter of st
On 5/1/2020 4:46 PM, Carl Eugen Hoyos wrote:
> Am Fr., 1. Mai 2020 um 21:42 Uhr schrieb James Almer :
>>
>> On 5/1/2020 4:37 PM, Carl Eugen Hoyos wrote:
>>> Am Fr., 1. Mai 2020 um 21:34 Uhr schrieb James Almer :
On 5/1/2020 4:27 PM, Carl Eugen Hoyos wrote:
> Am Fr., 1. Mai 2020 um 20:
Am Fr., 1. Mai 2020 um 21:58 Uhr schrieb James Almer :
>
> On 5/1/2020 4:46 PM, Carl Eugen Hoyos wrote:
> > Am Fr., 1. Mai 2020 um 21:42 Uhr schrieb James Almer :
> >>
> >> On 5/1/2020 4:37 PM, Carl Eugen Hoyos wrote:
> >>> Am Fr., 1. Mai 2020 um 21:34 Uhr schrieb James Almer :
>
> On 5/1
On 5/1/2020 5:01 PM, Carl Eugen Hoyos wrote:
> Am Fr., 1. Mai 2020 um 21:58 Uhr schrieb James Almer :
>>
>> On 5/1/2020 4:46 PM, Carl Eugen Hoyos wrote:
>>> Am Fr., 1. Mai 2020 um 21:42 Uhr schrieb James Almer :
On 5/1/2020 4:37 PM, Carl Eugen Hoyos wrote:
> Am Fr., 1. Mai 2020 um 21:
On 5/1/2020 4:50 PM, Dale Curtis wrote:
> On Fri, May 1, 2020 at 12:37 PM Carl Eugen Hoyos wrote:
>
>>>
>>> So ICC on Linux defines __GNUC__ >= 5 yet doesn't support these builtins?
>>
>> No, but yes, this is the effect.
>>
>
> Does this patch work instead on the ICC compiler? GCC 4.2+ have supp
Am Fr., 1. Mai 2020 um 22:06 Uhr schrieb James Almer :
>
> On 5/1/2020 4:50 PM, Dale Curtis wrote:
> > On Fri, May 1, 2020 at 12:37 PM Carl Eugen Hoyos wrote:
> >
> >>>
> >>> So ICC on Linux defines __GNUC__ >= 5 yet doesn't support these builtins?
> >>
> >> No, but yes, this is the effect.
> >>
>
On Fri, May 1, 2020 at 12:53 PM Michael Niedermayer
wrote:
> On Thu, Apr 30, 2020 at 05:39:43PM -0700, Dale Curtis wrote:
> > 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 ove
Am Fr., 1. Mai 2020 um 22:05 Uhr schrieb James Almer :
> Unless you explain why, with details, I'll have to ignore you.
https://ffmpeg.org/pipermail/ffmpeg-devel/2020-May/261801.html
This email and a follow-up from you are offending and annoying, and
it was indeed a waste of time to discuss this
On Fri, May 1, 2020 at 1:12 PM Carl Eugen Hoyos wrote:
> Am Fr., 1. Mai 2020 um 22:06 Uhr schrieb James Almer :
> > Just make the check
> >
> > (AV_GCC_VERSION_AT_LEAST(5,1) || defined(__clang__)) &&
> > !defined(__INTEL_COMPILER)
>
> And switch the conditions.
>
Thanks. Done.
- dale
From 84a19
May 1, 2020, 12:31 by derek.buitenh...@gmail.com:
> Rav1e currently uses the time base given to it only for ratecontrol... where
> the inverse is taken and used as a framerate. So, do what we do in other
> wrappers
> and use the framerate if we can.
>
> Signed-off-by: Derek Buitenhuis
> ---
> No
May 1, 2020, 14:16 by mich...@niedermayer.cc:
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/oggdec.c | 25 +
> 1 file changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/libavformat/oggdec.c b/libavformat/oggdec.c
> index c591bafddd..a9034ea61c 100644
>
May 1, 2020, 14:16 by mich...@niedermayer.cc:
> Fixes: out of array write
> Fixes: Regression since f619e1ec66b89215582eff4404b681b760540b4f
>
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/oggdec.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/libavformat/oggdec.c b/l
Am Fr., 1. Mai 2020 um 22:16 Uhr schrieb Dale Curtis :
>
> On Fri, May 1, 2020 at 1:12 PM Carl Eugen Hoyos wrote:
>
> > Am Fr., 1. Mai 2020 um 22:06 Uhr schrieb James Almer :
> > > Just make the check
> > >
> > > (AV_GCC_VERSION_AT_LEAST(5,1) || defined(__clang__)) &&
> > > !defined(__INTEL_COMPIL
On Thu, Apr 30, 2020 at 07:53:03PM +0200, Paul B Mahol wrote:
> LGTM
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liber
Hi!
Attached patch, inspired by a patch by Andreas, fixes the following
warning when -Wpedantic is used:
CC libavutil/threadmessage.o
libavutil/threadmessage.c: In function ‘av_thread_message_flush’:
libavutil/threadmessage.c:222:23: warning: ISO C forbids
initialization between function poin
On Fri, May 1, 2020 at 2:00 PM Carl Eugen Hoyos wrote:
> Am Fr., 1. Mai 2020 um 22:16 Uhr schrieb Dale Curtis <
> dalecur...@chromium.org>:
> >
> > On Fri, May 1, 2020 at 1:12 PM Carl Eugen Hoyos
> wrote:
> >
> > > Am Fr., 1. Mai 2020 um 22:06 Uhr schrieb James Almer <
> jamr...@gmail.com>:
> >
Hi!
Attached patch fixes an ugly warning when compiling with -Wpedantic.
I am not in favour of adding casts to silence such warnings, but there
already is an incorrect cast.
Please comment, Carl Eugen
From ed41ff40b9e1bff357b52394dcfa1107dc4ada74 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
D
> 2020年5月1日 下午11:24，vectronic 写道：
>
> After opening an HLS package with avformat_open_input() and then getting
> stream
> info with avformat_find_stream_info() I was then setting some of the input
> streams
> to be discarded via avStream->discard = AVDISCARD_ALL.
>
> However subsequent calls
> 2020年4月29日 下午12:50，Steven Liu 写道：
>
> fix ticket: 8625
> and add testcase into url for double dot corner case
>
> Signed-off-by: Steven Liu
> ---
> libavformat/tests/url.c | 5 +++
> libavformat/url.c | 77 ++---
> tests/ref/fate/url | 5 +++
>
> From: Martin Storsjö
> Sent: Tuesday, April 28, 2020 04:09
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: Fu, Linjie
> Subject: Re: [FFmpeg-devel] [PATCH v4 7/9] lavc/libopenh264enc: add profile
> high option support
>
> On Wed, 15 Apr 2020, Linjie Fu wrote:
>
> > A
On Fri, May 1, 2020 at 12:22 AM Kieran Kunhya wrote:
>
> 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-
> From: ffmpeg-devel On Behalf Of
> Martin Storsjö
> Sent: Tuesday, April 28, 2020 04:13
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: Fu, Linjie
> Subject: Re: [FFmpeg-devel] [PATCH v4 8/9] lavc/libopenh264enc: allow
> specifying the profile through AVCodecContext
>
Hi,
On Tue, Apr 28, 2020 at 12:58 AM Paul B Mahol wrote:
>
> On 4/26/20, Sebastian Dröge wrote:
> > From: Sebastian Dröge
> >
> > s->target_i and global are in dB but s->target_tp and true_peak are
> > linear. Instead of mixing these in the calculations, convert the former
> > first to have all
95 matches
Mail list logo
