View Full Version : sex264 (updated almost daily by now)


sysKin
5th January 2005, 11:55
Hi everyone :)

I just finished "my" first really working build of x264 with up-to-date VfW interface. The GUI has most of the options that core has, including bframes, two-pass, and motion estimation selectors. It's pretty ugly I admit but I don't care :p

I need testers. Consider this version RC1 - I think it works but I don't feel like testing ;)

The name is sysKin's experimantal x264, or sex264 for short.

Grab it (build and src) at http://syskin.is.dreaming.org/x264/ .

Have fun, and don't forget to report anything that is wrong or missing.

Radek

[edit 9th Jan] New version available.

Yong
5th January 2005, 12:02
sex264, nice name! lol:p

Sirber
5th January 2005, 12:55
Cool!

What are the *working* features?

[edit]

Install don't work, VDub don't see it :(.

sysKin
5th January 2005, 13:13
Originally posted by Sirber
What are the *working* features?Whatever x264's core currently has. Ffdshow doesn't want to play its b-frames (asserion error with newest Celtic Druid's build) but Videosoft's decoder plays them fine.
Install don't work, VDub don't see it :(. Very bad. This definitely works for me - check if x264vfw.dll got copied to windows\system32\ (ah, maybe you're not administrator?).

Radek

Sirber
5th January 2005, 13:22
I'm administrtator. Second click on the .inf, install. It seems to copy a file but in VDubMod, nothing :(

[edit]

Tryed with regsrv32.exe, but it said function DLLRegisterServer is not found.

bond
5th January 2005, 13:59
np showing up here in vdm

btw syskin you might want to consider using "avc1" as fourcc, its not nice looking, but still its the four letter "fourcc" the mpeg-4 standard defines to use for signalling h.264 in .mp4 (i think it can be taken as the equivalent to the .avi 4ccs)
its already supported by ffdshow :)

edit3: maybe it would be also nice to add a description to the subpixel options (eg uses qpel, uses hpel aso..)

edit: and how do you make 2pass working in vfw?
for the first pass i assume you use constant quant, what quant do you use?

edit2: two gui problems:
1) the "ok" button in the advanced tab is divided by the bottom line (i hope its clear what i mean)
2) i still get the problem, that when i push the "load defaults" that all values get set to 0 and all options get unticked in the advanced tab

Jerry_Sm@rt
5th January 2005, 14:20
great!cann't wait to try it.
Any mirror?i just can not visit that url.:(

Tommy Carrot
5th January 2005, 14:22
Originally posted by sysKin
Whatever x264's core currently has. Ffdshow doesn't want to play its b-frames (asserion error with newest Celtic Druid's build)
Today's build by celtic_druid can play it back without any problems.

Just a question: what is the recommended b-frame prediction mode, temporal or spatial?

Shinobu
5th January 2005, 14:29
no problem at all with this codec, but i'll launch more test this night ^^.

the load default isn't working great on windows 2000, you have to close the config tab of the codec and reopen it to apply the reset.

++

SeeMoreDigital
5th January 2005, 14:36
Hi sysKin,

Will an Mpeg4/AVC implementation, such as this, ever make it into XviD?


Side Note:
I wonder how quickly Doom9 will get round to creating an Mpeg4/AVC section. As the forum is full of such discussions ;)


Cheers

virus
5th January 2005, 15:32
Ok, I've already reported to Radek the most obvious cosmetic flaws, now I'd like someone testing for a more serious issue.

I run several 2pass encodes (settings: all @ default) from the same 1stpass statsfile, just changing the target bitrate. When aiming for medium or high bitrates, everything went fine. But when aiming for low bitrates (450 kbit/s) everything b0rked with an assertion in ratecontrol.c.

According to sysKin, that should happen when the statsfile is shorter than needed... but the statsfile is OK since I run several successful encodes with it. I observed that problem in the past with ffdshow though - at the times it seemed to happen when the 2nd pass average QP was much bigger than the 1st pass one (1stpass is run at fixed QP=26 currently, so you need to go with very low bitrates to trigger it in sysKin's build).

If you can try and see if that happens to you too, that would be great. Thanks! :)

virus

hellfred
5th January 2005, 15:36
Yesterday i have downloaded an installed 03012005_x264_bin.7z with the right-click-install method.
What is the recomendet procedure to update differen versions of sex264 /vfw codecs in one dll?
Just replace the x264vfw.dll?
regsrv32.exe -u x264vfw.dll and right-click-install the newer version?
And how to uninstall?
regsrv32.exe -u x264vfw.dll and deleting the dll?

Hellfred

bond
5th January 2005, 15:53
maybe someone finds it interesting and so i dont forget about it:

when encoding with x264 vfw with b-frames (eg in virtualdub(mod) you will maybe find out the following (as i did):

- when choosing 2 b-frames -> two zero length frames get placed in the output stream (frames that avi thinks exist, but in fact dont exist :D ) -> as the output stream has the same framenumber as the input stream this means that practically there are 2 frames too few in the output
- for 1 b-frame -> 1 zero length frame -> 1 frame lost
- for 0 b-frames -> 0 zero length frames -> 0 frames lost
aso...

thats caused by the video for windows (vfw) framework (as used in vd(m)), which is NOT able to handle b-frames correctly on its own (as b-frames are a newer technology than vfw)

i talked about that with syskin and he meant that the old workaround to solve this (using one-byte 0x7f frames) should not be used, as it creates an incompatible stream if the app (eg everything, except vd(m)) doesnt know about it :(

Tommy Carrot
5th January 2005, 16:01
@Hellfred: replacing should do it.

@Bond: that is exactly how the b-frame support works with xvid, if it didn't bother anyone for years, i don't see why it suddenly became a problem with x264.

bond
5th January 2005, 16:04
Originally posted by Tommy Carrot
@Bond: that is exactly how the b-frame support works with xvid, if it didn't bother anyone for years, i don't see why it suddenly became a problem with x264.because the workaround working for xvid, doesnt work for avc (in xvid no frames are lost) :rolleyes:

you should read the whole post :p

Tommy Carrot
5th January 2005, 16:08
Well, i'm sure syskin will find a simple solution for that. :)

bond
5th January 2005, 16:16
he meant the best is to keep the current way (who cares about 2 frames in a 200000 frames movie :D )

another way would be to make avery adopt vd to beaware of these lost frames...

anyways just wanted to post that info so it doesnt get lost in the depths of irc :D

JoeBG
5th January 2005, 17:54
I really have no idea how to use it. I downloaded everything, but there is no *.exe. I always thought, a gui has a *.exe.

How does the tool work?

Sirber
5th January 2005, 18:29
you're supposed ti install it using the .inf, but it failed for me :(

stephanV
5th January 2005, 18:42
I have a small question.

Since i recently (today) found out about the difference between I-frames and IDR-frames, i was wondering: is the keyframe-interval really the keyframe interval? Or is it the I-frame interval? I suppose i could try and found out, but i'd rather have some confirmation about it.

JoeBG
5th January 2005, 18:48
Originally posted by Sirber
you're supposed ti install it using the .inf, but it failed for me :(

Okay, I made a right mouse click on the inf, the system worked and worked (there was a progress bar). It finished, but still no *.exe.

Can someone help me?

stephanV
5th January 2005, 19:05
he, exe?

open virtualdub and go to the compression menu :)

JoeBG
5th January 2005, 19:12
Originally posted by stephanV
he, exe?

open virtualdub and go to the compression menu :)

Okay it works: This was my first time, so sorry for my question. Life is easier when doing things the second time :)

Neo Neko
5th January 2005, 19:12
Installed and working here. Nice! But sex264 just does not seem sexy enough. What about the 101 other days of the year. Something like sex365 or sex24/7 would be much more sexy. :D

Moitah
5th January 2005, 19:40
Originally posted by bond
he meant the best is to keep the current way (who cares about 2 frames in a 200000 frames movie :D )

another way would be to make avery adopt vd to beaware of these lost frames...

anyways just wanted to post that info so it doesnt get lost in the depths of irc :D
I will see about adding this to avs2avi soon.

virus
5th January 2005, 19:51
:(

well, I have an issue with this build which is driving me crazy so I think I'd just post it here and maybe someone will have a suggestion for me.

In short: sex264 is painfully slow on my machine, compared with other people's speeds. This build seems to be a bit slower on pentiums and I do have a P4 indeed, but nothing compares to what's happening on my PC. I've compared my speeds with several people running both AMDs and Pentiums.

It's not compiler-related, because gcc and msvc gave the same results. It's not kernel-related, because bond (who runs win9x like me) doesn't have such low speeds. It's not even revision-related, because I downloaded and compiled old revisions from the repository and they are all slow.

But I just run a test and damn, look at the results - they explain the situation very well:

PAL DVD source @ 560x304 / vdub 1.5.10
fastest settings (no cabac, no inloop, no analyzer flags, no bvops, subpixel ref. and multiple ref. at minimum)

ffdshow/x264 Oct 5, 2004 -> 17 fps
sex264 -> 5.5 fps

There's no way it can be so slow, akupenguin told me that something has been made faster, something a bit slower (for better quality). All in all, and given others' people speeds, sex264 should give me 15-18 fps with the fastest settings... instead I got 5 fps with fastest settings and almost 3 fps with all the bells and whistles on, which is very strange too (slowest settings are more than 3x slower than fastest ones for other people).

Now I've spent countless hours trying to understand this crap and I don't know what the hell is going on - what can intefere with x264 and make it so slow here? If you have any suggestion please let me know, thank you.

virus

akupenguin
5th January 2005, 20:18
Originally posted by bond
he meant the best is to keep the current way (who cares about 2 frames in a 200000 frames movie :D )
If it were just losing the last 2 frames, it wouldn't be a problem. But it also adds 2 null frames at the beginning, which causes ~80ms of A/V desync. (Until you remux with something that discards the null frames.)

snacky
5th January 2005, 20:58
Since i recently (today) found out about the difference between I-frames and IDR-frames, i was wondering: is the keyframe-interval really the keyframe interval? Or is it the I-frame interval? I suppose i could try and found out, but i'd rather have some confirmation about it.
When the encoder inserts an I-frame in order to meet your keyint requirement, it will always be IDR. After all, the only purpose of specifying a keyframe interval is to guarantee a certain amount of seekability.

When an I-frame is inserted because a scenechange was detected, it depends on what IDR-interval you asked for.

akupenguin
5th January 2005, 21:02
Originally posted by snacky
When the encoder inserts an I-frame in order to meet your keyint requirement, it will always be IDR. After all, the only purpose of specifying a keyframe interval is to guarantee a certain amount of seekability. That would be good, but it's not true yet. IDR interval is a strict alternation.

Doom9
5th January 2005, 22:26
nice work. There's just a few cosmetical things: the three bitrate/quantizer input values touch the border area, and in the advanced settings, you have an inactive X button as well as an OK button that is only halfway placed inside the border area.

hellfred
5th January 2005, 22:48
Is it only with x264/sex264 that your system becomes that slow?
If you had compiled your x264 yourself, i had asked if you did install nasm and did some testing with it. In x264 source is a test suit to check nasm output.
To build it one has to typ
make checkasm
and then change to testing and run checkasm.exe.

Hellfred

SeeMoreDigital
5th January 2005, 23:10
Well... I've managed to generate an encode but I don't seem to be able to play it!

Normally I use Nero's ShowTime player and filters to do "the business", as it's been able to play just about every other variant of the AVC variant currently available... but with this one... I've had no joy :(


Cheers

stephanV
5th January 2005, 23:20
im not sure nero supports AVC in AVI (or try to change the fourcc to AVC1)

with the latest ffdshow from celtic druid i had no problems.

Leo 69
5th January 2005, 23:21
@ SeeMoreDigital

Try to change the fourcc to H264

Ark
5th January 2005, 23:24
Well i tried with the usual combo mpc+ffdshow and it works like a charm... (if that can help you)

virus
5th January 2005, 23:36
Originally posted by hellfred
To build it one has to typ
make checkasm
and then change to testing and run checkasm.exe.
Well, thx for the suggestion :)
I've tried it, though I have no idea if this utility is updated or not and whether it should work or not (anyway, syskin uses msvc for compiling and not gcc like me - and in both cases, everything is very slow here).

Here's the output:

x264: MMXEXT against C
- pixel sad : [OK]
- pixel satd : [OK]
- pixel avg : [OK]
- sub_dctXxX : [OK]
- add_idctXxX : [OK]
- (i)dct4x4dc : [OK]
- (i)dct2x2dc : [OK]
mc[0][mv(2,1) 8x16] [FAILED]
mc[0][mv(2,1) 8x8 ] [FAILED]
mc[0][mv(2,1) 8x4 ] [FAILED]
mc[0][mv(2,1) 4x8 ] [FAILED]
mc[0][mv(2,1) 4x4 ] [FAILED]
mc[0][mv(2,3) 8x16] [FAILED]
mc[0][mv(2,3) 8x8 ] [FAILED]
mc[0][mv(2,3) 8x4 ] [FAILED]
mc[0][mv(2,3) 4x8 ] [FAILED]
mc[0][mv(2,3) 4x4 ] [FAILED]
- mc luma : [FAILED]
- mc chroma : [OK]

I wonder if those "failed" messages are relevant or not...

EDIT: maybe it's better to add that I use NASM version 0.98.38, compiled on Sep 12 2003

virus

akupenguin
5th January 2005, 23:41
If it says failed then it means failed.
x264: MMXEXT against C
- pixel sad : [OK]
- pixel satd : [OK]
- pixel avg : [OK]
- sub_dctXxX : [OK]
- add_idctXxX : [OK]
- (i)dct4x4dc : [OK]
- (i)dct2x2dc : [OK]
- mc luma : [OK]
- mc chroma : [OK]
x264: All tests passed Yeah :)

