x264 development

[Yong]

Is the x264.exe(using default options) accept the yuv4mpeg(using mpalyer -vo yvu4mpeg) format?
since x264 is able to encode the yuv file,
but playback is funny,
the video is scrolling:D :D :D
from left to right...
my own compiled x264 don't have avis-in and mp4-out support,
because i have some problem to compile gpac...
and avis-in only avialable for cygwin, which is "b0gus" for me.
when i try to compile x264 with cygwin, it's pup-up some message: unable to locate "cyg.....something.dll", arrrrgh:devil:

more stup1d questions: why avis-input available for cygwin?
i will post gpac compiling problem later:)

[Manao]

> the video is scrolling

You didn't enter the correct resolution for the input video, perhaps ?

> and avis-in only avialable for cygwin

Making it available for msvc is more than easy : link with vfw32.lib, and in x264.c, include windows.h, vfw.h and define AVIS_INPUT.

[Yong]

@Manao:
my simple x264(r196) cli options:
start /low /b /w X264 -o "%userprofile%\desktop\%~n1.264" %1 320x240
The yuv file info:
YUV4MPEG2 file format detected.
==> Found video stream: 0
YUV4MPEG2 Video stream 0 size: display: 320x240, codec: 320x240
VIDEO: [YV12] 320x240 12bpp 30.000 fps 0.0 kbps ( 0.0 kbyte/s)
[V] filefmt:12 fourcc:0x32315659 size:320x240 fps:30.00 ftime:=0.0333
When playing the raw h264 stream:
Cache fill: 10.16% (851968 bytes) H264-ES file format detected.
==> Found video stream: 0
Searching for sequence parameter set... OK!
Searching for picture parameter set... H264: 0x168
OK!
Searching for Slice... OK!
FPS seems to be: 250000/10000
[V] filefmt:30 fourcc:0x10000005 size:0x0 fps:25.00 ftime:=0.0400
what's wrong with it?

btw thanks for the msvc tips, but i know nothing about programming...:p

[ak]

I think x264 expects raw yuv, which you can get with, say,

> mencoder in.avi -nosound -ovc raw -vf format=i420 -of rawvideo -o oyt.yuv

or 'ffmpeg -i in.avi out.yuv'

[Yong]

@ak:
omg...
(i wonder why using -vo yuv4mpeg2 and the result video is scrolling...)
it's work :)
thanks:D :D :D

[bill_baroud]

