@broadblues

Thank you for understanding, I have asked my accountant about this and am awaiting a reply on the matter. As a freelancer I do have to fill periodic VAT paperwork, including intra-EU invoicing, which is more complicated than usual but not that much, and it's hard for me not to invoice services properly -and the fines are pretty high if I don't. I actually live on this, not just Altivec/SIMD work -I admit it's not 100% of my time as I would like- but software development in general. It's quite common for me to work with companies abroad and usually -at least within the EU- there is no problem, but I've never had to provide my services to individuals so far, which complicates things a bit, but I trust to find a solution soon. But as others have already pointed, this is off-topic and I won't bother the list again until a solution has been found,

I've just started looking at the code and in the next days I'll be posting updates here. I will try my best to prove worthy of everyone's trust and I hope the result will be to your satisfaction.

@zzd10h

Sure I could do that, but as I work as a freelancer already, invoicing for my services is something I do anyway and thought people would take it for granted.

@pvanni

Intra-EU invoicing needs valid VAT # I think, as invoices are registered to IntraStat/VIES service for cross checks, but I'm going to ask my accountant nevertheless.

@Hans

Quote:

I remember some years ago I asked just this thing to my accountant and he had to call the tax agency, and some fellow accountants, on whether one can deduct VAT from services to a US company. He was definitely confused at first but eventually it turned out that services are different from products -for which you can go to customs and collect the extra VAT paid. There is supposed to be some different status quo in this case -he did refer to some laws, I can ask if you like- but the end result was that I had to include VAT in the invoice for s/w development services rendered to a US company.
I also think that this whole situation is hellishly confusing and overcomplicated, but since I got the final ack from my accountant, I have no choice but to follow his suggestion.

@tommysammy

As I said in a private message, I am pretty sure I have to invoice a legal entity, and not an individual, so that means having a VAT # is a must. Maybe you could find some Amiga-related company that could accept the invoice? Furthermore, I will send the invoice, when I have completed the number of hours promised and when some results can be shown and replicated by others, but not before. It's not going to take long though, I hope to be done sometime within the next 10 days or so.

@Hans

(Note: I'm talking about services not products, I have no idea what the status is there, but I do know for a fact that it's an entirely different and more complex game).

I've been invoicing companies in the US/EU since 2004, for software development services rendered and I've never had to include VAT inside the EU (mostly Germany and UK), but I did have to include it in the price for US based companies -as I did have to pay it locally in the end. I think this falls in the category of double-taxation avoidance treaties between the countries, I think Greece/USA have been signed only very recently. It's different between every country it seems, the only common ground is VAT exemption between EU countries. For that matter, I have no idea what the case would be if I had to invoice a NZ-based company, when in doubt, I just ask my accountant who definitely knows more than me in such matters :)

@tommysammy

what you started is actually a fundraiser, which is not directly tied to a specific bounty, I've requested 805 EUR for 35 hours, VAT is not included for invoices within the EU (but would be included if for example invoicing a US company), however any extra cash you could keep for further bounties, even not related to the mplayer bounty, wherever you see fit.

I will start asap, and will post regular updates and the commit logs here.

@all

I think I can start now since the bounty is going surprising well, but just to avoid any wasted time, we're talking about mplayer1 (not mplayer2) and ffmpeg not libav, right? Though, it should be easy to contribute the code to both projects, I'd rather start with the needed project.

@tommysammy

I see you did that as a fundraiser, that's a bit more generic than a specific bounty issue, but if it works for you guys, it's fine. Just one comment:

"it is risk for all Altivec owners,no guarantee of a speed advantage"

That's imprecise, a speed advantage will most likely be achieved, but it's unclear just how much.

@Tuxedo

Thank you for your kind words, I really appreciate it, but I have to be modest. I consider myself a decent developer, with enough skills to cope with many tasks (not all, and kernel/firmware stuff is where I draw the line, I just don't have the necessary experience), maybe my 'advantage' is that I *really* like SIMD stuff in general to have devoted literally thousands of hours in this. Now with regards to getting a new Amiga system in exchange for my services, as much as I would like that, I'm pretty sure my wife would object to that as that doesn't really help to feed my family, as I'm sure many of you already know. :)

I have already too many projects I'm working for free, like Debian/armhf, Eigen(where I maintain both NEON and Altivec/VSX ports), working on a new portable SIMD library -yes, I know there are many, but I'm working on some features not found in others, at least I hope it works that way- and writing a SIMD book (that of course covers Altivec), and have a day job on the side (that unfortunately does not include SIMD in the slightest). If I'm going to justify allocating yet more hours out of my already pressed schedule, then I'll have to make sure that it helps my family, otherwise I'm just not going to do it.

Regarding mplayer itself, I think it's prudent to take it in small steps. Let's see if/how this works out, if it satisfies the requirements people have set, if there is more room for improvement, etc. Usually, there is *always* more room for more optimizations, but it has to justify the means.

