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.

[MSlv]

About b-frames.
When using them, BSPlayer refuses to play the file and gives me this error message:
"List index out of bounds (0)"
Also, the same file acts strange in videolan. It shows artefacts like this:
http://img64.echo.cx/img64/9279/x264bfrvlc9bm.th.jpg (http://img64.echo.cx/my.php?image=x264bfrvlc9bm.jpg)

Same file plays fine in Media Player Classic.

[Mug Funky]

yet offer manual control where desired, including some cool combing artifact cleanup features that no one has done yet, AFAIK

this sounds interesting!

another thing i'd really love to see is a "segment re-encode" feature (maybe this is best suited to Virtualdub's interface?).

ie. you watch the movie, and note all the crappy bits. you then set I-frame (or IDR frame for AVC, i suppose) in and out points, and re-encode the bad part using the same GOP structure.

i know DVDMaestro offers this (and it's reeeeally nice to use if you've got the Spruce MPX3000 encoder card plugged in - seamless integration with the authoring app). it'd be good to see this built into an mpeg-4 solution - this would mean if your encode is undersized, it's not a problem. it also means if you're using a not-so-good encoder (WMV? Divx 3?) you can still get nice encodes if you re-do enough segments (this is exactly what the feature is for in Maestro - mpeg-2 isn't the best codec, and sometimes a client just wants so much video on a disc that the bitrates go way down).

well, this is also a pipe dream, but i'm sure lots of tweekers would find it useful (the kind who use YATTA for instance :))

[Stacey Melissa]

I hadn't heard of YATTA before. Judging from its description, it sounds like it gets about halfway there for what I was wanting to do to clean up combing artifacts. I'll have to check it out. Thanks. :)

And since you mention setting IDR frames... part of my pipe dream includes the ability to force IDR frames at specified frames. This would be used in combination with the Nero-style chapters that have been recently integrated into mp4box. Chapter seeking would be very fast if the chapter is always set on an IDR frame. Anyway, that would be something nice to have built into x264, although not essential.

And another cool feature to have in x264 would be the ability to use different deblocking strengths for different zones. Maybe that was already planned anyway? I think I've done maybe 30 or 40 encodes of Matrix3, and no matter what x264 parameters I set, I can't get rid of that damn horrendous blocking behind Merv on his balcony. But if I could jack up the deblocking strength to, say, 6, just for that scene, then I'd consider that progress. :D That would at least be one possibility for improving such troublesome scenes. Other possibilities all have to do with fancy AVS wizardry, so I suppose I'll save 'em for another thread. :p

[Doom9]

part of my pipe dream includes the ability to force IDR frames at specified frames. This would be used in combination with the Nero-style chapters that have been recently integrated into mp4box.Is that really necessary? After all, if the playback filter cooperates, you can easily jump to any given frame regardless of its frame type.

[Stacey Melissa]

Of course it's not necessary. It's part of my pipe dream! :p

What it would help with is just making chapter seeking more responsive.

[virus]

some problems here when using b-refs with revision 215... but that's likely a skipping issue so probably a long-standing one. Very weird artifacts due to exaggerate skipping, or maybe some probs with direct mode + brefs, dunno. Anyway, cmdline:

x264 -m 3 -b 3 --b-pyramid --frames 300 -q 27 -o x264-r215-brefs.mp4 ~/mplayer/main/test-2.avs

The result is available here (http://www.webalice.it/riccardo.stievano/video_stuff/x264-r215-brefs.mp4) (627 KB). Look at frames 200 and following. The mess on the woman's face is evident. Frame 230 (according to MPlayer's numbering, ffdshow's may differ) seems the worse.

I got a report (thanks to AlexW) that even decoding with JM the artifacts are there, so it's definitely an encoding issue. The quantizer of bvops is 28-29 here so nothing exceptionally low; not enough to justify such problems, at least. Similar problems happen (maybe even worse) when using -m 5 so it's not directly related to the ME type.

[bond]

Originally posted by virus
[B]some problems here when using b-refs with revision 215... but that's likely a skipping issue so probably a long-standing one. Very weird artifacts due to exaggerate skipping, or maybe some probs with direct mode + brefs, dunno.i can confirm that i get the same problem :scared:

i saw that especially with -q 20 -b 5 --b-bias 100 --b-pyramid


btw the new --progress option rocks! would be cool if it gets enabled by default :)

[akupenguin]

Originally posted by virus
some problems here when using b-refs with revision 215... but that's likely a skipping issue so probably a long-standing one. Very weird artifacts due to exaggerate skipping, or maybe some probs with direct mode + brefs, dunno.
Fixed. The encoding was correct. Only the header was wrong. Old references are forgotten in encoding order, not in order of display timestamp. So when references are reordered (pyramid), having a bigger DPB than expected can change the meaning of "L0 ref 1" to mean something other than what the encoder thought. I didn't notice because only the oldest ref is affected => not very many MBs in B-frames at frameref=8 or 16.

[rushin_911]

feature request: Choosing SAR values from the vfw version...

(I know I've asked that before in this same thread, but I hadn't mentioned the vfw version specifically and at the time this feature had already been introduced in the CLI version)

[Yong]

Why don'y use the CLI x264 encoder?
It isn't hard to use than vfw and more up-to-date imho.
But still i hope x264 devs or other contributors can update this vfw:)

@rushin_911:
You can transmuxing the video to MKV and changing the D/SAR via MKVtoonix.;)

I've tried with MKVToolnix, the D/SAR is ignore by ffdsohw(or haali matroska splitter?)...:rolleyes:
Only MPlayer is respect the MKV D/SAR value.

EDIT: nasty typo...

[Sirber]

I'm thinking about adding CLI in RealAnime, instead of only using the VFW one. Since it supports AVS, it will be easy to implement.

[rushin_911]

Originally posted by Yong
Why don'y use the CLI x264 encoder?
It isn't hard to use than vfw and more up-to-date imho.
But still i hope x264 devs or other contributors can update this vfw:)

@rushin_911:
You can transmuxing the video to MKV and changing the D/SAR via MKVtoonix.;)

I've tried with MKVToolnix, the D/SAR is ignore by ffdsohw(or haali matroska splitter?)...:rolleyes:
Only MPlayer is respect the MKV D/SAR value.

EDIT: nasty typo...

Well the reason for not using the CLI version is that I´m not very familiar with the command line environment...

As for the MKVtoolnix I already use the DAR values from it when muxing into MKV, unfortunatly though it´s, as you have stated, ignored by ffdshow even when enabling overlay and also ignored by Media Player Classic (my player of preference)...

My request for the SAR values to be visible in the VFW however are for when I mux the media files created into the MP4 format.

[Yong]

@rushin_911:
@echo off
IF '%1'=='' GOTO EOF
title X264 Encoder
start /belownormal /b /w X264 -p 1 --stats "%userprofile%\desktop\X264[%~n1].log" -o nul: %1 --progress
start /belownormal /b /w X264 -p 2 --stats "%userprofile%\desktop\X264[%~n1].log" -o "%userprofile%\desktop\%~n1.mp4" %1 --progress
pause
:EOF
save the above code to "x264.bat"
u can try to add other cli option if u need like, --b-pyramid, --weightb and --subme 5.

[Yong]

can anyone play those video clip normally from VSoft's h264 free video clips download section?
http://www.vsofts.com/h264/videoclips.html
Mplayer and ffdshow hang when playing those CIF and D1 video clips...
(becareful, my computer almost freeeeeeze when playing with ffdshow :rolleyes: )

Second, i think there may be a problem in x264 encoders
, when playing x264 encodeds with libavcodec in grayscale mode,
mplayer and ffdshow both show some random big green blocks when playing(extra, flashing green in mplayer),
but HD video clip from apple website doesn't have this kind of problem...

