There are many discussions about how Theora should be used and about how it smokes x264 somehow.

I do not believe it or at least I don't believe the proofs till I try myself.

Any of the Theora zealots reading could please provide a reproducible benchmark so everybody could see for themselves how good/bad Theora is?

A script that fetches the new theora encoder, ffmpeg, takes an original, produces two videos using theora and h264 (no audio), same bitrate for both and in the end outputs cpu and memory usage would be great.

I'm eventually back home, I'm dead tired, the c-base party was great in many ways (people, food, place) and ending the night (actually starting the morning) playing Go with beer and music was _quite_ fun (thanks again for the games =))

I'll try to wrap up everything in a short post before falling asleep completely: the LinuxTag had been a wonderful experience I had been more there as FFmpeg developer and less as Gentoo developer (mostly because I had to man the FFmpeg booth mostly since we aren't that many and that I failed to chat in a proficuous with the gentoo people even if we spent the evening in the same place most of the time =| In the end I had a refreshing conversation about Gentoo with rbu luckily and I managed to chat a bit more with fauli just before he was leaving...)

Was quite fun going at the end of the event to the fsfe stand to do explain the FFmpeg stance about patents, Theora (more will follow) and why, in our humble opinion at least, isn't correct to propose^Wactually shove down to the web users throat such codec just because of some claims that are yet to be validated...

The discussion was quite pleasant mostly because to my surprise fsfe people there weren't zealots, so the whole discussion discussion even evolved to touch more interesting topics, like reverse engineering, making sure our license is respected and actually multimedia, with a brief discussion on containers, codec and streaming (that part actually started from an explanation why Theora isn't that perfect fruit of opensource that is claimed and why Ogg has many
shortcomings as container and why in multimedia you do not have one-size-fit-all solutions... )

After about 4 years I eventually managed to get there! Today is the first day and I'm actually sort of manning the FFmpeg Booth and from time to time I could happen to be in the Gentoo one as well.

In the FFmpeg stand we are showing BBB high res in a big LCD screen from a small beagleboard. The operating system image is obviously Gentoo as well the other system present showing some jumpy Japanese idol video (not my idea).

See you! (Pictures will come later)

During August I was supposed to prepare something new for the LScube project.
I was supposed to do a bit more for the Summer of Code (Sorry Keiji and Seraphim) and the FFmpeg project (libswscale isn't yet in shape I know).

Sadly I spent about a month with a bad pneumonia and just now I'm starting to catch up really. (I hoped to stay better before but, as my 2 miss on council meetings shown, wasn't ok yet)

Diego is doing a wonderful job rationalizing LScube suite, Ale almost finished his Flux (started as a way to show me that C++ isn't the problem, just people misusing it), Michael decided to make libswscale the default in FFmpeg forcing more people taking care about it.

What now?

Well first I'll try to not miss new council meetings (and I'll ask Chrissy and Diego to back me up when happens I cannot be there).

I have some pending stuff about libswscale that will end up having a better structure to provide arch specific optimizations, once they hit I'll try to do again a witch hunt over ffmpeg using applications to provide the new libavcodec in portage.

Hopefully the next feng (and friends) release will hit portage and the stale fenice and libnemesi will be replaced accordingly ^^;

There is plenty of new stuff on the CELL land to be tried and provided (like mars)

I'll try to take some time to merge the openmoko patches to the new (and gcc-4 building) qemu so I won't have to provide an qemu-openmoko to help people interested in getting Gentoo on the freerunner (openrc could help a bit the boot time possibly and bitbake is a bit annoying from time to time)

Last but not least Syoyo is getting his blazing fast renderer Lucille to be usable even by common people.

Lots is happening (with and without me) =)

Quick and easy task for this day: check which is the status of openwengo since seems that's the only client providing what skype does, at least in theory...

Part one, get the source - delivered from the site as a nifty .zip

- wget + unzip worked as should

Part two, build the beast.

