ffmpeg AltiVec on PA6-T

MickJT has just released a new version of ffmpeg (3.4) in the upload section of OS4Depot at the moment.

I've made some tests converting video or audio files to MP3 and the results give a very bad sound qualitry.

Actually only the AltiVec version gives this bad result (on the PA6T, I don"t know on G4). If I use the non Altivec version, the sound is of very good quality.

Others have exprerienced the same behaviour ?

I've Just converted some flac files to mp3 with the altivec version with no problems, PA6T here too.


I used this command in DOpus5:

ffmpeg -i {fu} -vn -acodec libmp3lame -b:a 192k {f}.mp3

@K-L

I have no way of testing altivec builds, but I did have someone do a quick test for me before releasing and all seemed OK.

What's the exact command line arguments you were using? libmp3lame itself doesn't use altivec instructions, but perhaps decoding from a particular format does, so if you could paste the shell output too that would be great, so I can see what format the original file is in.

Does 3.1.1 work? It's still available on se.os4depot.net until that mirror gets updated.

Check your PMs for something to test.

@Severin

Try different codecs for input files.

@K-L

Just tried myself on an X1K with Altivex and converted some .flac music to .mp3, gives perfect and crisp quality.

(Took @severin's line for the quick test)

Though the vide decoder is borked it seems.

@Mick

ffmpeg -i anyfilehere -vcodec libx264 output.avi
ffmpeg -i anyfilehere -vcodec libxvid output.avi
ffmpeg -i anyfilehere output.avi

Tried the above lines with the Wildlife video and all give disorted sound over the whole vid.
You can still hear every bit, but it sounds as if a layer of disortion is put over it.

I'll send you one file so you can hear what i mean privately.

Ok well I'll do what I've done in the past and link the binary using an older adtools containing gcc 4.2.4, instead of my own build that contains gcc 6.1.0. That normally fixes it. No full re-compiling necessary.

Raziel, check your email.

Edit: Clarity.

I've been using smtube and ffmpegGUI to convert them, those don't use libmp3lame.

ffmpegGUI uses this command line :

ffmpeg -file.m4a -vn -acodec mp3 -ar 44100 -b:a 160k -ac 2 outputfile.mp3

I also tried the simple command :

ffmpeg -file.m4a -vn outputfile.mp3

Same result. I will try with libmp3lame option.

Raziel : could you test with non AltiVec version ?

Too bad, I get the same degraded sound volume with libmp3lame but I still get a crystal clear sound with the non AltiVec build.

MickJT : there is no b inary for ffmpeg 3.1.1 on OS4Depot only libs. But it used to work flawlessly formerly.

Maybe I should download it agin and run Unpack again.

BTW, thanks evryone for your answers and big thanks to MickJT for ffmpeg on AmigaOS 4.1 !

@K-L

No problems with generic build

I also don't have problems with music files, seems to affect only ripping audio from video files...


@Mick

Odyssey permits displaying the google drive, i only get a blank window

@Raziel : thanks.

Here is my result with AltiVec build : Edit : here is the result with AltiVec binary : http://amiga-ng.org/resources/TestFrozenConversion_1.mp3

It seems to be played by a Genesis/Megadrive

@K-L

Spoke too soon.

It seems only the "normal" generic decoder rips it correctly (from movie files).

If i use h264 or xvid with the generic decoder i have disortion as well.

Yes, your test file seem to suffer the same disortion.

K-L

3.1.1 is on http://se.os4depot.net, a manually updated mirror.

Did you check PMs? I sent you a link to a binary that I think will work. Use a mobile phone / PC if you can't download from Google Drive on OS4.

I've also temporarily uploaded it to [removed]

MickJT : ah, sorry, I dit not see the PM.

I've tested and indeed no more troubles (and it is even faster)

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.

@MickJT

Maybe gcc 6+ is not fully supported?
Just an idea

@MickJT

Quote:

Are you linking the binaries using static or dynamic linking?

If you link dynamically with newer libgcc.so and the user then uses it with an older libgcc.so that was included with the OS then that would explain the problems.

Note that with the latest gcc you may have to add the -static option to LDFLAGS to force static linking of all libraries.

To check if an already compiled program has shared object dependencies and what they are you can use:

ppc-amigaos-objdump -d <program>

Assuming that the program was wholly statically linked it should say that there is no dynamic section in the file.

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

@salass00

Wouldn't that rather be

objdump -T program ?

program: file format elf32-amigaos

objdump: program: not a dynamic object
DYNAMIC SYMBOL TABLE:
no symbols


If i use -d it will print stuff no matter if the exe is static or shared

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

Looks like I meant "ppc-amigaos-readelf -d <program>" instead of objdump.

I always get these two programs confused because they do essentially the same thing but have slightly different command line options.

@salass00

Ah, ok, exactly what i ws looking for

Thanks