stupid typo again...
Ok, finally i found some playable clips from LEAD h264 free video clips (http://www.leadcodecs.com/Download/H264-Videos.htm) , forget the buggy VSS video clips :D

[dude051]

Can anyone help tell me which values in the VFW are relative to the CLI values? I can pick out all but two, b-frames reduction % and bitrate variability %. I encode mainly Anime, and want to jump to the CLI version to have some of the newer options. My current setup im working with looks like:

@echo off
start /belownormal /b /w x264 -I 300 -i 30 -b 2 -A all -w --b-pyramid --no-chroma-me -p 1 --stats "X264[%~n1].log" -o nul: %1
--progress encode.avs
start /belownormal /b /w x264 --merange 32 -I 300 -i 30 -b 2 -f 1:0 -B 1453 -r 8 -A all -w --me esa --b-pyramid --chroma-qp-offset 2 -p 2
--stats "X264[%~n1].log" -o "encode.mp4" %1 --progress encode.avs

I've heard setting a constant quant as apose to constant bitrate is better, how would i go about guessing one close to my desired bitrate? Also... in the VFW version, does checking "fast firstpass" disable most non-needed cpu intensive things like -A , --me? And im not too sure how different h.264 works compared to XviD, but would it ever be possible to create custom matricies for x264? Although x264's quality vs. noise is alot more impressive than the older codecs, I would like to be able to work on the nasty DCT blocks that show up. Setting the deblocking filter high does not help with this.. as it helps to prevent blocks from already existing blocks. I want to try and help blocks that occur from large flat dark/low contrast areas (such as in most anime). I've searched as much on these questions as much as I wanted to... but its getting late heh.

Thanx in advance...

[Doom9]

but would it ever be possible to create custom matricies for x264?Not until x264 supports the AVC high profile. If you have a look at bond's excellent sticky:
http://forum.doom9.org/showthread.php?s=&threadid=73022 you'll see that the AVC Main profile does not support custom quantizer matrices.

[Sagittaire]

good quality with good speed

x264.exe --bframe 2 --ref 5 --pass 1 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.30 --analyse "all" --weightb --progress -o x264-HDTV.mp4 HDTV.avs
x264.exe --bframe 2 --ref 5 --bitrate 2500 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.30 --analyse "all" --weightb --progress -o x264-HDTV.mp4 HDTV.avs
x264.exe --bframe 2 --ref 5 --bitrate 2500 --pass 2 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.30 --analyse "all" --weightb --progress -o x264-HDTV.mp4 HDTV.avs

"esa" is too slow and quality improuvement is really small
bpyramid don't improve quality and playback is not good

[Yong]

Originally posted by Sagittaire
...bpyramid don't improve quality and playback is not good
Should i say you are kiddding?:rolleyes:

no b pyramid:
x264 [info]: PSNR Mean Y:42.93 U:46.83 V:46.70 Avg:43.66 Global:41.87 kb/s:604.7

b pyramid:
x264 [info]: PSNR Mean Y:42.56 U:46.74 V:46.66 Avg:43.30 Global:42.00 kb/s:601.0

EDIT: So far i haven't encountered any playback problem with b-pyramid...

[bond]

Originally posted by Yong
Ok, finally i found some playable clips from LEAD h264 free video clips (http://www.leadcodecs.com/Download/H264-Videos.htm) omg, what files are these...

- they use wav audio (good for the bandwidth...)
- they place avc in a bastard version of the .ogm format (not listed as video stream)
- they give the .ogm files the .avi extension
- they dont seem to like p-frames, as their streams mainly use b-frames and a few i-frames

funky :D

[Yong]

Originally posted by bond
omg, what files are these...

- they use wav audio (good for the bandwidth...)
yep, uncompressed 1411 kb/s PCM, they are stup1d...
- they place avc in a bastard version of the .ogm format (not listed as video stream)
- they give the .ogm files the .avi extension

OGM? Are you sure?
i see the "RIFF" in the top of file

- they dont seem to like p-frames, as their streams mainly use b-frames and a few i-frames

funky :D
Sure:D

Hey Bond, can u play the free VSS h264 video clips normally?
in my test, mplayer and ffdshow both crashed when playing:devil:

[bond]

Originally posted by Yong
OGM? Are you sure?
i see the "RIFF" in the top of filethe whatbox samples are avi, the others are ogm

Hey Bond, can u play the free VSS h264 video clips normally? the vss clips use an illegal packing of b-frames, which only their own decoder supports

[Yong]

Originally posted by bond
the whatbox samples are avi, the others are ogm

i think we should rename the *.OGM to *.OMG(oh my god):D

the vss clips use an illegal packing of b-frames, which only their own decoder supports
wtf?
SHIFT-DELETE the VSS h264 video clip:sly:

[JoeBG]

Originally posted by Yong
@rushin_911:
@echo off
IF '%1'=='' GOTO EOF
title X264 Encoder
start /belownormal /b /w X264 -p 1 --stats "%userprofile%\desktop\X264[%~n1].log" -o nul: %1 --progress
start /belownormal /b /w X264 -p 2 --stats "%userprofile%\desktop\X264[%~n1].log" -o "%userprofile%\desktop\%~n1.mp4" %1 --progress
pause
:EOF
save the above code to "x264.bat"
u can try to add other cli option if u need like, --b-pyramid, --weightb and --subme 5.

A few questions from a commandline noob :) :
- -o nul: : what is this doing? I hope it makes encoding faster
- %1 : is this for a avisynth input? :rolleyes: Can I start the skript somehow just with making an avisynth-skript and start this skript :confused:;)

Thanks for you help.

[Tommy Carrot]

Originally posted by JoeBG
A few questions from a commandline noob :) :
- -o nul: : what is this doing? I hope it makes encoding faster It means it doesn't create output file in the first pass.
- %1 : is this for a avisynth input? %x (x can be 1-9) is external parameter for the batch file, in this case the input filename.

[JoeBG]

Originally posted by Tommy Carrot
It means it doesn't create output file in the first pass.

This is really helpful, many thanks :)

Originally posted by Tommy Carrot
%x (x can be 1-9) is external parameter for the batch file, in this case the input filename.

How can I use this? To make an example: I have my avisynthskript and I want to use the batchfile for creating an output with the same name like the avisynthskript. Can do this? And how does it work?

Sorry for bagging you :(

[Tommy Carrot]

Originally posted by JoeBG
How can I use this? To make an example: I have my avisynthskript and I want to use the batchfile for creating an output with the same name like the avisynthskript. Can do this? And how does it work?

The most simple way is if you give the same parameter to the input and output field. Using the previously posted batchfile, this would be like this:
@echo off
IF '%1'=='' GOTO EOF
title X264 Encoder
start /belownormal /b /w X264 -p 1 --stats %1.log -o nul: %1.avs --progress
start /belownormal /b /w X264 -p 2 --stats %1.log -o %1.mp4 %1.avs --progress
pause
:EOF

The only problem is that this way you must specify the input name without the extension, for example with "plan 9 from outer space.avs" the command line is:

x264.bat "plan 9 from outer space"

without the avs extension.

[dude051]

A more useful bat file in my opinion, lets you set input, output, stats log file and bitrate. Here's what I use.
@echo off
start /belownormal /b /w x264 -p 1 --stats %3 -o nul: --progress %1
start /belownormal /b /w x264 -B %4 -p 2 --stats %3 -o %2 --progress %1

Using it is simple, just use the command

start x264.bat AVS_Name.avs Output_Name.mp4 Stats_Log.log ##bitrate##

And you should include the .avs extension... you only place quotes ("") around the name if the name includes any spaces. To simplify, keeps your naming down to one word or replace spaces with underscores ( _ ).

[JoeBG]

@ dude051 & Tommy

This is impossible to use for people without DOS knowledge. Open questions are:

@ Tommy

How to start the batchfile. I can create the *.bat and I can save it but noone would ever explain to use it because DOS knowledge seems to be pre-condition. People without DOS knowledge can´t use x264. But I really would like to :)

@ dude051

Originally posted by dude051
Using it is simple, just use the command

start x264.bat AVS_Name.avs Output_Name.mp4 Stats_Log.log ##bitrate##


This is really not fair without instruction to use. But it´s nice that you tell us that you can do this :)

@ All

My question is not o.k in this threat here, but I hoped for help. So forget about it. :)

[dude051]

all you do is create a bat file, in your favorite text editor. Save it as .bat. Bat files are executable, so all you have to do is double click and it will run the commands within it in a DOS window for you. You can either goto Start> Run > Type : cmd , and then type the commands by hand, or make a couple of bat files to do it all for you. Simply enough, place the first set of codes to execute X264.exe in one bat file:


@echo off
start /belownormal /b /w x264 -p 1 --stats %3 -o nul: --progress %1
start /belownormal /b /w x264 -B %4 -p 2 --stats %3 -o %2 --progress %1

Save this as x264.bat

Then create another bat file, with the second set of code:

@echo off
start x264.bat AVS_Name.avs Output_Name.mp4 Stats_Log.log 1000

Bitrate is the last value and is set in Kbps. Save this as encode.bat

Then all you need to do is run encode.bat ( by double clicking it) and it will execute X264 with the commands from x264.bat.

The available commands to X264 can be gotten from running the -h flag... but here:

x264 core:23 svn-215M
Syntax: x264 [options] -o outfile infile [widthxheight]

Infile can be raw YUV 4:2:0 (in which case resolution is required),
or AVI or Avisynth if compiled with AVIS support (yes).
Outfile type is selected by filename:
.264 -> Raw bytestream
.mp4 -> MP4 if compiled with GPAC support (yes)

Options:

-h, --help Print this help

-I, --keyint <integer> Maximum GOP size [250]
-i, --min-keyint <integer> Minimum GOP size [25]
--scenecut <integer> How aggressively to insert extra I-frames [40]
-b, --bframe <integer> Number of B-frames between I and P [0]
--no-b-adapt Disable adaptive B-frame decision
--b-bias <integer> Influences how often B-frames are used [0]
--b-pyramid Keep some B-frames as references