- cmake! The worst build system since imake, sadly brought into the fashionable stuff because of KDE4,
Now we get something interesting, on a phenom you get:

qlop -tH cmake
cmake: 5 minutes, 12 seconds for 1 merges

A comparison:
perl: 3 minutes, 43 seconds for 1 merges
m4: 29 seconds for 1 merges
automake: 14 seconds for 3 merges
autoconf: 16 seconds for 2 merges
libtool: 44 seconds for 1 merges
make: 30 seconds for 1 merges
cmake: 5 minutes, 12 seconds for 1 merges

Using something less new makes the whole thing even more interesting. Let's say that to build something using cmake I need the 3/2 the time to build perl, just to start.

gentoo has an ebuild for it so it it's just getting it, (why cmake needs xmlrpc-c is a question I'll left unanswered...)

Now back to openwengo.

I have to create a build dir and run cmake from there, it obviously finds something wrong with ffmpeg even if supposedly it has its stale internal version (remind: ffmpeg changed the include paths some time ago) as fallback (no, you have to run cmake a first time, have it fail, run ccmake, find the right option and turn it on, start again).

I'm not sure if this brain damage is due wengo people or cmake, still I find this annoying. The *oh* so despised configure from autotools can be smarter and does not require that many lines if you know what you are doing...

It still doesn't take in account that there are different endianess for linux (autotools have a nice builtin for this...)...

Once the thing built (took a while), I just got more or less the same thing I got last time I tried it, looks like the 2.2 isn't quite up to date and they are working on the new mayor release =/

Back looking for other alternatives for skype =_=

Lately I started to test some stuff, after hammering openrc inside bsd jails I started to use it on my laptop, the ps3 and the new phenom I bought recently. So far I hadn't anything to complain but just minor glitches that got promptly addressed by Roy. With the help of the other testers and developer you'll get baselayout 2 soon and in a pretty good shape.

Feng and felix got quite an overhaul and hopefully I'll release them once I cleaned up the code:
- felix had lots of experimental stuff added and you may not want it nor look at it right now.
- feng is getting the eventloop reshaped so that you can understand what's doing w/out losing your sanity.

I'm still waiting for more SoC applications (in particular people willing to learn CELL seems fewer than we'd like) you have this week left to apply!

I'm again mentor, again for the same organizations (Gentoo and FFmpeg), with quite yet another batch of strange ideas and demanding tasks for you.

FFmpeg
With Benjamin Larsson and possibly Kristian Jerpetj

First of all I'm eventually snapshotting a newer ffmpeg, I'll need some help to get it play nice with all the other applications. The new ffmpeg has lots of improvements but it changes its api slightly so every application should update accordingly, time has passed so I hope upstream caught up with the change.

Once it will be unmasked I'll hopefully put the next release of feng in portage, currently I'm studying lighttpd internals in order to

• Have feng using the same lighttpd syntax for configuration
• Improve its behavior as server

So far I started importing lighttpd datatypes and lemon based parser directly in a separate branch and reshaping a bit feng in order to make it more rational. First thing learnt from lighttpd: keep everything in instance variables.

In the other news my alubook got its fan broken (and the tibook is in the same sorry shape), if you know where to find replacement parts for it please tell me (bonus if they aren't that pricey).

I had been busy doing my usual load of random stuff, most not completely gentoo related, some a bit more.

Let's start with the nicer ones: Marco spent lots of time and eventually it paid off, ffdirac now supports Iframes just fine, it's quite an important step! As mentor I hadn't to do much beside watching the evolution of the code and suggesting course of action. In the other news there is a new dirac spec released just today, probably some of the changes are due Marco's work =)
Today we tried to do some hackery to get git-svn play nice with the braindamage we have on the ffmpeg soc svn. Sadly my side works great, his side not (fetching from svn and pulling to an ffmpeg.git branch works, pushing back to svn not).