(because yuv4mpeg2 as a little header ? so it doesn't read the correct data if it's expecting a raw frame. well that's pure speculation from my side)

[Stacey Melissa]

@Yong - Would Avisynth input be an option for you when using the CLI? It works well for me, and I don't even have to specify the input resolution.

In fact, I'm glad I tried the CLI out, since it seems to be just as easy to use as mencoder, plus it doesn't have the quirks with aspect ratio support, or the extra frame at the end of every encode.

@Sharktooth - I had already been using bitrate*2 for the rc_buffer. (Mencoder's default is bitrate*1.) I'm testing out further adjustments to see if that helps any. As for rceq, I have no idea how I could use that to enforce a bitrate ceiling.



One other thing, while I'm thinking of it... I checked to see that the CLI exposes all the same options that mencoder does. According to the CLI's help screen, there is no way to turn off chroma ME. But --no-chroma-me will turn it off. There also is no mention of a way to set the CABAC IDC, and I couldn't figure out anything either. Besides those two missing items, the CLI has everything mencoder does, and then some. Quite a few of the defaults are different, though. Looks like I'll be using CLI instead of mencoder from here on out. :)

[CREXbzh]

Originally posted by Stacey Melissa
One other thing, while I'm thinking of it... I checked to see that the CLI exposes all the same options that mencoder does.
Just so you know, akupenguin is the guy who's maintaining the x264 section of MEncoder, so it should always be up-to-date and a reliable source of informations.:)

[Yong]

@bill_baroud:
May be,i see some human readable character:
"YUV..." something at the start of the file.(when loading it to hex editor) mplayer also can decode it without any options used.
but this one completely is a raw video files:
mencoder in.avi -nosound -ovc raw -vf format=i420 -of rawvideo -o out.yuv:p

@Stacey Melissa:
I do something stupid before i compiling the x264:rolleyes:
so the x264 won't work...
and now my own compiled x264 work without problems:D

@x264 devs:
Is possible make the x264vfw/mencoder output video frames to mp4?:cool:
Just like the ffvfw, can override the video encoding apps options.
(Because i've heard a lot of bad things about vfw...
and may be the VDub will never support mp4, i hope this just a rumour...):D
Sorry, too many feature requested...:p

edit: cr@zy grammar error and typo..

[Doom9]

mencoder will eventually be able to write mp4 using the libavformat (but so far it's not quite complete yet). Considering the commandline x264 supports AviSynth input and mp4 output... what's wrong with using it?

[Yong]

@Doom9:
Nothing wrong with it,
i don't like avisynth(i'm newbies, still learn how to use avisynth :p), but i need it:rolleyes:
because of x264.exe...
mp4 output is great:cool:

[TheUnforgiven]

cant wait for a CLI build with AVS and MP4 support :(

[Yong]

Originally posted by TheUnforgiven
cant wait for a CLI build with AVS and MP4 support :(
Then Do It Yourself:D,
search this forum for "compiling x264"...
If you have any question please PM me,
But don't expect too much,
i'm newbies only
:D

[TheUnforgiven]

since a lot of members sure have done this already, sharing the build will save a lot of duplicate work for the other members.

[Yong]

I know, but if you want to test the latest functions,
DIY, compiling it is very easy.
shouldn't take too much time to learning it.:)
but downloading time is needed, the mingw filesize is 50359 kb...

[Kurtnoise]

I made a short compile from the last rev (201 right now). Here is the file (http://kurtnoise.free.fr/x264/x264_r201.zip). But only with avs input support. I've an error message during my compilation when I enable the mp4 output support. :(

Compile with minGW. Here is the error message :
gcc -o x264 x264.o libx264.a -lvfw32 -lm4systems_static -lwinmm
c:\MinGW\bin\..\lib\gcc\mingw32\3.4.2\..\..\..\..\mingw32\bin\ld.exe: cannot find -lm4systems_static
collect2: ld returned 1 exit status
make: *** [x264] Error 1

So, if anyone I've an idea to resolve this issue...



Btw, I've a question : for a simple windows users like me :D , what's version is recommended ? The CLI or the VFW ? I noticed that the command line version provide more settings. Is it useful to use it right now ?

Thanks.

[Yong]

@Kurtnoise13:
compiling x264 with mp4-output need GPAC (http://gpac.sourceforge.net/),
just download it from CVS and compile it.
After done compiling,
1. copy the "libm4systems_static.a"
to mingw\lib,
2. copy the folder "GPAC" form "GPAC\include" to mingw\include.
3. type "make clean", "configure" x264 again, and "make --eanble-avis-input --enable-mp4-output"
4. done:D

i preffer cli version of x264, more options to play and mp4 out:cool:

[Kurtnoise]

I can't compile gpac...It needs some external dependices. Too hard for me. So, for the moment you can use my compile and then mp4box to mux the file.


/me waiting Celtic_Druid compile...:p

[Yong]

@Kurtnoise13:
u use cygwin?
I try to use cygwin to compile GPAC,
but:
bash: ./configure permission denied :rolleyes:
dunno what's wrong with it...
Try msys instead:D
It needs some external dependices
DLL?

[Bogalvator]

Yong, perhaps the GPAC folder is specified as read-only?

Also, GPAC needs zlib to compile:
http://www.zlib.net/

[Sharktooth]

My latest build (rev202) supports both AVS input and MP4 muxing.
As usual it's here: http://forum.doom9.org/showthread.php?s=&threadid=89979
Can someone extensively test it and report back please?

[namchik]

Originally posted by Sharktooth
My latest build (rev202) supports both AVS input and MP4 muxing.
As usual it's here: http://forum.doom9.org/showthread.php?s=&threadid=89979
Can someone extensively test it and report back please?
Thanks for your daily.. gonna try it
BTW, why mmx-build only? :confused: i guess 99% of people here have at least sse-optimized CPU's... :rolleyes:

[yaz]

Originally posted by namchik
Thanks for your daily.. gonna try it
BTW, why mmx-build only? :confused: i guess 99% of people here have at least sse-optimized CPU's... :rolleyes: because the users wont gain anything from it (~2-3% if any) but it would double (triple) the efforts of the 'releaser'. imho, it's simple as that ;)
thx
y

[Sharktooth]

My MMX build is 8-10% faster than default builds yet.
Adding SSE or SSE2 only gives a speed increase of about 1%.
The reasons are:
1) the most complex codec parts are written in ASM. So optimizing the C compiler flags doesnt give a significative speed increase.
2) when using SSE, -ffast-math must be disabled
3) -mfpmath=sse is faster than -ffast-math only in certain "situations" but there's no big margin because of 1)

[namchik]

Originally posted by Sharktooth
My MMX build is 8-10% faster than default builds yet.
Adding SSE or SSE2 only gives a speed increase of about 1%.
The reasons are:
1) the most complex codec parts are written in ASM. So optimizing the C compiler flags doesnt give a significative speed increase.
2) when using SSE, -ffast-math must be disabled
3) -mfpmath=sse is faster than -ffast-math only in certain "situations" but there's no big margin because of 1)