--no-cabac Disable CABAC
-r, --ref <integer> Number of reference frames [1]
--nf Disable loop filter
-f, --filter <alpha:beta> Loop filter AlphaC0 and Beta parameters [0:0]

-q, --qp <integer> Set QP [26]
-B, --bitrate <integer> Set bitrate
--qpmin <integer> Set min QP [0]
--qpmax <integer> Set max QP [51]
--qpstep <integer> Set max QP step [4]
--rcsens <integer> CBR ratecontrol sensitivity [10]
--rcbuf <integer> Size of VBV buffer [0]
--rcinitbuf <integer> Initial VBV buffer occupancy [0]
--ipratio <float> QP factor between I and P [1.40]
--pbratio <float> QP factor between P and B [1.30]
--chroma-qp-offset <integer> QP difference between chroma and luma [0]

-p, --pass <1|2|3> Enable multipass ratecontrol:
- 1: First pass, creates stats file
- 2: Last pass, does not overwrite stats file
- 3: Nth pass, overwrites stats file
--stats <string> Filename for 2 pass stats ["x264_2pass.log"]
--rceq <string> Ratecontrol equation ["blurCplx^(1-qComp)"]
--qcomp <float> QP curve compression: 0.0 => CBR, 1.0 => CQP [0.60]
--cplxblur <float> Reduce fluctuations in QP (before curve compression) [20.0]
--qblur <float> Reduce fluctuations in QP (after curve compression) [0.5]

-A, --analyse <string> Analyse options: ["i4x4,p8x8,b8x8"]
- i4x4
- p8x8, p4x4, b8x8
- none, all
--direct <string> Direct MV prediction mode ["temporal"]
- none, spatial, temporal
-w, --weightb Weighted prediction for B-frames
--me <string> Integer pixel motion estimation method ["hex"]
- dia: diamond search, radius 1 (fast)
- hex: hexagonal search, radius 2
- esa: exhaustive search algorithm (slow)
--merange <integer> Maximum motion vector search range [16]
-m, --subme <integer> Subpixel motion estimation quality: 1=fast, 5=best. [5]
--no-chroma-me Ignore chroma in motion estimation

--level <integer> Specify level (as defined by Annex A)
--sar width:height Specify Sample Aspect Ratio
--fps <float|rational> Specify framerate
--frames <integer> Maximum number of frames to encode
-o, --output Specify output file

--no-asm Disable all CPU optimizations
--no-psnr Disable PSNR computation
--quiet Quiet Mode
-v, --verbose Print stats for each frame
--progress Show a progress indicator while encoding
--aud Use access unit delimiters

You then just add these flags (things with - or -- by them) along with their associated value by adding/changing them in the first bat file, x264.bat. An example would be close to:

start /belownormal /b /w x264 -I 300 -i 30 -b 2 -B %4 -w --b-pyramid -p 2 --stats %3 -o %2 --progress

If you are this scared about using the command line, then I suggest you use the VFW version via VirtualDub or something. This CLI version is a bit more advanced... but is not too complicated once you work with it.

[Doom9]

I have to ask.. why waste time with batchfiles when MeGUI offers you all x264 options, more codecs, more output options, more automatism, jobs, profiles, etc? A lot of the complexity in MeGUI stems from the fact that I try to cater to an advanced audience that could handle batchfiles and such, but why bother with it if you have a GUI tool that can do a lot more?

[dude051]

I actualy have nothing against MeGUI, but I was looking into the CLI version of x264 specifically because I was having errors in vdub with some random crashes. No more crashes or memory leaks since i started with the CLI version. I recently haven't had the time yet to look into MeGUI. Looking into it now actualy and im gonna give it a try.
Thanx :sly:

Edit:
I have to give ya the extreme credit, MeGUI is the holy grail... great stuff! I love it so far.

Later

[JoeBG]

Originally posted by Doom9
I have to ask.. why waste time with batchfiles when MeGUI offers you all x264 options...

A few months ago I asked for my first commandline (mp4box) in the german doom9. The answer was: go to "VHS" (which is a kind of school for adults).

Since then I want to learn more about this. :) And MeGUI is the best!!!

[Doom9]

I'm getting a bunch of

x264 [error]: Error: 2pass curve failed to converge
x264 [error]: target: 1450.00 kbit/s, got: 1387.39 kbit/s, avg QP: 10.0023reported from various MeGUI users.. I was wondering, would it be possible to have an option that automatically lowers the min QP in such a case (or start encoding anyway and just dump a warning rather than exit)?

[akupenguin]

Done. It will still complain, but produce undersized encodes instead of aborting. (If you want the min to be automatically set... just use qp_min=0.)

[Yong]

x264 [error]: Error: 2pass curve failed to converge
x264 [error]: target: 1450.00 kbit/s, got: 1387.39 kbit/s, avg QP: 10.0023
IIRC i only get this kind of warning if transcode WMV without -fps xx options in Mencoder.
The default -fps value for WMV in mencoder is 1000fps:rolleyes:

[Chainmax]

So, does MeGUI allow for access to all of x264 CLI's options? I find x264 CLI a bit daunting after looking at Saggitaire's example batch files and would love something more simplified.

[rushin_911]

Originally posted by Yong
@rushin_911:
@echo off
IF '%1'=='' GOTO EOF
title X264 Encoder
start /belownormal /b /w X264 -p 1 --stats "%userprofile%\desktop\X264[%~n1].log" -o nul: %1 --progress
start /belownormal /b /w X264 -p 2 --stats "%userprofile%\desktop\X264[%~n1].log" -o "%userprofile%\desktop\%~n1.mp4" %1 --progress
pause
:EOF
save the above code to "x264.bat"
u can try to add other cli option if u need like, --b-pyramid, --weightb and --subme 5.

Hey Yong... Thank you for this :) (sorry for my late response)

[Doom9]

does MeGUI allow for access to all of x264 CLI's options?No, there are a few missing (not exposed in mencoder) but I'm pretty sure you won't miss any of them. You really don't need stuff like level, debug, psnr, etc.

@aku: I noted something else.. if you give x264 an empty stats file, it'll throw a curve convergence error.. shouldn't this rather be a "your stats file is invalid"?

[Sagittaire]

and RDO patch ... ???

[Neo Neko]

Originally posted by Doom9
No, there are a few missing (not exposed in mencoder) but I'm pretty sure you won't miss any of them. You really don't need stuff like level, debug, psnr, etc.

If you get time could you add controls on the interface for the -aspect switch in mencoder. Sure I can just paste it in via the comandline builder. But it would IMO make an already excelent tool just a bit better. ;)

[baer999]

Wow I thought the developing is stopped, but now there are a few more versions, my question is:

+ Won a bunch of cycles by not trusting gcc about inlining and
unrolling properly
(about 17% faster globally)

What is 17% faster ? The encoding ? Because i don't know whats is meant by globally :)

[akupenguin]

What does x264 do other than encode? "globally" is benchmarking the whole program, as opposed to listing the speed improvements of one subroutine.

[JoeBG]

Originally posted by baer999
Wow I thought the developing is stopped, ...

A nightmare.....:rolleyes:


@ akupenguin

I hope you´re ok? Everything ok with you and your family? :sly:

[Doom9]

If you get time could you add controls on the interface for the -aspect switch in mencoder. Sure I can just paste it in via the comandline builder.I'll put it into the (already long) todo list. Can't promise it will be in the next version as there is quite a bit of new stuff scheduled already.

[JoeBG]

What makes "--seek" and how do I use it?

Edit:

It´s for stopping the encoding, sorry, I was too fast with this post :(

[Kurtnoise]

Does the --vizualize command work only on Linux/Unix systems ?

I try to compile x264 on win32 platform with some X11 headers but without success...

[Sharktooth]

*nix only :(

[Kurtnoise]

shame yeah...maybe someone can try with a cross-compile ?

[bill_baroud]

well if you need a X11 client, you're somewhat screwed on windows... i think i remember something about one, but it wasn't free iirc.

[nm]

Originally posted by bill_baroud
well if you need a X11 client, you're somewhat screwed on windows... i think i remember something about one, but it wasn't free iirc.

Actually you need an X server (applications are clients) and the free and Open Source Cygwin environment has X.org, see http://x.cygwin.com/

You'll just need to figure out how to compile x264 under Cygwin so that it finds the X headers and libraries.

[Sharktooth]

didnt work for me. maybe i'll try again when i have some time.

[Leak]

Originally posted by Sharktooth
didnt work for me. maybe i'll try again when i have some time.

Works like a charm here; and if you want to build directly under Linux just install coLinux (http://www.colinux.org/) (which is basically a Linux kernel running as a Windows process) and use the X server under windows as a display...

np: Primal Scream - Stuka (Two Lone Swordsmen Remix) (Two Lone Swordsmen - Peppered With Spastic Magic)

[Sharktooth]

well, im redownloading cygwin with X11 and i will try re-building x264.

[nm]

For those unfamiliar with X11, note that X is not just a graphics library, but an entire client-server architecture in which you have to run the server process, X separately. I suppose the Cygwin X project has basic usage instructions somewhere, so be sure to read the documentation. Also try some X applications like xcalc that come with the server (maybe in a separate tools-package, haven't checked myself). If they don't work, nothing else will either.

[Sharktooth]

I managed to compile a win32 build with -visualize enabled but it's useless unless you have cygwin with X11 installed, so i'll keep it disabled...

[Sirber]

Questions:

1) ./configure doesn't like -ffastmath.
2) Can I set -march from ./configure cmdline?

[CREXbzh]

Originally posted by Sirber
Questions:

1) ./configure doesn't like -ffastmath.
2) Can I set -march from ./configure cmdline?

