FFmpeg 0.6 released

@MickJT

Quote:

The above strcpy call should be replaced with:

strlcpy(proto_str, "file", sizeof(proto_str) );

Using the strcpy() function assumes the destination storage is large enough to take the 4 characters being copied. In this case it is, but it's far safer to check first. If someone changes the size of the proto_str buffer, there is no check when coping to it that it is large enough, and you'll possibly get a DSI if the buffer overruns.

As I said, in this case it won't be a problem, but you should always use length-checking functions to copy strings around (unless you are only copying the pointer to it, of course).

Simon

@afxgroup

Please test altivec versions if you can.

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

Quote:
I meant the current ffmpeg release on OS4depot supports encoding amr_wb. It doesn't use opencore-amr. It uses libamr-wb.

Quote:
I've been playing with x264 (no-altivec) using several different filters and I can't get good results. The resulting videos break up and look horrible. Anyone have any better luck?

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

Quote:
Use the "-t N" command, where N is the duration of the video to code in seconds. This will allow you to test things by only encoding the first N seconds of the video. (ie. -t 20) for the first 20 seconds.

Quote:
Yes. "-vcodec mpeg4" encodes in mpeg4 part 2. This works fine for ipods and such. It also works for your build as well. In your build "-vcodec libxvid" also encodes in mpeg4 part2 and seems to work fine. libx264 encodes in mpeg4 part 10.


Quote:
I'm using ffmpegGUI and leaving the video codec field set to default, which doesn't issue the -vcodec command, and putting "-vcodec libx264 -vpre libx264-default" in the Additional Option, Output string gadget. The resulting command line is as follows:

ffmpeg" -i "Data:movies/jws.mpeg" -vcodec libx264 -vpre libx264-default -t 12 "Ram:Outfile.mp4"

This uses the default bitrate of 200k which is low but the original video is right around that anyway. Other video codecs work fine with this video.

If you would like I can send you the modified version of ffmpegGUI that you could use for testing. Just PM me with an email address to send it to if you decided you would like to use it.

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

Quote:
Ah yes, your correct. I meant no H.264 on the one from OS4Depot. Sorry.

The point I was trying to make is that most devices, like the ipod and PSP which will play back h.264 will also play back videos that are mpeg4. Of course h.264 has better compresson to quality ratio so it would be a nice addition to get working.

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

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

Did you ever get round to releasing a version of FFmpegGUI that is compatible with FFmpeg 0.6?

Cheers

Quote:
I'll release it this weekend.

@ktadd
FFMPEG-GUI release ......MAGGICC! -:)

ace

@ktadd

I use FFMPEG-GUI rather often!

That's a GREAT NEWS!

@ktadd

Thanks mate.

ffmpeg 0.6.1 has been uploaded to OS4Depot. I hope it works :)

@MickJT

THX!!

Just for the next update could you use xdelta3 (os4depot) to create the .patch file it's waaaay faster than GPatch (m68k)

example:

to reate .patch file:
xdelta3 -s ffmpeg_ppc ffmpeg_altivec ffmpeg.delta

to "create" ffmpeg_altivec from ffmpeg.delta:
xdelta3 -d -s ffmpeg_ppc ffmpeg.delta ffmpeg_altivec





Keep the good work!!!

@MickJT

It's working but the Altivec patch doesn't seem to be working. It creates a new file but Altivec is not enabled (slower that previous version and no "--enable-altivec" indicated when launching ffmpeg) but maybe it's a normal behaviour ?

By the way, I'll have to modify my test of FFMpeg+FFmpegGUI, tested for the French magazine Amiga Power befor its release

@jabirulo

I was unaware of xdelta3. It creates smaller files too. I might re-upload it. Maybe, maybe not. Is it worth re-uploading just for this?

@K-L

Altivec optimizations are enabled by default, so only --disable-altivec is needed when creating a generic version.

I'm unable to test Altivec versions here. I had one person on the AmigaWorld IRC server test it out for me. All I was concerned about is whether it crashed or not. It does for me (no altivec here), and not for him, and thus that's good enough for me.

I can confirm that the altivec routines are being used though, because on my system, if I keep clicking "Continue Program" when running the debug build, it crashes repeatedly on the ff_fft_calc_altivec function.

The altivec version is not linked against an altivec libx264 this time, since the libx264 source is currently broken for making altivec builds.

http://www.listware.net/201010/x264-d ... 64-with-altivec-unit.html

It doesn't really matter anyway because libx264 is totally broken in every OS4 build i've made and also the build of x264 by Fredrik Wikstrom on OS4Depot, and creates crap quality files. I have no idea why. The only 2 theories I have are that libx264 detects PPC (generic) and tries to do certain calculations that don't work properly, or that it only works properly on hardware it has specific functions for, instead of just "generic". I had an altivec build of x264 tested and it produced the same crap results, so I don't know.

As for having to use -vpre in ffmpeg when using libx264, that's the way it is currently even on the Windows builds. Someone in the ffmpeg team is going to have to fix that up.

My only concern now is whether I can make a successful altivec optimized build of the next version of libxvid when that is released, since I had no luck with libmp3lame (and I tried everything, including the sourcecode included on OS4Depot for the prior "LAME" 3.98.2 build). As the LAME program says, it's generally due to a buggy compiler and i'm going to have to agree with it unless someone can prove me wrong.

@MickJT

Thanks for the explanation. So Altivec version is working ok here

And thanks for the hard work, ffmpeg + ffmpeGUI are truly a must have regarding video converion on AmigaOS 4.