Signed-off-by: Steven Liu
---
libavformat/rtmpproto.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
index b741e421af..eb08d4d424 100644
--- a/libavformat/rtmpproto.c
+++ b/libavformat/rtmpproto.c
@@ -2386,7 +2386,7 @@ static
Signed-off-by: Steven Liu
---
libavformat/avidec.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/libavformat/avidec.c b/libavformat/avidec.c
index e3cd844169..1ca26968fa 100644
--- a/libavformat/avidec.c
+++ b/libavformat/avidec.c
@@ -117,8 +117,8 @@ static co
Signed-off-by: Steven Liu
---
libavformat/mms.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/libavformat/mms.c b/libavformat/mms.c
index 768fda6525..16babc0954 100644
--- a/libavformat/mms.c
+++ b/libavformat/mms.c
@@ -60,7 +60,7 @@ int ff_mms_asf_header_pa
Signed-off-by: Steven Liu
---
libavcodec/videotoolbox.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index e9b3370169..8773de3393 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -617,7 +617,7 @@
Signed-off-by: Steven Liu
---
libavformat/network.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/network.c b/libavformat/network.c
index 5664455d18..0f5a575f77 100644
--- a/libavformat/network.c
+++ b/libavformat/network.c
@@ -238,7 +238,7 @@ int ff_accept(i
Signed-off-by: Andreas Rheinhardt
---
libavformat/aiffenc.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavformat/aiffenc.c b/libavformat/aiffenc.c
index dd8b8c3d01..0b837cd264 100644
--- a/libavformat/aiffenc.c
+++ b/libavformat/aiffenc.c
@@ -235,7 +235,7 @@ stat
The check "if (!pb->seekable & AVIO_SEEKABLE_NORMAL)" is wrong, because
! has higher precendence than &. But it is also redundant, because this
part of the code is only ever reached when the AVIO_SEEKABLE_NORMAL flag
is set for pb. So simply remove the check.
Signed-off-by: Andreas Rheinhardt
---
Up until now, aiffenc didn't rely on the standard functions for adding
an element to a linked list and freeing the list, but instead
reimplemented them. This has been changed.
Signed-off-by: Andreas Rheinhardt
---
libavformat/aiffenc.c | 33 -
1 file changed, 4 in
TIFF decoder uses wrong default YCbCrSubsampling value so it breaks
on files that rely on standard default and omit the value.
This patch broke fate-exif-image-tiff and fate-lavf-tiff.
Patch updated, fixed one more error in code: rps check used subsampling even
for non-subsampled formats.
FATE
On Tue, Oct 1, 2019 at 4:19 AM Carl Eugen Hoyos wrote:
> Am Di., 10. Sept. 2019 um 21:12 Uhr schrieb Jun Li :
> >
> > Fix #7637
> > One empty/end sample is created and inserted between two caption lines
> when there is a gap.
> > This patch is to split the sample into multiple ones when its durat
Am So., 25. Aug. 2019 um 17:48 Uhr schrieb James Almer :
>
> On 8/25/2019 11:55 AM, Carl Eugen Hoyos wrote:
> > Am So., 25. Aug. 2019 um 16:15 Uhr schrieb Carl Eugen Hoyos
> > :
> >> Hi!
> >>
> >> x264 removed the usage of strtok(), using FF_CODEC_CAP_INIT_THREADSAFE
> >> is ok with new libx264.
>
Hi there,
TL;DR:
Lots of compile errors when building FFmpeg 4.2 ARM/NEON Code through
gas-preprocessor and armasm(64). Build target is Windows (UWP) ARM and ARM64.
X86 and X64 targets are building fine.
Long Version:
I am building FFmpeg with an MSYS2 environment where ARM/NEON assembly cod
On Tue, 2019-10-01 at 21:41 +0200, Carl Eugen Hoyos wrote:
> Am Di., 1. Okt. 2019 um 21:35 Uhr schrieb Raphaël Zumer <
> rzu...@tebako.net>:
> > On Tue, 2019-10-01 at 20:09 +0100, Derek Buitenhuis wrote:
> > > On 01/10/2019 18:25, James Almer wrote:
> > > > The value in the unused field will be 0xF
Am So., 25. Aug. 2019 um 18:43 Uhr schrieb Carl Eugen Hoyos
:
>
> Am So., 25. Aug. 2019 um 18:38 Uhr schrieb James Almer :
> >
> > On 8/25/2019 1:27 PM, Carl Eugen Hoyos wrote:
> > > Hi!
> > >
> > > Attached patch should fix ticket #7542.
> > >
> > > Please comment, Carl Eugen
> > >
> > >
> > > 000
Am Di., 1. Okt. 2019 um 21:35 Uhr schrieb Raphaël Zumer :
>
> On Tue, 2019-10-01 at 20:09 +0100, Derek Buitenhuis wrote:
> > On 01/10/2019 18:25, James Almer wrote:
> > > The value in the unused field will be 0x after this change
> > > instead of 0, since you're writing 32 bits as duration
On Tue, 2019-10-01 at 20:09 +0100, Derek Buitenhuis wrote:
> On 01/10/2019 18:25, James Almer wrote:
> > The value in the unused field will be 0x after this change
> > instead of 0, since you're writing 32 bits as duration instead of
> > 64
> > where the high 32 bits (corresponding to the u
On Mon, 30 Sep 2019, lance.lmw...@gmail.com wrote:
From: Limin Wang
How to tested it, please try with the following command:
./ffmpeg -f lavfi -i
"smptebars=duration=5:size=1280x720:rate=30,freezedetect=d=1:f=0" -f null -
frame= 150 fps=0.0 q=-0.0 Lsize=N/A time=00:00:05.00 bitrate=N/A s
On Tue, 2019-10-01 at 13:56 -0400, Calvin Walton wrote:
> The ffmpeg code read and wrote a 64bit duration field (in timebase
> units) in the ivf
> header, where the libvpx and chromium code instead use a 32bit frame
> count field, and
> then 32bits of unused (reserved?) space.
>
> Switch ffmpeg to
On 01/10/2019 18:25, James Almer wrote:
> The value in the unused field will be 0x after this change
> instead of 0, since you're writing 32 bits as duration instead of 64
> where the high 32 bits (corresponding to the unused field) are zeroed.
> That means the ivf demuxer prior to this pat
Am Sa., 28. Sept. 2019 um 00:52 Uhr schrieb Lou Logan :
>
> Signed-off-by: Lou Logan
> ---
> fftools/cmdutils.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
> index 6f4031fbb9..84f98b7c04 100644
> --- a/fftools/cmdutils.c
> +
On Sat, Sep 28, 2019, at 5:04 PM, myp...@gmail.com wrote:
>
> LGTM
Pushed
61b7676bd5a6ae79e4a607a600d3741c84ec6d8a
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, o
On Tue, 2019-10-01 at 15:26 -0300, James Almer wrote:
> On 10/1/2019 2:56 PM, Calvin Walton wrote:
> > libavformat/ivfdec.c | 3 ++-
> > libavformat/ivfenc.c | 11 ---
> > 2 files changed, 6 insertions(+), 8 deletions(-)
> >
> > diff --git a/libavformat/ivfdec.c b/libavformat/ivfdec.c
>
Compiling FFmpeg with gas-preprocessor.pl and armasm or armasm64 fails since
FFmpeg 4.2.
New .rdata sections have been added in ARM NEON assembly code (e.g.
libavutil/aarch64/asm.S).
This fix allows gas-preprocessor to translate those sections to armasm
compatible code.
Gas-preprocessor is mai
This is a superset of my patch(es). It should match the behavior of
libvpx more closely, but the validity of the change from duration to
number of frames depends on your interpretation of the reference
implementation, which comments the field as "length".
On Tue, 2019-10-01 at 23:41 +0530, Gyan wr
On 01-10-2019 11:53 PM, James Almer wrote:
On 10/1/2019 3:11 PM, Gyan wrote:
On 01-10-2019 11:26 PM, Calvin Walton wrote:
The ffmpeg code read and wrote a 64bit duration field (in timebase
units) in the ivf
header, where the libvpx and chromium code instead use a 32bit frame
count field, and
On 10/1/2019 2:56 PM, Calvin Walton wrote:
> The ffmpeg code read and wrote a 64bit duration field (in timebase units) in
> the ivf
> header, where the libvpx and chromium code instead use a 32bit frame count
> field, and
> then 32bits of unused (reserved?) space.
>
> Switch ffmpeg to match the
On 10/1/2019 3:11 PM, Gyan wrote:
>
>
> On 01-10-2019 11:26 PM, Calvin Walton wrote:
>> The ffmpeg code read and wrote a 64bit duration field (in timebase
>> units) in the ivf
>> header, where the libvpx and chromium code instead use a 32bit frame
>> count field, and
>> then 32bits of unused (res
On 01-10-2019 11:26 PM, Calvin Walton wrote:
The ffmpeg code read and wrote a 64bit duration field (in timebase units) in
the ivf
header, where the libvpx and chromium code instead use a 32bit frame count
field, and
then 32bits of unused (reserved?) space.
Switch ffmpeg to match the behaviou
The ffmpeg code read and wrote a 64bit duration field (in timebase units) in
the ivf
header, where the libvpx and chromium code instead use a 32bit frame count
field, and
then 32bits of unused (reserved?) space.
Switch ffmpeg to match the behaviour of libvpx & chromium.
Note that libvpx writes
Am Do., 26. Sept. 2019 um 03:48 Uhr schrieb Liu Steven :
>
>
>
> > 在 2019年9月25日，下午8:11，Carl Eugen Hoyos 写道：
> >
> > Am Mi., 25. Sept. 2019 um 11:35 Uhr schrieb Carl Eugen Hoyos
> > :
> >>
> >> Hi!
> >>
> >> Attached patch helps users fixing ticket #8197.
>
> LGTM
Patch applied.
Thank you, Carl E
Thank you for the review. I have left the encoded value as 64 bits and
split the patch into two in the v2 just sent: one for the decoder
change in field size, and one for the encoder comments.
On Tue, 2019-10-01 at 14:25 -0300, James Almer wrote:
> On 10/1/2019 2:05 PM, Raphaël Zumer wrote:
> > Si
Signed-off-by: Raphaël Zumer
---
libavformat/ivfdec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavformat/ivfdec.c b/libavformat/ivfdec.c
index 40ae464b76..4a802573e7 100644
--- a/libavformat/ivfdec.c
+++ b/libavformat/ivfdec.c
@@ -53,7 +53,8 @@ static int read_heade
Signed-off-by: Raphaël Zumer
---
libavformat/ivfenc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
index adf72117e9..ae461a872b 100644
--- a/libavformat/ivfenc.c
+++ b/libavformat/ivfenc.c
@@ -53,7 +53,7 @@ static int ivf_write_
On 10/1/2019 2:05 PM, Raphaël Zumer wrote:
> Signed-off-by: Raphaël Zumer
> ---
> libavformat/ivfdec.c | 3 ++-
> libavformat/ivfenc.c | 5 +++--
> 2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/ivfdec.c b/libavformat/ivfdec.c
> index 40ae464b76..2fdb6f5a04 100644
Signed-off-by: Raphaël Zumer
---
libavformat/ivfdec.c | 3 ++-
libavformat/ivfenc.c | 5 +++--
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/libavformat/ivfdec.c b/libavformat/ivfdec.c
index 40ae464b76..2fdb6f5a04 100644
--- a/libavformat/ivfdec.c
+++ b/libavformat/ivfdec.c
@@ -5
On Mon, Sep 30, 2019 at 10:30:59PM -0300, James Almer wrote:
> On 9/30/2019 1:30 PM, Michael Niedermayer wrote:
> > Fixes: -nan is outside the range of representable values of type 'unsigned
> > short'
>
> From lrint documentation:
>
> "If x is a NaN or an infinity, or the rounded value is too l
Signed-off-by: James Almer
---
libavformat/matroskaenc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index a64ffdb690..37706e56c7 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -1311,6 +1311,9 @@ static in
On 10/1/2019 11:59 AM, Raphaël Zumer wrote:
> Signed-off-by: Raphaël Zumer
> ---
> libavformat/ivfenc.c | 3 ++-
> libavformat/version.h | 2 +-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
> index adf72117e9..54327f5025 100644
Am Di., 1. Okt. 2019 um 16:59 Uhr schrieb Raphaël Zumer :
>
> Signed-off-by: Raphaël Zumer
> ---
> libavformat/ivfenc.c | 3 ++-
> libavformat/version.h | 2 +-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
> index adf72117e9..543
On Tue, Oct 01, 2019 at 10:23:08PM +1000, Peter Ross wrote:
> On Tue, Oct 01, 2019 at 01:12:50AM +0200, Michael Niedermayer wrote:
> > Fixes: Assertion failure
> > Fixes:
> > 17770/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5700606668308480
> >
> > Found-by: continuous fuzzing process
Hi,
I'll apply these in a couple days if no objections. Works ok in my
tests.
- Lauri
___
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...
The IVF format includes a 4-byte field for the number of frames.
I could not find a specification to cite, but for example,
the Chromium IVF parser handles this field.
Please see:
https://chromium.googlesource.com/chromium/src/media/+/master/filters/ivf_parser.h
_
Signed-off-by: Raphaël Zumer
---
libavformat/ivfenc.c | 3 ++-
libavformat/version.h | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
index adf72117e9..54327f5025 100644
--- a/libavformat/ivfenc.c
+++ b/libavformat/ivfenc.c
@@ -53
This patch fixes the remuxing of OPUS audio into MP4 container, as per the
issue described here:
http://ffmpeg.org/pipermail/ffmpeg-user/2019-September/045274.html
but introduces a regression for WEBM recordings.
(Originally posted here, with attachments:
http://ffmpeg.org/pipermail/ffmpeg-user/2
On Tue, Sep 24, 2019 at 10:30:38PM +0800, Kah Goh wrote:
> On Wed, Sep 11, 2019 at 08:28:09PM +0200, Michael Niedermayer wrote:
> > On Wed, Aug 28, 2019 at 11:12:51PM +0800, Kah Goh wrote:
> > > There are differing standards that define different starting line
> > > numbers. For example, VSF TR-03
On Tue, Oct 01, 2019 at 01:12:50AM +0200, Michael Niedermayer wrote:
> Fixes: Assertion failure
> Fixes:
> 17770/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5700606668308480
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signe
Cool :) Please let me know if the attached patch works for you (tried to
follow ffmpeg's code&commit style).
Armin
On Tue, 1 Oct 2019 at 12:16, Carl Eugen Hoyos wrote:
> Am Di., 1. Okt. 2019 um 10:32 Uhr schrieb Armin Hasitzka >:
>
> > sorry for dumping this here with HTML formatting (haven't
Am Mo., 30. Sept. 2019 um 15:37 Uhr schrieb :
>
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavfilter/af_silencedetect.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/af_silencedetect.c b/libavfilter/af_silencedetect.c
> index 3a71f39..c3
Am Di., 10. Sept. 2019 um 21:12 Uhr schrieb Jun Li :
>
> Fix #7637
> One empty/end sample is created and inserted between two caption lines when
> there is a gap.
> This patch is to split the sample into multiple ones when its duration is too
> long (>= INT_MAX).
> ---
> libavformat/movenc.c
Am Di., 1. Okt. 2019 um 10:32 Uhr schrieb Armin Hasitzka :
> sorry for dumping this here with HTML formatting (haven't yet figured out
> how to turn it off in Gmail); we ran into a weird HLS playlist today that
> sends a malformed location header together with a 200 status code (which is
> a misco
Signed-off-by: Paul B Mahol
---
libavformat/mpeg.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavformat/mpeg.c b/libavformat/mpeg.c
index 3205f209e6..6f132aae05 100644
--- a/libavformat/mpeg.c
+++ b/libavformat/mpeg.c
@@ -490,6 +490,7 @@ static int mpegps_read_p
Hi guys,
sorry for dumping this here with HTML formatting (haven't yet figured out
how to turn it off in Gmail); we ran into a weird HLS playlist today that
sends a malformed location header together with a 200 status code (which is
a misconfiguration on a client's system but cannot be changed). A
On Mon, Sep 30, 2019 at 23:22:18 +0800, lance.lmw...@gmail.com wrote:
> +if ( s->force_discard > 0 && frozen)
> +s->drop_count++;
> +else if ( s->force_discard < 0 && frozen && s->drop_count <
> 0) {
> +s->drop_count = 0;
> +
On Mon, Sep 30, 2019 at 21:36:43 +0800, lance.lmw...@gmail.com wrote:
> -The printed times and duration are expressed in seconds.
> +The printed times and duration are expressed in seconds. The
> @code{lavfi.silence_start}
> +or @code{lavfi.silence_start.X} metadata key is set on the first frame w
54 matches
Mail list logo