You can edit config.mak after ./configure, that sure works.

[akupenguin]

configure --extra-cflags="-march=..."

[Sirber]

ok. I'll try. Thanks! :D

[Sharktooth]

-ffast-math doesnt work with SSE.

[LigH]

So, revision 237 ff has "zones" now. :thanks:

Unfortunately, not yet in the VfW GUI. -- How long may it take to redesign the dialog?

[Sharktooth]

Im working on the vfw gui, but an average of 5mins/day coz am really busy.
So any help is welcome.

[TNM]

I'm sorry if this question was asked before but for x264vfw, what happen if i set the deblocking filter strength to negative values?

Also about the max and min IDR-frame interval, do they work the same way as xvid's which mean i need to set them according to my vid's fps value?

[CREXbzh]

Originally posted by TNM
I'm sorry if this question was asked before but for x264vfw, what happen if i set the deblocking filter strength to negative values?

Also about the max and min IDR-frame interval, do they work the same way as xvid's which mean i need to set them according to my vid's fps value?

For the deblocking filter, the way I understand it: it has a tendency to wash out some details a bit too much, so if you set it to a negative value, you'll sort of "get back some details".

Please read this doc to get more informations: http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-x264.html

Regarding max/min IDR-frame, I don't know.

[snacky]

Originally posted by CREXbzh
[B]For the deblocking filter, the way I understand it: it has a tendency to wash out some details a bit too much, so if you set it to a negative value, you'll sort of "get back some details".
I don't agree with this. I think you will see more artifacts than details. You will also see a PSNR decrease in most cases. However I will admit that in pictures with high spatial frequency, detail and artifacts may look similar.
Please read this doc to get more informations: http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-x264.html
I'd like to point out that this guide argues AGAINST weakening the deblocking filter. The guide suggests that it would be better to conceal artifacts by adding a small amount of noise in playback.

[CREXbzh]

Originally posted by snacky
I don't agree with this. I think you will see more artifacts than details. You will also see a PSNR decrease in most cases. However I will admit that in pictures with high spatial frequency, detail and artifacts may look similar.

I'd like to point out that this guide argues AGAINST weakening the deblocking filter. The guide suggests that it would be better to conceal artifacts by adding a small amount of noise in playback.
Yeah, I did read the your guide (which is the link I gave). I'd just happends that TNM was asking "what happends if the deblocking filter strength to negative values", and you explained it quite well... :)

[Zero1]

Nice bit of a guide there, x264 could do with some more docs like that ;)

While I'm here, can anyone briefly explain --b-bias, I've read in the CLI that it "Influences how often B-frames are used" but as for choosing a value, I have no idea what would be a good realistic value that wouldn't be detrimental to the quality. Say for instance I was using 3 b-frames and b-pryamid, would setting b-bias to 3 be wise?

With regard to the keyint and minkeyint, it would seem logical to me that you do base these on the framerate of your source, just like you would in XviD. I also changed the --scenecut from 40 to 48 (with my source being 23.976 fps), though I'll admit I haven't checked yet to see if it has a good or bad effect on the quality. Bad me :sly:

[bond]

if you have doubts, the best would be to leave the options at default i would say :)

[el divx]

@ x264 devs: When will support for the baseline, main, high & extended profile features that are currently only accessible through cli be added to vfw?

[bond]

@ x264 devs: When will support for the baseline, main, high & extended profile features that are currently only accessible through cli be added to vfw?
all you vfw/avi loving nerds should have a look at the x264 encoder included in ffdshow (yeah it offers a vfw x264 encoder too), it seems to offer as good as all options of x264 ;)

[Doom9]

the core developers are not even workign on the VfW.. so volunteers would obviously be welcome ;)

[celtic_druid]

I added AR (pretty much copy/paste from GUI) just now to VfW. Tested and working here.

[Sirber]

Cool! Thanks!

Could you add also new 8x8 options? :D

[celtic_druid]

I'll see what I can do.

Some other missing options would be:
scene cut threshold
bframe bias
chroma me
chroma qp offset
vbv max bitrate
vbv buffer size
Initial VBV buffer occupancy
min quant
max quant
quant step
Ratecontrol equation
cplxblur
qblur
me method
me range
idc level

and zones.

Ok, I8X8 and 8X8 DCT added. But let me see if I got this right... I8X8 requires 8x8 DCT. I8X8 is enable by default, but 8x8DCT isn't?

Someone want to test this?
http://mirror05.x264.nl/celtic_druid/test/x264vfw.7z

Didn't waste time arranging stuff as it is all going to need re-arranging anyway to fit other options in.

[bob0r]

I'll see what I can do.

..

Ok, I8X8 and 8X8 DCT added. But let me see if I got this right... I8X8 requires 8x8 DCT. I8X8 is enable by default, but 8x8DCT isn't?

Someone want to test this?
http://mirror05.x264.nl/celtic_druid/test/x264vfw.7z

Didn't waste time arranging stuff as it is all going to need re-arranging anyway to fit other options in.

I disabled 8x8dct, you ask us to test what? if it encodes? if it plays back?
I am now encoding default settings + 8x8dct disabled.

1 pass ABR @ 800kbps

[Doom9]

I'd strongly suggest not adding the rc equation as only codec developer know what it does anyway. there's too much potential to screw up in this area.

[bond]

about vbv and levels:
it would rock if the gui would let the user choose profiles and levels, like xvid does it, and automatically adjust the vbv and options allowed to set according to that (+ an unrestricted option)

[Revgen]

I'll see what I can do.


Ok, I8X8 and 8X8 DCT added. But let me see if I got this right... I8X8 requires 8x8 DCT. I8X8 is enable by default, but 8x8DCT isn't?

Someone want to test this?
http://mirror05.x264.nl/celtic_druid/test/x264vfw.7z



I replaced the x264vfw.dll in my ..Windows/system32/ folder with yours. And encoded a file I previously encoded with sharktooth's rev239 build.

The clip is a Garfield and Friends cartoon encoded at 720x480.

Both clips use the same settings except for the 8x8DCT and 8X8i settings included in your .dll

Whats strange is that I was able to play the HP clip in the 2005-05-10 version of your version of FFDshow.

I installed the new June version afterwards and both played fine in that too.


I also can't tell the difference both clips. They both look good.

It might be because the the resolution is too low and because cartoons don't carry as much detail as a motion picture.


I'm going to try and test and resize some 3 Stooges shorts and see if there is a difference.


UPDATE:

I encoded two ivtc'd three stooges clips at 1440x960 1600kbs which were resized from a 720x480 source.

I couldn't notice a difference between the HP one and the regular one.

[Sagittaire]

