Re: [FFmpeg-devel] [PATCH]Force __EXTENSIONS__ on Solaris
Michael Niedermayer gmx.at> writes: > the feature_tests.h and the header that contains > mreq likely should point at what is the cause The cause is the following check in the relevant header /usr/include/netinet/in.h: #if !defined(_XPG4_2) || defined(__EXTENSIONS__) We had set __EXTENSIONS__ for many years and I don't remember any reports while we set it. It comes down to the question how to use another libc on Solaris (and if it is a problem to set __EXTENSIONS__ on this hypothetical library). Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Add one CRLF to http headers if necessary
Michael Niedermayer gmx.at> writes: > if you only want t fix the end, then existing \r > and \n should be stripped and crlf be added > litterally without use of \r\n but literal byte > values On which system can I test this (so that it actually makes a difference)? Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Add one CRLF to http headers if necessary
Le nonidi 19 ventôse, an CCXXIII, Michael Niedermayer a écrit : > there should be a loop that replaces each sequence of any \n\r by a single > crlf sequency > also ensure that one such sequence is at the end I believe this would be correct. > using no \r \n codes but only litteral bytes and This part would also be correct, but I believe it is completely unnecessary: POSIX specifies the byte value of \r and \n (the C standard does not), and AFAIK we never had bug reports that could even remotely be linked to that issue. And seriously, if a compiler were to use different values, FATE would fail all over the place immediately. It does not matter much, since this is equivalent, but I believe most C programmers will find \n and \r much more readable than \012 and \015 or even \x0a and \x0d; I do. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Post-processing filter Documentation
On date Tuesday 2015-03-03 21:37:03 -0400, Peter Cordes encoded: > On Sat, Feb 7, 2015 at 6:23 AM, arwa arif wrote: > > > On Mon, Feb 2, 2015 at 10:23 AM, Michael Niedermayer > > wrote: > > > > > On Sat, Jan 31, 2015 at 02:30:29PM +0530, arwa arif wrote: > > > > On Thu, Jan 29, 2015 at 5:18 PM, Stefano Sabatini > > > > wrote: > > > > > > > > > On date Thursday 2015-01-29 03:46:42 +0530, Arwa Arif encoded: > > > > > > I have updated the page with new images. > > > > > > http://trac.ffmpeg.org/wiki/Postprocessing > > > > I used this command to create the query image: > > > > ffmpeg -i matrixbench_mpeg2.mpg -b:v 200k matrixbench_mpeg2-lq.mpg > > > > The wiki page just says "compressed to 200kbps", which is not nearly enough > information. I was going to just update that in the wiki, but then ended > up replacing a bunch of the earlier text. > > Before, it didn't even mention that modern codecs have built-in > deblocking, and usually don't look better when you PP. Anyway, I rewrote a > lot of stuff, and I think it's a lot more informative now. Yes, it's much better now, thanks. -- FFmpeg = Fantastic and Freak Multimedia Power Extravagant Governor ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: Add support to process_command in vf_eq.c
On date Tuesday 2015-03-10 00:27:52 +0530, Arwa Arif encoded:
> On Fri, Feb 20, 2015 at 5:41 AM, Stefano Sabatini
> wrote:
>
> > On date Thursday 2015-02-19 17:13:15 +0530, Arwa Arif encoded:
> > > Updated the patch.
> >
> > > From 66a8c9d03995c9e7c6ccc05fb9b20756f51c17f4 Mon Sep 17 00:00:00 2001
> > > From: Arwa Arif
> > > Date: Thu, 19 Feb 2015 01:26:44 +0530
> > > Subject: [PATCH] Add process_command to eq.
> > >
> > > ---
> > > doc/filters.texi| 35 +++
> > > libavfilter/vf_eq.c | 171
> > +--
> > > libavfilter/vf_eq.h | 56 +++--
> > > 3 files changed, 210 insertions(+), 52 deletions(-)
> > >
> > > diff --git a/doc/filters.texi b/doc/filters.texi
> > > index 191b52f..e5bf3a2 100644
> > > --- a/doc/filters.texi
> > > +++ b/doc/filters.texi
> > > @@ -4402,6 +4402,41 @@ Default is @code{1.0}.
> > >
> > > @end table
> > >
> > > +@subsection Commands
> > > +The filter supports the following commands:
> > > +
> > > +@table @option
> > > +@item contrast
> > > +Set the contrast expression.
> > > +
> > > +@item brightness
> > > +Set the brightness expression.
> > > +
> > > +@item saturation
> > > +Set the saturation expression.
> > > +
> > > +@item gamma
> > > +Set the gamma expression.
> > > +
> > > +@item gamma_r
> > > +Set the gamma_r expression.
> > > +
> > > +@item gamma_g
> > > +Set gamma_g expression.
> > > +
> > > +@item gamma_b
> > > +Set gamma_b expression.
> > > +
> > > +@item gamma_weight
> > > +Set gamma_weight expression.
> > > +
> > > +The command accepts the same syntax of the corresponding option.
> >
> > What parameters do the expressions accept? Can you suggest some useful
> > use-case? (And add useful examples in the docs?)
> >
> >
> There are no parameters accepted by the expressions. I will add some
> examples in the doc.
Look how it is done in hue. In general an expression is useful if you
want to express something in function of the time or the number of
frame or something else.
[...]
> > > +if (!strcmp(cmd, "contrast")) {
> > > +ret = set_expr(&eq->contrast_pexpr, args, cmd, ctx);
> > > +set_contrast(eq);
> > > +return ret;
> > > +}
> > > +else if (!strcmp(cmd, "brightness")) {
> > > +ret = set_expr(&eq->brightness_pexpr, args, cmd, ctx);
> > > +set_brightness(eq);
> > > +return ret;
> > > +}
> > > +else if (!strcmp(cmd, "saturation")) {
> > > +ret = set_expr(&eq->saturation_pexpr, args, cmd, ctx);
> > > +set_saturation(eq);
> > > +return ret;
> > > +}
> > > +else if (!strcmp(cmd, "gamma")) {
> > > +ret = set_expr(&eq->gamma_pexpr, args, cmd, ctx);
> > > +set_gamma(eq);
> > > +return ret;
> > > +}
> > > +else if (!strcmp(cmd, "gamma_r")) {
> > > +ret = set_expr(&eq->gamma_r_pexpr, args, cmd, ctx);
> > > +set_gamma(eq);
> > > +return ret;
> > > +}
> > > +else if (!strcmp(cmd, "gamma_g")) {
> > > +ret = set_expr(&eq->gamma_g_pexpr, args, cmd, ctx);
> > > +set_gamma(eq);
> > > +return ret;
> > > +}
> > > +else if (!strcmp(cmd, "gamma_b")) {
> > > +ret = set_expr(&eq->gamma_b_pexpr, args, cmd, ctx);
> > > +set_gamma(eq);
> > > +return ret;
> > > +}
> > > +else if (!strcmp(cmd, "gamma_weight")) {
> > > +ret = set_expr(&eq->gamma_weight_pexpr, args, cmd, ctx);
> > > +set_gamma(eq);
> > > +return ret;
> >
> > this can be probably factorized using a macro
> >
> >
> Okay. I was going through other filters which use macros, can you explain
> me the what is meant by the symbol ## in statement no.2 of the following
> code snippet:
## is the concatenation operator. See for example:
https://gcc.gnu.org/onlinedocs/cpp/Concatenation.html
> #define SET_SIZE_EXPR(name, opt_name) do {
> \
> ret = av_expr_parse_and_eval(&res, expr = rot->name##_expr_str,
>\
> var_names, rot->var_values,
> \
> func1_names, func1, NULL, NULL, rot, 0,
> ctx); \
> if (ret < 0 || isnan(res) || isinf(res) || res <= 0) {
> \
> av_log(ctx, AV_LOG_ERROR,
>\
>"Error parsing or evaluating expression for option %s: "
>\
>"invalid expression '%s' or non-positive or indefinite value
> %f\n", \
>opt_name, expr, res);
> \
> return ret;
>\
> }
Something like:
#define SET_PARAM(param_name) \
if (!strcmp(cmd, param_name)) { \
ret = set_expr(&eq->param_name##_pexpr, args, cmd, ctx); \
set_##param_name(eq); \
return ret; \
}
SET_PARAM(contrast);
SET_PARAM(brightness);
...
should probably work.
[...]
--
FFmpeg = Faithful and Forgiving Multimedia Pacific Exploitable Gadget
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
htt
Re: [FFmpeg-devel] [PATCH] lavfi: Add support to process_command in vf_eq.c
On date Monday 2015-03-09 19:54:57 +0530, Arwa Arif encoded: > I was going through the code, and I realized that I have made a mistake. I > have corrected the code, and attached the corresponding patch. > From 2ebd299b55a34914d5549f21d264e8cb7f5f605d Mon Sep 17 00:00:00 2001 > From: Arwa Arif > Date: Mon, 9 Mar 2015 19:50:32 +0530 > Subject: [PATCH] Fix the wrong parsing style in vf_eq lavfi/eq: fix ... > > blah ? Please explain what's wrong with the current code in the commit log, and be more explicit in the subject. > --- > libavfilter/vf_eq.c | 33 - > libavfilter/vf_eq.h | 34 -- > 2 files changed, 24 insertions(+), 43 deletions(-) Also, I think retaining expression parameters may be useful if you add meaningful parameters (e.g. time, as in hue). [...] -- FFmpeg = Forgiving and Fanciful Martial Pitiless Erotic Guru ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 1/2] rtpenc_mpegts: Free the right ->pb in the error path in the init function
On Mon, Mar 09, 2015 at 11:16:13PM +0100, Andreas Cadhalpun wrote:
> On 09.03.2015 22:15, Martin Storsjö wrote:
> >This fixes a typo from 8e32b1f096.
> >---
> > libavformat/rtpenc_mpegts.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/libavformat/rtpenc_mpegts.c b/libavformat/rtpenc_mpegts.c
> >index 8ad446b..8ced6a9 100644
> >--- a/libavformat/rtpenc_mpegts.c
> >+++ b/libavformat/rtpenc_mpegts.c
> >@@ -98,7 +98,7 @@ static int rtp_mpegts_write_header(AVFormatContext *s)
> >
> > fail:
> > if (mpegts_ctx) {
> >-ffio_free_dyn_buf(&chain->mpegts_ctx->pb);
> >+ffio_free_dyn_buf(&mpegts_ctx->pb);
> > avformat_free_context(mpegts_ctx);
> > }
> > if (rtp_ctx)
> >
>
> This change looks correct, because chain->mpegts_ctx is NULL if
> mpegts_ctx isn't.
merged
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 2/2] rtpenc_mpegts: Set chain->rtp_ctx only after avformat_write_header succeeded
On Mon, Mar 09, 2015 at 11:18:30PM +0100, Andreas Cadhalpun wrote: > On 09.03.2015 22:15, Martin Storsjö wrote: > >By making sure we at each time only have one pointer set, either a > >local variable or one in the context, we avoid potential double frees > >in the cleanup routines. If chain->rtp_ctx is set, it is closed by > >calling avformat_write_trailer, but that shouldn't be called unless > >avformat_write_header succeeded. > > > >This issue was pointed out by Andreas Cadhalpun. > >--- > >Andreas, does this seem to fix the issue for you as well? > > Yes, it does. > > >--- > > libavformat/rtpenc_mpegts.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > >diff --git a/libavformat/rtpenc_mpegts.c b/libavformat/rtpenc_mpegts.c > >index 8ced6a9..585d1ad 100644 > >--- a/libavformat/rtpenc_mpegts.c > >+++ b/libavformat/rtpenc_mpegts.c > >@@ -88,11 +88,10 @@ static int rtp_mpegts_write_header(AVFormatContext *s) > > st->time_base.num = 1; > > st->time_base.den = 9; > > st->codec->codec_id = AV_CODEC_ID_MPEG2TS; > >-chain->rtp_ctx = rtp_ctx; > > rtp_ctx->pb = s->pb; > > if ((ret = avformat_write_header(rtp_ctx, NULL)) < 0) > > goto fail; > >-rtp_ctx = NULL; > >+chain->rtp_ctx = rtp_ctx; > > > > return 0; > > > > > > This looks like the proper fix. merged thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In fact, the RIAA has been known to suggest that students drop out of college or go to community college in order to be able to afford settlements. -- The RIAA signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]Fix arm compilation with --disable-neon
Hi! Attached patch fixes compilation for arm with --disable-neon, reported by Sebastian Holmqvist. Please comment, Carl Eugen diff --git a/libavcodec/hevcdsp.c b/libavcodec/hevcdsp.c index 04af178..b7a4729 100644 --- a/libavcodec/hevcdsp.c +++ b/libavcodec/hevcdsp.c @@ -259,6 +259,6 @@ int i = 0; if (ARCH_X86) ff_hevc_dsp_init_x86(hevcdsp, bit_depth); -if (ARCH_ARM) +if (HAVE_NEON) ff_hevcdsp_init_arm(hevcdsp, bit_depth); } ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AAC: [PATCH] AAC: Add support for 7350Hz sampling rates
On Tue, Mar 10, 2015 at 12:37:34AM -0300, Claudio Freire wrote: > On Mon, Mar 9, 2015 at 3:31 PM, Claudio Freire wrote: > > On Mon, Mar 9, 2015 at 1:38 PM, Michael Niedermayer > > wrote: > >> On Mon, Mar 09, 2015 at 01:31:26PM -0300, Claudio Freire wrote: > >>> On Mon, Mar 9, 2015 at 1:26 PM, Michael Niedermayer > >>> wrote: > >>> > doesnt help > >>> > but > >>> > this does: > >>> > -fate-aac-s7350-encode: CMD = enc_dec_pcm adts wav s16le $(REF) -strict > >>> > -2 -c:a aac -b:a 256k > >>> > +fate-aac-s7350-encode: CMD = enc_dec_pcm adts wav s16le $(REF) -strict > >>> > -2 -c:a aac -b:a 88k > >>> > > >>> > this seems to fix it, didnt ivestigate why ... > >>> > >>> 88k is the maximum allowed bitrate at 7350hz, but it shouldn't make > >>> any difference given that lavc/aacenc.c:775 already clamps the bitrate > >>> to that number. > >> > >> i think it clamps to 88200 while 88k sets 88000 > >> i can reproduce the difference with -b:a 88200 > > > > Oh... I see. > > > > There's a specific implementation for mips, I had completely > > overlooked it on all patchesets. > > > > I'll have to look into it more thoroughly, most earlier patches should > > be applied to that implementation as well when applicable. > > Ok, try the attached patch on top of the previous ones, see what it > does. stddev: 443.22 PSNR: 43.40 MAXDIFF: 5038 bytes: 176400/ 180224 stddev: |443.22 - 414| >= 5 Duration: 00:00:06.89, bitrate: 57 kb/s Stream #0:0: Audio: aac (LC), 7350 Hz, stereo, fltp, 57 kb/s > I cannot test myself yet (cannot build against mips, it will > probably take me a long while before I can set up qemu for that), but > the patch should bring both implementations in sync, at least enough > for the test to pass without the -b:a 88k if you use a debian based distro then the packages from http://www.emdebian.org/ can probably be used to cross compile to mips (you might need to force some versions manually during install, at least in the past the binary packages referred to many non existing package versions so only some versions of the packages had all dependancies available) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pthread: Fix ff_thread_get_formatissues when called outside frame decode.
On Mon, 09 Mar 2015 18:56:57 +0100 Reimar Döffinger wrote: > On 9 March 2015 15:28:48 CET, Hendrik Leppkes wrote: > >On Mon, Mar 9, 2015 at 1:50 PM, Reimar Döffinger > > wrote: > >> On 9 March 2015 13:34:24 CET, Hendrik Leppkes > >wrote: > >>>On Mon, Mar 9, 2015 at 7:38 AM, Rainer Hochecker > >>> wrote: > Reimar Döffinger gmx.de> writes: > > > > > Any reason to believe this patch causes it? > > Because I can't see how it would. > > Maybe it's just a bug with DXVA and multithreading in the HEVC > >code? > > Can you provide some more information like a stacktrace, possibly > >>>using a > tool like DrMemory? > > I don't think the patch itself is the root cause of the issue, it > >>>just > triggers it. get_format is called 4 times, something seems to get > >>>corrupted > in opening our hw decoder. > Do you have an explanation why it works with thread_safe_callbacks > >>>set to 1? > > I am wondering if hevc misses the multithreading fix done for other > >>>codecs: > http://ffmpeg.org/pipermail/ffmpeg-cvslog/2013-March/062620.html > > What do you think? > > >>> > >>>I build the HEVC HWAccel support, and I consider frame-threading with > >>>hwaccel an abomination that should not be supported, so I didn't > >spend > >>>any time thinking about it. > >>> > >>>Honestly, there are several issues with MT+HWaccel in H264 as well, > >at > >>>least on Intel hardware, so I can only strongly urge everyone to not > >>>combine it. There is zero advantages, and only downsides! > >> > >> Only if you completely ignore the practical issues that anyone trying > >to use it will have. > >> In many cases applications will not know whether hardware supports > >decoding the video until there get_format call. Worse, it can even > >change from supported to not supported. > >> Do you expect everyone to disable multithreading "just in case"? > >Buffer the last n bits of data to be able to restart decoding? > > > >What I do is simply restart decoding with the packet that failed the > >hardware decoder. Don't need to buffer anything, you still have the > >AVPacket in question anyway. > > Uh, so you simply assume that decoding the same frame twice doesn't break > anything? How do you enable multithreading? Do you just assume you can do > that in the middle of decoding? > Or do you create a new decoder? In which case, how do you ensure that the new > SPS wasn't in an earlier packet due to bad muxing for example? > Also the buffering issue is the other way, when you try to go from > multithreading to HW decode, how do you handle that? > If it works well I'd be totally in favour, but I strongly suspect it only > works because you both got lucky and don't even try the hard things and still > need more code on the user side. Just create a new context. Really, there are (or will be) hardware decoders which do not fit into the hwaccel model. So you need to open a new codec anyway to handle fallbacks correctly. I think the current way how hardware decoding fallback is supposed to work in lavc sucks by design, has multiple implementation problems (like this one!), and is a dead-end. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Fix arm compilation with --disable-neon
On Tue, Mar 10, 2015 at 12:03:35PM +0100, Carl Eugen Hoyos wrote: > Hi! > > Attached patch fixes compilation for arm with --disable-neon, > reported by Sebastian Holmqvist. > > Please comment, Carl Eugen > hevcdsp.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > a2e07b355b70d0a91f1c0622fd2e40c04a1a52d7 patchhevcneon.diff > diff --git a/libavcodec/hevcdsp.c b/libavcodec/hevcdsp.c > index 04af178..b7a4729 100644 > --- a/libavcodec/hevcdsp.c > +++ b/libavcodec/hevcdsp.c > @@ -259,6 +259,6 @@ int i = 0; > > if (ARCH_X86) > ff_hevc_dsp_init_x86(hevcdsp, bit_depth); > -if (ARCH_ARM) > +if (HAVE_NEON) > ff_hevcdsp_init_arm(hevcdsp, bit_depth); probably ok unless someone intends to add non neon optimizations [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Force __EXTENSIONS__ on Solaris
On Tue, Mar 10, 2015 at 07:54:15AM +, Carl Eugen Hoyos wrote: > Michael Niedermayer gmx.at> writes: > > > the feature_tests.h and the header that contains > > mreq likely should point at what is the cause > > The cause is the following check in the relevant > header /usr/include/netinet/in.h: > #if !defined(_XPG4_2) || defined(__EXTENSIONS__) > We had set __EXTENSIONS__ for many years and I > don't remember any reports while we set it. > > It comes down to the question how to use another > libc on Solaris (and if it is a problem to set > __EXTENSIONS__ on this hypothetical library). why is _XPG4_2 set ? doesnt this mean you want ONLY _XPG4_2 which is what you get i assume without checking all the specs ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Add one CRLF to http headers if necessary
On Tue, Mar 10, 2015 at 09:39:50AM +0100, Nicolas George wrote: > Le nonidi 19 ventôse, an CCXXIII, Michael Niedermayer a écrit : > > there should be a loop that replaces each sequence of any \n\r by a single > > crlf sequency > > > also ensure that one such sequence is at the end > > I believe this would be correct. > > > using no \r \n codes but only litteral bytes and > > This part would also be correct, but I believe it is completely unnecessary: > POSIX specifies the byte value of \r and \n (the C standard does not), and > AFAIK we never had bug reports that could even remotely be linked to that > issue. And seriously, if a compiler were to use different values, FATE would > fail all over the place immediately. > > It does not matter much, since this is equivalent, but I believe most C > programmers will find \n and \r much more readable than \012 and \015 or > even \x0a and \x0d; I do. iam fine with either, i was just trying to be completely correct which may be overkill and indeed make the code less readable for no gain [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Force __EXTENSIONS__ on Solaris
Michael Niedermayer gmx.at> writes: > > The cause is the following check in the relevant > > header /usr/include/netinet/in.h: > > #if !defined(_XPG4_2) || defined(__EXTENSIONS__) > > We had set __EXTENSIONS__ for many years and I > > don't remember any reports while we set it. > why is _XPG4_2 set ? One of the following is responsible afaict: -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -std=c99 I don't know which and I don't know how to find out. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Force __EXTENSIONS__ on Solaris
On Tue, Mar 10, 2015 at 12:04:48PM +, Carl Eugen Hoyos wrote: > Michael Niedermayer gmx.at> writes: > > > > The cause is the following check in the relevant > > > header /usr/include/netinet/in.h: > > > #if !defined(_XPG4_2) || defined(__EXTENSIONS__) > > > We had set __EXTENSIONS__ for many years and I > > > don't remember any reports while we set it. > > > why is _XPG4_2 set ? > > One of the following is responsible afaict: > -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 > -D_XOPEN_SOURCE=600 -std=c99 > I don't know which and I don't know how to find out. re-reading the headers, i think they are actually broken your original patch seems the only way to make this work, sorry patch should be ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Add one CRLF to http headers if necessary
Le decadi 20 ventôse, an CCXXIII, Michael Niedermayer a écrit :
> iam fine with either, i was just trying to be completely correct
> which may be overkill and indeed make the code less readable for no
> gain
What about the attached patch?
Regards,
--
Nicolas George
From 28fc644a1d7e4f73921bbc9ab7c103de922480f1 Mon Sep 17 00:00:00 2001
From: Nicolas George
Date: Tue, 10 Mar 2015 13:43:17 +0100
Subject: [PATCH] lavf/http: cleanup headers option string.
Replace any sequence of CR or LF with a single CRLF
and make sure there is a final CRLF.
Signed-off-by: Nicolas George
---
libavformat/http.c | 65 ++
1 file changed, 65 insertions(+)
diff --git a/libavformat/http.c b/libavformat/http.c
index 55dcb6e..5371e92 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -25,6 +25,7 @@
#include
#endif /* CONFIG_ZLIB */
+#include "libavutil/avassert.h"
#include "libavutil/avstring.h"
#include "libavutil/opt.h"
@@ -292,6 +293,67 @@ int ff_http_averror(int status_code, int default_averror)
return default_averror;
}
+/**
+ * Cleanup HTTP headers option string
+ * Replace any sequence of CR or LF with a single CRLF (empty lines are not
+ * valid in HTTP) and make sure there is a final CRLF.
+ */
+static int cleanup_headers_option(char **str)
+{
+char *in = *str, *out, *p, *q;
+size_t nb_chars = 0, nb_lf = 0, out_size;
+int clean = 1, eol = 0;
+
+if (!in)
+return 0;
+p = in;
+while (*p) {
+if (*p == '\n' || *p == '\r') {
+nb_lf++;
+eol = 1;
+if (p[0] != '\r' || p[1] != '\n' || p[2] == '\n' || p[2] == '\r')
+clean = 0;
+while (*p == '\n' || *p == '\r')
+p++;
+} else {
+nb_chars++;
+eol = 0;
+p++;
+}
+}
+if (clean && eol)
+return 0;
+if (!eol)
+nb_lf++;
+if (nb_lf >= (SIZE_MAX - nb_chars) / 2 - 1)
+return AVERROR(ENOMEM);
+out_size = nb_chars + nb_lf * 2 + 1;
+out = av_realloc(NULL, out_size);
+if (!out)
+return AVERROR(ENOMEM);
+p = in;
+q = out;
+while (*p) {
+if (*p == '\n' || *p == '\r') {
+*(q++) = '\r';
+*(q++) = '\n';
+while (*p == '\n' || *p == '\r')
+p++;
+} else {
+*(q++) = *(p++);
+}
+}
+if (!eol) {
+*(q++) = '\r';
+*(q++) = '\n';
+}
+*(q++) = 0;
+av_assert0(q == out + out_size);
+av_free(in);
+*str = out;
+return 0;
+}
+
static int http_open(URLContext *h, const char *uri, int flags,
AVDictionary **options)
{
@@ -310,6 +372,9 @@ static int http_open(URLContext *h, const char *uri, int flags,
if (options)
av_dict_copy(&s->chained_options, *options, 0);
+ret = cleanup_headers_option(&s->headers);
+if (ret < 0)
+return ret;
if (s->headers) {
int len = strlen(s->headers);
if (len < 2 || strcmp("\r\n", s->headers + len - 2))
--
2.1.4
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Add one CRLF to http headers if necessary
Nicolas George nsup.org> writes: > What about the attached patch? Please add a reference to ticket #3268 to the commit message. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Add one CRLF to http headers if necessary
Le decadi 20 ventôse, an CCXXIII, Carl Eugen Hoyos a écrit : > Please add a reference to ticket #3268 > to the commit message. I was about to reply "locally added", but no, because it does not fix that ticket. Re-thinking on the whole discussion, I withdraw this patch, it is wrong. This part of the code is an API, not an UI, so it is better if it is strict. I will try to propose another patch for pure validation. Regarding the trac ticket itself, I wrote this, and I stick to it: # I am not in favour of fixing the shortcomings of the user's shell in # FFmpeg's libraries # If we are talking about end-user interface, the changes should happen in # cmdutils.c. In other words, I vote for closing #3268 as WONTFIX and suggesting windows users to use a better shell (maybe the so-called powershell introduced in the recent windows versions can do it). If people really want to fix microsoft's shortcomings in FFmpeg, then it must happen in the UI, not the API, i.e. in cmdutils.c. Maybe something like that: "ffmpeg ... -expand -headers 'Cookies: chocolate\r\n'" (-expand being a new option meaning "perform escape-character expansion on the following option argument"). But I do not intend to work on it, because anybody can get a shell where $'\r\n' works. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AAC: [PATCH] AAC: Add support for 7350Hz sampling rates
On Tue, Mar 10, 2015 at 8:05 AM, Michael Niedermayer wrote: >> I cannot test myself yet (cannot build against mips, it will >> probably take me a long while before I can set up qemu for that), but >> the patch should bring both implementations in sync, at least enough >> for the test to pass without the -b:a 88k > > if you use a debian based distro then the packages from > http://www.emdebian.org/ > can probably be used to cross compile to mips > (you might need to force some versions manually during install, at > least in the past the binary packages referred to many non existing > package versions so only some versions of the packages had all > dependancies available) I don't have any debian or its derivatives at hand sadly. I may unearth an old laptop that had some form of ubuntu at some point, it's old and slow but that shouldn't be a problem for this sort of thing, but that will have to wait until next week. In the meantime I'm trying to make cross-mips-linux-gcc work on openSuse without much luck yet. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Fixed memory leak in EvalContext::channel_values
There are some doubles being allocated in aeval_config_output which is called by avfilter_graph_config. They are not being deleted and I am (on my filter graph) seeing two doubles (16 bytes on my system) of leaked memory. - Ole Andre Birkedal From e4c6316a2d90624277f933fe64b5c8397793b6ca Mon Sep 17 00:00:00 2001 From: Ole Andre Birkedal Date: Tue, 10 Mar 2015 14:12:30 +0100 Subject: [PATCH] Fixed a memory leak in EvalContext::channel_values --- libavfilter/aeval.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavfilter/aeval.c b/libavfilter/aeval.c index 45629a9..69de1f7 100644 --- a/libavfilter/aeval.c +++ b/libavfilter/aeval.c @@ -217,6 +217,7 @@ static av_cold void uninit(AVFilterContext *ctx) eval->expr[i] = NULL; } av_freep(&eval->expr); +av_freep(&eval->channel_values); } static int config_props(AVFilterLink *outlink) -- 1.9.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] GSoC Introduction
Hi everyone! My name is David Reidler and I am an undergraduate student looking to participate in GSoC 2015. My IRC handle on freenode is dreidler. After reviewing the ideas on the wiki page, I would like to work on implementing basic servers for network protocols. I enjoy programming in C, and have experience writing network clients and servers. I hope that GSoC allows me to help FFmpeg and help me get my foot in the door to contributing towards open source software. Regards, David ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fixed memory leak in EvalContext::channel_values
On Tue, Mar 10, 2015 at 02:23:26PM +0100, Ole Andre Birkedal wrote: > There are some doubles being allocated in aeval_config_output which is > called by avfilter_graph_config. They are not being deleted and I am (on my > filter graph) seeing two doubles (16 bytes on my system) of leaked memory. > > - Ole Andre Birkedal > aeval.c |1 + > 1 file changed, 1 insertion(+) > 5359214c3c0481bb0b16a92748283e6eeb8205bc fix_channel_values.patch > From e4c6316a2d90624277f933fe64b5c8397793b6ca Mon Sep 17 00:00:00 2001 > From: Ole Andre Birkedal > Date: Tue, 10 Mar 2015 14:12:30 +0100 > Subject: [PATCH] Fixed a memory leak in EvalContext::channel_values applied can you also add a fate test for aeval ? we have one for aevalsrc which didt catch this leak thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] GSoC Introduction
Le decadi 20 ventôse, an CCXXIII, David Reidler a écrit : > My name is David Reidler and I am an undergraduate student looking to > participate in GSoC 2015. My IRC handle on freenode is dreidler. > > After reviewing the ideas on the wiki page, I would like to work on > implementing basic servers for network protocols. > > I enjoy programming in C, and have experience writing network clients and > servers. I hope that GSoC allows me to help FFmpeg and help me get my foot > in the door to contributing towards open source software. Welcome on the list. Several people have already stated their interest on the same project, including, as you can see on the wiki, someone who already started working on a proof-of-concept HTTP server, so I suggest you do not waste time for discussing an actual qualification task. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]Print number of reference frames if debug level >= verbose
Hi!
Attached patch prints the number of reference frames
on increased loglevel.
Please comment, Carl Eugen
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 5b28496..aa00581 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -3024,6 +3024,8 @@ void avcodec_string(char *buf, int buf_size,
AVCodecContext *enc, int encode)
if (profile)
snprintf(buf + strlen(buf), buf_size - strlen(buf), " (%s)", profile);
+if (av_log_get_level() >= AV_LOG_VERBOSE && enc->refs)
+snprintf(buf + strlen(buf), buf_size - strlen(buf), ", %d reference
frame(s)", enc->refs);
if (enc->codec_tag) {
char tag_buf[32];
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Add one CRLF to http headers if necessary
On Tue, 10 Mar 2015 14:09:10 +0100 Nicolas George wrote: > Le decadi 20 ventôse, an CCXXIII, Carl Eugen Hoyos a écrit : > > Please add a reference to ticket #3268 > > to the commit message. > > I was about to reply "locally added", but no, because it does not fix that > ticket. > > Re-thinking on the whole discussion, I withdraw this patch, it is wrong. This > part of the code is an API, not an UI, so it is better if it is strict. I > will try to propose another patch for pure validation. > > Regarding the trac ticket itself, I wrote this, and I stick to it: > > # I am not in favour of fixing the shortcomings of the user's shell in > # FFmpeg's libraries > > # If we are talking about end-user interface, the changes should happen in > # cmdutils.c. > > In other words, I vote for closing #3268 as WONTFIX and suggesting windows > users to use a better shell (maybe the so-called powershell introduced in > the recent windows versions can do it). > > If people really want to fix microsoft's shortcomings in FFmpeg, then it > must happen in the UI, not the API, i.e. in cmdutils.c. Maybe something like > that: "ffmpeg ... -expand -headers 'Cookies: chocolate\r\n'" (-expand being > a new option meaning "perform escape-character expansion on the following > option argument"). But I do not intend to work on it, because anybody can > get a shell where $'\r\n' works. > > Regards, > Why not fix the shortcomings in FFmpeg? (The option API.) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pthread: Fix ff_thread_get_formatissues when called outside frame decode.
On 10.03.2015, at 12:10, wm4 wrote: > On Mon, 09 Mar 2015 18:56:57 +0100 > Reimar Döffinger wrote: >>> >>> What I do is simply restart decoding with the packet that failed the >>> hardware decoder. Don't need to buffer anything, you still have the >>> AVPacket in question anyway. >> >> Uh, so you simply assume that decoding the same frame twice doesn't break >> anything? How do you enable multithreading? Do you just assume you can do >> that in the middle of decoding? >> Or do you create a new decoder? In which case, how do you ensure that the >> new SPS wasn't in an earlier packet due to bad muxing for example? >> Also the buffering issue is the other way, when you try to go from >> multithreading to HW decode, how do you handle that? >> If it works well I'd be totally in favour, but I strongly suspect it only >> works because you both got lucky and don't even try the hard things and >> still need more code on the user side. > > Just create a new context. There is nothing "just" about creating a new context, not for those who want seamless switching between hardware and software decoding. I am not one of those people admittedly, but I do see it as an issue. > Really, there are (or will be) hardware decoders which do not fit into > the hwaccel model. So you need to open a new codec anyway to handle > fallbacks correctly. I think the current way how hardware decoding > fallback is supposed to work in lavc sucks by design, has multiple > implementation problems (like this one!), and is a dead-end. That may well be, but that doesn't mean it should be our goal to make things work worse and be even more effort for users. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] [PATCH] lavfi: add inverse telecine filter
This is an exact inverse of the telecine filter unlike previously existing
pullup and fieldmatch ones.
The algorithm was briefly discussed with Carl. The algorithm is not completely
tested, though I do have a some sample suggestions and will be testing on
them soon. Documentation is yet to be added.
---
Changelog | 1 +
libavfilter/Makefile| 1 +
libavfilter/allfilters.c| 1 +
libavfilter/vf_detelecine.c | 323
4 files changed, 326 insertions(+)
create mode 100644 libavfilter/vf_detelecine.c
diff --git a/Changelog b/Changelog
index e88359d..341faca 100644
--- a/Changelog
+++ b/Changelog
@@ -3,6 +3,7 @@ releases are sorted from youngest to oldest.
version :
- FFT video filter
+- Detelecine filter
version 2.6:
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index b184f07..399072c 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -112,6 +112,7 @@ OBJS-$(CONFIG_DECIMATE_FILTER) +=
vf_decimate.o
OBJS-$(CONFIG_DEJUDDER_FILTER) += vf_dejudder.o
OBJS-$(CONFIG_DELOGO_FILTER) += vf_delogo.o
OBJS-$(CONFIG_DESHAKE_FILTER)+= vf_deshake.o
+OBJS-$(CONFIG_DETELECINE_FILTER)+= vf_detelecine.o
OBJS-$(CONFIG_DRAWBOX_FILTER)+= vf_drawbox.o
OBJS-$(CONFIG_DRAWGRID_FILTER) += vf_drawbox.o
OBJS-$(CONFIG_DRAWTEXT_FILTER) += vf_drawtext.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 043ac56..2e4e2f6 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -128,6 +128,7 @@ void avfilter_register_all(void)
REGISTER_FILTER(DEJUDDER, dejudder, vf);
REGISTER_FILTER(DELOGO, delogo, vf);
REGISTER_FILTER(DESHAKE,deshake,vf);
+REGISTER_FILTER(DETELECINE, detelecine, vf);
REGISTER_FILTER(DRAWBOX,drawbox,vf);
REGISTER_FILTER(DRAWGRID, drawgrid, vf);
REGISTER_FILTER(DRAWTEXT, drawtext, vf);
diff --git a/libavfilter/vf_detelecine.c b/libavfilter/vf_detelecine.c
new file mode 100644
index 000..ce9ba74
--- /dev/null
+++ b/libavfilter/vf_detelecine.c
@@ -0,0 +1,323 @@
+/*
+ * Copyright (c) 2015 Himangi Saraogi
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file detelecine filter.
+ */
+
+#include "libavutil/avstring.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "video.h"
+
+typedef struct {
+const AVClass *class;
+int first_field;
+char *pattern;
+unsigned int pattern_pos;
+unsigned int nskip_fields;
+
+AVRational pts;
+double ts_unit;
+int occupied;
+
+int nb_planes;
+int planeheight[4];
+int stride[4];
+
+AVFrame *frame;
+AVFrame *temp;
+} DetelecineContext;
+
+#define OFFSET(x) offsetof(DetelecineContext, x)
+#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
+
+static const AVOption detelecine_options[] = {
+{"first_field", "select first field", OFFSET(first_field),
AV_OPT_TYPE_INT, {.i64=0}, 0, 1, FLAGS, "field"},
+{"top","select top field first",0, AV_OPT_TYPE_CONST,
{.i64=0}, 0, 0, FLAGS, "field"},
+{"t", "select top field first",0, AV_OPT_TYPE_CONST,
{.i64=0}, 0, 0, FLAGS, "field"},
+{"bottom", "select bottom field first", 0, AV_OPT_TYPE_CONST,
{.i64=1}, 0, 0, FLAGS, "field"},
+{"b", "select bottom field first", 0, AV_OPT_TYPE_CONST,
{.i64=1}, 0, 0, FLAGS, "field"},
+{"pattern", "pattern that describe for how many fields a frame is to be
displayed", OFFSET(pattern), AV_OPT_TYPE_STRING, {.str="23"}, 0, 0, FLAGS},
+{NULL}
+};
+
+AVFILTER_DEFINE_CLASS(detelecine);
+
+static av_cold int init(AVFilterContext *ctx)
+{
+DetelecineContext *s = ctx->priv;
+const char *p;
+int max = 0;
+
+if (!strlen(s->pattern)) {
+av_log(ctx, AV_LOG_ERROR, "No pattern provided.\n");
+return AVERROR_INVALIDDATA;
+}
+
+for (p = s->pattern; *p; p++) {
+if (!av_isdigit(*p)) {
+
Re: [FFmpeg-devel] [PATCH] [PATCH] lavfi: add inverse telecine filter
Himangi Saraogi gmail.com> writes:
> +{"pattern", "pattern that describe for how many
> fields a frame is to be displayed", OFFSET(pattern),
This works fine in a quick test.
An additional parameter could be "start_frame" to
allow using the filter after a stream was cut.
For example: Assuming the default "32" value for
telecine, your current detelecine filter only works
if the stream is uncut or if exactly a multiple of
five frames was cut (from the beginning). Add an
option that allows to choose the starting point in
the telecine pattern.
Warnings are shown when vf_detelecine.c is compiled,
please remove them.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] x86: Makefile: fix DBG parameter evaluation
This recently caused me some issues, as in, being ignored. -- Christophe From 5c1b07147502135a9f6a04a1edcf060a1575efd3 Mon Sep 17 00:00:00 2001 From: Christophe Gisquet Date: Sun, 8 Mar 2015 17:54:25 +0100 Subject: [PATCH] x86: Makefile: fix DBG parameter evaluation --- common.mak | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common.mak b/common.mak index 20b7fa3..eac8bd9 100644 --- a/common.mak +++ b/common.mak @@ -7,7 +7,7 @@ all: all-yes DEFAULT_YASMD=.dbg -ifeq (1, DBG) +ifeq ($(DBG),1) YASMD=$(DEFAULT_YASMD) else YASMD= -- 1.9.2.msysgit.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 0/4] Port XvID iDCT to yasm syntax
This patch series does not attempt to change the core implementation
of the iDCT.
First patch is relatively straightforward. I've only dropped the
alignment on a series of jumps which I didn't see helping at all.
Second patch is less, as I've also tried to reuse tables. Some of them
seem to be similar to what can be found in, e.g., fdct.c. This MMX code
is not compiled for ARCH_X86_64. I also decided to edit the licence
header.
The last 2 patches are more questionable. They attempt to merge the
{put,add}_clamped and the iDCT for the SSE2 versions. This leads to
little object size increase, as the iDCT was always inlined in them.
To achieve this merge, ease rather than code minimization was targeted.
It's roughly 10 cycles/10% gain, but that's hardly noticeable.
This has been tested under Win32 and Win64, on a 14-frames video,
producing the expected CRC. The patch series passes fate's xvid-idct
and xvid-custom-matrix.
However, linux was not tested, and this is arguably sensitive code, so
further evaluation is welcome.
Christophe Gisquet (4):
x86: xvid: port SSE2 idct to yasm
x86: xvid_idct: port MMX IDCT to yasm
x86: xvid_idct: merged idct_put SSE2 versions
x86: xvid_idct: SSE2 merged add version
libavcodec/x86/Makefile| 3 +-
libavcodec/x86/xvididct.asm| 983 +
libavcodec/x86/xvididct_init.c | 49 +-
libavcodec/x86/xvididct_mmx.c | 549 ---
libavcodec/x86/xvididct_sse2.c | 406 -
5 files changed, 1024 insertions(+), 966 deletions(-)
create mode 100644 libavcodec/x86/xvididct.asm
delete mode 100644 libavcodec/x86/xvididct_mmx.c
delete mode 100644 libavcodec/x86/xvididct_sse2.c
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/4] x86: xvid_idct: port MMX IDCT to yasm
Also reduce the table duplication with SSE2 code, remove duplicated
macro parameters.
---
libavcodec/x86/Makefile| 3 +-
libavcodec/x86/xvididct.asm| 450 -
libavcodec/x86/xvididct_init.c | 40 ++-
libavcodec/x86/xvididct_mmx.c | 549 -
4 files changed, 482 insertions(+), 560 deletions(-)
delete mode 100644 libavcodec/x86/xvididct_mmx.c
diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
index 276df44..e19475a 100644
--- a/libavcodec/x86/Makefile
+++ b/libavcodec/x86/Makefile
@@ -73,8 +73,7 @@ MMX-OBJS-$(CONFIG_FDCTDSP) += x86/fdct.o
MMX-OBJS-$(CONFIG_IDCTDSP) += x86/simple_idct.o
# decoders/encoders
-MMX-OBJS-$(CONFIG_MPEG4_DECODER) += x86/xvididct_mmx.o\
- x86/xvididct.o
+MMX-OBJS-$(CONFIG_MPEG4_DECODER) += x86/xvididct.o
MMX-OBJS-$(CONFIG_SNOW_DECODER)+= x86/snowdsp.o
MMX-OBJS-$(CONFIG_SNOW_ENCODER)+= x86/snowdsp.o
MMX-OBJS-$(CONFIG_VC1_DECODER) += x86/vc1dsp_mmx.o
diff --git a/libavcodec/x86/xvididct.asm b/libavcodec/x86/xvididct.asm
index d16db34..4c52bf1 100644
--- a/libavcodec/x86/xvididct.asm
+++ b/libavcodec/x86/xvididct.asm
@@ -1,5 +1,9 @@
; XVID MPEG-4 VIDEO CODEC
-; - SSE2 inverse discrete cosine transform -
+;
+; Conversion from gcc syntax to x264asm syntax with modifications
+; by Christophe Gisquet
+;
+; === SSE2 inverse discrete cosine transform ===
;
; Copyright(C) 2003 Pascal Massimino
;
@@ -8,8 +12,6 @@
;
; Originally from dct/x86_asm/fdct_sse2_skal.asm in Xvid.
;
-; This file is part of FFmpeg.
-;
; Vertical pass is an implementation of the scheme:
; Loeffler C., Ligtenberg A., and Moschytz C.S.:
; Practical Fast 1D DCT Algorithm with Eleven Multiplications,
@@ -22,6 +24,32 @@
;
; More details at http://skal.planet-d.net/coding/dct.html
;
+; === MMX and XMM forward discrete cosine transform ===
+;
+; Copyright(C) 2001 Peter Ross
+;
+; Originally provided by Intel at AP-922
+; http://developer.intel.com/vtune/cbts/strmsimd/922down.htm
+; (See more app notes at
http://developer.intel.com/vtune/cbts/strmsimd/appnotes.htm)
+; but in a limited edition.
+; New macro implements a column part for precise iDCT
+; The routine precision now satisfies IEEE standard 1180-1990.
+;
+; Copyright(C) 2000-2001 Peter Gubanov
+; Rounding trick Copyright(C) 2000 Michel Lespinasse
+;
+; http://www.elecard.com/peter/idct.html
+; http://www.linuxvideo.org/mpeg2dec/
+;
+; These examples contain code fragments for first stage iDCT 8x8
+; (for rows) and first stage DCT 8x8 (for columns)
+;
+; conversion to gcc syntax by Michael Niedermayer
+;
+; ==
+;
+; This file is part of FFmpeg.
+;
; FFmpeg is free software; you can redistribute it and/or
; modify it under the terms of the GNU Lesser General Public
; License as published by the Free Software Foundation; either
@@ -39,11 +67,13 @@
%include "libavutil/x86/x86util.asm"
SECTION_RODATA
+; Similar to tg_1_16 in MMX code
tan1: times 8 dw 13036
tan2: times 8 dw 27146
tan3: times 8 dw 43790
sqrt2: times 8 dw 23170
+; SSE2 tables
iTab1: dw 0x4000, 0x539f, 0xc000, 0xac61, 0x4000, 0xdd5d, 0x4000, 0xdd5d
dw 0x4000, 0x22a3, 0x4000, 0x22a3, 0xc000, 0x539f, 0x4000, 0xac61
dw 0x3249, 0x11a8, 0x4b42, 0xee58, 0x11a8, 0x4b42, 0x11a8, 0xcdb7
@@ -61,12 +91,154 @@ iTab4: dw 0x4b42, 0x6254, 0xb4be, 0x9dac, 0x4b42, 0xd746,
0x4b42, 0xd746
dw 0x3b21, 0x14c3, 0x587e, 0xeb3d, 0x14c3, 0x587e, 0x14c3, 0xc4df
dw 0x6862, 0x587e, 0x979e, 0xc4df, 0x3b21, 0x979e, 0x587e, 0x979e
+%if ARCH_X86_32
+; -
+;
+; The first stage iDCT 8x8 - inverse DCTs of rows
+;
+; -
+; The 8-point inverse DCT direct algorithm
+; -
+;
+; static const short w[32] = {
+; FIX(cos_4_16), FIX(cos_2_16), FIX(cos_4_16), FIX(cos_6_16),
+; FIX(cos_4_16), FIX(cos_6_16), -FIX(cos_4_16), -FIX(cos_2_16),
+; FIX(cos_4_16), -FIX(cos_6_16), -FIX(cos_4_16), FIX(cos_2_16),
+; FIX(cos_4_16), -FIX(cos_2_16), FIX(cos_4_16), -FIX(cos_6_16),
+; FIX(cos_1_16), FIX(cos_3_16), FIX(cos_5_16), FIX(cos_7_16),
+; FIX(cos_3_16), -FIX(cos_7_16), -FIX(cos_1_16), -FIX(cos_5_16),
+; FIX(cos_5_16), -FIX(cos_1_16), FIX(cos_7_16), FIX(cos_3_16),
+; FIX(cos_7_16), -FIX(cos_5_16), FIX(cos_3_16), -FIX(cos_1_16) };
+;
+; #define DCT_8_INV_ROW(x, y)
+; {
+; int a0, a1, a2, a3, b0, b1, b2, b3;
+;
+; a0 = x[0] * w[0] + x[2] * w[1] + x[4] * w[2] + x[6] * w[3];
+; a1 = x[0] * w[4] + x[2] * w[5] + x[4] * w[6] + x[6] * w[7];
+; a2 = x[0] * w[8] + x[2] * w[9] + x[4] * w[1
[FFmpeg-devel] [PATCH 1/4] x86: xvid: port SSE2 idct to yasm
The main difference consists in renaming properly labels, and letting yasm select the gprs for skipping 1D transforms. --- libavcodec/x86/Makefile| 2 +- libavcodec/x86/xvididct.asm| 379 ++ libavcodec/x86/xvididct_init.c | 18 +- libavcodec/x86/xvididct_sse2.c | 406 - 4 files changed, 395 insertions(+), 410 deletions(-) create mode 100644 libavcodec/x86/xvididct.asm delete mode 100644 libavcodec/x86/xvididct_sse2.c diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile index 6b9164a..276df44 100644 --- a/libavcodec/x86/Makefile +++ b/libavcodec/x86/Makefile @@ -74,7 +74,7 @@ MMX-OBJS-$(CONFIG_IDCTDSP) += x86/simple_idct.o # decoders/encoders MMX-OBJS-$(CONFIG_MPEG4_DECODER) += x86/xvididct_mmx.o\ - x86/xvididct_sse2.o + x86/xvididct.o MMX-OBJS-$(CONFIG_SNOW_DECODER)+= x86/snowdsp.o MMX-OBJS-$(CONFIG_SNOW_ENCODER)+= x86/snowdsp.o MMX-OBJS-$(CONFIG_VC1_DECODER) += x86/vc1dsp_mmx.o diff --git a/libavcodec/x86/xvididct.asm b/libavcodec/x86/xvididct.asm new file mode 100644 index 000..d16db34 --- /dev/null +++ b/libavcodec/x86/xvididct.asm @@ -0,0 +1,379 @@ +; XVID MPEG-4 VIDEO CODEC +; - SSE2 inverse discrete cosine transform - +; +; Copyright(C) 2003 Pascal Massimino +; +; Conversion to gcc syntax with modifications +; by Alexander Strange +; +; Originally from dct/x86_asm/fdct_sse2_skal.asm in Xvid. +; +; This file is part of FFmpeg. +; +; Vertical pass is an implementation of the scheme: +; Loeffler C., Ligtenberg A., and Moschytz C.S.: +; Practical Fast 1D DCT Algorithm with Eleven Multiplications, +; Proc. ICASSP 1989, 988-991. +; +; Horizontal pass is a double 4x4 vector/matrix multiplication, +; (see also Intel's Application Note 922: +; http://developer.intel.com/vtune/cbts/strmsimd/922down.htm +; Copyright (C) 1999 Intel Corporation) +; +; More details at http://skal.planet-d.net/coding/dct.html +; +; FFmpeg is free software; you can redistribute it and/or +; modify it under the terms of the GNU Lesser General Public +; License as published by the Free Software Foundation; either +; version 2.1 of the License, or (at your option) any later version. +; +; FFmpeg is distributed in the hope that it will be useful, +; but WITHOUT ANY WARRANTY; without even the implied warranty of +; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +; Lesser General Public License for more details. +; +; You should have received a copy of the GNU Lesser General Public License +; along with FFmpeg; if not, write to the Free Software Foundation, +; Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + +%include "libavutil/x86/x86util.asm" + +SECTION_RODATA +tan1: times 8 dw 13036 +tan2: times 8 dw 27146 +tan3: times 8 dw 43790 +sqrt2: times 8 dw 23170 + +iTab1: dw 0x4000, 0x539f, 0xc000, 0xac61, 0x4000, 0xdd5d, 0x4000, 0xdd5d +dw 0x4000, 0x22a3, 0x4000, 0x22a3, 0xc000, 0x539f, 0x4000, 0xac61 +dw 0x3249, 0x11a8, 0x4b42, 0xee58, 0x11a8, 0x4b42, 0x11a8, 0xcdb7 +dw 0x58c5, 0x4b42, 0xa73b, 0xcdb7, 0x3249, 0xa73b, 0x4b42, 0xa73b +iTab2: dw 0x58c5, 0x73fc, 0xa73b, 0x8c04, 0x58c5, 0xcff5, 0x58c5, 0xcff5 +dw 0x58c5, 0x300b, 0x58c5, 0x300b, 0xa73b, 0x73fc, 0x58c5, 0x8c04 +dw 0x45bf, 0x187e, 0x6862, 0xe782, 0x187e, 0x6862, 0x187e, 0xba41 +dw 0x7b21, 0x6862, 0x84df, 0xba41, 0x45bf, 0x84df, 0x6862, 0x84df +iTab3: dw 0x539f, 0x6d41, 0xac61, 0x92bf, 0x539f, 0xd2bf, 0x539f, 0xd2bf +dw 0x539f, 0x2d41, 0x539f, 0x2d41, 0xac61, 0x6d41, 0x539f, 0x92bf +dw 0x41b3, 0x1712, 0x6254, 0xe8ee, 0x1712, 0x6254, 0x1712, 0xbe4d +dw 0x73fc, 0x6254, 0x8c04, 0xbe4d, 0x41b3, 0x8c04, 0x6254, 0x8c04 +iTab4: dw 0x4b42, 0x6254, 0xb4be, 0x9dac, 0x4b42, 0xd746, 0x4b42, 0xd746 +dw 0x4b42, 0x28ba, 0x4b42, 0x28ba, 0xb4be, 0x6254, 0x4b42, 0x9dac +dw 0x3b21, 0x14c3, 0x587e, 0xeb3d, 0x14c3, 0x587e, 0x14c3, 0xc4df +dw 0x6862, 0x587e, 0x979e, 0xc4df, 0x3b21, 0x979e, 0x587e, 0x979e + +walkenIdctRounders: times 4 dd 65536 +times 4 dd 3597 +times 4 dd 2260 +times 4 dd 1203 +times 4 dd 120 +times 4 dd 512 + +pb_127: times 8 db 127 + +SECTION .text + +; Temporary storage before the column pass +%define ROW1 xmm6 +%define ROW3 xmm4 +%define ROW5 xmm5 +%define ROW7 xmm7 + +%macro CLEAR_ODD 1 +pxor %1, %1 +%endmacro +%macro PUT_ODD 1 +pshufhw %1, xmm2, 0x1B +%endmacro + +%macro MOV32 2 +%if ARCH_X86_32 +movdqa%2, %1 +%endif +%endmacro + +%macro CLEAR_EVEN 1 +%if ARCH_X86_64 +CLEAR_ODD %1 +%endif +%endmacro + +%macro PUT_EVEN 1 +%if ARCH_X86_64 +PUT_ODD %1 +%else +pshufhw xmm2, xmm2, 0x1B +movdqa%1, xmm2 +%endif +%endmacro + +%if ARCH_X86_64 +%d
[FFmpeg-devel] [PATCH 3/4] x86: xvid_idct: merged idct_put SSE2 versions
--- libavcodec/x86/xvididct.asm| 202 - libavcodec/x86/xvididct_init.c | 8 +- 2 files changed, 140 insertions(+), 70 deletions(-) diff --git a/libavcodec/x86/xvididct.asm b/libavcodec/x86/xvididct.asm index 4c52bf1..58ffb11 100644 --- a/libavcodec/x86/xvididct.asm +++ b/libavcodec/x86/xvididct.asm @@ -292,13 +292,13 @@ SECTION .text %define TAN3 xmm13 %define TAN1 xmm14 %else -%define ROW0 [r0 + 0*16] +%define ROW0 [BLOCK + 0*16] %define REG0 xmm4 -%define ROW2 [r0 + 2*16] +%define ROW2 [BLOCK + 2*16] %define REG2 xmm4 -%define ROW4 [r0 + 4*16] +%define ROW4 [BLOCK + 4*16] %define REG4 xmm6 -%define ROW6 [r0 + 6*16] +%define ROW6 [BLOCK + 6*16] %define REG6 xmm6 %define XMMS xmm2 %define SREG2 xmm7 @@ -369,8 +369,71 @@ SECTION .text movdqa TAN1, [tan1] %endmacro +%macro FIRST_HALF 2 ; %1=dct %2=type(normal,add,put) +psrawxmm5, 6 +psrawREG0, 6 +psrawTAN3, 6 +psrawxmm3, 6 +; dct coeffs must still be written for AC prediction +%if %2 == 0 +movdqa [%1+1*16], TAN3 +movdqa [%1+2*16], xmm3 +movdqa [%1+5*16], REG0 +movdqa [%1+6*16], xmm5 +%else +; Must now load args as gprs are no longer used for masks +; DEST is set to where address of dest was loaded +%if ARCH_X86_32 +%xdefine DEST r2q ; BLOCK is r0, stride r1 +movifnidn DEST, destm +movifnidn strideq, stridem +%else +%xdefine DEST r0q +%endif +lea r3q, [3*strideq] +%if %2 == 1 +packuswb TAN3, xmm3 +packuswb xmm5, REG0 +movq [DEST + strideq], TAN3 +movhps [DEST + 2*strideq], TAN3 +; REG0 and TAN3 are now available (and likely used in second half) +%else +%warning Unimplemented +%endif +%endif +%endmacro + +%macro SECOND_HALF 6 ; %1=dct %2=type(normal,add,put) 3-6: xmms +psraw%3, 6 +psraw%4, 6 +psraw%5, 6 +psraw%6, 6 +; dct coeffs must still be written for AC prediction +%if %2 == 0 +movdqa [%1+0*16], %3 +movdqa [%1+3*16], %5 +movdqa [%1+4*16], %6 +movdqa [%1+7*16], %4 +%elif %2 == 1 +packuswb %3, %5 +packuswb %6, %4 +; address of dest may have been loaded +movq [DEST], %3 +movhps [DEST + r3q], %3 +lea DEST, [DEST + 4*strideq] +movq [DEST], %6 +movhps [DEST + r3q], %6 +; and now write remainder of first half +movq [DEST + 2*strideq], xmm5 +movhps [DEST + strideq], xmm5 +%elif %2 == 2 +%warning Unimplemented +%endif +%endmacro + + ; IDCT pass on columns. -%macro iLLM_PASS 1 ;dct +%macro iLLM_PASS 2 ; %1=dct %2=type(normal,add,put) movdqa xmm1, TAN3 movdqa xmm3, TAN1 pmulhw TAN3, xmm4 @@ -407,7 +470,7 @@ SECTION .text psubsw xmm5, REG6 MOV32ROW0, REG0 MOV32ROW4, REG4 -MOV32TAN1, [r0] +MOV32TAN1, [BLOCK] movdqa XMMS, REG0 psubsw REG0, REG4 paddsw REG4, XMMS @@ -423,33 +486,22 @@ SECTION .text movdqa XMMS, REG0 psubsw REG0, xmm3 paddsw xmm3, XMMS -MOV32[r0], TAN1 -psrawxmm5, 6 -psrawREG0, 6 -psrawTAN3, 6 -psrawxmm3, 6 -movdqa [%1+1*16], TAN3 -movdqa [%1+2*16], xmm3 -movdqa [%1+5*16], REG0 -movdqa [%1+6*16], xmm5 +MOV32[BLOCK], TAN1 + +FIRST_HALF %1, %2 + movdqa xmm0, xmm7 movdqa xmm4, REG4 psubsw xmm7, xmm1 psubsw REG4, TAN1 paddsw xmm1, xmm0 paddsw TAN1, xmm4 -psrawxmm1, 6 -psrawxmm7, 6 -psrawTAN1, 6 -psrawREG4, 6 -movdqa [%1+0*16], xmm1 -movdqa [%1+3*16], TAN1 -movdqa [%1+4*16], REG4 -movdqa [%1+7*16], xmm7 + +SECOND_HALF %1, %2, xmm1, xmm7, TAN1, REG4 %endmacro ; IDCT pass on columns, assuming rows 4-7 are zero -%macro iLLM_PASS_SPARSE 1 ;dct +%macro iLLM_PASS_SPARSE 2 ; %1=dct %2=type(normal,put,add) pmulhw TAN3, xmm4 paddsw TAN3, xmm4 movdqa xmm3, xmm6 @@ -475,7 +527,7 @@ SECTION .text movdqa xmm6, REG0 psubsw xmm6, SREG2 paddsw SREG2, REG0 -MOV32TAN1, [r0] +MOV32TAN1, [BLOCK] movdqa XMMS, REG0 psubsw REG0, xmm5 paddsw xmm5, XMMS @@ -485,70 +537,92 @@ SECTION .text movdqa XMMS, REG0 psubsw REG0, xmm3 paddsw xmm3, XMMS -MOV32[r0], TAN1 -psrawxmm5, 6 -psrawREG0, 6 -psrawTAN3, 6 -psrawxmm3, 6 -movdqa [%1+1*16], TAN3 -movdqa [%1+2*16], xmm3 -movdqa [%1+5*16], REG0 -movdqa [%1+6*16], xmm5 +MOV32[BLOCK], TAN1 + +FIRST_HALF %1, %2 + movdqa xmm0, SREG2 movdqa xmm4, xmm6 psubsw SREG2, xmm1 psubsw xmm6, TAN1 paddsw xmm1, xmm0 paddsw TAN1, xmm4 -psrawxmm1, 6 -psraw SREG2, 6 -psrawTAN1, 6 -psrawxmm6, 6 -movdqa [%1+0*16], xmm1 -movdqa [%1+3*
[FFmpeg-devel] [PATCH 4/4] x86: xvid_idct: SSE2 merged add version
---
libavcodec/x86/xvididct.asm| 92 --
libavcodec/x86/xvididct_init.c | 9 +
2 files changed, 91 insertions(+), 10 deletions(-)
diff --git a/libavcodec/x86/xvididct.asm b/libavcodec/x86/xvididct.asm
index 58ffb11..0220885 100644
--- a/libavcodec/x86/xvididct.asm
+++ b/libavcodec/x86/xvididct.asm
@@ -384,6 +384,12 @@ SECTION .text
; Must now load args as gprs are no longer used for masks
; DEST is set to where address of dest was loaded
%if ARCH_X86_32
+%if %2 == 2 ; Not enough xmms, store
+movdqa [%1+1*16], TAN3
+movdqa [%1+2*16], xmm3
+movdqa [%1+5*16], REG0
+movdqa [%1+6*16], xmm5
+%endif
%xdefine DEST r2q ; BLOCK is r0, stride r1
movifnidn DEST, destm
movifnidn strideq, stridem
@@ -397,8 +403,6 @@ SECTION .text
movq [DEST + strideq], TAN3
movhps [DEST + 2*strideq], TAN3
; REG0 and TAN3 are now available (and likely used in second half)
-%else
-%warning Unimplemented
%endif
%endif
%endmacro
@@ -427,7 +431,88 @@ SECTION .text
movq [DEST + 2*strideq], xmm5
movhps [DEST + strideq], xmm5
%elif %2 == 2
-%warning Unimplemented
+pxorxmm0, xmm0
+%if ARCH_X86_32
+; free: m3 REG0=m4 m5
+; input: m1, m7, m2, m6
+movqxmm3, [DEST+0*strideq]
+movqxmm4, [DEST+1*strideq]
+punpcklbw xmm3, xmm0
+punpcklbw xmm4, xmm0
+paddsw xmm3, %3
+paddsw xmm4, [%1 + 1*16]
+movq %3, [DEST+2*strideq]
+movqxmm5, [DEST+ r3q]
+punpcklbw %3, xmm0
+punpcklbw xmm5, xmm0
+paddsw%3, [%1 + 2*16]
+paddsw xmm5, %5
+packuswbxmm3, xmm4
+packuswb %3, xmm5
+movq[DEST+0*strideq], xmm3
+movhps [DEST+1*strideq], xmm3
+movq[DEST+2*strideq], %3
+movhps [DEST+ r3q], %3
+lea DEST, [DEST+4*strideq]
+movqxmm3, [DEST+0*strideq]
+movqxmm4, [DEST+1*strideq]
+movq %3, [DEST+2*strideq]
+movqxmm5, [DEST+ r3q]
+punpcklbw xmm3, xmm0
+punpcklbw xmm4, xmm0
+punpcklbw %3, xmm0
+punpcklbw xmm5, xmm0
+paddsw xmm3, %6
+paddsw xmm4, [%1 + 5*16]
+paddsw%3, [%1 + 6*16]
+paddsw xmm5, %4
+packuswbxmm3, xmm4
+packuswb %3, xmm5
+movq[DEST+0*strideq], xmm3
+movhps [DEST+1*strideq], xmm3
+movq[DEST+2*strideq], %3
+movhps [DEST+ r3q], %3
+%else
+; l1:TAN3=m13 l2:m3 l5:REG0=m8 l6=m5
+; input: m1, m7/SREG2=m9, TAN1=m14, REG4=m10
+movqxmm2, [DEST+0*strideq]
+movqxmm4, [DEST+1*strideq]
+movq xmm12, [DEST+2*strideq]
+movq xmm11, [DEST+ r3q]
+punpcklbw xmm2, xmm0
+punpcklbw xmm4, xmm0
+punpcklbw xmm12, xmm0
+punpcklbw xmm11, xmm0
+paddsw xmm2, %3
+paddsw xmm4, TAN3
+paddsw xmm12, xmm3
+paddsw xmm11, %5
+packuswbxmm2, xmm4
+packuswb xmm12, xmm11
+movq[DEST+0*strideq], xmm2
+movhps [DEST+1*strideq], xmm2
+movq[DEST+2*strideq], xmm12
+movhps [DEST+ r3q], xmm12
+lea DEST, [DEST+4*strideq]
+movqxmm2, [DEST+0*strideq]
+movqxmm4, [DEST+1*strideq]
+movq xmm12, [DEST+2*strideq]
+movq xmm11, [DEST+ r3q]
+punpcklbw xmm2, xmm0
+punpcklbw xmm4, xmm0
+punpcklbw xmm12, xmm0
+punpcklbw xmm11, xmm0
+paddsw xmm2, %6
+paddsw xmm4, REG0
+paddsw xmm12, xmm5
+paddsw xmm11, %4
+packuswbxmm2, xmm4
+packuswb xmm12, xmm11
+movq[DEST+0*strideq], xmm2
+movhps [DEST+1*strideq], xmm2
+movq[DEST+2*strideq], xmm12
+movhps [DEST+ r3q], xmm12
+%endif
%endif
%endmacro
@@ -623,6 +708,7 @@ cglobal xvid_idct_add, 0, NUM_GPRS, 8+7*ARCH_X86_64, dest,
stride, block
INIT_XMM sse2
IDCT_SSE2 0
IDCT_SSE2 1
+IDCT_SSE2 2
%if ARCH_X86_32
diff --git a/libavcodec/x86/xvididct_init.c b/libavcodec/x86/xvididct_init.c
index 2530d7a..57f6ed6 100644
--- a/libavcodec/x86/xvididct_init.c
+++ b/libavcodec/x86/xvididct_init.c
@@ -27,12 +27,7 @@
#include "xvididct.h"
void ff_xvid_idct_put_sse2(uint8_t *dest, int line_size, short *block);
-
-static void xvid_idct_sse2_add(uint8_t *dest, int line_size, short *block)
-{
-ff_xvid_idct_sse2(block);
-ff_add_pixels_clamped(block, dest, line_size);
-}
+void ff_xvid_idct_add_sse2(uint8_t *dest, int line_size, short *block);
#if ARCH_X86_32
static void xvid_idct_mmx_put(uint8_t *dest, int line_size, short *block)
@@ -88,7 +83,7 @@ av_cold void ff_xvid_idct_init_x86(IDCTDSPContext *c,
AVCodecContext *avctx,
if (EXTERNAL_SSE2(cpu_flags)) {
c->idct_put = ff_xvid_idct_put_sse2;
-c->idct_add = xvid_idct_sse2_add;
+c->idct_add = ff_xvid_idct_add_sse2;
c->idct = ff_xvid_idct_s
[FFmpeg-devel] [PATCH] sftp: support reading config from ~/.ssh/config
libssh provides a function for parsing ~/.ssh/config for ssh connection
parameters like user, hostname, identity file
and port. This patch makes ffmpeg use this function to take parameters from the
config file for everything that's not
explicitely set in the url. It also supports host aliases, i.e. using a
shorthand in the url and replacing it with the
hostname / IP address specified for the shorthand in the config file.
Signed-off-by: Florian Jacob
---
libavformat/libssh.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/libavformat/libssh.c b/libavformat/libssh.c
index 3ec60cb..1ed1d72 100644
--- a/libavformat/libssh.c
+++ b/libavformat/libssh.c
@@ -55,6 +55,10 @@ static av_cold int libssh_create_ssh_session(LIBSSHContext
*libssh, const char*
ssh_options_set(libssh->session, SSH_OPTIONS_TIMEOUT_USEC, &timeout);
}
+if (ssh_options_parse_config(libssh->session, NULL) < 0) {
+av_log(libssh, AV_LOG_ERROR, "Could not parse the config file.\n");
+}
+
if (ssh_connect(libssh->session) != SSH_OK) {
av_log(libssh, AV_LOG_ERROR, "Connection failed: %s\n",
ssh_get_error(libssh->session));
return AVERROR(EIO);
@@ -187,7 +191,7 @@ static av_cold int libssh_open(URLContext *h, const char
*url, int flags)
{
LIBSSHContext *libssh = h->priv_data;
char proto[10], path[MAX_URL_SIZE], hostname[1024], credencials[1024];
-int port = 22, ret;
+int port, ret;
const char *user = NULL, *pass = NULL;
char *end = NULL;
@@ -198,8 +202,9 @@ static av_cold int libssh_open(URLContext *h, const char
*url, int flags)
path, sizeof(path),
url);
-if (port <= 0 || port > 65535)
-port = 22;
+// a port of 0 will use a port from ~/.ssh/config or the default value 22
+if (port < 0 || port > 65535)
+port = 0;
if ((ret = libssh_create_ssh_session(libssh, hostname, port)) < 0)
goto fail;
--
2.3.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] sftp: support reading config from ~/.ssh/config
On 11.03.2015 00:22, Florian Jacob wrote:
libssh provides a function for parsing ~/.ssh/config for ssh connection
parameters like user, hostname, identity file
and port. This patch makes ffmpeg use this function to take parameters from the
config file for everything that's not
explicitely set in the url. It also supports host aliases, i.e. using a
shorthand in the url and replacing it with the
hostname / IP address specified for the shorthand in the config file.
Signed-off-by: Florian Jacob
---
libavformat/libssh.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/libavformat/libssh.c b/libavformat/libssh.c
index 3ec60cb..1ed1d72 100644
--- a/libavformat/libssh.c
+++ b/libavformat/libssh.c
@@ -55,6 +55,10 @@ static av_cold int libssh_create_ssh_session(LIBSSHContext
*libssh, const char*
ssh_options_set(libssh->session, SSH_OPTIONS_TIMEOUT_USEC, &timeout);
}
+if (ssh_options_parse_config(libssh->session, NULL) < 0) {
+av_log(libssh, AV_LOG_ERROR, "Could not parse the config file.\n");
This should be a warning (not an error), or return with error code from
here. A warning is probably better.
+}
+
if (ssh_connect(libssh->session) != SSH_OK) {
av_log(libssh, AV_LOG_ERROR, "Connection failed: %s\n",
ssh_get_error(libssh->session));
return AVERROR(EIO);
@@ -187,7 +191,7 @@ static av_cold int libssh_open(URLContext *h, const char
*url, int flags)
{
LIBSSHContext *libssh = h->priv_data;
char proto[10], path[MAX_URL_SIZE], hostname[1024], credencials[1024];
-int port = 22, ret;
+int port, ret;
const char *user = NULL, *pass = NULL;
char *end = NULL;
@@ -198,8 +202,9 @@ static av_cold int libssh_open(URLContext *h, const char
*url, int flags)
path, sizeof(path),
url);
-if (port <= 0 || port > 65535)
-port = 22;
+// a port of 0 will use a port from ~/.ssh/config or the default value 22
+if (port < 0 || port > 65535)
+port = 0;
Is this really required? Port will be overwritten if present in config
either way?
if ((ret = libssh_create_ssh_session(libssh, hostname, port)) < 0)
goto fail;
I will test later, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] sftp: support reading config from ~/.ssh/config
> > libavformat/libssh.c | 11 ---
> > 1 file changed, 8 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavformat/libssh.c b/libavformat/libssh.c
> > index 3ec60cb..1ed1d72 100644
> > --- a/libavformat/libssh.c
> > +++ b/libavformat/libssh.c
> > @@ -55,6 +55,10 @@ static av_cold int
> > libssh_create_ssh_session(LIBSSHContext *libssh, const char*>
> > ssh_options_set(libssh->session, SSH_OPTIONS_TIMEOUT_USEC,
> > &timeout);
> >
> > }
> >
> > +if (ssh_options_parse_config(libssh->session, NULL) < 0) {
> > +av_log(libssh, AV_LOG_ERROR, "Could not parse the config
> > file.\n");
> This should be a warning (not an error), or return with error code from
> here. A warning is probably better.
Of course, excuse me. I'll correct it.
> > @@ -198,8 +202,9 @@ static av_cold int libssh_open(URLContext *h, const
> > char *url, int flags)>
> >path, sizeof(path),
> >url);
> >
> > -if (port <= 0 || port > 65535)
> > -port = 22;
> > +// a port of 0 will use a port from ~/.ssh/config or the default
> > value 22 +if (port < 0 || port > 65535)
> > +port = 0;
> Is this really required? Port will be overwritten if present in config
> either way?
It is required. In my first version without that change, I wondered why
everything worked besides the port which was still set to 22. The reason is
that if the port is set != 0, libssh treats it as port that is explicitely set
by the user, and therefore doesn't overwrite it with the port specified in the
config file.
> I will test later, thanks.
Thanks in advance. :)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] sftp: support reading config from ~/.ssh/config
libssh provides a function for parsing ~/.ssh/config for ssh connection
parameters like user, hostname, identity file
and port. This patch makes ffmpeg use this function to take parameters from the
config file for everything that's not
explicitely set in the url. It also supports host aliases, i.e. using a
shorthand in the url and replacing it with the
hostname / IP address specified for the shorthand in the config file.
Signed-off-by: Florian Jacob
---
libavformat/libssh.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/libavformat/libssh.c b/libavformat/libssh.c
index 3ec60cb..fac6114 100644
--- a/libavformat/libssh.c
+++ b/libavformat/libssh.c
@@ -55,6 +55,10 @@ static av_cold int libssh_create_ssh_session(LIBSSHContext
*libssh, const char*
ssh_options_set(libssh->session, SSH_OPTIONS_TIMEOUT_USEC, &timeout);
}
+if (ssh_options_parse_config(libssh->session, NULL) < 0) {
+av_log(libssh, AV_LOG_WARNING, "Could not parse the config file.\n");
+}
+
if (ssh_connect(libssh->session) != SSH_OK) {
av_log(libssh, AV_LOG_ERROR, "Connection failed: %s\n",
ssh_get_error(libssh->session));
return AVERROR(EIO);
@@ -187,7 +191,7 @@ static av_cold int libssh_open(URLContext *h, const char
*url, int flags)
{
LIBSSHContext *libssh = h->priv_data;
char proto[10], path[MAX_URL_SIZE], hostname[1024], credencials[1024];
-int port = 22, ret;
+int port, ret;
const char *user = NULL, *pass = NULL;
char *end = NULL;
@@ -198,8 +202,9 @@ static av_cold int libssh_open(URLContext *h, const char
*url, int flags)
path, sizeof(path),
url);
-if (port <= 0 || port > 65535)
-port = 22;
+// a port of 0 will use a port from ~/.ssh/config or the default value 22
+if (port < 0 || port > 65535)
+port = 0;
if ((ret = libssh_create_ssh_session(libssh, hostname, port)) < 0)
goto fail;
--
2.3.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] [PATCH] lavfi: add inverse telecine filter
On 11 March 2015 at 04:00, Carl Eugen Hoyos wrote:
> Himangi Saraogi gmail.com> writes:
>
> > +{"pattern", "pattern that describe for how many
> > fields a frame is to be displayed", OFFSET(pattern),
>
> This works fine in a quick test.
> An additional parameter could be "start_frame" to
> allow using the filter after a stream was cut.
> For example: Assuming the default "32" value for
> telecine, your current detelecine filter only works
> if the stream is uncut or if exactly a multiple of
> five frames was cut (from the beginning). Add an
> option that allows to choose the starting point in
> the telecine pattern.
>
Sure, I missed this.
>
> Warnings are shown when vf_detelecine.c is compiled,
> please remove them.
>
>
Fixed locally.
Another important clarification is for the case when the pattern has a 1 or
a 0. In the 0 case, I am currently just missing the frames in the output
as there is no way to recover them. However, for the 1 case, one of the
fields of a frame is missing. in the output, I can fill the second field
with the nearest frame, but is there a better solution?
Thank you, Carl Eugen
>
> ___
> 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] sftp: support reading config from ~/.ssh/config
On 11.03.2015 01:13, Florian Jacob wrote: libssh provides a function for parsing ~/.ssh/config for ssh connection parameters like user, hostname, identity file and port. This patch makes ffmpeg use this function to take parameters from the config file for everything that's not explicitely set in the url. It also supports host aliases, i.e. using a shorthand in the url and replacing it with the hostname / IP address specified for the shorthand in the config file. Works nice, pushed, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] [PATCH] lavfi: add inverse telecine filter
On Tue, Mar 10, 2015 at 2:52 PM Himangi Saraogi wrote: > This is an exact inverse of the telecine filter unlike previously existing > pullup and fieldmatch ones. > What's the difference between the three seemingly similar filters? Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] sftp: support reading config from ~/.ssh/config
On Tue, Mar 10, 2015 at 5:47 PM Lukasz Marek wrote: > On 11.03.2015 01:13, Florian Jacob wrote: > > libssh provides a function for parsing ~/.ssh/config for ssh connection > parameters like user, hostname, identity file > > and port. This patch makes ffmpeg use this function to take parameters > from the config file for everything that's not > > explicitely set in the url. It also supports host aliases, i.e. using a > shorthand in the url and replacing it with the > > hostname / IP address specified for the shorthand in the config file. > > Works nice, pushed, thanks. > Does this patch change the default behavior in any way? Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] sftp: support reading config from ~/.ssh/config
On 11.03.2015 01:51, Timothy Gu wrote: On Tue, Mar 10, 2015 at 5:47 PM Lukasz Marek wrote: On 11.03.2015 01:13, Florian Jacob wrote: libssh provides a function for parsing ~/.ssh/config for ssh connection parameters like user, hostname, identity file and port. This patch makes ffmpeg use this function to take parameters from the config file for everything that's not explicitely set in the url. It also supports host aliases, i.e. using a shorthand in the url and replacing it with the hostname / IP address specified for the shorthand in the config file. Works nice, pushed, thanks. Does this patch change the default behavior in any way? I thought about it, but I don't think so. If changelog consider quite minor changes then it can be mentioned tho. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86: Makefile: fix DBG parameter evaluation
On Tue, Mar 10, 2015 at 11:54:55PM +0100, Christophe Gisquet wrote: > This recently caused me some issues, as in, being ignored. > > -- > Christophe > common.mak |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > 40122fe4b5590c27d7280b402ae8992bd6a63d53 > 0001-x86-Makefile-fix-DBG-parameter-evaluation.patch > From 5c1b07147502135a9f6a04a1edcf060a1575efd3 Mon Sep 17 00:00:00 2001 > From: Christophe Gisquet > Date: Sun, 8 Mar 2015 17:54:25 +0100 > Subject: [PATCH] x86: Makefile: fix DBG parameter evaluation applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] x86: xvid_idct: port MMX IDCT to yasm
On Tue, Mar 10, 2015 at 11:11:52PM +, Christophe Gisquet wrote: > Also reduce the table duplication with SSE2 code, remove duplicated > macro parameters. > --- > libavcodec/x86/Makefile| 3 +- > libavcodec/x86/xvididct.asm| 450 - > libavcodec/x86/xvididct_init.c | 40 ++- > libavcodec/x86/xvididct_mmx.c | 549 > - > 4 files changed, 482 insertions(+), 560 deletions(-) > delete mode 100644 libavcodec/x86/xvididct_mmx.c this breaks make libavcodec/dct-test ... LD libavcodec/dct-test libavcodec/dct-test.o:(.rodata+0xe8): undefined reference to `ff_xvid_idct_mmx' libavcodec/dct-test.o:(.rodata+0x108): undefined reference to `ff_xvid_idct_mmxext' [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] x86: xvid: port SSE2 idct to yasm
On 10/03/15 8:11 PM, Christophe Gisquet wrote: > The main difference consists in renaming properly labels, and > letting yasm select the gprs for skipping 1D transforms. > --- > libavcodec/x86/Makefile| 2 +- > libavcodec/x86/xvididct.asm| 379 ++ > libavcodec/x86/xvididct_init.c | 18 +- > libavcodec/x86/xvididct_sse2.c | 406 > - > 4 files changed, 395 insertions(+), 410 deletions(-) > create mode 100644 libavcodec/x86/xvididct.asm > delete mode 100644 libavcodec/x86/xvididct_sse2.c > > diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile > index 6b9164a..276df44 100644 > --- a/libavcodec/x86/Makefile > +++ b/libavcodec/x86/Makefile > @@ -74,7 +74,7 @@ MMX-OBJS-$(CONFIG_IDCTDSP) += x86/simple_idct.o > > # decoders/encoders > MMX-OBJS-$(CONFIG_MPEG4_DECODER) += x86/xvididct_mmx.o\ > - x86/xvididct_sse2.o > + x86/xvididct.o Should be YASM-OBJS, and moved to the end of the file. Also, related to the build failure Michael mentioned for the second patch, this is missing an inline -> external change in libavcodec/x86/dct-test.c As you said the patch is pretty much straightforward, so if fate passes and the output is the same then it should be ok. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Does FFmpeg support SDL 2.0?
Hi all, I found the newest FFmpeg is only support SDL 1.2 from its configure file. But i need use SDL 2.0, Does it has plan to support SDL 2.0? Thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Print number of reference frames if debug level >= verbose
On Tue, Mar 10, 2015 at 03:27:20PM +0100, Carl Eugen Hoyos wrote: > Hi! > > Attached patch prints the number of reference frames > on increased loglevel. > > Please comment, Carl Eugen > utils.c |2 ++ > 1 file changed, 2 insertions(+) > 3027911b398c8e5f89bc5b868f980f4a2ff50b01 patchrefs.diff > diff --git a/libavcodec/utils.c b/libavcodec/utils.c > index 5b28496..aa00581 100644 > --- a/libavcodec/utils.c > +++ b/libavcodec/utils.c > @@ -3024,6 +3024,8 @@ void avcodec_string(char *buf, int buf_size, > AVCodecContext *enc, int encode) > > if (profile) > snprintf(buf + strlen(buf), buf_size - strlen(buf), " (%s)", > profile); > +if (av_log_get_level() >= AV_LOG_VERBOSE && enc->refs) > +snprintf(buf + strlen(buf), buf_size - strlen(buf), ", %d reference > frame(s)", enc->refs); this should only be printed for video and the "s" should only be printed for refs > 1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Reorganized libpostproc code
From: Tucker DiNapoli
The only changes were formating and moving code.
---
libpostproc/postprocess.c | 436 ++--
libpostproc/postprocess_c.c| 1328
libpostproc/postprocess_internal.h | 30 +-
libpostproc/postprocess_template.c | 124 ++--
4 files changed, 1468 insertions(+), 450 deletions(-)
create mode 100644 libpostproc/postprocess_c.c
diff --git a/libpostproc/postprocess.c b/libpostproc/postprocess.c
index 9d89782..8649bb5 100644
--- a/libpostproc/postprocess.c
+++ b/libpostproc/postprocess.c
@@ -76,6 +76,7 @@ try to unroll inner for(x=0 ... loop to avoid these damn if(x
... checks
#include "config.h"
#include "libavutil/avutil.h"
#include "libavutil/avassert.h"
+#include "libavutil/cpu.h"
#include
#include
#include
@@ -115,7 +116,7 @@ const char *postproc_license(void)
#define GET_MODE_BUFFER_SIZE 500
#define OPTIONS_ARRAY_SIZE 10
-#define BLOCK_SIZE 8
+
#define TEMP_STRIDE 8
//#define NUM_BLOCKS_AT_ONCE 16 //not used yet
@@ -130,9 +131,6 @@ DECLARE_ASM_CONST(8, uint64_t, b08)= 0x0808080808080808LL;
DECLARE_ASM_CONST(8, uint64_t, b80)= 0x8080808080808080LL;
#endif
-DECLARE_ASM_CONST(8, int, deringThreshold)= 20;
-
-
static const struct PPFilter filters[]=
{
{"hb", "hdeblock", 1, 1, 3, H_DEBLOCK},
@@ -198,364 +196,10 @@ static inline void prefetcht2(const void *p)
);
}
#endif
-
-/* The horizontal functions exist only in C because the MMX
- * code is faster with vertical filters and transposing. */
-
-/**
- * Check if the given 8x8 Block is mostly "flat"
- */
-static inline int isHorizDC_C(const uint8_t src[], int stride, const PPContext
*c)
-{
-int numEq= 0;
-int y;
-const int dcOffset= ((c->nonBQP*c->ppMode.baseDcDiff)>>8) + 1;
-const int dcThreshold= dcOffset*2 + 1;
-
-for(y=0; y c->ppMode.flatnessThreshold;
-}
-
-/**
- * Check if the middle 8x8 Block in the given 8x16 block is flat
- */
-static inline int isVertDC_C(const uint8_t src[], int stride, const PPContext
*c)
-{
-int numEq= 0;
-int y;
-const int dcOffset= ((c->nonBQP*c->ppMode.baseDcDiff)>>8) + 1;
-const int dcThreshold= dcOffset*2 + 1;
-
-src+= stride*4; // src points to begin of the 8x8 Block
-for(y=0; y c->ppMode.flatnessThreshold;
-}
-
-static inline int isHorizMinMaxOk_C(const uint8_t src[], int stride, int QP)
-{
-int i;
-for(i=0; i<2; i++){
-if((unsigned)(src[0] - src[5] + 2*QP) > 4*QP) return 0;
-src += stride;
-if((unsigned)(src[2] - src[7] + 2*QP) > 4*QP) return 0;
-src += stride;
-if((unsigned)(src[4] - src[1] + 2*QP) > 4*QP) return 0;
-src += stride;
-if((unsigned)(src[6] - src[3] + 2*QP) > 4*QP) return 0;
-src += stride;
-}
-return 1;
-}
-
-static inline int isVertMinMaxOk_C(const uint8_t src[], int stride, int QP)
-{
-int x;
-src+= stride*4;
-for(x=0; x
4*QP) return 0;
-if((unsigned)(src[1+x + 2*stride] - src[1+x + 7*stride] + 2*QP) >
4*QP) return 0;
-if((unsigned)(src[2+x + 4*stride] - src[2+x + 1*stride] + 2*QP) >
4*QP) return 0;
-if((unsigned)(src[3+x + 6*stride] - src[3+x + 3*stride] + 2*QP) >
4*QP) return 0;
-}
-return 1;
-}
-
-static inline int horizClassify_C(const uint8_t src[], int stride, const
PPContext *c)
-{
-if( isHorizDC_C(src, stride, c) ){
-return isHorizMinMaxOk_C(src, stride, c->QP);
-}else{
-return 2;
-}
-}
-
-static inline int vertClassify_C(const uint8_t src[], int stride, const
PPContext *c)
-{
-if( isVertDC_C(src, stride, c) ){
-return isVertMinMaxOk_C(src, stride, c->QP);
-}else{
-return 2;
-}
-}
-
-static inline void doHorizDefFilter_C(uint8_t dst[], int stride, const
PPContext *c)
-{
-int y;
-for(y=0; yQP){
-const int q=(dst[3] - dst[4])/2;
-const int leftEnergy= 5*(dst[2] - dst[1]) + 2*(dst[0] - dst[3]);
-const int rightEnergy= 5*(dst[6] - dst[5]) + 2*(dst[4] - dst[7]);
-
-int d= FFABS(middleEnergy) - FFMIN( FFABS(leftEnergy),
FFABS(rightEnergy) );
-d= FFMAX(d, 0);
-
-d= (5*d + 32) >> 6;
-d*= FFSIGN(-middleEnergy);
-
-if(q>0)
-{
-d = FFMAX(d, 0);
-d = FFMIN(d, q);
-}
-else
-{
-d = FFMIN(d, 0);
-d = FFMAX(d, q);
-}
-
-dst[3]-= d;
-dst[4]+= d;
-}
-dst+= stride;
-}
-}
-
-/**
- * Do a horizontal low pass filter on the 10x8 block (dst points to middle 8x8
Block)
- * using the 9-Tap Filter (1,1,2,2,4,2,2,1,1)/16 (C version)
- */
-static inline void doHorizLowPass_C(uint8_t dst[], int stride, const PPContext
*c)
-{
-int y;
-for(y=0; yQP ? dst[-1] : dst[0];
-const int last= FFABS(dst[8] - dst[7]) < c->QP ? dst[8] : dst[7];
-
-int sums[10];
-sums[0] = 4*first +
Re: [FFmpeg-devel] [PATCH] lavfi: Add support to process_command in vf_eq.c
On Tue, Mar 10, 2015 at 2:41 PM, Stefano Sabatini
wrote:
> On date Tuesday 2015-03-10 00:27:52 +0530, Arwa Arif encoded:
> > On Fri, Feb 20, 2015 at 5:41 AM, Stefano Sabatini
> > wrote:
> >
> > > On date Thursday 2015-02-19 17:13:15 +0530, Arwa Arif encoded:
> > > > Updated the patch.
> > >
> > > > From 66a8c9d03995c9e7c6ccc05fb9b20756f51c17f4 Mon Sep 17 00:00:00
> 2001
> > > > From: Arwa Arif
> > > > Date: Thu, 19 Feb 2015 01:26:44 +0530
> > > > Subject: [PATCH] Add process_command to eq.
> > > >
> > > > ---
> > > > doc/filters.texi| 35 +++
> > > > libavfilter/vf_eq.c | 171
> > > +--
> > > > libavfilter/vf_eq.h | 56 +++--
> > > > 3 files changed, 210 insertions(+), 52 deletions(-)
> > > >
> > > > diff --git a/doc/filters.texi b/doc/filters.texi
> > > > index 191b52f..e5bf3a2 100644
> > > > --- a/doc/filters.texi
> > > > +++ b/doc/filters.texi
> > > > @@ -4402,6 +4402,41 @@ Default is @code{1.0}.
> > > >
> > > > @end table
> > > >
> > > > +@subsection Commands
> > > > +The filter supports the following commands:
> > > > +
> > > > +@table @option
> > > > +@item contrast
> > > > +Set the contrast expression.
> > > > +
> > > > +@item brightness
> > > > +Set the brightness expression.
> > > > +
> > > > +@item saturation
> > > > +Set the saturation expression.
> > > > +
> > > > +@item gamma
> > > > +Set the gamma expression.
> > > > +
> > > > +@item gamma_r
> > > > +Set the gamma_r expression.
> > > > +
> > > > +@item gamma_g
> > > > +Set gamma_g expression.
> > > > +
> > > > +@item gamma_b
> > > > +Set gamma_b expression.
> > > > +
> > > > +@item gamma_weight
> > > > +Set gamma_weight expression.
> > > > +
> > > > +The command accepts the same syntax of the corresponding option.
> > >
> > > What parameters do the expressions accept? Can you suggest some useful
> > > use-case? (And add useful examples in the docs?)
> > >
> > >
>
> > There are no parameters accepted by the expressions. I will add some
> > examples in the doc.
>
> Look how it is done in hue. In general an expression is useful if you
> want to express something in function of the time or the number of
> frame or something else.
>
So, I should add these options:
1. frame count
2. frame rate
3. timestamp expressed in seconds
4. timebase
>
> [...]
> > > > +if (!strcmp(cmd, "contrast")) {
> > > > +ret = set_expr(&eq->contrast_pexpr, args, cmd, ctx);
> > > > +set_contrast(eq);
> > > > +return ret;
> > > > +}
> > > > +else if (!strcmp(cmd, "brightness")) {
> > > > +ret = set_expr(&eq->brightness_pexpr, args, cmd, ctx);
> > > > +set_brightness(eq);
> > > > +return ret;
> > > > +}
> > > > +else if (!strcmp(cmd, "saturation")) {
> > > > +ret = set_expr(&eq->saturation_pexpr, args, cmd, ctx);
> > > > +set_saturation(eq);
> > > > +return ret;
> > > > +}
> > > > +else if (!strcmp(cmd, "gamma")) {
> > > > +ret = set_expr(&eq->gamma_pexpr, args, cmd, ctx);
> > > > +set_gamma(eq);
> > > > +return ret;
> > > > +}
> > > > +else if (!strcmp(cmd, "gamma_r")) {
> > > > +ret = set_expr(&eq->gamma_r_pexpr, args, cmd, ctx);
> > > > +set_gamma(eq);
> > > > +return ret;
> > > > +}
> > > > +else if (!strcmp(cmd, "gamma_g")) {
> > > > +ret = set_expr(&eq->gamma_g_pexpr, args, cmd, ctx);
> > > > +set_gamma(eq);
> > > > +return ret;
> > > > +}
> > > > +else if (!strcmp(cmd, "gamma_b")) {
> > > > +ret = set_expr(&eq->gamma_b_pexpr, args, cmd, ctx);
> > > > +set_gamma(eq);
> > > > +return ret;
> > > > +}
> > > > +else if (!strcmp(cmd, "gamma_weight")) {
> > > > +ret = set_expr(&eq->gamma_weight_pexpr, args, cmd, ctx);
> > > > +set_gamma(eq);
> > > > +return ret;
> > >
> > > this can be probably factorized using a macro
> > >
> > >
>
> > Okay. I was going through other filters which use macros, can you explain
> > me the what is meant by the symbol ## in statement no.2 of the following
> > code snippet:
>
> ## is the concatenation operator. See for example:
> https://gcc.gnu.org/onlinedocs/cpp/Concatenation.html
Okay. Thanks.
>
>
> > #define SET_SIZE_EXPR(name, opt_name) do {
> > \
> > ret = av_expr_parse_and_eval(&res, expr = rot->name##_expr_str,
> >\
> > var_names, rot->var_values,
> > \
> > func1_names, func1, NULL, NULL, rot, 0,
> > ctx); \
> > if (ret < 0 || isnan(res) || isinf(res) || res <= 0) {
> > \
> > av_log(ctx, AV_LOG_ERROR,
> >\
> >"Error parsing or evaluating expression for option %s: "
> >\
> >"invalid expression '%s' or non-positive or indefinite
> value
> > %f\n", \
> >opt_name, expr, res);
> > \
> > return ret;
> >\
>
Re: [FFmpeg-devel] [PATCH] Reorganized libpostproc code
On 11/03/15 12:57 AM, Tucker DiNapoli wrote:
> From: Tucker DiNapoli
A couple comments below.
>
> The only changes were formating and moving code.
This needs to be split into several different patches. Also, why does "moving
code" end up with the
addition of one thousand new lines?
> ---
> libpostproc/postprocess.c | 436 ++--
> libpostproc/postprocess_c.c| 1328
>
> libpostproc/postprocess_internal.h | 30 +-
> libpostproc/postprocess_template.c | 124 ++--
> 4 files changed, 1468 insertions(+), 450 deletions(-)
> create mode 100644 libpostproc/postprocess_c.c
If you want to properly refactor the code, it may be a good chance to move the
target specific
assembly to their own separate folders (x86, ppc, etc).
Look at the other libraries to see how it's normally done.
Admittedly outside of the scope of your qualification task, so don't worry too
much for now.
[...]
> @@ -573,8 +217,13 @@ static av_always_inline void do_a_deblock_C(uint8_t
> *src, int step,
> #include "postprocess_template.c"
> #define TEMPLATE_PP_SSE2 1
> #include "postprocess_template.c"
> +#define TEMPLATE_PP_AVX2 1
> +#include "postprocess_template.c"
> #else
> -#if HAVE_SSE2_INLINE
> +#if HAVE_AVX2_INLINE
I'm not sure people will be happy with inline AVX2 code being introduced to the
tree. Last time i
tried with AVX it was not well received and eventually replaced with a yasm
port.
I guess it's an acceptable start, considering at some point all the asm should
be ported to yasm
anyway.
Nonetheless, the addition of an avx2 codepath needs to be in a separete patch,
preferably alongside
some actual avx2 assembly (This patch is adding a bunch of "avx2" functions
that contain duplicated
mmx and sse2 code).
> +#define TEMPLATE_PP_AVX2 1
> +#include "postprocess_template.c"
> +#elif HAVE_SSE2_INLINE
> #define TEMPLATE_PP_SSE2 1
> #include "postprocess_template.c"
> #elif HAVE_MMXEXT_INLINE
> @@ -593,10 +242,10 @@ static av_always_inline void do_a_deblock_C(uint8_t
> *src, int step,
> typedef void (*pp_fn)(const uint8_t src[], int srcStride, uint8_t dst[], int
> dstStride, int width, int height,
>const QP_STORE_T QPs[], int QPStride, int isColor,
> PPContext *c2);
>
> -static inline void postProcess(const uint8_t src[], int srcStride, uint8_t
> dst[], int dstStride, int width, int height,
> +static inline void post_process(const uint8_t src[], int srcStride, uint8_t
> dst[], int dstStride, int width, int height,
> const QP_STORE_T QPs[], int QPStride, int isColor, pp_mode *vm,
> pp_context *vc)
> {
> -pp_fn pp = postProcess_C;
> +pp_fn pp = post_process_C;
> PPContext *c= (PPContext *)vc;
> PPMode *ppMode= (PPMode *)vm;
> c->ppMode= *ppMode; //FIXME
> @@ -605,24 +254,27 @@ static inline void postProcess(const uint8_t src[], int
> srcStride, uint8_t dst[]
> #if CONFIG_RUNTIME_CPUDETECT
> #if ARCH_X86 && HAVE_INLINE_ASM
> // ordered per speed fastest first
> -if (c->cpuCaps & AV_CPU_FLAG_SSE2) pp = postProcess_SSE2;
> -else if (c->cpuCaps & AV_CPU_FLAG_MMXEXT) pp = postProcess_MMX2;
> -else if (c->cpuCaps & AV_CPU_FLAG_3DNOW)pp = postProcess_3DNow;
> -else if (c->cpuCaps & AV_CPU_FLAG_MMX) pp = postProcess_MMX;
> +if (c->cpuCaps & AV_CPU_FLAG_AVX2) pp = post_process_AVX2;
> +else if (c->cpuCaps & AV_CPU_FLAG_SSE2) pp = post_process_SSE2;
> +else if (c->cpuCaps & AV_CPU_FLAG_MMXEXT) pp = post_process_MMX2;
> +else if (c->cpuCaps & AV_CPU_FLAG_3DNOW)pp = post_process_3DNow;
> +else if (c->cpuCaps & AV_CPU_FLAG_MMX) pp = post_process_MMX;
> #elif HAVE_ALTIVEC
> -if (c->cpuCaps & AV_CPU_FLAG_ALTIVEC) pp = postProcess_altivec;
> +if (c->cpuCaps & AV_CPU_FLAG_ALTIVEC) pp =
> post_process_altivec;
Cosmetics belong in a separate patch, if anything to make the diff of the
actual code changes
smaller and easier to read.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
