"Although the binary runs, ffmpeg will produce glitchy videos."
I don't have a machine that supports altivec instructions, but that is what I've been told happens when I send the binary the cross-compiler generates.
In the context of that post, I was describing what happens when I link any program binary (one that uses altivec instructions) with the cross-compiler I built myself from adtools. All I have to do is re-link it on my Sam machine or in zerohero's cross-compiling environment which doesn't have that issue, and then the binary is fine (assuming the code is fine). All of the object .o files are fine. It's something in the linking stage.
If you took my post to mean that ffmpeg 2.6.1 (official tree) with altivec produces glitchy videos, then you're mistaken. I'm only talking about when I *link* on the cross-compiler, which I didn't do for the binaries on OS4Depot. If the altivec builds on OS4Depot produce glitchy video, then I'm unaware of that, and probably can't do anything about that.
Edit: Made 1st paragraph clearer.
Edited by MickJT on 2015/6/26 5:44:34 Edited by MickJT on 2015/6/26 14:40:15
The green color bug comes with 2.5 (Feanor has modified), and 2.6.3 (that Feanor has not modified), what I found out its part of h264 AltiVec optimized routines, I have traced the bug back to two files, that has AltiVec optimization. For now I have disabled all optimization on this two files, I will next try to enable some of it, and see if I can find function's that has bugs. Once It's located I will most likely isolate the problem, by disable code that is not working.
This is time consuming, because I need to modify files, and do test compiles, modify files again, new test compiles and so on, until problems go away, or come back.
Green color bug is not an issue produced by me or Feanor, no one is to blame. As for GCC being the problem, me nor Feanor thinks it is to blame.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
Probably stupid but isn't it possible to add a test to the code to check the color generated and if it's green then stop and search backward from there? (with a known video file that cause the problem)
Sometimes it is easier to ask questions, and then there is answer.
However, the short answer is that stack traces only work when you have branches, jump from one sub routine to another. At last branch, you have the crash; you can look at previews function calls before the crash, so you know pretty match where and way,
When you do not have crash, the program continues, and so you do not know where and way, things go bad, so you most look at problem from the other end.
As for testes is only useful, if the all the smaller routines are tested after a specification, because once you have the end result you do not know way.
Even then, there might be something that have expected behavior and none expected behavior, so again you might end up being clueless.
I don't know how common it is write tests for C programs, but if you do, it’s a good idea to start when you start writing the project, not after you have generated years of code / work.
Edited by LiveForIt on 2015/6/26 20:15:11 Edited by LiveForIt on 2015/6/26 20:16:37 Edited by LiveForIt on 2015/6/26 20:35:45
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
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:
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.
On my end, I have found the overloaded functions that produce the green bug; this information was shared with Feanor, yesterday.
As I pointed out before I do not think the green bug has anything to do with changes Feanor has made, the bug was found in 2.6.3 as well, as 2.5 that Feanor is working on.
So if anyone won't to look at the problem you can, there are not that many operating systems that care about PowerPC anymore, with Apple gone, we can't expect things to get fixed automatically in the future by Linux / Apple developers.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.