bug with 8x8dct: frame 29 with this sample (http://multimediacom.free.fr/Video/bug.mp4)

x264.exe --bframe 3 --8x8dct --ref 5 --filter 0:0 --bitrate 896 --pass 1 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --8x8dct --ref 5 --filter 0:0 --bitrate 896 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --8x8dct --ref 5 --filter 0:0 --bitrate 896 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o x264HP-896.mp4 Encodage.avs

but not with this command line (different bitrate: 447 vs 946)

x264.exe --bframe 3 --8x8dct --ref 5 --filter 0:0 --bitrate 447 --pass 1 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --8x8dct --ref 5 --filter 0:0 --bitrate 447 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --8x8dct --ref 5 --filter 0:0 --bitrate 447 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o x264HP-447.mp4 Encodage.avs

[bond]

bug with 8x8dct: frame 29 with this sample (http://multimediacom.free.fr/Video/bug.mp4)
no problem here playing that file with haali + ffdshow, cant you be more specific?

[Sharktooth]

He means this:
http://www.webalice.it/f.corriga/misc/bug.jpg

Btw i decoded it with Nero decoder. FFDShow can decode it without problems.
Maybe the bug is in nero...

[Manao]

With ateme's decoder, it's wrong too ( though the wrong frame is replaced by a surrounding one )

[dinolib2]

Here with mpc, haalis and latest CD ffdshow, plays fine...

[Manao]

Shartooth, bond, dinolib : nero and ateme's decoders are different, and both have problems decoding that clip. Though a test with the JM would be the most efficient way to find the culprit, it is more than likely that the fault lies in x264 / in gpac.

[Sharktooth]

I will post an updated build with the latest GPAC (updated today).

[Sagittaire]

I will post an updated build with the latest GPAC (updated today).

this last build work perfectly (x264cli 253D + ffdshowdec 06/06/05) in my test for all situation (8x8dct, multi-pref, bref, multi-bframe and combinaisons)

very good job ... :)

[bobololo]

He means this:
http://www.webalice.it/f.corriga/misc/bug.jpg

Btw i decoded it with Nero decoder. FFDShow can decode it without problems.
Maybe the bug is in nero...

This stream appears to be broken. Decoding with the JM (9.6) I got a segfault at picture 29, mb 103. Something seems to be wrong with the reference index.

[Sagittaire]

other (old) problem:
bref + 16 pref playback is good now with ffdshow but not with nero dec.

you want bug: I can to find it ... if you want ... lol

[Sharktooth]

Since i will be at home for some days i decided to restart working on the x264 vfw gui (i re-started from the x264gui by virus):
http://www.webalice.it/f.corriga/misc/gui.png
Advanced options are read from a .xml file so it's easier to update.
The .xml file contains the option name, list of values, registry key, etc...
So when a new functionality is added to the core, you just need to update the .xml file to have it in vfw too.
Well, i hope to finish it soon.

[akupenguin]

bug with 8x8dct: frame 29 with this sample (http://multimediacom.free.fr/Video/bug.mp4)
fixed.

[bob0r]

fixed.

Does this mean ffdshow (libavcodec) needs updating again too?

I just did an encode with build 254
-Latest gpac
-Latest ffdshow
-Latest matroskasplitter

x264 build 254 crashes again.

If we indeed need a new libavcodec, i hope celtic_druid is still here tomorrow!

[Sagittaire]

you want bug ... ???

My HPII trailers and the "warner bros" logo is very hard for encoder ... lol

no bug with x264cli rev 253D + ffdshow 06/06/05 but bug with x264cli rev 253D + last nero AVC dec

bug 3: (http://multimediacom.free.fr/Video/bug3.mp4) problem with bref + multi-pref
x264.exe --bframe 3 --b-pyramid --ref 16 --filter 0:0 --bitrate 447 --pass 1 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --b-pyramid --ref 16 --filter 0:0 --bitrate 447 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --b-pyramid --ref 16 --filter 0:0 --bitrate 447 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o x264MP-447.mp4 Encodage.avs

bug 4: (http://multimediacom.free.fr/Video/bug4.mp4) always problem with bref + multi-pref
x264.exe --bframe 3 --b-pyramid --ref 16 --filter 0:0 --bitrate 896 --pass 1 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --b-pyramid --ref 16 --filter 0:0 --bitrate 896 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --b-pyramid --ref 16 --filter 0:0 --bitrate 896 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o x264MP-896.mp4 Encodage.avs


bug 1: (http://multimediacom.free.fr/Video/bug1.mp4) always problem with bref + multi-pref
x264.exe --bframe 3 --b-pyramid --8x8dct --ref 16 --filter 0:0 --bitrate 447 --pass 1 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --b-pyramid --8x8dct --ref 16 --filter 0:0 --bitrate 447 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --b-pyramid --8x8dct --ref 16 --filter 0:0 --bitrate 447 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o x264HP-447.mp4 Encodage.avs


bug 2: (http://multimediacom.free.fr/Video/bug2.mp4) always problem with bref + multi-pref and another frame 29 bug
x264.exe --bframe 3 --b-pyramid --8x8dct --ref 16 --filter 0:0 --bitrate 896 --pass 1 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --b-pyramid --8x8dct --ref 16 --filter 0:0 --bitrate 896 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --b-pyramid --8x8dct --ref 16 --filter 0:0 --bitrate 896 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o x264HP-896.mp4 Encodage.avs

[bob0r]

@Sagittaire
Can you also try if the same bugs still exist with revision 254?
Because maybe the typo fix in 254 fixes more than just 1 bug.

You may have a problem with playback of 254, lets just hope we can fetch an update before all coders are on summer timeout :scared:

[celtic_druid]

Fixed the VfW. DCT8x8 wasn't getting enabled.

[Tommy Carrot]

What is the advantage of "umhex" motion estimation method over the default "hexagon" method? I thought that it might be faster, but apparently it's the contrary, and i cannot really notice any quality improvement when i'm using it.

[Sharktooth]

Uhm... i think there are still some problems with x264 and 8x8 stuff.

http://www.aziendeassociate.it/temp/hp2-x264_8x8-900.avi

watch it with ffdshow and nero...

[Sagittaire]

this "warner bros" logo is very very hard for x264 ... lol

[Revgen]

Fixed the VfW. DCT8x8 wasn't getting enabled.

<SHORT STORY>
I tested the new VfW.

High Profile seems to be working now.

<LONG STORY>

I resized and reencoded my 720x480 3 Stooges clips that I mentioned earlier at 1600kbps and 1440x960 resolution. The HP settings now take longer to encode than the SP. They both took the same amount of time with yesterdays version.

The difference between the SP and HP clips are very small. I have to look at at individual frames in Virtual Dub to see what details are preserved in the HP settings. The HP does preserve details but IMHO isn't worth the extra time to encode.

Part of the reason for this may be that my 3 stooges clips come from a low resolution source, and HP may work better with original HD content.

I'm going to try downloading some non-DRM WMV HD trailers from the Microsoft site and see if I can't get better results.

[akupenguin]

no bug with x264cli rev 253D + ffdshow 06/06/05 but bug with x264cli rev 253D + last nero AVC dec
OK, one of the SPS values was bad, and ffdshow was OK since it ignored that value.

Uhm... i think there are still some problems with x264 and 8x8 stuff.
Both lavc and JM die on the last frame of that clip. Is it a coincidence that the error is there, or can you create a shorter clip with the same error, or are you complaining of something else?

EDIT: oops, truncated download. No, I don't see any errors with either lavc or JM, and seeking works properly in MPlayer.

I resized and reencoded my 720x480 3 Stooges clips that I mentioned earlier at 1600kbps and 1440x960 resolution.
duh. If you upsize by a factor of 2, then there aren't any details.

What is the advantage of "umhex" motion estimation method over the default "hexagon" method? I thought that it might be faster, but apparently it's the contrary, and i cannot really notice any quality improvement when i'm using it.
It is higher quality. On an average movie, I see only something like +.1 PSNR (which is why it isn't the default), but some high-motion clips (e.g. bus.cif) get huge savings. If done optimally, umhex would be only a little slower than simple hex. x264's implementation isn't optimal.

[Sharktooth]

I'll try to recreate with another clip. Btw if you seek forward the video starts to playback normally... then suddenly it gets distorted until the next keyframe.

[Revgen]

I've just downloaded the Amazon 1280x720 clip from the Microsoft site.

I've encoded 40 sec's of the clip at 1600kbps in both SP and HP and I still find no huge differences between the two profiles.

The only way I can still see any differences is by looking at two frames of each clip in Vdub.


That being said, the quality is still much better compared to xvid and divx.

I'm sure it will improve as you guys go further.

[cheburashka]

@akupenguin
Can you comment the last changes in x264 ?
r255 | pengvado | 2005-06-08 19:16:20 +0200 (Wed, 08 Jun 2005) | 3 lines

revert 216, another try at max_dec_frame_buffering.
disable adaptive cabac_idc by default; 0 is always best anyway.
I can't find anything in rev.216 about this.

Thank you

[akupenguin]

http://trac.videolan.org/x264/changeset/216
http://trac.videolan.org/x264/changeset/255

[Selur]

small question:
should 8x8DCT and 8x8 Intra Search even help with normal (dvd resolution sized) encodes or do they only (really) help with higher resolution encodes (asking since after reading up some stuff via googling that high profile is mainly ment for hdtv resolutions)

Cu Selur

[Manao]

It almost always help. It only doesn't when your video is almost not textured ( which happens when you blur it, or when it's a simpson-like cartoon ). Small-res videos tend not to be that much textured, but 'normal' resolution ( over 512xXXX ) should be detailed enough for high profile to be worth it.

[Sagittaire]

8x8dct help always in all situation (metric always better): if you make H264 encoding 720*576 q28 for average quant quality difference between MP and HP could be high but if you make H264 encoding 720*576 q20 for average quant quality difference could be little. IMO HP help very well like all advanced function ... for hard situation.

[Tommy Carrot]

small question:
should 8x8DCT and 8x8 Intra Search even help with normal (dvd resolution sized) encodes or do they only (really) help with higher resolution encodes (asking since after reading up some stuff via googling that high profile is mainly ment for hdtv resolutions)
Cu Selur
The improved efficiency of high profile is a nice addition, but imo the biggest advantage of 8x8 DCT is that it helps reducing the blocking artifacts (or at least makes them less annoying) quite effectively, when i encode something with disabled inloop-filter. Until now h.264 only gave acceptable quality with activated deblocking, and that more or less blurs the video. With 8x8 DCT, we can relatively safely encode without deblocking, so we can get sharper videos as result.

[Tima]

Sorry, I don't know how to tell it corectly..

When encoding 'Tonari No Totoro' ('My Neighbour Totoro') at 1175 kbps I get a lot of blocks in many scenes. Especially on areas with solid colour.

For example, in first scene when the cat bus arrives, there are VERY much blocks on Totoro's back (it's solid grey)..

The problem doesn't disappear even afer denoising (the source is noisy only a little, though). I tried FFT3D with different sigma and default settings of GK (little, medium and heavy)

I used x264 CLI rev 255, 255a (also tried 250, no diffecence) with such comandline:

x264 --pass 1 --bitrate 1175 --bframe 3 --b-pyramid --filter -5:-5 --analyse all --weightb --progress --seek 76950 --frames 200 -o NUL Project_unresized.avs
x264 --pass 2 --bitrate 1175 --bframe 3 --b-pyramid --filter -5:-5 --analyse all --weightb --progress --seek 76950 --frames 200 -o test.mp4 Project_unresized.avs

This result of encoding the full cartoon has this pb too..

Also I use the latest FFDshow (2005-06-09)

(sorry 4 my bad English)

[hpn]

You could also use "reference frames" and "adaptive spatial transform size", so add this to both passes:
--ref 5 --8x8dct

Also 200 frames maybe too little to allow the encoder to do its best, so try encoding at least 2000 (or more)

[Sagittaire]

lol ... you want no blocking why use inloop = -5 ... :confused:

the best setting with h264 is inloop = [-2;0] interval and certainely not inloop = -5 ... :search:

[Tima]

--filter 0:0
The result is nearly the same.

[Sagittaire]

try to make only 1 pass with --qp 25 --filter 0:0 : if bitrate is very higher than 1175 then your source is very uncompressible ...

H264 is a very good codec but not make miracle ...

[hpn]

the best setting with h264 is inloop = [-2;0] interval Is it --filter -2:0 or you mean something else?

This term "best settings" is so speculative, cause it depends exclusively on the source you encode. I dream of a tool that authomatically returns the "best settings" for a given bitrate by doing multiple short encodes with different predefined profiles (sets of settings) and probably comparing the resulting SSIM or PSNR, so I don't have to scratch my head trying to figure out what settings to use every time I encode a new movie :D

[Sagittaire]

0:0 is in practice always the best setting for OPSNR (perhabs not for SSIM). Inloop is adaptative: 0 for quant 25 is not the same deblocking strenght than 0 for quant 20. For low quant (high quality) inloop is in practice desactived. IMO if you want no problem then you must use the default setting for inloop ... ;)

[Tima]

try to make only 1 pass with --qp 25 --filter 0:0 : if bitrate is very higher than 1175 then your source is very uncompressible ...


No, the result is SMALLER (447 KB vs 1.15 MB).

Could you have a look at it?

http://nwfiles.gorodok.net/test.mp4 - --bitrate 1175

x264 --pass 1 --bitrate 1175 --bframe 3 --b-pyramid --filter 0:0 --analyse all --weightb --progress --seek 76950 --frames 200 -o NUL Project_unresized.avs
x264 --pass 2 --bitrate 1175 --bframe 3 --b-pyramid --filter 0:0 --analyse all --weightb --progress --seek 76950 --frames 200 -o test.mp4 Project_unresized.avs



http://nwfiles.gorodok.net/test_qp25.mp4 - --qp 25

x264 --pass 1 --bframe 3 --qp 25 --b-pyramid --filter 0:0 --analyse all --weightb --progress --seek 76950 --frames 200 -o test_qp25.mp4 Project_unresized.avs

[Manao]

You can't do anything about it, except adding noise during the playback ( which is very effective to hide the blocks ) or heavyfiltering the source before encoding it ( which is hard to do ). No option in the codec will help you.

[Tima]

You can't do anything about it, except adding noise during the playback ( which is very effective to hide the blocks ) or heavyfiltering the source before encoding it ( which is hard to do ). No option in the codec will help you.
The pb is that my source doesn't have much noise. :) After basic denoising i can't see any noise at all..

But.. I encoded uncropped source. Could black border be responsible for these blocks?

[akupenguin]

The blocks on totoro's back are caused by noise. It's less visible before compression, but a good temporal smoother is the way to fix it.
Black borders don't directly cause blocking, but they do seriously hurt compression in general, so you'll see lower quants without the borders.
Likewise, multiple reference frames don't directly affect blocking, but they also generally reduce bitrate and thus allow more bits to be spent where they're needed.

[hpn]

Yes, just remove the black borders and you may get quantizers less than that on the screenshot (19). There is really some blocking on totoro's back, but the clip quality is pretty good overall
http://img12.echo.cx/img12/4117/199dq.jpg

[Sagittaire]

try higher inloop ... :devil:

IMO for particular source like anime you can use higher deblocking, inloop [2;4] is better and produce the same visual result than RV10 ...

[Tommy Carrot]

As i said in my previous post (which was ignored somehow), 8x8 DCT helps a lot in reducing the blocking artifacts, definitely worth a try.

[Sergejack]

As i said in my previous post (which was ignored somehow), 8x8 DCT helps a lot in reducing the blocking artifacts, definitely worth a try.

nevertheless inloop keep being usefull :p

[akupenguin]

Accurate deblocking: yes You have postprocessing enabled for h264 ?!

[Tommy Carrot]

nevertheless inloop keep being usefull :p
The fact that 8x8 DCT helps with disabled deblocking doesn't mean that it is not beneficial with activated inloop-filter as well, it should be in all circumstances.

[Maximus_G]

Sorry, i don't see any mencoder/mplayer thread whish is fresh enough.

When i'm trying to start mencoder from mplayer2005.06.09.P3 - i get an error message saying (it's not in english, so this is just a translation):
"Application could not be started, because pthreadGC2.dll could not be found. A new application install may solve this problem."

And Mencoder from mplayer2005.06.04.P3 works just fine. Just I8x8 high profile is unusable, because of inadequate version of mencoder.

Seems like a bug?

[Manao]

Maximum_G : the error message is clear enough. Download the missing dll, and place it in your path. That link (http://forum.doom9.org/showthread.php?t=92726&page=5&pp=20) should help you to find the dll.

[Maximus_G]

Oh, thanks. Maybe then it would be useful to place that link at "x264 win32 daily builds..." thread.

[celtic_druid]

Odd. x264 is using native windows threads and I don't remember enabling pthreads in mencoder. I'll have a look later.

edit: Ok, configure was updated to support mingw pthreads . Previously I had to manually enable it. As such since I had pthreads, it was autodetected.

[Sharktooth]

Oh, thanks. Maybe then it would be useful to place that link at "x264 win32 daily builds..." thread.
It's already there...

[hpn]

You have postprocessing enabled for h264 ?!
Actually I couldn't find a way to disable "Accurate deblocking". It's always "On" (Yes) on the OSD, no matter if I disable or enable postprocessing, but maybe I look at a wrong place or it should always be ON anyway:

http://img176.echo.cx/img176/9746/19b5vl.jpg

[bond]

i assume this refers to loop deblocking. why do you want to disable it?
and if you dont want it you have to disable it when encoding

[LigH]

Somehow it seems hard to distinguish the general DCT based deblocking functions (which shall be deactivated if H.264 video gets decoded) from the H.264 internal deblocking functions (e.g. inloop filter). Just for that reason, the current ffdshow has the long combobox in the lower right part, which allows to disable the usual DCT deblocking when H.264 is decoded, I thought...

[hpn]

I don't want it disabled (I don't even know what exactly it really does), but because akupenguin asked me a few posts above, I thought he was wondering why it's ON, not OFF in this particular case.

[celtic_druid]

Updated the VfW again.
http://mirror05.x264.nl/celtic_druid/test/x264vfw.7z
Added Me method, range and chroma me.

[Tommy Carrot]

Thank you, finally vfw is up to date again. :cool:

I found a small bug though, it seems to me that 8x8 transform is not applied on keyframes, if you could fix this, everything would be perfect. :)

[bob0r]

@celtic_druid

Looks great, x264 rev 260 updated your previous update.
Can you add ,Configure to the .dll?

With celtic_druid VFW still has a great future.... and so does cligui ;)

[celtic_druid]

Well, I'll finish up some stuff and then do a new diff vs. rev 260.
Also the 8x8 bug is as far as I know fixed.

Looks live Configure has been uncommented in the CVS anway.

[bob0r]

..
Looks live Configure has been uncommented in the CVS anway.

That's what i meant :sly:

[Sharktooth]

i submitted all patches i was using to create my builds, including the driverproc.def one (configure).
i confirm the 8x8 thing is fixed in rev260.

[celtic_druid]

Well under debug you can now change the log level to get stats on stuff like 8x8. Default is error.

I also moved fourCC there and put scene change threshold in its place.

Link is still the same: http://mirror05.x264.nl/celtic_druid/test/x264vfw.7z
Diff file: http://mirror05.x264.nl/celtic_druid/test/x264vfwpatch.diff
I also updated the GUI: http://mirror05.x264.nl/celtic_druid/test/x264gui.7z
diffs: http://mirror05.x264.nl/celtic_druid/test/x264gui.diff

[bond]

http://mirror05.x264.nl/celtic_druid/test/x264gui.7z
diffs: http://mirror05.x264.nl/celtic_druid/test/x264gui.diff
thx a lot!
btw it seems there is a problem starting an encode right from inside the gui, because it seems that your build seems to assume that x264.exe is in the path c:\ and not in the folder of x264gui

edit: it seems this only happens when you load defaults (if you dont do it the encoding process starts fine)

btw: can you disable the debug mode by default plz

[LigH]

I like the new detailed GUI in rev. 260A!

I'm not sure what exactly you would like to have tested. But at least I was able to successfully encode a video (see the "Terragen" thread).

Just one issue I faced: Just for fun, I used 4 threads on a single Duron CPU. At the end of the encoding, I get "possible live-locks" (I/O thread not cycled for 10 seconds, later even the main thread). But one click on "OK", and the Dub window closes and the AVI is fine.

[bob0r]

"btw: can you disable the debug mode by default plz"
My thoughts exactly :sly:

And about the x264.exe dir, i think its best to select where x264.exe is when you first run the gui (and after reset load defaults).

Then people know where the x264.exe is, and people know what and where they are working. More knowledge is more test results :)