thanks 4 the explanation.
but frankly speaking i didn't understand paragraphs 2 and 3 at all :rolleyes:

[Sharktooth]

They're both compiler flags for optimizing performance.

[Sirber]

Originally posted by namchik
thanks 4 the explanation.
but frankly speaking i didn't understand paragraphs 2 and 3 at all :rolleyes: Have fun here (http://gcc.gnu.org/onlinedocs/gcc-3.3.5/gcc/Optimize-Options.html#Optimize-Options)! :D

[easyfab]

Originally posted by Sharktooth

3) -mfpmath=sse is faster than -ffast-math only in certain "situations" but there's no big margin because of 1) [/B]


Sharktooth have you give a try to -mfpmath=sse,387 , it should give better speed (less stability?) because it allows the 2 units x87/MMX and SSE to work in same time.

[Sharktooth]

It crashes when encoding on my system. So i think it's not safe.

[akupenguin]

All those fp settings make negligible difference, not because of the ASM, but because x264 doesn't use any floating-point outside of ratecontrol.

[Sharktooth]

Yep, but there are some SSE(2) integer instructions that are faster than MMX. However the speed gain is negligible.

[IgorC]

I read that H.264 was developed on base of variables of only 16 bits
not compilation 32 bits - float or double. So SSE instructions are useless

[bill_baroud]

with SSE, you can put 8 words (16bits) in one register (128bits) and process them in parallel ... so no, SSE instructions aren't useless at all (well if they can serve h264 purpose, and it should be the case imho).

[Manao]

bill_baround : actually, SSE only do parallel floating point. What is interesting however is SSE2, which does what you're describing. But the speed gain is far less than the one between plain C and MMX, because the memory access time is already the bottleneck for MMX, and SSE2 doesn't help in that regard.

[MacAddict]

Originally posted by Sharktooth
My latest build (rev202) supports both AVS input and MP4 muxing.
As usual it's here: http://forum.doom9.org/showthread.php?s=&threadid=89979
Can someone extensively test it and report back please? Is it just me or have the last couple of builds provided oversized encodes? Might be time for an XP reload:(

[bill_baroud]

hm, yeah, i was re-reading the docs this morning, and saw that i misunderstood the integer SSE part...it use the MMX registers and not the SSE ones. Well the prefetch and cacheability control of SSE for mmx instructions are definitly a plus when memory access is a problem... i guess i'm far from being able to use those sets efficiently.

[Doom9]

Is it just me or have the last couple of builds provided oversized encodes? Did you consider that you're specifying the video bitrate whereas your output size depends on video bitrate + container overhead? Only XviD takes the container overhead (for AVI output) into account when you set a desired bitrate/size. at least in the cli encoder and mencoder, the encoder tells you the video bitrate at the end.. does that match your requested bitrate?

[Kurtnoise]

Hi,

I've request for x264 developpers. May I suggest the avi output type for the x264 CLI ? If I remember, there is already a tool for the conversion : avc2avi. So, merge it directly into x264 core will be great. ;)

Thanks.

[Yong]

Originally posted by Kurtnoise13
Hi,

I've request for x264 developpers. May I suggest the avi output type for the x264 CLI ? If I remember, there is already a tool for the conversion : avc2avi. So, merge it directly into x264 core will be great. ;)

Thanks.
afaik mux AVC to avi is a bad idea...
why not matroska? ;)
the default container fomrat for avc is mp4...
you better go to here "irc://freenode/x264" and ask;)
if you really need this function, then try mencoder:)

[Kurtnoise]

Originally posted by Yong
afaik mux AVC to avi is a bad idea...
I don't think so...

Originally posted by Yong
why not matroska? ;)
because we can't mux raw avc streams into matroska.

Originally posted by Yong
the default container fomrat for avc is mp4..
I'm not sure...for x264 it seems to be raw h264. ;)


BTW, my request is not very important imho. There are lot of things more interesting to implement before.

[ChronoCross]

I think right now everyone is asking for muxing to every format. Here's my opinion.

