August 2009 - ffmpeg-devel - lists.ffmpeg.org

[PATCH] Add RSHIFT_POS and ROUNDED_DIV_POS
by ramiro.polla＠gmail.com 02 Aug '09

02 Aug '09

Hi, Currently there is RSHIFT(a,b) and ROUNDED_DIV(a,b), which work for both negative and positive values of a. This patch adds variants that only work on positive values of a, so it may be used on variables known to be positive. And another patch uses it in swscale. Ramiro Polla

2 4

[PATCH] Use enums in libavformat/output-example.c.
by ramiro.polla＠gmail.com 02 Aug '09

02 Aug '09

$subj

2 2

Remove some optimizations from Makefile
by ami_stuff＠o2.pl 02 Aug '09

02 Aug '09

Hi, I would like to propose remove of some optimalizations from makefile. 1. GCC 4.4.1 -O3 flag activates these optimizations: -O2 -finline-functions -funswitch-loops -fpredictive-commoning -fgcse-after-reload -ftree-vectorize The problematic optimization is "-funswitch-loops". When I compile FFmpeg with this flag enabled as a result: a) I get monstruary/slow binary generated for m68k. * libavcodec/dsputil.o + -03 flag -> 1,18MB * libavcodec/dsputil.o + -O2 flag -> 306KB + -finline-functions + -fpredictive-commoning + -fgcse-after-reload + -ftree-vectorize options b) GCC 4.4.1 ICEs on "libavcodec/mpegvideo.o" because of "-funswitch-loops". Without this flag there is no ICE at all. 2. GCC 3.4.0 -O3 flag activates -fweb optimization. This optimization produces bad result from belowe inline: static inline int64_t MAC64(int64_t d, int a, int b) { union { int64_t x; int hl[2]; } x = { d }; int h, l; __asm__ ("muls.l %5, %2:%3 \n\t" "add.l %3, %1 \n\t" "addx.l %2, %0 \n\t" : "+dm"(x.hl[0]), "+dm"(x.hl[1]), "=d"(h), "=&d"(l) : "3"(a), "dmi"(b)); return x.x; } When I use "-fno-web" switch, inline works correctly. First I thought this inline is supposed to work with GCC 4.x+ only, but it looks like -fweb optimization destroyes it. Maybe Mans have GCC 3.x m68k cross-compiler installed and can test if the same happens with GCC 3.4.1 and up to 3.4.6. Regards

2 8

[PATCH] getenv & strerror should be a NOP on WinCE
by ismail＠namtrac.org 02 Aug '09

02 Aug '09

Hi; Patch attached. Regards. -- ?smail D?NMEZ

3 6

[PATCH] mov.c should include os_support.h since it uses strerror
by ismail＠namtrac.org 02 Aug '09

02 Aug '09

Hi; Patch attached. Regards. -- ?smail D?NMEZ

2 2

adding --cpu=native option to ffmpeg configure script
by jekarlson＠gmail.com 02 Aug '09

02 Aug '09

Greetings Basically the motivation and some sort of draft solution (only for gentoo ebuild though) is described here. http://bugs.gentoo.org/show_bug.cgi?id=273421 ie. ffmpeg configure --cpu=native option might be able to optionally choose the cpu type on the local computer. Sample solution: cpu=`echo "int main() {}" | gcc -march=native -xc -S -Q -v - |& egrep -m 1 -o "\-march=.*" | cut -f 1 -d \ | cut -f 2 -d \=` It's a bit ugly but shouldn't cause any regressions, if you limit this code to option --cpu=native. Any comments? -Emil

2 1

[PATCH] remove commented-out code from rv10.c
by diego＠biurrun.de 02 Aug '09

02 Aug '09

I suspect most of it is cruft. Michael, I will commit whatever you approve hunk by hunk. Diego

2 1

[MPlayer-users] [BUG] swscaler conversion of yv12 to nv12 broken (fwd)
by g.liakhovetski＠gmx.de 01 Aug '09

01 Aug '09

Hi all I was suggested to forward this report / possible fix to the ffmpeg list, so, here it goes. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ ---------- Forwarded message ---------- Date: Thu, 30 Jul 2009 14:58:58 +0200 (CEST) From: Guennadi Liakhovetski <g.liakhovetski at gmx.de> Reply-To: "MPlayer usage questions, feature requests, bug reports" <mplayer-users at mplayerhq.hu> To: mplayer-users at mplayerhq.hu Subject: Re: [MPlayer-users] [BUG] swscaler conversion of yv12 to nv12 broken On Thu, 30 Jul 2009, Guennadi Liakhovetski wrote: > Hi > > I'm using mplayer on a SuperH platform with the sh_veu vidix driver, which > takes nv12 as an input format. It used to work at least with a version > from August 2008, a recent (21.07) SVN snapshot doesn't work any more. > Doesn't work means, that with the clean SVN version the image appears > black-and-white on the LCD. Ok, problem fixed. Or more precisely, it's cause found and a crude solution produced, now it's up to you to produce a correct one. So, the cause is, that sws_getContext() is now picking up a wrong converter for the yv12 -> nv12 case. It first gets the right one - PlanarToNV12Wrapper(), but then it goes on and overwrites its first choice with planarCopy(). The reason, I think, is too broad criteria for the latter one. I narrowed them down with Index: libswscale/swscale.c =================================================================== --- libswscale/swscale.c (revision 29435) +++ libswscale/swscale.c (working copy) @@ -2791,7 +2791,9 @@ || (isGray(dstFormat) && isGray(srcFormat)) || (isPlanarYUV(srcFormat) && isPlanarYUV(dstFormat) && c->chrDstHSubSample == c->chrSrcHSubSample - && c->chrDstVSubSample == c->chrSrcVSubSample)) + && c->chrDstVSubSample == c->chrSrcVSubSample + && dstFormat != PIX_FMT_NV12 && dstFormat != PIX_FMT_NV21 + && srcFormat != PIX_FMT_NV12 && srcFormat != PIX_FMT_NV21)) { if (isPacked(c->srcFormat)) c->swScale= packedCopy; As I said, this is, probably, not the right solution, but it fixes the problem. In the working version the test was just if ( srcFormat == dstFormat || (isPlanarYUV(srcFormat) && isGray(dstFormat)) || (isPlanarYUV(dstFormat) && isGray(srcFormat))) Looking forward to a correct solution of the problem. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ _______________________________________________ MPlayer-users mailing list MPlayer-users at mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/mplayer-users

3 3

[PATCH][RFC] Indeo3 replacement
by max_pole＠gmx.de 01 Aug '09

01 Aug '09

Hi crews, as already volunteered I'd like to maintain indeo3 decoder in the future. Unfortunately the ffmpeg's decoder is unmaintable (Mike, sorry!) because nobody understands how it works. Therefore I want to submit a patch proposing a new source for this algorithm. Below its advantages in short: - deobfuscated algorithm - heavily commented source - decoding tables will be generated dynamically making "indeo3data.h" tiny compared to the existing one! - one huge code blob was splitted into several functions Disadvantages: - it was written fast therefore it contains several simplifications can be programmed safer - may be further splitted - it was not tested on PPC yet There is already a documentation for this algorithm here: http://wiki.multimedia.cx/index.php?title=Indeo_3 Attached files are the sources itself because the new sources are VERY different from the existing ones! Plz be merciful to me and help me out to make this stuff good-looking! Waiting for reviews...

9 22