Re: [FFmpeg-devel] Fw: [PATCH] libavcodec Adding ff_v210_planar_unpack AVX2
> On 2019-03-26 21:22, Mike Stoner via ffmpeg-devel wrote: > > > Hello, > > I’ve accounted for all feedback on this so far, I’m wondering if it is > > ready to be pushed upstream? > > > > Here are my results from ‘checkasm’ (lower is better): > > > > v210_unpack_c: 1636 > > v210_unpack_ssse3: 611 > > v210_unpack_avx: 601 > > v210_unpack_avx2: 423 > > > > I ran it 5 times and averaged the middle 3 results for each CPU target > > (ignoring the highest and lowest time). > > > > https://patchwork.ffmpeg.org/patch/12325/ > > > > > > Thanks… -Mike > > > Sorry that I keep forgetting about this. I will try to make some time > tomorrow to give this another look over. > > I'm not sure what order this and my checkasm patch should be applied in, > which I also forgot about. > > Did anyone else make comments on either patch? > Martin Vignali had commented about using VBROADCASTI128 instead of doubling the constants to 32 bytes for AVX2. I incorporated that into the updated patch. Your checkasm patch looks good to me. I think you could also add it to "/tests/fate/checkasm.mak". I'm open to either order that these could be committed. Note there are already a few Fate vsynth tests that will fail if v210dec gets broken. -Mike ___ 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".
Re: [FFmpeg-devel] [PATCH 3/3] libavcodec Adding ff_v210_planar_unpack AVX2
On Wed, Apr 10, 2019 at 5:48 AM James Darnley wrote: > > From: Michael Stoner > > Replaced VSHUFPS with VPBLENDD to relieve port 5 bottleneck > AVX2 is 1.4x faster than AVX > --- > > Mike, is this still the patch you want applied. I had to make a small > amendment to it because you had some tabs as indentation. That looks right, thanks. Sorry about the tabs. They snuck in since I was editing with Visual Studio. -Mike ___ 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".
Re: [FFmpeg-devel] [PATCH] Added ff_v210_planar_unpack_aligned_avx2
Thanks for the feedback. You are right, I can use VPERMQ to free up a register. I can also remove the PAND mask by doing PSLLD/PSRLD. That eliminates the need for an x86-64 block. I tried the naive 'unrolled' version with no permute, and it was much slower, about the same as the AVX/SSSE3 code. VPERMQ/D is a single shuffle uop on port 5, so it turns out to be useful. I will submit a new patch with those improvements and the VBROADCASTI128 macro. I role-modeled my code from 'v210enc.asm' which also could be updated with VBROADCASTI128. Note, I'm running on Windows and it looks like 'checkasm' performance benchmarking is only enabled on Linux. For my tests I put a 100x loop around the 'unpack_frame' call and ran: ffmpeg.exe -s:v 1920x1080 -vcodec v210 -stream_loop 200 -i OddaView_1920x1080.v210 -f null -y NUL If there is a better way, let me know... Thanks,Mike ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Revised ff_v210_planar_unpack AVX2
I am submitting another patch. Please disregard this one. -Mike ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec Adding ff_v210_planar_unpack AVX2
Hello, I resent my AVX2 patch for v210 unpacking. My first attempt didn't get picked up by the Patchwork list for some reason. I installed Linux on a Broadwell laptop to utilize James Darnley's checkasm patch for v210 decode. The results are below. AVX2 gets a nice boost from replacing SHUFPS instructions with VPBLENDD, which has more flexible port bindings. VBLENDPS could also be substituted and is available from SSE4.1 onward, however I found only the AVX2 code received any measureable gain from that change. Any further comments are greatly appreciated. Thanks, Mike Tested on Broadwell CPU, Ubuntu 18.10 x86_64 ~/FFmpeg$ tests/checkasm/checkasm --bench --test=v210dec benchmarking with native FFmpeg timers nop: 94.1 checkasm: using random seed 3963743306 SSSE3: - v210dec.v210_unpack [OK] AVX: - v210dec.v210_unpack [OK] AVX2: - v210dec.v210_unpack [OK] checkasm: all 3 tests passed v210_unpack_c: 1625.2 v210_unpack_ssse3: 604.2 v210_unpack_avx: 592.2 v210_unpack_avx2: 422.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Submitting patches.
Is there a FAQ or other documentation on how to submit patches? There's a compiler warning that's driving me nuts and I'd like to clean it up if I can. Thank you, Mike ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.
A later patch to configure to make sure it was defined, so the breakage stopped. The patch for the configure option and the code should have been atomic, IMNSHO. On Thu, Jul 7, 2016 at 8:42 PM, Michael Niedermayer wrote: > On Thu, Jun 30, 2016 at 03:36:31PM +0200, Michael Niedermayer wrote: > > On Wed, Jun 29, 2016 at 04:15:12PM +, Dan Parrot wrote: > > > This patch addresses Trac ticket #5570. The optimized functions are in > file > > > libswscale/ppc/input_vsx.c. Each optimized function name is a > concatenation of the > > > corresponding name in libswscale/input.c with suffix _vsx. > > > --- > > > libswscale/ppc/Makefile | 1 + > > > libswscale/ppc/input_vsx.c| 437 > ++ > > > libswscale/swscale.c | 3 + > > > libswscale/swscale_internal.h | 1 + > > > 4 files changed, 442 insertions(+) > > > create mode 100644 libswscale/ppc/input_vsx.c > > > > patch applied > > > > Please keep an eye on fate.ffmpeg.org, if it breaks on one of the ppc > > machines i will revert the patch > > According to https://trac.ffmpeg.org/ticket/5570#comment:3 > this broke build on some machines > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > It is dangerous to be right in matters on which the established authorities > are wrong. -- Voltaire > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] bug in stream_loop
Hi! For the last couple of days I have been trying to get FFmpeg to loop a video with audio, but both the stream_loop option and loop filter have a bug. Since stream_loop is the most efficient of the two (and almost works), that one is my favourite. Can I persuade someone to look at ticket 5719 and make this option work? I can't do it myself, but am happy to offer my services for (thorough) testing. Thanks! Mike ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] bug in stream_loop
Thank you Paul, sorry to hear that. As for the issues I am having with the loop filter, please refer to https://video.stackexchange.com/questions/21757/using-ffmpeg-loop-filter-makes-audio-disappear/21758 Mike/mobile On Jun 24, 2017 09:14, "Paul B Mahol" wrote: > On 6/23/17, Mike Versteeg wrote: > > Hi! > > > > For the last couple of days I have been trying to get FFmpeg to loop a > > video with audio, but both the stream_loop option and loop filter have > > a bug. Since stream_loop is the most efficient of the two (and almost > > works), that one is my favourite. Can I persuade someone to look at > > ticket 5719 and make this option work? I can't do it myself, but am > > happy to offer my services for (thorough) testing. > > Nope. > > What's bug with loop filter? > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/outdevs: Add declink signal generator example
On Fri, Mar 9, 2018 at 3:38 PM, Devin Heitmueller wrote: > >>> +ffmpeg -re -f lavfi -i "testsrc=s=1920x1080:rate=3/1000" -f lavfi -i >>> "sine=frequency=1000:sample_rate=48000" +-ac 2 -acodec pcm_s16le >>> -pix_fmt uyvy422 -format_code Hi30 -f decklink 'DeckLink Studio 2' >> >> You should not need the -re flag, the decklink outdev blocks if it gets too >> many frames and because of this the "encoding" speed should be limited to >> realtime even without -re. Or you see something different? If don't use -re I get an average of ~31 fps and speed 1.03x, but with -re the status stays at 30 fps and 1x. No idea why the difference. > Also, isn’t -format_code a capture parameter? Is it even valid to provide > that on output? > > I had plans to add support for -format_code for output - if it’s already > working then that’s great. You are right, -format_code does not appear to do anything for the output. > Devin > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] doc/outdevs: Add declink signal generator example
Signed-off-by: Mike Goins --- doc/outdevs.texi | 7 +++ 1 file changed, 7 insertions(+) diff --git a/doc/outdevs.texi b/doc/outdevs.texi index daf7b1ae62..1ca81ba139 100644 --- a/doc/outdevs.texi +++ b/doc/outdevs.texi @@ -180,6 +180,13 @@ Play video clip with non-standard framerate or video size: ffmpeg -i test.avi -f decklink -pix_fmt uyvy422 -s 720x486 -r 24000/1001 'DeckLink Mini Monitor' @end example +@item +Signal Generator mode: +@example +ffmpeg -re -f lavfi -i "testsrc=s=1920x1080:rate=3/1000" -f lavfi -i "sine=frequency=1000:sample_rate=48000" +-ac 2 -acodec pcm_s16le -pix_fmt uyvy422 -format_code Hi30 -f decklink 'DeckLink Studio 2' +@end example + @end itemize @section libndi_newtek -- 2.16.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/opensrt: add Haivision Open SRT protocol
On Thu, Mar 8, 2018 at 7:55 PM, Michael Niedermayer
wrote:
>
> On Mon, Mar 05, 2018 at 05:09:04PM +0100, Sven Dueking wrote:
> >
> >
> > > -Ursprüngliche Nachricht-
> > > Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im Auftrag
> > > von Sven Dueking
> > > Gesendet: Dienstag, 27. Februar 2018 08:27
> > > An: 'FFmpeg development discussions and patches'
> > > Betreff: Re: [FFmpeg-devel] [PATCH] avformat/opensrt: add Haivision
> > > Open SRT protocol
> > >
> > >
> > >
> > > > -Ursprüngliche Nachricht-
> > > > Von: Sven Dueking [mailto:s...@nablet.com]
> > > > Gesendet: Mittwoch, 21. Februar 2018 15:25
> > > > An: 'FFmpeg development discussions and patches'
> > > > Betreff: AW: [FFmpeg-devel] [PATCH] avformat/opensrt: add Haivision
> > > > Open SRT protocol
> > > >
> > > >
> > > >
> > > > > -Ursprüngliche Nachricht-
> > > > > Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im
> > > > > Auftrag von Michael Niedermayer
> > > > > Gesendet: Mittwoch, 21. Februar 2018 14:35
> > > > > An: FFmpeg development discussions and patches
> > > > > Betreff: Re: [FFmpeg-devel] [PATCH] avformat/opensrt: add Haivision
> > > > > Open SRT protocol
> > > > >
> > > > > On Wed, Feb 21, 2018 at 10:16:48AM +0100, Sven Dueking wrote:
> > > > > > protocol requires libsrt (https://github.com/Haivision/srt) to be
> > > > > > installed
> > > > > >
> > > > > > Signed-off-by: Sven Dueking
> > > > > > ---
> > > > > > MAINTAINERS | 1 +
> > > > > > configure | 5 +
> > > > > > doc/protocols.texi | 134 ++-
> > > > > > libavformat/Makefile| 1 +
> > > > > > libavformat/opensrt.c | 589
> > > > > >
> > > > > > libavformat/protocols.c | 1 +
> > > > > > 6 files changed, 730 insertions(+), 1 deletion(-) create mode
> > > > > > 100644 libavformat/opensrt.c
> > > > > >
> > > > > > diff --git a/MAINTAINERS b/MAINTAINERS index b691bd5..3e0355a
> > > > 100644
> > > > > > --- a/MAINTAINERS
> > > > > > +++ b/MAINTAINERS
> > > > > > @@ -499,6 +499,7 @@ Protocols:
> > > > > >http.cRonald S. Bultje
> > > > > >libssh.c Lukasz Marek
> > > > > >mms*.cRonald S. Bultje
> > > > > > + opensrt.c sven Dueking
> > > > > >udp.c Luca Abeni
> > > > > >icecast.c Marvin Scholz
> > > > > >
> > > > > > diff --git a/configure b/configure index 013308c..9a78bae 100755
> > > > > > --- a/configure
> > > > > > +++ b/configure
> > > > > > @@ -294,6 +294,7 @@ External library support:
> > > > > >--enable-opengl enable OpenGL rendering [no]
> > > > > >--enable-openssl enable openssl, needed for https
> > > > support
> > > > > > if gnutls or libtls is not used [no]
> > > > > > + --enable-opensrt enable Haivision Open SRT protocol
> > > [no]
> > > > > >--disable-sndio disable sndio support [autodetect]
> > > > > >--disable-schannel disable SChannel SSP, needed for TLS
> > > > support
> > > > > on
> > > > > > Windows if openssl and gnutls are not
> > > > > > used [autodetect] @@ -1648,6 +1649,7 @@ EXTERNAL_LIBRARY_LIST="
> > > > > > mediacodec
> > > > > > openal
> > > > > > opengl
> > > > > > +opensrt
> > > > >
> > > > > there is something wrong with newlines this patch is corrupted and
> > > > > cannot be tested or applied
> > > > >
> > > > > [...]
> > > >
> > > > Hi Michael,
> > > >
> > > > Sorry, no idea why this happens. Patch attached.
> > >
> > > Ping ?!
> > >
> > > >
> > > > > --
> > > > > Michael GnuPG fingerprint:
> > > > 9FF2128B147EF6730BADF133611EC787040B0FAB
> > > > >
> > > > > Rewriting code that is poorly written but fully understood is good.
> > > > > Rewriting code that one doesnt understand is a sign that one is
> > > less
> > > > > smart then the original author, trying to rewrite it will not make
> > > > > it
> > > > better.
> > >
> >
> > Any chance to get feedback ?
>
> is anyone working on a review of this patch or intends to review it ?
>
> If not i intend to push it after a light review (i think there are
> other people around who are more qualified to review this than i am)
Just a cursory glance at the moment, I can functionally test tomorrow
(pretty familiar with SRT).
+{ "timeout","set timeout of socket I/O operations",
OFFSET(rw_timeout),
AV_OPT_TYPE_DURATION, { .i64 = -1 }, -1, INT_MAX, .flags = D|E },
+{ "listen_timeout", "Connection awaiting timeout",
OFFSET(listen_timeout),
AV_OPT_TYPE_DURATION, { .i64 = -1 }, -1, INT_MAX, .flags = D|E },
Is there guidance for option descriptions? The capitalization is inconsistent.
+{ "mss","the Maximum Transfer Unit",
[FFmpeg-devel] [PATCH] use proper macro to avoid issue with prior avutil/timestamp.c
>From b2ddfdd9ed695a1f47ed6251369abca08864e3ab Mon Sep 17 00:00:00 2001
From: Mike Lieman
Date: Fri, 16 Aug 2024 23:05:51 -0400
Subject: [PATCH] use proper macro to avoid issue with prior
avutil/timestamp.c
patch causing long startup times with some files under mplayer
(https://trac.mplayerhq.hu/ticket/2425)
---
libavutil/timestamp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/timestamp.c b/libavutil/timestamp.c
index 6c231a517d..eab2531538 100644
--- a/libavutil/timestamp.c
+++ b/libavutil/timestamp.c
@@ -24,7 +24,7 @@ char *av_ts_make_time_string2(char *buf, int64_t ts,
AVRational tb)
snprintf(buf, AV_TS_MAX_STRING_SIZE, "NOPTS");
} else {
double val = av_q2d(tb) * ts;
-double log = (fpclassify(val) == FP_ZERO ? -INFINITY :
floor(log10(fabs(val;
+double log = (fpclassify(val) == FP_ZERO ? FP_INFINITE :
floor(log10(fabs(val;
int precision = (isfinite(log) && log < 0) ? -log + 5 : 6;
int last = snprintf(buf, AV_TS_MAX_STRING_SIZE, "%.*f", precision,
val);
last = FFMIN(last, AV_TS_MAX_STRING_SIZE - 1) - 1;
--
2.46.0
___
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".
Re: [FFmpeg-devel] [PATCH] use proper macro to avoid issue with prior avutil/timestamp.c
> > FP_INFINITE is a return value from fpclassify(), not a double. > > Does maybe using av_int2double(UINT64_C(0xFFF) << 52) help your slow > startup? > Sadly, no. double log = (fpclassify(val) == FP_ZERO ? av_int2double(UINT64_C(0xFFF) << 52) : floor(log10(fabs(val; gives the same long-startup time. ___ 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".
Re: [FFmpeg-devel] [PATCH] use proper macro to avoid issue with prior avutil/timestamp.c
I now understand that and am trying to work through the logic to see why
we are getting this strange behaviour.When I have some free time, I
think I'm going to have to step through this with gdb since without the
context of what's actually in buf, ts, and tb I can't understand what's
going on in the for loops, but it seems something's going on in the for
loops, since it's not happening when I'm using the incorrect constant.
On Sat, Aug 17, 2024 at 10:07 AM Rémi Denis-Courmont
wrote:
>
>
> Le 17 août 2024 06:09:16 GMT+03:00, Mike Lieman a
> écrit :
> >From b2ddfdd9ed695a1f47ed6251369abca08864e3ab Mon Sep 17 00:00:00 2001
> >From: Mike Lieman
> >Date: Fri, 16 Aug 2024 23:05:51 -0400
> >Subject: [PATCH] use proper macro to avoid issue with prior
> >avutil/timestamp.c
> > patch causing long startup times with some files under mplayer
> > (https://trac.mplayerhq.hu/ticket/2425)
> >
> >---
> > libavutil/timestamp.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/libavutil/timestamp.c b/libavutil/timestamp.c
> >index 6c231a517d..eab2531538 100644
> >--- a/libavutil/timestamp.c
> >+++ b/libavutil/timestamp.c
> >@@ -24,7 +24,7 @@ char *av_ts_make_time_string2(char *buf, int64_t ts,
> >AVRational tb)
> > snprintf(buf, AV_TS_MAX_STRING_SIZE, "NOPTS");
> > } else {
> > double val = av_q2d(tb) * ts;
> >-double log = (fpclassify(val) == FP_ZERO ? -INFINITY :
> >floor(log10(fabs(val;
> >+double log = (fpclassify(val) == FP_ZERO ? FP_INFINITE :
>
> You're papering over whatever the real issue is here. As noted by James
> and the Trac issue already, FP_INFINITE is *not* a floating point value and
> using it this way makes no sense.
>
> >floor(log10(fabs(val;
> > int precision = (isfinite(log) && log < 0) ? -log + 5 : 6;
> > int last = snprintf(buf, AV_TS_MAX_STRING_SIZE, "%.*f",
> precision,
> >val);
> > last = FFMIN(last, AV_TS_MAX_STRING_SIZE - 1) - 1;
> ___
> 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".
>
___
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".
Re: [FFmpeg-devel] [PATCH] use proper macro to avoid issue with prior avutil/timestamp.c
> > On Sat, Aug 17, 2024 at 11:29 AM Hendrik Leppkes > wrote: > Or you could check if your build uses ffast-math, not sure we support that > Hot Dog! We have a weiner! Removing -ffast-math from my mplayer build appears to have resolved the issue. Thank you for your time and guidance. ___ 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".
[FFmpeg-devel] APNG blending with pixel format rgb24 not implemented
Per the message I get from ffmpeg/ffplay (likewise video players like mpv that depend on ffmpeg), I get the following message on every frame of an APNG file that I constructed: [apng @ 0x7f85c800a460] Blending with pixel format rgb24 is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented. The file is doom3-lights.png, and I have uploaded it to /incoming in the FTP also as the command suggests. It is a file I created by using ffmpeg to record from the game (with x11grab), outputted individual png frames from ffmpeg and then constructed into an APNG by using apngasm. As the message suggests, I tried compiling the current HEAD of ffmpeg and it still is unsupported. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: add xbr filter
Sent from my BlackBerry 10 smartphone on the Rogers network.
Original Message
From: Michael Niedermayer
Sent: Tuesday, October 28, 2014 17:51
To: FFmpeg development discussions and patches
Reply To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH] lavfi: add xbr filter
On Tue, Oct 28, 2014 at 07:16:45PM +0100, Clément Bœsch wrote:
> On Tue, Oct 28, 2014 at 06:30:34PM +0100, Stefano Sabatini wrote:
> [...]
> > How much effort would it take to implement the remaining scaling modes?
> >
>
> According to
> https://ffmpeg.org/pipermail/ffmpeg-devel/2014-October/164574.html
>
> "I think 4x can be done fast enough, but 3x will take time."
>
> [...]
> > > +typedef struct {
> > > + uint32_t rgbtoyuv[1<<24];
> >
> > We should avoid this 64MiB. Also the table should be possibly static,
> > so you don't have to fill it per each xBR instance.
> >
>
> So, I requested to do it exactly the same as HQx because this part is
> common according to the specifications. This should be kept the same
> vf_hqx, and then factorized.
>
> Now about removing this allocation, I did benchmark this LUT vs
> computation (see attached patch for comp. version). And the problem is
> that it's slightly slower, probably due to the /1000.
why do you divide at all ?
cant you do the computations with full precission ?
also instead of doing 2 rgb2yuv and then taking their difference you
can do the difference in rgb space and convert the rgb difference to
a yuv difference
its just aM - bM = (a-b)M
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: add xbr filter
Sent from my BlackBerry 10 smartphone on the Rogers network.
Original Message
From: Michael Niedermayer
Sent: Tuesday, October 28, 2014 17:51
To: FFmpeg development discussions and patches
Reply To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH] lavfi: add xbr filter
On Tue, Oct 28, 2014 at 07:16:45PM +0100, Clément Bœsch wrote:
> On Tue, Oct 28, 2014 at 06:30:34PM +0100, Stefano Sabatini wrote:
> [...]
> > How much effort would it take to implement the remaining scaling modes?
> >
>
> According to
> https://ffmpeg.org/pipermail/ffmpeg-devel/2014-October/164574.html
>
> "I think 4x can be done fast enough, but 3x will take time."
>
> [...]
> > > +typedef struct {
> > > + uint32_t rgbtoyuv[1<<24];
> >
> > We should avoid this 64MiB. Also the table should be possibly static,
> > so you don't have to fill it per each xBR instance.
> >
>
> So, I requested to do it exactly the same as HQx because this part is
> common according to the specifications. This should be kept the same
> vf_hqx, and then factorized.
>
> Now about removing this allocation, I did benchmark this LUT vs
> computation (see attached patch for comp. version). And the problem is
> that it's slightly slower, probably due to the /1000.
why do you divide at all ?
cant you do the computations with full precission ?
also instead of doing 2 rgb2yuv and then taking their difference you
can do the difference in rgb space and convert the rgb difference to
a yuv difference
its just aM - bM = (a-b)M
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: add xbr filter
Sent from my BlackBerry 10 smartphone on the Rogers network.
Original Message
From: Michael Niedermayer
Sent: Tuesday, October 28, 2014 17:51
To: FFmpeg development discussions and patches
Reply To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH] lavfi: add xbr filter
On Tue, Oct 28, 2014 at 07:16:45PM +0100, Clément Bœsch wrote:
> On Tue, Oct 28, 2014 at 06:30:34PM +0100, Stefano Sabatini wrote:
> [...]
> > How much effort would it take to implement the remaining scaling modes?
> >
>
> According to
> https://ffmpeg.org/pipermail/ffmpeg-devel/2014-October/164574.html
>
> "I think 4x can be done fast enough, but 3x will take time."
>
> [...]
> > > +typedef struct {
> > > + uint32_t rgbtoyuv[1<<24];
> >
> > We should avoid this 64MiB. Also the table should be possibly static,
> > so you don't have to fill it per each xBR instance.
> >
>
> So, I requested to do it exactly the same as HQx because this part is
> common according to the specifications. This should be kept the same
> vf_hqx, and then factorized.
>
> Now about removing this allocation, I did benchmark this LUT vs
> computation (see attached patch for comp. version). And the problem is
> that it's slightly slower, probably due to the /1000.
why do you divide at all ?
cant you do the computations with full precission ?
also instead of doing 2 rgb2yuv and then taking their difference you
can do the difference in rgb space and convert the rgb difference to
a yuv difference
its just aM - bM = (a-b)M
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: add xbr filter
Ыы
Sent from my BlackBerry 10 smartphone on the Rogers network.
Original Message
From: Michael Niedermayer
Sent: Tuesday, October 28, 2014 17:51
To: FFmpeg development discussions and patches
Reply To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH] lavfi: add xbr filter
On Tue, Oct 28, 2014 at 07:16:45PM +0100, Clément Bœsch wrote:
> On Tue, Oct 28, 2014 at 06:30:34PM +0100, Stefano Sabatini wrote:
> [...]
> > How much effort would it take to implement the remaining scaling modes?
> >
>
> According to
> https://ffmpeg.org/pipermail/ffmpeg-devel/2014-October/164574.html
>
> "I think 4x can be done fast enough, but 3x will take time."
>
> [...]
> > > +typedef struct {
> > > + uint32_t rgbtoyuv[1<<24];
> >
> > We should avoid this 64MiB. Also the table should be possibly static,
> > so you don't have to fill it per each xBR instance.
> >
>
> So, I requested to do it exactly the same as HQx because this part is
> common according to the specifications. This should be kept the same
> vf_hqx, and then factorized.
>
> Now about removing this allocation, I did benchmark this LUT vs
> computation (see attached patch for comp. version). And the problem is
> that it's slightly slower, probably due to the /1000.
why do you divide at all ?
cant you do the computations with full precission ?
also instead of doing 2 rgb2yuv and then taking their difference you
can do the difference in rgb space and convert the rgb difference to
a yuv difference
its just aM - bM = (a-b)M
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec Adding ff_v210_planar_unpack AVX2
Hello, I’ve accounted for all feedback on this so far, I’m wondering if it is ready to be pushed upstream? Here are my results from ‘checkasm’ (lower is better): v210_unpack_c: 1636 v210_unpack_ssse3: 611 v210_unpack_avx: 601 v210_unpack_avx2: 423 I ran it 5 times and averaged the middle 3 results for each CPU target (ignoring the highest and lowest time). https://patchwork.ffmpeg.org/patch/12325/ Thanks… -Mike ___ 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".
