x264 development

[Sharktooth]

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

[virus]

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

[celtic_druid]

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

[Blue_MiSfit]

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

Open Source development is really far too cool.

:D :thanks:

[Yong]

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

[celtic_druid]

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

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

[LigH]

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

[celtic_druid]

EN_KILLFOCUS I believe. I'll try that.

Ok, that works better.

[Manao]

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

[celtic_druid]

Seems to work ok here.

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

[Manao]

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

[LigH]

Okay, there was one issue when I did so:

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

Event driven user interfaces are fun. :sly:

[Kurtnoise]

Great stuff CD...;)

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

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

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


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

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

[SeeMoreDigital]

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

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

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

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

Please let me know what other info you guys require?


Cheers

[LigH]

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

[Doom9]

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

[SeeMoreDigital]

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

[bond]

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


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


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

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

[Manao]

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

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

[Sharktooth]

Great stuff CD...;)

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

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

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


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

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

[SeeMoreDigital]

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

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

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

Many, many thanks

[Sharktooth]

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

[Kurtnoise]

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

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


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

[cheburashka]

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

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

:thanks:

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

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

[Maximus_G]

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

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

[SeeMoreDigital]

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

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

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


Cheers

[Sharktooth]

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

[SeeMoreDigital]

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

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


Cheers

[Sharktooth]

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

[SeeMoreDigital]

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

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


Cheers

[berrinam]

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

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

[SeeMoreDigital]

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


Cheers

[Sharktooth]

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

[Yong]

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

[Sharktooth]

the interface is being redesigned.

[Inventive Software]

I have something that might interest the devs...

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

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

[SeeMoreDigital]

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

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


Cheers

[Sharktooth]

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

[SeeMoreDigital]

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


Cheers

[Inventive Software]

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

[SeeMoreDigital]

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

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


Cheers

[Inventive Software]

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

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

[Mutant_Fruit]

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

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

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

[jellysandwich]

Newbie question here...

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

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

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

js

[Revgen]

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

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

[snacky]

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

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

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

[ChronoCross]

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

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

[snacky]

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

[Revgen]

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

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

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

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

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

ChronoCross answered this question better than I could.

[LigH]

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

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