@Hans

Yeah I know, got bitten by that already, I still think it's worth it though and intend to add at least one of my own projects there in the future.

@Hans

I know, I've created one in the past, the thing is that this case is not a full blown vectorization effort to justify a kickstarter project, that is, we're not really vectorizing a full codec (like x265 for example), but only adding a few optimizations where needed to get the extra % of performance.

Also, with a kickstarter there is always a risk of never gathering the necessary funds, but also not receiving them. I think a bounty is safer as you can always request your money back if the bounty fails (at least I've done it before). As a suggestion, here is a possible workflow on bountysource:

1) forking ffmpeg on github
2) attaching it to bountysource, by installing the relevant plugin on the github project (one can login to bountysource by their github account)
3) create the particular tickets on github (they appear automatically on bountysource)
4) I can state that I will work on this particular (or more) tickets for the requested amount
5) people can donate to this particular tickets
6) when done, I can post the patch inside the ticket itself or even do a pull request from my own tree and claim the bounty
7) people can review it and when happy, they can accept the claim

that's it. I've already done this before on bountysource (I've done the VSX port of Eigen, which was coincidentally an IBM bounty on bountysource, and I was already 70% done when I discovered that so it was easy for me :)

@corto

Quote:

I have a Powerbook 12" G4@1Ghz, and both a ppc64 and a ppc64le VM -that are VSX enabled.

@Hans

I don't think it's a good idea for me to handle the bounty personally.

@Hans

Well, to be completely honest, I did ask a good friend of mine, an altivec/libav guru (Luca Barbato/lu_zero if anyone knows him), and he said he can't right now quantify the performance impact these functions have, but he did say that porting them would definitely help. Also, From what I saw, qpel altivec functions exist, at least I can see *_h264_qpel16_*_lowpass_altivec in libavcodec/ppc/h264qpel.c. Now, it may be possible that not all functions are implemented, but I can't really say that without really messing with the code.

@tommysammy

Well, it obviously cannot be me :)

@all

Ok, I took a close look the past days at the ffmpeg codebase, basically the altivec and arm(neon) trees. My first impression was that the altivec port was seriously lacking as there were far fewer files. However, a closer look showed that the functions were implemented but inside the .c files, and not separately as happens with the neon port. Still, not all were implemented, in particular I could not find altivec code for the ff_pred16x16_vert_* type of functions (found in libavcodec/arm/h264pred_init_arm.c). So these would be the ones I would tackle first.

I suggest to allocate ~35 hours initially for this task alone, and take a look at it again -note that it might not mean an actual week, as I am already working on a day job. Since you asked me for a public quote, my rate usually is 30EUR/hour, but as I promised and since working on Altivec is a pleasure, I'm willing to do a discount, at 23EUR/hour (if invoicing within the EU, VAT will be deducted, and I would have to invoice someone for that amount). So, in total 805EUR.

So, what do you guys think?

@Raziel

Quote:

Well, yes and no, it's mostly the same, but some things are different between eg. a G4 (aka MPC74xx) and a G5 (aka PPC970), in general the altivec unit in the G4-class is more powerful, but the advantages of the G5 (clock speed, better memory bandwidth, etc) eliminate that. Differences are bigger in newer cores like the e6500 or in recent IBM cores like the Power6 onwards.

But we don't care about these cases, AFAIU, focus is on 32-bit big endian altivec, but I'll make it 64-bit safe ofc, and if possible, be/le agnostic so that it can run on a 64-bit LE OS as well, such as ppc64le. That's free of charge. I'll only charge for the 32-bit BE initial work.

@tommysammy

I don't have an X1000 so I can't really benchmark, I need a lower base of reference. I have a G4@1Ghz so I can use that, and I have access to some Power7/8 VMs with VSX, but that's a different beast.

@tommysammy

That's a bit vague. What's the base hardware and what kind of h264 video would you consider as minimum for playback? Eg. even with full altivec, I guess getting 1080p 60fps streams on a G4@800Mhz is going to be a bit over-optimistic to expect.
Plus, getting the 90% of the optimizations is going to be probably "easy", but if one wants to get the full deal, it's not uncommon to spend exponentially more time to get the rest done, most likely because you have to resort to heavily tuned asm, instead of C intrinsics, etc.

What is the expected outcome and what would make people accept such a challenge as solved?

Eg. pick a video stream (bigbuckbunny?) and a base hardware spec and expect that to work with no frames dropped?

@all,

I was away for a few days for a business trip, I will look at the code for a few days and will let you know how long it would take to bring it in parallel to eg. arm or x86 levels, at least. Would that interest you? Should I post the quote here in public, or would you prefer it in private first? At the very latest I expect by Monday to have a clear idea of what has to be done.