About the dirac project I must say that they started with the right frame of mind from day 0, I couldn't find a group more open to discussion and suggestion, no matter if were things like "It's wrong to implement dirac in C++, nobody would use it" or "the latex pdf output as you made it is unreadable. I hope to eventually have the time to get texlive working or find something that converts the tex files to docbook and provide a better pdf for them, really I cannot stand reading it for more than 5min... Now I hope this summer of code effort will lead to get a better dirac overall (and that eventually BBC will use it for streaming their fine contents, oh, did I mention that I have a student on my university that should work on getting dirac-rtp a reality? check LScube in the next month)

To sum up, I'm quite happy with this summer of code experience and I thank Marco again for being a great person to work with.

While we are at it some more informations about ffmpeg related efforts, I eventually hacked again a bit on roundup resulting in fixing/workarounding some problems with the email integration, if you happen to have some problems on ffmpeg please give it a try.

Beside that, my work at LScube is still going on, sucking lots of my time... Lately I tried to add more packetizers to feng but w/out much success, looks like my aac implementation is a *bit* wrong, usually relooking at it after a while helps me fixing the issue (as I did for h264) I hope to have it (and many more) completed for the next release. On the client side libnemesi is still waiting for more depacketizers while Alessandro is cleaning up the network stacks, making it less quirky.

Now I could speak of gentoo related stuff, I'm trying to fix some of the programs still using the img_* interface, since it is an annoying task I waited a bit hoping upstream would adapt... No reaction so far so I'm starting with something simple as blender and then hopefully move on other ones. What sucks about the img -> sws move is that sws is less commented, has quite ugly but performant code and it's a pain to hack on, I started to clean it up but then got sidetracked so there are still some patches waiting completion...

I guess this is a post long enough, probably I'll add another update tomorrow.

I spent much of my time trying to get the whole LScube project more alive, so far it's just a slow start:

I moved the development to git ( https://live.polito.it/gitweb ) and now I'm trying to update the website to a newer drupal and with more documentation. Since the forums are just a spam magnet I guess I'll nuke them, if you want to contact us just use irc or email =P

I put the efika in use to stress test the streaming server, you can watch

rtsp://130.192.86.166/tc.mov

or

rtsp://130.192.86.166/ed.mov

(both streams are h264+mp3, not many clients could handle that... Yet)

Hopefully a Feng release will appear soon.

That's for the streaming stuff.

Now, I have a ps3 working and eventually managed to configure and install it, I already found something itchy: git's ppcsha1+64ul == KaBOOM, I hope it's just due my test with bleeding edge compilers but I'm afraid not. So far I'm quite impressed by the ps3, just a pity I'm slow in doing something nice there...

More will follow

lu

Just a quick update :

- got the ps3 running and well, I must say that its quite cool
- got swamped in many other things and so I'm slowly configuring my network to get the ps3 on, in the process I managed to brick my first access point (a belkin that now I'll have to hack a bit to recover if possibile...)
- the lscube tasks are proceding nicely, currently we eventually ironed out some bugs due mp3 and the compositing layer, for the ones not following: I'm working on a new streaming server called Feng, currently it streams h264 and mp3 and let you either just point an url to a container and automagically provide a sdp or, more interesting, let you define a special editlist so you can just provide a simple textfile with the files and the start and stop time and have aggregated streams on the fly, pretty interesting if we manage to complete it and then make it usable =)
- I still have to fix B frames support in h264 and then move on improving those framers or eventually implement vorbis and theora, the gst crew beat me at it but I'd like to be at least a close second ^^;
- I hope to cleanup the roundup setup and the site restyle for lscube soonish once the previous task got addressed since I'd like to get more people involved and the current framework still has some rough edges...

- I'll start probably hacking on the bfin due a course I'm attending, I cannot say I really like the arch since is a bit irregular, still much nicer than x86 (expect ffmpeg patches about it soon^^)

- last but not least I have my laptop eventually back!

that said I guess you may know why I'm not much reactive on bugs (I promise I'll try at least the blender ebuild and to provide updates to ffmpeg and mplayer ones during the week end) and I less than lively...