[hpn]

Just one issue I faced: Just for fun, I used 4 threads on a single Duron CPU. At the end of the encoding, I get "possible live-locks" (I/O thread not cycled for 10 seconds, later even the main thread). But one click on "OK", and the Dub window closes and the AVI is fine.
Actually it's not a real issue, just a warning. The Dub encodes at "Idle" priority by default, so it's very common to get such "not cycled for 10 seconds" messages, if you're doing other stuff with your PC. I often get these when compressing with winrar at the same time for example :)

p.s. The extended vfw dialog is awsome. celtic_druid rocks!

[LigH]

@ hpn:

But the warning list gets longer and longer if I don't close it. It seems to wait for a not correctly terminated thread, in my opinion. But it may be hard to determine the real reason.

Unfortunately, if you try a batch encode (or e.g. GordianKnot running n-pass), each pass would halt here until the user presses "OK".

[hpn]

Unfortunately, if you try a batch encode (or e.g. GordianKnot running n-pass), each pass would halt here until the user presses "OK".
I haven't tried it, cause I've never had such issue with GKnot and multiple passes, but maybe changing the Vdub default priority could help:
Vdub ->Options->Preferences->Process Priority (Norma or High) -> click "SAVE" (not Accept)

(OT here, but anyway)

[SeeMoreDigital]

