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

Lately I spent lots of time cleaning up lscube related stuff, mostly trying to hack together lighttpd features inside feng. I'm getting ready for the Internet Governance Forum meeting that we will webcast.

My laptops (both G4, one titanium and one aluminium) got their fan broken in a quite unpleasant way and I'm still wandering looking for replacement, maybe it's time to buy something else =_=
Lately I tried to look around and found some more or less nice laptops and even started thinking about getting a phenom system for home...

In the other news Seems that something would appear soonish at least as desktop... so maybe I could stay x86 free for a bit more ^^;

lu

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.

You may wonder what I'm doing since has been a long time since the latest blog item, well I was busy trying to do too many thing, searching, traveling and so on.

Here a summary:

- I eventually released feng as you can see on http://live.polito.it
That involved getting the website up, writing lots of documentation (that hopefully someone will read), hacking the code to be in the right shape and making the whole bundle bearable for people with less understanding of autotools and dependencies... I hope the first release isn't that ugly and I thank dario and alessandro for their help =)

- The ffmpeg bug tracker is taking shape eventually, hacking roundup isn't the simplest thing in the world
mostly because examples and alternate templates aren't available; the documentation saves the day most of the times anyway. you may see it on https://roundup.mplayerhq.hu/roundup/ffmpeg/

- On the cell side I started hacking a bit the build system in order to have it working for me (using gentoo, standard paths and stock gcc toolchain) and for the ones that are using the IBM sdk/fedora (bogus paths, shortened prefixes) I hope the people in charge of deciding what would be the standard for writing and running spu code would provide a sane default. Hopefully one I'll have more time I'll start writing something on my own, so far I'm just testing pathes and contributions by others ^^;

- the vorbis and theora rfc are proceedings and currently feng and gst are interoperable, I hope to complete the standardization and move to something else, it's taking too much!

- my altivec work on cairo is still on hold, I hope to get enough time to push an update (since the ibm/sony mathlib has an implementation of vector integer division I could rip it and add some more vector ops in pixman).

- the SoC with ffmpeg has already started, so far I'm receiving some good feedbacks from my student and I'm trying to find the time to reread the dirac spec in order to follow him better.

That's more or less all, the keyword of the whole document is TIME, lately the lscube involvement took a bit too much mostly because you cannot manage the time well if you have your plans spoiled every by unexpected priorities appearing out of the blue.

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...

It was quite a busy week, we (me and dario) eventually end up gaining full access to our lab and got all the duties our previous mentor and colleagues had at lscube.

We had been at ONU for our first webcast in Geneva. The place was quite nice and the people were absolutely great =). Once we got back in Italy we spend some time preparing the feed for storage and preparing a new release for fenice (did we tell the 1.12 was the last? well not really since felix was missing....) and felix, the live feeder.

Hopefully tomorrow I'll set up everything for a proper release and then move to fenice-ng or fe.ng and libnemesi, while we were travelling I eventually fixed the h264 packetizer so now fe.ng can stream h264 and mp3 correctly =) Once I get also libnemesi supporting it I'll do at least as rc snapshot. Dario worked quite hard to improve the scheduler in order not to choke on certain bad behaviours from a certain well known client...

Now I have a big news: I eventually got a ps3 =) It is japanese model sony graciously lent me for a while ^^ Sadly the label on says 100V~3.8A 50/60Hz and that means that I have to get a voltage converter... Luckily Geert pointed me a nice german shop with good prices, http://www.thiecom.de, I hope what I ordered (correcting at the last minute a product mismatch, I hope the order change email reached otherwise I'd get a 110to220 that is exactly the opposite I need...) will arrive next week since I want to check myself the new livecd and maybe complete the step by step docs.

I eventually complete the fbcompose altivectorization in cairo (check the mailing list for the patch) and hopefully now there is enough to start benchmarking it...

Now the sad news: my Alubook hd died, I'm trying to recover as much as possible and then send it for repair (this time I have a full applecare and I'm going to use fully ^^ ), so I won't as much available as I was before for more or less 2-3 weeks, hopefully.

I guess that's more or less all.

- Ps3/Cell: I eventually fixed the binutils in order to get it build for spu-elf, I'm about to unbreak better gcc since someone thought NOTE_INSN_EXPECTED_VALUE wouldn't be of any use, while the spu.md is using it for the cmp instructions... (needless to say my workaround isn't working that well...), tomorrow hopefully I'll update the patchset either with the revert of this patch or with a proper solution (hard since I'm not that proficient in gcc internals =/), I'm afraid of glibc...

- Fenice/lscube: trac + git is a no go, trac itself or setuputils on the fedora server that is streaming is from bad to idiotic or maybe it's just me unproficient, add also that gitweb seems unavailable as fedora and you get an interesting picture, importing is easy, working almost (once everybody figures the commands), so there some uncertain about a full transition.

- Personal life: You can use anything happens to you to improve, still I'm afraid I won't develop the ability to teleport and/or timeshift in order to improve the situation, anyway I'm unfeeling better.

- University: I'm forced to do something in mono for an exam and obviously I have about 30h to learn enough gtk# to do that, luckly glade is always glade...

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...)

Ok, the name isn't that stable and probably I'm going to shake the api a bit more soon.

Anyway, the rtp/rtsp client library from lscube is eventually getting in shape and now I moved from simple example to something more useful:

- audacious now has support for mp3 over rtsp using libnemesi simple/toplevel API

- MPlayer is about to get a demuxer using again the simple API (or at least I'm trying to)

- I'm pushing Diego in order to get also Xine nemisified.

So, last calls before the API freeze and the first release. Start playing with it now so you can get the changes you need before the next major version.