Avi Muxing == bad idea
mp4 Muxing == good idea but I don't know much about mp4's container capabilities
mkv === I'd enjoy this the most. I love mkv because it's much more versitle than everything else.
Divx's media format === Really horrible atm. wouldn't use it even if they paid me.

[Yong]

@Kurtnoise13:
afaik avi cannot handle b-frame correctly...
(i can't remember, many reason...
where are you Bond, Manao or bobololo :p ? please explain... :D )
i thinks Sharktooth uploaded the cli x264 already can write video frames to mp4.:)
because we can't mux raw avc streams into matroska.
we need volunteers to do it:D

[Doom9]

why spend time on containers? both avs input and mp4 output was not done by the core developers.. if you need avi output, use mencoder or the VfW.. if you want mkv, use whatever input works for you. In fact, GK supports x264 and MKV, so...

[bond]

Originally posted by Doom9
why spend time on containers? both avs input and mp4 output was not done by the core developers.. if you need avi output, use mencoder or the VfW.. if you want mkv, use whatever input works for you. In fact, GK supports x264 and MKV, so... my words
its funny how people cry for supporting some things in a cli encoder and once its here people will surely cry for a gui to be able to use it ;) :D

[ChronoCross]

Well that's because most people who are encoding arent really doing it because they are trying to learn about encoding...rather they are doing it either for production(warez) or because some person thought it would be cool to try out....but most people are too lazy to read docs and whatnot to figure out what it does.

[Sharktooth]

I actually use the CLI encoder, but i would like to have something like Megui for x.264 CLI.
Why? Coz i have WINDOWS installed... not DOS...:)
Remark: I didnt say "I want"... just "I would like to have".

[Stacey Melissa]

Personally, I think anything beyond raw output is just an added bonus. I think the development focus for the forseeable future should really be on the codec itself. If that doesn't work for the warez people, well, tough shit, they shouldn't be doing that stuff anyway.

[Doom9]

but i would like to have something like Megui for x.264 CLI.To be perfectly honest, ever since the cli version got avs input and mp4 output I've been thinking about it.. but at least zoning will have to be done before that.. else I end up making an mp4 that I have to extract to raw and then mux into mp4 again just because people wanna encode credits separately.

But then of course there's also the issue with mencoder getting properly working mp4 output..

[Stacey Melissa]

I've been using a nifty little Excel spreadsheet to do all my calculations, then plugging a few resulting numbers into an even niftier batch file, which then automates practically everything, including command line generation, and even outputs a nice log file. Perhaps the best thing is that I don't have to make Doom9 all cranky with asinine feature requests and poor bug reports. I just fix the thing myself. :D

Still, though, it's long been an idea of mine to make sort of a power user's Recode-type interface to fully automate everything, yet offer manual control where desired, including some cool combing artifact cleanup features that no one has done yet, AFAIK. It's probably all a pipe dream, though, since I'm just a lowly web programmer by trade, and all this C stuff tends to boggle my poor little mind. :p

[Stacey Melissa]

As previously mentioned, I've been trying to achieve lower maximum bitrates without compromising too much on the qcomp value. Per Sharktooth's suggestion, I've been adjusting the rcbuf value, and the results so far have been just the opposite of what I had expected. It turns out that the correlation between rcbuf and max bitrate is positive.

qcomp rcbuf max bitrate
---------------------------
.65 900 7677
.65 1800 7825
.65 3600 8610
.65 5400 8852
.70 900 8246
.70 1800 8380
.70 3600 8505
.70 5400 8710
.75 900 8837
.75 1800 8975
.75 3600 9190
.75 5400 9297
I've been reusing the first pass stats file for each of these encodes. The second pass uses all the same settings, except the varying qcomp and rcbuf. All encodes are done at 1800 kbps. The source is a 185770 frame, 720x352, 23.976 fps AVS from The Matrix: Revolutions. I find the max bitrate of each encode using mp4box -info on the video track of the .mp4.

5.1 channel vbr-streaming HE-AAC is played using the 10/12/2004 ffdshow, and is output as DD5.1 through SPDIF. No pre- or post-processing is done to the audio. Right off the top, the audio sucks up 20-25% of the available CPU cycles from the Athlon XP 1800+. The splitter and video decoder are the latest from Nero, with all PP disabled. WMP10 is used for playback.

Problematic playback areas are during the yellow explosion at the beginning; small parts of the firefight between the APUs and sentinels; and the final battle between Neo and Smith, from when they first contact each other, through the first "mushroom cloud" of water they create.