PS: Cocoa programming isn't that nice...

I prepared some new snapshots in line with the newer x264, ffmpeg will be replaced soon since there are already some minor known issues, mplayer should be sane enough.

I hope I didn't forget anything in the ebuild.

Have fun

After getting some sense about memcpy and h264 (ok, my sample was short enough to make relevant some optimizations that apply just on codec init, thus meaningless) I eventually got something in that seems to be relevant enough and tool quite few lines: I enabled prefetch.

It is pretty much a single asm line and in certain cases it meant a 10% of overall decoding time shaved away. Before I tried using altivec prefetch and it didn't show a great result so I just removed it, 2 days ago I implemented it with the generic instruction and the result was pleasant enough.

If you happen to have non G4 systems please try to benchmark mpegvideo and h264 decoding for me and report results, the commit revision is 6669

Hopefully I'll try to provide a snapshot for gentoo in this weekend.

Ok, the title is misleading on purpose, as you can see from the previous post I got some requests about ffmpeg+ppc (power, cell, plain ppc), in the case of h264 I'm afraid all the useful bits are already vectorized and the little left around will be useful but isn't really top priority (obviously I'll try to be on par with i386 optimizations, so weight and loop filter funcs will have their respective in altivec sooner or later). Other codecs have lots missing vectorization wise, say vp{3,5,6} family that many could like/need because of flash embedded videos, or some quick asm bits could be quite useful for our lil embedded ppcs the same way they are already useful and implemented for arm.

My plan for the next week is keep reordering code and put it back in arch specific dirs so it could be implemented in a more agile way (see what I did for the mathops or what I'm about to try for the bitstream read/write functions), hopefully I'll complete and commit some altivec optimizations like the mdct (even if I should check if in altivec makes the difference or not), the vp idct variant or the h264 latest bits.

I'll be unavailable for the week end, see you monday =)

Recently I got some inquiries about h264 and altivec. just testing decode time was disappointing to some user.

I did my test and on my g4 1.6 I got about the double ofthe speed he experienced on his g5 2.4.

time nice --20 ./ffmpeg -i ~ryan/bluesky_HD_CAVLC_JM93_217f.264 -f rawvideo - > /dev/null
real 0m47.685s
user 0m44.304s
sys 0m3.220s

cat /proc/cpuinfo
processor : 0
cpu : ppc970, altivec supported
clock : 2400.000000MHz
revision : 4.0 (pvr 0070 0400)

time nice --20 ./ffmpeg -i /tmp/bluesky_HD_CAVLC_JM93_217f.264 -f
rawvideo - > /dev/null
real 0m25.877s
user 0m23.768s
sys 0m1.904s

cat /proc/cpuinfo
processor : 0
cpu : 7447A, altivec supported
clock : 1666.666000MHz
revision : 0.5 (pvr 8003 0105)

The ffmpeg code is the same, I hadn't use anything but the stock cflags, same for him.
I was expecting quite a different result, time hunt the slow gear!

I used oprofile

just started and stopped it befor the ffmpeg call, and the asked opreport to compute some statistics about symbols.

an excerpt

CPU: PowerPC G4, speed 1666.67 MHz (estimated)
Counted CYCLES events (Cycles) with a unit mask of 0x00 (No unit mask) count 100000
samples % image name symbol name
60355 23.2602 libc-2.4.so _wordcopy_fwd_aligned
13572 5.2305 ffmpeg_g put_h264_chroma_mc8_altivec
13417 5.1708 ffmpeg_g filter_mb
11379 4.3853 ffmpeg_g put_h264_qpel16_h_lowpass_altivec
9700 3.7383 ffmpeg_g fill_caches
9332 3.5965 ffmpeg_g hl_decode_mb
8201 3.1606 vmlinux __flush_dcache_icache

Looks like I'll have to replace something... or start thinking about optimized glibc...
(mine is built targeting my cpu and is pretty recent, I wonder if the G5 isn't running on an older or generic built glibc...)