Any altivec experts? (H.264 codec)

@tommysammy

And no more reply by mail ?

Feanor was logged in here on the 24th of March.
Don't light the torches or sharpen the pitchforks just yet...

@ddni

sorry, I was not away, nor did I forget my promise. The imac g5 needs some more tinkering, the ssd I bought for it did not work (hint: don't buy SATA3 SSDs for SATA1 macs, they probably don't work, at least not the kingston ones).
Secondly, I wanted to git-sendmail my patches to upstream but I got some build errors due to some changes (hint: libavcodec/dss_sp.c fails to build because of the extensive use of 'vector' keyword (which suprise suprise, is used by altivec datatypes).

I'm sorry for the delay, but I honestly don't see though how/why my patches just can't be used as they are on a slightly older upstream release. In any case, the stuff that remains to be done is optional AC3/AAC audio decoding, the rest of the patches are right there to be picked from my tree. Why can't you make snapshots? Are the AmigaOS changes so extensive/impossible to be accepted upstream or integrated?

If you want to be more clear, the coding work is already over, the upstreaming work is left to be done and some optional decoding optimizations (AC3/AAC and some other not so vital stuff that I saw). That does not mean that I will not touch it again, I just want a reasonable working environment to use, my powerbook G4 was so loud and slow when compiling that I put it in a storage room, which means I have to go and check the video playback manually everytime. The imac should make this much simpler (which was the reason I got it in teh first place) but the internal disk was slow -hence the attempt to put an SSD in it- and the fans were extremely loud -I think I've somehow fixed that now after cleaning its internals from the tons of dust in the fans.

These are not excuses, just the actual reasons, it's hard to code with a slow jet engine next to your ears. I'm sorry it's taking that long, I only have the weekends nowadays to work on this due to extra work on dayjob, but with the aforementioned problems with the mac, it just got delayed too long.

Also a final note: I'm going to send my patches upstream asap, but that does not mean they will automatically be accepted, at least not without being reviewed, and I definitely have no control over that process. So I cannot tell when these will appear upstream, so there really is no reason that you should wait for a version to appear for testing before these get upstreamed properly.

Sorry for the delay, I hope you understand.

Note: BTW, mail is definitely faster to 'ping' me. I do login automatically, but with 70 tabs open, it's easy to overlook something. I would also have no problem giving to some few people my skype/jabber ids, or even talking on IRC (Both on OFTC and Freenode as markos/markos_ resp.), I certainly am not hiding.

@feanor
thanks
the reason why i am asking is that LiveforIt start only a new MPlayer version, when you say you have finished it.
We want waste our time to create for every small optimization a new MPlayer version.
Please upload the last otimizations, so LiveforIt can start the work.
If you do some more otimizations from time to time, we can have a look at it and superior if we create a new MPlayer version from time to time.
Now it is important to make a cut and finish it.

@tommysammy

Quote:

If you read what he typed, he has already done so. You just need to download from his repository and apply the patches.

Or you can wait for the upstream process to finish which is not in feanors control.

Is LiveForIt even ready to start working himself?

@LiveForIt
Have you started compiling it ?

@TommySammy

Any news or do it need another bounty for the mplayer integration ?

@zzd10h

We have to wait for Liveforit. At moment i can do nothing.

@all

I have spoken with Liveforit. And he can do it, but would like some money for the work. So i'm guessing a bounty will work nicely. As he has no job at the time.
Who would like to donate for this?
I will atleast.

@LiveForIt

How much do you want for this work ?

edit : and is this future bounty could include too the support of webm (some webm are distorted under smtube) ?
Thx

Also would be nice if he can fix the remained tickets on Sourceforge .. still a lot of unfixed things

@samo79

I'll donate to a bounty for that.

@feanor

I recently found libjpeg-turbo which is a simd-accelerated version of libjpeg. I don't know, but maybe you could use some of its Altivec code for further j/mpeg acceleration?

It is tremendously fast! Between 2-3 times (200-300%) faster than the original libjpeg for both jpeg encoding and decoding. I'm currently trying to make a jpeg.library out of it, and I emailed Oliver Roberts to make a new WarpDT.jpeg out of it. No response yet though... Seems jpeg.library is not open-source, which is kind of stupid.

@zzd10h

I do not understand compression algorithms, fixing codecs are not some think I know how to do, or how time consuming it is too fix, I have no prior experience fixing codecs, can I replace a codec from a different FFMEG this is possible.

The last fix I did regarding the audio codecs was by replacing FFMEG.

@Samo79 and zzd10h

I think be better to have many small bounties instead of one big one. Its greater risk for me, if everything is bundled into one big bounty.

As I understand it, buntysource might be ideal for this kind of thing.

@zzd10h

How much do you want for this work?

I will expect good chunk, for the time spent, you're basically paying me for not looking for work else where.

I'm looking for ways to make money, not give away my time for free.

I have gave away lots of my time last year, where only 8% donated that will not happen this year.

Last year my motivation was bit different, last year it was impossible to scale video on X1000, well almost impossible, you here able to thanks SDL video output at the cost of CPU power, this made mplayer slow and not so pleasant, and mplayer crashed a lot, this two problems annoyed me. A few more FPS when most videos played well, do not annoy me to the same extent.

At least it does not feel urgent.

@LiveForIt
"I will expect good chunk"
OK, what is a "good chunk" ?

Regarding webm videos, it works well with MickJT SDL MPlayer.
It's the one that I use especially with SMTube because of webm problem.

I know that it's easier to give advice than to effectively code, but maybe that you could ask to MickJT ?

@zzd10h

I expect recompiling mplayer with mew FFMPEG, applying the 64bit fix, somewhere round 1 to 2 weeks of work, with testing, 30000 NOK (typical monthly pay) * 1/4 = 7500 NOK ~ 750 Euro.

Issue 26: Implementing menus in mplayer I think that take around one week so - 750 Euro.
Issue 27: Drag and Drop, (3 days work) - 450 Euro.
Issue 33: Install script, (2 days work) - 300 Euro.
Issue 34: Adding Screenshotdir and EXTPATTERN (2 days work) - 300 Euro.
Issue 36: AmiUpdate support (30 min) - 0 Euro.

Issue 1 and 3 I think that we just close.

I know its not free, but on the upside you get things faster.

Quote:

Ok, we need to revisit this issue after we updated FFMEG again, maybe the problem disappear by itself, it might have been fixed upstream.

After that, we can always ask MikeJT what FFMPEG versions he is using, and maybe retro fit the webm codec.

@LiveForIt taxes included?

@LiveForIt

Thank you for the detailed reply.

"AmiUpdate support (1 days work) - 150 Euro."

@zzd10h

Quote:

Yes, it might take less time than a day, maybe 3 hours, but normally you mess around with things, time fly, I have not done any AmiUpdate stuff before, I expect need to read about it, investigate other amiupdate scripts etc.