The new GUI in build X264VFW_rev260A_mmx.exe looks okay: -

http://img172.echo.cx/img172/7416/x264newgui8td.gif

PAR signalling appears to work fine too.... I will do some more tests tomorrow ;)


Many thanks guys

[bond]

i think that "direct mode" and "weighted biprediction" should be grouped together with "b-frames". i dont think they belong to "analysis"

also i wouldnt enable everything by default, eg p4x4 is disabled in mencoder by default, after all enabling everything also slows things down
also i would disable the high profile features by default, cause they will definitely lead to interoperability problems (eg with quicktime). only people who know what they are doing should enable this

[Doom9]

btw, zones are still missing ;)

[Revgen]

I just encoded a Garfield and Friends cartoon episode from my DVD with all default options.

It plays fine in the latest version of FFDShow.

[Sharktooth]

Rev261 is up and contains all the new stuff. We'll discuss the defaults tomorrow (need to sleep now) and maybe even a new fast first pass...

[virus]

Shouldn't "ME range" be disabled for UMH motion estimation too?
Currently it's active, but according to mencoder's documentation it only applies to Exhaustive search.

[celtic_druid]

Haven't looked at mencoders docs but it enables me_rage for me_method >= 3 and me_method 3 = X264_ME_UMH. I just did the same.

[Blue_MiSfit]

Gosh I stop paying attention for one freaking day and all of a sudden theres a new GUI and all sorts of nice improvements!

Open Source development is really far too cool.

:D :thanks:

[Yong]

thx for the new x264vfw interface :)
btw,
a bit headache when i wan to adjust the "ME range value",
so many value i cannot enter... :rolleyes:
eg. 32...

[celtic_druid]

Well you can kinda enter 32. You just have to enter say 12, then change the 1 to a 3. Not sure what to do about it. Guess I could just remove the < 4 check.

Moved the < 4 check so that it checks when it reads from the registry and when it parses the param. So you can now enter a value < 4, but you will just get 4.

[LigH]

Depends on the event you use for validity checks. Being a programmer myself, I experienced that quite often. Better don't check values on each and every change, instead do it only when the focus is taken away from the edit field (don't know how the event handler is called in your programming language: OnExit, OnBlur, ...).

[celtic_druid]

EN_KILLFOCUS I believe. I'll try that.

Ok, that works better.

[Manao]

Usually, text fields needs only to be checked when pressing the OK button. Alternatively, the OK button can be disabled if a field is incorrect. EN_KILLFOCUS has an issue : it isn't necessary called ( i once stumbled accross a blog from a microsoft dev saying not to use the killfocus notification because of that reason ).

[celtic_druid]

Seems to work ok here.

So you think I should just move all of the checks to the OK button?

[Manao]

That's what I would do. The best imho would be a check function that colors the invalid controls and disables the OK button, and to call that function for each EN_CHANGE notifications. But that needs time, and it's not that important.

[LigH]

Okay, there was one issue when I did so:

If I pop up a dialog when the value is invalid, and the focus is removed because I click a button, the button is left in "pressed" state because the dialog pops up. :D

Event driven user interfaces are fun. :sly:

[Kurtnoise]

Great stuff CD...;)

May I suggest some things ? It could be great to separate the Analysis options with B-Frames to help newbies with the advanced settings. Here is some suggestions :

http://kurtnoise.free.fr/motion.png

http://kurtnoise.free.fr/bframes.gif


Another request : to have some presets (High Profile, Main Profile...).

And the last thing : I think the min/max/QP step must be disabled when we choose the Bitrate single pass...

[SeeMoreDigital]

I think there's something not quite right with rev260A. As the encodes I've generated with it will not open in QuickTime player 7 (for Win XP).

I've used exactly the same generating procedure and settings with rev260A, as with the previous version(s) I've tried (last one being X264VFW_rev254+threads_mmx): -

http://img292.echo.cx/img292/6535/x264vfwrev254threadsmmxsetting.gif

But for some reason all my rev260A tests have so far stalled in QT7 (although they seem to work fine in other players).

Please let me know what other info you guys require?


Cheers

[LigH]

I'd rather guess that something is wrong with QT7, only supporting a small subset out of MPEG4-AVC. ;)

[Doom9]

@Kurtnoise13: I like your suggestions.. guess I'll add them to MeGUI as well.

[SeeMoreDigital]

@Kurtnoise13: I like your suggestions.. guess I'll add them to MeGUI as well.Yep.... I like your suggestions too ;)

[bond]

first of all i have to say, cause i often read "weighted prediction", that x264 does NOT support weighted prediction!
x264 supports weighted biprediction, which is a similar, but still another thing than normal weighted prediction


about the guis: yep, having the option to choose between "baseline", "main", "high profile" and "unrestricted" (which automatically en/disables options and sets the vbv) would really rock, this can also be combined with the already available option to set the levels


SMD, i assume you are not trying to open x264-in-avi in qt7, cause this will surely not work

make sure to disable the high profile features (8x8dct and i8x8), cause qt7 doesnt handle high profile
thats also one reason why i wrote that they should better be disabled by default

[Manao]

It's levels, not profiles, that restrain the vbv buffer size.

However, making high profile features default does'nt bother me, they really improve things a lot ( but ok, i really don't care for qt7 compliancy )

[Sharktooth]

Great stuff CD...;)

May I suggest some things ? It could be great to separate the Analysis options with B-Frames to help newbies with the advanced settings. Here is some suggestions :

http://kurtnoise.free.fr/motion.png

http://kurtnoise.free.fr/bframes.gif


Another request : to have some presets (High Profile, Main Profile...).

And the last thing : I think the min/max/QP step must be disabled when we choose the Bitrate single pass...
ME Range is NOT motion vector search range... it's the number of iterations for motion extimation.
Also it "biprediction" not "prediction"...

[SeeMoreDigital]

SMD, i assume you are not trying to open x264-in-avi in qt7, cause this will surely not workNo... of course I'm not ;)

