mencoder+x264

[virus]

a small note: my build uses runtime cpu detection (= single build for both AMD and Intel, I'm lazy :D), while celtic_druid's one not; also, mine is very slim while celtic_druid includes all and even more. :)
Still, the result is equally b0rked in both cases.

My personal opinion on this is that SSE2 over MMX2 can (perhaps) be useful only if you use mencoder for some task which is a bit more complex than simply reading the input and passing frames to the codec... that's why I don't care when distributing mencoder binaries, since you're supposed to use AVS input with them and do your business using AviSynth's own filters. The speed depends only on the codec in this case.

Also, some time ago akupenguin did a quick test for SSE2 vs MMX2 in x264, and there were no noticeable differences. Probably for the kind of stuff needed in a codec MMX2 is sufficient. Maybe it's just me, but I seem to recall some people complaining about the lack of improvements when forcing the use of SSE2 in XviD too.

Anyway x264 mainly relies on MMX2 at the moment. The official makefile for MSYS/Cygwin doesn't even enable SSE2 (=> smaller code). MMX are efficient and available on all recent processors, so basically I'd say the whole SSE thing is not a big deal ;)

[giandrea]

Is it possible that the last MPlayer daily CVS snapshot does not build with x264 on Mac OS X for some incompatibility? I compiled and installed x264 succesfully, but when I go and try to build MPlayer it does not recognize that the library is installed.
Checking for x264 ... no

[hellfred]

Originally posted by celtic_druid
It isn't just me. Every build that I have ever tried from numerous different sources always has 0 for SSE/SSE2.
If i remember corectly, SSE is disabled when compiling under win32 due to some problems. To test this, you can try to get hold of some linux system, (or boot from a linux live CD like Knoppix) and try to compile and run mplayer there.
@giandrea
Did you check weather x264.h is in a place where ./configure will find it. What is written in configure.log in the section x264?

Hellfred
EDIT:
It may look like this:
============ Checking for x264 ============

#include <inttypes.h>
#include <x264.h>
#if X264_BUILD < 0x0014
#error We do not support old versions of x264. Get the latest from SVN.
#endif
int main(void) { x264_encoder_open((void*)0); return 0; }

gcc -I/mingwpr/include -static -L/mingwpr/lib /tmp/mplayer-conf-1489-2196.c -o /tmp/mplayer-conf-13111-2196.o -lx264 -lm
G:/DOKUME~1/Stefan/LOKALE~1/Temp/mplayer-conf-1489-2196.c:4:2: #error We do not support old versions of x264. Get the latestfrom SVN.E~1/Stefan/LOKALE~1/Temp/mplayer-conf-1489-2196.c:4:2: #error We do not

ldd /tmp/mplayer-conf-13111-2196.o
./configure: ldd: command not found

Result is: no
##########################################

[giandrea]

it looks like this:
============ Checking for x264 ============

#include <inttypes.h>
#include <x264.h>
#if X264_BUILD < 0x0014
#error We do not support old versions of x264. Get the latest from SVN.
#endif
int main(void) { x264_encoder_open((void*)0); return 0; }

cc /tmp/mplayer-conf-16695-6736.c -o /tmp/mplayer-conf-10079-6736.o -lx264 -lm
ld: Undefined symbols:
_sqrtf

ldd /tmp/mplayer-conf-10079-6736.o
otool: can't open file: /tmp/mplayer-conf-10079-6736.o (No such file or directory)

Result is: no

I really don't understand what it says, I'll try to recompile x264 from the last CVS and see if the message remains. Thank you.

[giandrea]

And I just realized that I get this error when compiling x264 from the last CVS:
Link x264
ld: Undefined symbols:
_sqrtf

cc -o x264 x264.o libx264.a -lm

...failed Link x264 ...
followed by a very long list of errors in checkasm.c
Perhaps there is something wrong with the Mac OS X port? Or I am missing something?
Thank you,

giandrea

[hellfred]

Originally posted by giandrea
And I just realized that I get this error when compiling x264 from the last CVS:
Link x264
ld: Undefined symbols:
_sqrtf

cc -o x264 x264.o libx264.a -lm

...failed Link x264 ...
followed by a very long list of errors in checkasm.c
Perhaps there is something wrong with the Mac OS X port? Or I am missing something?
Thank you,

giandrea
Sorry, i do not know enough C to understand what is going wrong there. I have suggest you to ask in another thread here on doom9 or go to the IRC channel or mailing list of x264 project.

