@TSK

Quote:

Give me some time to prepare something.

Quote:

No, not at this time. But, there's another bounty for them, however rather than a "companion library" i want to create a new library from scratch which will contain everything.


@tommysammy

Quote:

Well, if you get the same issue while using 51.52 then yes, isn't my lib

Quote:

Can you please post a couple of screenshots, one by using 51.52 and the other with 53.1?

Also, may do you want to use the debug version in case there's something related printed on the console.

The Avatar movie is something we used for benchmarks since the starting scene is a good one for such purpose, but neither mrod nor me noticed wrong colors. In the other hand, it seems you're the first X1000 user testing the new lib :-/

Quote:

mrod............hello?

53.1 does *not* uses the libs/codecs from libs:avcodecs (eg, it does not even tries to open them because otherwise it'll just crash..)

Hence, it's safe to keep them as-is for people who want to test this new lib while keeping the old around (what is recommended for now)



Edit:

Quote:

Hmm, I don't think so.

Sure, convert them to MPEG or AVI (i.e MPEG-4)

And yes, if you want some new format supported on the player you should request it to him.

These videos uses the AVC codec, which effectively dvp does not seems to support.

keepvid: It appears you do not have Java installed....

How big are those videos? or get a 10 seconds video from youtube, keepvid it, and send it to me - if you don't mind? :)

I don't think these FLV movies are supported by DVP, Sure Cobra can provide more in deep details.

But, just in case let me do a test using that keepvid service.

@spotUP:

Just remove/rename the old lib, i used the following script:



No need to touch the libs:avcodecs folder since the new lib does not uses it.

BTW, I wanted to upload the archive name as "avcodec-53.1.lha" since there will be more than one lib (at least three) and i don't want to replace the old libs, but the admin renamed the archive. Also, the readme file through the web got all messed up - who should i contact about these issues?

Hello all,

The first preliminary updated version of avcodec.library has been uploaded to os4depot. This should be considered a BETA version, basically because it's based on a GIT snapshot - further details on the Readme file included in the archive.

Next version will be based on the last stable libavcodec as of time of this write.

Please note we've tested the lib under 440s, hence some feedback from other machines is highly welcome.

Thank you all for your donations.

Quote:

Well, i think we can add some background about the project and the unpaved road we were following.

Things started on March 2011, when mrod contacted me about the possibility of updating avcodec, and everyone who knows mrod is aware of how insistent he is ;) I agreed to take a look at it, and started trying to get the thing updated to latest lavc core, it started as something fun to do - after all my previous experience with amigift helped a lot, where i had to port a dozen of Linux's *.so as native amigaos libs/plugins - then the fun part temporarily became a tedious thing... while some codecs worked fine with minimum effort, most didn't worked at all or produced weird results, the incompatibility manifest took place... we found that dvp was using some hardcoded enums for codec definition and pixel format which broke our expectatives of a nice port (that was our thought at the time, things became worse later..) So... after implementing some "crazy stuff" to get 2008's definitions and forward to 2011's ones we got back on the right road... not for so long, since apart from the fact the ffmpeg team removed from their API the decode audio/video functions the original avcodec.library was using, we found the decoding of audio implemented on a hopefully backward-compatible way wasn't working properly... that was mostly noticeable with AC3 and some MPEGs, a kick on the balls literally since these are the most common formats as used eg on DVDs.

At this step, around two months later since we've started working on it (several hours per day, if you ask me) we got stuck... mainly due the development road we were following, since i lacked an os4 machine at the time i was cross-compiling the lib from Linux (OpenSUSE + KDevelop, i love them ;) and sending it back to mrod/elwood for the tests, which became quite frustrating to track down that audio decoding issue (changing a few lines of code and sending the lib to test, and so on and so on) Fortunately, a couple of months ago i've got an os4 machine from the loaner program, and i want to take this opportunity to thanks Troels and everyone else involved for providing my first ever os4 hardware :)

So... with a Sam at my hands things restarted well, the audio issue got properly fixed and hundred of tests made to try to achieve faster video decoding as well, with something we got nuts was with our tests with AVI (MPEG-4) and VOB/DVDs (MPEG-2) while we can achieve a "faster decoding" (aka, less cpu usage) with one of them, that involves the other being slower/weird... our thoughts as a joke was that in the worst case we can release two versions of the same lib, being one specifically for DVDs which would play them better than before, however we reached some point where the "distance" between them isn't too worse and still playing those formats/codecs better than before (still testing, though)

Our current Beta is version 53.1 based on lavc 53.0 from April 2011 - Depending on the bounty results we tend to keep the lib updated, being the next version based on the recently released 0.9.1 stable branch (53.1 is based on a GIT snapshot)

We have to mention we got a little disappointed with the nice way the ffmpeg ppl breaks their API... since its current stable version is already incompatible with the branch we've used for 53.1 and therefore we'll need to reinvent the wheel... looks like they have made more [incompatible] changes in the last year than from the 2008's branch to the 2011 used, anybody interested can check the diffs here.

Well, thank you all sincerely for supporting this bounty.

Yesterday i've compiled the adtools trunk to get V2 sobjs sup, and hundred of compiler warnings apart (on the first steps only, regarding some gcc macro iirc), the only issue i've noticed is that the libs libstdc++ libsupc++ libssp etc are now placed into a different directory than on the zh cross-compiler.

Trunk: /usr/local/amiga/ppc-amigaos/lib

ZH: /usr/local/amiga/lib/gcc/ppc-amigaos/4.2.4/newlib/lib

However, the new compiler still seems to look for the libs at the zh path, so i just created symlinks.

I've compiled a .so before noticing that and it was linked without using libgcc.so (and reporting no errors), then tried to compile a C++ program (statically linked) and noticed the mixed libs due i get the same undefined references to sjlj functions...

but still using the right libs, i was forced to specify -lgcc_eh (thx afxgroup ;), otherwise it does not link. It's really like that for the last trunk or i might have something wrong somewhere?

Anyhow, despite those little "issues", I really recommend everybody to build his own cross-compiler, it's really easy, well...it compiles OOTB! (great job adtools guys)

@emeck

4.4.3 is broken, use 4.2.4 instead.

@xenic

Quote:

There are three binaries:

1) "wget" (m68k) 1.401Kb statically linked using OpenSSL 1.0.0a

2) "wget-NoSSL" (m68k) 336Kb

3) "wget-OS4" 455Kb dynamically linked using AmiSSL.

all of them are stripped.