make sure to disable the high profile features (8x8dct and i8x8), cause qt7 doesnt handle high profile.

Thats also one reason why i wrote that they should better be disabled by default This was it thanks bond.... As soon as these two implementations were disabled, the encodes worked fine in QT7.

Many, many thanks

[Sharktooth]

However let's just implement options. It's easier to re-design it once you know how many things it should contain... :p

[Kurtnoise]

ME Range is NOT motion vector search range... it's the number of iterations for motion extimation.
well...indeed. I created this design too fast...;)

Also it "biprediction" not "prediction"...
It's included into B-Frames GroupBox that's why I didn't mention biprediction...,whatever it's not very important IMHO. It was just a picture to illustrate my suggestions...:)


Edit : zones area rocks. Don't forget this. ^^

[cheburashka]

Rev261 is up and contains all the new stuff. We'll discuss the defaults tomorrow (need to sleep now) and maybe even a new fast first pass...

So. What is the fast first pass in VFW gui? Is it the same as MeGUI's turbo mode?

:thanks:

Ok, found myself in sourse code:
if( config->b_fast1pass )
{
/* adjust or turn off some flags to gain speed, if needed */
param.analyse.i_subpel_refine = X264_MAX( X264_MIN( 3, param.analyse.i_subpel_refine - 1 ), 1 );
param.i_frame_reference = ( param.i_frame_reference + 1 ) >> 1;
param.analyse.inter &= ( ~X264_ANALYSE_PSUB8x8 );
param.analyse.inter &= ( ~X264_ANALYSE_BSUB16x16 );
}

That means it is MeGUI's turbo mode for automated 2pass encode + turned off p4x4 and b8x8.

[Maximus_G]

This is what i see when using mencoder "encopts threads=4" on a dual Xeon (HT) system, Win2000Server. Changing priority in MeGUI window doesn't affect this - total average CPU load is stable and about 50%.

And using threads=2 on a regular P4 with HT produces CPU load at about 70-90%.
I wish i could load those Xeons up to 80% too :)

[SeeMoreDigital]

With regard to the existing GUI layout. It's width has increased by quite a bit.

Anyway, I did some shuffling about and came up with this layout proposal: -

http://img138.echo.cx/img138/4294/newguioriginal2xq.png


Cheers

[Sharktooth]

PAR and DAR? No, x264 supports only one...

[SeeMoreDigital]

PAR and DAR? No, x264 supports only one...Well you can't knock a guy for trying :D

I've generated several PAR PAL test encodes using 45:64 (for 16:9) and 15:16 (for 4:3) and they are smack on the money.... Many thanks for including AR signalling via VfW.


Cheers

[Sharktooth]

There are definately other interesting options to include though.
Like zones, VBV, levels, ratetol, qblur, qp offset and chroma qp :)
However i like your design...

[SeeMoreDigital]

There are definately other interesting options to include though.
Like zones, VBV, levels, ratetol, qblur, qp offset and chroma qp :)
However i like your design...Thanks Sharktooth,

Would it be possible to add .MP4 output for VfW users?


Cheers

[berrinam]

Would it be possible to add .MP4 output for VfW users?

How would that work? Isn't the whole point of VfW that it is container independent?

[SeeMoreDigital]

How would that work? Isn't the whole point of VfW that it is container independent?I guess it could work in much the same way it did when DivX 5.0.2 was released.


Cheers

[Sharktooth]

it works the same way... the mp4 file is written to disk by the codec and it returns blank frames to vfw (so virtualdub writes a small and almost empty .avi).
im still working on it though, coz it will support audio (including delay) and subtitles muxing too.

[Yong]

i suggest remove the slider from deblocking filter "strength/thresthold" and b-frames bias,
b-bias already have a box to enter value, so i hope the deblocking filter "strength/thresthold" also have this kind of box to enter value.
coz i feel the slider doesnt useful(not change the value frequently) but only make the "X264 anvanced settings" window bigger... :p :D

[Sharktooth]

the interface is being redesigned.

[Inventive Software]

I have something that might interest the devs...

I can successfully do a 1st Pass, with the information file. When I try and do the Nth pass VDubMod complains that it can't start the compressor. I'm using x264 rev 216, VFW. Is this why?

P.S, this is to with the codec test I'm still trying to get results from. I am getting results from all but 2 or 3 of the codecs on test, no names mentioned except x264. I would like to get 2-pass working, because if not it's gonna hinder it when I come to the final conclusions.

[SeeMoreDigital]

I can successfully do a 1st Pass, with the information file. When I try and do the Nth pass VDubMod complains that it can't start the compressor. I'm using x264 rev 216, VFW. Is this why?Where have you pointed your "Stats File" location to?

http://img228.echo.cx/img228/9017/x264statsfile1qh.png


Cheers

[Sharktooth]

never had problems with 2 or more passes in VFW and never heard of any other report saying it doesnt work.

[SeeMoreDigital]

never had problems with 2 or more passes in VFW and never heard of any other report saying it doesnt work.I only ever have a problem with 2 (or more) pass, if I forget to re-set the "Stats File" location.... Which I place at C:\


Cheers

[Inventive Software]

@SMD: The statsfile is pointed to the file that was created. In trying to get Nth pass mode working, it just doesn't want to start the compressor. Is there something I'm missing?

[SeeMoreDigital]

@SMD: The statsfile is pointed to the file that was created. In trying to get Nth pass mode working, it just doesn't want to start the compressor. Is there something I'm missing?A similar thing happened to me.

All I can tell you is, when I moved the "Stats File" location to C:\ instead of the default location.... it cured my problem ;)


Cheers

[Inventive Software]

Yeah, but I have a directory that has many stats files in it, and some end with .stats, including the x264 ones. I am pointing the stats file to the absolute file that contains the information.

(The forward slashes are actually back-slashes)
Example: I have a stats file in "C:/Codec Test/1st Pass Information Files/Simpsons Roasting On An Open Fire - x264 rev 216.stats". This is where I put the file in the 1st Pass. When trying to do the Nth pass, and pointing to this file for the Nth Pass, it doesn't want to start the compressor. I have absolutely no idea what's going on here, and it's doing my head in.

[Mutant_Fruit]

It could be that your path is too long, and its fecking up the software then.

Save your stats info to the root c: with a shorter filename as a test to see if that helps. You can always rename it afterwards if you need to.

Also, you may have to re-run the first pass if it turns out the filename was too long, as it may not have saved correctly.

[jellysandwich]

Newbie question here...

How far has x264 come? I haven't checked on
its progress since ~r200, and browsing/searching
the forums hasn't helped me find the answer I
seek.

In terms of quality, how does it compare now to
Xvid, DivX, and the others (I remember it wasn't
as good at ~r200)?

Would it be a bad idea to start making backups
using x264 because it is still too early in the testing
stages?

js

[Revgen]

X264 is still actively being developed. It doesn't even have an integrated decoder yet. You have to use custom versions of FFDshow or Mencoder to view them.

You can make a backup, and it will look better than Xvid, but it might not be compatible in the future.

[snacky]

X264 is still actively being developed. It doesn't even have an integrated decoder yet.
Why should it?
You have to use custom versions of FFDshow or Mencoder to view them.
They're not custom. And any other sufficiently full-featured decoder will decode them too.

You can make a backup, and it will look better than Xvid, but it might not be compatible in the future.

Actually, videos you make today are certain to be compatible with future decoders.

[ChronoCross]

Actually, videos you make today are certain to be compatible with future decoders.

I disagree. if you make a backup of something now and it's b0rked then it will still be borked for future decoders. Bad headers or something implemented wrong, or something not working just right and therefore reducing possible quality. For now I'd say that x264 is a testing codec only not suitable for full featured backups, but from what I'm seeing it won't be long until it's ready for full on backup.

[snacky]

I only know of one instance since last July in which x264 has generated an invalid stream that prevents decoding. Arguably, this is better than xvid's track record.

[Revgen]

Why should it?
It's not practical for mainstream users. They won't be able to easily figure out how to use Mencoder/Mplayer or FFDshow to play a video. An easy plug and play codec is essential if X264 is to be used by the mainstream.

They're not custom. And any other sufficiently full-featured decoder will decode them too.

Look at Sharktooth's sticky page. He recommends using FFDShow builds made by Celtic Druid.

Also there was a post in some thread in this section mentioning an X264 file that wasn't able to play correctly in an H264 compatible player. However the person was able to play it correctly using FFDshow. I did a search for the post but I have still yet to find it to post a link. X264 still has a way to go before being completely compatible.

Actually, videos you make today are certain to be compatible with future decoders.

ChronoCross answered this question better than I could.

[LigH]

Look at Sharktooth's sticky page. He recommends using FFDShow builds made by Celtic Druid.
The main reason is that this build has most libavcodec options enabled.

I read somewhere that plain CVS builds of ffmpeg, for example, have many libavcodec options disabled, this might be true for default ffdshow projects as well.