@all

darn, just found a bug that corrupts the video partially, need to find exactly which commit broke it, so stay tuned. :-/

@all

Updated results (up to commit 4766373):



I now want to work on optimizing AAC and AC3, plus some others not so vital components, but every little bit helps. I'll post updates here.

@tommysammy

I did last night, if you check the github page[1], I am a bit sick with the flu atm, but I wanted to run some benchmarks first, but currently this version gives me another fps in some cases and also helps performance with other formats as well (like mpeg/ogg) not just h264. I'll post some benchmarks soon.

[1]: https://github.com/markos/FFmpeg/commits/master

@corto

I'm pretty positive that the DST instructions cause a performance hit on G5s as they were not properly implemented by IBM -for whatever reason. In the now defunct Apple Developer pages on Altivec, use of DST instructions was discouraged and the dcbz/dcbt ones were suggested instead, I can look it up in the Power ISA manual to see what the exact problem is but later today.

@K-L

I am not using any "special" Altivec instructions -in particular the problematic dst ones- which exist only on G4s, so the code should work on G5s as well, but the code is not tested yet on a 64-bit powerpc environment, so I am unsure it it will work/compile. OTOH, I understand that AmigaOS does not operate in 64-bit (yet?).

@all

(sortof)Update: I'm not at home these days for both work (and the upcoming elections), and while i do have my powerbook with me to commit the remaining patches, time is very short, I will try to commit them during the weekend, but if that doesn't succeed I'll do that on Tuesday when I return home. I still hold by my promise to work on other components of ffmpeg that I have found to be worth optimizing, regardless of the bounty.

Thanks for the understanding.

@tommysammy

It's at https://github.com/markos/FFmpeg

Just finished another small optimization and will do some more commits today.

@tommysammy

21 fps, that's ~15% slower than needed. We got the 4-5% covered, so we need an extra 10% improvement, which is not something trivial, but it's not unheard of either. I'm always saying "there is _always_ room for improvement", but it's unclear how much.

Anyway, I'll post the remaining patches and new numbers soon.

@Deniil

It depends on the codec parameters, and the movie itself and actually it changes within the same movie as well, for example, Prometheus is decoded at ~30fps in the beginning as it's a plain green background with some letters. The more action packed a scene is, the harder it is to compress/decompress, and hence the lower the FPS are.

@zzd10h

what's the current fps on that one? (don't forget that ffmpeg is benchmarking the decoding only, not display itself, so you have extra overhead there). Right now, on that particular movie, the gain is 4%, I expect it can get up to 6% with some more twiddling, but not much more. Otoh, there are other aspects, like ac3/aac decoding which can get optimized as well, or better memory prefetching -as suggested by corto in personal email- and general optimizations.

I'm sorry if that is not sufficient, the fact that my powerpc system is slow does not help the pace of development, I am thinking of getting an cheap old imac g5 to help with that, waiting for a G4 to build stuff -even upgraded with a SATA SSD- does not really help compile times :-/

@all

Here are some benchmarks with the "unpatched" version (as in the one I forked from on github) and mine (until rev 893065a), using 30 second clips (-t 30 on the command line). I have many more patches to apply but I have to clean them up first.



So, conclusions, so far not unsurprisingly even though there are some obvious gains, it's going to be very hard to achieve proper playback on h264 1080p on low end machines. I still have some patches that may give an extra few %, but at least on my system (G4@1Ghz) I don't expect that. Maybe with more optimizations 720p will be playable, but I'm not really hopeful for the 1080p. On the other hand, my machine is a really low end and with a very slow memory bus.

However, I'll keep working on this so regardless of the bounty as it's extremely intriguing, so it can only get better I think :)

I'll be posting updates here, as usual and on my blog soon.

@tommysammy

Thanks!
I am in the process of producing a report with some benchmarks with several videos -apart from the Prometheus. And I also have to clean up more patches and commit them to my tree.

Rest assured, I found plenty of stuff to continue work on Altivec so I'm not going to stop regardless the bounty (for the record I'm at 32/35 hours). Of course, nothing would please me more to continue to work on Altivec on a more permanent basis :)

@Hans

Yes, exactly.

update:

frame= 1656 fps= 15 q=0.0 Lsize=N/A time=00:01:09.40 bitrate=N/A
video:104kB audio:11952kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
bench: utime=108.484s
bench: maxrss=36748kB

@zzd10h

First, I'll submit patches to ffmpeg (actually to libav as well, since they're similar projects and this codebase is more or less common). Afterwards, and I assume they will be accepted, maybe with minor fixes/modifications, they'll propagate to the respective projects that use them. In this particular case, the OS4 projects might want to pull the patches directly and not wait for upstream.

@all

Another progress update.

Optimized some of the pred16x16 functions and some others, and I managed to get an extra fps (up to 14 on my G4@1Ghz) :)
Total runtime from 121secs to ~114s.

These patches have not been committed yet, want to clean them up a bit first, but I double and triple checked them and they produce correct results. Will probably commit the remaining patches during the weekend.

Still have a lot of stuff to do left (and most likely I will do that past the bounty hours, just because I like coding Altivec :). For that matter, I've spent ~18hours so far.

In my todo list:
AAC
AC3
FLAC

and in general optimizations where I see room for.

so, report 1:

first I added -fno-inline in the compile flags to get inlined functions also appear in the perf reports, from the list, I found one that was at first trivial to optimize and wanted to do it just to see the impact -if any. Proved to be non-trivial, mostly because of alignment (if data was aligned it would be 3x faster, but it wasn't).

So, with the perf run:



Running time/fps didn't change, both took 121-125secs. To be honest, I didn't expect a big change as it doesn't get called so often, so nothing to get excited about just yet, but testing with perf I was able to measure the instruction from



to



This took a total of 4 hours so far (I'm excluding the initial setup/code traversal). I have some better candidates to work on, so a 2nd update will come soon.

Code can be found here:

https://github.com/markos/FFmpeg/commi ... 2a11bd1e2fbb9e9c0af697d8a

Edit: any idea why \[code\] tag takes so much space?

@gerograph

edited:
Just to be clear, there is no rush on my part, I've already sent tommysammy the receipt as promised, but I agree that it would appear as bad manners on my behalf to expect to get paid wholly for such a small project in advance (for a bigger/longer project, I would definitely request an advance payment of 20-30%, but this is too small/short a project for that).

In any case, expect progress updates here.

@walkero

Thanks for the instant support :)

@PWP

Ah, sorry, it was in the inbox in the forums, for some reason I didn't have email notification setup here. I'll reply asap :)

edit: Just realized that my profile here uses a non-existent email account, any idea how/who to contact to have my email address changed to a more recent one?

@Raziel

The past days I admit I haven't been very involved with much, mostly due to the holidays, but things will start picking up pace soon, I've done some profiling myself -basically reproduced what corto did here and split some functions to get more fine-grained profiling, but not much more. I think I'll go with optimizing the pred* functions first and see what happens, these are optimized for arm/aarch64/x86 so it's a natural choice to do these for altivec as well.

@PWP

Hello,

Thank you for the support, but I admit I have not received any email yet, thought it was in my spam folder but it isn't perhaps you used the wrong address? (it's markos at freevec dot org).