Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
87 user(s) are online (52 user(s) are browsing Forums)

Members: 1
Guests: 86

Futaura, more...

Headlines

Forum Index


Board index » All Posts (feanor)




Re: Any altivec experts? (H.264 codec)
Just popping in
Just popping in


@samo79

I hope so, in the next days, assuming real life issues are solved soon, but yes, it's something I want/need to do.

Go to top


Re: Any altivec experts? (H.264 codec)
Just popping in
Just popping in


@all

So, I just replayed my patches on top of ffmpeg master (they can be found again in https://github.com/markos/FFmpeg) and tried all the videos I had, including the one pointed to by people here.

Testing framerate was done by the usual ffmpeg -benchmark line:

$ ffmpeg -cpuflags altivec -benchmark -i <file> -t 30 -f null /dev/null

and playback was done just by running ffplay

All this on an imac G5 running Debian Jessie Linux (no video acceleration, so just software decoding). Compilation was done remotely on a 16-core Power8 server again running Jessie for speed.

In both cases, I compared ffmpeg upstream master against master with my patches. In no case did I experience green video artifacts.

Benchmarks produced a slight speed increase as I had reported before, not huge, but eg. on the prometheous trailer from 29s to 27s to decode the first 30 seconds, that's within the 5-7% reported originally. Again, playing it with ffplay did not produced any green artifacts.

So, I'm bound to say that whatever bug there is, it's not within the decoder patches, maybe there is another bug in the display routines, and I will try to investigate it further.

Now that I've set up a sane compile environment (compilation on the power8 is *fast*), I expect to submit those patches and some other pending audio ones soon.

Thank you for your patience and understanding.

Go to top


Re: Any altivec experts? (H.264 codec)
Just popping in
Just popping in


@all

Sorry, everyone, looking at the forum is not a really productive way to discuss bugs and fixing them.

If anyone really wants to contact me, I suggest some kind of IM (irc, skype, gtalk), with irc the preferred way (I can be reached on freenode/markos_ and oftc/markos (mind the _ !)

Best would be to talk directly with LiveForIt so that I can reproduce the bug at least on the ffmpeg side.

Even though I leave the forum open in my browser, I do *not* look at it all the time.

Go to top


Re: Any altivec experts? (H.264 codec)
Just popping in
Just popping in


@zzd10h

I had seen it (the corruption that is) in some videos as well when I was testing the patches, I always ran the regression tests to make sure they passed but it's possible the tests did not cover all corner cases. Could you point to some online videos that I could test to see which patch is the culprit in this case?


Go to top


Re: Any altivec experts? (H.264 codec)
Just popping in
Just popping in


@kas1e

In that case, and if there are specific bugs to solve, why not do a separate bounty per task/bug/feature? Easier to track that way and you can be sure that the payment will only take place when something is completed.

Go to top


Re: Any altivec experts? (H.264 codec)
Just popping in
Just popping in


@kas1e

May I assume that you are not a programmer? :P

This is completely impossible to achieve. Not nearly, but 100% impossible, there is no such thing as bug-free software. Period. The closest thing is to get most bugs fixed and a well-behaving application in most circumstances. But not 100% of them. And also bug fixing sometimes takes longer than actual development, esp in long-standing, hard-to-track bugs, so keep that in mind when asking for the bugs to be fixed for free.

Same for the bounty transfer, you're basically paying for someone's time not paying him to produce finished software (time-and-material contract vs complete project delivery). In the latter case, there is a reason many companies charge a hell of a lot more since they have to account for bug-fixing period, and even then it's easy to go off-schedule.

"Unfinished stuff for which we all pay": you just described pretty much all of proprietary software.

Go to top


Re: Any altivec experts? (H.264 codec)
Just popping in
Just popping in


@all

Firstly, I am not laughing, maybe a bit sad. Secondly, I completely understand LiveForIt's reasons. Coding for free is what I do only for my pet projects, for things that *I* want to code, because I like to, it benefits me some way or because I believe in it. If other people find any of that useful or interesting so much the better, but there is no guarrantee for that. In the case of FOSS, of which I have become part since 1997, I both like it and believe in its open/free nature. A small contribution in a foss project will probably benefit many people but I would still like it for personal reasons mostly. For work, I was lucky to be paid for many years to work on FOSS projects like Debian and others. However that is no longer the case unless there is an exception -as it was in the ffmpeg optimizations- and I charge companies for my services, which is fair and just for both parties.

However, AmigaOS even as superior as it was at its time -and in some aspects still is- decided to stay in the closed/proprietary with no change over the years. The accepted paradigm in this case, at least as I remember it has been shareware. When I still had my Amiga, I was happy to pay for software that I used and I still remember MUI, ProEdit, IBrowse and several others that the names elude me after those years.

Some of those might probably use components that were open source already but so heavily modified/optimized for AmigaOS that the work involved definitely justified the amount paid. I would never consider it unfair just because the main component was open source -heck iirc, the whole TCP/IP stack was based on BSD4.4 at that time.

I don't want to rant, but since AmigaOS is so different that it justifies a week's -or more?- work from LiveForIt -or anyone else for that matter- to get Mplayer to shape and there is no way for someone to just do a recompile, and since current society is hard and people have to work in order to survive, I find the whole discussion unfair to LiveForIt. For that matter, nobody is forcing anyone to play movies on AmigaOS, you could easily load another OS for that. You all *want* to because it is your system of choice. Since there is not enough critical mass like in Linux/Windows to get enough developers to code multiple renditions of a single software on the OS (think VLC/Mplayer/Mplayer2/Totem/FFMPeg/Libav/etc), the way I see it you have 2 choices, either do the integration yourselves, or pay someone else to do it for you. Someone with knowledge and experience of the platform.

(Just said that I don't want to rant and here I am ranting)
To cut the long story short, I agree with LiveForIt, as someone that knows how hard it is to fix bugs in software written by others, he has the right to charge whatever he feels like. Bashing him for having asked for his work to be respected -in monetary form- is unfair. Many of you paid thousands of $/€/* for your hardware, why expect the software to be free? Even in Linux, *ALL* the core components are written by people who are paid to work on them.

Sorry for your time, (and knowing that I still have some remaining code to commit and some patches to send upstream, which I have not forgotten).

EDIT: Come to think of it, I don't think it was IBrowse, and maybe it was ProfEdit or Pedit and not ProEdit, but anyway it was a great editor for developers, which I was so glad to have bought, and a great tool for Exec.library optimized replacement functions, still forget its name :)


Edited by feanor on 2015/4/15 23:31:19
Go to top


Re: Any altivec experts? (H.264 codec)
Just popping in
Just popping in


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

Go to top


Re: Any altivec experts? (H.264 codec)
Just popping in
Just popping in


@tommysammy

hi, the imac g5 is not ready yet, it makes too much noise and it makes it unbearable to use, I still want to finish the AC3/AAC audio dsp functions and finetune it a bit, but in the meantime I want to send the patches upstream, I'll start doing that this weekend and Liveforit can get the source from upstream instead if he prefers. Sorry for the delay, the past couple of weeks have been very busy, the fact that the imac g5's fans make so much noise didn't make it any better. As soon as I started compiling stuff the thing sounded like I had an jet plane on my desk (it's one of the original 17" imacs).

Go to top


Re: Any altivec experts? (H.264 codec)
Just popping in
Just popping in


@all

Just finished setting up the g5, basically, install debian jessie on it, had some problems as nouveau doesn't want to work with acceleration on, so had to disable it. I'll setup a dev environment with ffmpeg on it and start tests. This has the bonus that it's much closer to the performance of the A1000 cpu rather than my old G4.

Go to top


Re: Any altivec experts? (H.264 codec)
Just popping in
Just popping in


@ddni

oh, I definitely have an interest in AmigaOS (I grew up with it!), but sadly, I have little experience programming in it (last time I coded in AmigaOS was in 1996), and the past 20 years I've been programming exclusively for Linux OSes, and am an OSS advocate :)

Go to top


Re: Any altivec experts? (H.264 codec)
Just popping in
Just popping in


@all

Just FYI, I just got myself a used imac G5 from a fellow developer, so that means faster development and shorter compile times, I had to wait a long time between compiles and tests everytime my chagnes triggered a full rebuild. So, the poor powerbook can rest soon :)

Go to top


Re: Any altivec experts? (H.264 codec)
Just popping in
Just popping in


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

Go to top


Re: Any altivec experts? (H.264 codec)
Just popping in
Just popping in


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

Go to top


Re: Any altivec experts? (H.264 codec)
Just popping in
Just popping in


@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

Go to top


Re: Any altivec experts? (H.264 codec)
Just popping in
Just popping in


@tommysammy

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

Go to top


Re: Any altivec experts? (H.264 codec)
Just popping in
Just popping in


@all

update: ok, bug fixed, moving on.

Go to top


Re: Any altivec experts? (H.264 codec)
Just popping in
Just popping in


@thellier

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

Go to top


Re: Any altivec experts? (H.264 codec)
Just popping in
Just popping in


@Deniil

asm output of the i*stride is of the form:

mulli r12,r4,7

which produces 7*stride product and puts it in r12. Later on,

stvx v0, 0, r3 (so 0*stride properly gets eliminated)
...
stvx v0,r12,r3


Go to top


Re: Any altivec experts? (H.264 codec)
Just popping in
Just popping in


@Deniil

in my experience, the more branches you eliminate the better, code can be fully decoded in the pipeline and the compiler usually does a pretty good job of scheduling the instructions to minimize stalls, etc. Plus in case of small loops (this is after all a very small loop), there is no reason not to unroll, as we have plenty of registers to use. What I'm undecided is whether I should just increase src += stride or use the i*stride form. But looking at the asm output, I'm guessing this is a better form, as the src += creates a dependency for each store, whereas the i*stride steps can be precalculated and just used when needed.

Go to top



TopTop
(1) 2 3 4 »




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project