Hellfred
_sqrtf -> google for it and find this (http://gcc.gnu.org/ml/java/2002-01/msg00277.html).

[giandrea]

Thank you, I've been on the IRC channel, and they told me that the Mac OS X version may be broken for now, because there is no Mac developer updating it. I will post the issue on the mailing list however,
thank you,

giandrea

[hitbit]

It seems that mencoder now support muxing via libavformat, at least experimentally. Anybody knows IF and HOW it works?

[opsis81]

@ hitbit
Is there a compiled build that supports it?
Link please :o
If you use the -of help command you can see the available output formats of your mencoder build.If avi is listed in the output formats the command for avi output is -of avi , if mp4 is listed in the output formats the command for mp4 output is -of mp4 etc

[ak]

Actually it's more like '-of lavf -lavfopts format=xxx', and it's not listed in '-of help', neither is it very useful atm, I believe.

[bond]

Originally posted by hitbit
It seems that mencoder now support muxing via libavformat, at least experimentally. Anybody knows IF and HOW it works? regarding avc (x264) i can say that libavformat doesnt support the correct muxing of avc in .mp4 or .mpg, so even if it would work it wouldnt be an useable option

[Doom9]

btw, rather than setting a fixed quantizer for the first pass, would it be possible to specify the bitrate as when using one of the libavcodec codecs? I know that the best way to make a first pass in x264 is to use the average quantizer that'll be used in the 2nd pass, but since we can't quite predict that, would it even matter?

[akupenguin]

x264's strict CBR doesn't work very well as a 1st pass. I have an experimental implementation of ABR (http://students.washington.edu/lorenm/src/x264/x264_abr.2.diff), which when finished will allow bitrate-based 1st pass.

[Doom9]

ok I guess I'll wait then.

I have some more questions and issues:

1)Is there any reason binary merging of raw x264 streams results in non working files? Since I've added separate credits processing to MeGUI that seems to happen depending on the settings (I haven't quite figured out when exactly it'll happen.. using the x264 defaults it seems fine, but with more advanced settings playback, once muxed into an mp4, is a no go)

So far, it looks like if the number of b-frames (0 works fine), and the number of reference frames (1 works fine) have something to do with this.

2) does separate credits encoding even make sense?

[Doom9]

I've done some more testing and it seems that the parameters of the merged files need to match. When I set the same number of reference frames, a merge works.

I've also tested b-frames and it seems we have the same behavior there.

So, I'm wondering: for raw binary merge streams to be properly playable, what settings do have to match and which ones can be changed safely?

[akupenguin]

Many of the encoder settings affect fields in the Picture Parameter Set and/or Sequence Parameter Set. PPS/SPS are allowed to change over the course of the encode, but only if you give each version a unique ID. If you do it in separate encodes, x264 doesn't know that it has to avoid conflicts with a previous stream, so it always uses ID=1.
The relevant params are: frameref, cabac, wpred, chroma_qp_offset, keyint (if it crosses a power of 2), B-frames (none vs normal vs pyramid; the number shouldn't matter), and of course resolution/aspect/framerate.
I would have expected many of those option changes to work at least some of the time. But I don't know what your mp4 muxer does when it encounters two different PPSs claiming to both represent the whole stream.

Also, if the 1st stream contains only 1 GOP, then concatenation will fail because consecutive GOPs must have different idr_pic_id's, and again x264 always starts at 1.

It would be possible to workaround both of these by allowing the user to force initial PPS/SPS/IDR IDs. But that's ugly.
The 2nd choice would be an informed merge, where the muxer automatically renumbers them. OK, but I'm not voluneering to write it.
The good way would be to add zoned ratecontrol. My volunteer disappeared, but it will happen eventually.

[defunkt]

It would be possible to workaround both of these by allowing the user to force initial PPS/SPS/IDR IDs. But that's ugly.

I have implemented this and as far as I can tell using MPEG4IP's h264_parse it is working exactly as I anticipated. SPS & PPS NALS still occur before every IDR but id's are incremented by one (and thus referenced by all subsequent NALS) if the section has been encoded separately & joined. The resulting stream plays correctly in alliance's avc player and if muxed into an mp4 (with MPEG4IP's mp4creator) plays in both mplayer & osmo. Unfortunately I cannot playback using DirectShow with either the Nero parser or Haali's splitter.

If you're still looking in on this thread, are you able to confirm that FFDShow's AVC decoder should be able to handle more than one SPS/PPS?

[hitbit]

As you probably know, mencoder has the ability to rip directly from DVD. So, for example, this line works fine:

mencoder dvd://1 -dvd-device q: -oac mp3lame -lameopts preset=medium -ovc xvid -xvidencopts fixed_quant=4 -o test.avi

This one, however, don't:

mencoder dvd://1 -dvd-device q: -oac mp3lame -lameopts preset=medium -ovc x264 -x264encopts qp_constant=24 -o test.avi

In this case, mencoder (latest build from celtic druid, same with Sherpya's) don't even start encoding: it exits with no particular error message.
Anyone...?