January 2008 - ffmpeg-devel - lists.ffmpeg.org

Searching for a ffmpeg BCLO (bastard chief legal officer)
by michaelni＠gmx.at 22 Apr '08

22 Apr '08

Hi The number of LGPL and GPL license violations increases, we already have 6 on roundup. I first thought ill try to contact them but i guess it would be more efficient if someone else could do that and i could concentrate on developing which id also prefer :) So what are the requirements for the BCLO: * Short temper (not the kind type of guy who nicely talks with them for 3 month) * legal knowlegde (you dont have to be a lawyer but you should know the (L)GPL and have an approximate idea of copyright law) * ability to read C code, use strings and grep * ability to use traceroute and the others to find the ISP, domain name provider, ... of a company Things which would be nice * some good contacts to online sites/local radio/newspapers which might be interrested in publishing an article about such copyright violation * actually being a lawyer What should be done * Contact the companies and demand full compliance to the LGPL/GPL that is source code from the whole program(GPL) or libav*(LGPL) under the *GPL, COPYING file, some mention in the about box and or similar if one exists, (removial of anti reverse engeneering clauses conflicting with the *GPL maybe as well), ... * give them a clear time limit (for example 2 weeks) and stick to that only give them more time if some progress is vissible and also dont overdo it, the 6month+ times we have on roundup are completely unacceptable * Dont waste time with irrelevant things (libamr is undistrbutable and such) thats none of our bushiness and only delays them in complying to the *GPL * If they fail to do solve any issue before the time limit, contact their ISP, domain provider, bank, anyone else you can think of and inform them about that their client is violating copyright. Also contact local radio stations, newspapers, online stuff, anyone else you can think of And if you are a real lawyer, sue them * also if they used GPL and switch to LGPL without ever releasing full source, demand some compenation like hardware and or money. My suggestion here would be 10k euro equivalent unless its a small company or some private guy. Payment none from us but if a company pays us something due to a license/copyright violation it certainly would be acceptable if some part of that would be given to you, maybe 30% or so, rest would go to the ffmpeg project ... But then this also opens the donations tax problems box, so someone would have to solve that first ... -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact

16 53

[RFC] Loop unrolling in C code for 'vector_fmul_*' functions
by siarhei.siamashka＠gmail.com 21 Apr '08

21 Apr '08

