@Srtest

There's a possibility of some seek() stuff I need to change.

Do you have a link to the exact file you are trying to play? Big Buck Bunny. Should be a freely available link somewhere? Also if you an md5 hash of the file, that'd be great so I can know that I'll be be trying the very same one.

Edit: I tried the 1920x1080 .avi torrent from https://peach.blender.org/download/ and I don't get seek errors here.

@samo79

I didn't start from LiveForIt's latest version. I started fresh from the official 1.3.0 source, then merged in changes from LiveForIt's repo and other sources bit by bit. My plan was originally to overwrite afxgroup's build, and I had permission to, but others wanted it kept for historical preservation, not to mention there's always the possibility of accidental regression of features.

The "TeamTeam" stuff, where exactly are you seeing that? In the GUI itself or on the titlebar of the window when playing a video? Which video output is being used (comp/p96_pip/etc.)? In MPlayer-GUI 1.60, I am seeing "2000-2016 MPlayer Team" at the screen titlebar when the GUI window is active.

Edit: The screenshot option the menu is different because when using filters, the regular screenshot option doesn't capture those differences.

@Tuxedo

Is v1.0 consistently crashing on every run for you, or just sometimes? You mention the new one runs 10% slower so I assume 1.0 doesn't always crash or at least not immediately.

The altivec version in post #1 of this thread disables altivec instructions used by ao_ahi_dev2.c, but shouldn't be slower than LiveForIt-MPlayer 6.5.7 because that didn't use them either as far as I know.

What soundcard are you using, if any? AHI settings/frequency? Curious.

Edit: Clarity.

@Srtest

I'll need something a little more specific than that :) Does it work with the one on OS4Depot? Usually that would be the one with the bug. If you have any shell output that'd be appreciated. I'll check back later, in the meantime, zzZZzzzz.

P.S Try with -vo comp or -vo sdl. Still, shell output if you can grab it. Might be useful to delete/rename the config file or remove quiet=1 from it.

@samo79

By spare output, you just mean the "Have My_Screen" printed to shell? I think would be present in LiveForIt-MPlayer too, right? It's in cgx_common.c. I could remove that line. Is it causing any issues?

@all

If you have an altivec capable machine, please try some .mp4 files using the version on OS4Depot. I would like to know if the altivec build on OS4Depot crashes sporadically and if the build in post #1 fixes it.

1.0.1 released on OS4Depot:

* Disabled experimental AHI code that was freezing some machines
* Suppressed an error preventing some .avis playing with vo_comp_yuv/yuv2
* Fixed some path issues preventing OSD menus from working
* P96_PIP: Fixed issue causing some videos to play distorted
* P96_PIP: Remember window position when returning from fullscreen
* Added "Stay on Top" functionality for all video outputs
* Change keyboard shortcut for "Load File". Conflicted with "Loop".
* Cosmetic tweaks to the About window.
* Disabled some debug output that was printing to shell


--- Original post below ---

Hello,

It's just turned Christmas day here in my timezone and I've uploaded a new MPlayer build to OS4Depot. Naturally, there's already been a bug report Seeing as I'm going to be unavailable most of the day, if any of you with altivec capable machines are experiencing lockups or crashes, please try this binary and report back here, and I will check on it as soon as I have time. Keep in mind my programming knowledge is extremely limited for C and I probably can't fulfill feature requests.

(Links removed)

Here's a working MUI version:

https://www.sendspace.com/file/3ldh83

I got it to work by changing AllocBitMap to p96AllocBitMap, removing the use of friend_bitmap and adding a hardcoded colour format. Seems to work fine on 16/24/32 screens. I'm sure there's a better way, but at least the system doesn't freeze anymore. The MUI version is faster.

@AmigaBlitter

Quote:

Well, I tried, but haven't succeed yet. The MUI version works before OS4.1 Update 1 (I hadn't yet updated my Sam440). The function call that freezes the system is p96BitMapLock(), part of Picasso96API.library. I don't think I'm skilled enough to re-write it to use graphics.library, even though it's probably simple to do for someone who knows what they're doing. That being said, a deprecated API or not, you'd still expect it to work.

The SDL2 version on the other hand is working OK, insofar as it functions properly and isn't crashing. It's slow, but I don't have the means anymore (without downgrading the OS) to compare MUI vs SDL2, and I'd never tried running a game on the MUI version before I updated the OS.

Anyone desperate for something to download & try can try this SDL2 build here: https://www.sendspace.com/file/tkcdws

But keep in mind, it could be so slow it's unusable. You'll still need all the data files from a full release. You can use -sdl2renderer <renderer> to choose between compositing, software and opengl. You can press F12 to bring up a menu.

Edit: I've managed to get the MUI version working, still using P96 functions. I'll upload a binary later on.

It's not ready for that yet. It's the first time I've used VICE on OS4 and it's very slow (unusable on my Sam Flex). I don't know if other versions are faster.

@AmigaBlitter

With the symlink in place, export PATH=$PATH:~/adtools/bin is probably all you need. Although there's that rare occasion when a configure script can't find something in /SDK/local/newlib/bin even when you use --prefix, so that can be added too.

You might need the latest YAM (development version) and latest AmiSSL v4.

https://yam.ch/downloads
https://github.com/jens-maus/amissl/releases

I logged into AmigaBlitter's computer remotely and fixed it up.

It all seemed to be related to file permissions. If you use sudo in places where it's not needed, it might extract or copy files fine but with root permissions only. A few uses of chown and chmod here and there and it's all sorted :)

One thing that's interesting with the "Windows Subsystem for Linux" (isn't that backwards?) is that although I could see the directory structure in %LOCALAPPDATA%\lxss, anything I copied in the seemingly correct locations were not visible in the bash terminal. Copying the files from /mnt/c using the bash terminal worked fine.

