On Sun, 16 May 2021, Timo Rothenpieler wrote:
On 16.05.2021 19:46, Jan Ekström wrote:
If you have interest in figuring out building binaries for
distribution, I would recommend contributing to one of the public and
automated build systems such as https://github.com/BtbN/FFmpeg-Builds
.
On Mon, 17 May 2021, Martin Storsjö wrote:
This is marginally slower, but correct for all input values.
The previous implementation failed with certain input seeds, e.g.
"checkasm --test=hevc_idct 98".
---
libavcodec/aarch64/hevcdsp_idct_neon.S | 11 +--
1 file changed, 5
Hi,
On Fri, 14 May 2021, Josh Allmann wrote:
On Thu, 13 May 2021 at 16:38, Josh Allmann wrote:
Previously, one or the other would have been ignored, but not both.
Since the probe terminates at three streams, it could exit
prematurely if both data and subtitles are present along with
On Thu, 13 May 2021, Josh Allmann wrote:
Previously, one or the other would have been ignored, but not both.
Since the probe terminates at three streams, it could exit
prematurely if both data and subtitles are present along with
slightly trailing media, usually video trailing audio.
Trailing
Hi,
On Fri, 9 Apr 2021, Camille Gonnet wrote:
Parityfec (RFC 2733) and ulpfec (RFC 5109) generic FEC encoding for RTP streams.
Signed-off-by: Camille Gonnet
---
Changelog | 1 +
doc/general_contents.texi | 1 +
doc/protocols.texi| 106 +
libavformat/Makefile
On Sun, 4 Jul 2021, Andriy Gelman wrote:
From: Andriy Gelman
Currently it is only checked that the rtp port does not exceed rtp_port_max.
Signed-off-by: Andriy Gelman
---
libavformat/rtsp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/rtsp.c
On Fri, 25 Jun 2021, Hayden Myers wrote:
Some encoders send GET_PARAMETER requests as a keep-alive mechanism.
If the client doesn't reply with an OK message, the encoder will close
the session. This was encountered with the impath i5110 encoder, when
the RTSP Keep-Alive checkbox is enabled
On Thu, 1 Jul 2021, Jan Ekström wrote:
On Thu, Jul 1, 2021 at 5:16 PM James Almer wrote:
From: Matthieu Patou
Suggested-by: ffm...@fb.com
Signed-off-by: James Almer
---
For the record, if Big Companies such as FB or Bilibili want to keep
on dragging FLV/RTMP around I recommend:
1.
On Tue, 22 Jun 2021, Jan Ekström wrote:
From: Jan Ekström
Includes basic support for both the ISMV ('dfxp') and MP4 ('stpp')
methods. This initial version also foregoes fragmentation support
as this eases the initial review.
Hmm, I'm not sure I understand here, this seems to add at least
On Sat, 26 Jun 2021, Martin Storsjö wrote:
On Fri, 25 Jun 2021, Hayden Myers wrote:
Some encoders send GET_PARAMETER requests as a keep-alive mechanism.
If the client doesn't reply with an OK message, the encoder will close
the session. This was encountered with the impath i5110 encoder
On Wed, 28 Apr 2021, Josh Dekker wrote:
From: Rafal Dabrowa
First a couple technical details:
The use of '.ifeqs "\op", "sshr"' needs to be changed into '.ifc \op,
sshr', because gas-preprocessor doesn't implement '.ifeqs'.
The checkasm tests for hevc_pel that were added in
On Tue, 4 May 2021, Steinar H. Gunderson wrote:
On Tue, May 04, 2021 at 04:46:29PM +0100, Derek Buitenhuis wrote:
Can this not be accomplished outside of FFmpeg, by registering your own I/O
callbacks? That would seem to me to be the 'proper' way to do this. More
work? Yes. But less hacky.
Hi Reimar,
On Sat, 16 Jan 2021, Martin Storsjö wrote:
+.macro idct_16x16 bitdepth
+function ff_hevc_idct_16x16_\bitdepth\()_neon, export=1
+//r0 - coeffs
+mov x15, lr
+
Binutils doesn't recognize "lr" as alias for x30
It didn’t have an issue in the Debian u
On Thu, 4 Feb 2021, Josh Dekker wrote:
From: Reimar Döffinger
Speedup is fairly small, around 1.5%, but these are fairly simple.
Signed-off-by: Josh Dekker
---
libavcodec/aarch64/hevcdsp_idct_neon.S| 190 ++
libavcodec/aarch64/hevcdsp_init_aarch64.c | 24 +++
2 files
On Thu, 4 Feb 2021, Josh Dekker wrote:
From: Reimar Döffinger
Makes SIMD-optimized 8x8 and 16x16 idcts for 8 and 10 bit depth
available on aarch64.
For a UHD HDR (10 bit) sample video these were consuming the most time
and this optimization reduced overall decode time from 19.4s to 16.4s,
On Thu, 4 Feb 2021, Josh Dekker wrote:
Signed-off-by: Josh Dekker
---
libavcodec/aarch64/hevcdsp_idct_neon.S| 54 +++
libavcodec/aarch64/hevcdsp_init_aarch64.c | 16 +++
2 files changed, 70 insertions(+)
diff --git a/libavcodec/aarch64/hevcdsp_idct_neon.S
On Thu, 4 Feb 2021, Josh Dekker wrote:
Only works for 8x8.
Signed-off-by: Josh Dekker
---
libavcodec/aarch64/Makefile | 3 +-
libavcodec/aarch64/hevcdsp_init_aarch64.c | 7 ++
libavcodec/aarch64/hevcdsp_sao_neon.S | 87 +++
3 files changed, 96
---
libavformat/tls_gnutls.c | 30 +-
1 file changed, 21 insertions(+), 9 deletions(-)
diff --git a/libavformat/tls_gnutls.c b/libavformat/tls_gnutls.c
index f9d5af7096..741578a596 100644
--- a/libavformat/tls_gnutls.c
+++ b/libavformat/tls_gnutls.c
@@ -51,6 +51,7 @@
Print every error in the stack, if more than one, and don't print
bogus errors if there's none logged within OpenSSL.
Retain the underlying IO error code, print an error message out of
it, and pass the error code on to the caller.
---
libavformat/tls_openssl.c | 41
On Fri, 26 Mar 2021, Martin Storsjö wrote:
Print every error in the stack, if more than one, and don't print
bogus errors if there's none logged within OpenSSL.
Retain the underlying IO error code, print an error message out of
it, and pass the error code on to the caller.
---
libavformat
---
libavformat/mov.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index a1411264ec..162772f499 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -410,7 +410,18 @@ retry:
str_size =
They can be other incompatible text encodings (such as UTF-16),
or even binary data.
---
libavformat/mov.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 162772f499..f539bca1f0 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@
This fixes building with MSVC after
a2a38b160620d91bc3f895dadc4501c589998b9c.
Remove the stray semicolon, and add casts for the input argument
(which is an intptr_t*) to the right type (void *volatile *).
---
compat/atomics/win32/stdatomic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
This fixes building with MSVC after
a2a38b160620d91bc3f895dadc4501c589998b9c.
Remove the stray semicolon, and add casts for the input argument
(which is an intptr_t*) to the right type (void *volatile *).
---
Changed to use PVOID.
---
compat/atomics/win32/stdatomic.h | 2 +-
1 file changed, 1
On Fri, 12 Mar 2021, Derek Buitenhuis wrote:
Files with the "dash" major brand are guaranteed to only have a single
initialization range for the whole file. We can check this and stop
appropriately - which is useful, as the existing check to see if the
offset reaches the end of the file is not
If b-frames were enabled implicitly (if max_b_frames wasn't set by
the caller at all, since a0949d0bcb0eee2f3fffcf9a4810c0295d14c0dc),
we wouldn't offset dts at all, producing invalid pts/dts combinations
(causing loud warnings by ffmpeg, or muxer errors if passed without
an extra cleanup pass).
On Sat, 13 Mar 2021, Andriy Gelman wrote:
From: Andriy Gelman
Commit 8c8e5d5286bf598a89ef9993a2cf6ea409d03a32 added a way to reduce
seek time by waiting for the windowed tcp packets instead of creating a
new socket connection. It implemented this by overwriting
s->short_seek_threshold in the
Since a0949d0bcb0eee2f3fffcf9a4810c0295d14c0dc, the b-frames
setting defaults to -1, which uses the preset's default setting.
If b-frames are enabled, but max_b_frames is kept at <= 0, the
output dts are inconsistent.
---
libavcodec/nvenc.c | 5 -
1 file changed, 4 insertions(+), 1
On Tue, 9 Mar 2021, Martin Storsjö wrote:
Since a0949d0bcb0eee2f3fffcf9a4810c0295d14c0dc, the b-frames
setting defaults to -1, which uses the preset's default setting.
If b-frames are enabled, but max_b_frames is kept at <= 0, the
output dts are inconsistent.
---
libavcodec/nvenc.c | 5
On Wed, 10 Mar 2021, Derek Buitenhuis wrote:
Files with the "dash" major brand are guaranteed to only have a single
initialization range for the whole file. We can check this and stop
appropriately - which is useful, as the existing check to see if the
offset reaches the end of the file is not
Hi Thilo,
On Sun, 28 Feb 2021, Thilo Borgmann wrote:
it's my first attempt to do some assembly, it might still includes some dont's
of the asm world...
Tested with gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Speed-wise, it sees a drop for small prediction orders until around 10 or 11.
Well, the
On Thu, 8 Apr 2021, Mikhail Nitenko wrote:
here are the benchmarks https://0x1.st/kX.txt
---
libavcodec/aarch64/h264pred_init.c | 75 +++---
libavcodec/aarch64/h264pred_neon.S | 123 +
2 files changed, 168 insertions(+), 30 deletions(-)
av_cold void
On Thu, 1 Apr 2021, Martin Storsjö wrote:
---
libavformat/mov.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
Ping
// Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo
On Thu, 1 Apr 2021, Martin Storsjö wrote:
They can be other incompatible text encodings (such as UTF-16),
or even binary data.
---
libavformat/mov.c | 8
1 file changed, 8 insertions(+)
Ping
// Martin
___
ffmpeg-devel mailing list
ffmpeg
Move the loop counter decrement further from the branch instruction,
this hides the latency of the decrement.
In loops that first load, then store (the horizontal prediction cases),
do the decrement after the load (where the next instruction would
stall a bit anyway, waiting for the result of the
On Thu, 15 Apr 2021, Mikhail Nitenko wrote:
Change structure to allow the addition of other bit depths.
---
libavcodec/aarch64/h264pred_init.c | 57 ++
1 file changed, 27 insertions(+), 30 deletions(-)
OK I guess.
// Martin
On Thu, 15 Apr 2021, Mikhail Nitenko wrote:
Benchmarks: A53 A72
pred16x16_dc_10_c: 136.0 124.0
pred16x16_dc_10_neon: 121.2 106.0
pred16x16_horizontal_10_c: 155.073.2
pred16x16_horizontal_10_neon:82.267.7
pred16x16_top_dc_10_c:
On Tue, 13 Apr 2021, Josh Dekker wrote:
Signed-off-by: Josh Dekker
---
configure| 2 +
tests/checkasm/Makefile | 1 +
tests/checkasm/checkasm.c| 19 -
tests/checkasm/checkasm.h| 10 ++-
tests/checkasm/macos_kperf.c | 143
On Tue, 13 Apr 2021, Mikhail Nitenko wrote:
Benchmarks:
pred16x16_dc_10_c: 124.0
pred16x16_dc_10_neon: 97.2
pred16x16_horizontal_10_c: 71.7
pred16x16_horizontal_10_neon: 66.2
pred16x16_top_dc_10_c: 90.7
pred16x16_top_dc_10_neon: 71.5
pred16x16_vertical_10_c: 64.7
pred16x16_vertical_10_neon:
On Tue, 13 Apr 2021, Lynne wrote:
Could you move this to libavutil and hook this up to libavutil/timer.h
as well?
I'm a bit hesitant about that, as the API (just like the existing linux
perf integration which is predecent for heavyweight timer APIs) requires a
bit more setup than what
This is much less precise than the cycle counter register, but
the cycle counter register is not available on apple platforms
(and on linux, it requires a kernel module for allowing user mode
access).
---
libavutil/aarch64/timer.h | 8 +++-
libavutil/arm/timer.h | 8 +++-
2 files
On Fri, 12 Feb 2021, Martin Storsjö wrote:
This is much less precise than the cycle counter register, but
the cycle counter register is not available on apple platforms
(and on linux, it requires a kernel module for allowing user mode
access).
---
libavutil/aarch64/timer.h | 8
On Mon, 16 Aug 2021, Mikhail Nitenko wrote:
Benchmarks: A53 A72
h264_h_loop_filter_chroma422_10bpp_c: 277.5 114.2
h264_h_loop_filter_chroma422_10bpp_neon: 109.781.7
h264_h_loop_filter_chroma_10bpp_c:
On Mon, 16 Aug 2021, Mikhail Nitenko wrote:
Benchmarks:A53 A72
pred8x8_dc_10_c: 64.255.7
pred8x8_dc_10_neon:61.753.7
pred8x8_dc_128_10_c: 26.020.7
pred8x8_dc_128_10_neon:30.724.5
On Tue, 17 Aug 2021, James Almer wrote:
On 8/17/2021 12:35 PM, Christopher Degawa wrote:
Fixes https://trac.ffmpeg.org/ticket/8903
relevant https://github.com/msys2/MINGW-packages/discussions/9258
Signed-off-by: Christopher Degawa
---
libavcodec/x86/cabac.h | 9 +++--
1 file changed,
On Tue, 17 Aug 2021, Christopher Degawa wrote:
Fixes https://trac.ffmpeg.org/ticket/8903
relevant https://github.com/msys2/MINGW-packages/discussions/9258
Signed-off-by: Christopher Degawa
---
libavcodec/x86/cabac.h | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git
> On Aug 23, 2021, at 17:41, Nicolas George wrote:
>
> Michael Niedermayer (12021-08-23):
>> Please make sure you use g...@git.ffmpeg.org:fateserver not
>> g...@source.ffmpeg.org:fateserver
>
> My bad. I fixed it and it worked.
Thanks for looking into these issues and bringing the fate site
alternatively fix the test
to only test things that the real decoder does, and this modification
could be reverted.
Signed-off-by: Martin Storsjö
---
libavcodec/arm/hevcdsp_qpel_neon.S | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/libavcodec/arm
On Fri, 20 Aug 2021, Mikhail Nitenko wrote:
Benchmarks:A53 A72
pred8x8_dc_10_c: 64.249.5
pred8x8_dc_10_neon:62.053.7
pred8x8_dc_128_10_c: 26.014.0
pred8x8_dc_128_10_neon:30.717.5
On Fri, 20 Aug 2021, Mikhail Nitenko wrote:
Benchmarks: A53 A72
h264_h_loop_filter_chroma422_10bpp_c: 282.7 114.2
h264_h_loop_filter_chroma422_10bpp_neon: 109.578.5
h264_h_loop_filter_chroma_10bpp_c:
On Tue, 17 Aug 2021, James Almer wrote:
On 8/17/2021 12:35 PM, Christopher Degawa wrote:
Fixes https://trac.ffmpeg.org/ticket/8903
relevant https://github.com/msys2/MINGW-packages/discussions/9258
Signed-off-by: Christopher Degawa
---
libavcodec/x86/cabac.h | 9 +++--
1 file changed,
On Thu, 12 Aug 2021, Martin Storsjö wrote:
On Thu, 12 Aug 2021, Hu Weiwen wrote:
"frag_start" is redundant, and every occurance can be replaced with
cluster[0].dts - start_dts
I think I can agree about this, so I think the patch should be fine, thanks
for taking the tim
On Thu, 12 Aug 2021, Martin Storsjö wrote:
On Thu, 12 Aug 2021, Hu Weiwen wrote:
track->mdat_buf can be not NULL while the track is still empty if the
last packet write failed.
Signed-off-by: Hu Weiwen
---
libavformat/movenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
On Fri, 20 Aug 2021, Mikhail Nitenko wrote:
there is a function that is not covered by tests, but I tested it with
sample videos, not sure what to do with it
If there are asm functions that lack checkasm tests, then please do add a
test for it while working on that function. Asm functions
Override the fate-sub-* wide comparison function of CMP=rawdiff
back to the default, CMP=diff, which ignores line ending differences
(where the ffprobe output contains CRLF line endings).
Signed-off-by: Martin Storsjö
---
tests/fate/subtitles.mak | 2 ++
1 file changed, 2 insertions(+)
diff
On Wed, 25 Aug 2021, Jan Ekström wrote:
subtitles.mak utilizes a more strict comparator and - to be honest -
the tests feel more at home in this location.
---
LGTM, although your commit message forgets to point out the relevant
effect of it - we're not just doing this for sorting things in
On Wed, 25 Aug 2021, Martin Storsjö wrote:
This unbreaks the fate-checkasm-hevc_pel test on arm targets.
The assembly assumed that the width passed to the DSP functions is
a multiple of 8, while the checkasm test used other widths too.
This wasn't noticed before, because the hevc_pel checkasm
On Fri, 20 Aug 2021, Mikhail Nitenko wrote:
Benchmarks: A53 A72
h264_idct4_add_10bpp_c:187.7 115.2
h264_idct4_add_10bpp_neon: 72.545.0
h264_idct4_add_dc_10bpp_c:
On Fri, 3 Sep 2021, Martin Storsjö wrote:
+function \type\()_h264_qpel8_v_lowpass_neon_10
+ld1 {v16.8H}, [x1], x3
+ld1 {v18.8H}, [x1], x3
+ld1 {v20.8H}, [x1], x3
+ld1 {v22.8H}, [x1], x3
+ld1
This gives rather big speedups on these functions:
Before:
put_h264_qpel_8_mc01_8_neon: 241.0 131.5 138.7
put_h264_qpel_8_mc02_8_neon: 214.7 121.2 127.5
put_h264_qpel_8_mc03_8_neon: 242.5 131.2 135.7
put_h264_qpel_8_mc11_8_neon: 421.2 218.7 251.0
Don't use the loaded registers directly, avoiding stalls on in
order cores. Use vrhadd.u8 with q registers where easily possible.
---
libavcodec/aarch64/h264qpel_neon.S | 60 +++---
libavcodec/arm/h264qpel_neon.S | 57
2 files changed, 54
On Thu, 2 Sep 2021, Andreas Rheinhardt wrote:
The earlier code did not properly check these initializations:
It only recorded whether the part of init where these initializations
are has been reached, but it did not check whether the initializations
were successful, although destroying them
This avoids using tainted data in the call to zcat in the main loop
in index.cgi.
This fixes the report listing for cases with a compile error.
---
FATE.pm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/FATE.pm b/FATE.pm
index ccb8958..0d4603f 100644
--- a/FATE.pm
+++
On Wed, 8 Sep 2021, Paul B Mahol wrote:
ffmpeg | branch: master | Paul B Mahol | Wed Sep 8 13:06:43
2021 +0200| [3b331468dae2e88ee6c87c257ac159ad662efcac] | committer: Paul B Mahol
avfilter/af_silenceremove: fix processing of periods > 1
On Thu, 9 Sep 2021, Paul B Mahol wrote:
Signed-off-by: Paul B Mahol
---
tests/fate/filter-audio.mak | 5 +--
tests/ref/fate/filter-silenceremove | 67 ++---
2 files changed, 35 insertions(+), 37 deletions(-)
Thanks, this does seem to fix the test on aarch64 at
On Fri, 20 Aug 2021, Mikhail Nitenko wrote:
transpose_4x4S and transpose_8x8S were declared in vp9itxfm_16bpp_neon, however
these macros are
not unique to vp9 and could be used elsewhere.
Signed-off-by: Mikhail Nitenko
---
libavcodec/aarch64/neon.S| 49
On Mon, 13 Sep 2021, Zhao Zhili wrote:
From: Zhao Zhili
---
libswresample/aarch64/audio_convert_neon.S | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libswresample/aarch64/audio_convert_neon.S
b/libswresample/aarch64/audio_convert_neon.S
index 74feff448a..9505b6
On Mon, 13 Sep 2021, Zhao Zhili wrote:
From: Zhao Zhili
---
v2: add local labels instead of changing the code
libswresample/aarch64/audio_convert_neon.S | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libswresample/aarch64/audio_convert_neon.S
On Mon, 13 Sep 2021, Zhao Zhili wrote:
From: Zhao Zhili
Use a temporary label instead of global function symbol for b.gt.
---
libavcodec/aarch64/videodsp.S | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/aarch64/videodsp.S b/libavcodec/aarch64/videodsp.S
index
On Sat, 18 Sep 2021, Timo Rothenpieler wrote:
On 18.09.2021 15:48, Gianfranco Costamagna wrote:
Hello Timo
Il giorno sab 18 set 2021 alle ore 13:15 Timo Rothenpieler <
t...@rothenpieler.org> ha scritto:
On 18.09.2021 11:06, Gianfranco Costamagna wrote:
New gcc changed the way it exposes
out the compiler's default via the -march flag.
Signed-off-by: Martin Storsjö
---
configure | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index 9249254b70..3a05b8294b 100755
--- a/configure
+++ b/configure
@@ -5009,9 +5009,11 @@ elif enabled arm
This was missed in 505f620a5d22ffef86ad5ffa1328e87ba6dc191b.
---
report.cgi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/report.cgi b/report.cgi
index 2b388e4..fb00fee 100755
--- a/report.cgi
+++ b/report.cgi
@@ -1,4 +1,4 @@
-#! /usr/bin/perl
+#! /usr/bin/perl -T
#
#
When invoking unxz, the variables making up the path
passed to unxz need to be validated.
load_summary normally only reads the "summary" file, but
if missing, it tries to use unxz to unpack report.xz. In
this case the slot value needs to be validated, which can
be done in the main loop in
On Thu, 19 Aug 2021, Mikhail Nitenko wrote:
diff --git a/libavcodec/aarch64/h264qpel_neon.S
b/libavcodec/aarch64/h264qpel_neon.S
index d27cfac494..eb18469b7f 100644
--- a/libavcodec/aarch64/h264qpel_neon.S
+++ b/libavcodec/aarch64/h264qpel_neon.S
@@ -932,3 +932,518 @@ endfunc
On Mon, 26 Jul 2021, Jan Ekström wrote:
From: Jan Ekström
Includes basic support for both the ISMV ('dfxp') and MP4 ('stpp')
methods. This initial version also foregoes fragmentation support
in case the built-in sample squashing is to be utilized, as this
eases the initial review.
If autoflushing on a new packet (e.g. due to the frag_every_frame
flag being set), there's no samples to be written in the new fragment,
so we can't overwrite the track duration in order to make it line
up with the next packet to be written.
Signed-off-by: Martin Storsjö
---
libavformat
Hi,
On Tue, 20 Jul 2021, 胡玮文 wrote:
After compile and run this code, run this command to inspect the dts (which
comes from the out of sync tfdt)
ffprobe -show_packets bug.mp4 | grep dts=
The output is:
dts=0
dts=1
dts=2
dts=2
dts=3
dts=4
With this patch applied, the output is:
dts=0
Hi,
On Mon, 9 Aug 2021, Hu Weiwen wrote:
Even if FF_MOV_FLAG_FRAG_EVERY_FRAME is set, don't flush if no frame available.
This fixes an issue that we overwrite the track duration, causing it to be
out-of-sync with the last written packet in previous fragment.
Signed-off-by: Hu Weiwen
---
Hi
On Tue, 10 Aug 2021, 胡玮文 wrote:
Thank you for your detailed explaination. Now I agree your patch is better.
Ok, I pushed that one then.
// Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Thu, 5 Aug 2021, Martin Storsjö wrote:
These became unnecessary when the stride arguments were changed from
int to ptrdiff_t in bc26fe89275c267d169b468356c82ee59874407d
(0576ef466d8a631326d1d0a5ec2e4c4c81d25353) and
d5d699ab6e6f8a8290748d107416fd5c19757a1b
On Thu, 5 Aug 2021, Martin Storsjö wrote:
Signed-off-by: Martin Storsjö
---
libavcodec/aarch64/h264dsp_neon.S | 520 +++---
1 file changed, 260 insertions(+), 260 deletions(-)
Pushed this one too.
// Martin
___
ffmpeg-devel
On Thu, 5 Aug 2021, J. Dekker wrote:
Signed-off-by: J. Dekker
---
tests/checkasm/Makefile | 1 +
tests/checkasm/checkasm.c | 3 +
tests/checkasm/checkasm.h | 1 +
tests/checkasm/h264chroma.c | 109
tests/fate/checkasm.mak | 1 +
5 files
On Thu, 5 Aug 2021, J. Dekker wrote:
Signed-off-by: J. Dekker
---
tests/checkasm/Makefile | 2 +-
tests/checkasm/checkasm.c | 1 +
tests/checkasm/checkasm.h | 1 +
tests/checkasm/hevc_deblock.c | 126 ++
tests/fate/checkasm.mak | 1 +
5
On Thu, 5 Aug 2021, J. Dekker wrote:
Also add to `make fate-checkasm' target.
Signed-off-by: J. Dekker
---
tests/checkasm/checkasm.c | 11 +--
tests/checkasm/checkasm.h | 11 +--
tests/checkasm/hevc_pel.c | 34 --
tests/fate/checkasm.mak | 1 +
4
On Thu, 12 Aug 2021, Hu Weiwen wrote:
track->mdat_buf can be not NULL while the track is still empty if the
last packet write failed.
Signed-off-by: Hu Weiwen
---
libavformat/movenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/movenc.c
On Thu, 12 Aug 2021, Hu Weiwen wrote:
"frag_start" is redundant, and every occurance can be replaced with
cluster[0].dts - start_dts
I think I can agree about this, so I think the patch should be fine,
thanks for taking the time to study it in detail!
My own mental model of the code,
Signed-off-by: Martin Storsjö
---
libavcodec/aarch64/h264dsp_neon.S | 520 +++---
1 file changed, 260 insertions(+), 260 deletions(-)
diff --git a/libavcodec/aarch64/h264dsp_neon.S
b/libavcodec/aarch64/h264dsp_neon.S
index 997167ca88..997082498f 100644
--- a/libavcodec
On Fri, 16 Jul 2021, Mikhail Nitenko wrote:
transpose_4x8H was declared in vp9lpf_16bpp_neon, however this macro is
not unique to vp9 and could be used elsewhere.
Signed-off-by: Mikhail Nitenko
---
libavcodec/aarch64/neon.S | 13 +
On Fri, 16 Jul 2021, Mikhail Nitenko wrote:
Benchmarks: A53A72
h264_h_loop_filter_chroma422_10bpp_c: 293.0 116.7
h264_h_loop_filter_chroma422_10bpp_neon: 283.7 126.2
h264_h_loop_filter_chroma_10bpp_c:
These became unnecessary when the stride arguments were changed from
int to ptrdiff_t in bc26fe89275c267d169b468356c82ee59874407d
(0576ef466d8a631326d1d0a5ec2e4c4c81d25353) and
d5d699ab6e6f8a8290748d107416fd5c19757a1b
(aa844dc46f93182a63ec0b53267d19e7342c79b9).
Signed-off-by: Martin Storsjö
On Fri, 16 Jul 2021, Mikhail Nitenko wrote:
Benchmarks:A53 A72
pred8x8_dc_10_c: 64.249.5
pred8x8_dc_10_neon:62.754.5
pred8x8_dc_128_10_c: 26.015.5
pred8x8_dc_128_10_neon:28.216.0
---
libavfilter/af_afftfilt.c | 1 +
libavfilter/avf_showspectrum.c | 1 +
libavfilter/vaf_spectrumsynth.c | 1 +
3 files changed, 3 insertions(+)
diff --git a/libavfilter/af_afftfilt.c b/libavfilter/af_afftfilt.c
index 3e69c636c8..877ccc5be0 100644
--- a/libavfilter/af_afftfilt.c
+++
The refactoring in 844890b1bc86316a38bc9e1dbf8ba0dd254307e3 caused
fate-source to point out that this could be av_clip_uintp2.
Signed-off-by: Martin Storsjö
---
libavfilter/vf_fftfilt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/vf_fftfilt.c b/libavfilter
On Thu, 7 Oct 2021, J. Dekker wrote:
--bench on AWS Graviton:
hevc_sao_edge_16x16_8_c: 1857.0
hevc_sao_edge_16x16_8_neon: 211.0
hevc_sao_edge_32x32_8_c: 7802.2
hevc_sao_edge_32x32_8_neon: 808.2
hevc_sao_edge_48x48_8_c: 16764.2
hevc_sao_edge_48x48_8_neon: 1796.5
hevc_sao_edge_64x64_8_c: 32647.5
On Thu, 7 Oct 2021, J. Dekker wrote:
--bench on AWS Graviton:
hevc_sao_edge_8x8_8_c: 516.0
hevc_sao_edge_8x8_8_neon: 81.0
Signed-off-by: J. Dekker
---
libavcodec/aarch64/hevcdsp_init_aarch64.c | 3 ++
libavcodec/aarch64/hevcdsp_sao_neon.S | 52 +++
2 files changed, 55
On Thu, 7 Oct 2021, J. Dekker wrote:
--bench on AWS Graviton:
hevc_sao_band_8x8_8_c: 317.5
hevc_sao_band_8x8_8_neon: 97.5
hevc_sao_band_16x16_8_c: 1115.0
hevc_sao_band_16x16_8_neon: 322.7
hevc_sao_band_32x32_8_c: 4599.2
hevc_sao_band_32x32_8_neon: 1246.2
hevc_sao_band_48x48_8_c: 10021.7
On Thu, 7 Oct 2021, J. Dekker wrote:
--bench on AWS Graviton:
hevc_sao_edge_16x16_8_c: 1857.0
hevc_sao_edge_16x16_8_neon: 211.0
hevc_sao_edge_32x32_8_c: 7802.2
hevc_sao_edge_32x32_8_neon: 808.2
hevc_sao_edge_48x48_8_c: 16764.2
hevc_sao_edge_48x48_8_neon: 1796.5
hevc_sao_edge_64x64_8_c: 32647.5
On Thu, 7 Oct 2021, J. Dekker wrote:
Signed-off-by: J. Dekker
---
libavcodec/aarch64/hevcdsp_sao_neon.S | 103 +++---
1 file changed, 44 insertions(+), 59 deletions(-)
diff --git a/libavcodec/aarch64/hevcdsp_sao_neon.S
b/libavcodec/aarch64/hevcdsp_sao_neon.S
index
On Fri, 3 Sep 2021, Martin Storsjö wrote:
This gives rather big speedups on these functions:
Before:
put_h264_qpel_8_mc01_8_neon: 241.0 131.5 138.7
put_h264_qpel_8_mc02_8_neon: 214.7 121.2 127.5
put_h264_qpel_8_mc03_8_neon: 242.5 131.2 135.7
put_h264_qpel_8_mc11_8_neon
On Mon, 18 Oct 2021, Paul B Mahol wrote:
lgtm
Thanks, pushed.
// Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
401 - 500 of 1402 matches
Mail list logo