Hello, I tried to figure out why 'ffvorbis' is somewhat slower than fixed point 'tremor' decoder on Nokia N800 in spite of having hardware floating point support onboard (VFP coprocessor). Some noticeable amount of time is used by 'vector_fmul_*' functions: # opreport -l ./mplayer CPU: ARM V6 PMU, speed 0 MHz (estimated) Counted CPU_CYCLES events (clock cycles counter) with a unit mask of 0x00 (No unit mask) count 100000 samples % symbol name 50133 20.7036 ff_fft_calc_c 43325 17.8921 ff_imdct_calc 31860 13.1574 vorbis_decode_frame 30818 12.7270 ff_vector_fmul_add_add_c 18704 7.7243 vorbis_inverse_coupling 18465 7.6256 vector_fmul_c 18057 7.4571 vector_fmul_reverse_c 11140 4.6005 ff_float_to_int16_c 8429 3.4810 render_line 4228 1.7461 vorbis_floor1_decode 1188 0.4906 ogg_page_checksum_set And 'vector_fmul_*' functions look like a 'low hanging fruit' in the sense that they seem to be quite easy to optimize :) But there is another interesting thing, C implementation of these functions is very straightforward and it does not even unroll loops. But assembly or other SIMD optimizations exist only for x86 and ppc at the moment for these functions. Is it intentional and code readability is the main priority for them? Or some tweaks could be added to improve 'generic C' code performance? I have written and attached a simple test program which benchmarks various 'vector_fmul' implementations and tried it on N800 and my desktop PC. The results are listed at the bottom of this message. I wonder what would be the results from the other platforms which do not have optimized implementations for these functions yet (non-x86 and non-ppc)? But at least for ARM, looks like the compiler is quite stupid and can't schedule instructions properly as seen from the benchmark results (just unrolling loop is not enough and some extra tweaks are needed in 'vector_fmul_c_other_unrolled'). VFP coprocessor has a high result latency (8 cycles), though throughput is quite good (1 cycle) and some other nice features which can improve performance exist (documantation for VFP can be found at http://www.arm.com) The compiler (gcc) does not even try to reorder instructions and pipeline is just stalled most of the time. I would not be surprised if the compiler screwed up and generated something suboptimal on more complicated floating point stuff as well (fft and imdct). Tweaking C code, performance can be improved quite a lot ('vector_fmul_c_other_unrolled' vs. 'vector_fmul_c_unrolled'). But such unnesessarily cluttering code because of inefficient compilers is not a good option. Anyway, probably at least just loops can be unrolled to help the compiler do its job? The compiler itself does not know that 'len is a multiple of 8' and manual loops unrolling seems to be reasonable. Well, I will do the rest of ARM VFP optimizations for all these 'vector_fmul_*' functions anyway :) I hope this post was not a completely useless spam. ------------------------------ Nokia N800 (ARM11 400MHz) gcc 4.2.2, '-O3 -fomit-frame-pointer -mcpu=arm1136jf-s -mfloat-abi=softfp' $ ./vector_fmul_test 400 Function: 'vector_fmul_c', time=34.439 (cycles/element=26.905) Function: 'vector_fmul_c_unrolled', time=22.801 (cycles/element=17.813) Function: 'vector_fmul_c_other_unrolled', time=7.012 (cycles/element=5.479) Function: 'vector_fmul_c_simd', time=20.049 (cycles/element=15.664) Function: 'vector_fmul_vfp', time=2.628 (cycles/element=2.053) ------------------------------ AthlonXP 2400+ (2000MHz) gcc 4.1.2 '-O3 -fomit-frame-pointer -march=athlon-xp' $ ./vector_fmul_test 2000 Function: 'vector_fmul_c', time=0.893 (cycles/element=3.486) Function: 'vector_fmul_c_unrolled', time=0.565 (cycles/element=2.207) Function: 'vector_fmul_c_other_unrolled', time=0.574 (cycles/element=2.242) Function: 'vector_fmul_c_simd', time=0.310 (cycles/element=1.210) ------------------------------ AthlonXP 2400+ (2000MHz) gcc 4.1.2 '-O3 -fomit-frame-pointer -march=athlon-xp -mfpmath=sse' $ ./vector_fmul_test 2000 Function: 'vector_fmul_c', time=0.810 (cycles/element=3.166) Function: 'vector_fmul_c_unrolled', time=0.803 (cycles/element=3.137) Function: 'vector_fmul_c_other_unrolled', time=0.801 (cycles/element=3.131) Function: 'vector_fmul_c_simd', time=0.312 (cycles/element=1.219)

9 18

[PATCH] Add the function libavcodec/utils.c:avcodec_type_string
by stefano.sabatini-lala＠poste.it 07 Apr '08

07 Apr '08

