On Fri, May 15, 2020 at 06:52:55PM +0200, Marton Balint wrote:
>
>
> On Fri, 15 May 2020, lance.lmw...@gmail.com wrote:
>
> > On Fri, May 15, 2020 at 08:02:44PM +0800, myp...@gmail.com wrote:
> > > On Fri, May 15, 2020 at 6:23 PM wrote:
> > > >
> > > > From: Limin Wang
> > > >
> > > > reanalyz
Andreas Rheinhardt:
> The parsing process of the AVOpt-enabled string controlling the mapping
> of input streams to variant streams is roughly as follows: Space and tab
> separate variant stream group maps while the entries in each variant
> stream group map are separated by ','.
>
> The parsing p
Just posting this as a single email not to spam the ML too much.
Going to push this sometime over the weekend alongside the other 3 patches to
finish
all work on Vulkan before the next release.
Satisfied with the code, though the last patch is slightly ugly.
Performance improvements out of async c
On Thu, May 14, 2020 at 03:31:55PM -0700, Dale Curtis wrote:
> Signed-off-by: Dale Curtis
> ---
> libavformat/mov.c | 4
> 1 file changed, 4 insertions(+)
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The educated differ from the uneduc
On Thu, May 14, 2020 at 12:46:56PM -0700, Dale Curtis wrote:
> On Thu, May 14, 2020 at 11:47 AM Michael Niedermayer
> wrote:
>
> > On Fri, May 01, 2020 at 11:42:43AM -0700, Dale Curtis wrote:
> > > On Fri, May 1, 2020 at 10:57 AM Carl Eugen Hoyos
> > wrote:
> > >
> > > > Could you confirm that y
On Fri, May 15, 2020 at 10:00:02AM -0700, Thierry Foucu wrote:
> On Thu, May 14, 2020 at 12:26 PM Derek Buitenhuis <
> derek.buitenh...@gmail.com> wrote:
>
> > On 14/05/2020 18:19, Thierry Foucu wrote:
> > > Looking at
> > >
> > https://developer.apple.com/library/archive/documentation/QuickTime/Q
On Fri, May 08, 2020 at 02:31:27PM +, Zane van Iperen wrote:
> Signed-off-by: Zane van Iperen
> ---
> Changelog | 1 +
> doc/general.texi | 2 +-
> libavcodec/Makefile| 1 +
> libavcodec/adpcmenc.c | 65 +++---
> libavcodec/allcod
On 15/05/2020 19:11, Martin Storsjö wrote:
This allows speeding up format conversions from yuv420 to nv12.
Cortex A53 A72 A73
interleave_bytes_c: 86077.5 51433.0 66972.0
interleave_bytes_neon: 19701.7 23019.2 15859.2
interleave_byt
On 15/05/2020 19:35, Martin Storsjö wrote:
From: Josh de Kock
The NEON hscale function only supports X8 filter sizes and should only
be selected when these are being used. At the moment filterAlign is
set to 8 but in the future when extra NEON assembly for specific sizes is
added they will need
On 5/15/2020 3:36 PM, Lynne wrote:
> Just posting this as a single email not to spam the ML too much.
> Going to push this sometime over the weekend alongside the other 3 patches to
> finish
> all work on Vulkan before the next release.
The new release is not going to happen tomorrow or even next
On Wed, 13 May 2020, Martin Storsjö wrote:
Cortex A53A72A73
get_pixels_c:140.7 87.7 72.5
get_pixels_neon: 46.0 20.0 19.5
get_pixels_unaligned_c: 140.7 87.7 73.0
get_pixels_unaligned_neon:49.2 20.2 26.2
diff_pixe
On Fri, 15 May 2020, Henrik Gramner wrote:
All 5 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
ffmpeg-devel-requ...
From: Josh de Kock
The NEON hscale function only supports X8 filter sizes and should only
be selected when these are being used. At the moment filterAlign is
set to 8 but in the future when extra NEON assembly for specific sizes is
added they will need to have checks here too.
The immediate usec
This allows speeding up format conversions from yuv420 to nv12.
Cortex A53 A72 A73
interleave_bytes_c: 86077.5 51433.0 66972.0
interleave_bytes_neon: 19701.7 23019.2 15859.2
interleave_bytes_aligned_c: 86603.0 52017.2 67484.2
in
---
This depends on "checkasm: Add functions for printing pixel buffers".
The existing x86 implementations of interleaveBytes seem to slow
down significantly for unaligned copies (GCC 7.5, Sandy Bridge):
interleave_bytes_c: 36251.6
interleave_bytes_mmx:10038.8
interleave_bytes_mmxext: 58
On Thu, May 14, 2020 at 12:26 PM Derek Buitenhuis <
derek.buitenh...@gmail.com> wrote:
> On 14/05/2020 18:19, Thierry Foucu wrote:
> > Looking at
> >
> https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/Metadata/Metadata.html
> > The spec does not seem to say 1 or more. But b
On Fri, 15 May 2020, lance.lmw...@gmail.com wrote:
On Fri, May 15, 2020 at 08:02:44PM +0800, myp...@gmail.com wrote:
On Fri, May 15, 2020 at 6:23 PM wrote:
>
> From: Limin Wang
>
> reanalyze() may misdetect the new packet size as 204, but it's 188 still
actualy,
> it'll cause many cc error
On Fri, 15 May 2020, Limin Wang wrote:
On Thu, May 14, 2020 at 11:03:49PM +0200, Marton Balint wrote:
This reverts commit 339593ca90cb3e05d659ec99a1479904ec742294.
Fixes null pointer dereference.
Signed-off-by: Marton Balint
---
libavfilter/vf_framerate.c | 15 ---
1 file c
Why was this applied without review?
Please revert ASAP!
On 5/14/20, Marton Balint wrote:
> This reverts commit d88e1c9838dbcfe29d7835f2705ffc9ee6a36bf3.
>
> Fixes null pointer dereference.
>
> Signed-off-by: Marton Balint
> ---
> libavfilter/vf_minterpolate.c | 16
> 1 file c
All 5 lgtm.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 27
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vsrc_gradients.c | 290 +++
4 files changed, 319 insertions(+)
create mode 100644 libavfilter/vsrc_grad
On 4/16/20, Nicolas George wrote:
> Signed-off-by: Nicolas George
> ---
> doc/filters.texi | 34 ++
> libavfilter/Makefile | 1 +
> libavfilter/allfilters.c | 1 +
> libavfilter/vf_untile.c | 198 +++
> tests/fate/filter-video
On Fri, May 15, 2020 at 08:02:44PM +0800, myp...@gmail.com wrote:
> On Fri, May 15, 2020 at 6:23 PM wrote:
> >
> > From: Limin Wang
> >
> > reanalyze() may misdetect the new packet size as 204, but it's 188 still
> > actualy,
> > it'll cause many cc errors report and cannot be recovered. So it's
On Fri, May 15, 2020 at 6:23 PM wrote:
>
> From: Limin Wang
>
> reanalyze() may misdetect the new packet size as 204, but it's 188 still
> actualy,
> it'll cause many cc errors report and cannot be recovered. So it's better to
> check
> the next sync byte before skip the extra unused bytes.
>
>
Steven Liu 于2020年5月15日周五 下午6:02写道：
>
> because it need be check for success, is should not
> change the old way if it failure.
Change the comments:
because it need be checked for success status, it should not
change the old way if it failure.
>
> Signed-off-by: Steven Liu
> ---
> libavformat/url
On Fri, 08 May 2020 14:31:27 +
"Zane van Iperen" wrote:
>
> Signed-off-by: Zane van Iperen
> ---
> Changelog | 1 +
> doc/general.texi | 2 +-
> libavcodec/Makefile| 1 +
> libavcodec/adpcmenc.c | 65
> +++--- libavcodec/allcode
On 14/05/2020 22:28, Martin Storsjö wrote:
On Thu, 14 May 2020, Josh de Kock wrote:
From: Martin Storsjö
This was ported from dav1d (c950e7101bdf5f7117bfca816984a21e550509f0).
Signed-off-by: Josh de Kock
---
tests/checkasm/checkasm.c | 42 +++
tests/checka
On 15/05/2020 09:41, Martin Storsjö wrote:
On Thu, 14 May 2020, Josh de Kock wrote:
This tests the hscale 8bpp to 14bpp functions with different filter
sizes.
Signed-off-by: Josh de Kock
---
Adds support for checking corner cases for signed and large
coefficients. Also makes the padded coeff
On 08/05/2020 12:25, Michael Niedermayer wrote:
On Thu, May 07, 2020 at 12:25:34PM +0100, Josh de Kock wrote:
The NEON hscale function only supports X8 filter sizes and should only
be selected when these are being used.
Signed-off-by: Josh de Kock
---
libswscale/aarch64/swscale.c | 5 -
From: Limin Wang
reanalyze() may misdetect the new packet size as 204, but it's 188 still
actualy,
it'll cause many cc errors report and cannot be recovered. So it's better to
check
the next sync byte before skip the extra unused bytes.
Also, it is best to change SIZE_STAT_THRESHOLD from 10 to
because it need be check for success, is should not
change the old way if it failure.
Signed-off-by: Steven Liu
---
libavformat/url.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/url.c b/libavformat/url.c
index 7cd9e0c705..6956f6dc10 100644
--- a/libavformat/ur
On Fri, May 15, 2020 at 11:50:08AM +0200, Paul B Mahol wrote:
> On 5/15/20, lance.lmw...@gmail.com wrote:
> > On Fri, May 15, 2020 at 11:27:00AM +0200, Paul B Mahol wrote:
> >> On 5/15/20, lance.lmw...@gmail.com wrote:
> >> > On Fri, May 15, 2020 at 10:27:35AM +0200, Paul B Mahol wrote:
> >> >> O
On 5/15/20, lance.lmw...@gmail.com wrote:
> On Fri, May 15, 2020 at 11:27:00AM +0200, Paul B Mahol wrote:
>> On 5/15/20, lance.lmw...@gmail.com wrote:
>> > On Fri, May 15, 2020 at 10:27:35AM +0200, Paul B Mahol wrote:
>> >> On 5/15/20, lance.lmw...@gmail.com wrote:
>> >> > On Thu, May 14, 2020 a
On Fri, May 15, 2020 at 11:27:00AM +0200, Paul B Mahol wrote:
> On 5/15/20, lance.lmw...@gmail.com wrote:
> > On Fri, May 15, 2020 at 10:27:35AM +0200, Paul B Mahol wrote:
> >> On 5/15/20, lance.lmw...@gmail.com wrote:
> >> > On Thu, May 14, 2020 at 09:00:21PM +0200, Marton Balint wrote:
> >> >>
On 5/15/20, lance.lmw...@gmail.com wrote:
> On Fri, May 15, 2020 at 10:27:35AM +0200, Paul B Mahol wrote:
>> On 5/15/20, lance.lmw...@gmail.com wrote:
>> > On Thu, May 14, 2020 at 09:00:21PM +0200, Marton Balint wrote:
>> >>
>> >>
>> >> On Thu, 14 May 2020, Marton Balint wrote:
>> >>
>> >> >
>> >
On Fri, May 15, 2020 at 10:27:35AM +0200, Paul B Mahol wrote:
> On 5/15/20, lance.lmw...@gmail.com wrote:
> > On Thu, May 14, 2020 at 09:00:21PM +0200, Marton Balint wrote:
> >>
> >>
> >> On Thu, 14 May 2020, Marton Balint wrote:
> >>
> >> >
> >> >
> >> > On Thu, 14 May 2020, Nicolas George wrote:
This allows speeding up format conversions from yuv420 to nv12.
Cortex A53 A72 A73
interleave_bytes_c: 86077.5 51433.0 66972.0
interleave_bytes_neon: 19701.7 23019.2 15859.2
interleave_bytes_aligned_c: 86603.0 52017.2 67484.2
in
---
This depends on "checkasm: Add functions for printing pixel buffers".
The existing x86 implementations of interleaveBytes seem to slow
down significantly for unaligned copies (GCC 7.5, Sandy Bridge):
interleave_bytes_c: 36251.6
interleave_bytes_mmx:10038.8
interleave_bytes_mmxext: 58
On Thu, 14 May 2020, Josh de Kock wrote:
This tests the hscale 8bpp to 14bpp functions with different filter
sizes.
Signed-off-by: Josh de Kock
---
Adds support for checking corner cases for signed and large
coefficients. Also makes the padded coefficients random data.
Tested on x86_64 and a
On 5/14/20, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Reviewed-by: Paul B Mahol
Please use full filter name when exporting metadata to rest of filtergraph.
> Signed-off-by: Limin Wang
> ---
> rebase with master and update the version and Changelog
>
> Changelog|
On 5/15/20, lance.lmw...@gmail.com wrote:
> On Thu, May 14, 2020 at 09:00:21PM +0200, Marton Balint wrote:
>>
>>
>> On Thu, 14 May 2020, Marton Balint wrote:
>>
>> >
>> >
>> > On Thu, 14 May 2020, Nicolas George wrote:
>> >
>> > > Marton Balint (12020-05-14):
>> > > > I am not a huge fan of this p
On Fri, May 15, 2020 at 9:06 AM Fu, Linjie wrote:
> > From: ffmpeg-devel On Behalf Of
> > Artem Galin
> > Sent: Tuesday, April 28, 2020 00:26
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Cc: Zhong Li
> > Subject: Re: [FFmpeg-devel] [PATCH, v2 1/2] lavc/qsvdec: add
> From: ffmpeg-devel On Behalf Of
> Mark Thompson
> Sent: Sunday, March 8, 2020 00:15
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 4/4] vaapi_encode_h265: Enable 4:2:2
> support
>
> On 05/03/2020 02:49, Fu, Linjie wrote:
> > 2. recon surface of Y210 or 444 (AYUV and Y410 in
On Thu, 14 May 2020, Josh de Kock wrote:
This tests the hscale 8bpp to 14bpp functions with different filter
sizes.
^ 8bpp to 14, and to 18, right?
Signed-off-by: Josh de Kock
---
Adds support for checking corner cases for signed and large
coefficients. Also makes the padded coefficients r
> From: ffmpeg-devel On Behalf Of
> Artem Galin
> Sent: Tuesday, April 28, 2020 00:26
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: Zhong Li
> Subject: Re: [FFmpeg-devel] [PATCH, v2 1/2] lavc/qsvdec: add decode
> support for HEVC 4:2:2 8-bit and 10-bit
>
> On Wed, 15
On Tue, 12 May 2020, Martin Storsjö wrote:
From: wm4
This contains encoder wrappers for H264, HEVC, AAC, AC3 and MP3.
This is based on top of an original patch by wm4
. The original patch supported both encoding
and decoding, but this patch only includes encoding.
The patch contains further
46 matches
Mail list logo