SeeMoreDigital
5th January 2005, 23:42
Originally posted by Leo 69
Try to change the fourcc to H264 Thanks Leo, that did the trick :D

You guys might be interested to know that for me, the codecs default, 4CC code of "h264" did not work but "H264" did!

And I'm using good old faithful MPEG Mediator as an encoding front end ;)


Cheers

Sirber
5th January 2005, 23:54
Oh, sorry. Works now, didn't know it was overwriting the old one :) Gonna add to RealAnime :)

SirCanealot
6th January 2005, 00:51
OMFG, w00tz0rs!!!!
Great stuff, I'm taking a look at this now, and it looks very, very decent :)

I'll probably have some questions to ask later~

*is excited at the concept of ditching silly XVid* :P

Moitah
6th January 2005, 01:11
It doesn't work with avs2avi, ICSeqCompressFrameStart fails.

SirCanealot
6th January 2005, 01:35
Could anyone explain to me what the following in advanced settings does? I'm looking for MAX quality :)

B-Frame prediction mode;
Motion search precision - what should be set for max quality?
I note Sub-8x8 PFRAME search isn't on, and Subpixel Refinement precision is only set to 3.
I'd muck around, but if someone could tell me what'll look best, that'd be great :P

Also, I've encoded with B-Frames on.
I tried one thing at Quant 18, and B-Frames were therefore Quant 20. It seems like H.264 deals with larger Quants, so wouldn't it be better if B-Frames were a higher quant? Defaults in XVid make Quant 2 use Quant 4 B-Frames, and Quant 4 use Quant 8 B-Frames, so just an increase of 2 seems a bit weird...

Thanks~

akupenguin
6th January 2005, 01:59
B-frame prediction mode: Adaptive would be better, but until I code that you only get one per movie. The better coice depends on content, but in general spatial is better psnr while temporal looks better.

The equivalent of XviD's quant 2/4 would be P-frames at qp=18 and B-frames at qp=24. But I have always been annoyed by XviD's low quality B-frames, so I turned it down. P@qp=18 with B@qp=21 (i.e. pb_factor=1.4) is the optimal psnr per bitrate, but you'll have to decide for yourself whether it looks better.
As with all settings, I haven't spent much time coming up with good defaults.

Sirber
6th January 2005, 03:30
Originally posted by Moitah

It doesn't work with avs2avi, ICSeqCompressFrameStart fails. * Pass 1/1: Frame 2/431, 0 B, 0.00 FPS, ETA

seems working, but uses 0% CPU and don't go on. :(

Moitah
6th January 2005, 05:00
avs2avi uses ICSeqCompressFrame* functions, where VirtualDub uses ICCompress* functions. I'm not sure why, but avs2avi's way doesn't work with sex264. I changed avs2avi to use ICCompress* and it's now working (including the b-frame workaround).

EDIT: See next post for download link.

Moitah
6th January 2005, 06:27
avs2avi 1.39x (http://www.avs2avi.org/avs2avi-139x.zip) <-- Here it is :). Use this only for x264 encoding, 'cause I'm not sure if it still works fine with all other codecs after I switched from ICSeqCompressFrame to ICCompress.

NOTE: The FourCC must be 'h264' (case sensative... sorry, I said 'x264' earlier which is wrong) for the B-frame workaround to work.

Yong
6th January 2005, 11:29
I got a assertion failed warnigs when encode video at second pass...

Some suggestion for the sex264vfw(most of them may same as XviDvfw):
1. Disble first pass video output:D
2. Selectable first pass statistic file location
3. Min/max Quant settings

Here how to install sex264 vfw manually(sorry, for M$ win2k and XP only:():

Open the registry editor, go to this key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\drivers.desc
Add a new "string value"
The name should be "x264vfw.dll"(place the x264vfw.dll to system directory), and the value is "SEXY 264"

Next is this key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32,
add a new "string value" again,
the name is "vidc.x264"
the value is "x264vfw.dll"
That's all:p

Tommy Carrot
6th January 2005, 12:55
After some tests, i can gladly say that contrary to what i expected, b-frames are already beneficial to the quality even in this early stage. The detail level is slightly better, but the biggest improvement is in the motion fluidity, enabling the b-frames almost completely fixes the "jumping blocks" issue, which was my biggest problem with x264. Nice job!

Ark
6th January 2005, 13:24
Yes, b-frames really helps a lot, expecially with small detail in background.

But i noticed that using spatial prediction mode cause heavy ghosting in some parts of the frame, while temporal is good.

Sirber
6th January 2005, 13:24
the encoded clip (at 4FPS, CBR) is plauying with blinking gray frames :SOriginally posted by Moitah
NOTE: The FourCC must be 'x264' (case sensative) for the B-frame workaround to work. [/B]Tryed, cannot decode. Bust I do the reg tweak above?

sysKin
6th January 2005, 13:29
Thank you everyone for your testing - I've noted all the bugs you've found so far. Unfortunatley I'm busy again so I won't give you an updated build just yet - perhaps tommorow.

Originally posted by Sirber
the encoded clip (at 4FPS, CBR) is plauying with blinking gray frames :STryed, cannot decode. Bust I do the reg tweak above?
I've seen these frames with older directshow decoder. Yesterday's build works well, at least for me.

Sirber
6th January 2005, 13:32
How can I update? ffdshow is at it'S latest (Oct 12) :(Originally posted by sysKin
Thank you everyone for your testing - I've noted all the bugs you've found so far. Unfortunatley I'm busy again so I won't give you an updated build just yet - perhaps tommorow.Woot woot :D

Ark
6th January 2005, 13:34
A small question: what's the difference between Deblocking filter Strength (A) and (B)? One is aplicated before the other? Or is it some sort of spatial x(horizontal/y(vertical) implementation? Or temporal?

Thanks!

Sirber
6th January 2005, 13:36
Would be cool to set in red the "not working" options :)

Ark
6th January 2005, 13:36
Originally posted by Sirber
How can I update? ffdshow is at it'S latest (Oct 12) :(Woot woot :D

try celtic_druid's builds here (http://celticdruid.no-ip.com/xvid/ffdshow/), they're more recent (and can decode 2-bframes made videos...)

Sirber
6th January 2005, 13:37
Originally posted by Ark
try celtic_druid's builds here (http://celticdruid.no-ip.com/xvid/ffdshow/), they're more recent. URL does not work :(

Ark
6th January 2005, 13:40
Yes now it's down :confused: ...try this (http://ebola.gamersrevolt.it/celticdruid/ffdshow/) mirror...

Sirber
6th January 2005, 13:40
Thanks :D

Sirber
6th January 2005, 14:00
2pass failed: Error: Unable to find the state file.

celtic_druid
6th January 2005, 15:15
Site should be back up tomorrow some time.

Sharktooth
6th January 2005, 15:24
Fortunately i've mirrored the 2004.01.05 build just before the celtic druid website went down :)
As Ark said just use that mirror to get the latest build.

hellfred
6th January 2005, 16:29
Originally posted by virus
Well, thx for the suggestion :)
I've tried it, though I have no idea if this utility is updated or not and whether it should work or not (anyway, syskin uses msvc for compiling and not gcc like me - and in both cases, everything is very slow here).

Here's the output:

x264: MMXEXT against C
- pixel sad : [OK]
- pixel satd : [OK]
- pixel avg : [OK]
- sub_dctXxX : [OK]
- add_idctXxX : [OK]
- (i)dct4x4dc : [OK]
- (i)dct2x2dc : [OK]
mc[0][mv(2,1) 8x16] [FAILED]
mc[0][mv(2,1) 8x8 ] [FAILED]
mc[0][mv(2,1) 8x4 ] [FAILED]
mc[0][mv(2,1) 4x8 ] [FAILED]
mc[0][mv(2,1) 4x4 ] [FAILED]
mc[0][mv(2,3) 8x16] [FAILED]
mc[0][mv(2,3) 8x8 ] [FAILED]
mc[0][mv(2,3) 8x4 ] [FAILED]
mc[0][mv(2,3) 4x8 ] [FAILED]
mc[0][mv(2,3) 4x4 ] [FAILED]
- mc luma : [FAILED]
- mc chroma : [OK]

I wonder if those "failed" messages are relevant or not...

EDIT: maybe it's better to add that I use NASM version 0.98.38, compiled on Sep 12 2003

virus
Looks like you CPU has a notch, as the tests do work on both of my system. Akupenguin is maintaining that peace of code, So if he says the tests are up to date and working, i would believe him :D
But how this is related to your system being slow when encoding videos, i do not know, as i would expect defect CPUs to be as fast as sane ones, but producing damaged frames.
Hellfred

EDIT: Forgot to mention that i am using same version of nasm

olnima
6th January 2005, 16:48
Happy new Year to all,
one question looking into the future:
Is it possible someday in the nearer future to use this codec for capturing / realtime-encodings? I'm asking because I do not have any idea about possible speed-improvements and about "how beta is beta". Maybe the kind of encoding is too CPU-hungry for todays CPUs.
In VirtualDub I got ~10fps (Athlon 3000+).

BTW: I couldn't use the codec in VirtualVCR for capturing. Selection is possible, but recording doesn't start.

Maybe Syskin or other "knowing people" can do some "Forecasts"

Thanks alot

Olnima

Koepi
6th January 2005, 17:20
With available high-end systems it's not yet possible to achieve realtime encoding.

It'll last a few more years until this will happen (and then we have HDTV instad of PAL/NTSC resolutions so the bigger image eats up all the speed gain - it'll last even longer).

Regards
Koepi

olnima
6th January 2005, 17:28
Thanks for reply.
That means to me: stay at good old xvid. And I do NOT have anything against that :-)

Olnima

Sergejack
6th January 2005, 18:05
Is the bitstream already defined ? (meaning what we encode now will still work on further releases)

stephanV
6th January 2005, 18:06
Originally posted by Sergejack
Is the bitstream already defined ? (meaning what we encode now will still work on further releases)

since they are trying to make an H264/AVC codec i would certainly hope so. :)

(of course, this excludes bugs)

Latexxx
6th January 2005, 18:08
Originally posted by Sergejack
Is the bitstream already defined ? (meaning what we encode now will still work on further releases)
It is already standardised. That means that every contemporary encoder which follows the standard can be decoded in the future.

