Any altivec experts? (H.264 codec)

Hi
I suppose that stride is a constant so (say) 3*stride will generate a constant too so no problem

BTW if stride is a constant it should better be written as STRIDE

Alain

@thellier

it's not a constant but a function parameter unfortunately so it can't be entirely precalculated -ie outside the function running scope.

@all

update: ok, bug fixed, moving on.

@feanor

Thanks
Is it now possible to compile a new ffmpeg version for testing?

@tommysammy

give me a few hours to do a few more tests, and I'll let you know.

@feanor
Ok no problem

@all

ok, bug fixed, but I'm in the process of reorganizing the patches in a separate branch. For easier integration to upstream. Also, the bug I've fixed, even though I've eliminated the branches resulted in slower code, because I included initialization code inside the loop, I'll do a refactor to make it work properly -for those that are interested it's about this commit here:

https://github.com/markos/FFmpeg/commi ... 72ad5f90eaa9f661436f6e9ec

@feanor

looking good

@feanor

I wish I could read (and write!) Altivec code. I have a few routines I probably could speed up a lot using Altivec.

Btw. Can't wait to test the new mplayer, or ffmpeg for video conversion as well, with these improvements, when its ready

@feanor

Many thanks

Is it now possible to compile a first ffmpeg testversion or take use for LiveforitMplayer?

@tommysammy

I've refactored some patches and put everything in this branch:

https://github.com/markos/FFmpeg/tree/feature/morealtivec

Now, I'm only including here patches that are tested to pass the tests both via "make fate" and by visual testing (no artifacts produced). So, at any moment, feel free to pull from this branch and produce a test version. In due time, I'll start sending the patches upstream, but I'm still occupied in the audio stuff at the moment.

@tommysammy

I have uploaded latest liveforit-mplayer to google code, I fear having to apply my 64bit off_t fix again, I really wish Solie fix it in the SDK, it was lot of work the first time.

@LiveForIt
Can you create a new LiveforitMPlayer version with the optimization from Markos?

@tommysammy

Yes someone has to replace FFPMEG that is built into mplayer, but also apply the large file support fix I have done in the one inside mplayer now.

@LiveForIt

If you do it, i will donate a few $$$ for you.

@LiveForIt
I need the e-mail address from Michael Trebilcock
Can somebody send me this address via PN ?

Sent.

Edit: Not sure how I could help. My ffmpeg port doesn't have any large file tweak (and is probably broken in that regard). LiveForIt would have to tell me what to do, not the other way around. I'd just take the current source, delete the existing ffmpeg directory, drop in the new ffmpeg repo and see what happens.

@all

another update:

past days, I optimized a couple more functions in the audiodsp.c, fixed a bug in float dsp (and found another one that manifests only in realaudio decoding for some reason), and am now working in AAC decoding optimizations (and ac3 after that).

@feanor
Thank you for your extra work

Really curious to test that "new" mplayer when available :)

@LiveForIt

-I noticed that your mplayer in os4depot was slower than mplayer from afxgroup that I still use on my g4 Pegasos2....can you do anything from that?

Thank you