Relevant:

https://superuser.com/questions/108396 ... g-files-outside-of-ubuntu
https://blogs.msdn.microsoft.com/comma ... g-windows-apps-and-tools/
https://blogs.msdn.microsoft.com/wsl/2 ... /wsl-file-system-support/

@Raziel

Did you mean CFLAGS? -fexceptions is recognized as an option on the 3 versions I tested, 4.2.4, 5.4.0 and 6.1.0. Whether it actually works or not, I have no idea.

Are you statically linking? I've only had C++ exceptions work properly with static libs (see bottom of post #25).

Ah look an old thread! http://www.amiga.org/forums/showthread.php?t=14416

Glad you got it sorted :)

Locale preferences?

@Deniil

Check your private messages.

@broadblues

Quote:

I'm still churning out binaries and having them tested by a couple of people. Then I will.

Quote:

The ones on bintray? That's something I need to test.

Quote:

I'll keep that in mind next time I need to build something natively. Thanks.

@corto

I'll give a full but brief story.

I'm using my own Cygwin x86 build (on a 64bit machine) of gcc 6.1.0 and binutils 2.23.2 from https://github.com/sba1/adtools

Years ago, ffmpeg's configure script started crashing abc-shell. This is before I had a cross-compiling set up. I would use a Linux VM and run the configure script there to generate the Makefile and config.h/.mak, then modify them, transfer those to the Sam440 and build it there.

Then later I set up a cross-compiling environment, using zerohero's adtools (gcc 4.2.4 and binutils 2.18) in a Linux VM. Worked fine.

Then I started to build adtools myself from the sourceforge repo, and since then, I've never been able to get anything that uses altivec instructions to work properly. I myself don't have a machine that I run these binaries on, but some friends test them for me.

I tried different branches of gcc & binutils on sourceforge, and all had the same problem. I thought it might be something I was doing, or my compiling environment.

On a whim I decided to transfer the whole directory structure of ffmpeg to my Sam440ep-Flex, keeping all the already compiled .o/.a files, and just re-link the binaries there, and the people that tested those said it worked! So that's what I did for a while, and then I set up a Cygwin environment and started linking it there, using zerohero's gcc 4.2.4 / binutils 2.18 build.

This time with ffmpeg 3.4, it had been a long time since the last port I did, and I have a different PC now and built adtools from scratch again, and I thought I'd try not re-linking this time. I sent the binary for testing, but obviously that wasn't thorough enough :) When K-L posted this thread, I knew exactly what to do to fix it (I just wanted to rule out a couple of things first).

So now I wanted to track down the root cause. So, knowing that re-linking fixed it, I knew it had to be either linker libs (libgcc/gcc_eh etc.), or the way the binary itself is put together. Turns out to be the latter.

The common denominator amongst ALL of my own adtools builds, including ones using binutils 2.18, is that they're all built after February 2010. At the moment I'm guessing it's revision 335 on sourceforge that did it. The official OS4 SDK and zerohero's port were done prior to that revision.

Using ldscripts/amigaos.x from the official SDK and loading it manually using -Wl,-T /path/to/amigaos.x (otherwise it will use an internal one), I can use binutils 2.23.2 / gcc 6.1.0 again and the altivec instructions work properly again!

I could be wrong about the exact cause. All I know is using the external amigaos.x from the OS4 SDK solves it.

So, according to testing by K-L, a binary I linked with binutils 2.18 and gcc 6.1.0 works fine. gcc 6.1.0 gives some arguments to "collect2" that an older binutils doesn't understand, but I can run it manually with those arguments removed and it works fine.

There were a lot of updates to binutils since 2.18 that might have caused this problem. Does anyone with more knowledge about these sorts of things have any idea which change it might have been?

Maybe this one? https://sourceforge.net/p/adtools/code/335/

That's still 2.18 but that change came after the binutils 2.18 build in the official SDK, and zerohero's port.

Edit: I've sent a build that uses the amigaos.x ldscript from binutils 2.18, but uses binutils 2.23.2 to do the linking using -Wl,-T /path/to/amigaos.x to load the file. Awaiting result!

Edit2: Report is in! That build appears fine.

I'm sending files to K-L. I'm thinking it's either differences in binutils (2.18 at the time of adtools 20090118) or libgcc. Seeing as we're in different timezones and I can't test these myself, it might take a couple of days.

Edit: Appears libgcc.a is not the culprit. More testing tomorrow.

@Raziel

I've had this happen on other versions in the 4.x.x range as well.

@salass00

Quote:

static

All I know is that taking the very same .o/.a files, and the same SDK too, all I have to do is swap out my own adtools I built myself for the one zerohero built on kas1e's mirror, then run "make" to re-link the binaries, and all is fine. And this problem only affects altivec instructions.

So, perhaps libgcc.a? I was also thinking maybe it's something in binutils. I don't really know at this stage, but I'm planning on figuring out exactly what it is. It's happened across multiple versions of adtools/gcc, on Linux and Cygwin, built on different machines. There's nothing special I'm doing to build adtools, pretty much the same as stonecracker's instructions, although I've been doing this for a long time before his post. What I haven't done is tried building the exact 20090118 revision of adtools/gcc.

Maybe in the future I could compare my own adtools build to someone elses, at the same revision, built in the same environment as much as possible, and see if one has the issue and one doesn't.

Edit: Clarity.

Still don't know why it helps to re-link the binaries with older gcc libs (edit: older adtools in general), but whatever works. I'll re-package it in a moment and upload it soon.

Edit: In the queue.