Sirber
6th January 2005, 18:15
Anyone got the 2pass working?

Lordlic
6th January 2005, 18:23
Originally posted by Sirber
Anyone got the 2pass working?

Yup, it's working fine here. 2pass @ 900 kbit/s and subpixel refinement precision is 5. I didn't touch anything else. I used a dvd source (avs anyway).

(I used the pre-compiled version.)

CruNcher
6th January 2005, 18:47
be carefull it won't encode anything non mod16

virus
6th January 2005, 19:10
Originally posted by hellfred
Looks like you CPU has a notch
My CPU has no problems at all. In fact, doing a fresh checkout and recompiling everything makes checkasm go fine (but x264 is still very slow).

But considered the problems we (we all, not just me) had in the past using ffdshow (forcing to install alternative versions of ff_x264.dll compiled by celtic_druid to avoid blocking) I'd say that something's wrong in the ASM code, especially the MMXEXT routines which made gcc b0rk badly with optimizations enabled.

Oh, important detail I forgot to mention: here the speed of a build without ASM is similar to those with ASM enabled. Couple this with the amazing speed I get with celtic_druid's ff_x264.dll (and only with it) and maybe you'll have an hint about what's going on...

easyfab
6th January 2005, 20:05
Ok here is my little test about x264 options .
I want to know what exactly each options give for results.

The avi source was encode with vdm and sex64 05.01.05 at quant 10

The results:

( size ; ssim ; gain)
all options min (37.5 ; 96.55 ; reference)
all options min + cabac (35.6 ;96.55 ;5%)
all options min +intra 4x4 (37.2 ;96.62 ;~0% but more qual.)
all options min +sub 8x8 (37.5 ;96.55 ;0%)
all options min +sub 16x16 (37.1 ;96.53 ;1%)
all options min +srp 5 (35.7 ;96.56 ;5%)
all options min +max ref 15 (36.9 ;96.54 ;2%)
all options min + all above (32.0 ,96.61 ;15%)


all options min + bf1 (71.59 ??? )

I have prob with bframe so i exclude this option from my test.
The most gain are with cabac and sub ref precision.
And what impress me is that with all options enable the gain is superior of the sum each option alone.
For me, i will always enable all at max.
(Caution, this test was only done of one sample file)

Ark
6th January 2005, 20:20
I noticed that b-frames have a huge impact on quality for given filesize, but they don't like very well flames....in fact i encoded 1 minute of the intro of LOTR SEE, and when there're flames it's all a blocky fest (but only in b-frames)...

I can attach a clip if someone want to look...

Settings used were:

- 2-pass@800kbps
- CABAC ON
- Deblocking filter ON with:
- Strength (A) at -4
- Strength (B) at -3
- Max Reference frames 2
- Max B-frames 2
- B-frame prediction mode 1 (temporal)
- MSP with all options checked
- Subpixel refinement precision 5

all other settings at default.

akupenguin
6th January 2005, 20:27
Originally posted by easyfab
The avi source was encode with vdm and sex64 05.01.05 at quant 10 quant 10? that's lower than mpeg4 @ quant 1.
all options min + bf1 (71.59 ??? ) That's probably the B-frame delay matching up encoded frames to the wrong source frames.
And what impress me is that with all options enable the gain is superior of the sum each option alone. You can't test options alone. sub8x8 requires sub16x16, and only works well with good sub pixel refinement. multiple ref frames help much more with cabac and spr than they do alone.


@syskin, suggestions:
Disable psub8x8 checkbox if psub16x16 is unchecked.
Remove numbers from "bframe prediction" (the names are the only meaningful part).
While the two deblocking paremeters are theoretically separate (you could say A is strength, B is threshold), I haven't found any use for adjusting them separately; a single slider would be just as good. (Anyone have examples to the contrary?)
bugs: If I click "load defaults", it sets everything to 0.

Originally posted by Ark
i encoded 1 minute of the intro of LOTR SEE, and when there're flames it's all a blocky fest (but only in b-frames)... If you're decoding it in ffdshow, that's partly because we don't yet deblock B-frames.

Ark
6th January 2005, 20:35
Yes, ffdshow's decoding...

eb
6th January 2005, 20:55
olnima wroteIs it possible someday in the nearer future to use this codec for capturing / realtime-encodings? I'm asking because I do not have any idea about possible speed-improvements and about "how beta is beta". Maybe the kind of encoding is too CPU-hungry for todays CPUs.
In VirtualDub I got ~10fps (Athlon 3000+).


Thanks to Koepi and Xvid, and ffdshow it is possible to encode in real time from digital satelite broadcasting even with such not powerful as my Athlon 2200+ (at2000MHz).
Samples you can see on ftp://www.eb.enterpol.pl
user name www.eb.enterpol.pl
password eb

Latest two sample were recorded on live to Xvid with 1 b-frame with cropping to 720x320 at the same time audio was converted to 6 ch LPCM.
Video was not processed latter but audio was processed to 6 channel AC3, AAC,OGG and mp3 and mp2.
Two samples with this multiaudios are clearly named.

eb

olnima
6th January 2005, 21:05
I'm also capturing in realtime using xvid.
Can You tell me something about your hard/software and your configuration? xvid-settings, ffdshow-settings, digital or analog card, etc.

Would be nice if You open a thread in the capturing-section.

Greetz
Olnima

eb
6th January 2005, 21:25
Hi olnima,

It is not capturing this is recording, this names i am using to distinguish between video sources.
In my case it is SS2 DVB PC card for digital sat tv.
Programs that are useful for this are SkyView by marfi, MyTHeatre 2.76 by Saar.
I am going to present Graphedit drawings for this two samples and post there is short my post in http://forum.doom9.org/showthread.php?s=&postid=587202#post587202hem in satelite thread of this forum.

eb]

Sirber
6th January 2005, 21:35
Where does it store it's analisys file?

SeeMoreDigital
6th January 2005, 22:16
Sadly, just like Sirber, I'm only able to generate 1pass encodes too!


Cheers

Ark
6th January 2005, 22:22
Originally posted by Sirber
Where does it store it's analisys file?

...just where it stores the first-pass .avi file!
It should be named "x264.stats".

Sirber
6th January 2005, 23:24
Originally posted by SeeMoreDigital
Sadly, just like Sirber, I'm only able to generate 1pass encodes too!


Cheers Works now, was an error in my code :) Wasn't calling the right config file for second pass for avs2avi :rolleyes:

SeeMoreDigital
6th January 2005, 23:34
Originally posted by Sirber
Works now, was an error in my code :) Wasn't calling the right config file for second pass for avs2avi :rolleyes: I'm not using AVS files... but it (sort of) works for me too!

However, my 2pass encodes "hang" when played in ShowTime... and they don't seem to look as good as the 1pass :(

This reminds me of what used to happen with early versions of VP6 in 2pass mode!


Cheers

Sirber
6th January 2005, 23:43
Did you get latest ffdshow? Try in MPC :o

http://ebola.gamersrevolt.it/celticdruid/ffdshow/

So far my encodes are all blocky (big blocks), at 536kbps, anime content.

http://www.detritus.qc.ca/test.mkv

