@xenic

Confirmed it here, check amigaworld.net thread. It's hard to reproduce.

@alfkil

You don't add -ldl, you just link using -use-dynld, simply add to the start of the command line (after the linker/compiler) when linking.

That makes your program use any shared libraries you have. If you don't want that, you have 2 options. You can either delete/rename the shared libs, leaving only the static ones to find, or "libdl" on OS4Depot might work.

I'm compiling libx264 that is 1 library for generic PPC and altivec CPUs, and i'll do the same to ffmpeg. In the end there'll be a static and shared ffmpeg, that will use altivec instructions if you have them. At least that's the plan.

@ktadd

Well, it's got nothing to do with any changed code. After disabling pthreads, there's no changes at all to the source.

Trying the build of x264 on OS4Depot now (not compatible with ffmpeg 0.6, but I can test some encoding). I didn't encode enough of the file to get a good look the first time round. I'll leave it for a while.

Results: x264 (Fredrik's port), bad quality. x264 (my port) even worse quality. Though there's been several changes between the revisions though. I think mine and Fredrik's ports are both bad. Perhaps the altivec code makes all the difference? His port detects and applies the altivec instructions automatically, while mine has it either on or off. So perhaps he never noticed any problems.

@ktadd

Quote:

You mean no. MPEG-4 part 2 is not H.264. So there's no H.264 encoding on the one on OS4Depot?

I tried the actual x264 executable (my own, revision 100) to encode a raw h.264 stream (.y4m as input), and it's crappy too. So i'm sure it's not ffmpeg's fault now. I did comment out a piece of code relating to PTHREADs and thread priorities. I'm now disabling pthreads in x264 to see what happens.

Will report back soon!

@ktadd

Bit too slow on here for me to really test it out. Give me 12 hours and i'll encode something overnight. Was/Is there any way to encode to H.264 video on the current ffmpeg_ppc on OS4Depot?

What's your command line?

ffmpeg -i input.mp4 -vcodec libx264 -vpre libx264-default-b 2000k -acodec libfaac -ac 2 output.mp4

Edit: Trying something small now. Will play back on PS3 and PC to check results.

Edit2: You're right, it's horrible. As if the bitrate is too low. I don't know if I can do anything about it, but i'll try. I'm aware that ffmpeg 0.6 and libx264 r100 don't like each either. libx264 complains that ffmpeg has broken default settings, making you use one of the presets (is that what you meant by filters?). I could test a windows build, but i'm guessing they've probably fixed up any issues like these already.

@afxgroup

Please test altivec versions if you can.

Edit: Ahh i've forgot to link with libunix. Not important now. Will do later.

@afxgroup

Thanks, i'll give that a go. Do you mind if I replace your ffmpeg on OS4Depot? I will make an altivec build, but will need someone to test that one.

Edit: New build is up. Seems to work OK.

@ktadd

What do you mean "currently released"? The latest ffmpeg doesn't have support for AMR wideband encoding anymore; Not since they changed to opencore-amr.

I see where in the code I can fix these path problems up, but i'm struggling to do it properly. I need help. I can think of 3 ways.

1) Does the file path exist? Yes? Then it's a valid amiga path

Problem: Never did it because I assume volume requesters would appear to check the existance of an HTTP or TCP device if you ever fed a URL as input, making you click cancel before it'd continue working.

2) If the protocol string is not http, rtmp, udp, tcp, concat, etc.. then the file path is considered valid.

Problem: Doesn't want to work for me, because I obviously don't know what i'm doing :)

3) Do it properly and check the existance of the volume name / assign or device before the colon in the file path.

Problem: No idea how to do that.

@Fab

While file: works and is a good solution for a GUI, I don't have any C/C++ coding skills, so to be honest I wouldn't have a clue where to start.

@Mrodfr

I have no idea what you just said :)

@ktadd

The goal would be to replace it sometime in the future.

ffmpeg constantly evolves, previously you used -vcodec h264, not -vcodec libx264. There was a time it was something else instead of -acodec libmp3lame too.

I'm re-uploading the versions again linked with libunix, since they don't prevent Amiga style paths from working. (Edit: Done. Same filesize, but it is a different build).

@ktadd

-lunix isn't doing it. Looking in Snoopy and SnoopDos, certain paths and filenames make ffmpeg not even bother to look for it, change the path to something else that doesn't exist, then it'll look for it, fail, and print the exact same message.

Quite peculiar. Looking into it now. If worse comes to worse, you could always make the GUI convert to unix-style paths if absolutely needed.

--- Edit ---

Must be a bug in ffmpeg. A workaround is to assign something with a space or a number, to the partition you want, and then use that assign.

RAM:, Work:, Other: don't work, but "RAM Disk:", DH1:, DH2:, etc.. work.

It's really interesting. If Windows allows colons in filenames, i'm going to do some testing and see if the bug exists in the Windows build too. On Windows, it'll see ram:test.mp4 as a filename with a colon, in the current directory. If I can name a file something with a colon, then change to ram2:test.mp4, and 1 works while the other doesn't, then it proves it's a bug in ffmpeg 0.6.

--- End edit ---

Edit2: Tested with ffmpeg windows build from January 2009. I couldn't put a colon in a filename, so I used a tool called "ProcMon" to monitor the system processes. When the input path is something like test:something.avi, it doesn't even try to find the file. Use test2:something.avi or "tes t:something.avi", and it does. Therefore, it's either some feature i'm unaware of, or a bug that Andrea is aware of and fixed in his port.

@ktadd

It's compiling. I'm going out now and will edit the first post in the thread when I get back.

It doesn't appear ffmpeg needs any high stack anyway, but i'll modify the source to include a stack cookie just incase, and so no-one has to remember to set a stack.

@ktadd

I built it with -lunix to support unix paths, but that has never stopped it from working with Amiga paths before. I'll try your example and edit this post in the coming minutes.

Edit: It's strange. It's only RAM: with the problem. "RAM Disk:" in quotes is fine, and every other Amiga path is fine too, just not RAM:. I will build it again without -lunix and see what happens, but it's a very large program and takes a couple of hours to build from scratch (and stupid me went and deleted the directory with all the object files because I thought it was ready).

@samo79

No, I haven't contacted him.

Note: This is an old post. Go to the end of the thread to see what is new.

OS4Depot download

Note: Altivec versions cannot be tested on my own machine. Please report if there any issues, although I probably won't be able to fix them. The Altivec version is naturally linked with an altivec version of libx264.

Pretty much everything enabled. ffplay may crash on exit. x264 encoding will require you to use one of the existing preset files. Use -vpre, don't include .ffpreset extension or path name.

This is for you, Kicko. XSUB encoding. I have no idea how to use it, but it's got the support for it!

Thanks Mrodfr for bringing back my attention to this software.

-- Edit --

Kicko, unfortunately ffmpeg can't demux or decode .srt subtitles. So XSUB encoding from .srt won't be possible.

-- End edit --

@Templario

Did you follow the instructions? It says specifically not to run from RAM Disk. Or is that what you meant?

Btw, what is "ejem"?

The -soname when building should have been libbz2.so.1.0.4, but due to a typo, is libbz2.so.1.0, meaning although there is a soft-link to libbz2.so, the OS cannot find the library if a program is built with it.

Edit: Changed my mind. All that is missing is a symlink. http://www.amigans.net/modules/newbb/ ... t_id=57493#forumpost57493

@samo79

OK. You should change the thread topic then.

Later this week I can check into it, but i'm gonna be very busy the next 2 days.

@samo79

VNC or VLC?

Edit: Topic is/was "LibVNC anyone?".