mencoder+x264

[hitbit]

I've built (with MinGW) mplayer/mencoder with the latest revision
of x264 (48). Good news: x264 it's almost twice as fast. I've tried to encode an AVI file with b-frames enabled (without cabac) but no player (mplayer, VLC, DS based players etc) seems to be able to play these files, and some of them even managed to crash my computer. There is a player that can actually play x264 with b-frames?

(for those interested, I've managed to built a quick'n'(VERY)dirty (I'm not a competent coder...) hacked version of ffmpeg with x264 encoder. (is such thing legal, at least for personal use?). Now I can encode mp4 files with AAC and h264 (no b-frames and 2-pass, though). VLC and mplayer play them, but I wonder if these files are fully standard...)

[akupenguin]

MPlayer CVS as of september 26 should be able to play H.264 with B-frames and without CABAC, and should at least not crash with CABAC. (If it still can't, file a bug report.)

Whether it's legal to use H.264 without paying for all the patents - who knows? I'll leave that to someone who cares. But there's nothing wrong with hacking ffmpeg or x264.

And why don't you support 2-pass? It's just another x264 option, doesn't require anything special in the application.

-- Akupenguin, x264 developer.

[MfA]

Contrary to popular belief any type of use of patented technology infringes, whether it be for education/research/whatever. The amount of damages if they were ever to sue you is just lower than for infringement for commercial gain.

Source-code is slightly different since it cannot be used directly and because of the freedom of speech angle, but it hasnt really been tested in courts much ... there is a possibility that even distribution of source code could be deemed contributory infringement.

Basically you should just ignore patents if you write software ... you cant avoid them, the best you can do is to make a conscious effort not to know anything about them. So if you do end up in court at least you wont have to pay tripple damages.

Or stop writing software.

[virus]

-- Akupenguin, x264 developer.
so, you're a developer... glad to have you here :)
I wonder how the current plans of development for x264 are. Last time I checked (ffdshow-20040828) there was no 2-pass RC and the 1-pass fixed quantizer mode was b0rked. IIRC this stuff has already been fixed/added, no?

What are you working on right now? What about the future? Any info would be appreciated.

cheers :)
virus

[snacky]

ffdshow not withstanding, 2-pass has been in x264 since August 28.

[Tommy Carrot]

FFdshow also contains the fixes and the 2-pass RC, the problem is that the latest build is exactly a month old. A new build would be greatly appreciated. :)

[Sirber]

The FFDShow I have (ffdshow-20040828.exe) can only encode CBR and CQ. Is there an update?

[akupenguin]

I'm currently working on rate-distortion optimization of block types, and improving 2-pass.
Future: There are lots of features that I have some idea how to add. I may or may not get around to implementing them anytime soon.

[bond]

Originally posted by akupenguin
I'm currently working on rate-distortion optimization of block types, and improving 2-pass.
Future: There are lots of features that I have some idea how to add. I may or may not get around to implementing them anytime soon. akupenguin, cool to see that you are working on x264 :)
i hope it can one time become what xvid is now: the opensource codec, that kicks other commercial implementations ass :D

[Sirber]

Originally posted by bond
i hope it can one time become what xvid is now: the opensource codec, that kicks other commercial implementations ass :D Correction: i hope it can one time become what xvid is now: the opensource codec, that kicks other commercial MPEG4 implementations ass :D

;)

[virus]

Originally posted by akupenguin
I'm currently working on rate-distortion optimization of block types, and improving 2-pass.
Nice! I need a new ffdshow build, and I need it now. :D

Future: There are lots of features that I have some idea how to add. I may or may not get around to implementing them anytime soon.
mmh, I really hope you're not alone in your efforts.
BTW a question I had for a long time, but since no x264 dev has been here recently to answer it, I guess you are the right man :)

What about inclusion of code from XviD into x264? I'm sure there are a number of routines that can be ported successfully. I'm specifically thinking about motion estimation and maybe stuff like the keyframe insertion algorithm, or trellis quantization, which are not so closely related to the bitstream format. Is that something that can be done and it's on the TODO list, or maybe you guys don't like to reuse code written by another project and want to develop your own framework, even if it takes more time?
(not everyone is happy working with someone else's code ;))

[akupenguin]

Originally posted by virus
Nice! I need a new ffdshow build, and I need it now. :DSorry, I don't do builds for Windows. :devil:

What about inclusion of code from XviD into x264?
I have nothing against borrowing from other projects. I don't feel that x264 is "my" code any more than any other GPL project is; I simply joined x264 and added to it, just like I've submitted code to other Open Source projects. Still, I would rather port x264 to be a part of libavcodec, instead of the other way around.

I'll look into XviD's frame type decision (at least for adaptive B-frames), but I think my scene-change detection algorithm (if not the one currently in x264) is already better.
Don't hope for too much improvement in motion estimation (other than codec-specific tweaks): The plain old EPZS diamond produces very good results. Wider searches are slow, and only slightly better.
Trellis quantization is actually very dependent on bitstream format: It's purpose is to reduce some inefficiencies in Huffman coding of DCT coefficients. But H.264 uses Arithmetic coding, which doesn't suffer the same problems.

On the other hand, a good example of something not closely tied to the format is rate-control, where we did get to re-use some existing code.

[virus]

Originally posted by akupenguin
Sorry, I don't do builds for Windows. :devil:
don't worry, the request was not for you ;)
(we already have some ppl here which output nice ffdshow builds at a very fast rate... unfortunately all the recent work on x264 is not into the latest one)

I'll look into XviD's frame type decision (at least for adaptive B-frames), but I think my scene-change detection algorithm (if not the one currently in x264) is
already better.
Fine. Personally, I like the way XviD deals with the "max interval between I-frames" by lowering frame after frame the scenechange threshold until it reaches 0 (at the frame you specify as a limit). Don't know if x264 already has that, but it's a clever way to insert an I-frame where it can actually save some bits, instead of blindly forcing an I-frame when you reach the limit.

Trellis quantization is actually very dependent on bitstream format: It's purpose is to reduce some inefficiencies in Huffman coding of DCT coefficients. But H.264 uses Arithmetic coding, which doesn't suffer the same problems.
Yeah, there's CABAC. Maybe it's better to say that trellis is dependent on the entropy coder instead of the bitstream (the original paper presented trellis for H.263+, but the implementation in MPEG-4 Visual is pretty the same).

But even if you encode arithmetic, there should be some sequences that can be encoded with a shorter average length I guess and thus maybe R/D optimization can still be applied. Maybe it's not so easy to calculate the resulting rate with CABAC though ;)
Well, mine's pure speculation anyway, I don't even know what kind of data you pass to CABAC. Does it work with triplets (run, level, last) like MPEG-4 Visual?

[akupenguin]

Originally posted by virus
I like the way XviD deals with the "max interval between I-frames" by lowering frame after frame the scenechange threshold until it reaches 0 (at the frame you specify as a limit).Yes, we do that (not the exact same formula, but the same idea.) The difference is what metric you apply that threshold to: XviD predicts motion vectors from the previous frame, and compares SAD against that threshold. x264 runs the I-frame decision after encoding the frame as P, so we know exactly how much it costs to force all blocks to be I.

But even if you encode arithmetic, there should be some sequences that can be encoded with a shorter average length I guess and thus maybe R/D optimization can still be applied. Differences:
While not really harder to calculate rate with CABAC, it is slower, because you have to run the full CABAC algorithm and keep track of pending fractional bits and backup contexts, while with VLC you can just keep a table of the lengths of the codes.
You can think of CABAC as using (run,level-1,last), with run being coded in unary. But that's misleading. It's equivalent to coding as (zero,level-1,last), with (level-1,last) omitted if zero=true. Which is in turn equivalent to coding as (level,last) with (last) omitted if level=0. Each coefficient uses a separate CABAC context, so you gain nothing from merging two runs.
VLC has to use a whole number of bits per token, so you have to choose between, say, a more accurate quantization with length rounded up, and a less accurate one with length rounded down. But CABAC can use fractional bits per token, so both choices will have accurate costs, and there's not much to R/D optimize.

And just to test my theory, I tried out XviD's trellis code. Results: 0.15% reduced bitrate at a given PSNR, and 60% increased encode time. I'm sure it could be faster, but I don't hope for better quality.

[virus]

akupenguin, thanks for taking the time to answer my questions :)
Originally posted by akupenguin
And just to test my theory, I tried out XviD's trellis code.
WHAT?!? :eek:
You managed to add trellis in just a few hours?
This means that if I ask you a question about B-frames, you would make x264 fully Main Profile compliant in just a couple of days? :D

[Bogalvator]

@hitbit

Please post your exact command line to get x264 to be built into mencoder, i.e. ./configure ..... etc

I could not get configure to detect the x264 libraries when I tried with MinGW.

[akupenguin]

Originally posted by virus
You managed to add trellis in just a few hours?
This means that if I ask you a question about B-frames, you would make x264 fully Main Profile compliant in just a couple of days?
Trellis is a clever algorithm, but the implementation is pretty concise. And I could do almost a line-by-line substitution from XviD's implementation, aside from the complications of finding the length of a CABAC token. And since it didn't help and won't be included in main x264, I haven't spent the time to optimize it.
On the other hand, H.264 B-frames are nothing special conceptually, but still are a big mess of possible alternative encoding modes and lots of variables to optimize over. While I could implement a "fully compliant" B-frame encoder in a few days, it would take longer to make it effectively use all those alternatives, and even longer to develop heuristics to make it fast.
And since I've joined the FFmpeg opinion that the whole concept of B-frames and reordering is ugly, it's not high on my todo-list. OTOH, I'll have to investigate whether it's legal to use B-frames without reordering, just for the multiple predictions from the past, and avoid increasing the cost of P-frames (or avoid P-frames entirely).

[MfA]

Pity that to give up b-frames you have to give up (temporal) direct mode.

I have always missed temporal motion prediction for p-frame MV coding in h.264 (or even better meta motion compensation). Alexis Tourapis has done some work now, but that is too little too late.

[ivan_alias]

Can mencoder be used to output mp4 files? If not I guess Videolan may be the best way to take DTT sources and encode them to h.264 in an mp4 container.

Unless anyone knows of another way to do this?

[ak]

Doubtly, 'mencoder -of help' will list all available formats.

[hitbit]

mencoder can only output mpeg, avi and raw video. That's why I've tried to integrate x264 in ffmpeg, that has a huge list of output formats, including mp4. BTW, I wonder why the mencoder developers don't use libavformat muxers, since this library is already included in the program...

[bond]

avc has to be especially muxed into .mp4, i doubt that ffmpegs .mp4 support handles this! i even doubt that its mpeg-4 asp outputted .mp4 files are spec compliant

[hitbit]