akupenguin
7th January 2005, 00:17
Originally posted by Sirber
So far my encodes are all blocky (big blocks), at 536kbps, anime content. First thing to try: don't use more than 1 B-frame, as they're not yet adaptive. (I'm pretty sure the beginning of your clip would be better off with no B-frames.) Also, ffdshow doesn't yet deblock B-frames.

Sirber
7th January 2005, 00:22
oh, good, trying :D

Paced
7th January 2005, 00:25
Nice work sysKin! But, I'm afraid I have to report something 'wierd.' Sex264 was working flawlessly for me up until I rebooted my computer - for the first time since I'd installed it. Now, VirtualDubMod just seems to abort the process/job 1/4 of the way through the first pass (I'm using the same settings I used before the reboot, and everything is being done the same way). Basically, VDubMod just exits, and when I re-open it to check the Job Control, it says that Job 1 was Aborted :confused: I then proceeded to try other codecs - XviD, VP6, etc. and they all worked fine on the same job.

Note: I also uninstalled sex264 then reinstalled it (without rebooting, not sure if that matters), but the same thing is still happening (Win2K Pro, SP4).

bond
7th January 2005, 00:32
two things:

- vd outputs error messages always at the end of each pass (not really an error message, but in the job control, next to each job there is a note "warning", which says "dub: i/o thread has not cycled for 10seconds - possible livelock" or so

- syskin, you might want to rename the subpartition options a little bit to make clear what they enable:
like "enable 8x8, 16x8, 8x16", or "enable 16-8 search..."

Doom9
7th January 2005, 08:29
"dub: i/o thread has not cycled for 10seconds - possible livelock"I've seen this a lot recently when I encoded for the codec comparison. It happened with all kinds of codecs and I have no idea what causes it.

akupenguin
7th January 2005, 09:37
Originally posted by Doom9
dub: i/o thread has not cycled for 10seconds - possible livelock That simply means that the codec is slow.

Blue_MiSfit
7th January 2005, 10:25
x264 is amazing on cartoon material.

I can achieve a 720p encode of Family Guy at less than 1000kbit.

I can do full frame 480p encodes with he-aac and do 94mb per episode to fit the entire series on one DVD-R (50 episodes at 94mb is 4.7 GB).

All this is with light spatial denoising only...

UnDot()
and
UnFilter(-5,-5)

and Lanczos as the resizer always.

Of course this is with all the quality enhancing features enabled, 2 passes, and 15 reference frames, so it runs very slowly encoding even on my overclocked athlon 64.

Works for me at any rate :)

btw, this may have been answered already and I apologize if it has been, but has x264's bitstream been finalized? I dont want to do a whole DVD-R of this stuff only to have future decoders b0rk...

~misfit

akupenguin
7th January 2005, 11:27
Originally posted by Blue_MiSfit
btw, this may have been answered already and I apologize if it has been, but has x264's bitstream been finalized? I dont want to do a whole DVD-R of this stuff only to have future decoders b0rk... Yes. x264 outputs H.264 Main Profile, which was finalized in 2003. There may well be bugs in x264, but nothing will intentionally break compatibility.

Yong
7th January 2005, 11:38
Crash virtualdub during first-pass:
An out-of-bounds memory access (access violation) occurred in module 'x264vfw'...
...while compressing frame 2468 from 022b0000 to 0a6b0020 using codec "x264 - H264/AVC encoder" (VideoSequenceCompressor.cpp:594)...
...while running thread "Processing" (thread.cpp:150).


Here's my encoding first-pass option:
bitrate=600, No CABAC, deblocking filter -3:-3, Max refrence frames 3, Max b-frames=1, prediction method= 2 spatial, max key frame interval= 300, subpixel refinement precision=0

Can i disable the CPU-hungry option at first-pass(just like the mencoder 2pass first-pass encoding)?

708145
7th January 2005, 17:41
constant quant for first pass gives better results than constant bitrate. Maybe you want to try. And very maybe it doesn't crash then as well.

bis besser,
T0B1A5

JoeBG
7th January 2005, 20:47
I donīt have any crash. Everything works fine with celticdruids ffdshow filters. Iīm making a comparison in the moment between 1 b-frame 2-bframe and 3frame with 5 reference frames. Seems to be, that 3 b-frames brings the best results.

PlazzTT
7th January 2005, 21:04
The Last Samurai, 34 second comparison at ~500kbps

XviD (Cruncher's Extra Detail 1.3) (http://eirways.com/x264/xvid2.avi) (2.03MB)
(default settings, QpeL, 2 Bframes)

X264 (with sex264) (http://eirways.com/x264/x2642.avi) (2.09MB)
(defaults but with 1 BFrame (Spacial))

SeeMoreDigital
7th January 2005, 21:07
Originally posted by PlazzTT
The Last Samurai, 34 second comparison at ~500kbps

XviD (Cruncher's Extra Detail 1.3) (http://eirways.com/x264/xvid2.avi) (2.03MB)
(default settings, QpeL, 2 Bframes)

X264 (with sex264) (http://eirways.com/x264/x2642.avi) (2.09MB)
(defaults but with 1 BFrame (Spacial)) Are they 1pass or 2pass encodes?


Cheers

PlazzTT
7th January 2005, 21:34
2-pass.

X264 used ~511kbps, btw, XviD used 497kbps.

I aimed for 500kbps in both.

EDIT: Here's X264 @ 200kbps if anyones interested.
872kb (http://eirways.com/x264/x264_200kbps.avi) (same specs as X264 clip above, but at 200kbps)

SeeMoreDigital
7th January 2005, 21:55
Originally posted by PlazzTT
Here's X264 @ 200kbps if anyones interested.
872kb (http://eirways.com/x264/x264_200kbps.avi) (same specs as X264 clip above, but at 200kbps) Bloody good... And perfectly watchable.

Nice one!

SeeMoreDigital
7th January 2005, 22:40
Try this (http://82.2.167.237/Uploaded_Files/Doom9_Forum_files/720x576@149.0Kbps.mp4) Recode2 encode, generated at just 150Kbps at full DVD resolution!


Cheers

Fl0ppy
7th January 2005, 23:35
how i can play a .mp4? :confused:
I not use nero recode

Blue_MiSfit
8th January 2005, 00:37
If you have Recode installed you have Ahead's AVC/AAC decoders installed and you should be able to play that MP4 on any decent player like Core, or Media Player Classic

kurt
8th January 2005, 00:40
or install for example ffdshow (05.01.05) (http://ebola.gamersrevolt.it/celticdruid/ffdshow/) and activate decoding h264 in it....

@SMD: nice vid @ such low bitrate ! :)

bond
8th January 2005, 01:52
Originally posted by Fl0ppy
how i can play a .mp4? :confused:
I not use nero recode :search: this has been answered a thousand times already :devil:

ChronoReverse
8th January 2005, 02:07
I suppose I might be missing something, but the two clips at 2.03MB aren't too far apart in quality.

PlazzTT
8th January 2005, 02:27
Originally posted by ChronoReverse
I suppose I might be missing something, but the two clips at 2.03MB aren't too far apart in quality.

On my PC, if I view them both in full-screen mode (1280x1024) there is very obvious ringing and typical MPEG artifacts around the edges (eg- just over peoples shoulders).

This effect is much less in the X264 encode, IMO.

JoeBG
8th January 2005, 08:23
Okay I made a comparison between 3, 2 and 1 b-frame
the other settings were:
bitrate=1000, CABAC, deblocking filter -2:-2, Max refrence frames 5, , prediction method= 1 temporal, max key frame interval= 250, subpixel refinement precision=4=always b-frames

For me, Max b-frames=3 brings best results (with celticdruids newest filters), sadly the clips are too big to up them somewhere. Iīll make shorter (=smaller :) ) ones next time


My problem is, I donīt find a muxer to convert them into MP4 (fourcc is h264). The following donīt work:
- 3ivx: as expectet
- mp4creator60: I really thought he can do this
- mp4box: I was sure this would work
- MP4UI: as expectet

Any new ideas?



The second thing is the question, how to make the first pass faster. The second pass ist as fast as with Ateme. But the first pass with Ateme is much faster. Canīt we have something like "discard first pass" like in Xvid?

plonk420
8th January 2005, 09:47
maybe bobolo will share MP4 Toolbox to the general public?

akupenguin
8th January 2005, 10:10
Originally posted by JoeBGermany
My problem is, I donīt find a muxer to convert them into MP4 (fourcc is h264).
ffmpeg -vcodec copy -i x264.avi -y x264.mp4
I don't know how compliant the result is, but I can play it in MPlayer.

The second thing is the question, how to make the first pass faster. The second pass ist as fast as with Ateme. But the first pass with Ateme is much faster. Canīt we have something like "discard first pass" like in Xvid?
Feel free to use faster options on the 1st pass. subpixel refinement, # reference frames, and psub8x8 are good candidates to reduce at little cost in the 2nd pass's quality.
I don't have a single option to do the adjustments for you, because the speed/quality tradeoffs are still changing, so any effort I spend now optimizing the decisions will become obsolete soon.

Doom9
8th January 2005, 11:17
unfortunately, I'm also getting a 2nd pass error. Interestingly enough, when I closed VDub, opened it and created my job manually (I had set up the 2nd pass job in the job list and wanted to run it this morning), things worked just fine. In absence of a vdub log entry I have no idea what went wrong when trying to start the 2nd pass for the first time.

mezzanine
8th January 2005, 11:38
My second pass gave an error at ~ 60% (rate.c something error) with b-frames enabled.
With all advanced options switched off everything worked smoothly. I'm gonna try another 2-pass encoding tonight with the default options and see what happens.
Very good quality so far..

IgorC
8th January 2005, 13:52
sorry for offtopic but i need advise.

Right now iīm encoding a DVD Harry Poter pr. Azkaban( 2h 9m) in recode2 Nero H.264 (too slow options: ref 6, b 3, Extra , MV 511, 2pass.... ) but i want to test sex264 in Vdub. will be there any problems (artefacts) if iīll do it at the same time?
can i put pause in recode2 encoding?

JoeBG
8th January 2005, 14:12
Originally posted by akupenguin
ffmpeg -vcodec copy -i x264.avi -y x264.mp4
I don't know how compliant the result is, but I can play it in MPlayer.


Works very good for me, thanks.

Another question maybe is what brings best quality in the field motion search precision. I choosed sub-8x8 PFRAME search and 4x4INTRA search together and nothing else. Can I make it better?
Which combination brings best results?

Tommy Carrot
8th January 2005, 14:52
Originally posted by JoeBGermany
Which combination brings best results?
If everything is working correctly, then enabling all of them should give the best quality (and slowest encoding speed too :p).

DeathTheSheep
8th January 2005, 20:28
ALL of them? You gotta be kidding... :-)

Wow, I typically don't use B-frames... With no deblocking and slower encode time, what use are they?

The only things that really help are yer reference frames. I typically stick in 15. Compared to 1, 2, or even 3, this thing packs one heck of a punch in the lamb chops, baa

Cheers, baa

Blue_MiSfit
8th January 2005, 22:03
hmm well after watching more thoroughly my 95mb family guy x264 episodes I noticed a strange problem with multiple consecutive b-frames.

Occasionally some of the b-frames will recieve absurdly high quantization, blocking very heavily (see my samples), while some of their neighboring b-frames recieve normal quantization, and look nice.

I'm not short on bitrate... considering 95-99% of the frames look incredible.

I'm not complaining, rather inquiring if ppl are aware of this rate control bug.

Samples:
clean frame
http://people.ucsc.edu/~dpresteg/bvop_clean.jpg

b0rked b-frame (previous frame's neighbor)
http://people.ucsc.edu/~dpresteg/bvop.jpg

Leak
8th January 2005, 22:54
Originally posted by Blue_MiSfit
Samples:
clean frame
http://people.ucsc.edu/~dpresteg/bvop_clean.jpg

b0rked b-frame (previous frame's neighbor)
http://people.ucsc.edu/~dpresteg/bvop.jpg

Maybe it's just me, but this doesn't look like it was just overquantized - there's so much residue from the surrounding frames that something else must have gone wrong here...

Not that I'm well-versed in codec development, mind you... :)

np: Pan Sonic - Käytävä / Corridoor (Kesto (234.48:4) (Disc 3))

akupenguin
9th January 2005, 00:38
Yes, that's drastically overquantized.
H.264@qp=37 is ~equivalent to mpeg4@qp=18, while H.264@qp=46 would be equivalent to mpeg4@qp=50 if the scale went that high. Any frames that look good at qp=37 are just because they happen to motion compensate very well based on a P-frame at lower quantizer. (unless ffdshow displays some wacky quantizer scale?)
That said, it is a bug and I will try to find it.

Blue_MiSfit
9th January 2005, 01:28
I am suspicious of ffdshow's OSD... Its "input bitrate" is never correct with h264, so perhaps the quantizer scale is incorrect as well.

I am re-encoding with 1 bvop and will let you know if these frames are better.


encode finished. Problems persist with b-frames.

I am using ffdshow to decode, a very recent version from celtric_druid, his jan 5 build.

Could this be a decoder issue and if so how can I try another one?


~misfit

haibane
9th January 2005, 05:37
I have the same problem as Blue_MiSfit with the overquantization with 2 bframe enabled on anime contend. I tried to use both ffdshow and nero video decoder, they both showed very blocky frames. The only difference is that for the nero decoder, it looks like it have the deblocking on but it is turned off, while the ffdshow is showing distinct blocks.

akupenguin
9th January 2005, 05:49
Bug found. I can't reproduce anything that extreme, but some of my encodes do use B-frame quantizers significantly higher than I asked for. Now testing alternative ratecontrol methods.

sysKin
9th January 2005, 07:28
Hi everyone,

I just uploaded an updated version. Small changelog:
- uses core revision 88 - akupenguin has improved some speed and quality
- cosmetical fixes of all kinds
- some widgets get disabled when they are not active
- "x" button now closes the advanced dialog (works like "ok", not "cancel")
- first pass drops the bitstream. this also improves speed because we can skip some packaging stuff
- "load defaults" *probably* works better (I couldn't reproduce the problem but I think I know why it happened)


Stuff *not* fixed:
- no new widgets added (bframe ratio, stats file location, etc etc)
- no old widgets removed (still two settings for deblocker)
- still the same fourCC ("avc1" crashes ffdshow, because it makes ffdshow expect different packaging method)
- I never touched the core - second pass might still fail just like before

Have fun,
Radek

link: http://syskin.is.dreaming.org/x264/

JoeBG
9th January 2005, 11:56
Great :) :) :)

Just unzip and replace?

Doom9
9th January 2005, 11:59
I'd suggest a clean uninstall and then install the new one. That's always the safest way not to mess up your Windows.

mezzanine
9th January 2005, 14:19
Second pass only fails with b-frames enabled. I tested your latest build and it seems to stuck at the last frame with avs2avi (1st pass).

trbarry
9th January 2005, 14:41
I don't know much about AVC but the "quant" artifacts above are really more typical of a bug in motion comp pointing at the wrong reference blocks or frames. You can see it where little pieces of the image appear in the wrong places.

I've manage to create such bugs once in a while in my own coding on other projects.

- Tom

JoeBG
9th January 2005, 14:44
Originally posted by Sharktooth
Fortunately i've mirrored the 2004.01.05 build just before the celtic druid website went down :)
As Ark said just use that mirror to get the latest build.

When itīs not too much work, it would be fine to have also the mplayer/mencoder win32 compile for the x264gui from doom9 on your side. Is this possible? :thanks:

Shinobu
9th January 2005, 17:06
no more "load default" bug on my computer.

++

Leak
9th January 2005, 18:28
Originally posted by trbarry
I don't know much about AVC but the "quant" artifacts above are really more typical of a bug in motion comp pointing at the wrong reference blocks or frames. You can see it where little pieces of the image appear in the wrong places.

That's exactly what I meant in my last post, but I guess I could have worded it better... :)

np: Pan Sonic - Painovoima / Gravity (Kesto (234.48:4) (Disc 1))

bond
9th January 2005, 19:04
Originally posted by JoeBGermany
My problem is, I donīt find a muxer to convert them into MP4 (fourcc is h264). The following donīt work:
- 3ivx: as expectet
- mp4creator60: I really thought he can do this
- mp4box: I was sure this would work
- MP4UI: as expectet:search: as described in the container forum, its already possible to mux raw h.264 into .mp4 correctly with mp4creator (demux the h.264 stream from .avi with mpeg4ips avi2raw tool)
also you can mux h.264 in avi or raw into .mp4 with videolan (this is currently broken in the svn, but works fine here with an old compile i have here from july)
note that both tools will not work correctly with b-frames

Originally posted by sysKin
- still the same fourCC ("avc1" crashes ffdshow, because it makes ffdshow expect different packaging method)thats strange. basically because till now there is no avc-in-avi content existing that uses the avc1 fourcc, so i wonder why it should expect special packaging in ffdshow? also i never had a problem with avc-in-avi using the avc1 fourcc...
is it only with b-frames?

virus
9th January 2005, 19:22
two small cosmetic things, very easy to correct:

1) since rev. 86, subme=0 has been disabled. Needs to be removed from the gui.
2) in the About box, the "Visit homepage" button links to an outdated address. The new one is http://videolan.org/x264.html (file /vfw/x264vfw.h)

(btw @akupenguin: the "encoder features" list in that webpage is somewhat outdated, it doesn't list the latest additions to b-frames, as well as the 2pass RC and 1 pass const quantizer)

virus

JoeBG
9th January 2005, 20:26
Originally posted by bond
:search: as described in the container forum, its already possible to mux raw h.264 into .mp4 correctly with mp4creator

This is something I understand and can do. You think of this commandline donīt you:
mp4creator60.exe -c raw-avc-stream.h264 -rate 25 avc.mp4

Originally posted by bond
(demux the h.264 stream from .avi with mpeg4ips avi2raw tool)

But I cantīt find any explanation for this. In the whole threat everyone writes "demux with avi2raw tool". But how does this work. So I googelt to the avi2raw site and found this:
avi2raw -v mymedia.avi myvideo.yuv or
avi2raw -v mymedia.avi myvideo.rgb

I think for h.264 it should be
avi2raw -v mymedia.avi myvideo.h264

Is this correct?

Sergejack
9th January 2005, 20:28
Originally posted by bond
:search: this has been answered a thousand times already :devil:

I don't manage to find an answer in all that non sorted thousand answers.

bond
9th January 2005, 20:45
Originally posted by JoeBGermany
I think for h.264 it should be
avi2raw -v mymedia.avi myvideo.h264avi2raw doesnt care about the extension and it will always output the raw video stream
so yes, you are correct

bond
9th January 2005, 20:46
Originally posted by Sergejack
I don't manage to find an answer in all that non sorted thousand answers.troll?
you just posted a message in my mp4 faq sticky... what about reading it?

JoeBG
9th January 2005, 20:49
Originally posted by bond
avi2raw doesnt care about the extension and it will always output the raw video stream
so yes, you are correct

This is pretty clear now, thank you very much for your help. I often do not understand everything, so sorry for my many questions. :)

Sergejack
9th January 2005, 20:53
Originally posted by SeeMoreDigital
Try this (http://82.2.167.237/Uploaded_Files/Doom9_Forum_files/720x576@149.0Kbps.mp4) Recode2 encode, generated at just 150Kbps at full DVD resolution!


Cheers

Can I have a link to the Directshow binaries decoders for video and audio, pls ?

bond
9th January 2005, 21:02
Originally posted by Sergejack
Can I have a link to the Directshow binaries decoders for video and audio, pls ? ok thats enough...
you asked for the same in the container forum, you dont want to read and understand my answer there, you dont want to read my mp4 faq to find out how to play .mp4 files (altough you posted there) and now you ask again for illegal stuff

striked for rule 6

Fl0ppy
9th January 2005, 21:06
I juts tried with a few dvd's and xvid files and the compression it's amaziing!!:D

I can recode a xvid file at half size of the original (350mb's) and the quality looks really g00d.

Sergejack
9th January 2005, 21:12
Originally posted by bond
ok thats enough...
you asked for the same in the container forum, you dont want to read and understand my answer there, you dont want to read my mp4 faq to find out how to play .mp4 files (altough you posted there) and now you ask again for illegal stuff

striked for rule 6

I read your FAQ, it didn't help, I don't want any thirdparty player, I just want the decoder, and I don't have any idea what you'r talking about "illegal stuff".

I download 3ivx and installed it and I installed the raw ACC parser too, but still it doesn't display.
I also have the last Nero media player.

Don't blame me 'cause I didn't spend my all life here and I may have miss some basical your not even talking about in your FAQ.

Leak
9th January 2005, 21:22
Originally posted by Sergejack
I read your FAQ, it didn't help, I don't want any thirdparty player, I just want the decoder, and I don't have any idea what you'r talking about "illegal stuff".

Can I have a link to the Directshow binaries decoders for video and audio, pls ?

Since Nero doesn't make these available for download, asking for them here is a bit inapropriate, don't you think? Especially since representatives from Nero are reading this forum... *hint* *hint*

np: Iwasaki Taku - Let My Tears Stream (R.O.D The TV Original Soundtrack 1)

SeeMoreDigital
9th January 2005, 21:29
I take it you read this bit from bonds FAQ: -

http://img70.exs.cx/img70/6012/mpeg4avcdecoders0zm.gif


Cheers

Sergejack
9th January 2005, 21:35
May I suggest an option in the GUI of sex264 to save different profiles ?

Originally posted by Leak
Since Nero doesn't make these available for download, asking for them here is a bit inapropriate, don't you think? Especially since representatives from Nero are reading this forum... *hint* *hint*

np: Iwasaki Taku - Let My Tears Stream (R.O.D The TV Original Soundtrack 1)

So Recode2 is a Nero product ?
Weren't we taling about sex264 ?

Koepi
9th January 2005, 22:38
^Yes, and sex264 doesn't use mp4 as container.

So get your container issue sorted out (it's described even in this very thread i think) and then use celtic druids latest ffdshow (also linked to in this thread very often). (I.e. 3ivx mp4 splitter and ffdshow h264 decoder.)

It's not too much to ask from you to read the posts at least before starting flaming and complaining.

Koepi

Sergejack
9th January 2005, 22:53
Originally posted by Koepi
^Yes, and sex264 doesn't use mp4 as container.

So get your container issue sorted out (it's described even in this very thread i think) and then use celtic druids latest ffdshow (also linked to in this thread very often). (I.e. 3ivx mp4 splitter and ffdshow h264 decoder.)

It's not too much to ask from you to read the posts at least before starting flaming and complaining.

Koepi

I did do all of that before "flaming and complaining".
The question is "What does that Recode2 sample wich I can't render have to do with all of that ?"

bond
9th January 2005, 23:08
he asked for "noone knows what" filters to be available seperated from official packages to play avc-in-mp4
he got my answer that the links are there, he could also use search and that its illegal to provide commercial filters seperated from their original packages (especially nero as its payware)
he meant he also, quoting someone else, didnt find the answer for how to play avc-in-mp4 files, after he got my answer and after he posted the first question in the mp4 faq, which clearly says how you can do it
he asked for the nero filters seperated from the official packages, pointing to a nero encoded .mp4

but of course he was talking about x264...

to make it short: do not feed the trolls

IgorC
10th January 2005, 05:54
where can i get gui? there is nothing http://celticdruid.no-ip.com/xvid/mplayer/

iīm trying syskin x264
same situation here .Visual blocks are at wrong places.
x264 use more CPU than Nero AVC (maybe because of unoptim. ffdshow decoding)
bframes donīt work properly. more than 1 bframe brings visual bug, but itīs possible to notice how it increase a quality.

Ark
10th January 2005, 11:26
I tested more for this blocking issue, and saw that it only happen with 2-pass encodings, with 1-pass fixed quantizer i can set 1, 2 or 3 b-frames and it's all perfect!

JoeBG
10th January 2005, 13:29
Originally posted by Ark
I tested more for this blocking issue, and saw that it only happen with 2-pass encodings, with 1-pass fixed quantizer i can set 1, 2 or 3 b-frames and it's all perfect!

I also have blocking with b-frames. Only when I choose 0 b-frames itīs ok. But would be nice to have b-frames support :)

Sirber
10th January 2005, 13:33
Originally posted by Ark
I tested more for this blocking issue, and saw that it only happen with 2-pass encodings, with 1-pass fixed quantizer i can set 1, 2 or 3 b-frames and it's all perfect! Can't we use sex264 as a decoder instead of ffdshow? It should supports itself...

bond
10th January 2005, 13:49
Originally posted by IgorC
where can i get gui? there is nothing http://celticdruid.no-ip.com/xvid/mplayer/sex264 is a vfw wrapper for the x264 video encoder. another different wrapper is mencoder, which you can find via the link you pointed to

Originally posted by Sirber
Can't we use sex264 as a decoder instead of ffdshow? It should supports itself...whats wrong with installing ffdshow?
x264 doesnt include a decoder (of course encoder and decoder doesnt need to be combined or offered together when we are talking about an open standard (like mpeg-4), as all decoders following the standard should decode the stream). still x264 has a decoder, but its very weak
also when you look at aku's additions to ffmpeg's avc decoder, it can be seen as "x264's decoder"

Ark
10th January 2005, 14:58
Originally posted by JoeBGermany
I also have blocking with b-frames. Only when I choose 0 b-frames itīs ok. But would be nice to have b-frames support :)

Actually what i meant is that b-frames (1,2,3 or whatever) seems to be well supported, but only in 1-pass mode.
In fact in 2-pass mode they show the blocking issue i mentioned some posts ago (i also attached a screenshot), that it's not the usual blocking caused by too low bitrate, but a wrong allocation of macroblocks (i think...), they seems like a puzzle with pieces in the wrong place...

sysKin
10th January 2005, 15:00
Hi,
I'm glad to tell you that whole VfW code, as you've seen it yesterday plus two other changes, made it into x264's repository.

Changelog:
- removed subpixel refinement 0, as core doesn't support it anymore (thanks virus)
- changed x264's homepage to "the real one" (thanks virus)

At this moment, I concider sex264 round one closed. My next goal is to start hacking the core, and I will open sex264 round two to let you have fun with whatever bugs I invent.

The result of round one (ie the same x264 that is in CVS, revision 89) can be downloaded from the usual place http://syskin.is.dreaming.org/x264/

Thank you everyone for your time spent on testing and discussing this vfw library :D

Radek

chilledoutuk
10th January 2005, 15:41
I encoded a music video with this codec but I noticed black blocks apearing on the video when the camera zooms out very fast.

here is a clip of the encode where the blocks can be seen
http://www.aoul98.dsl.pipex.com/rachel clip.avi

Here is a clip from the source mpeg2 ts.
http://www.aoul98.dsl.pipex.com/source.mpg

these are the settings used
http://www.aoul98.dsl.pipex.com/sex264config.png

IgorC
10th January 2005, 20:10
by default 4x8 8x4 4x4 P frames turned off. what does it mean?
has it some problem or it too slow thatīs why is turned off.

untill now i didnīt notice visual bug of this oprtions maybe becuase of others like Bframes

akupenguin
10th January 2005, 20:28
Originally posted by IgorC
by default 4x8 8x4 4x4 P frames turned off. what does it mean? They used to reduce compression on some sources, but that should be fixed now. I just haven't rebenchmarked them to decide if they're always worth the speed cost. (It's not too slow, but they don't usually have a huge effect either.)

CruNcher
11th January 2005, 17:34
@chilledoutuk
known skip problem its being worked on

Sergejack
11th January 2005, 23:43
What does the "Every '1' th INTRA becomes a keyframe" ?
Isn't '1' meaning that each INTRA will be uncompressed ? (EDIT : I'm talking about a temporal compression here of course)
Because if that's trhe case, maybe '1' isn't a good choice for high compression.

stephanV
11th January 2005, 23:57
Intra frames are not uncompressed although they do tend to take up more space then a P or B frame. Anyway, in H.264 i-frames are not necessarily keyframes as with the multiple references a p-frame after that i-frame can refernce to a p-frame before it. Seeking from that i-frame is therefor impossible. To solve this a new frame type was introduced called an IDR frame. P frames after an IDR-frame are not allowed to reference a frame before the IDR frame, even if multiple references are used. Therefor, IDR frames can be used as seeking points.

Forcing every intra frame to become a keyframe will ensure that when a codec decides to insert an I-frame it is in fact an IDR-frame. This improves seekability of the file, while giving up a little bit of quality.

akupenguin
12th January 2005, 00:01
Intra frames always use no temporal prediction (that's what intra means.) But unlike previous formats, H.264 uses multiple reference frames, so just being intra does not guarantee that you can decode the following frames. So there's another kind of frame "IDR" which additionally guarantees seeking by blocking old references. Usually there's little or no loss from always using IDR on scenecuts, but sometimes (e.g. flashes or very high motion), the movie cuts back to the previous scene a few frames later. And then it can save some bits with multiple references if it didn't IDR.
If you are not using multiple refs, always set this to 1.
If you are, then I will eventually make this decision adaptive, but until then there isn't a good setting. (1 => wastes bits in high motion, 2 => wastes bits in low motion.)

708145
12th January 2005, 00:46
what about setting a max_idr_distance?
So worst case seekability is configurable but codec is still not forced to use a IDR too often.

bis besser,
Tobias

akupenguin
12th January 2005, 01:12
Yes, that's the plan. I'm just spending more time discussing it than implementing it.

Sirber
12th January 2005, 04:48
x264 dev? nice :D Are you using the videolan svn?

akupenguin
12th January 2005, 05:02
Yes, the official repository is the one on videolan.

akupenguin
12th January 2005, 05:54
I might have just fixed people's problems with blocks in B-frames. Or I might not. If not, someone will have to send me a sample, because I can't reproduce the bug here.

JoeBG
12th January 2005, 09:15
Originally posted by akupenguin
I might have just fixed people's problems with blocks in B-frames. Or I might not. If not, someone will have to send me a sample, because I can't reproduce the bug here.

Wow, thatīs good news, you have my admiration :). What do I have to update for MeGUI and for sex264 to begin with testing? (sorry if this is a stupid question):(

bond
12th January 2005, 10:40
Originally posted by JoeBGermany
What do I have to update for MeGUI and for sex264 to begin with testing? (sorry if this is a stupid question)you have to wait till someone compiles a new version of sex264 or mencoder :)

hellfred
12th January 2005, 10:45
Originally posted by JoeBGermany
Wow, thatīs good news, you have my admiration :). What do I have to update for MeGUI and for sex264 to begin with testing? (sorry if this is a stupid question):(
To get latest x264 improvements using MeGUI you need to get a mencoder.exe which was linked to a libx264.a build from x264 rev 92.
If you want it right away, you have to take it up with compiling mplayer/mencoder yourself. It is not that hard, as the howto i posted before tells you what to do step by step. Leave out all libs you do not need as you do not want to use the feature conneted to the lib. So if you e.g. do not plan to encode from a set of jpeg/gif/png pictures, there is no need to build those libraries.
So no need for
Step 2 ogg and vorbis
Step 3 freetype (for osd font rendering)
Step 4 zlib, libregif, libpng, libjpeg
Step 6 live.com rtsp streaming support

Which leaves you with
Step 1 Mingw and msys
downloading and installing MSYS/MinGW.
(Windows installer, one will ask you to type in some information)
Step 2 directx headers
(enhanced)Step 5
Just do the steps needed to build nasm and x264
Step 7 MPlayer
Try it, it is not that hard.

Hellfred

EDIT: directx may be mandatroy, too, as they are just needed for playback, but downloading an unpacking an archiv is not that much work to get an very fast player addidional to mencoder.exe.

sysKin
12th January 2005, 10:59
Originally posted by JoeBGermany
Wow, thatīs good news, you have my admiration :). What do I have to update for MeGUI and for sex264 to begin with testing? (sorry if this is a stupid question):( OK, revision 92 (with today's date) uploaded. Just for you.

This time, I compiled it with MinGW / GCC. In theory, this binary should be much faster, because all optimized assembler code is compiled - contrary to MSVC build which is unable to compile optimized motion compensation (not fully ported to nasm yet...).

Have fun,
Radek

JoeBG
12th January 2005, 11:22
Originally posted by sysKin
OK, revision 92 (with today's date) uploaded. Just for you.
Wow ;) :thanks:

So noone else is allowed to use? :rolleyes:

celtic_druid
12th January 2005, 12:00
Revision 93:
Changes the mechanics of max keyframe interval:
Now enforces min and max GOP sizes, and allows variable numbers of
non-IDR I-frames within a GOP.

Seems to work ok, however I did have to change codec.c, codec.h and x264vfw.h to match the new x264.h (no more i_idrframe and iframe).

sysKin
12th January 2005, 13:05
..and another update :)

This is still revision 92 (so doesn't contain new keyframe code) but with a simple change, discovered by virus (thanks! hehe, again): removed profiling code, which calculates how long different parts of the core take to complete.

Result - ~7% faster for me and *many many times* faster for virus.

New binary, along with a diff (vs revision 92 or 93, doesn't matter), available at the usual place.

len0x
12th January 2005, 13:32
Can someone tell me how does x246's one pass encoding comparing to XviD's one pass in terms of quantizers? They probably not the same, aren't they? (as range is 0-51 vs 1-31)

virus
12th January 2005, 13:38
:) <--- virus

Eh-eh, all the countless hours spent trying to understand why my PC was the only one where sex264 was 3x slower than any other machine around finally produced the result: I found the problem!

It lurks on encoder.c, and more specifically in 6 static 64-bit variables that measure the encoding times internally. Removing them, as well as the associated logging, produced an increase in performance which ranges from 2.5x to 3.6x depending on the options... but, as sysKin already said, looks like that you all are going to enjoy a bit of extra-speed, and that's great :)

Just don't ask me why that happened, and why so badly only on my machine. The code I trashed is slow, and maybe it even made the ASM b0rk or get misaligned, who knows... :rolleyes:

cheers :)
virus

And remember: every year thousands of programmers are killed by static variables. Help us save them! Don't use static variables in your code!

Sirber
12th January 2005, 13:56
to play with sex264, I just need SVN client and M$VC++ 6?

Leak
12th January 2005, 13:58
Originally posted by virus
And remember: every year thousands of programmers are killed by static variables. Help us save them! Don't use static variables in your code!

Nononono...

It's spelled "Every time you mis-use a static variable, god kills a kitten." ;)

sysKin
12th January 2005, 14:10
Originally posted by Sirber
to play with sex264, I just need SVN client and M$VC++ 6? Yup. For SVN, I use Tortoise SVN (http://tortoisesvn.tigris.org/). M$VC 6 will let you compile, but using MinGW, you can compile a faster binary. Your choice.

Radek

hellfred
12th January 2005, 14:31
Originally posted by Sirber
to play with sex264, I just need SVN client and M$VC++ 6?
Compiling x264 using MinGW/Msys is a piece of cake!
Help yourself to a svn.exe from out of one of the win32 binary archives from tigirs and place it to /mingw/bin to be able to use it.
Than a very simple skript sould do it:

#!/bin/sh

# Script for automatic downloading/updating of x264,
# compiling and installing it so that mplayer's config script will find it.
svn co svn://svn.videolan.org/x264/trunk x264
cd x264/build/cygwin
make
cp bin/libx264.a /mingw/lib
cd ../..
cp x264.h /mingw/include
The last three lines are just to move the libx264.a and x264.h to a place where mplaysers configure-script will detect them and build mencoder whith ability to encode using x264 (MeGUI).
I have never tryed to include building syskins vfw interface up to now.
Does it come with a makefile, or just with dsp?

Hellfred

gotaserena
12th January 2005, 14:57
Have virus' modifications been commited to svn yet?

Sirber
12th January 2005, 15:13
got the sources, installing MSVS6sp6. I will start playing with it tonight. Been a while for C++ :) I will use another compiler if I produce binaries :D

virus
12th January 2005, 15:16
Originally posted by gotaserena
Have virus' modifications been commited to svn yet?
well, let's leave akupenguin sleep a bit, he did a commit tonight... not to mention that the fix has been found less than 3 hours ago ;)

gotaserena
12th January 2005, 15:32
It's 4:30 PM here! He can't be sleeping! :P

Only joking, of course. I've just thought of doing a psnr shoot-out with my copy of "black hawk down", and having a faster code would help.

But I shouldn't complain: mencoder got 3x faster since I've moved from FC2 to gentoo...

Sirber
12th January 2005, 15:35
from gentoo, you simply "emerged" it?

gotaserena
12th January 2005, 15:43
Yup, but I installed cvs on top of it afterwards. Saved me the time of finding fonts, win32 codecs, etc. and configuring the gui.

Sirber
12th January 2005, 15:43
just looked at the todo... :eek: is there a good PDF about h264 so I can get some concepts? :D

[edit]

Might just play with the GUI :rolleyes:

SeeMoreDigital
12th January 2005, 18:22
I've been generating SExh264 encodes using MPEG Mediator... And just wanted to check if the GUI's and function settings I'm seeing, are the same as everybody else is seeing?

http://img132.exs.cx/img132/8449/sex264codec0yu.gif


Cheers

Sirber
12th January 2005, 19:03
set max bf to 1, and max reference 16 :D

IgorC
12th January 2005, 19:40
sex264 (12 jan.)

b-frames work good. i tried 2-3 bframes and 15 ref

while Xvid 1.1 and Nero AVC have a frames as IBBP IBP IBBPBBBP
sex264 has a strange consecuence of frames like IPBBP IPBBBP

first is I frame (itīs normal) then P-frames is followed by b-frames (strange??)

i used ffdshow (12 jan Celtic Druid has a bug with OSD turned on) for decode xvid, nero avc,

sex264.

thereīs no differnces in time of coding between 10 jan. and 12 jan. versions of sex264.
(celeron4 sse2)

Sirber
12th January 2005, 19:52
the celtic ffdshow I have has a bug with bframes, with AVC and sex264.

[edit]

which is squares :)

jdobbs
12th January 2005, 23:12
At the risk of sounding as clueless as I probably am... I tried this codec by using VDub to encode a small video segment. When I try to play back the resulting -- AVI my system reboots.

Am I too stupid to be helped?

EDIT: Perfect timing... I just tried the newer (FASTER) version and it works..

Ark
12th January 2005, 23:20
@SMD

Yup, these are the correct windows, for what i can see all is in the right place.

dvd_maniac
13th January 2005, 01:11
I was wondering if anybody here has moved from doing there encodes from Nero Digital's AVC to this codec? I am getting fustrated with ND and the Audio sync errors, Low Volume ACC and encoding speeds.

Can somebody give me an idea of the Pros & Cons of switching to this one?

I use ND to encode my dvd collection onto hard drive at about 300MB/hour of video. Somewhere around 750kbps.

Joe Fenton
13th January 2005, 02:37
Originally posted by gotaserena
But I shouldn't complain: mencoder got 3x faster since I've moved from FC2 to gentoo...

The only way that would happen is if you were using an old binary compiled for i386 in FC2. Gentoo generally builds from source, so you probably went from an unoptimized i386 build of an older version to a new build for i686 with extensions. If you had built mencoder on FC2 instead of fetching a binary from the respository, you'd have seen the same speedup. ;)

Sirber
13th January 2005, 03:26
Originally posted by gotaserena
Yup, but I installed cvs on top of it afterwards. Saved me the time of finding fonts, win32 codecs, etc. and configuring the gui. good. from source it's always better :D

akupenguin
13th January 2005, 03:53
Originally posted by Sirber
is there a good PDF about h264 so I can get some concepts?
http://vcodex.com/h264.html is a pretty good overview.

Sirber
13th January 2005, 04:30
cool, thanks :D

gotaserena
13th January 2005, 14:11
anybody played with the 3-pass mode? Is it worth the extra time?

Yong
13th January 2005, 14:15
x264vfw always crash for me if i resize the video to resolution
768x576(this res is 16mod and 4:3), PreciseBibubic=0.75, with virtualdub1.63/mod...
the source video is 800x600.

But doesn't crash mencoder if i using the same resize parameter.:)
Bug?

JoeBG
13th January 2005, 15:02
How can I properly deinstall the programm. I still have blocks with b-frames in 2 pass mode and I want to check if itīs getting better after deinstall and reinstall again.

begu
13th January 2005, 15:09
Hi,
I just wanted to ask that what colorspace does the sex264 codec (and .264 codecs in general) use?
I presume that it is YV12.
Does the spec allow more bit depth than the previous h263?

I ask this because the current colordepth is not quite good enough for high quality encoding.

Isn't the DVD colorspace generally only 8 bit? And the chroma information is only half of the luma (ie. half the resolution of the luma).

As far as I understand, the DVD could be encoded as better colour resoluion, but it is waste of bitrate, since human eye is sensitive to luminance accuracy. BUT: the colour banding is clearly detectable, because it is only 8 bit.

We have currently much better color depth in our computer due to dx9 and new graphics hardware. Generally the colordepth is calimed to be 32 bit (in grapchics cards) but it is 8 bit / colorchannel. So it is only 8 bits for red, 8 for blue and 8 for green (etc.). But now we can have more colors with better bit depth (new HW). So the limiting factor is the DVD itself, not the HW or display. The current LCD TV sets have better bit depth. For example I have panasonic projector, that has 10 bit colordepth and it is way better than my previous sanyo 8 bit. Again only the DVD or Xvid files, etc. are the limiting factor.

So is it possible to use better colordepth with these new codecs? I assume that these 264 type codecs find their way to these upcoming HD-DVD and bluray discs as well. I know that if the source is good and the encoding is done using high bitrate, the natural dithering smooths up the colorbanding issue. But if the bitrate is low, the codec can't maintain the 'microstructure' of the colorgrades, resulting colorbanding (if using 8 bit depth). Now the better colordepth could improve this kind of banding a huge amount. Even if the 'microstructure' (dithering) is lost in encoding, the better colorspace (10+ bit) reults a picture without color bands.

Well, I'm not a coder, and my knowledge is very limited, but I assume that increasing a colourdepth doesn't take so much bitrate compared to the bitrate needed for the 'microstructure' to be visible to eliminate the colourbands. But I might be wrong. But I guess my point is understandable.

This post is quite messy, but maybe it is useful in someway, or creates some discussion. And finally thanks so much for this sex(y)264 thing :)

708145
13th January 2005, 15:30
I agree with you that 10bit per channel will lead to higher quality but the banding is not a 8bit issue!
It's an issue of too high quantization per post processing.

bis besser,
T0B1A5

akupenguin
13th January 2005, 19:11
Originally posted by JoeBGermany
How can I properly deinstall the programm. I still have blocks with b-frames in 2 pass mode and I want to check if itīs getting better after deinstall and reinstall again. /me shakes his head at the windows attitude of reinstall and hope the problem goes away...
If you really want it fixed, how about sending me a compressed clip exhibiting the bug?

Originally posted by Sirber
the celtic ffdshow I have has a bug with bframes, with AVC and sex264. which is squares So it might be a decoding bug? Anyway, I wrote the H.264 B-frame support in libavcodec too, so maybe I can still fix it. Unless it's a compiler/dshow issue.

Originally posted by gotaserena
anybody played with the 3-pass mode? Is it worth the extra time? I'd say not yet worth the time. (The improvement is around .1 dB PSNR ~= 2% bitrate.) It will provide a bigger gain when we get to using multipass for more than just ratecontrol.

stephanV
13th January 2005, 19:13
Originally posted by JoeBGermany
How can I properly deinstall the programm. I still have blocks with b-frames in 2 pass mode and I want to check if itīs getting better after deinstall and reinstall again.

You are not using PP in ffdshow right?

virus
14th January 2005, 02:21
There have been some updates to the VfW frontend added to the repository, both by me and akupenguin. The GUI is now in sync with the changes in the I/IDR frame management, there are new defaults (slower but top-quality) and there's a new "fast first pass" checkbox which will automatically disable a few flags during 1st pass. Should be effective especially if you encode with slow settings.

Also, you can no longer switch off direct mode prediction for B-frames ("None") so make sure you hit Load Defaults when using newer releases or you'll probably see that field go blank due to the changes :)

Besides, is there someone that would like to have 3-pass encoding added, even if right now it's not very effective? Please let me know.

cheers :)
virus

JoeBG
14th January 2005, 08:11
Originally posted by virus
There have been some updates to the VfW frontend added to the repository, both by me and akupenguin. The GUI is now in sync with the changes in the I/IDR frame management, there are new defaults (slower but top-quality) and there's a new "fast first pass" checkbox which will automatically disable a few flags during 1st pass. Should be effective especially if you encode with slow settings.

Also, you can no longer switch off direct mode prediction for B-frames ("None") so make sure you hit Load Defaults when using newer releases or you'll probably see that field go blank due to the changes :)

Besides, is there someone that would like to have 3-pass encoding added, even if right now it's not very effective? Please let me know.

cheers :)
virus

sound great :)

Doom9
14th January 2005, 08:27
there's a new "fast first pass" checkbox which will automatically disable a few flags during 1st pass. Should be effective especially if you encode with slow settings. Does anybody know which settings those are?

akupenguin
14th January 2005, 08:33
fast 1st pass:
disables partitions P-sub8x8 and B-sub16x16
reduces number of reference frames by a factor of 2 (round up)
if subpel refinement was higher than 3, reduce it to 3. else reduce it by 1.

Sergejack
14th January 2005, 09:50
Could someone get in charge to make builds of the new releases ?
(I don't have much time to figure out every trouble I have with cygwin for now)

celtic_druid
14th January 2005, 12:12
I already put a compile up some hours ago. Even did an installer.

http://www.aziendeassociate.it/cd.asp?dir=/x264

Sharktooth
14th January 2005, 12:41
@celtic_druid: X264VFW.exe is always the latest rev. + the installer?
And what are the differences with sex.264?

P.S.: Mirror up @ http://ebola.gamersrevolt.it/celticdruid/x264/

celtic_druid
14th January 2005, 13:00
Yep, like the XviD builds, the installer is simply whatever the latest .7z is.

Guess sex264 was just pre svn and now that it (Syskin's VFW code) is in the svn it isn't really sex264 anymore.

Irwin
14th January 2005, 13:07
Why you use 7z?

celtic_druid
14th January 2005, 13:15
Why not use 7z? What else should I be using? As I have said before, suggest something that works better and I will switch.

Take x264vfw.revision97
rar = 131kb
zip = 146kb
7z = 112kb

Sirber
14th January 2005, 13:24
Originally posted by Irwin
Why you use 7z? Coz it's simply the best and it's free :D

Doom9
14th January 2005, 13:33
if you use winrar, update to the latest version and 7zip support is built-in (previous versions would make you think they can open 7zip, but then fail after the double click).

JoeBG
14th January 2005, 13:38
Originally posted by Irwin
Why you use 7z?

You donīt use 7zip as Standart? Why?

Irwin
14th January 2005, 14:34
I use zip - one click in Total Commander, it's fast on my machine (PIII 500mhz)
7z is very uncomfort for me - special program, many clicks, etc

celtic_druid
14th January 2005, 14:45
http://www.totalcmd.net/plugring/7zip_plugin.html

Irwin
14th January 2005, 14:48
Thanks!!!

sysKin
14th January 2005, 15:15
Originally posted by celtic_druid
http://www.totalcmd.net/plugring/7zip_plugin.html Ooooooooooo thank you so much celtic_druid :D I really really needed that.

Now, if only 7zip's own gui supported drag&drop (oh wait, maybe it does now?) my happines with 7z would be complete.

From now on, my website's x264 builds will be 7z as well. I considered it before (~10% better compression) but was worried about you not having 7zip. Now, it's too late ;p

Radek

Sirber
14th January 2005, 15:16
I don't think it does... D&D is not that complicated to implement :|

Shinobu
14th January 2005, 15:33
use tugzip.
free and support lot of uncomp&com setting (and 7z of course)

http://www.tugzip.com/

++

buzzqw
14th January 2005, 15:40
[OT on]
I build a little batch file to compress with 7z (without installing the ugly windows version)
---- start
@echo off
FOR %%i in (%1) DO SET extdir=%%~xi
FOR %%i in (%1) DO SET name=%%~ni
IF '%extdir%'=='' DO SET extdir=1
FOR %%i in (%1) DO SET where=%%~dpi
cls
IF '%extdir%'=='1' 7zip a -r -mx9 "%where%%name%.7z" %1/*
IF '%extdir%' neq '1' 7zip a -mx9 "%where%%name%.7z" %1
---- end

save it in your "send to" folders, and now you can compress with 7z by "send to 7z"

the decompression is even simplier

by by
BHH

IgorC
14th January 2005, 15:53
Originally posted by Shinobu
use tugzip.
free and support lot of uncomp&com setting (and 7z of course)

http://www.tugzip.com/

++

maybe this will be even better.
official http://www.7-zip.org/ new beta 2005-01-11 http://www.7-zip.org/dl/7z414b.exe

Irwin
14th January 2005, 16:05
This is x264 thread ! not 7z :) :p

Sergejack
14th January 2005, 16:35
Originally posted by celtic_druid
I already put a compile up some hours ago. Even did an installer.

http://celticdruid.no-ip.com/xvid/x264/

I suggest it is sticked in the first post.

MSlv
15th January 2005, 08:53
I encoded the first VOB (.99gb) from the Triple X DVD and I must say I'm impressed! I encoded with vdubmod using 1 Pass Quality at the default 26 value and all other settings unchanged and audio on Direct Stream Copy (ac-3 audio) and the final .avi was 5x smaller. The high motion scenes were unbelivable! Almost perfect! And no blocks!
What sucked though was the low motion scenes. The background lost a lot of detail and it was pretty blurry.

I can post some pics if you want.

I used VideoLAN to play the file.

The encoding speed was between 4-10 fps with vdubmod at Normal priority setting on my AMD 64 3000+ 512RAM.

All-in-all, it was a great experience. I can't wait for the 1st open-source codecs to become competitive to XviD and Nero's AVC. Or for the Nero codec to become usable outside the nero package, like Xvid or DivX, or x264 (;)) is.

akupenguin
15th January 2005, 09:58
Originally posted by MSlv
The high motion scenes were unbelivable! Almost perfect! And no blocks!
What sucked though was the low motion scenes. The background lost a lot of detail and it was pretty blurry.
Try a 2pass encode. It changes the bit distribution to be more in favor of low motion scenes.

Shinobu
15th January 2005, 10:42
this codec realy become competitive at average and hight bitrate.
do you plan to add a multi thread option ?
i'll test 2-pass in a few days, but 1-pass Q22 is realy great bitrate/quality.

++

Doom9
15th January 2005, 11:29
disables partitions P-sub8x8 and B-sub16x16Is there a way to disable those in mencoder? According to what bond told me about the features in this area, there are just 4x4mv and b8x8mv.

akupenguin
15th January 2005, 11:34
Originally posted by Shinobu
do you plan to add a multi thread option?
It's a possibility, since someone has kindly donated a dual opteron for testing. But I'm still working on algorithmic improvements. CPU optimization comes later (unless someone wants to send patches? ;))

akupenguin
15th January 2005, 11:46
Originally posted by Doom9
Is there a way to disable those in mencoder? According to what bond told me about the features in this area, there are just 4x4mv and b8x8mv.
The mencoder option "4x4mv" is identical to the vfw option "4x8, 8x4 and 4x4 P-frame search" which I have here abbreviated "P-sub8x8".
likewise, "b8x8mv" is the same as "B-sub16x16".

easyfab
15th January 2005, 11:58
I have a compile question.(i'm not a developper)

Default compile works fine with GCC under cygwin.
But I try to optimise the compile (cflags) for mu CPU (barton 2500+).
I have ~15% speed improvment of the available binaries for the moment.
When I add -march=athlon-xp the compile works (no errors) but VDM crash.
I searched and it comes from -msse option.
Must x264 have some sse codes to work with -march? or something else ?
For exemple xvid compile works fine when i use -msse cflags.

Thanks for your work.

akupenguin
15th January 2005, 12:23
I have a Barton 2500+, and I compile under Linux/GCC 3.3.1 with -march=athlon-4. no problems here. (march=athlon-xp works too, with no measurable difference in speed.)

Sergejack
15th January 2005, 12:33
I still have bugs in the videos I encode, some square of the animation just disapears sometime leaving black holes.
It isn't random, it happen the same way as I replay the video over and over again.

Paced
15th January 2005, 12:39
Originally posted by Sergejack
I still have bugs in the videos I encode, some square of the animation just disapears sometime leaving black holes.
It isn't random, it happen the same way as I replay the video over and over again.

Same here, I get black pixels also.

easyfab
15th January 2005, 12:40
Originally posted by akupenguin
I have a Barton 2500+, and I compile under Linux/GCC 3.3.1 with -march=athlon-4. no problems here. (march=athlon-xp works too, with no measurable difference in speed.)

I have GCC 3.4.1 .
I will test with GCC 3.3 version
Thanks

mezzanine
15th January 2005, 12:54
I've changed and old gui i made some months ago to support x264.
The gui is using avs2avi and other tools to encode dvd's. If anyone wants to test it send me a pv. Here is a screenshot

http://fyv12.homelinux.net/fusionyv12.gif

Output container is avi but it can easily changed to mkv:p

hellfred
15th January 2005, 13:18
Originally posted by akupenguin
It's a possibility, since someone has kindly donated a dual opteron for testing. But I'm still working on algorithmic improvements. CPU optimization comes later (unless someone wants to send patches? ;))
I praise that person for his courtesy, as that system will prove to be very useful for you while coding and therefor provide us all with a fast evolving x264 codec.
So Tank You a lot!

Hellfred

hellfred
15th January 2005, 13:27
Originally posted by mezzanine
I've changed and old gui i made some months ago to support x264.
The gui is using avs2avi and other tools to encode dvd's. If anyone wants to test it send me a pv. Here is a screenshot

http://mezzanine1.dyndns.org/fusionyv12.gif

Output container is avi but it can easily changed to mkv:p
That GUI looks promising. Did you already implement all features displayed in the GUI? That it would indeed be an impressing pice of software, and the best way to get a next to one click backup of a DVD that usese x264. But sorry, i have just the leisure to read the forum in my rare spare time, no time for extensive testing. :(
Therefore I hope you find beta tester and release a version for us to play with.
Hellfred

mezzanine
15th January 2005, 13:46
Originally posted by hellfred
That GUI looks promising. Did you already implement all features displayed in the GUI? That it would indeed be an impressing pice of software, and the best way to get a next to one click backup of a DVD that usese x264.

Yes all the features are implemented.

http://fyv12.homelinux.net/screenshots.htm

JoeBG
15th January 2005, 15:54
Originally posted by mezzanine
Yes all the features are implemented.

http://mezzanine1.dyndns.org/screenshots.htm

Looks great, but I miss some functions which would be nice to get integrated when possible :)

1) AAC Audio. Best would be a function for BeSweet like in RipRobot. There you can add your own commandline (I added commandlines for AAC)

2) SRT Subpictures

3) Muxing to MP4 and MKV
Mp4 is the natural Kontainer of AVC and MKV is open source

Muxing for MP4 should work with mp4box.

SirCanealot
15th January 2005, 19:54
Is anyone else having problems with the builds from http://syskin.is.dreaming.org/x264/?

I'm getting the error from VirtualDubMod:

"Cannot start video compression:

An unknown error occured (may be corrupt data).
(error code -100)"

Anyone got any ideas?
I've tried restarting and reinstalling, but the same thing happens.
The older builds work fine, but they don't seem to be mirrored on there any more. -_-

This does it nomatter WHAT settings I have on or off.

Anyone got any ideas?

Thanks...

jdobbs
15th January 2005, 20:34
Are you running Windows 2000? I noticed that it ran ok on my XP machine, but I got that error under my Win2000 machine... don't have a clue why, though.

unmei
15th January 2005, 20:47
SirCanealot, i get this error when i try to encode a video that is not mod 16.

Ark
15th January 2005, 21:48
I had the very same issue, in an attempt of encoding with some settings i wanted to test, like 3 b-frames and 5 max ref. frames (source was mod16).

I changed them to default value and everything was fine, maybe the solution is the simplest thing: hit the default button after a reinstall, maybe you haven't tried it yet :confused:

SirCanealot
16th January 2005, 02:46
Originally posted by unmei
SirCanealot, i get this error when i try to encode a video that is not mod 16.

Yup, that's it.
My source is 704x396 :/
Any idea on when this will be "fixed"?
Edit: acording to my calculator, this doesn't leave me with many 16:9 resolutions to use :/

Sergejack
16th January 2005, 07:04
Originally posted by SirCanealot
Yup, that's it.
My source is 704x396 :/
Any idea on when this will be "fixed"?
Edit: acording to my calculator, this doesn't leave me with many 16:9 resolutions to use :/

When you'll resize your source to 704*384 wich indeed IS mod 16.

Yong
16th January 2005, 07:19
Originally posted by SirCanealot
Is anyone else having problems with the builds from http://syskin.is.dreaming.org/x264/?

I'm getting the error from VirtualDubMod:

"Cannot start video compression:

An unknown error occured (may be corrupt data).
(error code -100)"

I received this message too, don't know why,
If i entered encoding bitrate too low(below 650) for some movies...
ratecontrol problem?
Same problem with mencoder,
can't start video encoding(crash at second pass...) if the maximum quantizer set too high(depend of movies).

Koti
16th January 2005, 07:44
I have had the same error on ocassion in Vdub with x264. Something I have noticed though - If I retry the 2nd (errored) pass in job control by double clicking on it so the 2nd pass shows waiting and start it again, the 2nd pass will start with no error.

dvd_maniac
16th January 2005, 09:58
@ mezzanine

I've changed and old gui i made some months ago to support x264.
The gui is using avs2avi and other tools to encode dvd's. If anyone wants to test it send me a pv. Here is a screenshot.

Hi Mezzanine,

Is this the same tool that needs .NET framework? Where can I download this from?

Bluedan
16th January 2005, 19:46
Originally posted by mezzanine
[...] send me a pv.

I'd like to send you a PM if you do accept that instead. :D

Bluedan
16th January 2005, 22:00
Originally posted by len0x
Can someone tell me how does x246's one pass encoding comparing to XviD's one pass in terms of quantizers? They probably not the same, aren't they? (as range is 0-51 vs 1-31)

I kindly want to recal THIS question, because I am simply looking for an easy explanation, too, that I cannot find neither in the FAQs nor in far advanced places like this one here (http://www.vcodex.com/h264.html) which is much too technical for me - I have to admit.

akupenguin
16th January 2005, 22:26
From the MPlayer manpage:
The mapping is approximately H264QP = 12 + 6*log2(MPEGQP). For example, MPEG at QP=2 is equivalent to H.264 at QP=18.

len0x
18th January 2005, 18:06
Is it equivalence in size or quality?
In my small test I can see that size of XviD @ quant2 ~ size of x264 @ quant17...(which is indeed close to quant18)

akupenguin
18th January 2005, 19:42
Originally posted by len0x
Is it equivalence in size or quality?
It's equivalence in quantizer (or lambda for rate-distortion). Which tends to be somewhere between size and quality.

hworldjj
19th January 2005, 05:43
Originally posted by len0x
Is it equivalence in size or quality?
In my small test I can see that size of XviD @ quant2 ~ size of x264 @ quant17...(which is indeed close to quant18)

You can refer to Iain E G Richardson' paper about Transform and quantization in H.264. There is a talbe to map qp_index to qp_step from 1 .. 51.

Blue_MiSfit
19th January 2005, 08:19
Any possibility of adding a status window like XviD's? :) I love being able to monitor quantizer distribution and getting all those nice stats like max/min/avg i/p/b frame sizes etc...

It really sets XviD apart from the competition.

~misfit

Yong
25th January 2005, 11:47
The x264vfw revision105 version is wierd,
i can't access the x264vfw cofiguration window, or the "about" window,
need to clear the registry settings so i can access it...:eek:
I tried with VD1.6.3, VDMOD and TMPGEnc, all have the same problem...

Sirber
25th January 2005, 15:11
x264 fails on my HDTV test encode at 1280x720. AVS2AVI gives me a nasty exitCode :confused:

len0x
25th January 2005, 15:22
IMHO this thread needs to be closed and all discussion should go into main developent thread here: http://forum.doom9.org/showthread.php?s=&threadid=80910
(as bug reports get separated between these two threads - i.e. problem with rev 105&106 is already being discussed there).

bond
25th January 2005, 20:21
hm syskin might add things to sex264 that will not go directly to svn, so it might be good to leave this open (also for the vfw codec related issues)

len0x
25th January 2005, 21:58
Originally posted by bond
also for the vfw codec related issues

those are being discussed in the main thread anyway :)
Its just we have to make clear that general x264 bugs have to go to the other place, otherwise its getting hectic.

kilivipin
26th January 2005, 15:11
264th post!
I just noticed it in the forum list, and I couldn't resist.
I am really sorry.

garumphul
28th January 2005, 21:39
I download a codec to have a play (everybody else is playing, why can't I?), and there's a fundamental problem with the "dec" part. My little test encodes up nicely with the new Gordian Knot but... nothing wants to play it. What do I need to download other than the (incorrectly titled) x264 codec from Mr Druid?

MSlv
28th January 2005, 21:48
latest ffdshow maybe?

len0x
28th January 2005, 23:43
Which brings up another question: are there any plans to make a VFW x264 decoder? :)

Tommy Carrot
28th January 2005, 23:55
The x264 library doesn't support decoding, only encoding, so the codec would have to use external library for decoding, and afaik only libavcodec is capable for that, and including it would bloat the codec hugely. Using external decoder (ffdshow) is simpler.

garumphul
29th January 2005, 01:36
Well there you go then.

There's a fundamental problem with calling something a "codec" when it does not, in fact, "dec".

The word "codec" is, surprisingly enough, a contraction of the words "encoder" and "decoder". One would expect, therefore, that downloading a "codec" would enable the encoding *and* decoding of video. Or maybe I'm getting a bit literal in my old age.

If somebody had said to me "hey, here's a really great video encoder... just the encoder... no decoder... but a fabulous encoder", then I might have saved myself the effort of downloading it. What's the point?

It interests me not a jot to be able to encode a film in a lovely cutting-edge format if I can't *watch* the bloody thing to find out how good it is!

Call it what it is - it's an **encoder**, not a codec.

If I've done something blatantly wrong in installing a "codec" and expecting it to decode the file it encoded, then feel free to enlighten me with every ounce of sarcasm available to you.

virus
29th January 2005, 02:21
Originally posted by garumphul
Call it what it is - it's an **encoder**, not a codec.

If I've done something blatantly wrong in installing a "codec" and expecting it to decode the file it encoded, then feel free to enlighten me with every ounce of sarcasm available to you.
No need to. You seem already full of sarcasm, especially about work that other people are providing for free to you. Thanks for the lecture. It was not needed, but that's not important.

I'd like to encourage you to do the following steps:

1) open the Select Video Compression window in VDub
2) look into the list at the left
3) watch the name of the x264 codec listed there

Then I'd also like to encourage you to check the source code (http://developers.videolan.org/cgi-bin/viewcvs.cgi/trunk/?root=x264) for the file /x264/x264.c, line 511-514, which I report here:

static int Decode( x264_param_t *param, FILE *fh26l, FILE *fout )
{
fprintf( stderr, "decompressor not working (help is welcome)\n" );
return -1;


Finally, I'd like to point you at the project main page (http://videolan.org/x264.html), especially at the red warning printed just below the title:
BIG FAT WARNING: x264 is still in early development stage
Now, if you want to continue blaming other people for your lack of understanding of the forum rule #1, you're free to go on with your useless whining. But I don't think a moderator would tolerate that for so long. ;)

regards,
virus

MSlv
29th January 2005, 10:25
Is there any new build yet to come?

Arkoki
29th January 2005, 13:09
Hello,

The x264 library doesn't support decoding, only encoding, so the codec would have to use external library for decoding, and afaik only libavcodec is capable for that, and including it would bloat the codec hugely. Using external decoder (ffdshow) is simpler.

If you change the fourCC option in Sex264 to H264 (no, h264), you can use Nero Decoder too. Then, using external decoder (ffdshow or nero decoder) is simpler.

Thanks.