Hi to all, suggested log: $subject. Well, I know it's stupid, nonetheless I find myself writing this little function again and again in applications (especially when I'm trying to do some debugging). Also bumps micro version since it adds a function to the external api. Best regards. -- Stefano Sabatini Linux user number 337176 (see http://counter.li.org)

8 20

[PATCH] ported SGI decoder to the new API
by sunxiaohui＠dsp.ac.cn 30 Mar '08

30 Mar '08

Xiaohui Sun wrote: patch updated. > Hi > > On Thu, Apr 05, 2007 at 09:42:59AM +0800, Xiaohui Sun wrote: > [...] > > > + * @param out_ptr output buffer > > this pointer does not point to the output buffer but rather to the line > after the output buffer done > > > > + * @param in_buf input buffer > > + * @param end_buf end of input buffer > > + * @param s the current image state > > + * @return 0 if no error, else return error number > > + */ > > +static int read_rle_sgi(unsigned char* out_ptr, uint8_t *in_buf, > > + uint8_t *end_buf, SgiState* s) > > s/end_buf/in_end/ done > > > > +{ > > + uint8_t *dest_row = out_ptr; > > + unsigned int len = s->height * s->depth * 4; > > + uint8_t *start_table = in_buf; > > + unsigned int y, z; > > + unsigned int start_offset; > > + > > + /* size of RLE offset and length tables */ > > + if(len * 2 > end_buf - in_buf) { > > + return AVERROR_INVALIDDATA; > > + } > > + > > + in_buf -= SGI_HEADER_SIZE; > > + for (z = 0; z < s->depth; z++) { > > + for (y = 0; y < s->height; y++) { > > + dest_row -= s->linesize; > > + start_offset = bytestream_get_be32(&start_table); > > + if(start_offset > end_buf - in_buf) { > > + return AVERROR_INVALIDDATA; > > + } > > + if (expand_rle_row(in_buf + start_offset, end_buf, > dest_row + z, > > + dest_row + FFABS(s->linesize), s->depth) != s->width) > > + return AVERROR_INVALIDDATA; > > + } > > > + dest_row = out_ptr; > > if you move this line before the for() then you avoid the second such > assignment above done > > > > + } > > + return 0; > > +} > > + > > +/** > > + * read an uncompressed SGI image > > + * @param out_ptr output buffer > > > + * @param end_ptr end ofoutput buffer > > typo also s/end_ptr/out_end/ done > > > > + * @param in_buf input buffer > > > + * @param end_buf end of input buffer > > s/end_buf/in_end/ > done > > [...] > > + uint8_t *dest_row = end_ptr; > > this is uneeded > done > > > + uint8_t *ptr = in_buf; > > + unsigned int offset = s->height * s->width; > > + > > + /* test buffer size */ > > + if (offset * s->depth > end_buf - in_buf) { > > + return -1; > > + } > > + > > + for (y = s->height - 1; y >= 0; y--) { > > > + dest_row = out_ptr + (y * FFABS(s->linesize)); > > this looks wrong changed > > > > + for (x = s->width; x > 0; x--) { > > + for(z = 0; z < s->depth; z ++) { > > + bytestream_put_byte(&dest_row, *ptr); > > + ptr += offset; > > + } > > > + ptr = ++in_buf; > > if you move this assignment before the for loop then you avoid the second > redundant assignment farther above done > > > [...] > > + dimension = bytestream_get_be16(&in_buf); > > + s->width = bytestream_get_be16(&in_buf); > > + s->height = bytestream_get_be16(&in_buf); > > + s->depth = bytestream_get_be16(&in_buf); > > these could be verticall aligned like > > dimension = bytestream_get_be16(&in_buf); > s->width = bytestream_get_be16(&in_buf); > s->height = bytestream_get_be16(&in_buf); > s->depth = bytestream_get_be16(&in_buf); > > looks nicer ... (not really important though) changed > > > [...] > > + /* name */ > > + memset(buf, 0, 80); > > + buf += 80; > > + > > + /* colormap */ > > + bytestream_put_be32(&buf, 0L); > > + > > + /* the rest of the 512 byte header is unused */ > > + memset(buf, 0, 404); > > + buf += 404; > > thats just a single memset() ... > > > [...] > > + if((length = ff_rle_encode(buf, end_buf - buf - 1, > encode_buf, 1, width, 0, 0, 0x80, 0)) == -1) { > > if(... < 1) > done > > [...]

4 16

[PATCH] Vorbis I floor type 0 support
by eclipse7＠gmx.net 16 Mar '08

16 Mar '08

Hi, i extended the ffmpeg vorbis decoder to decode vorbis floor0 files. It is my first try at this kind of stuff. I only had one sample tho testing wasn't too exhaustive. I tested the code on linux x86 and Solaris SPARC so far. As always comments and testers welcome. Have fun, Alex (beastd)

7 17

[qt-faststart] Ever get "could not allocate 0x14 byte for ftyp atom"?
by kevin.t.campbell＠gmail.com 14 Mar '08

14 Mar '08

Hello, I am checking with people to see if anyone has ever gotten this error after running qt-faststart. I am pulling my hair out trying to figure out what the problem may be and wondered if anyone knew of a starting point. I'll take anything! *Error:* *could not allocate 0x14 byte for ftyp atom* *System: *Linux (centos), gcc ~3.4, latest ffmpeg, latest qt-faststart, basically all codec libraries (the movie comes out great with FFMPEG, it just wont stream because I fear the MOOV atom is out of place). *Example FFMPEG: First Pass* ffmpeg -i input.avi -an -pass 1 -threads 2 -vcodec libx264 -b 512k -bf 3 -subq 6 -cmp 256 -refs 5 -qmin 10 -qmax 51 -qdiff 4 -coder 1 -loop 1 -me hex -me_range 16 -trellis 1 -flags +mv4 -flags2 +bpyramid+wpred+mixed_refs+brdo+8x8dct -partitions parti4x4+parti8x8+partp4x4+partp8x8+partb8x8 -g 250 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 output.mp4 *Second Pass:* ffmpeg -i input.avi -acodec libfaac -ar 44100 -ab 160k -pass 2 -threads 2 -vcodec libx264 -b 512k -bf 3 -subq 6 -cmp 256 -refs 5 -qmin 10 -qmax 51 -qdiff 4 -coder 1 -loop 1 -me hex -me_range 16 -trellis 1 -flags +mv4 -flags2 +bpyramid+wpred+mixed_refs+brdo+8x8dct -partitions parti4x4+parti8x8+partp4x4+partp8x8+partb8x8 -g 250 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 output.mp4 *QT-FASTSTART: *qt-faststart output.mp4 newOutput.mp4 Please let me know if anything else is needed. Kevin

7 10

[PATCH][0/4]: MMS base and MMSH implementation
by bjorn.axelsson＠intinor.se 10 Mar '08

10 Mar '08

This is basically the same as my old MMS patch, only somewhat updated and split into smaller patches (one per file). Patch 1 and 2 are only new files and can be applied in any order. Patch 3 depends on 1 and 2, but still only touches the new files. The fourth patch in this series contains the makefile changes and protocol registration code, and should not be applied before the other three are applied. Only when this patch is applied can the new code be compiled and used. The complete series passes "make test". -- Bj?rn Axelsson Phone: +46-(0)90-18 98 97 Intinor AB Fax: +46-(0)920-757 10 www.intinor.se Interactive Television & Digital Media Distribution

4 13

[PATCH] Read ogg stream language
by Reimar.Doeffinger＠stud.uni-karlsruhe.de 02 Mar '08

02 Mar '08

Hello, attached patch makes vorbis_comment (which lacks a ff_ prefix btw) parse the language tag into AVStream.language (if a mapping is known). It also adds vorbis comment parsing to oggparseogm.c (I would apply as a second step). The code is probably improvable, the mapping list even more so. Greetings, Reimar D?ffinger

4 15

[PATCH] activate ac3 decoder
by justinruggles＠bellsouth.net 28 Feb '08

28 Feb '08

Hi, The AC-3 decoder is at a point where it can be activated. Really it has been working for a while, but I wanted to get downmixing correct before activating it. This patch works for me, but I'm not absolutely sure that it's the correct way to do it. I'm definitely not done with the changes to the decoder...I just think it has enough working features now to be fully included in FFmpeg. For now it's still licensed as GPL. I'm about 95% confident that the parts derived from liba52 are now gone, but I'm not 100% sure. Once the E-AC3 decoder is added and if Michel Lespinasse gives his blessing, then it can be changed to LGPL at that time. -Justin

10 24

Unified CPU Endianness for framecrcenc
by mike＠multimedia.cx 26 Feb '08

26 Feb '08

Hi, I am using libavformat/framecrcenc.c for automated testing on the FATE Server ( http://fate.multimedia.cx ). For those who don't know, '-f framecrc' is a neat tool that "muxes" a file by simply running the Adler CRC algorithm over incoming packets and printing some frame stats to the stdout. It's great for validating bit accuracy for file/codec types that are expected to be bit exact. I am having trouble with certain formats, however. For example, if the data is decoded as 15- or 16-bit RGB/BGR, the data will be stored in CPU endianness. Would it be acceptable to have a special "#ifdef BIG_ENDIAN" case in the muxer that swaps bytes before running the CRC? Or is there a better solution to the problem? I'm asking before I do the coding work. There is also the problem with the endian-order palette on PAL8 frames, but I want to address the 15/16-bit problem first. This also affects 32-bit RGB/BGR. Thanks... -- -Mike Melanson

3 6