avc has to be especially muxed into .mp4, i doubt that ffmpegs .mp4 support handles this! i even doubt that its mpeg-4 asp outputted .mp4 files are spec compliant

I feared that. Which is, then, a reliable way to mux AVC in .mp4?

[ak]

One can go this route:
- encode with mencoder outputing to raw h264
- mux result to mp4 using mp4creator.

Not the most prettiest way, but then again pretty much worky.

[bond]

Originally posted by hitbit
I feared that. Which is, then, a reliable way to mux AVC in .mp4?the way to store h.264 in .mp4, the spec compliant way is defined in mpeg-4 part 15 afaik

i think the latest cvs version of mp4creator can mux raw h.264 into .mp4 following this, but i never really tested it whether its really spec compliant

[BoNz1]

Originally posted by akupenguin
And since I've joined the FFmpeg opinion that the whole concept of B-frames and reordering is ugly, it's not high on my todo-list. OTOH, I'll have to investigate whether it's legal to use B-frames without reordering, just for the multiple predictions from the past, and avoid increasing the cost of P-frames (or avoid P-frames entirely).

Shame. It would be nice, if someone could provide a patch for FFmpeg to decode b-frames w/ CABAC and in-loop filtering. I mean it would be nice to at least be able to watch the Ateme encoded files in linux or windows without the help of their directshow filters. I sort of understand your position about not wanting to add b-frames to the encoder because of the amount of work it would take. But the ffmpeg position and more specifically Michael Neidermayer's position not to add support for b-frames decoding seems close to zealotry to me.

[snacky]

But the ffmpeg position and more specifically Michael Neidermayer's position not to add support for b-frames decoding seems close to zealotry to me.
You misunderstand. Nobody is opposed to putting completely working b-frame decoding in ffmpeg's h.264 decoder. It just hasn't been done yet.

[hitbit]

MPlayer CVS as of september 26 should be able to play H.264 with B-frames and without CABAC, and should at least not crash with CABAC. (If it still can't, file a bug report.)

Incidentally, even latest builds of mplayer (1/10/04) can't play
h264 with b-frames. With cabac, it flickers like hell and warn you
that you can't use b-frames with cabac. Without cabac, it plays
for some seconds and crash miserably.

To Bogalvator:
you have to compile x264, put libx264.a in mingw/lib and x264.h in mingw/include. You probably have to add this line
#include <stdarg.h>
on top of x264.h
There usually no need to add --enable-x264 in configure, because the program finds it itself.

[BoNz1]

Originally posted by snacky
You misunderstand. Nobody is opposed to putting completely working b-frame decoding in ffmpeg's h.264 decoder. It just hasn't been done yet.

No I do not misunderstand. Basically, what all the core ffmpeg developers have said is that they will not support it. They will however, accept a patch provided it is clean and not too nasty. But, honestly there are not that many developers that I know of that are actually comfortable with ffmpeg other than the core developers. So I don't see this happening any time soon. I don't know how much time and effort it would take to fully support main profile decoding in ffmpeg. It may take a lot of time, I dunno. But it can't take _that_ much time though for someone of Michael's skill. Hell, I would give him a 40GB notebook hard drive that he wanted if he would do it http://www.mplayerhq.hu/homepage/design7/donations.html It just seems to me like the core developers just want to make a statement that they hate b-frames which is just plain annoying.

[akupenguin]

Originally posted by hitbit
Incidentally, even latest builds of mplayer (1/10/04) can't play
h264 with b-frames. Without cabac, it plays for some seconds and crash miserably.
I haven't encountered such a bug. B-frames + deblocking works for me too. Want to submit a bug report with a sample file that it crashes on?

[Bogalvator]

Originally posted by hitbit

you have to compile x264, put libx264.a in mingw/lib and x264.h in mingw/include. You probably have to add this line
#include <stdarg.h>
on top of x264.h

Many many thanks hitbit, this worked a charm.

[ivan_alias]

I think this is probably the right thread..

I'm trying to convert an mpeg2 stream from DVD to x264/mp3 in avi. I'd prefer x246 and aac in mp4 but cant find a way to do that just yet.

I'm using mencoder from celtic-druid's site and I can happily do mpeg4 etc. no problem.

However x264 isnt working for me :(

here is my command line:

mencoder.exe test.mpg -oac mp3lame -ovc x264 -x264encopts qp_constant=14 -of avi -o output.avi

I'm getting this back:


C:\Documents and Settings\ade\Desktop\Downloads\mplayer2004.10.20>mencoder.exe test.mpg -oac mp3lame -ovc x264 -x264encopts qp_constant=14 -of avi -o output.avi
MEncoder dev-CVS-041020-21:23-3.4.2 (C) 2000-2004 MPlayer Team

CPU: Advanced Micro Devices Athlon MP/XP/XP-M Barton (Family: 6, Stepping: 0)
Detected cache-line size is 64 bytes
CPUflags: Type: 6 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 0 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE

Reading C:/Documents and Settings/ade/Desktop/Downloads/mplayer2004.10.20/mplayer/codecs.conf: 77 audio & 181 video codecs
Reading config file C:/Documents and Settings/ade/Desktop/Downloads/mplayer2004.10.20/mplayer/mencoderfont: can't open file: C:/Documents and Settings/ade/Desktop/Downloads/mplayer2004.10.20/mplayer/font/font.desc
font: can't open file: /usr/local/share/mplayer/font/font.desc
MPEG-PS file format detected.
VIDEO: MPEG2 720x576 (aspect 3) 25.000 fps 8000.0 kbps (1000.0 kbyte/s)
[V] filefmt:2 fourcc:0x10000002 size:720x576 fps:25.00 ftime:=0.0400
==========================================================================
Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
MP3lib: init layer2&3 finished, tables done
AUDIO: 48000 Hz, 2 ch, 16 bit (0x10), ratio: 32000->192000 (256.0 kbit)
Selected audio codec: [mp3] afm:mp3lib (mp3lib MPEG layer-2, layer-3)
==========================================================================
Opening video filter: [expand osd=1]
Expand: -1 x -1, -1 ; -1 (-1=autodetect) osd: 1
==========================================================================
Opening video decoder: [mpegpes] MPEG 1/2 Video passthrough
VDec: vo config request - 720 x 576 (preferred csp: Mpeg PES)
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
VDecoder init failed :(
Opening video decoder: [libmpeg2] MPEG 1/2 Video decoder libmpeg2-v0.4.0b
Selected video codec: [mpeg12] vfm:libmpeg2 (MPEG 1 or 2 (libmpeg2))
==========================================================================
Building audio filter chain for 48000Hz/2ch/16bit -> 48000Hz/2ch/16bit...
ODML: Aspect information not (yet?) available or unspecified, not writing vprp header.
VDec: vo config request - 720 x 576 (preferred csp: Planar YV12)
VDec: using Planar I420 as output csp (no 1)
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.

It also says 'the selected video_out device is incompatible with this codec.

Any ideas for a working commandline for converting mpeg2 to x264?

thanks a lot

[RadicalEd]

I also get an error, using celticdruid's tbird win32 compile:mencoder.exe G:\testes\tenchi
_ffv1.avi -ovc x264 -nosound -ffourcc avc1 -passlogfile -x264encopts bitrate=100
0 keyint=300 idrint=1 frameref=10 deblockalpha=6 deblockbeta=6 qp_min=1 fullinte
r subq=5 log=3 pass=1 G:\testes\x264stats.log -o G:\testes\mencoderx264p1.avi
MEncoder dev-CVS-041022-03:26-3.4.2 (C) 2000-2004 MPlayer Team

CPU: Advanced Micro Devices Athlon Thunderbird (Family: 6, Stepping: 2)
Detected cache-line size is 64 bytes
CPUflags: Type: 6 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 0 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE

Reading C:/Tools/mplayer/mplayer/codecs.conf: 77 audio & 181 video codecs
File not found: 'frameno.avi'
Failed to open frameno.avi
Reading config file C:/Tools/mplayer/mplayer/mencoder: No such file or directory

font: can't open file: C:/Tools/mplayer/mplayer/font/font.desc
font: can't open file: /usr/local/share/mplayer/font/font.desc
success: format: 0 data: 0x0 - 0x8abda8c
AVI file format detected.
AVI_NI: No audio stream found -> no sound.
VIDEO: [FFV1] 640x480 24bpp 23.976 fps 13448.9 kbps (1641.7 kbyte/s)
[V] filefmt:3 fourcc:0x31564646 size:640x480 fps:23.98 ftime:=0.0417
Opening video filter: [expand osd=1]
Expand: -1 x -1, -1 ; -1 (-1=autodetect) osd: 1
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffv1] vfm:ffmpeg (FFV1 (lossless codec))
==========================================================================
Forcing output fourcc to 31637661 [avc1]
Writing AVI header...
ODML: Aspect information not (yet?) available or unspecified, not writing vprp header.
VDec: vo config request - 640 x 480 (preferred csp: Planar YV12)
VDec: using Planar I420 as output csp (no 4)
Movie-Aspect is undefined - no prescaling applied.
At this point mencoder crashes with the following error signature:AppName: mencoder.exe AppVer: 0.0.0.0 ModName: msvcrt.dll
ModVer: 7.0.2600.2180 Offset: 00036137

Perhaps the culprit is "Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE"?

[yaz]

Originally posted by RadicalEd
I also get an error, using celticdruid's tbird win32 compile:
At this point mencoder crashes with the following error signature:
AppName: mencoder.exe AppVer: 0.0.0.0 ModName: msvcrt.dll the same here with xp version (???)
Originally posted by RadicalEd
Perhaps the culprit is "Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE"? don't think so (my athlon xp would love that option).
to get somewhat closer i tried to encode mpeg2, divx, xvid & x264. this problem occurs only(!) with x264. i tried different sources too (vob, mpeg, avi, avis) bacause i've thought that avisynthing(ffdshow.ax) is the problem but not; no way of encoding to x264 independently of the source type.

another strange thing is that mplayer cries for some 'sdl.dll'. what's that and how can i get it ? (i've never seen this msg before)

y

[ak]

Originally posted by yaz
another strange thing is that mplayer cries for some 'sdl.dll'. what's that and how can i get it ? (i've never seen this msg before)

http://www.libsdl.org/download-1.2.php

And here's plain i686 build with runtime-cpu-detection: http://4nykey.nm.ru/bin/mencoder-cvs.exe, so it should run on PentiumPro and up.

[celtic_druid]

Hmmm, I thought that I disabled SSE.

There does/did seem to be a problem with x264 encoding. Did a fresh compile and it seems to work fine. Only did a brief test, but no more crash with default settings.

mplayer/mencoder Athlon-XP (http://celticdruid.no-ip.com/xvid/mplayer/mplayer2004.10.22.7z)

Will try another tbird and P4 compile if I have time.

[Tommy Carrot]

Slightly offtopic, but is there anyone who could successfully encode with snow codec in mencoder? It crashes here everytime i try to use it.

[KpeX]

Originally posted by Tommy Carrot
Slightly offtopic, but is there anyone who could successfully encode with snow codec in mencoder? It crashes here everytime i try to use it. Same here, under linux, with mencoder or ffmpeg.

[hellfred]

Hy to all those that compile mplayer/mencoder themselves.
I have been doing this for quite a while now under mingw and cygwin, but I am running into problems when trying to compile x264 under MinGW. The assembler compiler nasm is missing:

Stefan@J5U7R1 ~/x264_20041020/build/cygwin
$ make
A: core/i386/dct.asm
make: nasm: Command not found
make: *** [core/i386/dct.obj] Error 127

I found some win32 builds (nasm-0.98-win32.zip) on the net and extracted them to MSYS bin (nasmw.exe and ndisasmw.exe). I had to rename nasmw.exe to nasm.exe to get it being used, but now there are syntax problems when invoking nasm:

Stefan@J5U7R1 ~/x264_20041020/build/cygwin
$ make
D: /home/Stefan/x264_20041020/build/cygwin/bin
C: core/mc.c
C: core/predict.c
D:/STEFAN/MSYS/1.0/home/Stefan/x264_20041020/core/predict.c: In function `predic t_4x4_vr':
D:/STEFAN/MSYS/1.0/home/Stefan/x264_20041020/core/predict.c:536: warning: unused variable `l3'
D:/STEFAN/MSYS/1.0/home/Stefan/x264_20041020/core/predict.c: In function `predic t_4x4_hd':
D:/STEFAN/MSYS/1.0/home/Stefan/x264_20041020/core/predict.c:569: warning: unused variable `t3'
D:/STEFAN/MSYS/1.0/home/Stefan/x264_20041020/core/predict.c: In function `predic t_4x4_vl':
D:/STEFAN/MSYS/1.0/home/Stefan/x264_20041020/core/predict.c:593: warning: unused variable `t7'
C: core/pixel.c
C: core/macroblock.c
C: core/frame.c
C: core/dct.c
C: core/cpu.c
C: core/cabac.c
C: core/common.c
C: core/mdate.c
C: core/csp.c
C: encoder/analyse.c
C: encoder/me.c
C: encoder/ratecontrol.c
C: encoder/set.c
C: encoder/macroblock.c
C: encoder/cabac.c
C: encoder/cavlc.c
C: encoder/encoder.c
C: encoder/eval.c
C: core/i386/mc-c.c
C: core/i386/dct-c.c
C: core/i386/predict.c
A: core/i386/dct.asm
nasm: no input file specified
type `nasm -h' for help
make: *** [core/i386/dct.obj] Error 1

How to get x264 compiled with the asembler code under MinGW? Or did i miss a MinGW package containing a suitable nasm.exe. Can i compile the object files under cygwin, copy them to the mingw build of x264 and link them with the other object files created by MinGWs gcc-compiler?

Hellfred

[ak]

I believe, to use snow, just like ffv1 and other experimental stuff, 'vstrict=-1' has to be added to lavcopts.

As for nasm, maybe try 'make -f Makefile.cygwin' from top dir, it should give more verbose output.

[hellfred]

Originally posted by ak
I believe, to use snow, just like ffv1 and other experimental stuff, 'vstrict=-1' has to be added to lavcopts.

As for nasm, maybe try 'make -f Makefile.cygwin' from top dir, it should give more verbose output.
The vstrict=-1 sounds reasonable, as the spezifications for snow are most probably not be finished yet and therefore vstrict=-1 should be set (strict logic of ffmpeg project)
For the Makefile.cygwin. I will compare it with the Makefile under build/cygwin. I have used that and copied the object files produced with cygwin to to the mingw bin/i386 directory. make succeeeded in building the lib and executeable, and just now i am compiling mencoder, to see if the libx264.a works correctly with the cygwin nasm objects.

Hellfred

[Bogalvator]

Hellfred, download the nasm source and compile using MinGW. Then copy the executables into the mingw\lib directory - this worked for me.

[Tommy Carrot]

Originally posted by ak
I believe, to use snow, just like ffv1 and other experimental stuff, 'vstrict=-1' has to be added to lavcopts.
Thanks, it works.

[Tommy Carrot]

Still offtopic. :D

I've played with this snow codec a bit, and forgive my enthusiasm, but i find it very great! It's still very early in the development, so there are issues/artifacts (usually miscolorization), but other than that, it's very impressive, the detail level far exceeds xvid, i would say it's on par or even a bit better than h.264. I hope Michael will continue the development, because snow has great potential to beat even h.264.

[RadicalEd]

Thanks Celtic, the new build works perfectly.

[RadicalEd]

@Tommy, where did you get information about snow's usage in mencoder? I can't seem to find any non-sourcecode documentation.

[dragongodz]

not exactl sure where this should go but since cabac and b frames mentioned in the previous page...

h264.c in ffmpeg just had this

> Allows decoding of most B-type MBs in H.264 with CABAC.
> B_Skip is still unimplemented.

thought some people here may find it of interest. :)

[BoNz1]

Originally posted by dragongodz
not exactl sure where this should go but since cabac and b frames mentioned in the previous page...

h264.c in ffmpeg just had this

> Allows decoding of most B-type MBs in H.264 with CABAC.
> B_Skip is still unimplemented.

thought some people here may find it of interest. :)

Yeah, I saw that akupenguin sent that to the mailing list a couple of days ago. Thanks :).

[hellfred]

Compiling first nasm souce code and after that x264 (using build/cygwin/Makefile) and mplayer cvs works fine using MinGW. Encoding does work, too.
Skript used for the first tests:
#!/bin/sh
#Skript to test mencoder x264encopts

#Versuch 1
#./mencoder tng.yuv -o x1_subq1.avi -ovc x264 -x264encopts qp_constant=22:fullinter:cabac=1:iframe=100:psnr:subq=1

#Versuch2 -> klappt
#./mencoder test.avi -ovc x264 -x264encopts qp_constant=22:fullinter:cabac=1:keyint=250:psnr:subq=1:deblock \
-nosound -of avi -o out.avi

#Versuch3 -> Qualität für Anime in nur einem Durchgang steigern
#./mencoder test.avi -ovc x264 -x264encopts qp_constant=22:fullinter:cabac:keyint=250:psnr:subq=2:deblock: \
deblockalpha=2:frameref=5 -nosound -of avi -o out.avi

#Versuch4 2-pass
#./mencoder test.avi -ovc x264 -x264encopts pass=1:qp_constant=22:fullinter:cabac:keyint=250:psnr: \
subq=2:deblock:deblockalpha=2:frameref=5 -nosound -of avi -o out.avi
#./mencoder test.avi -ovc x264 -x264encopts pass=2:bitrate=666:qp_min=12:qp_max=45:rc_buffer_size=5:fullinter: \
cabac:keyint=250:psnr:subq=2:deblock:deblockalpha=2:frameref=5 -nosound -of avi -o out.avi

#Versuch4a 2-pass geringere Bitrate RC mit Standartwerten + hoher Wert fur subpel-Verfeinerung
./mencoder test.avi -ovc x264 -x264encopts pass=1:qp_constant=22:fullinter:cabac:keyint=250:psnr: \
subq=4:deblock:deblockalpha=2:frameref=5 -nosound -of avi -o out.avi
./mencoder test.avi -ovc x264 -x264encopts pass=2:bitrate=450:qp_min=15:qp_max=51:qcomp=0.8:rc_buffer_size=1: \
fullinter:cabac:keyint=250:psnr:subq=4:deblock:deblockalpha=2: \
frameref=5 -nosound -of avi -o out_Versuch5.avi
Line breaks for not exeeding the width of the html page are makred with "\", and those smilies are supposed to be ": p" without the white space.
On my PIII 550MHz I get 2 fps for "Versuch2" (1 pass qp_constant=22) for a souce with resolution of 640X480 pixel under MinGW/Win98 and about double the speed on the same system/script when booting to linux.
On the PIV@3.06GHz the speed rises to about 16fps using MinGW/WinXP. Too bad that i can not install any linux distros to the haddrive of the second system.
*dreaming of 20+ fps encoding speed

Hellfred

[akupenguin]

Originally posted by hellfred
those smilies are supposed to be ": p" without the white space. You can disable smilies, you know. :p

And why are you using such a tiny rc_buffer_size ?

[hellfred]

Originally posted by akupenguin
And why are you using such a tiny rc_buffer_size ?
Because actually i do not know what i am doing after all?
I try to get along with the infos given in mplayer manpage and some very basic knowledge from doom9 guids for encoding MPEG4.
So what do you suggest for rc_buffer_sice (and all the other parameters tuning the rate control)?
Another question where I need your help please.
I do not understand the concept of the options needed for multipass encoding in x264 or the wording of the manpage.
For first pass (analysing complexity of the source frames) i have used
-x264encopts pass=1:qp_constant=22:...
and for the second pass
-x264encopts pass=2:bitrate=450:...
and hoped that in average(!), each set of 24 frame will get 450 kbit (24 frames = one second), the less complex frames sets less bitrate and the more complex frames sets more bitrate. Though reading the manpage again I got some doubts, as only ConstantBitRate is mentioned there:
bitrate=<value>
Sets the bitrate to be used in kbits/second (default: off).
This is required if you want a CBR (constant bitrate) encode.
So what do i have to add after pass=1 and pass=2 for two pass encoding, and what after pass=1 and after first and second pass=3 for three pass encoding?

Hellfred

[akupenguin]

The default rc_buffer_size is 1 second's worth of bits, so you could just leave it alone. But if you do want to specify it, it's measured in kbits, not seconds, so you'd want something around rc_buffer_size=450.

In both CBR and multi-pass, setting rc_buffer_size too small will cause wild fluctuations in quantizer, because even a small error in predicting one frame size will completely empty or fill the buffer. The optimal buffer in my tests was around .5-1 second for CBR, or 1-2 seconds for multi-pass. So I selected a default of 1 second, and you shouldn't have to change it unless you have some special restrictions.

Now, in your case it didn't actuall kill your encode, because x264 recognizes 1kbit as a rediculously small buffer (it's less than the size of one frame), emits a warning message, and uses .5 seconds worth of bits instead.

[hellfred]

I read in the manpage that the default for rc_buffer_sice is just enough bitrate to store the frames of one second of the clip, but i missed that i have to give kbits, not the amount of seconds i want it to store. Stupid me. Any hints about what to specify after pass=1 and pass=2/3? Google does not help me with this problem.

Hellfred

EDIT: This is my first try of a three pass encoding:
#Versuch5
./mencoder test.avi -ovc x64 -x264encopts pass=1:qp_constant=15:fullinter:cabac:deblock:subq=4:keyint=300: \
scenecut=45:frameref=8:deblockalpha=1:deblockbeta=0 \
-nosound -of avi -o out.avi
./mencoder test.avi -ovc x64 -x264encopts pass=3:bitrate=450:qp_min=15:qp_max=51:qcomp=0.8:rc_buffer_size=700: \
fullinter:cabac:deblock:subq=4:keyint=300:scenecut=45:frameref=8: \
deblockalpha=1:deblockbeta=0 -nosound -of avi -o Versuch5_pass2.avi
./mencoder test.avi -ovc x64 -x264encopts pass=3:bitrate=450:qp_min=15:qp_max=51:qcomp=0.8:rc_buffer_size=700: \
fullinter:cabac:deblock:subq=4:keyint=300:scenecut=45:frameref=8: \
deblockalpha=1:deblockbeta=0 -nosound -of avi -o Versuch5_pass3.avi

[akupenguin]

You can save some time by using a faster first pass: nofullinter, subq=3, maybe frameref=4. (I haven't tested exactly what effect a reduced first-pass frameref has on final quality, but it should be ok in 3pass mode.)

Other than that, the optimal scenecut depends on the video, and deblockalpha/deblockbeta are a matter of preference. You'll have to decide for yourself what looks best.

[yaz]

@akupenguin
thx for your help ! amof, what i've found about h264 encoding so far is far not enough to make any reasonable setup in mencoder. maybe, u can answer these too.
- i understand that rc_b_s is set to 1s if bitrate is defined. but how is it set in quality mode (fixed quantizer) ?
- what q do u suggest for the 1st pass ? i tried 5, 10, 15, 20 but i can't see any difference & differences in psnr were also very small (in the range of 0.0x)
- what if only subq=1 is used for 1st pass ? does it affect significantly the 2nd pass ? again, i found not too much difference caused by subq of 1st pass

thx
y

[akupenguin]

rc_b_s affects ratecontrol - the function that modifies quantizers to meet a desired bitrate. In fixed quantizer mode there's no ratecontrol at all, so rc_b_s does nothing.

I recommend using a 1st pass QP about the same as the expected average QP of the final encode. Yes, you'll have to guess. It's probably better to err on the side of lower QP.

Yes, you can probably use much faster options on the 1st pass. In 3 pass mode, you might even get away with leaving out some options on the middle pass. I'm still mostly working on implementing H.264 features, so not so much testing has gone into speedwise optimal options.

[pogo stick]

I am so exited about development of x264! Akupenguin, please, keep your good work! :)

Originally posted by dragongodz
not exactl sure where this should go but since cabac and b frames mentioned in the previous page...

h264.c in ffmpeg just had this

> Allows decoding of most B-type MBs in H.264 with CABAC.
> B_Skip is still unimplemented.

thought some people here may find it of interest. :)
Does it mean that B-frames and CABAC will be correct decodable by mplayer and ffdshow?
And what is B_Skip?

[yaz]

thx for the answers !
Originally posted by akupenguin
I'm still mostly working on implementing H.264 features, so not so much testing has gone into speedwise optimal options. pls, keep on developing ! amof, i'm interested not really in speed but in quality. and it's getting better and better :-)
thx
y

[gotaserena]

slightly OT, but are celtic_druid's builds of mplayer supposed to work "out of the box"? I'm having trouble playing h.264 files with it, both in .avi (wrapped by mencoder itself) and .mp4 (muxed by mp4creator, which changes the fourcc to avc1).

Anybody knows what is going on?

[celtic_druid]

Works fine here. At least with avi files. What exactly is the problem?

[gotaserena]

Thanks, celtic_druid... It's probably me doing smth stupid, but here it goes.

when I play a .avi h.264 file I get errors like
[h264 @ 007A3C38]left block unavailable for requested intra4x4 mode -1 at 0 0
[h264 @ 007A3C38]error while decoding MB 0 0
[h264 @ 007A3C38]concealing errors
and then crashes.

when I try the .mp4 I get these
[h264 @ 007A3C38]error, NO frame 0%
Error while decoding frame!
which keeps going.

The mplayer I compiled in linux works with both files. I'm just compiling CVS with x264 support in cygwin to see if I can repeat the error.

[bond]

Originally posted by gotaserena
muxed by mp4creator, which changes the fourcc to avc1thats the correct behaviour, every h.264 stream has to be marked as "avc1" in .mp4

[Yong]

What's problem with my x264 encoding options?

"F:\mplayer\mencoder.exe" %1 -o "%userprofile%\desktop\%~n1.avi"
-noskip -oac copy -ovc x264 -x264encopts
bitrate=1200:keyint=300:frameref=3:nocabac:bframes=3

Crash mplayer and ffdshow...
Cause by the b-frame?

[akupenguin]

Before anyone can help you, please read the Bug Reporting Guidelines (http://mplayerhq.hu/DOCS/HTML/en/bugreports.html).

As for what's wrong with your options: CBR mode sucks (there's nothing wrong with x264's implementation of CBR, it's just that CBR in general sucks), and bframes don't help yet (this one is x264's fault). But that's not why it crashed.

[Yong]

Originally posted by akupenguin
Before anyone can help you, please read the Bug Reporting Guidelines (http://mplayerhq.hu/DOCS/HTML/en/bugreports.html).

As for what's wrong with your options: CBR mode sucks, and bframes don't help yet. But that's not why it crashed.

Sorry, my english comprenhensive is not good...
I use CBR for testing only ;) .
That's mean you recommend me using the fix quant?
Still can't use b-frame?

OK, i'll try to make the bug report as detail as possible.

[Yong]

What's the meaning by this?
x264 [warning]: rc buffer size 0 too small

It's there have any problem with my x264 encoding setting?
"F:\mplayer\mencoder.exe" %1 -o "%userprofile%\desktop\%~n1.avi"
-noskip -oac copy -ovc x264 -x264encopts keyint=300:frameref=3:deblockalpha=3:
deblockbeta=3:rc_buffer_size=6:rc_init_buffer=6:qp_constant=31

[hellfred]

Originally posted by Yong
What's the meaning by this?
x264 [warning]: rc buffer size 0 too small

It's there have any problem with my x264 encoding setting?
"F:\mplayer\mencoder.exe" %1 -o "%userprofile%\desktop\%~n1.avi"
-noskip -oac copy -ovc x264 -x264encopts keyint=300:frameref=3:deblockalpha=3:
deblockbeta=3:rc_buffer_size=6:rc_init_buffer=6:qp_constant=31
I have made this mistake, too.
In the manpage you can read that the RateControl buffer size will default to a value that represents the amount of memory needed to store one second of the video, so for bitrate of e.g. 350 kbits per second the default equals rc_buffer_size=350. You need to set the kbits per seconds, not an amount of seconds. See akapenguins post above (15 posts earlier in this very same thread, on the third page) for some suggestions.
And by the way, for a one pass encode with fixed quantizizer, setting rate control is not needed. It is usefull for the second and third pass of a 2 pass or 3 pass encode. Read my posts above for some example commandlines for this, they are on the third page of this thread, too, just after akapenguins suggestions for a good rc_buffer_size.
Hellfred

[Yong]

Thanks hellfred, i won't make that mistake again;),
BTW your CLI x264 option is a good reference for me:D

[Yong]

New questions:
Sorry for the OT,
1. How disable video output at two-pass first-pass encoding in mencoder
(like XviD encoding, the first pass video may be large or equal to source video)?

2. It's the MPlayer have an option too raise the apps priority?
mplayer might be too sensitive at windows environment, event a right click can cause the audio or video playback become stuttering.:(

[nexx]

Originally posted by Yong

2. It's the MPlayer have an option too raise the apps priority?
mplayer might be too sensitive at windows environment, event a right click can cause the audio or video playback become stuttering.:(

If you're using a batch file, you can set the program's priority via switches

eg:
start /w /BelowNormal mencoder.exe

the /w means it will wait until it's finished before running the next command

[hellfred]

Originally posted by Yong
New questions:
Sorry for the OT,
1. How disable video output at two-pass first-pass encoding in mencoder
(like XviD encoding, the first pass video may be large or equal to source video)?

2. It's the MPlayer have an option too raise the apps priority?
mplayer might be too sensitive at windows environment, event a right click can cause the audio or video playback become stuttering.:(
I do not have a better answere than nexx for question #2 on win32.
On linux you can set the priority with the nice command
See e.g. this page (http://www.bunkus.org/dvdripping4linux/single/index.html#tc_mplayer_preview1) and man nice.
Now for Question #1. If you encode in any sort of linux/unix like environment, so MSYS or cygwin on Win32, you can put the output in the file /dev/null. /dev/null is like a black hole: everything you write there just vanishes. Performance on linux should be quite well, no idea what it is like on win32. What i have read in the mencoder manpage up to now indicates that there is no way to discard the output for the first pass other than sending it to /dev/null.
mencoder -o /dev/null -oac ...

Hellfred

[Leak]

Originally posted by hellfred
Now for Question #1. If you encode in any sort of linux/unix like environment, so MSYS or cygwin on Win32, you can put the output in the file /dev/null. /dev/null is like a black hole: everything you write there just vanishes. Performance on linux should be quite well, no idea what it is like on win32.

That would be "NUL:", as in "echo foo >NUL:"...

[hellfred]

Thanks for the tip, Leak.
"mencoder -o NUL:" works like a charm
Hellfred

[Yong]

great thanks for you, guys!!
@hellfred:
I have cygwin install on my computer, but dunno how to use...
(ok ok, enough off-topic already... Stop here);)

[DeepDVD]

It's kinda strange but all those new experimental codecs coming up and getting more stable from time to time doesn't have the option of VBR encoding. I can't really compare 2 clips without using the same kind of handling the bitrate... It's very frustrating ... :angry:

[RadicalEd]

Is it just me, or is celtic's 10/22 build not outputting files? :O 10/27 doesn't have x264 enabled and I can't test 10/31 due to lame processor. Still trying to get mingw to compile it myself so I can cross-check

[akupenguin]

@DeepDVD:
It's not so strange when you consider that the optimal ratecontrol algorithm depends on the characteristics of the compressor, and a suboptimal ratecontrol is no better than constant quant for a quality per filesize tradeoff. You can't just paste in another ratecontroller. So it's both easier and more logical to make it first compress well at constant quant, and only worry about ABR when the low-level algorithms have stabilized.
That said, if you're complaining in this thread, you're probably using ffdshow, and just haven't noticed that it has a weird interface for x264's 2pass mode.

[celtic_druid]

MEncoder dev-CVS-041026-20:10-3.4.2 (C) 2000-2004 MPlayer Team
Available codecs:
copy - frame copy, without re-encoding. Doesn't work with filters.
frameno - special audio-only file for 3-pass encoding, see DOCS.
raw - uncompressed video. Use fourcc option to set format explicitly.
nuv - nuppel video
lavc - libavcodec codecs - best quality!
vfw - VfW DLLs, currently only AVID is supported.
qtvideo - QuickTime DLLs, currently only SVQ1/3 are supported.
xvid - XviD encoding
x264 - H.264 encoding

Not enabled?

Just tested the 26/10 and the 22/10 tbird builds (on a athlon 800) and they both seem to work fine. Only re-encoded a 10sec avi clip. -ovc x264 -oac copy -o out.avi.

[RadicalEd]

Hm... faulty bug report. I'm not sure where the no-x264 build of mencoder I was using came from. No output must have been a problem with my settings, because the simple -ovc x264 -o out.avi works alright...
Sorry bout that :/

[bond]

i just tested celtic_druid's latest athlonxp compile (12/23) and it always crashes here in msvcrt.dll (winme) when encoding with x264 (lavc mpeg4 works fine).
i also tested his 10/26 tbird build (as it was reported to be working correctly) and it indeed works here (so something must be b0rked in x264's code currently)
edit: 12/12 tbird compile works too

i have a pentium3 866mhz (nice, i know :D )


EDIT: and in case someone didnt realise it till now, its possible to decode avc streams created by x264 (mencoder) with the freely available avc directshow decoder of videosoft (even if the streams are using CABAC, Deblocking and B-Frames (2 in a row) combined) when using the VSSH fourcc in avi!
great stuff!!! :)

[bond]

my findings:

- RC matches the desired bitrate very accurately (missed by 1kbps in my samples)
- quality very good (comparable to xvid, if not better)
- deblocking seems to be good, but smooths too much in fast moving background+still foreground scenes (eg matrix1: neo in front of the weaponshelf)
- not sure if b-frames help quality atm, will have to check that more closely
- mencoder outputted two frames too much (mpeg4ip's avi2raw tool reports two zero lenght frames too) there seems to be the correct framenumber in the .log files
- when setting 2 consecutive b-frames they are not adaptively set, but i assume thats the expected behaviour
- pretty fast, mencoder displayed 4fps encoding speed with b-frames, cabac and deblocking enabled with my pentium3 866mhz

all in all: very nice! :)

[celtic_druid]

Older builds all used the same generic libx264.a, in newer builds the XP version got an XP optimised libx264.a and xvidcore.a as did the P4 version (optimised for P4 that is). That would probably explain the Athlon-XP version crashing on a P3.

[akupenguin]

Originally posted by bond
- deblocking seems to be good, but smooths too much in fast moving background+still foreground scenes (eg matrix1: neo in front of the weaponshelf) The solution there is not adjusting the deblocking, but rather adaptive quant.
- not sure if b-frames help quality atm, will have to check that more closely
- when setting 2 consecutive b-frames they are not adaptively set, but i assume thats the expected behaviour 1 consecutive B-frame isn't adaptive either.
I don't consider B-frames to be usable yet: scenecut detection doesn't work correctly with them (i.e. it will insert I-frames but not IDR, so no seeking). This will be fixed at the same time as I add adaptive B-frames, because it's really the same problem.
But aside from that, they do sometimes help compression. Even without adaptiveness, I've seen as much as +.4 dB psnr improvement for some videos, (and as low as -.5 dB for others).
I also haven't finished subpel motion refinement for B-frames. subq=5 is unaffected, but anything less is suboptimal quality.
- mencoder outputted two frames too much (mpeg4ip's avi2raw tool reports two zero lenght frames too) there seems to be the correct framenumber in the .log files This with B-frames? Known bug (I recently fixed the same bug in lavc). But that comes after the above issues.
- pretty fast, mencoder displayed 4fps encoding speed with b-frames, cabac and deblocking enabled with my pentium3 866mhz For whatever reason (unfinished subpel, no 4x4 modes, or just the increased number of SKIP blocks), I find that encoding is often faster with bframes=1 than without.

[bond]

Originally posted by celtic_druid
Older builds all used the same generic libx264.a, in newer builds the XP version got an XP optimised libx264.a and xvidcore.a as did the P4 version (optimised for P4 that is). That would probably explain the Athlon-XP version crashing on a P3. which build should i use? :confused:

Originally posted by akupenguin
The solution there is not adjusting the deblocking, but rather adaptive quant.hm, does x264 already offer adaptive quant? (btw xvid handles such scenes pretty good even without adaptive quant, dunno how exactly tough)
i noticed that the described behaviour is worse with deblocking, as streams with disabled deblocking didnt show the smoothing that strongly

I also haven't finished subpel motion refinement for B-frames. subq=5 is unaffected, but anything less is suboptimal quality. what do you mean exactly with "unaffected" and "anything less is suboptimal quality"?

This with B-frames? Known bug (I recently fixed the same bug in lavc). But that comes after the above issues.nope, this also happens with streams not using b-frames (tested it on two different encodes)

For whatever reason (unfinished subpel, no 4x4 modes, or just the increased number of SKIP blocks), I find that encoding is often faster with bframes=1 than without.hm, so i assume enabling b-frames, disables 4x4mv? are there any other limitations than the ones you listed atm?

also can you plz describe how to enable exactly the different macroblock types via commandline

also is it necessary to guess the constant quant for the firstpass or is it possible to use something like pass=1:bitrate=650 instead?

to get a better speed is it still possible to use different subq values for 1st and 2nd pass? if yes how big do you think can the difference be (eg for subq=5)?

also where exactly can i find the latest x264 sources? where do you upload them? mplayer cvs/svn, videolan cvs/svn...?

thx and keep up the good work :)

[celtic_druid]

Well I guess I will put a P3 build up. Probably won't be till tomorrow though. Other option is to compile it yourself or grab the latest from mplayerhq, that is assuming that it is compiled with x264 enabled.

[bond]

Originally posted by celtic_druid
Well I guess I will put a P3 build up. Probably won't be till tomorrow though.thx a lot! :)

Other option is to compile it yourself or grab the latest from mplayerhq, that is assuming that it is compiled with x264 enabled.well, i am not really the one to ask when it comes to compiling ;)

[bond]

ok i now did more quality tests:

- x264 introduced some green color all over the picture (which isnt there when encoding with xvid). it also doesnt seem to be decoder related, as both ffdshow (ffmpeg) and vssh's decoder show this greenish picture
- there seems to be a lot of "movement" in the background, which makes the picture look not really "quiet"
- comparing the detail preservation/sharpness, i would say that x264 is already clearly sharper than xvid in most scenes
- an exception is the already described still-foreground/moving-background smoothing, that xvid (as one of the few codecs existing) is able to handle in a very nice way
- when doing frame-by-frame comparisons, b-frames seem to introduce fluctuating quality (once more details than xvid, once less. i assume depending on whether you look at a b- or i/p-frame)
- in high(medium-high) motion scenes x264 blocks more and shows less details than xvid (even more with b-frames enabled), good seeable in the lobbyshootout (especially the flying wall-parts)
- eg the detailed walls in the lobby shootout seem to get encoded less detailed and more blocky in x264
- regarding flat surfaces (eg, walls) x264 tends to block a lot (ugly) in contrary to xvid, which managed to handle walls very nicely beginning with the introduction of its vhq modes (rdo) if i remember it right
- fog gets encoded more blocky in x264 than in xvid
- x264 shows by far less blocks on "not-flat-surfaces" (eg on edges) especially with deblock, still deblock doesnt seem to visually hurt the details noticably

note that i base these findings on the following settings used to encode the matrix1 scenes, doom9 also uses in his tests, at ~650kbps:
xvid: 1.01_Lanczos_hvs-best_VHQ4_ChromaMotion_QPel_GMC_Trellis_Bvops-2-default_AdaptivQuant
x264: mencoder20041212_Lanczos_Cabac_(no)deblock_alpha-beta:-3,-3_(no)Bvops-2_subq1/5

all in all:
highmotion, the background and flat surfaces (walls) need some tuning imho, the rest kicks ass :D

[bond]

and if anyone wants to try x264 with 2pass out him/herself, here is a sample commandline similar to the one i use (copy it to a .txt file, adjust the path/filenames, change the extension from .txt to .bat and execute the .bat)

"C:\path to\mencoder.exe" -ss 00:00:00.400 -frames 1000 -sws 9 -vf crop=720:416:0:82,scale=640:256,harddup "C:\path to\source.vob" -ovc x264 -x264encopts pass=1:qp_constant=22:cabac:deblock:frameref=3:subq=4 -o NUL: -passlogfile "x264_2pass.log"
"C:\path to\mencoder.exe" -ss 00:00:00.400 -frames 1000 -sws 9 -vf crop=720:416:0:82,scale=640:256,harddup "C:\path to\source.vob" -ovc x264 -x264encopts pass=2:bitrate=650:cabac:deblock:frameref=3:subq=5 -of avi -ffourcc VSSH -o output.avi -passlogfile "x264_2pass.log"you can read up the meaning of all the switches here (http://mplayerhq.hu/DOCS/man/en/mplayer.1.html)

i chose the VSSH fourcc to be able to play streams with b-frames with the videosoft decoder (but ffdshow also knows that fourcc)

[akupenguin]

Originally posted by bond
hm, does x264 already offer adaptive quant? no.

what do you mean exactly with "unaffected" and "anything less is suboptimal quality"? subq=5 runs the full motion search on all macroblock types. this is implemented.
subq<5 runs part of the motion search algorithm on all block types, then chooses the best type, then finishes the search on just the winner. I haven't implemented the finishing part for B-frames. So subq=1 will use only fullpel motion compensation for B-frames, and subq=3 will use only halfpel.

nope, this also happens with streams not using b-frames (tested it on two different encodes) I don't see it (MEncoder 1.0pre6, x264r72). Post commandline and samples?

hm, so i assume enabling b-frames, disables 4x4mv? are there any other limitations than the ones you listed atm? P-frames can still use 4x4mv, but B-frames (so far) only go down to 8x8.

Other limitations:
Non-adaptive direct mode (brute force decision produced about +.1 PSNR in one test encode.)
B-frames aren't kept as references. (No idea how much this would help.)
No weighted prediction (No idea how much this would help, though Ateme might give you an idea. But even JM doesn't do this well, so maybe not.)
Generally non-tuned. I think my fast B_Skip detector is too lenient, but it will take a lot of test encodes and CPU time to tweak it.

also can you plz describe how to enable exactly the different macroblock types via commandline With my latest patch (applied to mplayer a few minutes ago), the relevent options are 4x4mv (default=off), b8x8mv (default=on), and direct_pred (default=temporal).
Before (i.e. in your test), b8x8 was disabled.

also is it necessary to guess the constant quant for the firstpass or is it possible to use something like pass=1:bitrate=650 instead? You can use CBR for the 1st pass, but I usually see better results from qp_constant, even if it's significantly off from the 2nd pass bitrate.

to get a better speed is it still possible to use different subq values for 1st and 2nd pass? if yes how big do you think can the difference be (eg for subq=5)? Yes, that still works, and probably won't ever change. (Maybe when I extend 2pass to do more than ratecontrol.) I've seen good results even from subq=1:no4x4mv:nob8x8mv on the 1st pass. If you want to be conservative, then subq=3:no4x4mv. And theoretically speaking, I would expect that the only option to really matter on the 1st pass would be frameref, since it can affect scenecut detection. Even then, you don't lose too much from 1st pass frameref=1, except in special cases.

also where exactly can i find the latest x264 sources? where do you upload them? mplayer cvs/svn, videolan cvs/svn...? svn co svn://svn.videolan.org/x264/trunk x264

when doing frame-by-frame comparisons, b-frames seem to introduce fluctuating quality (once more details than xvid, once less. i assume depending on whether you look at a b- or i/p-frame) Really? I see more fluctuation in XviD, which uses quant 2 for P-frames and quant 4 for B-frames. Whereas x264 used a factor of 1.4, which I recently changed to 1.3.

x264: mencoder20041212_Lanczos_Cabac_(no)deblock_alpha-beta:-3,-3_(no)Bvops-2_subq1/5 recommended:
Bvops at most 1 until I finish adaptive decision.
frameref=3 or so on the 2nd pass. (larger numbers help slightly, but not worth the extra time except on anime.)

[Yong]

Originally posted by bond
i just tested celtic_druid's latest athlonxp compile (12/23) and it always crashes here in msvcrt.dll (winme) when encoding with x264 (lavc mpeg4 works fine).
i also tested his 10/26 tbird build (as it was reported to be working correctly) and it indeed works here (so something must be b0rked in x264's code currently)
edit: 12/12 tbird compile works too

i have a pentium3 866mhz (nice, i know :D )


EDIT: and in case someone didnt realise it till now, its possible to decode avc streams created by x264 (mencoder) with the freely available avc directshow decoder of videosoft (even if the streams are using CABAC, Deblocking and B-Frames (2 in a row) combined) when using the VSSH fourcc in avi!
great stuff!!! :)

The latest build mplayer2004.12.23P4.7z also crash for me(crash msvcrt.dll), when try to encode video with x264,
i'm on P4 2.4GHz, Windows XP machine,
Now i'm downloading the new mplayer2004.12.28P3.7z, but not sure it can work on my machine or not...

[celtic_druid]

Looks like there is a problem with all the builds from the 23rd and x264 encoding. I will put up some new builds. Will have the patch that akupenguin was talking about, plus x264r73 anyway.

[Yong]

Wow thanks!!!

[celtic_druid]

Ok, new compile seems fine. Think it was a case of an old header. Next issue could be audio output as the cvs appears to be in the middle of a change there. Anyway audio is working fine here both with dsound and win32.

[bond]

new compiles work fine (except pentium4 one, which crashes in mencoder.exe here)

[bond]

ak, could you reproduce the "greenish picture" problem i reported?
the nero decoder also shows that effect

Originally posted by akupenguin
I don't see it (MEncoder 1.0pre6, x264r72). Post commandline and samples?ok, i used the following commandline on cd's build from today:
mencoder.exe -frames 1000 matrix1.vob -ovc x264 -of avi -ffourcc VSSH -o mencoder.aviwhen encoding mencoder always reports "1 duplicate frame(s)!" at the beginning

when opening the file in virtualdub, 999 frames get reported
edit: when using the same commandline, but with "-ss 00:00:00.400 -frames 500 -noskip -sws 9 -vf crop=720:416:0:82,scale=640:256", 500 frames got outputted/reported in vd (so not one too few)

when extracting the video stream from .avi to raw with mpeg4ip's avi2raw tool, i get the warning "1 zero length frames ignored" and "998 video frames written"
on the 500 frames sample i got a "2 zero length frames" -> 498 frames

grab the sample here (http://mp4menu.sourceforge.net/download/sample.zip)
edit: added the 500 frames sample

on longer streams i encoded last time (7119 frames), the tool skipped 2 "zero length frames" too (never used b-frames)

[akupenguin]

Originally posted by bond
ak, could you reproduce the "greenish picture" problem i reported?
the nero decoder also shows that effect No, I don't see that either. (I've tried lavc and JM for decoding.)

ok, i used the following commandline on cd's build from today:
when encoding mencoder always reports "1 duplicate frame(s)!" at the beginning OK, that's a problem with mencoder's A/V sync algorithm, which is common when encoding from VOBs. It's not related to x264. If you know the source is good, use "-noskip -mc 0". If you need to let mencoder "correct" A/V sync, use "-vf harddup". (I'll add skip-frame encoding to x264 some time to make this more automatic.)

[bond]

so you are sure that there are no "zero length frames" in the two video samples i uploaded, mpeg4ip complains about?

Originally posted by akupenguin
No, I don't see that either. (I've tried lavc and JM for decoding.)i have uploaded a screenshot of the xvid encode showing the true color of the video, which you can compare to the two samples i linked to in my last post

grab it here (http://mp4menu.sourceforge.net/download/sample.png)

[akupenguin]

Originally posted by bond
so you are sure that there are no "zero length frames" in the two video samples i uploaded, mpeg4ip complains about? There are zero length frames, it's just that they were added by mencoder, not by x264. The mencoder doc says that these zero frames are no problem in avi, but should be avoided (using harddup) if you're going to remux.

[bond]

by analysing the raw avc streams with mpeg4ips h264.exe tool, i noticed that it seems as if there are always 1 more reference frame signalled than was used: eg if i set only 1 ref frame it says "num_ref_frames: 2", if i set 3 "num_ref_frames: 4", aso...

Originally posted by akupenguin
There are zero length frames, it's just that they were added by mencoder, not by x264. The mencoder doc says that these zero frames are no problem in avi, but should be avoided (using harddup) if you're going to remux.thx! i used the following cmdl: "C:\path\mencoder.exe" -ss 00:00:00.400 -noskip -mc 0 -sws 9 -vf crop=720:416:0:82,scale=640:256,harddup "C:\path\matrix1.vob" -ovc x264 -x264encopts pass=1:qp_constant=22:cabac:deblock:deblockalpha=-3:deblockbeta=-3:frameref=3:subq=4 -o NUL: -passlogfile "x264_2pass.log"(harddup for both passes), but there are still the two zero frames :(

[akupenguin]

oh, I know what's up: it's the mpeg2 decoder delay. The delay is reduced to 1 frame by using "-vfm ffmpeg" (as opposed to libmpeg2. which also has problems seeking (produces garbage for the next B-frame). I don't know why it's still the default).
I didn't notice this problem in my backups before, because I always go through huffyuv (now ffvhuff), which happens to fix it.

[bond]

using ffmpeg as decoder leads to that i get 3 zero length frames, compared to libmpeg2, which leads to 2 zero length frames with the same following cmdl (adding the proposed "noskip, harddup.." doesnt make a difference:
mencoder.exe -ss 00:00:00.400 -frames 100 -noskip -mc 0 -sws 9 -vf crop=720:416:0:82,scale=640:256,harddup "C:\path\matrix1.vob" -ovc x264 -of avi -ffourcc VSSH -o mencoder.avialso the greenish picture, plus the one too much reference frame signalling in the nal stays the same :(

[akupenguin]

Weirdness... it seems that -noskip sometimes (whenever there are B-frames?) adds null frames at the beginning. Try with harddup and -mc 0 but without -noskip.
You might try filing a bugreport, but most of the devs refuse to touch mencoder. I'm not sure I could fix it either.

Reference frame signalling is now fixed. (It was unconditionally allowing an extra ref for B-frames.)

Green tint is acknowledged. I don't know what's causing it.

[bond]

ok i tried the following: with the settings as mentioned above (-frames 100 and no (!!!) b-frames set (default setting)) with cd's latest compile (not using your latest updates):

- decoding with ffmpeg, no -noskip, with harddup: 1 zero length frame reported, also during encoding i get a "1 duplicate frame(s)" message (mpeg4ips avi2raw tool writes 98 frames of 100 frames)
- decoding with ffmpeg, using -noskip and harddup: 3 zero length frames reported, but no "1 duplicate frame(s)" message during encoding (97 frames written)
- decoding with ffmpeg, no -noskip, no harddup: 2 zero length, 1 duplicate frame (97 frames written)

- decoding with libmpeg2 and no -noskip, with harddup: no zero length frame reported! but during encoding "1 duplicate frames" (99 frames written)
- decoding with libmpeg2 and -noskip, with harddup: 2 zero length frames, no duplicate message (98 frames written)
- decoding with libmpeg2, no -noskip, no harddup: 1 zero length frame, 1 duplicate (98 frames written)



doing the math:
- not using -noskip leads to the removal of 1 (not zero length) frame (called "duplicate frame" during encoding) during encoding with both ffmpeg and libmpeg2 and outputting 1 frame too few independant of the zero frames issue
- using noskip on the other side also leads to that two frames of the output are zero length frames with both ffmpeg and libmpeg2

independant of using -noskip:
- using ffmpeg as decoder leads to that two frames of the output are zero length frames
- using libmpeg2 as decoder leads to that one frame of the output is a zero length frame

- using harddup removes 1 zero length frame with both ffmpeg and libmpeg2


if i didnt made a mistake thats the only solution fitting my findings

edit: adding/removing "-mc 0" gives exactly the same results

[bond]

and another thing: does x264 or mencoder automatically set the aspect ratio info in the avc bitstream?
if yes, how does this work?

i checked this as a x264 stream imported to .mp4 was played back anamorphically with nero, altough i didnt resize during the encoding process

[akupenguin]

Yes.

Mplayer/Mencoder can detect aspect from a variety of sources, in your case the mpeg2 headers. If mencoder can't detect aspect, it is assumed to be 1:1 SAR. You can force the input to be 1:1 SAR with "-noaspect", or you can override DAR with "-aspect #:#"
If you perform filtering (-vf crop,scale) that modifies these, it does the right thing: preserves SAR across crop, preserves DAR across scale. This computation is not disabled by -noaspect.
The encoder frontend (ve_x264.c) is always given a pixel resolution and a display resolution, from which it calculates SAR. It then passes SAR to libx264, which writes it in the header. There may be a little rounding involved here, since DAR is in units of integer pixels.

[Yong]

What's wrong with my x264 encoding option?

start /b /low /w mencoder %1 -noskip -nosound -o nul: -ovc x264 -x264encopts keyint=300:nocabac:no4x4mv:nob8x8mv:subq=0:pass=1: -passlogfile "x2642ndpass.log"

start /b /low /w mencoder %1 -audio-preload 2.0 -noskip -oac copy -o "%userprofile%\desktop\%~n1.avi" -ovc x264 -x264encopts keyint=300:pass=2:bframes=3:bitrate=1000 -passlogfile "x2642ndpass.log" -ffourcc X264

some stupid pose deleted...

I tried many time with the latest mplayer build, but no b-frame on output video...

[akupenguin]

Originally posted by Yong
I tried many time with the latest mplayer build, but no b-frame on output video...
Frame types are decided on the 1st pass. You didn't enable bframes there.

[Yong]

That's mean at the first-pass
CLI option need to add "...:bframes=3"?

[akupenguin]

yes.

And for now, use "bframes=1" instead of 3. Higher numbers don't yet help quality.

[Yong]

@akupenguin:
Thanks for the answers.:)
And for now, use "bframes=1" instead of 3. Higher numbers don't yet help quality.
Yeah, i tried with bframes=16, looks terrible:D

[Doom9]

uhh, shouldn't mencoder support AVI input? Here's what I'm trying to do

C:\temp\mplayer>mencoder d:\kill_bill_vol2\video_ts\killbill2.avi -ovc x264 -x264encopts keyint=300:frameref=3:bframes=1:deblock:deblockalpha=-3:deblockbeta=-3:cabac:subq=4 -o NUL: -passlogfile "x264_2pass.log". killbill2.avi is a wrapped AviSynth script (makeAVIS), that even bitchy MS tools accept. Yet mencoder only throws a
File not found: 'frameno.avi'
Failed to open frameno.avi
x264encopts is not an MEncoder option

Exiting... (error parsing cmdline)
There's no frameno.avi anywhere on my system, but it's not in the commandline so I don't understand why mencoder is looking for it. Likewise, x264encopts is a friggin mencoder option, it's definied right there on the manpage.

mencoder is a standard w32 compile right from the mplayer homepage. build 1.0pre6

[bond]

Originally posted by Doom9
killbill2.avi is a wrapped AviSynth script (makeAVIS), that even bitchy MS tools accept. Yet mencoder only throws a
File not found: 'frameno.avi'
Failed to open frameno.avi
x264encopts is not an MEncoder option

Exiting... (error parsing cmdline)
There's no frameno.avi anywhere on my system, but it's not in the commandline so I don't understand why mencoder is looking for it. Likewise, x264encopts is a friggin mencoder option, it's definied right there on the manpage.the frameno.avi thing has nothing to do with this. i also always get that message, its not a problem

whats causing your problem is more that i think the latest official compile might not support x264 already (or not completely), as it noted that -x264encopts is not an option mencoder understands
use the latest compile from celtic_druid here (http://celticdruid.no-ip.com/xvid/mplayer/), it works here for sure

[Doom9]

whats causing your problem is more that i think the latest official compile might not support x264 already (or not completely), as it noted that -x264encopts is not an option mencoder understandsGreat, then why is it on the manpage that comes with the build?

So I updated my winrar and got celticdruid's compile, now I'm stuck with a VIDEO: [AVIS] 640x272 16bpp 23.976 fps 0.8 kbps ( 0.1 kbyte/s)
[V] filefmt:3 fourcc:0x53495641 size:640x272 fps:23.98 ftime:=0.0417
Opening video filter: [expand osd=1]
Expand: -1 x -1, -1 ; -1 (-1=autodetect) osd: 1
==========================================================================
Cannot find codec matching selected -vo and video format 0x53495641.
Read DOCS/HTML/en/codecs.html!
==========================================================================

[bond]

i seems the default decoder doesnt recognize these files

try adding "-vfm ffmpeg,dshow,vfw", that will first try to decode the stream with ffmpeg, if this doesnt work it will try to decode it with dshow (will surely work if ffdshow is installed and the AVIS support option in the dshow decoder is enabled), than if that doesnt work will try to find a vfw decoder

[Doom9]

doesn't work either.

I got avs2yuv working though so I'm using that now.

BTW, the manpage says the following about x264 bitrate
bitrate=<value>

Sets the bitrate to be used in kbits/second (default: off). This is required if you want a CBR (constant bitrate) encode.

Yet, you have to specify a bitrate in 2 pass mode. I'm a bit confused though how to perform the first pass. Do I have to specify anything but pass=1 in the first pass, and pass=2:bitrate=mybitrate in the 2nd pass, or do I have to specify the bitrate in both passes?

[Sharktooth]

Doom9 are you going to update your codec comparison or yours is simply a x264 interest?:)

[Doom9]

Doom9 are you going to update your codec comparisonNot for at least half a year. Currently, x264 is not ready imho. Look at the problems above, then there's the b-frame issue (muxing and playback mostly so unrelated to the x264), rate control could still need some improvement according to bond, and of course usability ;)

[bond]

Originally posted by Doom9
Do I have to specify anything but pass=1 in the first pass, and pass=2:bitrate=mybitrate in the 2nd pass, or do I have to specify the bitrate in both passes?you have two possibilities:
either set a fixed quant for the first pass, which matches the average quant of your desired 2nd pass bitrate
or you set the desired bitrate in the firstpass too (meaning both passes aim at the same bitrate, 1st pass is cbr, 2nd pass vbr)
you could even do a third or more passes (like divx5's multipass option), but i think it might not be necessary

about the other options: aku posted some hints about what can be disabled in firstpass, when used in secondpass too, but generally i would use the same settings in the first as in the second pass (x264 is not really slow, so that shouldnt be a problem)

[Bogalvator]

I use something like

-x264encopts keyint=300:bframes=1:nodeblock:pass=1:qcomp=1:subq=1

in the fist pass and then something like

-x264encopts bitrate=???:keyint=300:bframes=1:nodeblock:pass=2:qcomp=1:direct_pred=1:subq=5

Probably sub-optimal, but fast (difference in quality is probably not noticeable anyway). If you're paranoid then you can set the pass option to pass=3 for the second pass, and run it twice (pass=3 is n-th pass encoding in mencoder) to do 3 passes.

Also, the ratecontrol in x264 is already excellent - test the above and you will see (not usually more than 3 kbps out in my tests on a reasonable length encode i.e. at least 1 hour)

You'll probably want to activate deblocking for lower bitrates (less than about 750kbps for 640x352 resolution) though I myself wouldn't go any higher than -3 (even that's sometimes too strong for my liking)

EDIT: Note the above will default to fixed quant encoding for the first pass

[Doom9]

what are allowable sizes for ip_factor, pb_factor, qp_step, rc_buffer_size and rc_buffer_init?

[hellfred]

Originally posted by Doom9
what are allowable sizes for ip_factor, pb_factor, qp_step, rc_buffer_size and rc_buffer_init?
akupenguin once (http://forum.doom9.org/showthread.php?s=&threadid=83039&perpage=20&pagenumber=3) pointed out that rc_buffer_size gives good results when set around 0.5-1 second worth of video bitrate for CBR, or 1-2 seconds worth of bitrate for multi-pass.
Meaning when you are doing your onpass with bitrat 450 kbits/second go for 225 kbits/second to 450 kbits/second, and to 450 kbits/second to 900 kbits/second for multipass encoding with same bitrate.

I am doing just a little bit of guess when it comes to rc_buffer_init, but i would set it to something near one times bitrate specified in rc_buffer_size when clip starts with a hard to encode sequence, so that rate controll can start distributing additional bits right away. If clip start with easy to encode frames go down to the default value of 1/4 time bitrate specified.

Hellfred

[akupenguin]

ip_factor: allows 1..10. sane values: 1.2 .. 1.5
pb_factor: allows 1..10. sane values: 1 .. 1.4
qp_step: allows 1 .. 51. sane values: 1 .. 3
rc_buffer_size: allows (bitrate/fps) .. bignum. sane values: (bitrate/2) .. (bitrate*2)
rc_buffer_init: I just changed this to be a fraction (0..1) (previously it was in units of kbit). I set the default to 0.25 because most movies begin with some seconds of blackness or otherwise no motion, so the buffer will quickly fill up anyway. It you're encoding a clip that starts right away, you might set rc_buffer_init to 0.5 or more. (Only matters for CBR.)

Meaning when you are doing your onpass with bitrate 450 kbits/second go for 225 kbits/second to 450 kbits/second, and to 450 kbits/second to 900 kbits/second for multipass encoding right, except that the units of rc_buffer_size are kbit, not kbit/second.

Also, the ratecontrol in x264 is already excellent - test the above and you will see (not usually more than 3 kbps out in my tests on a reasonable length encode i.e. at least 1 hour) Sure, it can accurately meet your specified average bitrate. That's easy. (I have no idea why WMV9 and VP6 have such issues with it.) But that doesn't mean it's good ratecontrol: The reason 2pass is better than 1 is that the codec can adjust the distribution of bits based on the complexity of the scene. And my distribution algorithm was mostly pasted from libavcodec, with only minor tweaks for H.264.

[giandrea]

Hello, I'm trying to compile the last SVN version of x264 (v80 if I remember correctly) with the last CVN snapshot of Mplayer, but it is giving strange errors:
#error We do not support old versions of x264. Get the latest from SVN.
So I was wondering if it is a known problem or if it is me doing something wrong.
Thank you,

giandrea

[akupenguin]

You must have an old version of x264.h somewhere. Make sure that the one actually included/linked is v80.

[giandrea]

Originally posted by akupenguin
You must have an old version of x264.h somewhere. Make sure that the one actually included/linked is v80.
Men, how could I be so stupid... after compiling x264 I replaced the old library file with the new one, but I forgot the include... :eek: :D
Thank you again,

giandrea

[Doom9]

ip_factor: allows 1..10. sane values: 1.2 .. 1.5
pb_factor: allows 1..10. sane values: 1 .. 1.4
qp_step: allows 1 .. 51. sane values: 1 .. 3What's the default for those?

[akupenguin]

ip_factor=1.4, pb_factor=1.3, qp_step=1
But there's no theoretical basis behind my defaults. I just took the settings for optimal PSNR with my current ratecontrol, and turned them down a notch.

[Doom9]

I have another question, regarding the (no)4x4mv parameter. How does it work? I figured it would apply to all macroblock size and types listed in the manpage (i16x16, i4x4, p16x16, p16x8, p8x16, p8x8, p8x4, p4x8, p4x4, skip), so if I for instance don't want to have 16x16 macroblocks in I-frames, I'd use "noi16x16mv", but that doesn't appear to work. So how does that option work?

[bond]

i talked to aku about that yesterday and the man page has been updated accordingly making the options more clear :)

the possible options are:
- nob8x8mv
- b8x8mv
- no4x4mv
- 4x4mv

(no)b8x8mv:
Use additional macroblock types b16x8, b8x16, b8x8 (default: enabled). Without this option, B-frames will use only types i16x16, i4x4, b16x16, skip, di- rect. See 4x4mv for details.

(no)4x4mv:
Use additional macroblock types p8x4, p4x8, p4x4 (default: disabled). Without this option, P-frames will use only types i16x16, i4x4, p16x16, p16x8, p8x16, p8x8, skip.

[bond]

akupenguin, i now encoded a stream with the by syskin updated vfw wrapper for x264 (code from today), with b-frames, mref3, loop, cabac and subp5 and when extracting the stream again to raw with the avi2raw tool, i get the "warning: one zero length frame ignored" message, and it outputs one frame less than there should be outputted
edit: when using 2 b-frames the message says "two zero length frames..."
when disabling b-frames that error message is gone

now, as this doesnt really fit into the mencoder results (which was able to avoid the zero length issue even with b-frames) i dunno whether this is caused by x264 itself, or the vfw interface not able to handle b-frames 100% correctly or virtualdub (which always had a problem with outputting frames at the end of the stream, i assume its the same here too)

[bond]

Originally posted by akupenguin
Reference frame signalling is now fixed. (It was unconditionally allowing an extra ref for B-frames.)it still says one too much

i encoded with 1 b-frame and 3 reference frames and the nal looks like that:
Nal length 23
ref 3 type 7 Sequence parameter set
profile 4d
constaint_set0_flag: 0
constaint_set1_flag: 0
constaint_set2_flag: 0
level_idc: 21
seq parameter set id: 0
log2_max_frame_num_minus4: 5
pic_order_cnt_type: 0
log2_max_pic_order_cnt_lsb_minus4: 6
num_ref_frames: 4
...when using 2 b-frames, it says the same (4)

when disabling b-frames it says "3" as it should be

[akupenguin]

Originally posted by bond
it still says one too much

i encoded with 1 b-frame and 3 reference frames and the nal looks like that:
num_ref_frames: 4
when using 2 b-frames, it says the same (4)
That is correct. The x264 option "frameref" sets the number of references used in a P-frame. B-frames have one more than that (the future P-frame.)
It is possible that some other distribution of references would produce better compression per CPU cost, but until I run that comparison, this is the most logical implementation.

[bond]

Originally posted by akupenguin
That is correct. The x264 option "frameref" sets the number of references used in a P-frame. B-frames have one more than that (the future P-frame.)ah yes of course, thx for the info :)

[hellfred]

Originally posted by bond
akupenguin, i now encoded a stream with the by syskin updated vfw wrapper for x264 (code from today), with b-frames, mref3, loop, cabac and subp5 and when extracting the stream again to raw with the avi2raw tool

Bond, where to get the updated vfw wrappper. Comparing latest svn checkout of x264 (rev82) with older checkouts(rev72) showed not changes.
And i can not access the x264 mailing list archive (http://www.via.ecp.fr/via/ml/x264-devel/index-en.html) for 2005 right now.

Hellfred

[bond]

Originally posted by hellfred
Bond, where to get the updated vfw wrappper. Comparing latest svn checkout of x264 (rev82) with older checkouts(rev72) showed not changes.
And i can not access the x264 mailing list archive (http://www.via.ecp.fr/via/ml/x264-devel/index-en.html) for 2005 right now.it hasnt been in the x264 svn till now as syskin hasnt finished it till now (wants to make 2pass working too, aso)

you can find his latest binary and source here (http://homepages.ihug.com.au/~syskin/x264/)

[akupenguin]

Originally posted by bond
i now encoded a stream with the by syskin updated vfw wrapper for x264 (code from today), with b-frames, mref3, loop, cabac and subp5 and when extracting the stream again to raw with the avi2raw tool, i get the "warning: one zero length frame ignored" message, and it outputs one frame less than there should be outputted.
B-frames in vfw need application support. Virtualdub knows about divx/xvid delayed frames, and doesn't mux them. I assume that it doesn't treat x264 specially.

[hellfred]

Originally posted by akupenguin
B-frames in vfw need application support. Virtualdub knows about divx/xvid delayed frames, and doesn't mux them. I assume that it doesn't treat x264 specially.
So one needs to use a codec that knows of bframes to decode the stream to raw frames. Maybe using a AVISynth Script to open the avi with DirectShowSource (if you use latest ffdshow with updated h264 decoding) or AviSource (using the same and enabling it to decode h264 for vfw, too= will work for you then.

Hellfred

[bond]

akupenguin referred to the problems of b-frames with vfw (vfw cant by itself not handle b-frames). there have been workarounds developed to make b-frames work in vfw. syskin is at it to add these to x264 vfw too, like they exist for xvid

[Yong]

What problem with my x264 encoding options? During first-pass, mencoder display some message:
buffer underflow -xxxxx...
Will it hurt quality?

start /b /low /w mencoder %1 -noskip -nosound -o nul: -ovc x264 -x264encopts keyint=300:nocabac:no4x4mv:nob8x8mv:subq=0:bframes=2:pass=1:bitrate=600 -passlogfile "x2642ndpass.log"

start /b /low /w mencoder %1 -audio-preload 2.0 -noskip -oac copy -o "%temp%\temp.avi" -ovc x264 -x264encopts keyint=300:frameref=5:deblockalpha=-3:deblockbeta=-3:ip_factor=1.4:
pb_factor=1.3:cabacidc=2:scenecut=40:idrint=2:cabac:4x4mv:b8x8mv:
direct_pred=2:subq=5:qp_step=6:rc_sens=1:qp_min=26:qp_max=51:
pass=2:bframes=2:bitrate=600 -passlogfile "x2642ndpass.log" -ffourcc X264

EDIT:
Disable smilies to prevent a** appear:D

[akupenguin]

Originally posted by Yong
What problem with my x264 encoding options? During first-pass, mencoder display some message: buffer underflow -xxxxx...
Will it hurt quality? That means the CBR ratecontrol couldn't meet your specified bitrate (for some scene) due to the qp_min=26. It will not hurt quality unless your 2nd pass decides to use quants < 26.

[Doom9]

rc_buffer_size: allows (bitrate/fps) .. bignum. sane values: (bitrate/2) .. (bitrate*2)Whats a bignum? long aka 64 bit integer? thanks for indicating all the sane values btw..

[akupenguin]

The specific definition of bignum is an infinite precision integer type. I was using the more general definition of some number that's big enough that you don't have to know exactly what it is. In this case, rc_buffer_size is actually stored in a 32bit signed int. x264 places no further limits, while mencoder (for no particular reason) limits it to 24e6 (measured in kbit, so that converts to 188 MiB).

[Yong]

@akupenguin:
Thanks for the replies:)
(looks like here is x264 support center):p

What's the meaning by this?
bits<0.9
mencoder print alot of this word at the beginning of second pass.
(the x264 encoding option is same as my last post)

Again, thanks for your replies:)

[akupenguin]

Originally posted by Yong
bits<0.9
That means you had some size 0 frames (absolutely no motion) and my ratecontrol complained. It should have no side-effects, and I removed the message on 2005-01-05.

[bond]

Originally posted by bond
ok i tried the following: with the settings as mentioned above (-frames 100 and no (!!!) b-frames set (default setting)) with cd's latest compile (not using your latest updates):

- decoding with ffmpeg, no -noskip, with harddup: 1 zero length frame reported, also during encoding i get a "1 duplicate frame(s)" message (mpeg4ips avi2raw tool writes 98 frames of 100 frames)
- decoding with ffmpeg, using -noskip and harddup: 3 zero length frames reported, but no "1 duplicate frame(s)" message during encoding (97 frames written)
- decoding with ffmpeg, no -noskip, no harddup: 2 zero length, 1 duplicate frame (97 frames written)

- decoding with libmpeg2 and no -noskip, with harddup: no zero length frame reported! but during encoding "1 duplicate frames" (99 frames written)
- decoding with libmpeg2 and -noskip, with harddup: 2 zero length frames, no duplicate message (98 frames written)
- decoding with libmpeg2, no -noskip, no harddup: 1 zero length frame, 1 duplicate (98 frames written)



doing the math:
- not using -noskip leads to the removal of 1 (not zero length) frame (called "duplicate frame" during encoding) during encoding with both ffmpeg and libmpeg2 and outputting 1 frame too few independant of the zero frames issue
- using noskip on the other side also leads to that two frames of the output are zero length frames with both ffmpeg and libmpeg2

independant of using -noskip:
- using ffmpeg as decoder leads to that two frames of the output are zero length frames
- using libmpeg2 as decoder leads to that one frame of the output is a zero length frame

- using harddup removes 1 zero length frame with both ffmpeg and libmpeg2


if i didnt made a mistake thats the only solution fitting my findings

edit: adding/removing "-mc 0" gives exactly the same results ok i now noticed something similar with direct .avs input (source has 50 frames):
- no matter if i use b-frames or not the output always adds one frame to the input (51 frames in the case that no b-vops are used)
- it seems the last frame is double and that last frame is not a zerolength frame

- using 1 b-frame in a row leads to that additionally 1 frame less gets outputted (51-1 = 50 frames)
- using 2 b-frames in a row leads to that additionally 2 frames less gets outputted (51-2 = 49 frames) aso...

- using "-mc 0", "-noskip" and "-vf harddup" doesnt change this behaviour
- using avi or rawvideo output doesnt change this behaviour


somehow i have the feeling mencoder isnt really working 100% correctly :D

[Doom9]

Has anybody else with an Athlon64 noticed that when mencoder lists the cpu flags, it doesn't list either sse or sse2 as present. consequently it seems both athlonxp and amd64 builds from celticdruid do not use the full potential of the cpu, and run at the same speed.

[virus]

@Doom9:

well, this is what I see with my build on my P4 (same output with celtic_druid's one):
MEncoder dev-CVS-050218-20:59-3.2.3 (C) 2000-2005 MPlayer Team
CPU: Intel Pentium 4/Xeon/Celeron Foster (Family: 8, Stepping: 7)
Detected cache-line size is 64 bytes
CPUflags: Type: 8 MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 0 SSE2: 0

[Doom9]

virus: that's also incorrect. to at least the sse detection is b0rked. Here's the output from the athlon xp compile:

CPU: Advanced Micro Devices (Family: 8, Stepping: 0)
Detected cache-line size is 64 bytes
CPUflags: Type: 8 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 0 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE

and here from the amd64 compile

CPU: Advanced Micro Devices (Family: 8, Stepping: 0)
Detected cache-line size is 64 bytes
CPUflags: Type: 8 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 0 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2

makes one wonder, doesn't it?

[celtic_druid]

It isn't just me. Every build that I have ever tried from numerous different sources always has 0 for SSE/SSE2.

[Doom9]

Every build that I have ever tried from numerous different sources always has 0 for SSE/SSE2.so another confirmation that something is wrong. I'm just wondering if the detection has anything to do with enabling/disabling of any optimized codepaths. I guess I need to run a longer test of the two builds that work on my box and see if the build that ought to use sse2 actually is faster.

[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...?