DeathTheSheep United: x264 Guide and VfW Builds

[DeathTheSheep]

DeathTheSheep United (http://DeathTheSheep.Uni.cc): The ultimate x264 VFW spot has been born.

Download new VfW builds here (http://komisar.gin.by/) or here (Bugmaster) (http://sourceforge.net/projects/x264vfw/)! Special thanks to Komisar!

New x264 VfW builds, comprehensive x264 settings guide [server currently down], small community forum.

[Caroliano]

Don't ever use me-range higher than 32... it will only low the PNSR and increase the encoding time. ( http://forum.doom9.org/showthread.php?t=96636 )

And the B-frame reduction for anime is intersting... I think it can work, but don't tested yet. In that case I can use B-frames as references?

[berrinam]

the "Video Quality (PSNR)":"filesize" ratio will increase.I'm a bit surprised by this. Are you saying that you compared two files with different filesizes and different PSNRs? AFAIK, PSNR doesn't scale linearly with filesize.

Anyway, except for that, thank you for all your work and your guide. :thanks:

[DeathTheSheep]

Don't ever use me-range higher than 32... it will only low the PNSR and increase the encoding time.
Ah, thanks for that. You're right about it increasing the encoding time. As for the filesize, though, it will actually decrease with -esa (where it was mentioned), but PSNR values may be sacrificed in some cases. Due to the apparent variability of these results, I'll have this upper bound removed.

I'm a bit surprised by this. Are you saying that you compared two files with different filesizes and different PSNRs? AFAIK, PSNR doesn't scale linearly with filesize.
Actually, I just meant that you will achieve better PSNR for your file size (presumably, the same filesize proffers heightened PSNR with the higher-quality approach-- and vise versa).
I'll clarify that in my guide. Thanks! :)

[Sirber]

Good! I will try the SMEQ at 6 and bframe reduction 50%! :D

[neo_anderson]

i use 1 b-frame, 3 ref. frames and +512 to-512 range in nero digital avc max. def. and i get great quality!i see the average bitrate in info. in recode 2 and i use 20% of that bitrate in 2-pass encoding!

[DeathTheSheep]

Good news. What type of source material do you typically use? Animation, "real" movies, etc?

You mentioned how you got 20% of "that bitrate" when encoding in Nero. What exactly do you mean by this? ex: Have you achieved 20% better compression with Nero Recode than with x264 using the above method? Or did you simply use 20% of the average bitrate Nero reported to you?

My regards,
DTS

[DeathTheSheep]

The Guide is really long now...In fact, it can't get much longer at all due to the post size limit... *gulps in anxiety*

ADDED:

<> Deblocking Guide

<> Bitrate Variability Section

<> Streaming sections

NEED:

<> Cosmetics Work

<> More space for the rest of the guide (there's a 16000-char. limit here)!

[CiNcH]

//<>\\ When they become available for use, take advantage of custom H.264 quantization matrices. These nifty little numerical spreadsheets control how and where different frames are quantized. Typically, these matrices are not in widespread circulation and are still being tweaked to provide the best quality possible. The x264 codec currently (rev. 285) does not support this feature.

It actually does. Guess that it is just not part of the VfW interface.

CLI:
--cqm <string> Preset quant matrices ["flat"]
- jvt, flat
--cqmfile <string> Read quant matrices from a JM-compatible file
Overrides any other --cqm* options.
--cqm4 <list> Set all 4x4 quant matrices
Takes a comma-separated list of 16 integers.
--cqm8 <list> Set all 8x8 quant matrices
Takes a comma-separated list of 64 integers.
--cqm4i, --cqm4p, --cqm8i, --cqm8p
Set both luma and chroma quant matrices
--cqm4iy, --cqm4ic, --cqm4py, --cqm4pc
Set individual quant matrices

Problem is that ffdshow still doesn't support CQM. Have to use Nero Digital AVC Decoder instead.


Interesting information on motion search engine/motion search algorithms in x264: Motion Search Method (http://forum.doom9.org/showthread.php?t=98092)

[Sirber]

We could make that sticky :D

[neo_anderson]

Good news. What type of source material do you typically use? Animation, "real" movies, etc?

You mentioned how you got 20% of "that bitrate" when encoding in Nero. What exactly do you mean by this? ex: Have you achieved 20% better compression with Nero Recode than with x264 using the above method? Or did you simply use 20% of the average bitrate Nero reported to you?

My regards,
DTS
My sources are widescreen DVD movies, and yes, i use 20% of the bitrate recode reports, with range as +-512.5,3 ref. frames, 1 b-frames, psycho off, color optimization on, and using -1 deblocking!

check out these screenshots:
DVD Screen : http://img223.imageshack.us/img223/4628/riddickdvd1vg.jpg
Nero Max-Def AVC Screen:http://img223.imageshack.us/img223/56/riddickmp46wg.jpg

[DeathTheSheep]

Cool. :cool:

The thing that frazzles me is that the people who use Nero often confuse the "range:32" of x264 and the "range:512" of Recode2. I think some "range" clarification is in order for us poor folks (motion vector range : motion estimation range).

neo_anderson:
Slightly OT... But btw, in the screenshots, the guy looks more pleasant and clean-shaven in the AVC encode...He looks more menacing/dirty in the DVD frame with all his stubble. Gotta love that MPEG-4 smoothing! ;)

It actually does [already support CQM]. Guess that it is just not part of the VfW interface.
...
Problem is that ffdshow still doesn't support CQM. Have to use Nero Digital AVC Decoder instead.

Indeed. This is precisely the reason I left it out of my guide. I changed the wording a bit, though. :rolleyes:

Interesting information on motion search engine/motion search algorithms in x264: Motion Search Method (http://forum.doom9.org/showthread.php?t=98092)
Yes, my guide is fully compliant with that thread. :cool: I just wrote up the best methods in my guide to illimate the need for users to poke about.

Is there any way to increase the post size limit? (From 16000 characters to, say... 25000?)

[neo_anderson]

umm..., i used chronicles of riddick r1 director's cut dvd, so it's the best quality available for this movie!

[DeathTheSheep]

I know-- The source DVD looks very good in your screenshot :). I meant that the AVC encode smooths out his whiskers and makes him look less feirce.

But maybe only I think that.... :p

[neo_anderson]

hey, thank god u're online, please can u tell me some other way for finding out bitrate to be used,along with -1 deblocking, and 5 ref. frames? also, should i use more than 1 b-frames?

[DeathTheSheep]

To find out what bitrate to use, start out by asking yourself what the maximum should be. For instance, if I wanted to encode The Matrix 3, I'd probably set aside 2 CDs to acheive the maximum quality. Then use a bitrate calculator (like the one in xvid).

But, if you wanted a more exact bitrate based on quality, try to take a sample of the source (make it a fairly large) and encode it with your desired QP. With the resulting file, perform this calculation:

{ (# of MB in file x 1024) / (# of seconds in file) } x 8 = (Average Bitrate)

This will give you an average bitrate for the quality you desired.

An example: I take out 10 minutes of a cool scene in the middle and encode it with a quantizer of 22, 26, and 28. I find that the file with the quantizer of 26 fits my liking, so I apply my formula to it. With the resulting bitrate, I encode the entire movie in 2-Pass mode with the "High Speed, High Quality" mode above.

Of course, if you knew your target size (ex: you wanted to fit your content fit to two CDs), use the following formula:

( {(target MB x 1024) / (# of seconds in video)} x 8 ) - (audio bitrate) = (bitrate needed)

Cheers.

[neo_anderson]

thks DTS Dude, pls tell me what are ur thoughts or recommendations on Psycho-Visual Enhancements in Nero Digital AVC!

[_E_]

MeGUI comes with a bitrate calculator ;) You don't need to do any calcuations. It detects the type & size of audio used and it generates the average bitrate/target filesize based on the inputted framerate, total frames number, b frames mode on/off and desired container. So far it's giving accurate results.

[DeathTheSheep]

Psychovisual Enhancements? Okay, I added the section. The guide is shaping up, right? ;)

Well, I'll really have to do something about that accursed 16000 character limit in this forum... I had to tone down the guide already, and it's already full to the max! LOL

[CiNcH]

Here's my interpretation of Psychovisual Modeling / Psychovisual Heuristics:

Psychovisual modeling algorithms exploit the peculiarities of the Human Visual System (HVS). This knowledge allows the encoder to more efficiently allocate video data, helping it to increase perceptual quality. This area is full of possibilities which are continuously being explored and developed.

On FrameLevel data is reduced for a video sequence at full frame rate in a way that the HVS does not notice.

On MacroblockLevel distortions are masked in dark/bright (luminance masking) or highly textured areas of the picture (in other words bit spend is reduced) where the HVS does not notice it, details in flat areas, where the human eye is most sensitive, are enhanced.

Although psychovisual heuristics appear to improve quality the PSNR score drops, so the PSNR metric does not have a good correlation with subjective perception of video quality.


Psy-Vis in latest Ateme AVC Encoder Beta (I am not a tester so I am not aware of its effects)

There are 4 psychovisual levels, which are independant from the other settings.

* psy 0 -> no psychovisual heuristics
* psy 1 -> psychovisual heuristics on a frame level
* psy 2 -> psychovisual heuristics on a macroblock level
* psy 3 -> enhanced psychovisual heuristics on a macroblock level. Some people prefer it over psy 2, others don't.

[Sharktooth]

added Death The Sheep guide (link to this thread) to x264 builds sticky.

[DeathTheSheep]

I saw the doom9 guide section and couldn't help but wonder: how could I go about submitting this guide to the main Doom9 site? If I did that, I would have more space, a cleaner layout, and room to put in screenshots! How's that for a high-quality space for a high-quality guide? :p :D

[TheBashar]

---Bitrate Variability---
The bitrate variability feature controls how much your datarate can fluxuate at any given time. That is, if you plan on encoding at 500kbps and set this value to 40, the maximum amount of bitrate given to more complex scenes is 700kbps. In a nutshell, the lower you set this value, the better still/non-complex scenes look, but high-motion/complex scenes will look more shabby and garbled. The higher you set this value, the more equal the overall quality will become: still scenes would look worse than with a low value, and high-motion/complex scenes would look a lot better.

DTS,

I may have misunderstood two of the x264 parameters (ratetol and qcomp) but I believe qcomp is responsible for deciding how much more high motion scenes are compressed (aka lower bitrate) than static scenes. I think ratetol is an additional constraint on how much you allow qcomp to do its job.

I believe that ratetol is the appropriate parameter to set/modify if you have streaming or hardware playback concerns. However, the low/high motion compensation that you are describing in the above quoted text would, I believe, be more appropriately handled by adjustments to qcomp in conjunction with a sufficiently permissive ratetol.

I am a little confused why ratetol defaults so low. I would think you would want to default it as high as possible, and then adjust qcomp for motion compensation issues.

Anyway, just my perhaps misguided thoughts.

[DeathTheSheep]

Qcomp, in a quite literal sense, is a form of Bitrate Variability--actually, it was simply renamed in the VFW and multiplied by 100 for integer simplicity.

The "ratetol" parameter, as you mentioned, controls the amount of bitrate explicitly awarded to the video, in turn effecting the quantizers used on it. It does so as part of a bitrate regulation -- to ensure that the content reaches a certain bitrate without fluxuation.
raising ratetol allows greater fluctuations in bitrate (thus it would be more similar to 2-pass) at the expense of precision in aiming the target bitrate
It therefore defaults to a 1, a low value, in order to more accurately hit a given bitrate in ABR (1-pass variable bitrate) mode.
For this "fluxuation insurance," high-motion scenes would obviously require a higher quantizer than do still scenes in order to maintain a certain steady bitrate. However, qcomp directly controls these quantizers (A quantizer curve compression, or quantizer regulation), which in turn impacts the bitrate, serving either to give it absolute stability (0) or allow infinite fluxuation (1) based on what quantizers are used on each frame in the video.
Control diagram:

<> qcomp -> quantizers -> bitrate variability
<> ratetol -> bitrate variability -> quantizers

I think ratetol is an additional constraint on how much you allow qcomp to do its job.
Yes, I would assume so.
It is therefore safe to assume that with Qcomp in play, ratetol serves as a sort of "peak cutoff," allowing the video to conform to the quantizer specifications in qcomp so long as they don't exceed the bounds specified in ratetol. Yes, ratetol would be an excellent parameter to set when encoding streaming content (if using the cli, of course), because of these solid bounds.

Their purposes seem to check and balance one another and provide more explicit control.

[jellysandwich]

all but the 8x8 transform (for MP-compliant streams).

When you say this, are you referring to P8x8, B8x8, I8x8 High Profile, or a combination?

js

[DeathTheSheep]

Merely the high profile transform. I apologize for any inconvenience.

Yours,
DTS

[Revgen]

I have a couple questions that I haven't seen here.

1) What is "B-Frame Bias"? Does this setting determine what direction (Future frames/Past Frames) that a B-Frame takes into account? What kind of sources would this be useful for?

2) Is the "Chroma ME" setting useful for encoding B&W sources? I'm assuming it isn't, but I don't know for sure.

Thanks.

[Caroliano]

@revgen:

1) This was called "BVOP Sensitivity" in Xvid. B-frame Bias let you tweak the amount of Bframes the encoder will put in the clip. 0 is the defaut b-frame decision algorithm. A positive value increases the amount of B-frames; a negative value decreases it. It's better you don't touch in that option. Normaly the defauts are always better, unless in a speed by quality trade of.

Warning: It isn't the same as max consecutive B-frames.

2) I can't guarantee too...

[bond]

If you wish your video to maintain a specific, constant quality the whole way through, use only the Constant Quality feature of 1-pass mode.
<> Do not use a quantizer of under 15 unless you are working for archive/reproduction quality.
<> Also, do not use anything over 40: the quality is simply unbearable unless you are encoding from an extremely sharp source of high-contrast edges and plan on streaming it over the internet.
<> A good bet for most people interested in high quality video would be the range of 22-30 (or, more specifically, 24-28). Of course, this varies depending on individual taste and how much free space you have.
<> On animated content with few detailed textures, consider using a higher quantizer.
<> On "real-life" content, especially that with many dark scenes and important subtle textures, consider using a much lower quantizer value.where do these values come from? any screenshots?

why do you think that its a bad idea to trust x264 on deciding what quant to use? any samples which show that x264 does a bad decision on that?

To stream x264 video, you need to have a player capable of handling streaming; nearly all players I can think of at the moment support this. I suggest using Media Player Classic, but Windows Media Player 9/10 works just as well for many people as long as the ffdshow decoder is installed. Make sure to configure the player to automatically start a stream with the desired file extension (the most commonly made x264 files use the ".avi" extension). you are sure that dshow players will be able to play streamed h.264 .avi files? somehow i cant believe this. do you have a sample stream link i can try?

<> Use 0 references. Reference frames cause a lot of hop-skipping around the stream. If a certain frame's reference is far off into the file, the entire file becomes unplayable until the video is downloaded up to that reference.i doubt you mean 0 references, as this would mean using an i-frame only stream. what you mean here is using 1 reference frame

<> Use a maximum of 1 B-frame. It is NOT recommended to use consecutive B-frames on very-low bitrate content. I have proven this with the thread entitled "The Coolness of B-Frames." The WORST place to use a B-frame in H.264 (or many other formats for that matter) is on low-bitrate, low framerate, streaming, animated content.well i wouldnt call this to be proven at all, after all the purpose of b-frames is helping in low bitrates too...

<> 4-5 references are the typically accepted maximum. However, if you have a little bit of extra time on your hands (or a beefy computer), consider using up to 8 references (which decode just about as fast as 5, according to my Pocket PC AVC benchmarks). my psnr comparisons showed that references over 5 dont really bring any quality increase but will slow down decoding

<> B-frame reduction (if you choose to use B-frames) should be adjusted according to the desired datarate. For most DVD backups, the default B-frame reduction of 30% seems to be sufficient. However, with certain animated medium bitrate content, I suggest use of up to 50% B-frame reduction.why dont you think that the default values of x264 are ok? any sample files which show that default setting in x264 does a bad job or that your proposal does a better job?

<> Don't ever use CAVLC... My benchmarks prove that decoding CABLC streams is only slightly faster than CABACnot true, cabac will decrease decoding speed clearly, as i described here (http://forum.doom9.org/showthread.php?t=99131)

<> Personally, I find that the keyframe threshold of 45% and keyframe QP boost: 20 to be the optimal in achieving quality at medium bitrates. However, if you wish to produce Ultra-Low-Bitrate video (DVD backups less than one CD), consider reducing this to 0, for your video's quality (PSNR) per BM will increase.again my request for samples that show that x264s defaults perform worse than with your proposal

However, if you have a particularly complex source (or if you really want to scrimp for the best possible quality), try Uneven Multi-Hexagon with a ME range of 16-32hm didnt pengvado write somewhere that it doesnt make sense to use a value higher than 16 and that it even could decrease quality!?

Generally lower framerates (12-15 as opposed to 23.976-29.97) need a higher estimation range.why that?

<> In maximum-quality content, I find that the keyframe threshold of 35% and keyframe QP boost of either: 30 or 0 to be the optimal in achieving quality at medium-high bitrates in my "maximum possible quality" mode. again my request for samples that show that x264s defaults perform worse than with your proposal

<>\ When they become more widely available for use, take advantage of custom H.264 quantization matrices. The x264 codec currently (rev. 285) does not support this feature.it does

*B-frames can be activated in "pyramid" mode, which allows B-frames to serve as references. If you wish to use a lot of references (and thereby increase quality slightly), consider selecting the "Use as references" checkbox.b-pyramid doesnt really have much to do with the number of reference frames

However, this option may cause some crashes with both the encoder and the decoder (if either is old enough). For this reason, I recommend NOT using B-frame references.doesnt make sense, instead you should recommend to always use the latest version of the codec

<> For deblocking strength, try not go out of bounds of the -3 to 3 range. Generally, any more than 3 will turn your result into mush while decreasing PSNR and actually increasing the output file slightly. Any less than -3 may cause the result to look a bit too blocky and any lack of texture will merely become more apparent as all smoothing is taken out.positive values of loop will tend to remove details -> smaller filesize

Present in certain AVC encoders, this is a method of lumi (+chroma) masking in which very light or dark areas of a scene are encoded in terrible quality, which gives more bitrate to the rest of the video.i wouldnt talk about "terrible quality" here, as the point here is to encode with lower bitrate where the eye cant see the difference anyways, so for the eye the quality will stay the same

<> The main determining factor in whether or not you would like to enable Psychovisual Enhancements is the darkness of your source. In films with very dark scenes (dungeons, tunnels, night, shadow), turn this OFF for good measure. If the source isn't very dark, I'd recommend you try light enhancement. Strong psychovisual enhancement can lead to problems (the codec might think important semi-dark things are "dark enough" to heavily reduce the quality, which may be obvious to the viewer). Check out CiNcH's post below for more info... you are talking here mainly about nerodigital as x264 doesnt do psy, any link to information about how psychovisual enhancments work in nerodigital so i am able to find out whether nerodigital really does the lumimasking you describe and not something else?

[IgorC]

Deatsheep isn't a dev of x264 that's why his arguments far to be best. I apreciate his contribution :rolleyes: but induction and deduction aren't the same things. Particular case doesn't define situation in general.

[akupenguin]

The bitrate variability feature controls how much your datarate can fluxuate at any given time. That is, if you plan on encoding at 500kbps and set this value to 40, the maximum amount of bitrate given to more complex scenes is 700kbps.
No. See some explanations I gave to Chen.

Generally lower framerates (12-15 as opposed to 23.976-29.97) need a higher estimation range.
why that?
Because at lower framerates, objects have moved farther between consecutive frames. => need to search farther on average to find an object. OTOH, I can't think of any situation where I would reduce framerate below 24 without also reducing resolution, and low resolutions can use smaller search range. So it may cancel out.

If a certain frame's reference is far off into the file, the entire file becomes unplayable until the video is downloaded up to that reference.
No, multiple references have no effect on seekability. (BTW, they also have no effect on AVI compatibility.) All reference frames would have to decoded anyway, because they're between the current frame and the previous keyframe. (B-pyramid does add a few extra dependencies, but again it's independent of the number of reference frames.)

positive values of loop will tend to remove details -> smaller filesize
Not necessarily. If the codec encodes some details, and then loopfilter wipes them away, and then it has to code the details again in the next frame...
I'm not saying that the net effect is to increase size at a given QP (I don't know offhand; all of my loopfilter comparisons were 2pass, because it's the only fair way), just that you can't deduce the global effect from the definition of loopfilter.

[foxyshadis]

<> 4-5 references are the typically accepted maximum. However, if you have a little bit of extra time on your hands (or a beefy computer), consider using up to 8 references (which decode just about as fast as 5, according to my Pocket PC AVC benchmarks).
my psnr comparisons showed that references over 5 dont really bring any quality increase but will slow down decoding
It's quite concievable that different processor architectures on PPC vs PC could lead to different results. I'm not defending them, just saying.

<>\ When they become more widely available for use, take advantage of custom H.264 quantization matrices. The x264 codec currently (rev. 285) does not support this feature.
it does
True, but decoders don't. (I think ffdshow's support for it was buggy when I tried last month, and no others worked at all.)

<> Use a maximum of 1 B-frame. It is NOT recommended to use consecutive B-frames on very-low bitrate content. I have proven this with the thread entitled "The Coolness of B-Frames." The WORST place to use a B-frame in H.264 (or many other formats for that matter) is on low-bitrate, low framerate, streaming, animated content.
well i wouldnt call this to be proven at all, after all the purpose of b-frames is helping in low bitrates too...
B-frames help to a certain point, however below a certain framerate & bitrate they lower subjective quality. That section's about ultra-low bitrate streaming encodes, where assumptions from low-to-mid quality encodes don't all hold. (By that point the whole video looks like trash to me, but I'm not the target audience.) A few threads have come up about this.

[DeathTheSheep]

Bond:
As a renowned doom9 moderator with 5.7 thousand posts, your scrutiny is indeed commendable, justifying this vast post number while casting my rather insignificant 250 forum contributions into the realms of near-obscurity.

To Whom It May Concern:
Such a large number of doubts, questions, and concerns will not go unheeded by me, as I will attempt to explain myself for each of my points. I do this for the sake of both my guide and the doom9 community, which I hope will partake the reaping of its bounty.

For the sake of simplicity, I will display the questioned excerpt from my guide and explain myself briefly for each of the points bond (and perhaps other members) brought up about them in preceding posts.

---- M Y ----
D E F E N C E
-------------
I make the following statements to justify the content of my guide.

If you wish your video to maintain a specific, constant quality the whole way through, use only the Constant Quality feature of 1-pass mode.
<> Do not use a quantizer of under 15 unless you are working for archive/reproduction quality.
<> Also, do not use anything over 40: the quality is simply unbearable unless you are encoding from an extremely sharp source of high-contrast edges and plan on streaming it over the internet.
<> A good bet for most people interested in high quality video would be the range of 22-30 (or, more specifically, 24-28). Of course, this varies depending on individual taste and how much free space you have.
<> On animated content with few detailed textures, consider using a higher quantizer.
<> On "real-life" content, especially that with many dark scenes and important subtle textures, consider using a much lower quantizer value.
bond: why do you think that its a bad idea to trust x264 on deciding what quant to use? any samples which show that x264 does a bad decision on that?
DTS: However you may have conceived the preposterous notion that I intended to redefine x264’s quantizer utilization mechanism, I assure you, this is not the case at all. As is relatively obvious given the context of this quote, I was discussing the method to achieve high quality video using the “Constant Quality” 1-Pass mode of x264, where the user’s input literally is the codec’s control over the quantization. I also gave examples of when to use this feature. Please, read the guide carefully before jumping to conclusions based on fallacious/preconceived notions.


<> Use 0 references. Reference frames cause a lot of hop-skipping around the stream. If a certain frame's reference is far off into the file, the entire file becomes unplayable until the video is downloaded up to that reference. bond: i doubt you mean 0 references, as this would mean using an i-frame only stream. what you mean here is using 1 reference frame
DTS: Perhaps. However, you seem to be incorrect about your I-stream assumption; it appears as if you haven’t tried to input a value of ‘0’ for reference frames in x264, which outputs a perfectly normal IPB stream. It could very well be that 0 and 1 perform the same task in x264 when input into the VFW GUI, for which this guide was intended. In my guide, I was explicitly aiming for the least possible reference frames, so I used the value of 0 for clarity. Recall that I am not a developer of x264, nor was I discussing its internal workings—I was merely proffering input values which yield the highest output quality, based on various empirical and observational tests. Have you ever tried to input 0? Perhaps it wouldn’t hurt. After all,
IgorC: induction and deduction aren't the same things.
Here is a sample stream with “0” input for the number of reference frames: http://www.thefilehut.com/userfiles/xsquaredx/0refs.avi

<> Use a maximum of 1 B-frame. It is NOT recommended to use consecutive B-frames on very-low bitrate content. I have proven this with the thread entitled "The Coolness of B-Frames." The WORST place to use a B-frame in H.264 (or many other formats for that matter) is on low-bitrate, low framerate, streaming, animated content.
bond: well i wouldnt call this to be proven at all, after all the purpose of b-frames is helping in low bitrates too...
DTS: Although I might come off as a bit abrupt on my part, this statement may well prove nothing more than a lack of experience in the ultra low bitrate area on your part. The section of the guide from which the above quote was pulled was from an ultra-low bitrate section.
foxyshadis: B-frames help to a certain point, however below a certain framerate & bitrate they lower subjective quality. That section's about ultra-low bitrate streaming encodes, where assumptions from low-to-mid quality encodes don't all hold… A few threads have come up about this.
IgorC: induction and deduction aren't the same things. Particular case doesn't define situation in general.
DTS: Now, without looking into the matter further, it is not entirely safe to make such assumptions. Consider the following examples of standard, low bitrate, low-framerate content, one with and the other without B-frames. Which looks better to you? Remember, even if it seems that both results look shabby to you, you may not be of the target audience.
With: http://www.thefilehut.com/userfiles/xsquaredx/bframes1.avi
Without: http://www.thefilehut.com/userfiles/xsquaredx/bframes0.avi
These files were encoded with exactly the same settings (standard settings except for 2 references and 6-RDO refinement). The file with 2 consecutive B-frames is actually larger, and there is much more block noise during movement, and movement isn’t accurate (see how the character’s face looks to be falling off as he walks towards the camera). To further illustrate my point, I will refer you to a certain quote which attempts to explain such a phenomenon:
skal: Let's look at 3 frames at ~8fps (the upper ones in the following -ugly- sketch), and watch the coding in progress:

http://skal.planet-d.net/munch_me.jpg

Arghh! When the encoder is coding frame P1, look at what he has as reference! It's P0, coded at QP=45. A mere block feast!
Question: How do you expect to ME to find a good match between frame P0 and frame P1 ??? The first one is a block soup, but P1 still has lot of details. One could pick any block from the first frame and match it with the third, with a SAD of ~51340986542 (roughly) ;)
The motion vector field will be erratic, and the middle b-frame will find it difficult using the mighty BDirect mode (not to mention that it'll be hard to match the frame P0 / P1, too).
RadicalEd: possible for B frames to increase size indirectly, especially if they're not being overquantized with respect to the Ps. This is because a B frame essentially creates a void in prediction and the next P frame has to jump behind it and use the P (or I) frame before the B to predict from. Therefore P frames get bigger as a result of B frames. This is probably more prominent with anime as well, so maybe that's what sheep is experiencing.

<> 4-5 references are the typically accepted maximum. However, if you have a little bit of extra time on your hands (or a beefy computer), consider using up to 8 references (which decode just about as fast as 5, according to my Pocket PC AVC benchmarks).
bond: my psnr comparisons showed that references over 5 dont really bring any quality increase but will slow down decoding
DTS: At a constant quality quant=30, which I believe is the “fairest” way to test the quality of different settings on a filesize basis (it employs a uniform quality quantization throughout), see the following for yourself. Each having nearly identical quality to the other, which file is smallest?
5 refs http://www.thefilehut.com/userfiles/xsquaredx/5refs.avi
10 refs http://www.thefilehut.com/userfiles/xsquaredx/10refs.avi
16 refs http://www.thefilehut.com/userfiles/xsquaredx/16refs.avi
In my guide, I say 5 is the “typically excepted maximum.” But even so, it doesn’t take a leap of imagination to understand that there is a clear 14% filesize decrease between 5 references and 10 references. It isn’t a good idea to generalize on all content based on a single sect of testing; I have done tests with many bitrates and types of content, and there clearly a quality advantage at 10 references (over 5), but no real advantage over 10. My guide’s “absolute maximum” in this section is 8.

<> Don't ever use CAVLC... My benchmarks prove that decoding CABLC streams is only slightly faster than CABAC
bond: not true, cabac will decrease decoding speed clearly, as i described here (http://forum.doom9.org/showthread.php?t=99131)
DTS: I apologize, but I cannot take the word of that thread over the testing I have done, which has revealed much evidence to the contrary. Frankly, as IgorC pointed out below:
IgorC: Particular case doesn't define situation in general.
DTS: My results speak for themselves; I’ve no need to argue with anyone about my own findings. Consider these results at a constant quality of quant=35:
Cabac - http://www.thefilehut.com/userfiles/xsquaredx/cabac.avi
Cavlc - http://www.thefilehut.com/userfiles/xsquaredx/cavlc.avi
Benchmark them with this (ensure you set the screen size to 100%): http://cc.serveftp.org:8884/TCPMP_0.66e_for_Win32.exe
The results are clear: with the same exact source and exact same settings, cabac clearly underperforms cavlc in terms of decoding speed with the high-speed, high-quality ffmpeg H.264 decoder.

[i]However, if you have a particularly complex source (or if you really want to scrimp for the best possible quality), try Uneven Multi-Hexagon with a ME range of 16-32
bond: hm didnt pengvado write somewhere that it doesnt make sense to use a value higher than 16 and that it even could decrease quality!?
DTS: Perhaps you should have looked back upon said remark and the context in which it resided so as to attain a more complete understanding of the properties of such a motion estimation range. For instance, if you had more thoroughly read this thread, you would have found a thread in which I specified results to the contrary: http://forum.doom9.org/showthread.php?p=698397#post698397
akupenguin: dia and hex cap merange at 16. It slightly reduces code complexity, and if the real mv is more than 16 pixels from the prediction, they won't find it anyway.
DTS: Essentially, however, the range 32 uneven multi-hexagon search, because of its nature, would search a more exhaustive area within its range based on the principle that its core is larger, even if it is incapable of predicting past the 16 ME boundary (at which hex is capped). Again, I am not a developer, but I have seen consistent, concrete results using a umh ME range of 32.

Generally lower framerates (12-15 as opposed to 23.976-29.97) need a higher estimation range.
bond: why that?
akupenguin: Because at lower framerates, objects have moved farther between consecutive frames. => need to search farther on average to find an object.
DTS: This is also true of animated content, which by very definition is “animated;” drawings are typically spaced far enough apart from one another to render a higher ME range beneficial. This is also where B-frame users run into more trouble—due to the discrepancy between certain pairs of frames in low-framerate/animated content, bidirectionally predicted frames may not be able to accurately fill the gap easily, and even so, the subsequent P-frame would have to look 2 frames behind it for prediction (unless B-pyramid is activated). Look above for more information containing some B-frame analysis. My guide, however, states when to employ (or when not to employ) both B-frames and a high ME range, and it does so based on this “rule.”

<>\ When they become more widely available for use, take advantage of custom H.264 quantization matrices. The x264 codec currently (rev. 285) does not support this feature.
bond: it does
DTS: And if you’d read the entire thread, you will see that I acknowledge this, but due to the fact that decoder-side support of this is very limited at the moment (not to mention the lack of the current VFW’s lack of support), I chose to leave this out of my guide.
foxyshadis [to bond’s response]: True, but decoders don't. (I think ffdshow's support for it was buggy when I tried last month, and no others worked at all.)
DTS [earlier quote in this thread, to CiNcH]: Indeed. This is precisely the reason I left it out of my guide.

*B-frames can be activated in "pyramid" mode, which allows B-frames to serve as references. If you wish to use a lot of references (and thereby increase quality slightly), consider selecting the "Use as references" checkbox.
bond: b-pyramid doesnt really have much to do with the number of reference frames
DTS: True, but I still don’t really see much of a problem with my statement; B-pyramid, by very definition, is the usage of B-frames as “references” for following frames. By using B-frames as references, you are, in a sense, adding a type of references to the stream, thereby increasing quality slightly—due both to the fact that more references increase the video quality, and due to the fact that frames following the B-frames can use the B-frame for prediction (therefore, they would serve as references). Remember, I’m not a developer, so I don’t know the internal code, but try the guide—the quality attained using my tested method really speaks for itself.

However, this option may cause some crashes with both the encoder and the decoder (if either is old enough). For this reason, I recommend NOT using B-frame references.
bond: doesnt make sense, instead you should recommend to always use the latest version of the codec
DTS: It makes perfect sense. You see, the latest codec at the time of writing (rev. 285) consistently caused crashes for me when too many references were used with B-frame references. Why? I don’t know, but the fact is, the problem persists even today with revision 291 on all of my machines using the newest hardware and software. Whether the cause resides in the input colorspace, the codec’s internals, or a seemingly infinite number of other factors, it still frequently crashes on both of my brand-new computers and many others I know of, giving it my definition of “unstable” and therefore warranting a few words of my caution. It is for this reason that I’ve worded my statement so; perhaps when my guide is read at a later date, this option may have become more stable for all machines (or, at very least, when all major decoder-side components are stable—ffdshow has only begun to become stable for me within the past few months, to say nothing of others). But otherwise, I’d have to say that, yes, it is common knowledge to always use the newest version of a program/codec unless a newer version is known to have introduced sizeable flaws. Therefore, I shall also employ this advice in the upcoming, newer version of my guide.

[My statement continues in the following post]

[DeathTheSheep]

[This is a continuation of the statement started in the previous post]

<> For deblocking strength, try not go out of bounds of the -3 to 3 range. Generally, any more than 3 will turn your result into mush while decreasing PSNR and actually increasing the output file slightly. Any less than -3 may cause the result to look a bit too blocky and any lack of texture will merely become more apparent as all smoothing is taken out.
bond: positive values of loop will tend to remove details -> smaller filesize
(akupenguin [to bond’s statement]: Not necessarily.)
DTS: It is not safe to conclude this. If your statement is true, then I assume that at a fixed quantizer (and therefore with uniform quality throughout), filesize will decrease if loop filter is more heavily applied. Take a look at these sample encodings, where any difference is clearly discernable. I disabled B-frames, but all other settings are default (and quantizer = 30). You see, this statement is simply not true for most cases, and like akupenguin said, “you can’t deduce the global effect from the definition.”
Strength= 0; http://www.thefilehut.com/userfiles/xsquaredx/deblock0.avi
Strength=-6; http://www.thefilehut.com/userfiles/xsquaredx/deblock-6.avi
Strength= 6; http://www.thefilehut.com/userfiles/xsquaredx/deblock6.avi

And here are some 2-pass samples, which show such a phenomenon less, due to the fact that they are the same size because of the nature of 2-pass mode (but PSNR was lower for the -6 and 6 deblocked clips, as I predicted). In part due to the ultra, ultra low bitrate (unfortunately, I don’t have my own dsl line with which I can upload large files), and in part due to the animated nature of my content (I have qualms about uploading parts of Hollywood movies), the subjective quality stays about the same for the DB: 0 and DB: 6 encodes, but as the bitrate gets higher, difference is more capable of being clearly differentiated—the highly deblocked tends to wash too much detail.
http://www.thefilehut.com/userfiles/xsquaredx/deblockX_2pass.avi (replace the X with 0, 6, or -6).
All in all, though, it appears as if increasing or decreasing deblocking intensity by too far a margin will hurt both quality and filesize, as I clearly stated in my guide.

Present in certain AVC encoders, this is a method of lumi (+chroma) masking in which very light or dark areas of a scene are encoded in terrible quality, which gives more bitrate to the rest of the video.
bond: i wouldnt talk about "terrible quality" here, as the point here is to encode with lower bitrate where the eye cant see the difference anyways, so for the eye the quality will stay the same
DTS: It is true that I have seen fairly prominent flaws in low-lighted content not present in identical encodes with psychovisual enhancements disabled. Nevertheless, I was speaking of “quality” in terms of bitrate allocation; that is, how accurately dark areas are encoded. If I’d have said “visual quality,” I would be implying otherwise. Nevertheless, I can see your point, and I shall clear this up in my next version of the guide (let’s call the next version a “beta.”)
As to another issue relating to psychovisual enhancements, I’d like to make it clear that I am not a developer of NeroDigital AVC, and do not know what each psychovisual enhancement does internally, but I can be sure that the test results I have attained with ND AVC in very dark (dungeon) sources are of noticeably less visual quality than without psychovisual enhancements (most notably in textured areas), and it was indeed “noticeable.” If you insist, you may test this for yourself on a very dark source and see for yourself. This is most relevant at higher bitrates (so I can’t upload an indicative source).

<> B-frame reduction (if you choose to use B-frames) should be adjusted according to the desired datarate. For most DVD backups, the default B-frame reduction of 30% seems to be sufficient. However, with certain animated medium bitrate content, I suggest use of up to 50% B-frame reduction.

<> Personally, I find that the keyframe threshold of 45% and keyframe QP boost: 20 to be the optimal in achieving quality at medium bitrates. However, if you wish to produce Ultra-Low-Bitrate video (DVD backups less than one CD), consider reducing this to 0, for your video's quality (PSNR) per BM will increase.

<> In maximum-quality content, I find that the keyframe threshold of 35% and keyframe QP boost of either: 30 or 0 to be the optimal in achieving quality at medium-high bitrates in my "maximum possible quality" mode.
bond: where do these values come from? any screenshots? again my request for samples that show that x264s defaults perform worse than with your proposal
DTS: First and foremost, I’d like to clear up one massive point of obvious confusion: The above values, as were the constant values attained elsewhere in my guide, came to be as a combined result of my own empirical testing and material observation of visual results. The “evidence” is also within the results of this method.
Indeed, If you disagree with the guide without even attempting to try it, you cannot be certain of its fallacious nature. Remember, this is a guide (and one in “pre-alpha” stage at that), and as such, it deserves to be treated as one; give it a chance first and then compare the results to those of any other method you choose. Recall the fact that it is, at this point, you contesting me, or more correctly, the aforementioned results. However, I’m not about to argue with speculation-- speculation is easy and fun, isn’t it?—but rather, if the results I consistently achieve are in question, it is the duty of the challenger to provide counterevidence, which will indeed be addressed. In the case that you may have pondered the reason for my frequent requests for more forum space (or an alleviation of the 16k character limit), it was to provide extended services such as screenshots, a better graphic scheme, and more information—some of which, perhaps, serving to justify my conclusions. (Perhaps if you had read the entire thread, you might have come to this realization.)


------- M Y -------
C O N C E S S I O N
-------------------
I make the following statements to admit errors on my part.

The bitrate variability feature controls how much your datarate can fluxuate at any given time. That is, if you plan on encoding at 500kbps and set this value to 40, the maximum amount of bitrate given to more complex scenes is 700kbps.
akupenguin: No. See some explanations I gave to Chen.
DTS: I am not a developer, so I apologize for the misinformation regarding the internal workings of this tool. However, if the bitrate variability tool does not work as I have so erroneously stated, it still controls the amount by which the video stream fluctuates by means of it controlling QP curve compression, right?
Again I apologize, but I don’t really know who “Chen” is, much less where the aforementioned explanations were given. Any assistance?


To stream x264 video, you need to have a player capable of handling streaming; nearly all players I can think of at the moment support this. I suggest using Media Player Classic, but Windows Media Player 9/10 works just as well for many people as long as the ffdshow decoder is installed. Make sure to configure the player to automatically start a stream with the desired file extension (the most commonly made x264 files use the ".avi" extension).
bond: you are sure that dshow players will be able to play streamed h.264 .avi files? somehow i cant believe this. do you have a sample stream link i can try?
DTS: I understand your confusion. In fact, the wording wasn’t clear here in my guide. When I mention “desired file extension,” I’m not referring explicitly to .avi. On the contrary, I am referring to any format capable of streaming media, such as .asf or mp4, if you so choose. I also point out that the .avi file extension is most commonly used for the storage of x264 files, implying that at least a container switch could be in order if streaming is desired. I agree, though, that perhaps a bit more than the wording is unclear, and I apologize. Perhaps if I had more room, I could elaborate, but I will nevertheless either change the guide’s final wording or remove the streaming section entirely (but leave the streaming settings). However, it does appear as if I was mistaken about ffdshow being able to play streaming H.264 content as of yet; in fact, only with certain codecs was I able to attain streaming capability in WMP. Indeed, I should have stated that a streaming-enabled decoder is necessary, but I erroneously assumed the new versions of ffdshow could handle such content. I apologize; I’m clearly not an expert at making streams (do I have my own streaming server?), but my guide is intended for high-quality AVC settings, not a streaming how-to. Here is a sample asf stream attained using the beta ASF muxer. http://www.thefilehut.com/userfiles/xsquaredx/trythis2.asf
Perhaps the Moonlight H.264 Decoder & Streaming Pack could be of use in this situation, in which case it would supposedly be able to stream certain AVC-MP4 streams.


If a certain frame's reference is far off into the file, the entire file becomes unplayable until the video is downloaded up to that reference.
akupenguin: No, multiple references have no effect on seekability. (BTW, they also have no effect on AVI compatibility.) All reference frames would have to decoded anyway, because they're between the current frame and the previous keyframe...
DTS: You are absolutely correct, and I was absolutely (and rather foolishly) mistaken. I assumed (see, there’s the mistake) that somehow reference frames had an impact on streaming x264. I therefore assumed (there we go again...) that there must have been some sort of “backwards referencing” going on, which, looking back on it, now strikes me as preposterous. The reason I made these assumptions was that I could find so very little streaming x264 content online to perform comprehensive testing on. It was an imprudent decision to put any sort of streaming directions in my guide, for as I said above, my guide is intended for high-quality AVC settings advice, not a streaming how-to.

-----------
Final Words
-----------
By placing this preliminary version of a guide in a forum, I was obviously asking for responses and input, and I am thankful for all you have given me. Indeed, I greatly appreciate what I have learned and what the community has learned in the process. And this learning, I might add, will not be wasted on me, for I will release a so-called “beta” version of my highly updated and expanded guide in due time.

However, I can’t shake the feeling that there was some sort of negative connotation in your post, bond, based on the way you posed some of your questions. True, we all do different tests, and we can all make mistakes, and I’m sure you realize this too. We simply have to learn from them and grow. It never hurts to expand your knowledge-- my own, for my part. I thank you for being part of my own betterment in addition to part of your own, and I wish the rest of the community luck in utilizing this guide to its full potential.

I look forward to more comments and suggestions; after all, this is your guide, too!

DTS

[Revgen]

akupenguin: No. See some explanations I gave to Chen.
DTS: I am not a developer, so I apologize for the misinformation regarding the internal workings of this tool. However, if the bitrate variability tool does not work as I have so erroneously stated, it still controls the amount by which the video stream fluctuates by means of it controlling QP curve compression, right?
Again I apologize, but I don’t really know who “Chen” is, much less where the aforementioned explanations were given. Any assistance?


I believe he was reffering to this (http://forum.doom9.org/showthread.php?t=98386) thread.

[TheBashar]

DTS,

In the context of 2pass (or more) high quality encodes, I humbly suggest testing the parameters "--ratetol inf" and "--qpstep 40". In my testing I have had good results with these. Sorry, I don't know what they are referred to in the VfW encoder as I use CLI. They represent "Bitrate Variance" and "Maximum Quantizer Delta" in MeGUI.

Cheers!

[bond]

huh lots of things, i will pick out the most important ones :D

first of all thx everyone for the given info

- nero and moonlight support custom quant decoding
- when setting 0 reference frames in x264 it will encode with 1 reference frame (or 2 reference frames if b-frames are enabled). that is because x264 is smarter than the user i assume :D
- if you have crashes with b-ref and large numbers of mref you should start an own thread about this and tell the x264 devs
- "most x264 encodes use .avi" - where do you see that? on your harddisc? ;)

[numaios]

My sources are widescreen DVD movies, and yes, i use 20% of the bitrate recode reports,
I still don't understand :confused: So you don't use a fixed final size? And then you use the 20% of the source bitrate? Or the 20% of the bitrate that Nero Recode recommends you?

The thing that frazzles me is that the people who use Nero often confuse the "range:32" of x264 and the "range:512" of Recode2. I think some "range" clarification is in order for us poor folks (motion vector range : motion estimation range).
I don't understand, so is it the same or it isn't? "Maximum vector range" in Recode has the same effect as "Motion estimation range" in x264?

:thanks:

[bond]

I don't understand, so is it the same or it isn't? "Maximum vector range" in Recode has the same effect as "Motion estimation range" in x264?its not the same, x264 always uses 512 for vector range afaik?

[numaios]

I see, so we should always set 512 in Recode if we'd want the accuracy of x264, is that correct?

[max-holz]

Is it possible to update the guide with some explanation about the use of adaptive quantization?

[unmei]

What surprised me a bit is that the adaptive quantisation seems to work by "upping" the quality on bright areas (as compared to lower the quality in dark areas like i thought XviD did it).
I suspected this after doing a CQ (21) test with and without AQ. And while the one withou came out at 800 kbit/s the AQ one was 1400kbit/s (!). So i played the file and set ffdshow to show quantizers - and no longer surprisingly - a P frame supposed to be Q21 has the highest quantizer at 21 and the lowest one 12. A I frame (supposedly 18) even had blocks with quant 10 (that is the lowest allowed by the set Q range!).


Encoding with CQ 26 and AQ gave me a file with almost the same bitrate as Q21 and no AQ (800.52 vs 800.75 kbit/s). Interestingly the one with out AQ has a mean PNSR almost 1dB higher and global PSNR ~1.2dB higher than the one with AQ.

Also AQ seems to considerably raise the number of direct B macroblocks (2%->14%) and lower the number of skip B macroblocks (72%->42%). This is comparing the encodes with the same CQ (the one with adapted CQ 26 has 12% direct and 62% skip).

[Sharktooth]

one word: multipass.

[unmei]

i know that word :D

But would you elaborate a bit more.. will AQ only work correctly in a multipass scenario? Because this seems not to be the case..
Of course in CQ with AQ the file size becomes kind of even less predictable, but from what i saw so far, CQ with AQ also seems to be an option when i raise the "constant" quant to compensate for the lower quants in some macroblocks.

[Haali]

AQ should be used only when you have noticeable blocks in flat backgrounds. It will allocate lower qp to such areas. Adding some more bitrate won't hurt as well, so the rest of the frame doesnt lose too much quality.

[Teegedeck]

AQ seems to work fine for strong compression. I tested with various constant-quantizer encodings of the same clip and found that encoding at quantizer=27 without AQ yielded a filesize just above that produced by quant=29 + AQ. The encode at quant=27 without AQ exhibited extensive blocking (deblock=-1) while the one with AQ didn't and thus looked very acceptable, I daresay 'good'.

This should mean AQ makes the higher quantizers in x264 really worthwhile for the first time - because with AQ it's not necessary anymore to use strong deblocking that turns the whole picture into jelly.

Well done, Haali!

[IgorC]

--chroma-qp-offset <integer> QP difference between chroma and luma.
I couldn't fine any information about it.
When it's usefull to use this feature? At low bitrates? What are admissible integers numbers of interval --chroma-qp-offset [x,y]?

[akupenguin]

range: [-12,12]
I have no idea when it might be usefull. I just implemented it because it's one of those obscure headers that someone might want to play with.

[unmei]

Maybe this is totally obvious to anyone but me, but since it was not for me i thought i would mention it: Adaptive Quantisation will not only produce quantisers in the set QP range (QPmin, QPmax).

Probably i just had the wrong concept of these and they do not represent the actual quantizer limits but the limits of average quantizer in P frames (or something along that line).

I'm currently playing with the AQ and CQ vs CRF settings and let the QP range at default [10,51]. What i found so far are Q8 blocks in all frame types (I,P,B) ..and they are not rare at all, they might make up like a third of the frame.


Note that this is not a complaint, just a statement ;)


So far i really like the one movie i did completely with AQ and CQ 26 and as long as the result looks good i am not "against" low quantised blocks. Tho i might turn down the AQ strength a bit for the next movie (0.3 maybe), that is i do these tests right now to get a feeling of the AQ parameters.

[Kenshin5]

And here goes the first complaining about x264... When i pressed x264 uninstall it started deleting all my system32 dll files and the windows recovery thing showed up, next thing i restart windows is not working or shit. Fix this issue, i don't intend to reinstall windows for this.

[Omni]

Anyone got a short hint for improving scene fades?
i get some big blocks on fades not over the whole image but on certain almost uni-colored faces. i'd say it's something about b-frames but i'm not totally sure ^_^

[Audionut]

range: [-12,12]
I have no idea when it might be usefull. I just implemented it because it's one of those obscure headers that someone might want to play with.


But it seems to only work with "I Frames".

Is that correct?

[akupenguin]

chroma-qp-offset applies equally to all frames.

[Audionut]

Well it's just that when encoding I always get psnr return figures of say,

Y=45 U=48 V=50.

So I tried increasing the Chroma-qp-offset to 12.
From memory it only seemed to greatly affect the I frames.
P,B Frames still had larger psnr values for chroma.

I'm in the middle of a large encode ATM, so it will be 2-3 hours before I can confirm.

[akupenguin]

What was the qp? Above qp=28, chroma_qp doesn't increase as fast as luma_qp, and it maxes out at luma_qp=51, chroma_qp=39. chroma_qp_offset is added to the lumna_qp before converting it to the chroma scale, so no amount of chroma_qp_offset will reduce chroma quality beyond 39.

[Audionut]

I just tried another encode, ensuring low quants.
And Chroma-qp-offset made an impact on PSNR.


Pass1.
C:\Program Files\x264>x264.exe --pass 1 --bitrate 2000 --stats "F:\2pass.log" --bframes 2
--b-pyramid --weightb --analyse p8x8,b8x8,i4x4 --chroma-qp-offset 12 --threads 2 --progress --frames 2000 --output NUL
"F:\test.avs"


avis [info]: 704x288 @ 25.00 fps (7063 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
x264 [info]: slice I:47 Avg QP:15.06 size: 23452 PSNR Mean Y:49.06 U:45.86 V:46.75 Avg:47.88 Global:47.48
x264 [info]: slice P:1225 Avg QP:17.51 size: 12292 PSNR Mean Y:46.29 U:44.57 V:45.45 Avg:45.78 Global:45.47
x264 [info]: slice B:728 Avg QP:18.87 size: 5991 PSNR Mean Y:45.13 U:44.46 V:45.02 Avg:44.95 Global:44.54
x264 [info]: mb I I16..4: 17.3% 0.0% 82.7%
x264 [info]: mb P I16..4: 11.3% 0.0% 26.5% P16..4: 24.1% 21.2% 11.2% 0.0% 0.0% skip: 5.7%
x264 [info]: mb B I16..4: 2.4% 0.0% 5.3% B16..8: 50.1% 5.0% 10.9% direct: 5.9% skip:20.3%
x264 [info]: PSNR Mean Y:45.930 U:44.562 V:45.326 Avg:45.529 Global:45.139 kb/s: 2052.16

encoded 2000 frames, 18.22 fps, 2053.30 kb/s

Pass2.
C:\Program Files\x264>x264.exe --pass 2 --bitrate 2000 --stats "F:\2pass.log" --bframes 2
--b-pyramid --weightb --analyse p8x8,b8x8,i4x4 --chroma-qp-offset 12 --threads 2 --progress --frames 2000
--output "f:\test1.mkv" "F:\test.avs"


avis [info]: 704x288 @ 25.00 fps (7063 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
x264 [info]: slice I:47 Avg QP:15.66 size: 21978 PSNR Mean Y:48.69 U:45.71 V:46.50 Avg:47.61 Global:47.37
x264 [info]: slice P:1225 Avg QP:17.49 size: 12149 PSNR Mean Y:46.29 U:44.60 V:45.46 Avg:45.80 Global:45.59
x264 [info]: slice B:728 Avg QP:18.97 size: 5666 PSNR Mean Y:45.08 U:44.40 V:44.88 Avg:44.90 Global:44.66
x264 [info]: mb I I16..4: 18.2% 0.0% 81.8%
x264 [info]: mb P I16..4: 11.6% 0.0% 25.7% P16..4: 25.2% 21.2% 10.4% 0.0% 0.0% skip: 6.1%
x264 [info]: mb B I16..4: 2.2% 0.0% 5.4% B16..8: 50.4% 3.8% 8.3% direct: 6.8% skip:23.2%
x264 [info]: PSNR Mean Y:45.905 U:44.553 V:45.271 Avg:45.513 Global:45.263 kb/s: 2004.07

encoded 2000 frames, 20.34 fps, 2005.21 kb/s

[DeathTheSheep]

When i pressed x264 uninstall it started deleting all my system32 dll files and the windows recovery thing showed up, next thing i restart windows is not working or ****. Fix this issue, i don't intend to reinstall windows for this.

Wow, that's certainly never happened for me... Are you sure your installation file wasn't corrupt? Any bytes missing near the end? Which revision were you using?
I'm terribly sorry for your loss (of Windows, time, and respect for the x264 package).

[Sharktooth]

And here goes the first complaining about x264... When i pressed x264 uninstall it started deleting all my system32 dll files and the windows recovery thing showed up, next thing i restart windows is not working or shit. Fix this issue, i don't intend to reinstall windows for this.
Where you downloaded x264?

[Kenshin5]

It was posted by you on the forums, it's an official built.

[Sharktooth]

Well... something screwed your registry then. The uninstaller only removes the x264 installation dir that's stored in a registry key... if "something" (virus,program,whatever) modified the path in that registry key or if your windows registry is screwed than it's not my fault.

[stephanV]

uhm... what if someone decides to install it in systems32? it is normal behaviour for an uninstaller to not remove the installation dir, if any other files are present that are not from installing the software. I'd say this IS your problem.

[Sharktooth]

uhm... maybe you're right...
i'll update the installer script for the next build.
however if you install it in system32 you're an idiot :D

[stephanV]

Maybe not an idiot, just unexperienced. ;)

[Revgen]

however if you install it in system32 you're an idiot :D

LOL! :D

[carlo_0000]

possible to update the topic with the new version ?

[DeathTheSheep]

A new version was planned, but this very early guide was written primarily for the vfw x264 of yesteryear, and recent settings packs for the newer, more updated CLI-frontend MeGui are generally considered the encoding norms of today (look for Sharktooth's "MeGUI Custom Video Profiles" included in Sharktooth's x264 Full Installation builds).

If people want it though, I suppose I could revamp it after New Years ;)

[DarkFoon]

I want it :)
So I have a better idea of how to improve sharktooth's profiles for my own uses.

[Arcon]

ok, i just did my first x264 encodes and started to fiddle around with the options, but i'm still wondering if i'm expecting too much.

the results x264 produces are very smooth, i'm used to do high bitrate xvid encodes with qpel enabled and usually watch them without postprocessing, so i prefer a sharp picture with high details with some grain over the clinically smoothed version.

what settings are mainly responsible for this in x264 and how can i tweak them to get x264 to produce more detailed and less smoothed pictures? or is x264 and the postprocessing that coupled that i will have to say goodbye to the grain and start to get used to smoothed pictures?

[Caroliano]

The inloop filter setings. If you want sharper pictures, use negative values. Disable it is not recomended.

[DeathTheSheep]

Yeah, check out the Deblocking section of the guide! Maybe it'll help ;)

@all: OK, I'll revamp it right after New Years! (Or maybe as a Christmas present??)

Cheers! And happy holidays for those of us who have 'em comin' up!

[Arcon]

Yeah, check out the Deblocking section of the guide! Maybe it'll help ;)
but is x264 generally able to produce a picture similar to xvid+qpel or is the concept with the inloop deblocking that hardwired and part of the codec that the picture will always be smoother (or blockier if you set the inloop to negative values) than those asp-encoders create?

currently i wonder if i'm just using it the wrong way or if h.264 might only be superior to asp-encoders in situations where postprocessing is used to conceal low bitrate blocks.

[DeathTheSheep]

It definately produces a picture that is somewhat...different than XviD.
AVC and ASP are indeed 2 very different formats despite their conformance to one or another part of "MPEG-4."

is x264 generally able to produce a picture similar to xvid+qpel
Since the objective of a codec is to reproduce the source as accurately as possible, both will look pretty similar (like the source) if given high enough bitrate. The deblocking options control how much x264's resulting image is smoothed. The default deblocking tends to produce fewer visible blocking and ringing artifacts than ASP even while maintaining the same PSNR.

XviD's artifacts in high-detail scenes are often mistaken for detail. The Human Visual System tends to see XviD's artifacting in spatially complex scenes as the scene's actual detail. Indeed, the HVS often confuses artifacting for detail, and because x264 removes this artifacting by default, the HVS percieves this to be a "loss of detail" even though technically x264's detail is just as accurate.
However, reducing the deblocking in accordance to the guide is the best way to go about sharpening the image (reducing the soft smearing of deblocking). You might as well give it a try on a small clip: do a 30-second clip with XviD and x264 with -1 or -2 deblocking and then evaluate.

The general consensus as of yet (at least according to the metrics) is that x264 does tend to keep more detail more accurately than XviD at similar bitrates. However, the deblocker's removal of artifacts is occasionally confused by the HVS as a removal of legitamate detail, which the artifacts are occasionally mistaken for. If you find this to be the case, use a post-processing filter (AVISynth, mplayer, ffdshow maybe) to better synthesize noise.

[Tommy Carrot]

but is x264 generally able to produce a picture similar to xvid+qpel or is the concept with the inloop deblocking that hardwired and part of the codec that the picture will always be smoother (or blockier if you set the inloop to negative values) than those asp-encoders create?
If you disable the deblocking completely, x264 will behave similarly to xvid, except that the produced video will be even sharper. I think it's safe to disable deblocking up to quant 22 (bitrate-wise it's somewhere between quant 3-4 in xvid, usually used for 2cd rips), but over that the blocking is starting to become disturbing, a light deblocking is recommended.

[DeathTheSheep]

TC is right in general, but the resulting video won't have nearly as good of a quality measure as a video attained by using the default (or -1) deblocking settings; if you want noise, you'd almost always get better results with post-processing. I'd certainly never recommend turning off deblocking under any condition (unless the decoder doesn't support it or AVC playback is too complex for your machine).

[Tommy Carrot]

Disabled deblocking may have lower results in quality measures, but it can look better, especially in near-transparent encodings, where the artifacts are already unnoticable, and the deblocking would destroy the very fine details.

[DeathTheSheep]

but it can look better, especially in near-transparent encodings, where the artifacts are already unnoticable, and the deblocking would destroy the very fine details.
Using the default settings, deblocking is automatically scaled based on the quantizer used. If the quantizer is very high, default deblocking is heigtened accordingly by the encoder, and once the quantizer drops low enough that the encoder deems deblocking to be useless, it is automatically disabled.
Therefore, it is best to leave it as it is: at (0,0) unless you have specific preferences with deviation of no more than +2/-2. The encoder should handle the rest.

[Tommy Carrot]

Lol, i know that deblocking strength is adaptive, but the default settings are not always the best. If someone prefer the 'xvid look' over the smoothness of h.264, imo it's better to disable the deblocking at higher bitrates (<q22), where the default setting is washing away too much details unnecessarily, because the artifacts are rarely noticable there anyway. Afaik deblocking is turning off by default at quant 15, which is way too low imo, and this probably answers why many people prefers xvid over x264 at high bitrates.

At lower bitrates though, i agree, in-loop filtering is very useful and beneficial.

[Caroliano]

You tried -5,-5? It may be better than disable it completely. H.264 was thought with deblocking in mind. It shoud be more blocky w/o deblocking than Xvid. But I don't know. I haven't tested yet.

[Arcon]

I'd certainly never recommend turning off deblocking under any condition
i usually filter out noise during the preprocessing and want the codec to keep the picture as close to that input material as possible. removing noise afterwards was something i only liked for low bitrate encodes (i.e. avg quant ~4) where the pp had to filter out the shortcomings introduced by the encoding process, not by the source material.

thats why i was a bit disappointed in the x264 look compared to my beloved xvid.

but thanks for the tips, i'll fiddle around with the settings and try to find something that gets close to my expectations :)

[DigitalDivide]

*B-frames can be activated in "pyramid" mode, which allows B-frames to serve as references. If you wish to use a lot of references (and thereby increase quality slightly), consider selecting the "Use as references" checkbox.

Am I missing something here? I don't see a checkbox for "Use as references".

[foxyshadis]

It's called "Pyramid" in MeGUI, but the option is still there in the VFW B-frame section (in MBs&Frames tab). It only activates if you have more than one B-frame.

[LiFe]

A question that google hasn't been able to find on doom9:

What's the difference between Constant Quantizer (qp) mode and Quality (crf) mode?

Thanks.

[slavickas]

A question that google hasn't been able to find on doom9:

What's the difference between Constant Quantizer (qp) mode and Quality (crf) mode?

Thanks.
why google when forum search tool finds it perfectly
http://forum.doom9.org/showthread.php?t=101551&highlight=crf
probably post #20 most explaining

[[)370|\|470!2]

How many passes should be used to get the possible "best-out-of" x264.
And btw, does bitrate setting in 1st pass affect following passes?

[DarkZell666]

actually 2pass is pretty good already, but 3pass has been proven to give visible better quality in some cases (the examples that comes to my mind is anime @ low-bitrate, e.g. < 400kbps, with very sudden bitrate changes).

Ask Sirber :p
You could consider using --crf instead, all depends on what you are trying to do :)

[carlo_0000]

possible to update the topic with the last version
there is a lot of change

[Sirber]

DeathTheSheep is unavailable until March 10 due to circumstances beyond his control. You're gunna have to wait ;)

[DeathTheSheep]

I'm back, and with a massive update to the guide! It's much better than ever--now with detailed pictures, descriptions, instructions, and suggestions, the all new, fully revamped DeathTheSheep x264 VFW Guide is like nothing you've ever seen before!

[Sirber]

Seems you do productive things in your "forced freetime" ;)

[akupenguin]

http://gabe.5000megs.com/DeathTheSheepAVCguide.pdf
You got scenecut threshold and bitrate variability backwards.
Higher scenecut => more keyframes.
Bitrate variability = 0 => constant bitrate.

[DeathTheSheep]

Tweaked. ;) Thanks for catching that before it could do any damage!

that darn qcomp...

akupenguin: What do you think about the rest of the guide? :)

[Sirber]

No more GUI clutter, no more CLI mess!... use RealAnime! :D

[3ngel]

@DeathTheSheep
Where is gone the section dedicated to "Maximum quality regardless cpu time"?
And when it'll be back? :)

[DeathTheSheep]

3ngel:
Hi! My guide now includes information about the added quality and speed penalty of different options, so it allows you to choose for yourself whether or not to activate certain options based on the extra time they take to encode.

For instance, disabling fast P-skip, as is stated in the guide, results in a very small overall quality increase of the encode, but it results in a longer encoding process. Therefore, I didn't recommend it for fast encodes unless blocking on flat textures is experienced. However, if you want the little bit of extra quality regardless of the encoding loss, feel free to turn it off.

It also explains, for example, that more reference frames tend to increase quality, but the speed penalty clearly outweighs their quality gains after 8 are used. However, based on the information that more are better, despite longer encoding time, feel free to use the maximum (16).

I hope I have been helpful to you, and if you are still having issues with this matter, I will consider revising the guide.

Thank you for your interest in DeathTheSheep's x264 VFW Guide, and have a nice day!

[3ngel]

Oh, i see... so in other words you've changed the organization of the guide. I found very comfortable in the first version of the guide to skip the first two parts (in which i was not interested) and concentrate only on the third part (maximum quality). I found it very simple and clear.
Now i have to read the entire guide trying to districate myself in all the parameters... I think that if you reabilitate the three parts it would be more clear and simple, but if you're not, well i'll try to read the entire guide :)

[Dyolfknip]

Great guide! Thanx Sheep.

[thuongshoo]

Thanks you ! I'm using VirtualDub and K-lite codec pack 271 . I don't see where "fast skip" is . Did "New version vfw" remove this option ?
thanks !

[ChronoCross]

klite codec pack is stupid. probably doesn't have a newer version. I recommend staying awway from all codec packs.

[Audionut]

AFAIK, vfw never had fast p-skip.

[Sagittaire]

A good bet for most people interested in high quality video would be the range of 20 (highest
quality) to 30 (lower quality), depending on individual preference and the amount of disk space
reserved for the encoded file.

Q30 for full HD resolution will be high quality encoding
Q20 for CQIF resolution will be low quality encoding

Resolution is really important here because DCT artefact size are always the same but not DCT artefact relative size : it's hard to see high blocking level at 1080p but not soft blocking level at CQIF/QIF resolution.

Little example:
sample 1 q20 512*288 done 1057 Kbps
sample 2 q24 720*400 done 1021 Kbps
sample 3 q30 1280*720 done 1023 Kbps

Find the best sample for yours eyes ... ???

[celtic_druid]

I added an option to disable fast pskip last year (built as part of FU Wizard). Still it (VfW) has had fast pskip as long as the cli has. Just no option to turn it off.

[DeathTheSheep]

@Sagittaire: Of course! All users are recommended to experiment with settings until they find what looks best for them :) My guide is just a "guide" :P
Certainly, the higer the resolution, the higher the quantizer can be with less perceptual quality loss. I just didn't think people would use my guide to encode to something as high as "1280*720"... Thanks for the advice!

@Audionut:
AFAIK, vfw never had fast p-skip.
Yet another person not to even glance at the guide or at the new VFW but decides to comment anyway... ;)
Yes, later vfw revisions did indeed have all the options I describe in my guide. I suggest installation of: ChronoCross x264vfw (http://chronocrossdev.com/apps/x264/x264vfw.rar)

[killerhex]

where do i put the vfw

[DeathTheSheep]

1. Simply unzip the VFW package anywhere you like, and unzip this (gabe.5000megs.com/x264vfw.zip) in the same directory.
2. Right-click the x264vfw.inf and select "install"
3. Click "Continue Anyway" and you're done. You now have the new VFW installed! :D

[killerhex]

the .INF file wasnt in there

[ChronoCross]

If you install the x264.nl vfw builds just replace the vfw file from that pack. Since you need the lib file in the first place.

[Audionut]

I suggest installation of: ChronoCross x264vfw (http://chronocrossdev.com/apps/x264/x264vfw.rar)

Not all builds support that option. Supported by this statement.
I added an option to disable fast pskip last year (built as part of FU Wizard). Still it (VfW) has had fast pskip as long as the cli has. Just no option to turn it off.
But ChronoCross builds do.
Thanks for the heads up.:rolleyes:
Oh, wait. VFW blows.

[Inventive Software]

Sheepy: I commend you on your superb guide, especially the deblocking! Now I understand most of the options, and can use them properly, deblocking included! Previously, I just disabled it cause I didn't understand it! In later encodes, it cost me on the detail side. Thank you SO MUCH for your insider expertise!!!!!

[stax76]

I have some suggestions if you don't mind: Provide a HTML version, best as WIKI so others can contribute, use different pages and anchors e.g.:

http://test.com/bframes.htm#rdo

Make it GUI agnostic meaning don't use screenshots of a GUI since there are many popular GUIs like StaxRip, MeGUI, VFW, Gnome/GTK just to mention a few.

[DeathTheSheep]

That's a good idea--I'll look into it! The link you provided, however, is dead :(...

[stax76]

Thanks for considering my suggestions, link was just a example how a url with anchor looks.

[DeathTheSheep]

I've made some tiny changes to the guide and also uploaded it in html format, included in this zipped package (http://gabe.5000megs.com/guide/dts_x264vfw_guide.zip). It is not tagged or anything yet (partially due to the fact that I know next to nothing about html coding), but it is freely available for anyone to tweak or change to their heart's content. Email me or otherwise send me any changed files so that I can update the guide. Have fun! :)

[DeathTheSheep]

Large update!
- Default format for the guide is html
- PDF filesize cut by more than 50%!
- Revamped, easier-to-understand deblocking section
- "Late modified" added so you can always be sure you're viewing the most recent updates
- Chroma ME, rate control, and trellis explanations updated and improved
- Improved cosmetics and guide layout
- Many other fixes, changes, and improvements!

A special thanks to imcold for all his help with this project!

[modsoul]

thanks deathsheep. awesome guide. really increased my understanding of all the option. would you mind if i upload th guide to a torrent site. i figure more ppl will have access to it and it won't increase the load on your servers .

[xyloy]

Direct B-frame mode (S) allows B-frames to use “predicted motion vectors” to be used instead of coding the actual motion, thus saving space and increasing compression efficiency. Of the 2 modes currently available, I suggest usage of Spatial for animated content (better handling of inconsistent motion jumps) and Temporal for real-life content (fluid motion).
The theory is right, the experience is otherwise. ;)

With x264 CLI encoder, if I set the B-frame direct-mode to "auto"(wich enables the use of both spatial and temporal B-frames within the same AVC bitstream. The "decision" to use the first or the second mode for each B-frame is up to the x264 encoder), spatial is always the most used(according to the 1st and 2nd pass CLI log), even with the most "real life" content.

The most temporal use I've seen with "real life" content is 90% spatial, 10% temporal. Most of the time, it is around 98% spatial B-frames...

(of course, settings like 3 B-frames, B-pyramid, adaptive B-frames, RDO on B-frames, Weighted B-frames, and Bidirectionnal M.E are used, so thoses average results of 2-pass encodes are quite accurate)


So AFAIK, as long as the "auto" option is missing, spatial direct B-frame mode is the "good" choice for x264 VFW, whatever the content is.

[DeathTheSheep]

The most temporal use I've seen with "real life" content is 90% spatial, 10% temporal.
I am aware of this, and also of the fact that right before "auto" direct mode was implemented, the encoder defaulted to Spatial mode.
PSNR and other benchmarks, as well as other per-frame analysis techniques, tend to portray spatial mode as the superior of the two direct modes, but from my experience, motion fluidity is more positively affected by Temporal mode, a quality factor more noticeable than the relative perceived frame-by-frame quality decrement attained from its use. The ~3-10% of frames to which Auto mode designates temporal B-frames tend only to be those most drastically benefited by Temporal mode--or those most degraded by Spatial. I'd go as far as to venture that an average real-footage encoding with B-frames consisting entirely of Temporal B-frames would be more consistent in motion quality than one with B-frames entirely consisting of Spatial B-frames. This is especially noticeable in low-bitrate, fluid-motion clips which tend to exhibit jumps and motion inconsistency with Spacial B-frames. In regards to this same clip, while various metrics might report a nominal gain in all-Spatial vs. all-Temporal B-frame employment, the motion fluidity and consistency of Temporal B-frames more than makes up for the minuscule frame-by-frame artifacts it may introduce or the detail it doesn't manage to preserve "accurately."

Also, please bear in mind that Auto mode isn't available in the VFW settings configuration (at the time of writing), and my suggestions reflect this fact.

would you mind if i upload th guide to a torrent site.
Not at all--do whatever you please with it :)

[xyloy]

I'd go as far as to venture that an average real-footage encoding with B-frames consisting entirely of Temporal B-frames would be more consistent in motion quality than one with B-frames entirely consisting of Spatial B-frames. This is especially noticeable in low-bitrate, fluid-motion clips which tend to exhibit jumps and motion inconsistency with Spacial B-frames.
I should have noticed theses jumps and motion inconsistencies since I do low bitrate fluid-motion encodes, but I did not...
Maybe it's not obvious, or the bitrate I usually use is not low enough to see it(or both)

[DeathTheSheep]

Or perhaps you use Auto :D

[xyloy]

I meant with some "spatial" vfw encodes done in one pass(Constant Quantizer of 26) ;)

[DeathTheSheep]

CQ 26 is pretty mid-rate by my standards, at normal DVD resolution. But yeah, at that rate, it wouldn't be as apparent in most scenes. But when I did a certain 3D movie at low-res quant 33... it stuck out pretty badly. And my goodness does it hurt the subtle motion of clouds... 'tis a jumping block fest if I do say so myself :D

Well, happy camping and I wish you the best. "Do what works best for you" keeps coming back to me... ;)

[Egh]

High quality AVC the easy way! Check out DeathTheSheep's x264 VFW Guide now!

Is the website dead now? :) Along with the guide in all formats :)

[imcold]

I made this backup when we were working on cleaning up the html version. I't from 7.5.2006, dunno if anything was changed lately.
DeathTheSheep's x264 VFW Guide (http://imcold.evilhosting.org/files/dts_x264vfw_guide.zip)

[DeathTheSheep]

Hmm, I don't know what's wrong with the site, but until it's fixed, use imcold's link or go to the following temporary site for the pdf:
http://gabextreme.googlepages.com/

Oh, and by the way, the reason I've been absent from Doom9 lately is due to what I like to call the "summer fun" festival. :D

[DeathTheSheep]

As I posted in the thread that marked the end for the [official] x264 VFW:

Ah, the diversity and freedom of choice suffers another blow for the good of...uh, whatever the good in suddenly canning VfW happens to be (above posts hinted at...something or another, I believe). :P

Well, VfW is old, and I guess it is too easy for the average user, eh... Can't let 'em have it too easy; heavy-duty learning must be done! :P

I mean, it's not like my entire 13-page guide with explanations and illustrations has in one day been rendered completely and utterly useless...

And it's not like 50% of x264 users will be left in the cold, forced to switch to a whole new GUI, container, and jargon to receive any further updates to this one codec, and separately install GUI software to use this one codec, and install .NET framework 2 for this one codec (GUI), and other of such nasty things, eh?

This whole thing reminds me (unpleasantly) of having to learn and upgrade to a whole new OS (XP) or processor just to use a new version of a software (Windows encoder), when compatibility with the older ones could easily have been retained... Didn't you say something like that before, bond? :)

So here is my (constructive) suggestion: just keep the vfw code intact. The VfW is complete enough for the average user, is it not? Why force drastic and unnecessary change when leaving it the way it is takes virtually no effort?

Thanks for hearing me out.

In other words, the guide, which relies on VfW, will no longer be updated or maintained due to the removal of the tool used by roughly %50 (based on a poll and the folks I know) of the x264-encoding community, so it shall remain frozen in time. (Or will it...? Who knows what the future holds for the VfW...? ;))

Thank you for all the help and support you've given me throughout the guide's short but brilliant life!

My regards,
DeathTheSheep

[ChronoCross]

just remember you basing that stat on a shoddy poll done on x264.nl which is cookie based. I bet you I can make it so only 1% of user is vfw.

[GodofaGap]

@DeathTheSheep:

I wouldn't mind providing you a VFW build every 10-15 revisions or so, as long as you are willing to host it and compiling VFW isn't broken. PM me if you are interested.

[DeathTheSheep]

I think that's the best idea I've heard all day!

Check PM! :)

[Egh]

I think that's the best idea I've heard all day!

Check PM! :)

Looking forward to new vfw build as well! Just please add "no-fast-pskip" option in it as well :)

[foxyshadis]

Looking forward to new vfw build as well! Just please add "no-fast-pskip" option in it as well :)

VFW x264 requests aren't really welcome here, it should be obvious. It's a code-it-yourself-or-ask-privately situation, or risk bond getting banhappy. :p Point integration of minor features is as simple as copy-paste and rename a few things, in the code and the .rc file, you don't need much C expertise for that.

[ChronoCross]

doom9 already said no more vfw threads or feature requests.....he's the owner of the forum.....which is another reason threads that exist for providing stuff for vfw are supposed to be closed.

[Romario]

Well, perhaps he said that, but he can't stop users to post new VFW builds in the future.

Or, there is always Hydrogen Audio forum. Perhaps future x264 vfw builds should post there.

[ChronoCross]

Well, perhaps he said that, but he can't stop users to post new VFW builds in the future.

Or, there is always Hydrogen Audio forum. Perhaps future x264 vfw builds should post there.

I think you should stop advertising other forums here. If you don't like it here get the hell out.

Apparently the cli is too difficult for you.

[DeathTheSheep]

It's alright everybody, calm down now. Be happy! :)

A VfW comes if it comes, and if it does, you'll be the first to know ;)

[celtic_druid]

Don't see why people can't just use an old build. Most people using VfW I doubt would know the difference other than if it is newer it must be better.

[Kurtnoise]

doom9 already said no more vfw threads or feature requests.....he's the owner of the forum.....which is another reason threads that exist for providing stuff for vfw are supposed to be closed.
Calm down with this. You're not a Doom9 admin or mods. Simple users around here are free to ask. And as you can see, the vfw interface is still there in the Doom9 guides.

At last, don't mix up vfw-avc with others vfw interfaces. Otherwhise you can bother DXN, XviD and some others...

[ChronoCross]

Calm down with this. You're not a Doom9 admin or mods. Simple users around here are free to ask. And as you can see, the vfw interface is still there in the Doom9 guides.

At last, don't mix up vfw-avc with others vfw interfaces. Otherwhise you can bother DXN, XviD and some others...

I'm not saying don't use vfw for xvid or divx. but for AVC it's a no no.

Additionally perhaps you should read this:
http://forum.doom9.org/showthread.php?t=105899

So No one is even allowed to ask about new features and or builds. Which is one of the reasons the threads were closed.

[Romario]

A VfW comes if it comes, and if it does, you'll be the first to know ;)

Ok, I looking forward to the near future. Thank you, you are so kind.

Calm down with this. You're not a Doom9 admin or mods. Simple users around here are free to ask. And as you can see, the vfw interface is still there in the Doom9 guides.

You are absolutely right, kurtnoise13. I really don't know why ChronoCross behave like he is a mod:( I noticed his behavior earlier, but it's better not to say anything.

[imcold]

You can still rewrite it to be a generic description of x264 options.

[ChronoCross]

everyone should read this (New rules for vfw discussions):

http://forum.doom9.org/announcement.php?f=77

[Wilbert]

doom9 already said no more vfw threads or feature requests.....he's the owner of the forum.....which is another reason threads that exist for providing stuff for vfw are supposed to be closed.
@ChronoCross, you should stop acting like a mod. doom9 said no more feature requests until a regularily project is being maintained. You can read that in the link your posted. He didn't mention anything about "no more VfW threads". Also nobody asked about a new VfW build, GodofaGap offered to make one on a regularily basis. So, there's nothing wrong with this too.

[bond]

indeed, i now added to the announcement that its enough for a user to point a mod to a post where he thinks that a problem occurs

[Guest]

@ChronoCross

Chill on the rule 4 stuff. Some mod might take offense.

What is an "official project", and who are the officials?

[Romario]

Exactly, who are the officials?

[bananacreamandpeca]

Hi,

I wanted to download and use the free x264 codec.

But, wich is the official untampered release thats not been dev. for a while?
I cannot find it on x264.nl

Or what do you recommend? Any of the further dev. builds perhaps?

[Sharktooth]

There's no stable release for x264. All the builds are dev builds...

[bananacreamandpeca]

Hey sheep, thanks for this guide!
Its a good one. I appreciate it.

1 question: What is vfw?
I think its Video for Windows??????
(dunno why I think its abbreviation means this. never heard of the phrase, it just popped in my brain)
And its a global accessable coder for all application that handle video in a windows environment???

My next question I'm just too affraid too ask.
I read the sticky some days ago.
Questions about builds and where too find them were forbidden i think :rolleyes:

[DeathTheSheep]

Well, VfW (http://en.wikipedia.org/wiki/Video_for_Windows) (a.k.a "VCM" less commonly) is a widely-accepted video encoding framework standard that the vast majority of the world's popular codecs support. It's been around for a good long time now, so it's stable, tried, and true. Infinite freedom, you could say ;) Well, maybe not infinate...

You can check out my project under development here:
http://gabextreme.googlepages.com/x264vfwunited.

New VfW builds every once in a while, the guide will be updated there, there's a forum (tsh...could use some work, certainly). It's not mainstream yet, but you can check it out.

[ChronoCross]

I'm glad you guys continue to screw up the AVC standard. Good job. -_-

[DeathTheSheep]

The preceding message originated from an "MeGUI Enthusiast." You know, the "either you're with us or against us" GUI.

Just so there's no confusion.

PS: No offense CC, we're cool :D

[ChronoCross]

The preceeding message originated from someone who is lazy and continues to support something which will never play on a hardware player and continues to need hacks in order to even encode. But hey why put in any effort to learn something new when you can just go with the old stuff that sorta works.

Ps. No offense DTS, we're cool.

[DeathTheSheep]

LOL nice ;)

[check]

Hi - what licence is this file released under? Is there a changelog? Do you plan on updating this into the future?

[bond]

ChronoCross and DeathTheSheep get a month to rethink what i meant with that the vfw flames and provocations need to end

[G_M_C]

OK a short question;

When someone wants to use X264 with, say, VirtualDub(mod); He has to have a VfW version of X264, does't he ?

And secondly, for using X264 streams in AviSynth a VfW codec has to be available (if one doesnt want to use DirectShowSource). Isn't that true ?

If both above are true, then that would be reason enough for me to want a VfW version. But I'm not exactly shure atm. So do i need this VfW to do what i described, or not ?

[Sharktooth]

x264 is an encoder not a decoder... so you would need x264 VFW for virtualdub but not for avisynth...
However there's a workaround. You can use the vdub frameserving function to edit your video as usual and feed the result to x264 CLI.

[foxyshadis]

He means importing an H.264 stream into avisynth or virtualdub, not exporting. In that case, a vfw codec is required if your source is vfw avc, it's not going to do you a bit of good if it isn't.

I once played with building an mp4/mkv import plugin from the freely available source chunk of haali's splitter, but it was too unfamiliar and I'm not even sure it contained all that I'd need. Maybe if someone asks him really nicely he'll oblige; I'd certainly prefer an MP4Source over DirectShowSource.

The other viable option is making it out of MPC's internal splitters, but gabest is gone, so he can't help anyone with it.

[GodofaGap]

I think an MP4source or MatroskaSource wouldn't be that different from DirectShowSource, since you'd still rely on DirectShow to do decoding. If you want to move away from DirectShowSource, perhaps something like ffmpegSource would be necessary. :)

[Kurtnoise]

iirc, it's doable with avs3 with GstreamerSource...

[bond]

I once played with building an mp4/mkv import plugin from the freely available source chunk of haali's splitter, but it was too unfamiliar and I'm not even sure it contained all that I'd need. Maybe if someone asks him really nicely he'll oblige; I'd certainly prefer an MP4Source over DirectShowSource.

The other viable option is making it out of MPC's internal splitters, but gabest is gone, so he can't help anyone with it.about mp4 parsers

i think haali uses his own parser, gabest uses the bento4 (http://sourceforge.net/projects/bento4) parser. you could also use the parsers in mpeg4ip, gpac, ffmpeg or mplayer. you see there are a lot of opensource ones you could try, choose the one you like best ;)

[G_M_C]

He means importing an H.264 stream into avisynth or virtualdub, not exporting. In that case, a vfw codec is required if your source is vfw avc, it's not going to do you a bit of good if it isn't.

I once played with building an mp4/mkv import plugin from the freely available source chunk of haali's splitter, but it was too unfamiliar and I'm not even sure it contained all that I'd need. Maybe if someone asks him really nicely he'll oblige; I'd certainly prefer an MP4Source over DirectShowSource.

The other viable option is making it out of MPC's internal splitters, but gabest is gone, so he can't help anyone with it.

Exactly what I ment, but I do want to be able to encode stuff in H264 through VirtualDub(mod).

And a new funtion like MP4Source (like AVISource) would be a blessed function imho :) It will make using AviSynth on AVC/H264 clips a lot easier (and more dependable than with DirectShowSource and the grey-frames-"bug").

And ... i'm just used to doing things this way (been using virtualdub for so long now, i couldn't see myself switching easily ... maybe im finaly getting old ;) )

[SergeyFedosov]

My sympathy to DeathTheSheep and CronoCross. By the way, Bond, I presume that you have a car. Do you know, that its engine was described in 1509 and industrially implemented in 1823? Since that time the only progress was associated with new metals, bigger cylinders, some electronics and polished surface. More or less the same about ships, trains, planes, electricity and encoding with VfW. Does this mean that you reject all the above items because of their obsolete technology? I am encoding since appearance of DivX slow/fast motion (was it 1998-1999?) and your position looks pretty bizarre to me.

[check]

The comparison of vfw to an engine is misleading - while the petrol engine has not yet been replaced with a newer version, vfw has. You would be better to compare it to the phase out of leaded petrol in favour of unleaded petrol.

[Egh]

I think an MP4source or MatroskaSource wouldn't be that different from DirectShowSource, since you'd still rely on DirectShow to do decoding. If you want to move away from DirectShowSource, perhaps something like ffmpegSource would be necessary. :)

To wrap up the discussion about alternatives to DSS().

I've spoken with Haali himself on the topic.

To sum up: atm he is not quite interested in the development of either MP4Source() or MKVSource() (or HaaliSource() to handle them all, as I suggested :P)

(But I guess if you beg him he might change his position :P)

He reminds ppl of his tool called mkv2vfr which from recent versions supports AVC video streams as well.

N.B. the reason avc is not quite suitable for VfW is "b-pyramide", this feature, to my knowledge, can't be correctly implemented on VfW.

[Sharktooth]

Exactly what I ment, but I do want to be able to encode stuff in H264 through VirtualDub(mod).
"I want" are not the correct words. If "you want" then do it by yourself.
Pretending is the right way to get just nothing.
And ... i'm just used to doing things this way (been using virtualdub for so long now, i couldn't see myself switching easily ... maybe im finaly getting old ;) )
so long the tools you used to encode are so old they're no longed supported. it's time to learn how to use new tools.
However as i said thousands of times, you can use the Vdub frameserving capability to feed the frames to x264 CLI (or even to megui), so you can get the best of both "worlds".

[tomos]

but how to edit mp4 files? i've tried avidemux but it doesnt work with large files from what i've tried. e.g 7gig file wont open but i cut a small (5mb) sample and that loaded fine.

[Sharktooth]

actually if avidemux doesnt open it, you cant. try splitting the file with mp4box then edit it. When you're done, rejoin the files.
However the problem exists also with AVI files (cant be bigger than 4 gigz) but that's an AVI limitation.

[xyloy]

He's talking about large MP4 files.

so long the tools you used to encode are so old they're no longed supported. it's time to learn how to use new tools.
If a tool works, why trash it... The choice should be left up to the user.

[G_M_C]

"I want" are not the correct words. If "you want" then do it by yourself.
Pretending is the right way to get just nothing.

so long the tools you used to encode are so old they're no longed supported. it's time to learn how to use new tools.
However as i said thousands of times, you can use the Vdub frameserving capability to feed the frames to x264 CLI (or even to megui), so you can get the best of both "worlds".

If you're not able to help me, or just plainly don't want to help, please dont react.

And the other case: Not everybody is from a country where English is the native language. So the "want" thing you are on about just might be some form of translational error, expressing my wish for some workable form of H264 encoding-posibillities in VDmod.

About VD(mod); I just like to work with those tools. They work just fine with my avisynth scripts & XviD encodings, because XviD encoding is the biggest bulk of stuff I do. And there was a new release of VDmod not to long ago, so it's not THAT old.

[DDogg]

G_M_C, take a look at this (http://mewiki.project357.com/wiki/Using_.vdr_files_as_input) and let us know if that is a possible solution for you. We still need to update the information about whether colormatrix comes in to play as frameserving is rgb. Anybody that has a good grasp of that subject can update the wiki (correct, check?) Frameserving from VDM to x264 cli, or one of the GUI's, is a lot simpler than it might sound.

[SergeyFedosov]

G_M_C, just go to the site
http://gabextreme.googlepages.com/x264vfwunited
download x264 VfW and do whatever you wish with the codec and VDub.
A comment. Many inventors often forget about COMPATIBILITY with previously available technique (obsolete but customary). If something was started and became widespread, it is practically impossible to change the habitual way of things. Example: the letters on our keyboards are situated in the most stupid order just because the original typewriters had mechanical problems in typing, let us say, “the”. Yet, none of the attempts to make a more convenient layout succeeded.

[G_M_C]

G_M_C, take a look at this (http://mewiki.project357.com/wiki/Using_.vdr_files_as_input) and let us know if that is a possible solution for you. We still need to update the information about whether colormatrix comes in to play as frameserving is rgb. Anybody that has a good grasp of that subject can update the wiki (correct, check?) Frameserving from VDM to x264 cli, or one of the GUI's, is a lot simpler than it might sound.

G_M_C, just go to the site
http://gabextreme.googlepages.com/x264vfwunited
download x264 VfW and do whatever you wish with the codec and VDub.

A comment. Many inventors often forget about COMPATIBILITY with previously available technique (obsolete but customary). If something was started and became widespread, it is practically impossible to change the habitual way of things. Example: the letters on our keyboards are situated in the most stupid order just because the original typewriters had mechanical problems in typing, let us say, “the”. Yet, none of the attempts to make a more convenient layout succeeded.

This is more or less the thought that occurred to me; Why should backwards compatibillity be thown overboard so easyly ? Think of the fact that (estimated) 80% of video-stuff is done bij amateurs that are happy using the product they got with their camera, wich happens to be based upon VfW codecs.

But enough about this pro vs. con argumenting; I'm gonna make some time of in the next few weeks to set up one of my computers to work with X264/H264. Maybe even try stuff like nVidia's PureVideo decoder and such (on my 7800GS plus). See if I can find out what works best, but from the standpoint that I have to be able to keep using AviSynth and all its filter-possibillities. Thx all for the insight :)

[check]

A comment. Many inventors often forget about COMPATIBILITY with previously available technique (obsolete but customary). If something was started and became widespread, it is practically impossible to change the habitual way of things. Example: the letters on our keyboards are situated in the most stupid order just because the original typewriters had mechanical problems in typing, let us say, “the”. Yet, none of the attempts to make a more convenient layout succeeded.

Another fallacy! Argumentum ad antiquitam - just because we have always done something one way does not mean it is right or correct. Just because it is customary to do things one way in no way validates future choices of similar decisions.
As to the second prong of your argument (change is hard), you forget that examples - by themself - prove nothing.

[GodofaGap]

We still need to update the information about whether colormatrix comes in to play as frameserving is rgb.
You don't need colormatrix, but you will need to use Converttoyv12 with the correct matrix for the encoder.

[Sharktooth]

G_M_C, just go to the site
http://gabextreme.googlepages.com/x264vfwunited
download x264 VfW and do whatever you wish with the codec and VDub.
A comment. Many inventors often forget about COMPATIBILITY with previously available technique (obsolete but customary). If something was started and became widespread, it is practically impossible to change the habitual way of things. Example: the letters on our keyboards are situated in the most stupid order just because the original typewriters had mechanical problems in typing, let us say, “the”. Yet, none of the attempts to make a more convenient layout succeeded.
To make what? A 7Gb AVI? Sorry its not possible...
Think before you speak.

[tomos]

To make what? A 7Gb AVI? Sorry its not possible...
Think before you speak.

7gb avi? yes it is possible. i know since i have one on my drive right now.

[GodofaGap]

Opendml avis can exceed the 2 GB standard AVI limit by a very large amount (~2^64-1 bytes (?))

[Sharktooth]

True, but AFAIK vdub(mod) isnt able to edit them.

[GodofaGap]

You are wrong. It would be pretty silly if VirtualDub couldn't read its own files right?

[Sharktooth]

it may be. it has been... well, a lot of time since i dont use vdub.
however i clearly remember it had problems with huge AVIs. Maybe things have changed with new versions.

[GodofaGap]

If you don't use and don't know a tool, don't talk about it. Very simple.

[xyloy]

Yup, as you said: "think before you speak". :rolleyes:

[Sharktooth]

right... clearly my fault. sorry.

[Egh]

Good way to suit both sides:

very often i do zero pass.

i.e. i haev AVS which I encode in vdub into avi (which could be >100gb since i often do HD resolution), and then use simple bat file to encode with x264 cli.

The only drawback is huge harddrive space required, but it's faster and far more reliable compared to straight-from-avs encoding by x264. If you have second machine the advantages of such approach outweight any drawbacks, making both vfw x264 and even MeGUI redundant.

[bob0r]

Really, you guys shouldn't give bond a reason to strike or ban you..............................





http://x264.nl/bondvfw.gif

[G_M_C]

Well, there just ..... might ..... be a MPEG4/AVC-codec that will be as easy to use as XviD ..... XviD itself :)

Quote from the new site:

The upcoming development branch Xvid 2.0 adds support for MPEG-4 advanced video coding (AVC) de- and encoding up to High Profile and dramatically advances upon the compression performance of earlier Xvid versions.

Taken from this page (http://www.xvid.org/Project-Info.46.0.html) (@ subsection Goals).

Maybe this codec will enable us to keep using our currect software-packages/tools, only requiring updating of the codec.

[DeathTheSheep]

Hey, sorry for the long wait.

A new version of the guide and new VfW builds can be found at my new page: DeathTheSheep United (http://DeathTheSheep.Uni.cc): The ultimate x264 VFW spot has been born!

New version of the guide, new VfW builds, new (small) forum.... What's not to love? Check it out today!

[3ngel]

I have only one question DeathTheSheep:

How do you resolve the fact that using VFW in vdub and being forced to save as mkv, this leads vdub to create a broken mkv resulting in desynched A/V file (for a VFR x264)?

[DeathTheSheep]

How do you resolve the fact that using VFW in vdub and being forced to save as mkv, this leads vdub to create a broken mkv resulting in desynched A/V file (for a VFR x264)?
Emphasis mine
I would personally resolve the fact as so: VfW goes with AVI, not MKV, and "don't use ancient VdubMOD" when it doesn't work right ;)

Seriously, though, if you *really really really really* want your avi busted into an mkv, you'd have to:
1. Rip out video.
2. Mux to mkv.

Yes, it's 2 steps, not 1, so I'd stick with VfW in AVI, if I were you. Or maybe, if I were really you, I wouldn't use VfW at all for my needs (VFR MKVs and whatnot)! In your case, I'd use that excellent GUI made by leiming2006 (or some other chunky GUI to do whatever chunky tasks you might have to do with that kinda chunky stuff).

Well, have fun!

[3ngel]

No, pheraps i havent' explained, or you havent' understood, or pheraps i've not understood ad all your VFW project :)

So, if i've understood, you're talking about VFW for x264 right?
If i have to compress using x264 with more than 0 bframe i have to use mkv because x264 outputs a VFR (variable frame rate) 264 and vdub (not mod) doesn't support mkv at all.
For what i know avi doesn't support VFR.
So in what situation your VFW x264 gui is useful?

EDIT: Anyway, i'll try the leiming2006 gui, thanks.

[DeathTheSheep]

Well, you use it like XviD. It's VfW! The VfW doesn't mess with VFR in the first place (the closest thing to VFR in an AVI is a [D] frame, or N-VOP).

If i have to compress using x264 with more than 0 bframe i have to use mkv
Don't worry, someone is deceiving you. B-frames work fine with VfW and AVI. Check out a sample made with DTS x264 VfW with DEFAULT settings (2 b-frames): http://gabe.xw-h.com/b-frames.avi

Works like a charm, just need a decoder like CoreAVC or ffdshow to play in all DS players!

[3ngel]

Indeed, i had always thought that x264 would work only in MKV (sincerely i hadn't tried to encode in avi myself).
What i've tried is to use VFW x264 (3 bframes) with vdubmod and mkv, and i got desynched AV.
I'll try eventually the same setting with avi and see what happens.

[DeathTheSheep]

Sounds good! Yep, works fine with AVI, ogm, mkv, mp4, etc if you use the right tools. For AVI, some people have reported needing to set audio delay to +100ms due to some kind of B-frame lag, but I haven't noticed anything like it. And certainly not a large-scale desync, either.

Well, tell me about your results once you get them!

Cheers!
DTS

[ChronoCross]

You should note that on your site to only use vdub. Most of the people still using some of the guides for gknot which comes with vdubmod.

vdub has had alot of speed improvements and they should be using it anyway.

Perhaps you could add on some AVI -> xxxformat guides to show people what to do beyond just encoding using vfw.

btw welcome back.

[Egh]

@3ngel : you're not quite right about b-frames.

avc is different to ASP due to the fact it handles b-frames much better and allows consecutive strings of b-frames and stuff.

Yet even with 3 b-frames you can save h264 streams in avi files. But what is bad is the option called b-piramide, true gurus assure that option is not possible to implement in vfw, due to limitations of the interface itself.

The exact reasons for that are quite vague for me, so you need to ask them directly, but I trust their opinion :)

[foxyshadis]

Obviously the fact that it exists and functions in avi proves that it is possible. But if you try to seek around the file, you'll get a variable amount of lag of up to # of b-frames, which can be far more maddening than the constant lag with asp (try using ffdshow-vfw with a packed bitstream file - sometimes it'll lag, sometimes it won't). That and problems splitting within a gop basically break two of vfw's best features, the only one left being extensive compatibility with editing applications.

[Sharktooth]

well, the more advanced the codecs the less the compatibility with old frameworks (VFW and AVI).
The desynching problems are very usual in those situations and using different containers (like MKV) within vdubmod wont change the situation since the bitstream is still produced by a unsupported framework.
To avoid those problems you should:
1) Prefer CBR over ABR and VBR audio
2) Prefer CBR over ABR and VBR video (but thats quite impossible)
3) Do not use b-pyramid...
4) ... or limit the number of b-frames...
5) ... or do not use b-frames at all
6) have I-Frames in coincidence with IDR Frames
7) use a fixed interleaving

As you may understand those limitations will also limit the quality of your encode but if you desperately need virtualdub (or VFW/AVI in general) those restrictions are necessary to maximze streams synchronization in VFW/AVI.

[Egh]

To avoid those problems you should:
1) Prefer CBR over ABR and VBR audio
2) Prefer CBR over ABR and VBR video (but thats quite impossible)
3) Do not use b-pyramid...
4) ... or limit the number of b-frames...
5) ... or do not use b-frames at all
6) have I-Frames in coincidence with IDR Frames
7) use a fixed interleaving

As you may understand those limitations will also limit the quality of your encode but if you desperately need virtualdub (or VFW/AVI in general) those restrictions are necessary to maximze streams synchronization in VFW/AVI.

1) is not a problem in practice 2) you meant VFR i hope? yeah apart from 119.88fps trick avi doesn't support it.
4) 5) h264 with b-frames work very nice in avi (and even ASP mpeg4 has them)

as for 3) it is the only thing, to my knowledge, that really can't be implemented via VfW interface.

[DeathTheSheep]

3) B-pyramid works fine. :) It's the "Use as references" option in the VfW.

[Sharktooth]

1) is not a problem in practice 2) you meant VFR i hope? yeah apart from 119.88fps trick avi doesn't support it.
4) 5) h264 with b-frames work very nice in avi (and even ASP mpeg4 has them)

as for 3) it is the only thing, to my knowledge, that really can't be implemented via VfW interface.
1) is a problem. this is the major cause for audio desynch. you can work around it... infact i said "prefer"...
2) no, i meant what i said. the problem is avi doesnt like VBR streams. also VFR is another issue...
4) and 5) b-frames are "hacked" into avi, so editing video streams with b-frames is a PITA. also the more b-frames you set the more frames you loose... (setting 5 consequent b-frames will kill the last 5 frames of a video...)
3) works but it's a hackery... also do not set too much reference frames when trying to use this option...

However if you want a compliant stream try to respect those points (expecially the 3rd and 5th) or there may be decoders that refuse to decode the video stream, or worse, you may not be able to edit your video at a later time.

[squid_80]

4) and 5) b-frames are "hacked" into avi, so editing video streams with b-frames is a PITA. also the more b-frames you set the more frames you loose... (setting 5 consequent b-frames will kill the last 5 frames of a video...)
Not only do you lose frames from the end, but blank frames (dropped frames) are added to the beginning. Effectively the whole clip is shifted in time by the amount of b-frames which causes audio de-synch like 3ngel wrote about.

[Sharktooth]

exactly. also b-pyramid can be used only for 2 or more b-frames. Otherwise the codec will ignore it.
But as i said, to avoid delays or desynchs, keep the number of Bs as low as possible or dont even use them.

[DeathTheSheep]

...Or delay audio by (Num of B-frames)*(fps).

Or more simply: Add ~25ms (or 30, or whatever your framerate is) for each B-frame you are using. But really, it isn't that necessary-- x264's lag in AVI is hardly noticeable in most cases. And as ST said: Use a fewer number to be safe.

[shon3i]

But really, it isn't that necessary-- x264's lag in AVI is hardly noticeable in most casesAnd in most cases there is not any lag.

[DeathTheSheep]

Precisely. :)

[squid_80]

...Or delay audio by (Num of B-frames)*(fps).

Or more simply: Add ~25ms (or 30, or whatever your framerate is) for each B-frame you are using. But really, it isn't that necessary-- x264's lag in AVI is hardly noticeable in most cases. And as ST said: Use a fewer number to be safe.
Delay audio by (Num of B-frames)*(1/fps). E.g.:
For NTSC Film (23.976fps) frame duration is ~41.7ms
For PAL (25fps) frame duration is 40ms
For NTSC TV (29.97fps) frame duration is ~33.36ms

[akupenguin]

6) have I-Frames in coincidence with IDR Frames
Or just not set the keyframe flag on non-IDR I-frames, just like you do in any other container. If keyframes are set incorrectly, that's just a bug in x264vfw, not a limitation of VfW.

3) works but it's a hackery... also do not set too much reference frames when trying to use this option...
Number of reference frames has nothing to do with any of the limitations of VfW or AVI. The fact that you can use multiple reference frames is what promped H.264 to distinguish between I-frames and IDR-frames. But if you treat keyframes correctly, then it doesn't matter to AVI whether you use 1 ref or 16. And B-pyramid exacerbates the general B-frame problems because it increases the amount of re-ordering, not because it adds referenced B-frames.

[GodofaGap]

2) no, i meant what i said. the problem is avi doesnt like VBR streams.
For video this is absolute nonsense. Setting dwsamplesize to 0 means VBR in AVI and this works fine. There are no problems.

[foxyshadis]

The problem is with editors, not players. For playback, avi just works, once the necessary changes are made to the splitters to seek properly.

However, avi editors are mostly dumb as rocks compared to directshow splitters like haali's and even microsoft's; virtualdub only just recently started supporting vbr, avidemux has for a long time, but premier, AE, aviedit, and all the other avi cutters and editors that I've used just freak out on vbr. Some crash, some output garbage, some timeshift like vdubmod, and so on. This is avi's legacy, and combining that wide support base with avi's loose specs gives a lot of interoperability problems.

[squid_80]

If you put little effort into your avi importing functions and rely on the AVIFile API (which really shouldn't be a bad thing, it is part of win32 after all) you've got no hope when it comes to VBR audio.

[LoRd_MuldeR]

The problem is with editors, not players. For playback, avi just works, once the necessary changes are made to the splitters to seek properly.

However, avi editors are mostly dumb as rocks compared to directshow splitters like haali's and even microsoft's; virtualdub only just recently started supporting vbr, avidemux has for a long time, but premier, AE, aviedit, and all the other avi cutters and editors that I've used just freak out on vbr. Some crash, some output garbage, some timeshift like vdubmod, and so on. This is avi's legacy, and combining that wide support base with avi's loose specs gives a lot of interoperability problems.

Use Avidemux and be happy :D

[DeathTheSheep]

This is VBR audio we're talking about here, right? In terms of video, VBR has been supported since before VfW even came into existence. It practically MUST be VBR.

Anyways, DeathTheSheep United is now http://DeathTheSheep.Uni.cc
Fitting, isn't it? :)

[celtic_druid]

If I recall correctly there was a modified version of avs2avi which could encode via x264 taking bframes into account.

[servass]

I got "Can not Connect VidCompressor To AVIMux..." if I start capturing from tv-card with this x264?
I think I have vfw in use...
Another 264er (lead) run's without error, but on playing the captured video with vlc there is only black noise ...
Has someone a suggestion?

[snow_xmas]

There are many missing in x264vfw encoder. The original version confused "bitrate variability" with "qcomp". it said that if you change the "bitrate variability" to 100, the qcomp will be "1.00". And the "ratetol" is 4.00 forever whatever is set in "bitrate variability".
And "Const Quality" is important too. So I think the source of vfw requires to update.It is not enough that adding "fast p skip" and "DCT Decimate" only. Can the VFW encoder has all of options in MeGUI?

[Irwin]

There are many missing in x264vfw encoder. The original version confused "bitrate variability" with "qcomp". it said that if you change the "bitrate variability" to 100, the qcomp will be "1.00". And the "ratetol" is 4.00 forever whatever is set in "bitrate variability".
And "Const Quality" is important too. So I think the source of vfw requires to update.It is not enough that add "fast p skip" and "DCT Decimate" only. Can the VFW encoder has all of options in MeGUI?

For me x264vfw is best way to encode in h264. DeathThe Sheep when new version?

[snow_xmas]

I have built the newest x264 vfw encoder. Some options what is not in vfw before have been added. And the logo of "x264" have been removed by me because it is a waste of space and useless.
But I can't assure it have no bug. Anyone Who want it may tell me your email and I will post the source and the install package to you.
Let's keep x264 vfw together!

[dtomoyo]

I have built the newest x264 vfw encoder. Some options what is not in vfw before have been added. And the logo of "x264" have been removed by me because it is a waste of space and useless.
But I can't assure it have no bug. Anyone Who want it may tell me your email and I will post the source and the install package to you.
Let's keep x264 vfw together!

e-mail: dtomoyo at empal.com

sorry, wrong email address. ^^;

[Romario]

I have built the newest x264 vfw encoder. Some options what is not in vfw before have been added. And the logo of "x264" have been removed by me because it is a waste of space and useless.
But I can't assure it have no bug. Anyone Who want it may tell me your email and I will post the source and the install package to you.
Let's keep x264 vfw together!

email: akostic5 at yahoo.com

Thank you.

[plane]

Email: ultima0 at yahoo.com

:thanks:

[DarkZell666]

@snow_xmas: Why not just upload your packages to some webhost somewhere and post a link here ? Megaupload or others (not rapidshare plz) are sufficient for that sort of thing, and I bet your ISP offers a small webspace where you can upload your stuff too.

[squid_80]

email: akostic5 at yahoo.com
OT: What a surprise, Kostarum Rex Persia's real name was Aleksandar Kostic.

[shon3i]

@snow_xmas: Why not just upload your packages to some webhost somewhere and post a link here ? Megaupload or others (not rapidshare plz) are sufficient for that sort of thing, and I bet your ISP offers a small webspace where you can upload your stuff too.

Agree, or go to VFW united forum, and post there.

I think now FFdshow VFW x264 encoder is most updated vfw encoder, it supports CQM, but don't have 2pass encoding.

[ChronoCross]

OT: What a surprise, Kostarum Rex Persia's real name was Aleksandar Kostic.


wow that sob was the same person all the time. I wondered why they both had the same opinion and generally were annoying to all developers.

That gets a ban if I remember correctly.

[DarkZell666]

I hope I can upload it but I have no space on internet. I hope you tell me a network station so that I will upload it for share and debug it together.

Check your pm's :)

[DarkZell666]

You'll need an ftp client to upload your package first. You haven't even done that yet. And my webhost (1&1) forbids you from directly opening any url if the directory doesn't have an index.html or an index.php file inside (for privacy/security reasons).

However I'll suggest you try this : http://www.yousendit.com/
or this : http://www.megaupload.com/

Edit: there was a post between this one and my previous one but snow_xmas deleted it :rolleyes:

[DarkZell666]

Opening the url in IE I get an error from mediamax.com, and via firefox I get an empty file (0 byte). Is anyone else in this case ?

Edit: snow_xmas edited his link, now it works.

[Koti]

thx snow_xmas, will check it out.

no problem getting file.

[Irwin]

I have a problem with download this file.
Please upload it on rapidshare.com or other storage www.

[olnima]

Same here. Can not download the file :(

Olnima

[DarkZell666]

Confirmed, it's not working anymore. I get a japanese javascript alert and nothing else.
http://xasonline.info/doom9/x264vfw_japalert.png

Edit: I feel like I'm wrong bashing you, but snow_xmas: will you ever take into consideration the advice that's given to you ? ...
I've given you an ftp access but you don't seem to want to use it, and you've been recommended megaupload/rapidshare/yousendit, so why you keep trying some shady webhost is beyond me ...

Thank you for contributing your efforts though ... :)

[Kurtnoise]

http://www.megaupload.com/?d=2RKG92MK

[DarkZell666]

Thx kurtnoise, I mirrored it here: http://xeoteam.info/x264vfw/x264-r654-install.exe

I would have done so earlier but I inadvertly deleted the package from my desktop earlier today :o

[aiyunyi]

so, what "Constant Quality" mode actually is?

[DarkZell666]

it's CRF ...

[olnima]

Thanks for mirroring!

O.

[_xxl]

The newest vfw has been built. And the logo is added. Quality base can work now.

Can you share please the source code?

[plane]

I have built the newest x264 vfw encoder. Some options what is not in vfw before have been added. And the logo of "x264" have been removed by me because it is a waste of space and useless.
But I can't assure it have no bug. Anyone Who want it may tell me your email and I will post the source and the install package to you.
Let's keep x264 vfw together!

I tried your vfw and I think it's really nice. Can you add the CQM function in your next vfw build, please?

I don't use vfw anymore but it's not a great idea for me to teach some n00b to use like MeGUI, many of em simply just refused to use before they taste out x264+MeGUI because of the complexity of it.

[snow_xmas]

The Bitrate Variance option had something wrong. And the link is failure. I have fixed it and add the vfw_source and the installer to my space.

ENTER (http://free.ys168.com/english.aspx?snow-xmas)

[Underground78]

I mirrored it here : http://underground78.free.fr/x264-vfw-snow_xmas/ because your link seems to be slow ...

[snow_xmas]

How to mirror the link?

[DarkZell666]

@Underground78: free.fr do nasty bandwidth shaping, so anyone that isn't a "Free" subscriber will get a b0rked download rate. I would have uploaded it to my own free.fr webspace if it weren't for that. (but it'll still be faster than ys168.com I guess ^^)

@snow_xmas : mirroring is just the fact of copying a file to another location than it's original location, just in case the original location goes down. Usually it's done via daily mirroring scripts, but sometimes (like here) users do it manually.

[DarkZell666]

Link updated (http://xeoteam.info/x264vfw) with the sources and an index page :p

[Jerry_Sm@rt]

@DarkZell666
those are chinese,not japanese.
@sonw-xmas
the new constant quality mode has different quality index number than cmd crf mode.how to transform it to equal crf quality index number?

[snow_xmas]

@DarkZell666
those are chinese,not japanese.
@sonw-xmas
the new constant quality mode has different quality index number than cmd crf mode.how to transform it to equal crf quality index number?

Although it is different from the CLI. But most people are use to the bigger qualty index number, the higher quality of the object file. In CLI, the quality index number 0 can make a highest quality. I feel that it is too different from most people's habit. So I change it. And the number must be "int", "float" can't be set. so I set the max to 640.

[DarkZell666]

In CLI, the quality index number 0 can make a highest quality. I feel that it is too different from most people's habit.So you actually believe a 0 to 640 scale to be more useable ? If at least it were 0 to 100 I would have understood, but I wonder how we are meant to "guess" what the 0 to 640 stands for. What if I want a CRF 25 encode ? What "value" of yours should I set ? Dude, people on Doom9 encode night and day (rofl), and it's a habit for everyone to have 0 being good quality, and 51 (32 for MPEG4-ASP) to be bad quality. Inventing something "new" and "better" is by nature going against people's habits. Go figure ...I must have missed something again :rolleyes:

[snow_xmas]

But in MeGUI the quality index number can be set from 0.1 to 64. not 100%.Convert it to 100% will make some loss.

I give you a formula.

The quality index number in vfw is "vfw".
The quality index number in CLI is "cli".
vfw=(64.1-cli)*10
cli=(641-vfw)/10

So you can convert the number with the formula.And I will change it to that 0 make a highest quality.

[foxyshadis]

0-64 is a MeGUI bug. Thanks for catching that, btw. It should be 0-51, because it corresponds exactly with the x264 option and anything over 51 will be read as 51.

[snow_xmas]

I have fix the "quality index number" problem. And change the max number is 510.
Enter my space (http://free.ys168.com/english.aspx?snow-xmas)

[DarkZell666]

mirror (http://xeoteam.info/x264vfw) updated :)
Edit: updated again, for some wierd reason the files weren't updated, I needed to delete the old ones and upload the new ones again. Sorry for those that downloaded them these 5 last minutes ;)

[Romario]

I don't speak chinese language, snow_xmas, so I can't do anything on your site. Please provide direct download link to rev 655.

Thanks.

[DarkZell666]

I don't speak chinese language, snow_xmas, so I can't do anything on your site. Please provide direct download link to rev 655.

Thanks.

Jesus Christ, ask for a brain for next christmas will 'ya ? ... making an effort never hurts you know ... :rolleyes:

Just in case, you need to open the address in IE, not in FF, otherwise you get a black page probably saying something like "You must use IE 5.0 or later". I admit it took me some minutes to figure that out ...

Here you go, mirror updated with r655 : http://xeoteam.info/x264vfw/
Edit: 2nd mirror http://xss.xas.free.fr/x264vfw/

[ChronoCross]

I don't speak chinese language, snow_xmas, so I can't do anything on your site. Please provide direct download link to rev 655.

Thanks.

thanks KRP. This thread really needs more people like you.

[leo-nl]

Hi guys, I'm learning to encode AVI with X264vfw since I often record volleyball matches from TV with a DVD-Recorder. Could you guys give me some suggestions of the settings as to get better quallity for a match?

Thanks in advance!

[DarkZell666]

Hi guys, I'm learning to encode AVI with X264vfw since I often record volleyball matches from TV with a DVD-Recorder. Could you guys give me some suggestions of the settings as to get better quallity for a match?

Thanks in advance!

First, welcome to the doom9 forums :)

Second, have you noticed the thread title ? "The x264 guide". The first post even links to a guide related specifically to x264vfw (written by DeathTheSheep himself, the original poster). I think it should be enough to get your started =)

Here, a direct link, just for you :http://gabextreme.googlepages.com/DeathTheSheep_x264_VfW_guide.html

Good luck and have fun reading ;)

[snow_xmas]

Seems I have to create a space in English. How to regist a space in "www.free.fr"? I can't understand French.

[DarkZell666]

You won't be able to register with free.fr since they require you to enter a valid postal address to send you your login & password (in france of course ^^').

Try geocities over at yahoo : http://geocities.yahoo.com/ps/learn2/HowItWorks4_Free.html

I'm not too sure if it's a good alternative or what, but it's free (with ads).

Also, the ftp account I offered you is still open ... (that's where I'm mirroring your stuff right now :rolleyes:), but I'd understand if you wanted total control over your webspace :)

[leo-nl]

Good luck and have fun reading ;)Thanks for the info, DarkZell666. Certainly I've read that thread and I've tried a couple of times. I asked for some suggestions since I thought the settings might be a little different to convert a match than a normal DVD-film.:helpful:

[DarkZell666]

Well, sports in general tend to be very shaky and action-packed, which is naturally hard to compress if you consider how codecs work. If you tried encoding your match at 800kbps hoping for a miracle, you most probably ended up disappointed.

The best you can do is do some extra filtering with avisynth, downsize a bit more if you didn't already, and not expect low bitrates to look good for such a high-motion source.

Using "constant quality" mode (also known as CRF) is your friend if you can't get good-looking results. Use crf 18 (180 in snow_xmas's vfw build) to give yourself an idea of the bitrate needed to get a good picture quality. If you really need a smaller filesize, it's your job to decide wether you'll downsize, just turn the bitrate 10% lower and re-do a second pass, or live with the bigger filesize :)

[snow_xmas]

The newest x264 vfw has been built. Update my english interface space.

[Gromozeka]

The newest x264 vfw has been built. Update my english interface space.

You can make support matrices? For example high detailed elaboration?

[snow_xmas]

Quantizer matrices is so complex that I can hardly add it. If you know how to add it, please tell me.

[Gromozeka]

Quantizer matrices is so complex that I can hardly add it. If you know how to add it, please tell me.

I do not know, but in fact matrices is in XviD! :(
Use matrices often gives a lot of quality

[shon3i]

Quantizer matrices is so complex that I can hardly add it. If you know how to add it, please tell me.
Maybe you can fin answer in ffdshow x264 vfw implementation?

[snow_xmas]

I can hardly understand "quantizer matrix" in the source from x264 CLI. It isn't a simplex evaluate. It need so many array and involve so much knowledge of math. Different codecs may have various own matrix. Only C language cannot finish it well, I Think.

[Gromozeka]

I am afflicted! It is very a pity! It means that in vfw will not be matrices?

[Gromozeka]

Use matrices has appeared in the new version avidemux:
http://www.razorbyte.com.au/avidemux/

[DeathTheSheep]

All right guys, I leave for two weeks for some finals and all this happens when I'm gone. Sheesh :D

First of all, thank you snow_xmas for the spectacular build. You don't have to worry as much about hosting, since I put it on http://DeathTheSheep.Uni.cc/ now for all to download. You are credited right on the main page, of course.

A heck of a lot of new features I'm going to have to work into my guide, right? :)

REVISION 655 IS UP (http://DeathTheSheep.Uni.cc/) based on snow_xmas's fine build and a newer, faster, less buggy decoder for both VfW and DirectShow.

Remember to download the ffdshow version if you have ffdshow installed on your computer!

[daWsOn_s]

hi!

I'm using with VDM this vfw codec since months but...why everybody keeps saying that is better encoding with Megui for example instead of VFW codecs?

:)

[daWsOn_s]

Another question: why is it better using mkv with x264 and double audio tracks than AVI?

[Gromozeka]

That vfw it was equaled Cli it is necessary to finish:
matrices
deadzone inter (for image sharpness)
AQ (from Sharktooh's builds - best for constant quality)
coding on zones

[DarkZell666]

Another question: why is it better using mkv with x264 and double audio tracks than AVI?

The avi format is technically outdated, that's all. It wasn't designed to recieve h.264 and developers need to use hacks to get h.264 into avi (just like XviD and DivX developers hacked avi). People should stop using it, and developers should concentrate on making newer containers more interoperable (it isn't completely the case yet, so I understand that some users still want to stick to avi, especially considering the standalone player's compatibility ... that sucks hard time.). It isn't easy to change millions of user's habits, but that change needs to start somewhere. Mkv and mp4 are simply much more advanced (and new) containers, they have many more possibilities, and they should be used over AVI in the future for everyone's benefit. Also, avi was introduced by MS Windows. It's by "chance" or "good will" that other OS's offer decoding of avi files.
hi!

I'm using with VDM this vfw codec since months but...why everybody keeps saying that is better encoding with Megui for example instead of VFW codecs?

From the developer/technical point of view, it's a burden to maintain apparently. Of course from the user point of view it's the easiest way, and vdub(mod) only uses VFW (other commercial and well-known programs use VFW too, like adobe premiere, vegas, and probably "After Effects"). But any time developers loose maintaining a vfw interface is some time lost for developing new features and fixing other bugs (vfw is a source of bugs itself ...). x264 developers officially dropped vfw support since revision 580. The vfw builds contributed here are 3rd party contributions (thx DeathTheSheep & Kurtnoise, + snow_xmas more recently), so any bugs in the vfw version of x264 should be reported and investigated in this thread first before they are reported to the x264 developers.

[har-vas]

Hello all and congratulations for the support to the VfW interface. I have installed the latest version 655, but I see that it pops-up the well known error message "not compiled with pthread support", when I select 2 threads (I have an FX-60). The result is that the encoding almost doubles the time (CPU load ~55%), which is very annoying. So I would like to ask: When will we have a full-featured x264 VfW build? Is it technically so difficult to support dual-core CPUs (after rev600)? Thanks.

[edogawaconan]

hi!

I'm using with VDM this vfw codec since months but...why everybody keeps saying that is better encoding with Megui for example instead of VFW codecs?

:)

read this (http://forum.doom9.org/showthread.php?s=&threadid=80430), perhaps?

[DarkZell666]

Hello all and congratulations for the support to the VfW interface. I have installed the latest version 655, but I see that it pops-up the well known error message "not compiled with pthread support", when I select 2 threads (I have an FX-60). The result is that the encoding almost doubles the time (CPU load ~55%), which is very annoying. So I would like to ask: When will we have a full-featured x264 VfW build? Is it technically so difficult to support dual-core CPUs (after rev600)? Thanks.

As the error message itself says, it's a compile-time option. This simply means that snow_xmas probably didn't compile x264vfw.dll with the correct options (or to some extent, libx264.dll, which is "wrapped" in x264vfw.dll IIRC). All the multi-core support is there in libx264.dll already ! It needs enabling at compile-time, and linking to the vfw interface (which has been done already by DeathTheSheep IIRC).

@DeathTheSheep: do you have some indications about compiling the vfw version that could be of some help ?

[DarkZell666]

You'll find all you need about pthreads here : http://sourceware.org/pthreads-win32/

It's wierd the r580 built ok though ... but multithreading on x264 has been revisited since then.
Maybe it needs a more recent version of pthreads ? dunno ...

(ps: I haven't compiled c/c++ stuff for years now, sry :o)

[Gromozeka]

http://cef.neuf.fr/x264/

[snow_xmas]

Can't work with multy thread: A huge fault of this vfw encoder. How can I build a Complete one?

[DeathTheSheep]

Gromozeka, did you get the latest VfW to compile with pthreads? It seems like you link to a new version that works; can anyone test this?

[Gromozeka]

Where new version with custom matrices? :rolleyes:
I can testing

[DarkZell666]

It's a compilation option, that's all. If you can compile it dynamically, you can compile it statically too, simply by adding a switch or changing an option. I don't know what switch or option though, it's just the way it works :)

[har-vas]

Hello all. I would like to ask if there is any tested and error-free version of x264 VfW with multicore support. I tried Gromozeka's build, which didn't pop-up the pthreads-related error message, but in TWO different encoding cases (with GKnot of course), it created an error message after the first pass. The error message was about "different number of frames between the first and the second pass" which was irrelevant (in both cases the number of frames was the same and the difference was only and exactly 5 frames)! So obviously this build is buggy. Should I try the 15th-May version of show_xmas or should I have to wait? Thanks.

PS: The support for multicore CPUs is a MUST for a modern encoder, especially when you tune it for best quality. Now I am using the good old rev600 from DTS.

[Egh]

Hello all. I would like to ask if there is any tested and error-free version of x264 VfW with multicore support.

What about cef's builds? He has VFW version as well.

[Gromozeka]

cef's builds dont have many options

[SealTooGreat]

@snow_xmas
Could you implement "--sar" option(it's very useful for anamorphic encoding), and ability to save the options as a preset.
As someone said, matrices and AQ would be great.

edit:
VBV Maximum Bitrate
VBV Buffer size
... When I set numbers in this options and switch to next tab and come back, numbers no longer exist(only zeros). Is it bug or normal behavior?
(rev-655)
edit: "--mvrange" - This option would be great to have in vfw.

[snow_xmas]

Great!! I have built the newest VFW and it can support multy thread. This will become so much faster under the dual-core CPU. But it requires the "pthreadGC2.dll" and I have wrap it to the installer. New build's rev is 656. The bug that SealTooGreat reports has been fixed. And the matrix or other options I will add later(because it is so complex).

[Gromozeka]

And the matrix or other options I will add later(because it is so complex).

We shall wait it :) :) :)
Thanks for new 656 builds. Only it has one bug

http://keep4u.ru/imgs/b/070601/398777e9049f992b06.jpg

[SealTooGreat]

VBV Maximum Bitrate
VBV Buffer size
...When I set all parameters including VBV Maximum Bitrate and VBV Buffer size and close VFW configuration box and than open again in "Videio->Compression.. " in Vdub, all options are the same as I've set, only VBV Maximum Bitrate and VBV Buffer shows "0"
(rev-656)

[snow_xmas]

I have fix the bug of "VBV" and fix some logical fault in my source.
But there is another problem. If you use multy pass melody, enable to update stats file and finish the second pass, you wll see that the second pass stats file is also ".temp". It said that encoder can't rename normally. You must rename it your own. This bug begins at r607. And all of editions before haven't this bug.

[SealTooGreat]

I have fix the bug of "VBV" and fix some logical fault in my source.

So is it normally when I open VFW configuration box that all my options are the same(as I've set it before) but only VBV Maximum Bitrate and VBV Buffer size keep displaying "0". It's annoying to type values for those setting every time I open VFW.

[snow_xmas]

Update vfw again. Nth pass of updating stats file can rename normally. Because I change the kernel source(In fact I don't like change it, But it seems that more than 3 passes encoding can't work well unless do that). It is in "ratecontrol.c", function "x264_ratecontrol_delete()" has a sentence that:
if( h->i_frame >= rc->num_entries - h->param.i_bframe )
if( rename( rc->psz_stat_file_tmpname, h->param.rc.psz_stat_out ) != 0 )
{
x264_log( h, X264_LOG_ERROR, "failed to rename \"%s\" to \"%s\"\n",rc->psz_stat_file_tmpname, h->param.rc.psz_stat_out );
}
x264_free( rc->psz_stat_file_tmpname );
According to nearly all of files, "rename()" is not in a loop and "x264_ratecontrol_delete()" is not in a loop too. So I think that is unnecessary that deciding whether it should execute rename(), and deleted "if( h->i_frame >= rc->num_entries - h->param.i_bframe )". Renaming will not be ignore.

@SealTooGreat :
I use "eo video" and all of that is absolutely normal. Maybe your VDub is working in virtual environment and some value haven't write in reg. Try to run configuration from "start menu" , it will be normal.

[Gromozeka]

snow_xmas
The work on AQ and matrix is planned? :)

[clsid]

Can you statically link pthreads into the x264_vfw.dll?

[SealTooGreat]

@SealTooGreat :
I use "eo video" and all of that is absolutely normal. Maybe your VDub is working in virtual environment and some value haven't write in reg. Try to run configuration from "start menu" , it will be normal.
x264 vfw configuration from "start menu" doesn't help. Do you have any solution how to avoid reseting_to_zero of those options?

[homerpez]

Hello all. I would like to ask if there is any tested and error-free version of x264 VfW with multicore support. I tried Gromozeka's build, which didn't pop-up the pthreads-related error message, but in TWO different encoding cases (with GKnot of course), it created an error message after the first pass. The error message was about "different number of frames between the first and the second pass" which was irrelevant (in both cases the number of frames was the same and the difference was only and exactly 5 frames)!

I just got this exact error in Virtualdub, using snow_xmas's latest build, downloaded today from the site in his signature... This is pretty frustrating... :confused:

It looks like a simple work-around for this is to separate the passes: Perform the first pass, and let it finish (don't run 1st and 2nd passes in the same batch in other words). Then, edit the AVS file to be 5 frames shorter. Then open the new AVS and encode the 2nd pass using that one. It seems to be working (I don't know 100% for certain, but it is processing now and didn't give me that error any longer).

Besides this, I think snow_xmas's is like Chirstmas in June. :) I had no idea that previous builds had multi-thread broken, so I'm pretty happy seeing it fly with 2 threads REALLY working finally. Besides this bug, great job. :thanks:

[har-vas]

Hello all. Snow_xmas, congratulations for your work. I see that there are more options in your builds! It seems that the multicore support is now correct, but I want to report that the problem with 5 frames difference between 1st and 2nd pass is present in your build too. Has something to do with pthreadGC2.dll (which was skipped during the installation, obviously because it was already in system32)? I am asking, because in your previous single-core builds, this problem was absent and was only there in cef's multi-core builds.

I tried to encode with GKnot a 6-minute tv capture and after the first pass, I received this error: "2nd pass has more frames than 1st pass (106869 vs 106864)". Obviously there is an annoying bug in the VfW code. I am always using GKnot for my encodes and it is very uncomfortable to switch to VirtualDub and wait for the first pass to end, then edit the avs and blabla. I hope you can fix that bug. Thanks.

[snow_xmas]

I don't know what you use for converting. But first of all, 1st pass must finish then you can start 2nd pass. If 1st pass haven't finished, it is impossible to start 2nd pass. Because every frame's information of the video segment you want to convert is recorded into x264-1.stats. The number of frames in x264-1.stats must be equal to it in the video segment you want to convert. If there is someting deficiency in x264-1.stats, encoder can't process the frame what are not in x264-1.stats. I use eo video and all of that is normal. And VirtualDub, WinMPG videoconvert too.

[squid_80]

It's probably caused by virtualdub feeding the very last frame into the encoder multiple times to flush out encoded frames that are still being buffered due to b-frame lag i.e. it's a limitation of the vfw framework. Remove the frame number check from the code or don't use b-frames.

[snow_xmas]

I have tried VirtualDUB to convert a 30 seconds video. All of that is normal. Maybe you have to download a newest version of VirtualDub.
R658 have been built.

[SealTooGreat]

@snow_xmas
With new revision(r658) I don't have any "VBV" previous mentioned issue. Thanks

[homerpez]

My gut tells me it's because of the "B" frames issue (though I don't fully understand what that entails, sorry)... it does make sense since it's always just by 5 frames, and only when running mutiple threads.

I'm using practically identical settings on every encode, maybe changing the bitrate, but usually the settings recommended in DeathTheSheep's guide. The only change this time is the threads, then it causes this error... (Older versions of this VFW didn't do this when single threaded, multiple threads weren't working to know).

In any case for me, it really isn't a big deal, since it looks like it's just skipping the final 5 frames. It's easy enough to modify the avs for the second pass, or even just use 2 avs files since the 5 frames seems predictable. The encode I was talking about before worked just fine on the 2nd pass, with the avs modified.

Could be the way V-dub is handling it, but har-vas is saying Gknot does the same thing... so it's probably a bug in V264. Just not a real serious one for me. :)

EDIT: Oops... while I think of it, there actually was one more change I made since installing the new build: I did start using the "WMV DMO" video decoder instead of FFDShow. Is there any chance this would report incorrect frames somehow? (Just want to make sure that's ruled out too)...

[Gromozeka]

You can realize adaptive quantazion (from Sharktooth's builds)?
AQ well works on dark stages and gives high quality on low bitrate

[Koti]

I tried to encode with GKnot a 6-minute tv capture and after the first pass, I received this error: "2nd pass has more frames than 1st pass (106869 vs 106864)". Obviously there is an annoying bug in the VfW code.

Edit - Testing Error
Seems I shouldn't test stuff at 11 PM. I redid my GK test and got the same error with regular first pass selected, I must have changed the multi-threading back to 1 as well when I did the 1st test run last night ( Oooops ). If I use only 1 thread all worked flawlessly , fast 1st pass or regular. looks like multi-threading has a issue in vfw.

[homerpez]

I reproduced the same error using GK
Solution/Workaround was to use "Multipass - First Pass" instead of "Multipass - First Pass (fast)"

That fixes it? That would be awesome if it was only that... I am using First Pass (fast)...

Oh, and on another experiment, I got a number off by 4 frames, not 5. I guess it's not as repeatable as I thought.

But I'll try the normal "First Pass" mode on another one, to see if that solves this issue.

[Koti]

Another observation , the stats file (1st and 2nd) still shows 4 frames short of source but there is no error thrown and 2nd pass continues. Even more fun the resulting avi file has the correct # of frames , 5344 (3 Dummy in the front and 1 masked on the back of the file ) , but hey avc in avi (and vfw) has issues ;)


last note - thank you to snow_xmas for your work on the vfw of x264 :)

[har-vas]

Hello all, hello snow_xmas! Someone has to find a workaround for our problem.
I don't know what you use for converting.
Sorry, but I did reported it.
I tried to encode with GKnot a 6-minute tv capture
I am always using GKnot for my encodes

But first of all, 1st pass must finish then you can start 2nd pass
Obviously, but this is something that GKnot (VDudMod) takes care. I have never had any problem with GKnot in the past. As I said before, something has to do with multithreading and x264 VfW, since only under these circumstances this issue appears.
Maybe you have to download a newest version of VirtualDub.
Please, understand that this is not possible, since the great and very flexible GordianKnot works only with VDubMod, which is abandoned since version 1.5.10.2. Let's try not to confuse VDub 1.7.2 with VDubMod. Besides that, I can't use VDub, because it doesn't support the matroska container (hence vorbis audio, chapters etc).

It's probably caused by virtualdub feeding the very last frame into the encoder multiple times to flush out encoded frames that are still being buffered due to b-frame lag i.e. it's a limitation of the vfw framework. Remove the frame number check from the code or don't use b-frames.
I am not a developer, but that explanation really seems to make sense (but why this is not happening in the single-thread case?). I think that the first recommendation ("Remove the frame number check from the code") would be a quick "solution" in our problem. B-frames are too useful to let them out.
In any case for me, it really isn't a big deal, since it looks like it's just skipping the final 5 frames.
In my opinion, this is a big bug, because it stops me from automating an encoding (which I usually do at nights) or makes me to double the encoding time. For me, encoding is synonym with GordianKnot and I want of course to utilize my FX-60 CPU. Now, practically I can't encode in x264 and I am really close to restore the good old DTS's rev600. I hope that snow_xmas will find a solution for us!

[Koti]

For me, encoding is synonym with GordianKnot and I want of course to utilize my FX-60 CPU. Now, practically I can't encode in x264
VDubMod that GK uses will run avisynth on 1 thread while x264 will run encoding on the other thread , so you will be getting somewhat of a multi-threaded use out of your cpu even while selecting one thread in the vfw configuration options.
because it stops me from automating an encoding
For now using 1 thread is the workaround to automate GK encoding with X264 vfw (unless you go back to older vfw versions that used slices) :)

[snow_xmas]

Oh! Yes. It existed. But my trying is 3 frames. The r607 change so many code for being fast. But many of that is deathful for vfw. Maybe x264's developer stopping to provide vfw is reasonable. But I think if there is no vfw, x264 couldn't be perfect. I will try to fix it although it may be not success. Because only alter the vfw code is not enough.

[Gromozeka]

snow_xmas
You ignore my question:
"You can realize adaptive quantazion (from Sharktooth's builds)?
AQ well works on dark stages and gives high quality on low bitrate"

Adaptive quantazion it is realized in MeGui

http://keep4u.ru/imgs/s/070609/6e3e4dd8b28669854d.jpg (http://keep4u.ru/full/070609/6e3e4dd8b28669854d/jpg)

Elecard converter studio:

http://keep4u.ru/imgs/s/070609/00a6fbcc225bb0f45f.jpg (http://keep4u.ru/full/070609/00a6fbcc225bb0f45f/jpg)

and XviD:

http://keep4u.ru/imgs/s/070609/db2db5c062a4cd5dc3.jpg (http://keep4u.ru/full/070609/db2db5c062a4cd5dc3/jpg)

You can realize AQ in x264 vfw? I think difficulties in it should not be!
Please look here this page:
http://forum.doom9.org/showthread.php?t=89979

[DarkZell666]

Just a quick guess ... Gromozeka = Romario = KRP ? :rolleyes:

[Gromozeka]

DarkZell666
Just a quick guess ... Gromozeka = Romario = KRP ? :rolleyes

Gromozeka is not Romario and not KRP! Who they such?

[snow_xmas]

I have added r606 into my space. This version has no bugs. And move r658 to "x264vfw_Beta". From r607, the encoding melody has changed, encode some frames at the same time. Instead of encode frame by frame. So from r607, Maybe the last frame has finished to process and some others haven't. But while converting soft would stop to process. And in the 1st pass stats file, some frames do not exist. So it will display "2nd pass has more frames than 1st pass".
When developers stop to provide vfw, libx264 code was deserting vfw day after day. Maybe r606 is the last version which can support vfw well.
I have to say sorry to everyone. And I like vfw same to you. I will amend the code as far as possible.

[SealTooGreat]

Maybe I will sound stupid, but is it possible to create VFW wrapper for x264 cli?

[Kurtnoise]

for what for ?

Frankly, vfw should be dropped forever.

[Gromozeka]

Kurtnoise13
Frankly, vfw should be dropped forever.

A ne poshel bi ti podal'she?

[DarkZell666]

A ne poshel bi ti podal'she?

Say what ? ...

[nurbs]

Kurtnoise13


A ne poshel bi ti podal'she?

Say what ? ...


I don't speak that language, but taking similar words from russian my guess would be "Why don't you go far away?"

[SealTooGreat]

for what for ?
Frankly, vfw should be dropped forever.


When developers stop to provide vfw, libx264 code was deserting vfw day after day. Maybe r606 is the last version which can support vfw well.
I have to say sorry to everyone. And I like vfw same to you. I will amend the code as far as possible.

I thought that, for snow_xmas, would be much more productive and easer, focusing on VFW wrapper instead of fixing x264's VFW deserted code.

Kurtnoise13, than you should withdraw support for x264/avi->mp4 in Yamb.

[Gromozeka]

I don't speak that language, but taking similar words from russian my guess would be "Why don't you go far away?"

It means that my opinion does not coincide with its opinion! VFW it is actual!:)

[LoRd_MuldeR]

Kurtnoise13, than you should withdraw support for x264/avi->mp4 in Yamb.

Why? You can create H.264 in AVI with Avidemux very nice without using nasty VFW at all :)
And maybe you still want to be able to remux your files later with YAMB, when you need it for something. You never know...

[DarkZell666]

I thought that, for snow_xmas, would be much more productive and easer, focusing on VFW wrapper instead of fixing x264's VFW deserted code.

Kurtnoise13, than you should withdraw support for x264/avi->mp4 in Yamb.

avi & vfw are 2 different things all together, don't mix them up.
Avi doesn't even depend on vfw in anyway. It's the opposite : vfw seems to only be capable of outputing avi (and I'm probably even saying BS here, lol).

Something's bugging me about the difficulties of maintaining a VFW version though : VFW is just a set of methods a library should implement to be useable by the VFW engine (you find this interface vs. implementation pattern pretty much everywhere in programming nowadays). The vfw wrapper calls the core methods and transforms the results to feed the vfw engine. If the core's method signatures get modified, the vfw wrapper needs to be adapted (I like smashing open doors open ;)), just like the cli wrapper needs adapting (except akupenguin indeed maintains the cli wrapper). Now for the big question .... What modifications did the core recieve that suddenly break the vfw model ? snow_xmas stated multithreading was the cause. Somewhat because the vfw engine wants frame-by-frame information (in the correct order), whereas the x264 core seems to return the frames in the order they finish encoding (which can be different than the movie order, due to multithreading).
But doesn't the core give an identifier or ordering number to each frame it returns ? I suppose it's completely stupid to return some frame handles without saying which goes where isn't it ? How does the cli wrapper actually handle these "unordered frame returns" ?

(Huh, just my 0.02€ right ? Trying to shed some light on this stuff, even if I'll probably get bashed for being stupid ;)).

[foxyshadis]

It's because VFW requires handing back an encoded frame to the muxer before being given the next to encode. You could return a dummy frame, but then you have a frame lag and you lose a frame off the end of the movie. If it takes 20 frames in before x264 hands back a frame, because you went crazy on the references and b-frame settings, then you have that many blank frames in front, plus one or two more for decoding lag.

This is why ffdshow vfw has an internal output module, with alternate formats like mpeg ps.

A cli wrapper would require writing (or incorporating) a demuxer, which wouldn't be the simplest thing in the world.

[Kurtnoise]

Kurtnoise13, than you should withdraw support for x264/avi->mp4 in Yamb.
Exists already...but this step "x264/avi->mp4" doesn't make sense for me honestly.

:stupid:

[snow_xmas]

CLI is excellent, there is no doult. But it must work on avisynth. Avisynth is not almighty. Some of video we can't write into avisynth(e.g movie on PS Game CD). And some of container do not support avisynth so well, maybe if you make it into avisynth, it will be nsynchronous between vedio and audio streams(e.g Real and WMV). But all of that vfw can process it well. In other words, Vfw can do all of what CLI can. Maybe vfw is uncultured. But it is almighty. So I think deserting vfw is unadvisable although CLI is so excellent that it seems to instead of vfw.

[ChronoCross]

CLI is excellent, there is no doult. But it must work on avisynth. Avisynth is not almighty. Some of video we can't write into avisynth(e.g movie on PS Game CD). And some of container do not support avisynth so well, maybe if you make it into avisynth, it will be nsynchronous between vedio and audio streams(e.g Real and WMV). But all of that vfw can process it well. In other words, Vfw can do all of what CLI can. Maybe vfw is uncultured. But it is almighty. So I think deserting vfw is unadvisable although CLI is so excellent that it seems to instead of vfw.

umm yeah avisynth can handle all those streams as well.....you just need to know how to do it.

[Cho]

I'm confused in configuration of the lastest build. From this guide (http://gabextreme.googlepages.com/DeathTheSheep_x264_VfW_guide.html), Bitrate Variability should be set to 60, but it's 4 in the default setting of the lastest build. So, shoulde I change it to 60? or keep it at 4? There are a few more setting which is not mentioned in the guide: Quantizer Compression, Chroma QP Offset, VBV Maximum Bitrate, VBV Buffer Size, VBV Initial Buffer. What should I set those values?

The default setting of configuration windows screen shots are as follow:
http://img502.imageshack.us/img502/5167/x264aom5.th.jpg (http://img502.imageshack.us/my.php?image=x264aom5.jpg) http://img521.imageshack.us/img521/3725/x264bis6.th.jpg (http://img521.imageshack.us/my.php?image=x264bis6.jpg) http://img521.imageshack.us/img521/6362/x264coc8.th.jpg (http://img521.imageshack.us/my.php?image=x264coc8.jpg) http://img505.imageshack.us/img505/1135/x264dym1.th.jpg (http://img505.imageshack.us/my.php?image=x264dym1.jpg)

[Manao]

If a video opens in Virtual Dub, it opens in Avisynth via Avisource. Apart from that, indeed, avisynth-only input in x264 is restrictive, but so is the avi-only input in VirtualDub - which thus still requires avisynth.

Good vertsatile frontends for x264 - in that regard - would be mencoder/ffmpeg, which don't have to rely on avisynth.

[sp@rrow]

Why not add AQ in VfW?? AQ very good help from block on dark / gradient / a little contrast field - and its work is very visible.

[ZenFire]

I dl'd the Standard installer from the DTS site and I get a CRC failure when I run the executable.

[homerpez]

It's because VFW requires handing back an encoded frame to the muxer before being given the next to encode. You could return a dummy frame, but then you have a frame lag and you lose a frame off the end of the movie. If it takes 20 frames in before x264 hands back a frame, because you went crazy on the references and b-frame settings, then you have that many blank frames in front, plus one or two more for decoding lag.

This is why ffdshow vfw has an internal output module, with alternate formats like mpeg ps.

A cli wrapper would require writing (or incorporating) a demuxer, which wouldn't be the simplest thing in the world.

Sorry for my confusion here... does this mean that if I were to encode just the first pass, stop, THEN encode a second/third etc pass separately, then I can avoid the "2nd Pass has more frames than 1st pass" bug? Meaning, it's caused by the automatic starting of pass 2 right after pass 1?

Or is this talking apples and oranges?

[DanielSun]

i can not access to this site

http://deaththesheep.uni.cc/

are their any mirrors ?

[Starks]

x264 VfW doesn't hold a candle to x264 CLI running through MeGUI...

[LoRd_MuldeR]

i can not access to this site

http://deaththesheep.uni.cc/

are their any mirrors ?

http://gabextreme.googlepages.com/x264vfwunited :p

[LoRd_MuldeR]

x264 VfW doesn't hold a candle to x264 CLI running through MeGUI...

nope, but Avidemux does :)

[Gromozeka]

x264 vfw very qualitatively codes! I have checked up its work. Now I use x264 vfw, instead of cli version! If very much it is necessary I can translate avi in mp4 container

[celtic_druid]

I agree.
Gromozeka = Romario = KRP

[Gromozeka]

I agree.
Gromozeka = Romario = KRP

It's not truth! Gromozeka = Igor Tarakanov from Russia

[snow_xmas]

I'm confused in configuration of the lastest build. From this guide (http://gabextreme.googlepages.com/DeathTheSheep_x264_VfW_guide.html), Bitrate Variability should be set to 60, but it's 4 in the default setting of the lastest build. So, shoulde I change it to 60? or keep it at 4? There are a few more setting which is not mentioned in the guide: Quantizer Compression, Chroma QP Offset, VBV Maximum Bitrate, VBV Buffer Size, VBV Initial Buffer. What should I set those values?

The default setting of configuration windows screen shots are as follow:
http://img502.imageshack.us/img502/5167/x264aom5.th.jpg (http://img502.imageshack.us/my.php?image=x264aom5.jpg) http://img521.imageshack.us/img521/3725/x264bis6.th.jpg (http://img521.imageshack.us/my.php?image=x264bis6.jpg) http://img521.imageshack.us/img521/6362/x264coc8.th.jpg (http://img521.imageshack.us/my.php?image=x264coc8.jpg) http://img505.imageshack.us/img505/1135/x264dym1.th.jpg (http://img505.imageshack.us/my.php?image=x264dym1.jpg)

"Bitrate Variability" is not "Bitrate Variance". "Bitrate Variability" is "Quantizer Compression" in megui and I named it same to megui. So "Quantizer Compression" is set to 60. "Bitrate Variance" is the variability of the average bitrate. If it is set so large, Final file's bitrate will be much different from your expectation.

[DarkZell666]

Bitrate Variance is supposed to be called "Rate tolerance" AFAIK.

It's because VFW requires handing back an encoded frame to the muxer before being given the next to encode. You could return a dummy frame, but then you have a frame lag and you lose a frame off the end of the movie. If it takes 20 frames in before x264 hands back a frame, because you went crazy on the references and b-frame settings, then you have that many blank frames in front, plus one or two more for decoding lag.

This is why ffdshow vfw has an internal output module, with alternate formats like mpeg ps.

A cli wrapper would require writing (or incorporating) a demuxer, which wouldn't be the simplest thing in the world.Ouch, that really IS a sufficient reason to drop vfw from a developer point of view .... Out of curiosity, does DirectShow also have this limitation ?

So, it seems any x264 vfw wrapper won't be able to benefit the recent enhancements no matter what ... Adding the missing options to the GUI is all that can be done :rolleyes:

[akupenguin]

If it takes 20 frames in before x264 hands back a frame, because you went crazy on the references and b-frame settings, then you have that many blank frames in front, plus one or two more for decoding lag.
Your conclusion is correct, but references are not a problem. The x264 options that cause i/o delay (and thus incompatibility with vfw) are B-frames and threads.

[foxyshadis]

Ouch, that really IS a sufficient reason to drop vfw from a developer point of view .... Out of curiosity, does DirectShow also have this limitation ?

No, DShow doesn't have any 1-to-1 coupling like that, everything is based on timecodes instead. (Which is how the decoder and renderer can each buffer a varying # of frames and still be in sync, even when the output is out of order!)

Your conclusion is correct, but references are not a problem. The x264 options that cause i/o delay (and thus incompatibility with vfw) are B-frames and threads.

I meant that based on my understanding, it's a thread having to wait on the encoding of a reference frame for a block that causes it to retrieve another input frame, if another thread is already working on it, and I thought this meant that more references meant more contention. But now that I think about it, I guess it doesn't make any real difference, since the frames farthest preceding will tend to be most-coded and thus most rarely, if ever, cause the wait/retrieve. Interesting.

[snow_xmas]

Rev-662 adds a new source file. It is about deblock. Is it very useful?

[Gromozeka]

Rev-662 adds a new source file. It is about deblock. Is it very useful?

I don't used the cli version! :) Please make the version for vfw and I use it for testing

[foxyshadis]

Rev-662 adds a new source file. It is about deblock. Is it very useful?

Not unless you've found a way to use vfw on an older mac. (Or other ppc machine.) Please google altivec, so you'll know what the message means.

[snow_xmas]

Is it really impossible that new version of x264 can't work on vfw? How to modify the source?

[land]

Hi! I'm doing a project and I have to add more options in the vfw. I'm thinking in add matrices, aq, mvrange, zones, ...
I would like to know what options do you consider more importants and if you think that some options must be added even if these options aren't yet in the cli version.
Thanks

[snow_xmas]

@foxyshadis:

You are a menber of Doom9 team. And you must know the inside of x264 very much. So I hit up you pressingly, give me some help. Maybe only you can resurrection x264vfw.

[Gromozeka]

What news about x264 vfw?
Why calm?

[ChronoCross]

What news about x264 vfw?
Why calm?

none. because it's not compatible with the current x264.

[LogicallyGenius]

Its unthinkable that some people blatantly dictate that VFW for x264 is not continued.

Nothing can match VirtualDub today and hence we are forced to use old x264. And over this the developers create command line x264.exe.

What year are they in, 1972 ?

[Theliel]

...

better without comments.

[Gusar]

What year are they in, 1972 ?It's unthinkable that some people think that a console is some outdated technology. Many tasks are done faster at the console and the console is also a lot more flexible than a gui will ever be. Ever heard of shell scripting?

It's also unthinkable how people refuse to believe that VFW simply cannot handle the demands of modern codecs.



I know I shouldn't feed the trolls, but this console=outdated stuff really irks me.

[LogicallyGenius]

Why? You can create H.264 in AVI with Avidemux very nice without using nasty VFW at all :)
And maybe you still want to be able to remux your files later with YAMB, when you need it for something. You never know...

Nasty it may be, but that allows us to use x264 in variety of softwares. So we are not doomed to one softwares mercy.

[LogicallyGenius]

It's unthinkable that some people think that a console is some outdated technology. Many tasks are done faster at the console and the console is also a lot more flexible than a gui will ever be. Ever heard of shell scripting?

So u mean doing things faster is the only criteria ?

Ever heard of new users ?



It's also unthinkable how people refuse to believe that VFW simply cannot handle the demands of modern codecs.

VirtualDub is alive and kicking, as soon as we get a good substitute or that, i will move on to it. Until them x264 is on a big break i guess.


I know I shouldn't feed the trolls, but this console=outdated stuff really irks me.

I feel the same.

The best thing about VirtualDub is that i can put many codecs of my choice, nothing can beat that freedom.

[check]

So u mean doing things faster is the only criteria ?
Ever heard of new users ?
Ever heard of experienced users? :) The logic behind complicated, yet powerful interfaces is simple: you will spend 10% of your time learning it, and 90% using it after. I am happy to have a harder start if it means I have a far more flexible tool to work with later. The proof of the inherent adaptability of the CLI over a GUI is in the pudding: many applications use the x264 CLI (and many more are created each day and thrown away as .bat files), while only a handful use VfW.
It's not just the speed and power, it's the flexibility that makes the commandline so inviting.

[Gusar]

So u mean doing things faster is the only criteria ?

Ever heard of new users ?No, speed is not the only criteria, flexibility is another and probably the most important one. And I said many tasks, not all tasks. Writing a shell script for administrative stuff or batch processing will be much more flexible than clicking through a gui. On the other hand, configuring a codec is probably easier by clicking trough a gui, even though I personally don't see a difference. Guis certainly have their place, that's why MeGui, StaxRip, Avidemux and all the other stuff exists.

What I don't like about your message is the "consoles are a thing of the past" deal, which simply shows ignorance on your part.

x264 has enough users who are willing to learn new stuff (like MeGui or Avidemux or even the commandline), so if you refuse to do the same, the only one being at a disadvantage will be you.


I know I shouldn't feed the trolls, but this console=outdated stuff really irks me.I feel the same.Why do I have the feeling that you didn't understand what my sentence actually means?


Now a serious question: What is missing in MeGui or Avidemux, that you really need?

[DarkZell666]

Now a serious question: What is missing in MeGui or Avidemux, that you really need?I'll second that question and even phrase it in another way : what's vdub got you can't find elsewhere ? If you could make a decent list of what's "missing" for you, maybe it'll be added on someone's TODO list. For real, I'm not kidding, the only way to get things done is to nicely ask for them or do it yourself (which will probably end up being as dirty as DIY most of the time :P).

[Gromozeka]

The person has a choice. At voting for mp4 or avi opinions were divided 55/45% in favour of mp4, but people have freedom of a choice, but development x264vfw has stopped completely!
It is wrong! VirtualDub conveniently works with a sound! VirtualDub allows to break into pieces conveniently. We allocate 50 % of film and it is compressed on first CD, then on second CD). If it is necessary, 2CD it is possible to connect easily together. x264vfw it is used from many programs that does not allow to do Cli. Avi it is easily translated in mkv or a nested doll! I wish to tell what incorrectly to stop

[foxyshadis]

vfw support is available at deaththesheep's forum and will not be available here. That's the entire reason his forum exists, use the resources you're given! If a flamewar brews the thread will be locked, don't stir it up.

[clsid]

ffdshow has an up-to-date version of x264 that can be used through VFW. I don't know if it works properly and if all options are available in the GUI. Give it a try.

Get the xxl build. He is also the one who maintains the x264 stuff in ffdshow, so if you find any bugs/omissions report it to him.

[Gromozeka]

ffdshow has an up-to-date version of x264 that can be used through VFW. I don't know if it works properly and if all options are available in the GUI. Give it a try.

Get the xxl build. He is also the one who maintains the x264 stuff in ffdshow, so if you find any bugs/omissions report it to him.

Superb! ffdshow x264 coding with matrix " high details ", it is impossible x264 ftom snow_xmas builds,
it is impossible to do it in Avidemux! But in ffdshow there are not enough options!

snow_xmas Asked:
Quantizer matrices is so complex that I can hardly add it. If you know how to add it, please tell me.

clsid
You can tell as it to it to realize?

[clsid]

Like I said in my previous post, talk to xxl about it. I don't know anything about it.

[foxyshadis]

Seems to work here. Set Quantization type to custom in the quantizer page, and then load a table in the custom tables. mp4 guy's don't appear to be compatible because he doesn't pad his with spaces, dumb parser, this will be fixed. Sharktooth's, soulhunter's, and some others do work though.

[Gromozeka]

Like I said in my previous post, talk to xxl about it. I don't know anything about it.

clsid
xxl can tell as to do it?
I compressed yours ffdshow, it is the truth - it cannot use matrix for x264. I hope in following release it will be realized in your versions ffdshow and you can tell as to make x264 fvw with matrix :)

[foxyshadis]

You're going to have to be much more specific than "it doesn't work", especially since it works for me and I just gave you the steps to get it working.

[Gromozeka]

But where x264 vfw was added? :)

[DarkZell666]

Before you read the rest of my post, Gromozeka, please realise how careless you are and that you need to change your way of doing things.

Start > Programs > ffdshow > VFW Configuration > Encoder > H.264 (x264)

Then "Quantisation" list item => Quantisation type = "Custom".
Then "Custom Tables" list item => Load Matrix button.

Actually, you don't specifically need "x264 vfw", you just need a VFW frontend to x264's core (which is precisely what ffdshow's VFW wrapper seems to be doing if I understood correctly).

Does this answer your question ?

[Gromozeka]

New - More tiny tweaks. VBV issues addressed.
http://gabextreme.googlepages.com/x264vfwunited

[Gromozeka]

Lav build's has quantazion matrix:
http://www.megaupload.com/?d=ULVUPZEN

[DarkZell666]

Updates mirrored here : http://xeoteam.info/x264vfw/

[Gromozeka]

DarkZell666
Thanks
Please add this:
http://www12.atwiki.jp/lunatilia/pages/70.html
- x264vfw x264vfw encoder Lunatilia build
http://www12.atwiki.jp/lunatilia/?plugin=ref&serial=90
:)

[DarkZell666]

Done :)

[DeathTheSheep]

I like what I'm seeing here. This lav build is rather innovative, displaying parts of my guide as hover-over instructions in the box to the right. Some of my grammar, however, has apparently been "tweaked" for some reason (now: "It can be set this up to 50"...), but that's just nitpicking. :)

Now for some speed/reliability testing!

[Gromozeka]

I like what I'm seeing here. This lav build is rather innovative, displaying parts of my guide as hover-over instructions in the box to the right. Some of my grammar, however, has apparently been "tweaked" for some reason (now: "It can be set this up to 50"...), but that's just nitpicking. :)

Now for some speed/reliability testing!

Lav published him bilds in your forum:
http://dtsunited.20.forumer.com/viewtopic.php?t=100
:)

[Gromozeka]

http://www12.atwiki.jp/lunatilia/pages/70.html
Very very good x264 vfw rev.701 - perfect quality
:)

[Gromozeka]

BugMaster
Hi, all. I am glad to represent you first public version of my x264vfw encoder variant. May be it doesn't have some specific options such as VBV and deadzone-s (I am thinking of adding them later) but it also have some exclusive options (for example, "VD Hack" option fixes B-frames lag (also multithreading lag) when encoding with VirtualDub[Mod]) and a lot of bugfixes (which exists in other x264vfw variants), also it doesn't need pthreadGC2.dll for multithreading support. I will be glad to know your opinions and suggestions for future versions.
Here it is: http://stashbox.org/65245/x264vfw_714bm.exe

[har-vas]

Hi all. Today is a great day for me and also for all of us, the x264 VfW fans. I tried the Gromozeka's x264 encoder and I verified that it seems to work flawlessly! At least the well known problem with GordianKnot when you select multipass and >1 threads, is history (so at last I abandoned the snow xmas's r606). I have to say that I didn't even enable the VD hack checkbox!

I would like to hear from Gromozeka what was the trick he made to achieve that result, I am really curious... Well, I am always using GordianKnot, x264 VfW, multipasses and dual-core CPU, so that bug had driven me crazy! That's why I was using the last error-free build 606. Can you give us some more information about your x264 build?

Also, I would like to ask you if I should set 2 threads or 3 (I have a dual core CPU). I am asking so because I had read somewhere that we should set in x264's thread option "number of CPUs/cores * 1,5". I noticed that when I set 2 threads the CPU load was ~80-85% and only when I set 3 threads the CPU load reached the limits (>99%). A clarification here would be necessary.

The only flaw I noticed has to do with the bitrate in connection with the encoding mode. Here it is: I am setting the desired filesize in GordianKnot and the program calculates the correct video bitrate (as we all know). The problem with that version of x264 is that it doesn't receive that value from GordianKnot. When I come to the point to set the 1st and 2nd pass settings, the encoder is NOT at the Multipass mode but at the "Single Pass Ratefactor..." and when I manually set it to the "Multipass 1st pass" and "Multipass Nth pass" respectively, it enters the default value of 800 kbps (while my encoding is at 1080 kbps for example).

Of course, what I do is to set the calculated bitrate manually to the encoder and then the process starts normally and finishes with great results. I just report this small bug in case it can be fixed. I want to clarify that the other x264 VfW encoders hadn't that problem.

Gromozeka, thank you for this great Christmass gift and I hope that you will find the required time and motivation to continue your work. Congratulations!

[ChronoCross]

BugMaster made the build not Gromozeka. Gromozeka wouldn't be able to explain it to you.

P.S. vfw is outdated and no longer necessary and not supported on newer container formats that actually follow the standard. So continued use of x264 in avi will have almost 0 support when it comes to hardware playback

[Gromozeka]

Gromozeka, thank you for this great Christmass gift and I hope that you will find the required time and motivation to continue your work. Congratulations!
BugMaster made the build not Gromozeka. Gromozeka wouldn't be able to explain it to you.

Yes, Not me
This work from Bugmaster.
Thank's him:
http://dtsunited.20.forumer.com/viewtopic.php?t=3&start=60

avi it is easily packed in mkv by means of mkvtoolnix
Players with support x264 and mkv already are on sale!

[ChronoCross]

Gromozeka, thank you for this great Christmass gift and I hope that you will find the required time and motivation to continue your work. Congratulations!
BugMaster made the build not Gromozeka. Gromozeka wouldn't be able to explain it to you.

Yes, Not me
This work from Bugmaster.
Thank's him:
http://dtsunited.20.forumer.com/viewtopic.php?t=3&start=60

avi it is easily packed in mkv by means of mkvtoolnix
Players with support x264 and mkv already are on sale!

then why do you need avi and vfw in the first place? you could just output to matroska from the cli using one of the 30 thousand gui's that exist now.

[clsid]

Perhaps because those GUIs don't offer the functionality that some VFW based video editing application have.

[MasterNobody]

Hi, All. Here I am (Who didn't understand I am BugMaster). Here is new version of x264vfw: http://stashbox.org/66325/x264vfw_714bm_fix.exe
Changes:
- Hopefully fixed compatibility with GordianKnot
- update to gcc 3.4.5 (previous was compiled with gcc 3.4.2)
- replace nasm 0.98.39 with yasm 0.6.2.1985 (adding of SSE3 optimizations)
- minor changes

[dtomoyo]

Hi, All. Here I am (Who didn't understand I am BugMaster). Here is new version of x264vfw: http://stashbox.org/66325/x264vfw_714bm_fix.exe
Changes:
- Hopefully fixed compatibility with GordianKnot
- update to gcc 3.4.5 (previous was compiled with gcc 3.4.2)
- replace nasm 0.98.39 with yasm 0.6.2.1985 (adding of SSE3 optimizations)
- minor changes

Where can I find modified vfw sources?

[DeathTheSheep]

Ah, sorry to have been away for so long. Yes, thank you very much for the nice holiday gift build! I replied to the thread at the DTSUnited forums, too, finally.

BugMaster, would you mind if I incorporated this into the main page's build with the decoder, etc?

[MasterNobody]

BugMaster, would you mind if I incorporated this into the main page's build with the decoder, etc?
OK

Where can I find modified vfw sources?
Sorry, but for now nowhere. I want to implement all planed features before opening sources for community. So you need to wait some time (I hope not very long, suppose one or two months).

[LoRd_MuldeR]

Sorry, but for now nowhere. I want to implement all planed features before opening sources for community. So you need to wait some time (I hope not very long, suppose one or two months).
Keep in mind that x264 is released under the GNU General Public License.
Hence it's not your decision whether to make modified sources public or not. It's a must do!

The GPL does not give the licensee unlimited redistribution rights. The right to redistribute is granted only if the distribution is licensed under the terms of the GPL and either includes, or unconditionally offers to include at the moment of distribution, the source code. This requirement is known as copyleft.

As soon as you publish any binaries, you will have to publish your sources as well (without limitations).
Not doing so, is clearly a license violation!

[Gromozeka]

LordMurder
Why you speak it? MasterNobody will lay out source codes when will relieve x264 from bug's and realizes him the ideas. Until then to transfer source codes = to brake development. You are not right!
Remove your message! Your message looks as blackmail!

[LoRd_MuldeR]

LordMurder
Why you speak it? MasterNobody will lay out source codes when will relieve x264 from bug's and realizes him the ideas. Until then to transfer source codes = to brake development. You are not right!
Remove your message! Your message looks as blackmail!
That's not blackmail! That's simply what the GNU General Public License defines :)
I did not author the GPL nor did I decide to put x264 under the GPL. You are obviously blaming the wrong person...
My post was just a friendly advice, telling the facts, nothing else :rolleyes:

Also sharing your sources during the development does not hurt the development at all, the opposite is the case!
Or why do you think all the big OpenSource projects are developed on public SVN servers, eh?
The more people investigate the (possibly unfinished) code, the more people can contribute ideas and fixes...

[kumi]

It's not blackmail, it's the terms of the license. He has distributed an x264 binary, and then denied others access to the sourcecode. That's illegal.

[Gromozeka]

LoRd_MuldeR
That's not blackmail! That's simply what the GNU General Public License defines
I did not write the GPL nor did I decide to put x264 under GPL. You are blaming the wrong person...
My post was just a friendly advice, telling the facts, nothing else

:):):) Happy new year
:p:p:p
Это значит - счастливого наступающего тебе года и всем форумчанам of doom's.
Жалаю вам мира и любви. Все остальное второстепено - главное мира и любви!

It's not blackmail, it's the terms of the license. He has distributed an x264 binary, and then denied others access to the sourcecode. That's illegal.

MasterNobody пообещал выложить source code! почему ему нужно лишний раз нопиминать об этом? Вот если бы он сказал что не выложит, тогда и был бы разговор!!!

P.S: I understand English language a little bit, but hardly I speak on it! But to answer it is necessary!

[MasterNobody]

LoRd_MuldeR
OK. I know about GPL. And that I must to make sources publically available. I am only thinking about host provider. Now I am thinking about SourceForge.net but I don't sure have I writes to create new project there which is based on x264 vfw (which was removed after revision 580) without asking x264 author (or I need to ask them)? And also may I distribute x264 binaries also at SF (I am asking that because x264 developers doesn't distribute x264 binaries officially [only unofficial] and I don't sure why). That is why I was asking of some time for this (and because it is early alpha stage of development and the binaries was some sort of Christmas/New Year present). If all of this is OK with SF than I public sources in few days.

P.S. Also what do you think about this (http://www12.atwiki.jp/lunatilia/pages/70.html)? Where are sources there?

[LoRd_MuldeR]

LoRd_MuldeR
OK. I know about GPL. And that I must to make sources publically available. I am only thinking about host provider. Now I am thinking about SourceForge.net but I don't sure have I writes to create new project there which is based on x264 vfw (which was removed after revision 580) without asking x264 author (or I need to ask them)? And also may I distribute x264 binaries also at SF (I am asking that because x264 developers doesn't distribute x264 binaries officially [only unofficial] and I don't sure why). That is why I was asking of some time for this (and because it is early alpha stage of development and the binaries was some sort of Christmas/New Year present). If all of this is OK with SF than I public sources in few days.

I think this makes everything clear now :)

For the time being, you could simply zip your sources, upload them at some free/ad-sponsored webhost and post the links here.

And no, you don't need to ask the original authors of x264 for developing your own fork - as long as you respect the GPL of course.
Though I think it won't hurt to do that. But don't expect any support from them for VFW stuff, they hate VFW now ^^

Last but not least I think the reason why the x264 developers don't offer any official binaries is due to patenting issues...

[MasterNobody]

Last but not least I think the reason why the x264 developers don't offer any official binaries is due to patenting issues...
I suggest that, but not sure does this patenting issues will prevent to distribute my binaries on SF or not.

[LoRd_MuldeR]

I suggest that, but not sure does this patenting issues will prevent to distribute my binaries on SF or not.
I think it's okay as long as you don't redistribute your binaries for commercial purposes.
Various projects do host MPlayer/MEncoder binaries on SF. And we all know MEncoder incorporates x264, Xvid and so on...

[MasterNobody]

I have created new project on SourceForge.net: http://sourceforge.net/projects/x264vfw/
Changes:
- x264 core updated to svn-715
- some optimizations of "Multipass - 1st pass (fast)"
- cosmetic changes (x264 -> x264vfw, homepage, etc)

P.S. Sources are in SVN

[Gromozeka]

BugMaster
с радостью узнал в твоем билде что ты русскоязычный!
вот так всегда - только наши и спасут планету! :)
Спасибо большое за твой билд и возможность писать тебе на русском (вернее твоим родителям наверно :)), а то я в английском не очень силен.
Как я понял, теперь разработчики x264vfw смогут объединится под твоим началом?

Я вот тут успел сделать подробную руссификацию сносок под опции x264vfw:
http://rapidshare.com/files/81611766/714bm_rus.rar.html
Может проверишь на правильность, а то опций много, а не все могут разобраться.
Так же будет удобно многим. Это единственное чем я могу помочь в этом деле
А вот сама руссифицированная dll:
http://rapidshare.com/files/81613011/x264vfw.rar.html
С уважением, Игорь

in english:
BugMaster
With pleasure you have learned in yours build that Russian-speaking!
Here so always - only we also will rescue a planet!
Thanks big for yours build and a possibility to write to you in Russian (is more true to your parents likely), and that I in English am not so strong.
How I have understood, now developers x264vfw can will be united under your beginning?

I here have had time to make comprehensive russification of footnotes under options x264vfw:
http: // rapidshare.com/files //81611766/714bm_rus.rar.html
Can you will check up on correctness, and that is a lot of options, instead of everyone can understand.
As it will be convenient much. This only thing than I can help with this business
And here itself russian dll:
http: // rapidshare.com/files/81613011/x264vfw.rar.html
Respectfully, Igor

[DarkZell666]

Gromozeka, thank you for contributing some active help, but I'll kindly remind you about the rule 13. If you could use an automated translator before posting your message, it would avoid all of us having to do it ourselves.

Here's one of them that supports russian : http://translation2.paralink.com/
It's not perfect, so if you know a better one, use yours :)

[Gromozeka]

DarkZell666
Here's one of them that supports russian : http://translation2.paralink.com/
It's not perfect, so if you know a better one, use yours :)

Thanks - its very well :)
But I installer im my computer translate

[MasterNobody]

Version 2_718bm of x264vfw (http://sourceforge.net/projects/x264vfw/)
Changes:
- x264 core updated to svn-718
- added new option "Use command line" for using x264-style command line options instead of standard GUI options (GordianKnot users must check that this option is unchecked before encoding); for "VD hack" GUI option there is now --vd-hack command line option
- other minor changes

[Gromozeka]

MasterNobody
Version 2_718bm of x264vfw
Command line - functional accuracy. Matrixes fully loading.
Are you may addon in you'r builds AQ from Dark Shikari?
Tranlation's - is good.
Большущая тебе благодарность!!! :)

[Dark Shikari]

MasterNobody
Version 2_718bm of x264vfw
Command line - functional accuracy. Matrixes fully loading.
Are you may addon in you'r builds AQ from Dark Shikari?
Tranlation's - is good.
Большущая тебе благодарность!!! :)My AQ is a bit experimental at the moment, but it probably wouldn't be hard to make a VfW version supporting it.

[MasterNobody]

My AQ is a bit experimental at the moment, but it probably wouldn't be hard to make a VfW version supporting it.There is no problems in adding AQ to VfW version. The only thing that needed is too compile with patched x264lib (VfW code already known about --aq-strength and --aq-sensitivity command line options). But before I will add AQ in my builds somebody (may be I, but later) need to fix some side-effects of current AQ (I think, due to this side-effects AQ patch is not in x264 trunk).

[Dark Shikari]

There is no problems in adding AQ to VfW version. The only thing that needed is too compile with patched x264lib (VfW code already known about --aq-strength and --aq-sensitivity command line options). But before I will add AQ in my builds somebody (may be I, but later) need to fix some side-effects of current AQ (I think, due to this side-effects AQ patch is not in x264 trunk).There are two main AQs... Haali's and mine. Both have their side effects, and while Haali's is a lot weaker and therefore has fewer side effects, it isn't in trunk either.

[pelle412]

I've been trying to access DeathTheSheep's guide for a while now but the site has always exceeded the bandwidth. Is there a possibility for someone to attach the guide to a post here?

Thanks!

[DeathTheSheep]

Looks like it's gotten a little too popular... I'll put the zip as an attachment here, if it will fit.

Can anyone suggest/offer a better free hosting package?

[Dark Shikari]

Looks like it's gotten a little too popular... I'll put the zip as an attachment here, if it will fit.

Can anyone suggest/offer a better free hosting package?Just use Mediafire--reliable with unlimited download/upload and 100MB max file size.

[MasterNobody]

Version 3_719bm of x264vfw (http://sourceforge.net/projects/x264vfw/)
Changes:
- Added option "Extra options" (For those who want to mix standard options and x264-style command line options)
- Fixed impossibility to encode in some applications (for example, TMPGEnc Plus v2.524.63.181) which set lFrameCount == 0 in ICM_COMPRESS_FRAMES_INFO message
- Fixed other minor bugs

[Gromozeka]

Thanks, MASTER
There was trial version VirtualDub with support mkv:
http://216.75.63.164/andrew/VirtualDubMKVout.zip
http://216.75.63.164/andrew/VirtualdubMKVsrc.zip
Discussion is conducted here:
http://forums.virtualdub.org/index.php?act=ST&f=11&t=8904&st=60&

[Gromozeka]

MasterNobody, you can make more longly a line for a command line?
My parameters with by to a matrix do not get :(

[MasterNobody]

Gromozeka
I think current 259 symbols (260 including ending zero) for command line is enough. An it is the standard for real command line in Windows (this mean you can't use longer command line with x264 CLI version). I may suggest you to use "Extra options" instead of full command line. It has the same size 259 symbols but there you need to specify only options for which there is no standard GUI options.

May be you will post your command line which need more than 259 symbols here to look at it.

[LoRd_MuldeR]

MasterNobody, your installer doesn't create working shortcuts on WinXP x64 Edition!


What your installer created is:

Target: »C:\WINDOWS\system32\rundll32.exe x264vfw.dll,Configure«
Start in: »C:\WINDOWS\system32«


What we need on x64 Windows:

Target: »C:\WINDOWS\system32\rundll32.exe x264vfw.dll,Configure«
Start in: »C:\WINDOWS\sysWOW64«


Or alternatively you can use this:

Target: »C:\WINDOWS\system32\rundll32.exe C:\WINDOWS\sysWOW64\x264vfw.dll,Configure«
Start in: »C:\WINDOWS\system32«

[Gromozeka]

MasterNobody
The standart my command line from MeGui (not all):
--crf 18 --ref 10 --bframes 3 --b-pyramid --deblock -2,-1 --partitions all --8x8dct --direct auto --me umh --trellis 2 --subme 7 --mixed-refs --b-rdo --weightb --bime --no-fast-pskip --no-dct-decimate --cqmfile "C:\Program Files\x264GUI-Lite_14-04-2007\Matrices_x264\M4G HRM V2.cfg" --deadzone-inter 6 --deadzone-intra 6

in x264vfw:
--crf 18 --ref 10 --bframes 3 --b-pyramid --deblock -2,-1 --partitions all --8x8dct --direct auto --me umh --trellis 2 --subme 7 --mixed-refs --b-rdo --weightb --bime --no-fast-pskip --no-dct-decimate --cqmfile "C:\Program Files\x264GUI-Lite_14-04-2007\Matric

:confused:

[MasterNobody]

Version 4_720bm of x264vfw (http://sourceforge.net/projects/x264vfw/)
Changes:
- x264 core updated to svn-720
- Fix installation on 64 bit Windows versions
- Increased size of "command line" and "extra options" up to max 4095 symbols

[Gromozeka]

Version 4_720bm of x264vfw (http://sourceforge.net/projects/x264vfw/)
Changes:
- x264 core updated to svn-720
- Fix installation on 64 bit Windows versions
- Increased size of "command line" and "extra options" up to max 4095 symbols

Thanks you for a long command line :)

[MasterNobody]

I compiled x264vfw experimental (http://sourceforge.net/project/showfiles.php?group_id=213809&package_id=257910) build. This x264vfw (http://sourceforge.net/projects/x264vfw/) build was compiled using x264 core with adaptive quantization patch version 0.41 by Dark Shikari (http://forum.doom9.org/showthread.php?t=132760). There is no standard options for adaptive quantization so you need to specify x264-style command line options for using it.

P.S. I will update this builds not regularly (only when Dark Shikari will post new versions of his patch with source diff)

[LoRd_MuldeR]

Thanks :)

Will AQ be enabled by default in the "experimental" build? If not: What "x264-style command line options" do I need to set in particular to enable AQ?

BTW: Variance AQ, Version 0.42 is out ;)

[Dark Shikari]

I compiled x264vfw experimental (http://sourceforge.net/project/showfiles.php?group_id=213809&package_id=257910) build. This x264vfw (http://sourceforge.net/projects/x264vfw/) build was compiled using x264 core with adaptive quantization patch version 0.41 by Dark Shikari (http://forum.doom9.org/showthread.php?t=132760). There is no standard options for adaptive quantization so you need to specify x264-style command line options for using it.

P.S. I will update this builds not regularly (only when Dark Shikari will post new versions of his patch with source diff)Here (http://forum.doom9.org/showpost.php?p=1087716&postcount=144) is the latest 0.42 diff, though its somewhat commented up due to my ripping out of the half-broken lambda-based AQ.

Lambda AQ would fail horribly on high QPs due to a bug that will be difficult to solve.

[MasterNobody]

x264vfw experimental (http://sourceforge.net/project/showfiles.php?group_id=213809&package_id=257910) build was updated to AQ patch version 0.42 by Dark Shikari (slightly modified but must be bit identical (http://stashbox.org/72578/AQ_0.42_mod_diff.zip))
Thanks :)

Will AQ be enabled by default in the "experimental" build? If not: What "x264-style command line options" do I need to set in particular to enable AQ?

BTW: Variance AQ, Version 0.42 is out ;)
No, it not enabled by default. The easiest way to use it is to specify "--aq-strength 1.0" in "Extra options" field (also there is "--aq-sensitivity <float>" option but it is recommended to leave it equal to 0.0 and so use automatic sensitivity)

[LoRd_MuldeR]

No, it not enabled by default. The easiest way to use it is to specify "--aq-strength 1.0" in "Extra options" field (also there is "--aq-sensitivity <float>" option but it is recommended to leave it equal to 0.0 and so use automatic sensitivity)

I see :)

[MasterNobody]

Version 5_736bm and 5_736bm_AQ_0.47 of x264vfw (http://sourceforge.net/projects/x264vfw/)
Changes:
- Added colorspace conversion (removed from x264 svn-733)
- Added support for "tesa" motion estimation
- x264 core updated to svn-736

[Dark Shikari]

x264vfw experimental (http://sourceforge.net/project/showfiles.php?group_id=213809&package_id=257910) build was updated to AQ patch version 0.42 by Dark Shikari (slightly modified but must be bit identical (http://stashbox.org/72578/AQ_0.42_mod_diff.zip))

No, it not enabled by default. The easiest way to use it is to specify "--aq-strength 1.0" in "Extra options" field (also there is "--aq-sensitivity <float>" option but it is recommended to leave it equal to 0.0 and so use automatic sensitivity)Note that now the recommended settings are

--aq-strength 0.5
--aq-sensitivity 13
--qcomp 1.0

[DeathTheSheep]

Sounds reasonable.

I've also updated the main site, linked to bugmaster's sourceforge site, and moved some stuff to a better server. :)

[acro29]

Many many thenks for this one, Very useful guide for noob like myself.
Every thing is explained clearly and good, many many thenks :).

[LoRd_MuldeR]

@DeathTheSheep

Two questions about your guide:
1. You say that Trellis + DCT Decimate might cause trouble, so DCT Decimate should be disabled if Trellis is on
2. You say that Trellis shouldn't be used with CQ/CRF mode, because results are "unpredictable" and the effect on quality might even be "negative"

Is that information still valid with latest x264 ???
It seems most people use Trellis=1 in CRF mode and don't disable DCT Decimate...

[Dark Shikari]

Is that information still valid with latest x264 ???This information was never valid to begin with.

[LoRd_MuldeR]

This information was never valid to begin with.
So what is your opinion on that, please?

Trellis + DCT Decimate is safe? Trellis in CRF mode is usually a good idea?

[Dark Shikari]

So what is your opinion on that, please?As I said, the information is completely wrong and always has been unless there's a change I don't know about.
1. You say that Trellis + DCT Decimate might cause trouble, so DCT Decimate should be disabled if Trellis is onThis makes a slight amount of sense, given that decimate does indeed act after trellis, but I have never seen any problem with the two combined.
2. You say that Trellis shouldn't be used with CQ/CRF mode, because results are "unpredictable" and the effect on quality might even be "negative"This statement, however, is completely nonsensical.

In simple terms: keep dct-decimate on unless you have a very good reason to turn it off. Keep trellis on unless you have a very good reason to turn it off.

[LoRd_MuldeR]

In simple terms: keep dct-decimate on unless you have a very good reason to turn it off. Keep trellis on unless you have a very good reason to turn it off.

That's what I wanted to hear and what I use to do :)

@DeathTheSheep:
Maybe you want to rethink that paragraph in your guide...

[DeathTheSheep]

Hm, yes... I think I based it off of a conversation with manao, bond, et al awhile back where trellis was being argued over by the bigwigs.

I certainly will remove the connection between trellis and and dct decimation now, since suboptimal results have never been proven with actual testing. Trellis does 'tamper' with filesize at a given CQP (usually reducing it, in my experience, which makes sense), but I haven't seen any 'negative gain' myself, for what it's worth.

But then again, I need to do a re-haul of some of the stuff in there and actually update the darn thing to take into account the new stuff in the VfW.

Off the top of my head, I do believe the part about bitrate varience (%) needs adjustment as well. Keep pointing out the problems as you see 'em, folks, since that way the guide will be more informative to all.

[Selur]

@Dark Shikari: Reading your statement it sounds like trellis is a 'always win'-feature, but according to mano:
Trellis is an option that, with a fixed quantizer, or fixed pseudo quality ( crf ), can either raise or lower the quality, and lower or raise the bitrate. But, with a fixed size, trellis raises the quality, and with a fixed quality ( here, quality = PSNR ), trellis reduces the size. (http://forum.doom9.org/showthread.php?t=105904)
trellis 'can either raise or lower the quality'.

Would be nice if this could be explained a bit more detailed since I'm confused. :)

Cu Selur

[Dark Shikari]

@Dark Shikari: Reading your statement it sounds like trellis is a 'always win'-feature, but according to mano:
(http://forum.doom9.org/showthread.php?t=105904)
trellis 'can either raise or lower the quality'.

Would be nice if this could be explained a bit more detailed since I'm confused. :)

Cu SelurThe effect of trellis is always positive PSNR-wise, but not always positive visual quality-wise, since Trellis's lambda might decimate more detail than one would like, and as of the moment, unlike normal deadzone, trellis lambda is not adjustable.

[Manao]

Trellis + constant quantizer can either :
- make a QP 20 encoding looks like a QP 19.5 encoding, with the size of a QP 20 one.
- make a QP 20 encoding having the size of a QP 20.5 encoding, with the looks of a QP 20 one.
- make a QP 20 encoding having the look of a QP 20.5 encoding, with the size of a QP 21 one.
- make a QP 20 encoding having the look of a QP 19 encoding, with the size of a QP 19.5 one.

In all those cases, trellis actually makes you win 0.5 QP. But it also offset the quality/size tradeoff of the quantizer you're using.

The third case is an example of why some people say "trellis can lower quality". They always fail to see that if QP 20 + trellis gives QP 20.5 quality at QP 21 size, then QP 19 + trellis gives QP 19.5 quality at QP 20 size.

Now, always remember that all I say is valid when talking about quality as PSNR. If you're talking about visual quality, it's a completely different matter, and I wouldn't even dream to begin explaining the pros & cons of trellis. Try it, test it, see if you like it.

[Selur]

Okay, so general consent would be that:
1. trellis should help psnr wise, no matter is cq, crf or 2pass encode
2. trellis might slightly change the expected result of cq and crf encodes
right?

[Dark Shikari]

Okay, so general consent would be that:
1. trellis should help psnr wise, no matter is cq, crf or 2pass encode
2. trellis might slightly change the expected result of cq and crf encodes
right?Yes, that's roughly correct.

[Gromozeka]

From Bugmaster

Release Candidate 3 of next version: http://stashbox.org/86884/x264vfw_6rc3_736bm_12271.exe

Changes:
- Added decoder (used ffh264 from ffmpeg project revision 12271)
- Added horizontal scrollbar in log window
- Added minimize and close buttons in log window
- Fixed navigation with cursor buttons and TAB-button in configuration window
- Other minor changes

Please test the decoder before I make the final release (intended on Monday).

P.S. I can't fix decoding delay (lag of 1..2 frames) due the B-frames, so don't post about that.

decoder from Bugmaster only vfw :(

[snow_xmas]

Gromozeka's version is so good.

[snow_xmas]

But how can I download the source?

[MasterNobody]

snow_xmas
It is not Gromozeka's. It is mine (a.k.a. BugMaster). And the sources would be available on Monday (when I release final version with decoder) here: http://sourceforge.net/projects/x264vfw/. For now it is only Release Candidate. And this is some sort of beta-testing (and sources are only on my PC) before final release. So comments about bugs (specially in decoder) are welcomed.

[MasterNobody]

Versions 6_745bm_12293 and 6_745bm_AQ_0.48_12293 of x264vfw (http://sourceforge.net/projects/x264vfw/)
Changes (compare to Release Candidate 3):
- x264 core updated to svn-745
- ffh264 core updated to revision 12293

P.S. Sources available here (http://x264vfw.svn.sourceforge.net/viewvc/x264vfw/)

P.S. They crash on PC's with SSE2 support so they are not recommended. Use previous versions instead.

[Dark Shikari]

Versions 6_745bm_12293 and 6_745bm_AQ_0.48_12293 of x264vfw (http://sourceforge.net/projects/x264vfw/)
Changes (compare to Release Candidate 3):
- x264 core updated to svn-745
- ffh264 core updated to revision 12293

P.S. Sources available here (http://x264vfw.svn.sourceforge.net/viewvc/x264vfw/)Strongly recommend you get revision 746 [SVN was switched to git, so it might take a while for SVN mirror to update] given that 745 has an alignment bug that results in some SSE2 prediction methods crashing.

[MasterNobody]

Strongly recommend you get revision 746 [SVN was switched to git, so it might take a while for SVN mirror to update] given that 745 has an alignment bug that results in some SSE2 prediction methods crashing.
There is no need in this because compiled binaries would be identical except dates (at least my builds that I make for Win32 with gcc 3.4.5 (mingw special) were).

[Dark Shikari]

There is no need in this because compiled binaries would be identical except dates (at least my builds that I make for Win32 with gcc 3.4.5 (mingw special) were).My point was that r745 may crash. Therefore, one should avoid using anything before this diff (http://git.videolan.org/?p=x264.git;a=commit;h=6e55e8a729d59130f479f22ea5d53852b1ae2e1f) but after my SSE2 intra pred commit patch.

[MasterNobody]

Dark Shikari
Today I test them at work (my home PC doesn't support SSE2) and they really crash. But the problem is that latest version from git also crashes. I think it is the problem with compiler. I try to compile with GCC 3.4.5 (mingw special) and GCC 4.2.1-sjlj (mingw32-2) and both crash (x264.exe compiled with 4.2.1-sjlj doesn't crash but codec crash). So now I am searching for new GCC compiler for MinGW (binaries, not sources) which will compile it correctly.

[clsid]

See this topic for a binary of GCC 4.2.3 for mingw:
http://forum.doom9.org/showthread.php?t=108215


GCC 4.2.x has a special attribute for forcing alignment of function arguments:
__attribute__((force_align_arg_pointer))

I dunno if that is useful for the case you guys are talking about. Just FYI.

[Mr VacBob]

If it crashes in predict_8x8_ddl_ssse3 (or something like that), you need a new yasm. gcc is probably fine.

[MasterNobody]

Versions 7_747bm_12304 and 7_747bm_AQ_0.48_12304 of x264vfw (http://sourceforge.net/projects/x264vfw/)
Changes:
- x264 core updated to svn-747 (in fact git-HEAD)
- ffh264 core updated to revision 12304
- GCC updated to 4.2.3 (TDM-1 for MinGW)
- Fixed crash on PC's with SSE2 support

[Gromozeka]

BugMaster
8_757bm_12490[/b] и 8_757bm_AQ_0.48_12490 in x264vfw (http://sourceforge.net/projects/x264vfw/)

Changes:
x264 core updated to revision 757 (git-4d9499b)
ffh264 core updated to revision 12490
Minor changes

[MasterNobody]

9_763bm_12490 and 9_763bm_AQ_0.48_12490 of x264vfw (http://sourceforge.net/projects/x264vfw/)

Changes:
- x264 core updated to revision 763 (git-0949975)
- Increased compatibility with some buggy applications (nsvate/nsvcap)

[jult]

However latest revisions of x264CLI are more powerfull (new options, more output formats, avisynth support, etc.) and even new GUIs appeared (look above) so encoding with CLI is easier and results may be better than VFW.This sentence on this forum causes a lot of misunderstandings about versions of x264vfw. You should change the way this is put. I mean really, the delay for vfw is minimal, if it is there at all. "may be better" is nonsense.

x264vfw is alive and well: http://sourceforge.net/projects/x264vfw/

[Sharktooth]

Please stop posting or commenting on this thread. VFW is NONSENSE since there's no longer OFFICIAL support.
And FYI, yes, x264 CLI produces higher quality encodes than VFW, since AVI is an unoptimal container that doesnt even support h.264 and has a lot of overhead.

[MasterNobody]

Please stop posting or commenting on this thread. VFW is NONSENSE since there's no longer OFFICIAL support.
And FYI, yes, x264 CLI produces higher quality encodes than VFW, since AVI is an unoptimal container that doesnt even support h.264 and has a lot of overhead.
Sorry, but I would disagree with you. Yes, it is not supported by x264 developers team, but this doesn't mean that it is unsupported at all (At least for now it is supported my me [official admin of x264vfw project]. Why you couldn't call this OFFICIAL support? And what is the meaning of OFFICIAL support for you?). About higher quality I also disagree because VfW version generates the same bitstream as CLI version and the overhead is not the quality characteristic (Also who say about AVI? You may use VfW encoder and mux the bitstream in matroska). The only real disadvantage of VfW is problems with encoder delay due to B-frames and mutithreading, which couldn't be fixed without hacks (agreements between codec and encoding application, such as used in VirtualDub for fixing this problem).

[Dark Shikari]

And what is the meaning of OFFICIAL support for you?If it isn't supported by one of the main developers (currently Loren Merritt and me) or someone tasked with the job of supporting it by one of the main developers, the support isn't "official."

[Inventive Software]

Let VFW die already, and stop building and breaking the new optimisations that DS brings. CLI is the new VFW, especially since x264 has native AVS support.

[MasterNobody]

If it isn't supported by one of the main developers (currently Loren Merritt and me) or someone tasked with the job of supporting it by one of the main developers, the support isn't "official."
But if we would use such logic than such applications as AviDemux (and other GUIs that use x264 library) also don't have "official" support but this doesn't mean that this applications are bad and there use is NONSENSE.
Let VFW die already, and stop building and breaking the new optimisations that DS brings.
I don't understand how VFW breaking the new optimizations that DS brings? All his optimizations also exist in my VFW-version. Or you mean by DS not Dark Shikari but DirectShow?

[Dark Shikari]

But if we would use such logic than such applications as AviDemux (and other GUIs that use x264 library) also don't have "official" support but this doesn't mean that this applications are bad and there use is NONSENSE.You are connecting two unrelated concepts here. "Not official" means that its a third-party application, and we aren't responsible for any of it. That doesn't make it inherently bad; it just means that we are not going to help you with it because it isn't our responsibility; its the responsibility of the people who maintain it.

[Gromozeka]

x264 vfw forever
x264 vfw work with graphstudio (http://forum.doom9.org/showthread.php?t=133928&page=6) andh264 stream can put in mkv with ogg and aac, but cli version can not work with graph (directshow), with other video programs and must have avisynth

[MasterNobody]

You are connecting two unrelated concepts here. "Not official" means that its a third-party application, and we aren't responsible for any of it. That doesn't make it inherently bad; it just means that we are not going to help you with it because it isn't our responsibility; its the responsibility of the people who maintain it.
I understand this (and my post want show that x264 and x264vfw is separate projects which has different developers, and so saying that it not supported by one team doesn't mean it is not supported by another). But the first who connect them here is Sharktooth by
VFW is NONSENSE since there's no longer OFFICIAL support.

[ChronoCross]

I understand this (and my post want show that x264 and x264vfw is separate projects which has different developers, and so saying that it not supported by one team doesn't mean it is not supported by another). But the first who connect them here is Sharktooth by

Anything that requires workarounds to use the x264 library shouldn't be encouraged. I'd be immensely happy if they could find a way to make it so that x264 in vfw is impossible.

honestly if your using x264vfw in your project name it's deceiving to the general public. If you really want to be considered your own project you should change it to h264vfw, or AVCvfw. That would prevent vfw users from thinking that it's something that is officially supported by the real developers of x264.


x264 vfw forever
x264 vfw work with graphstudio (http://forum.doom9.org/showthread.php?t=133928&page=6) andh264 stream can put in mkv with ogg and aac, but cli version can not work with graph (directshow), with other video programs and must have avisynth


How about learning good tools rather than muxing something using a graph. To say that vfw is better because you can add ogg and aac using something that is not needed (as mkvtoolnix supports EVERY format that mkv does and is much easier I might add) is rather stupid and not a real reason to say that vfw is good. Graphedit is only useful for discovering decoder pins as there are much better tools for muxing.

But if you enjoy doing things the hard way then more power to you.

[GodofaGap]

Anything that requires workarounds to use the x264 library shouldn't be encouraged. I'd be immensely happy if they could find a way to make it so that x264 in vfw is impossible.
You'd be happy to take away freedom from people?

honestly if your using x264vfw in your project name it's deceiving to the general public. If you really want to be considered your own project you should change it to h264vfw, or AVCvfw. That would prevent vfw users from thinking that it's something that is officially supported by the real developers of x264.
It's not deceiving. It's a VFW front-end for the x264 encoder. It is exactly what it says.

[Shinigami-Sama]

You'd be happy to take away freedom from people?


It's not deceiving. It's a VFW front-end for the x264 encoder. It is exactly what it says.

you're missing the point the REAL x264 doesn't want their name to be sullied by a non-official project that no sane person would use

[GodofaGap]

you're missing the point the REAL x264 doesn't want their name to be sullied by a non-official project that no sane person would use
What they want is completely irrelevant. If they don't want their code to be re-used they should not use the current license.

[DarkZell666]

Keep it simple :
- The x264 devs have officially dropped VFW support, so it's not their problem anymore, they don't have to account for it.
- x264's source code is open for re-use as long as the license terms are respected (and they are).
- VFW has technical limitations which makes accurate implementation a pain in the a** (but not impossible).
- However (and you can't ignore this point), VFW is the most commonly used interface between video editing software and codecs on windows, even in the top-notch prosumer software market.
- CLI is flexible and all, but I bet there's only a handful % of PC users that even know it exists, and even less that know how it works.

When I introduce some friends of mine to x264, telling them how great it is etc., and say "the proper way to encode with x264 is to use the command-line and avisynth", they look at me like I'm a wierdo. Then I talk to them about x264vfw, and they say "thank god, why didn't you say so in the first place ?". I then answer "well, it's not the proper way to do it, software makers often went the cheap way and you could encounter unexpected problems using it", and (not-)surprisingly, they don't have any problems, it works great.

Until everyone who makes video editing software for windows stops sticking to VFW, there's just no other way around VFW to use x264 inside those programs, and there are so many that I find it's a shame to ignore them.

On the other side, we have many GUI's around here (hosted on this very forum !), that are good replacements to VFW-based solutions, but they aren't one-to-one replacements yet.

So, let x264vfw be as it is : a VFW frontend to libx264, nothing more, nothing less. As long as it's stated that that's what it is, the project perfectly has it's place.

[nicko]

DarkZell666

+1

VirtualDub still the best editor for the many of users....x264vfw will survive as its abolition can be profitable only for GUI designers (but this guys are not so stupid to start religious war for this reason :D ).

[LoRd_MuldeR]

DarkZell666

+1

VirtualDub still the best editor for the many of users....x264vfw will survive as its abolition can be profitable only for GUI designers (but this guys are not so stupid to start religious war for this reason :D ).

What about Avidemux? It's neither a GUI to some CLI encoder, nor does it use VFW :rolleyes:

[Dark Shikari]

Until everyone who makes video editing software for windows stops sticking to VFWThey use DirectShow, not Video for Windows.

If they used Video for Windows only, they would not be able to encode WMVs.

I know of very few programs that still support VfW, but don't support DirectShow.

[nicko]

What about Avidemux? It's neither a GUI to some CLI encoder, nor does it use VFW :rolleyes:
I use permanently mkvtoolnix for avi from VirtualDub (mux/demux, aac/ogg/...) with following repeated compression in VirtualDub, sliting video together with aac/ogg/... by no-key frames (in VD-1.8.1), no problems at all. :D

[ChronoCross]

You'd be happy to take away freedom from people?


It's not deceiving. It's a VFW front-end for the x264 encoder. It is exactly what it says.

I'd be happy pointing people in the intelligent direction. It's like having caveman eating raw meat. Wouldn't it be more intelligent to teach them to cook it with fire? Instead of saying the fire is too hard to build I'll just eat this raw meat get sick and die.

IT's decieving in that they think it's an actual x264 supported project. When in reality it's just a hack that every x264 developer has publicly denounced as being incorrect.

[LoRd_MuldeR]

I use permanently mkvtoolnix for avi from VirtualDub (mux/demux, aac/ogg/...) with following repeated compression in VirtualDub, sliting video together with aac/ogg/... by no-key frames (in VD-1.8.1), no problems at all. :D

So? I don't say what you do is bad. I only say Avidemux could do it easier and without using the unpopular (at Doom9's) Video for Windows interface...

[GodofaGap]

I'd be happy pointing people in the intelligent direction.
No that is not what you said. You were considering to forcefully prevent people from doing something. That's not pointing in the right direction.

It's like having caveman eating raw meat. Wouldn't it be more intelligent to teach them to cook it with fire? Instead of saying the fire is too hard to build I'll just eat this raw meat get sick and die.
How does using x264vfw make you go sick and die? How does using x264vfw destroy anything? Make analogies that make sense.


IT's decieving in that they think it's an actual x264 supported project.
How can you even pretend to know what everybody else is thinking? Your claim to the name x264 is simply nonsense.

[nicko]

So? I don't say what you do is bad. I only say Avidemux could do it easier and without using the unpopular (at Doom9's) Video for Windows interface...
Good for information.
You mean Avidemux can not work with vfw-files?
In spite of this mkvtoolnix can work with all tipes of video (CLI, vfw).

It is possible to slit video by no-key frames in Avidemux?

[ChronoCross]

No that is not what you said. You were considering to forcefully prevent people from doing something. That's not pointing in the right direction.



It is when people are too ignorant to listen.


How does using x264vfw make you go sick and die? How does using x264vfw destroy anything? Make analogies that make sense.


x264vfw makes it much more difficult to get people to do things the correct way. It destroys peoples will to learn the correct way of doing things killing themselves mentally. You missed the entire point in that VFW is not the correct way to do AVC like eating raw meat. Even Divx is going to stop using it for their AVC codec (see their beta thread).


How can you even pretend to know what everybody else is thinking? Your claim to the name x264 is simply nonsense.

Easily. Every time I help someone with x264 their using the retarded vfw interface thinking it's officially supported and then wonder why they have such a difficult time with their encodes and why none of the tutorials they have found show his config screen. Pointing them to the cli and proper encoding methods is something that I do quite frequently so I can gather from that what people are thinking.

The only nonsense here is using the editing excuse to keep vfw as 98% of the people that use the vfw interface are doing encoding straight through and not doing any editing whatsoever. There are also plenty of other ways to edit files without using vfw.

[Wilbert]

Two pages of comments which have nothing to do with the original topic of this thread. Could you guy(s) stop bitching about vfw and get back to the original topic?

[Sharktooth]

couldnt agree more. stop feeding the trolls. i already did it long time ago. however, even trolls are free to do what they want. so, leave them alone.

[GodofaGap]

Edited per request of Wilbert.

[LoRd_MuldeR]

You mean Avidemux can not work with vfw-files?

There is no such thing as "vfw-files" :confused:

Avidemux can open files that were created with VFW codecs, yes. But it will not use VFW codecs to decode them!
Instead Avidemux will use it's own "built-in" decoders to do those files. Of course you can only files in Avidemux if the video format is support.
Nevertheless Avidemux should be able handle all audio/video formats you need...

The same applies to encoding: Avidemux uses only it's "built-in" encoders. It will not use any VFW codecs, such as DivX.
Encoders "built-in" in Avidemux are: Xvid, x264, mpeg2enc plus a bunch of encoder from "libavcodec" (e.g. ffHuffYUV, ffv1, DV and MJPEG).

It is possible to slit video by no-key frames in Avidemux?

No tool can split a file at no-key frames without re-encoding at least a part of the video. It's just impossible :rolleyes:

However Avidemux can use "Smart Encoding", so if you cut at a non-key frame, it will only re-encode the frames before the very fist key-frame.
This usually are just a few frames at the beginning of your selection. All the rest will be copied 1:1 from the original...

[nicko]

to LoRd_MuldeR

Avidemux looks nice,

No better and no worse than VirtulDub (I hope Avidemux have a possibility to see a decompressed video during the coding online? :) ).

Not bad replacement, if for the some reason in future I will replace vfw with cli.
But it seems while the weighty reasons is not present. While new vfw work much more stable than cli (I have not detected yet any bugs in a new vfw-builds from BM... ;) )

[LoRd_MuldeR]

Avidemux doesn't preview the video while encoding, if that is what you meant :confused:

And to make it clear again:
Just because Avidemux doesn't use VFW codecs, this doesn't mean it uses CLI encoders. It uses neither VFW nor CLI ;)

[nicko]

Avidemux doesn't preview the video while encoding, if that is what you meant :confused:

No I mean not only preview, but decompressed preview, it is a most important difference (for example between VirtualDub-1.8.1 and VirtualDubMod/VirtualDub-1.7..) for me...

OK, I'll stay with old fashion VD ;)

[LoRd_MuldeR]

No I mean not only preview, but decompressed preview, it is a most important difference (for example between VirtualDub-1.8.1 and VirtualDubMod/VirtualDub-1.7..) for me...

OK, I'll stay with old fashion VD ;)

If you want to preview the compressed video with Avidemux while encoding, you can simply play the (incomplete) output file in a suitable player :p

This works 100% fine with MPlayer and VLC Player. It fails with MPC, because MPC seems to require "exclusive access" on the file...

[nicko]

If you want to preview the compressed video with Avidemux while encoding, you can simply play the (incomplete) output file in a suitable player :p

This works 100% fine with MPlayer and VLC Player. It fails with MPC, because MPC seems to require "exclusive access" on the file...
Important not to play encoded file, but to compare it fraime by frame with original during the procecces.
But if it needs additional softvare, than better to stay on the most all-in-one (VD). ;)

PS For many reason I do not like to use VLC

[Sharktooth]

@lord: my previous comment is valid for you too. when they'll be tired to eat crap they'll look for some genuine food.

[ChronoCross]

@lord: my previous comment is valid for you too. when they'll be tired to eat crap they'll look for some genuine food.

ha. Good one.

[GodofaGap]

couldnt agree more. stop feeding the trolls. i already did it long time ago. however, even trolls are free to do what they want. so, leave them alone.
It's funny how you continue to troll anyway. :)

@lord: my previous comment is valid for you too. when they'll be tired to eat crap they'll look for some genuine food.

[ChronoCross]

It's funny how you continue to troll anyway. :)

pot calling kettle black.

[GodofaGap]

pot calling kettle black.
Same to you buddy. At least I'm not the one calling people I don't know ignorant for no reason or tries to take away their freedom.

[LoRd_MuldeR]

@lord: my previous comment is valid for you too. when they'll be tired to eat crap they'll look for some genuine food.

Please explain this comment, thank you.

[ChronoCross]

Same to you buddy. At least I'm not the one calling people I don't know ignorant for no reason or tries to take away their freedom.

You talk like if vfw ends your going to be in shackles and taken off to a death camp. You free to do what you want. If you want to keep using vfw that's great. Just don't expect to be able to use the latest libraries. It's like expecting Windows 3.1 to be able to play the latest games and media. There is a reason it's no longer updated.

As for me thinking people I don't know are ignorant, if they use vfw they are ignorant in my book. That is my opinion and I have the Freedom to say so.

[ChronoCross]

Please explain this comment, thank you.

He means your wasting your time trying to convince them that AVIdemux is good. The more you explain the more that the VFW person is going to try and prove how much better VFW is.

At least that was my interpretation.

[Wilbert]

Like i said:
Two pages of comments which have nothing to do with the original topic of this thread. Could you guy(s) stop bitching about vfw and get back to the original topic?
I guess i wasn't clear enough. The next one(s) who posts a non-relevant comment does get a ticket.

[nicko]

Wilbert
+1 :)

@lord: my previous comment is valid for you too. when they'll be tired to eat crap they'll look for some genuine food.
Be care with words, the best on the present day metric 4 (I hope you already heard about it...) for combination with VAQ2 and many other "genuine" things and builds .... :D has come from vfw-builder....:rolleyes: Such words looks like a spit in to extended hand.




The last vfw version which contain new metrics 4 and 5.
4 - is a most interesting metric, imho, real break-through for prolongation of VAQ2 strategy, as it save from 5% to 12% of bitrate in comparison with metric 3

http://stashbox.org/143317/x264vfw_13_889bm_VAQ3mod_PsyRDO_13801.exe

PS
O sorry, for cli-people BugMaster has made a present too :D
http://stashbox.org/143318/x264_CLI_889bm_VAQ3mod_PsyRDO.zip

[Sharktooth]

can we discuss patches in the appropriate place?
there is a thread for VAQ. this is x264 VFW thread and it has NOTHING in common with patches for x264 core.
VFW is an interface, as API, CLI or DirectShow or whatever. Since VFW is no longer mantained in the x264 official repo or by the x264 official devs, this thread exists form the ppl that want to mantain a VFW interface for x264.
FYI i submitted some VFW patches too (that was some years ago when VFW was in the main x264 repo) that were committed to the x264 SVN. But at that time there were no tools or editors based on x264 API or CLI.

[Dark Shikari]

The last vfw version which contain new metrics 4 and 5.
4 - is a most interesting metric, imho, real break-through for prolongation of VAQ2 strategy, as it save from 5% to 12% of bitrate in comparison with metric 3Unless I'm mistaken, metric 4 is mathematically equivalent to metric 0 except with a constant multiplier... its equivalent to raising AQ strength :p

Also known as --placebo.

[nicko]

Unless I'm mistaken, metric 4 is mathematically equivalent to metric 0 except with a constant multiplier... its equivalent to raising AQ strength :p

Also known as --placebo.
I am afraid you mistaken, BM told me ony that it is next revision of metric 3.

From my test this metric dramaticaly increse the useful range for VAQ2 strength without artefacts, in some cases I have got no limitation for SSIM (artefacts) with strength (more than 2,5), degradated only PSNR.

But I only test it, lets wait his explanation.

[Dark Shikari]

I am afraid you mistaken, BM told me ony that it is next revision of metric 3.

From my test this metric dramaticaly increse the useful range for VAQ2 strength without artefacts, in some cases I have got no limitation for SSIM and artefacts with strength (more than 2,5), degradated only PSNR.

But I only test it, lets wait his explanation.I read the code, I know what it does ;)

(Sum of squared pixels) - (Average(pixels)^2) == Variance(pixels) == Sum((pixel - average)^2)

They're all difference mathematical methods of expressing the same thing. It isn't at all related to metric 3 in any way; it doesn't use an overlapped window.

[nicko]

I believe you (personal thanks you for VAQ2! I use it constantly :) ) but probably especially complex mathematic here is not necessary..?

How to explain such advantage between 4-th and 3-rd metric (0-metrics give me quite another sensitivity range, which shift my codec setup dramaticaly). Your judgement is very interesting.

[Dark Shikari]

I believe you (personal thanks you for VAQ2! I use it constantly :) ) but probably especially complex mathematic here is not necessary..?Note I am not 100% certain about what I'm saying here, but all my common sense tells me that I'm right (but who knows how trustworthy that is?)How to explain such advantage between 4-th and 3-rd metric (0-metrics give me quite another sensitivity range, which shift my codec setup). Your judgement is very interesting.I'm going to guess that if you took the 0 metric and raised the strength accordingly you could probably duplicate the results of the 4th metric.

[nicko]

I'm going to guess that if you took the 0 metric and raised the strength accordingly you could probably duplicate the results of the 4th metric.
In some sense I can experimentaly convince you words :) , but only in same sense :
in first case (metric 0) sensitivity 9.25, second (metric 4) 9.8616, strengts in both cases =1, 750 frames 688x512
vaq3-1-9.25-metric0.avi
x264vfw [info]: SSIM Mean Y:0.9707008
x264vfw [info]: PSNR Mean Y:37.713 U:41.171 V:43.302 Avg:38.725 Global:38.246 kb/s:539.71

vaq3-1-9.8616-metric4.avi
x264vfw [info]: SSIM Mean Y:0.9712587
x264vfw [info]: PSNR Mean Y:37.566 U:41.148 V:43.304 Avg:38.598 Global:38.129 kb/s:539.71

But for several reason I still prefere metrics-4 :)

[Dark Shikari]

In some sense I can experimentaly convince you words :) But you kept the strength constant, completely ignoring what I said.

[nicko]

But you kept the strength constant, completely ignoring what I said.
Sorry, as I told only in "some sense" about maximum proximity of 0 & 4-metric, as this test I made ~ week ago, and in that time I have no idea about you idea :)

For you idea I need time, to fit a bitrate....and so on, sorry, no earlier than tomorrow (this my computer not for testing, only mail-server). :)
But idea is interesting.

Nice to speak with you :)

OK, Tomorrow lets prolongate here https://forum.doom9.org/showthread.php?t=136445&page=6 ...

[Sharktooth]

... there's still https://forum.doom9.org/showthread.php?t=136445&page=6 ...

[jult]

What they want is completely irrelevant. If they don't want their code to be re-used they should not use the current license.Exactly.

I will use x264.exe on Windows machines. And I don't really see what the big fuss is about with VfW. Now I read that the "CLI version" is *not* considered VfW.
Well then, if that is the case:

Point us to the correct and useful win32/x64 binary we can use on the commandline shell, via WSH or VBscript or what not, because I for one certainly am not going to use some non-win32/x64 OS *just* to be able to encode using x264.

[Dark Shikari]

Point us to the correct and useful win32/x64 binary we can use on the commandline shell, via WSH or VBscript or what not, because I for one certainly am not going to use some non-win32/x64 OS *just* to be able to encode using x264.I don't see how this is related to the topic--people are saying you should use the Windows commandline encoder instead of the Windows VfW encoder. Where in the world do alternate operating systems even enter the discussion, except perhaps through your post? :p

[jult]

I don't see how this is related to the topic--people are saying you should use the Windows commandline encoder instead of the Windows VfW encoder. Where in the world do alternate operating systems even enter the discussion, except perhaps through your post? :pEehm.. how can it be that when I use x264.exe from the x264vfw sourceforge page I mentioned earlier is the one most tools use for their CLI encoding in Windows?

I think the abbreviation "video for Windows" is way too broad for what it ends up being then.

Call me crazy, but when I look at the first post in this thread it is really quite unclear what binary I should get for my CLI usage, other than the x264vfw one I mostly use.

[fbgd]

Eehm.. how can it be that when I use x264.exe from the x264vfw sourceforge page I mentioned earlier is the one most tools use for their CLI encoding in Windows?

I think the abbreviation "video for Windows" is way too broad for what it ends up being then.

Call me crazy, but when I look at the first post in this thread it is really quite unclear what binary I should get for my CLI usage, other than the x264vfw one I mostly use.
If you're doing encoding from the command line why would you not just use a x264.exe compiled from the official git?

It also sounds like you're a little confused about what "Video For Windows" actually is. I don't know a ton about it but as far as I know it is a video api in windows that programs can use to encode or play video for instance. I think one would want to use x264vfw if you wanted to encode using a program like virtualdub that uses the vfw interface. Someone correct me if I'm wrong.

[LoRd_MuldeR]

It also sounds like you're a little confused about what "Video For Windows" actually is. I don't know a ton about it but as far as I know it is a video api in windows that programs can use to encode or play video for instance. I think one would want to use x264vfw if you wanted to encode using a program like virtualdub that uses the vfw interface. Someone correct me if I'm wrong.

That is correct. "Video for Windows" (VfW) is an API. It's used for communication between host applications (e.g. VirtualDub) and VfW Codecs (e.g. DivX).

VfW has one big advantage: Every VfW-enabled application can use every VfW-based Codec installed on your computer.
But it also has a huge disadvantage: It dates back to Windows 3.1 and thus is completely outdated nowadays. Thus it was replaced by DirectShow.

For example VfW has a strict "one frame in, one frame out" limitation, which unfortunately is incompatible to the concept of B-Frames.
Various "hacks" have been invented to circumvent the limitations of VfW, but new problems occur...

And take care: Although applications that use VfW create AVI files in most cases, the limitations of VfW must not be mixed-up with the limitations of AVI.
The AVI container also has certain limitations, but these are not directly related to VfW. You can create AVI's without using VfW...

[Dark Shikari]

The latest CLI encoders can be procured from Jarod's site (http://www.x264.nl).Eehm.. how can it be that when I use x264.exe from the x264vfw sourceforge page I mentioned earlier is the one most tools use for their CLI encoding in Windows?Um... the VFW encoder is graphical, not CLI, and can only be accessed through apps such as Virtualdub. I don't know any x264 GUI that uses the VfW encoder.

[LoRd_MuldeR]

Um... the VFW encoder is graphical, not CLI, and can only be accessed through apps such as Virtualdub.
Well, even a CLI application can use VfW Codecs, although VfW Codecs obviously are not intended for that purpose (graphical configuration dialog).
For example MEncoder can use VfW Codecs (-ovc vfw), but you'll need to use a special tool to configure the codec in advance...

[clsid]

I think he confused the installer with a CLI?

[Sharktooth]

yes, that's why there are stickies....

[jult]

yes, that's why there are stickies....Sorry, but those didn't explain this part for me. Not in a wording I would understand anyway. Maybe now they do, but when I started writing about VfW in this hread, the first post was a LOT different.

I do use Sony Vegas and Virtualdub with x264 a lot, with the x264-GUI, and for that I had to have the VfW version. Saving files as x264 singleplass lossless is a quick and logical solution for me when transfering video from one to the other app.

I wasn't aware that the x264.exe compiled from the official git is to be used for Win32/x64 command line usage. In fact, until today, I was under the impression all the x264.exe files I have on my machines did NOT come from the official git and are VfW releases.
Sorry for the confusion.

[Sharktooth]

why not?
x264 VFW (no longer officially supported - mantained by third party developers):

DOWNLOAD
...

However latest revisions of x264CLI are more powerfull (new options, more output formats, avisynth support, etc.) and even new GUIs appeared (look above) so encoding with CLI is easier and results may be better than VFW.
etc... read again the sticky.
if ppl dont know what the words CLI or VFW mean then they need to :search: or google...

[jult]

if ppl dont know what the words CLI or VFW mean then they need to :search: or google...First of all, CLI and VfW are not "words", they are abbreviations. Second, as stated, "Video for Windows" already *has* a meaning, namely: video for windows. Using a commandline tool in Windows that generates video, is using a video for windows tool. I'm not the one who says they have a 'special hidden meaning' that is somehow not explained by the words themselves. If they do have some kind of hidden meaning, people should explain this when they use these words.

[Sharktooth]

abbreviations... whatever... they're common in encoding world. VFW is a microsoft invention to abbreviate the name of an ancient tech (never updated) born in the times of the 16 bit windows versions... Video For Windows, CLI is a more general abbreviation for Command Line Interface.
First of all, CLI and VfW are not "words", they are abbreviations. Second, as stated, "Video for Windows" already *has* a meaning, namely: video for windows. Using a commandline tool in Windows that generates video, is using a video for windows tool. I'm not the one who says they have a 'special hidden meaning' that is somehow not explained by the words themselves. If they do have some kind of hidden meaning, people should explain this when they use these words.
completely false, document yourself.

[Dark Shikari]

video for windows. Using a commandline tool in Windows that generates video, is using a video for windows toolJust because you refuse to look up basic information about the topic at hand (http://en.wikipedia.org/wiki/Video_for_Windows) doesn't mean that everyone else is at fault for your error.

[MythCreator]

Just a question, where could I find newest version?

[LoRd_MuldeR]

Just a question, where could I find newest version?

CLI: http://x264.nl/ or http://sites.google.com/site/ranguvar13/x264-builds
VfW: http://sourceforge.net/project/showfiles.php?group_id=213809 (at your own risk)

[Gromozeka]

The 751 vfw revision from:
http://komisar.gin.by/
vfw is not risk
cli is risk :)

[wyti]

CLI is risk ? O_O if you know what settings you use you don't take risk.
But x264 (and h.264 at all) isn't designed for vfv, you should not put h264 in a avi file.
So you take a risk cause your video may be less compatible than a mkv or mp4 file (actually some software player read them but less hardware can).

[LoRd_MuldeR]

vfw is not risk
cli is risk :)

If you don't know how to use CLI, better get learning. Or get an nice front-end. Or even better: Get Avidemux :D

[nicko]

If you don't know how to use CLI, better get learning. Or get an nice front-end. Or even better: Get Avidemux :D
It is not the case. :)
Gromozeka wants to make accent on the final quality of cli and vfw builds. Last work often more reliably. ;)

[LoRd_MuldeR]

Gromozeka wants to make accent on the final quality of cli and vfw builds. Last work often more reliably. ;)

No, VfW builds work less reliable due to the lack of maintenance and due to the lack of "official" support from the x264 developers.
Also VfW builds produce worse quality, due to inherent limitations of VfW and due to the lack of the latest features and improvements!

So stop spreading nonsense please... If you don't want to learn how to use the CLI encoder, get one of the many x264 GUI's :rolleyes:

[komisar]

...less reliable due to the lack of maintenance and due to the lack of "official" support from the x264 developers...
...produce worse quality... ...lack of the latest features and improvements...
(sorry, google.translate used)
Totally unfounded assertion. VFW-version based on the main GIT sources and ALL "features and improvements" present. Developers enough to support main sources. Rebuilding VFW will be automatically match latest "features and improvements".

Everyone chooses for tools/encoders himself.

[LoRd_MuldeR]

(sorry, google.translate used)
Totally unfounded assertion. VFW-version based on the main GIT sources and ALL "features and improvements" present. Developers enough to support main sources. Rebuilding VFW will be automatically match latest "features and improvements".

VfW has a strict "one frame in, one frame out" limitation. This was okay 16 years ago, when VfW was designed, but not today!
Therefore VfW can not handle anything that requires "delayed" frames, such as B-Frames and multi-threading (as implemented in x264).
Well, hacks can be introduced to workaround the limitations of VfW, but it's ugly and definitely can't be called "more reliable than CLI".

It's a known fact the x264 should not be used via VfW for a number of reasons. It was discussed enough here and the facts are clear :rolleyes:
I'm not going to further comment on this, because I don't want to feed the VfW flamewar...


Everyone chooses for tools/encoders himself.

Sure. But this doesn't allow the VfW devotees to spread nonsense about the CLI encoder ;)

[komisar]

I agree that the VFW-interface at the moment is not relevant.
But I am also not inclined to bring round the people working with the VFW, that the CLI is better. Let them will choose to assess all the advantages and disadvantages of both. :-)

P.S. I am use only CLI. But build VFW for some people..
Sure. But this doesn't allow the VfW devotees to spread nonsense about the CLI encoderSure.

[nicko]

Well, hacks can be introduced to workaround the limitations of VfW, but it's ugly and definitely can't be called "more reliable than CLI".
I am not sure that this "hacks" is "ugly" (please, be valid to their developers), and in any case they do not reduce in any way stability of builds, as the minimum for the last year in these versions was not of any error observed.

[Dark Shikari]

I am not sure that this "hacks" is "ugly" (please, be valid to their developers), and in any case they do not reduce in any way stability of builds, as the minimum for the last year in these versions was not of any error observed.I'd say the most likely reason why nobody notices any problems with VfW builds is because hardly anybody uses them.

[nicko]

I'd say the most likely reason why nobody notices any problems with VfW builds is because hardly anybody uses them.

I answer first of all for myself, as I use them constantly, 2 machines round day and night with very complex scripts (down to 0.25fps on CoreDuo-5.2+), several session in parallel, and during a last year no one failure/mistake is observed.

PS.
By the way, many thanks for last version of PsyRDO-Trellis (& b-adapt 2), I have nice result for them with the last x264_r987K/999bm_vfw builds. :)

Last tested vfw build with full set of BM patches and new full-function GUI: http://stashbox.org/247538/x264vfw_14beta3_999bm_15505.exe

Alternative full-featured vfw-GUI http://komisar.gin.by/gui/index.html

[DeathTheSheep]

It's hard to believe this old thread is still alive, but that's a good thing. komisar, I'll link to your superb build on the first post in case anybody sees it. I personally use your builds now, komisar. :)

I have yet to try nicko's linked build, though.

[komisar]

DeathTheSheep, thanks. All for popularize best video encoder on a global scale... :)

[nicko]

DeathTheSheep, komisar

Plese look on the new feature in BM build "Fast scenecut"- it is very helpfull for some strange cases of "unlimited generation" of Key-frames.

PS
to DeathTheSheep
The last fully equiped by BM-patches vfw-builds from komisar (987-996) beter to look for here http://komisar.gin.by/old/

[MasterNobody]

nicko
It is not new feature. It is simply the new element in GUI (which I add in new GUI for x264vfw) for old x264 option --pre-scencut. Same effect you could get earlier with extra options or by using more than one thread (because multithreading force this option).

[nicko]

OK, I mean GUI-feature

But without this your simple step in the vfw-menu I would have spent the "month" :) to search how to knock down this "chaotic" Key-frames generation (I do not use multithreading), and it is not enough only to swich it on (+ min/max GOP size +Scenecut treshold).

In any case thise GUI-feature can be quite helpfull for users.

[MasterNobody]

Build 14_1016bm_15762 of x264vfw (http://sourceforge.net/projects/x264vfw/)

Changes:
New configuration GUI (many options are added)
x264 core updated to revision 1016 (git-dbc5ef0)
ffh264 core updated to revision 15762
GCC update to (4.3.2-tdm-1 for MinGW) 4.3.2
NSIS update to 2.40

Known problems:
- There are no tooltips/hints in this release (they would be added later).
- Built-in decoder incorrectly decodes files encoded in lossless mode of this release (the only decoder that can correctly decode them now is CoreAVC 1.8.0.0 and newer).

Screenshots:
http://i34.tinypic.com/1igygy.png
http://i35.tinypic.com/2n83lvl.png
http://i33.tinypic.com/345lbew.png

[DeathTheSheep]

Kudos, this looks awesome.

[nicko]

Kudos, this looks awesome.
It is quite useful, as contain all essential information in face.


BugMaster, many thanks for the new 1016_vfw build!

PS
One important feature of BM builds - is capability to adjust of AQ-sensitivity by hand.

[Jaxel]

DeathTheSheep... with this new version of x264-VFW... I find myself looking to your AVC Guide for help... yet its gone now!

Any idea when your guide will be back up?

Also... I encode using VirtualDubMod... I noticed there is an option for VirtualDub Hack. From my understanding, this is to get the video to encode properly into the AVI wrapper. However, I also use MKVToolnix to put the video into an MKV wrapper. Do I still need to use the VD Hack option?

[Gromozeka]

Do I still need to use the VD Hack option
You still nee use VD-hack option if your VirtualDubMod do bad videostream (bad b-frames). This option no damage mkv

[Cyber-Mav]

thought i would post to add my support for this project. im still a user of the VFW builds of x264 and i use it in conjunction with gordian knot. excellent work on this update. iv got it installed and will be doing some encodes over the weekend. also will there be a new guide up for this at somepoint, a lot has changed since i was using the july version of the VfW encoder last time.

[Jaxel]

Okay... I got a question about "Subpixel ME Refinement"... What real difference does this setting make? What about "ME Algorithm"? I would figure the harder the refinement and the harder the algorithm would make the video encoding take longer... but the numbers I am getting are skewed. I tested using a single video with several different settings... Its 2:30, and at 1280x720 and 29.97fps; using 4 threads.

UMH - 9 RDr on All - 31 minutes to encode (with warnings - possible livelocks)
ESA - 9 RDr on All - 20 minutes to encode (with warnings - possible livelocks)
UMH - 8 RDr on I/P - 58 minutes to encode

These settings seem completely backwards to me! And do these possible livelock warnings have any bearings on my videos? Should I just stick with the ESA - 9 RDr on All settings? It seems to be the fastest, and according to DeathTheSheep's guide, it should give me the best quality as well.

[Dark Shikari]

Okay... I got a question about "Subpixel ME Refinement"... What real difference does this setting make? What about "ME Algorithm"? I would figure the harder the refinement and the harder the algorithm would make the video encoding take longer... but the numbers I am getting are skewed. I tested using a single video with several different settings... Its 2:30, and at 1280x720 and 29.97fps; using 4 threads.

UMH - 9 RDr on All - 31 minutes to encode (with warnings - possible livelocks)
ESA - 9 RDr on All - 20 minutes to encode (with warnings - possible livelocks)
UMH - 8 RDr on I/P - 58 minutes to encode

These settings seem completely backwards to me! And do these possible livelock warnings have any bearings on my videos? Should I just stick with the ESA - 9 RDr on All settings? It seems to be the fastest, and according to DeathTheSheep's guide, it should give me the best quality as well.ESA+subme9 should clearly be the slowest. If it isn't, someone broke something.

[Jaxel]

I'm using the Nov 25 build (comes with K-Lite Mega)...

Anyway... I'm running some additional tests... running UMH - 7 right now... gonna try running ESA - 9 agian to see what happens.

[kemuri-_9]

ESA+subme9 should clearly be the slowest. If it isn't, someone broke something.

depends on if he ran them back to back...
which would cause time differences for the 2nd and later runs,
since the data would already be in memory (RAM) and wouldn't have to read from slow media (HDD) like the first run.

no other information is provided on the state of the system during encoding, which could also affect the encoding times.

I'm using the Nov 25 build (comes with K-Lite Mega)...
.... <_< ...
the official builds on x264.nl are the best choice for testing speeds with...

[Jaxel]

The runs were done back to back... yes... but that makes the results even worse...

ESA-9 was the FIRST run at 20 minutes...
UMH-9 was the SECOND run at 31 minutes...
UMH-8 was the THIRD run at 58 minutes...

[Dark Shikari]

depends on if he ran them back to back...
which would cause time differences for the 2nd and later runs,
since the data would already be in memory (RAM) and wouldn't have to read from slow media (HDD) like the first run.That won't make a difference for such a large file... and x264 is not HDD bottlenecked on any sane input...I'm using the Nov 25 build (comes with K-Lite Mega)...facepalm, use the real x264.

[Ranguvar]

comes with K-Lite Mega

Now there's a reason if I ever heard one to avoid a piece of software.

[kemuri-_9]

That won't make a difference for such a large file... and x264 is not HDD bottlenecked on any sane input...


C:\>avs2yuv -o x264_build1.y4m x264buildsrcs\test.avs
x264buildsrcs\test.avs: 640x480, 30 fps, 4350 frames
preparing to close files
closing y4m file x264_build1.y4m
files are closed

C:\>ls -sh | grep x264_build1.y4m
1.86G x264_build1.y4m

(waited about 2 hours while doing some other high paging events)

C:\>x264.exe -m9 --me tesa -Aall x264_build1.y4m -B 1000
-o NUL --progress --threads 4
yuv4mpeg: 640x480@30/1fps, 0:0
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSEMisalign
x264 [info]: profile Main, level 3.0
x264 [info]: slice I:97 Avg QP:22.28 size: 6089 PSNR Mean Y:56.55 U:61.56
V:59.61 Avg:57.02 Global:43.73
x264 [info]: slice P:4253 Avg QP:29.48 size: 4216 PSNR Mean Y:38.48 U:44.08
V:41.74 Avg:39.30 Global:35.56
x264 [info]: mb I I16..4: 78.1% 0.0% 21.9%
x264 [info]: mb P I16..4: 15.8% 0.0% 5.3% P16..4: 37.0% 8.6% 4.0% 0.1% 0
.1% skip:29.2%
x264 [info]: final ratefactor: 28.13
x264 [info]: SSIM Mean Y:0.9550230
x264 [info]: PSNR Mean Y:38.884 U:44.470 V:42.139 Avg:39.695 Global:35.642 kb/s:
1021.96

encoded 4350 frames, 13.16 fps, 1022.16 kb/s

(and right after)

C:\>x264.exe -m9 --me tesa -Aall x264_build1.y4m -B 1000
-o NUL --progress --threads 4
yuv4mpeg: 640x480@30/1fps, 0:0
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSEMisalign
x264 [info]: profile Main, level 3.0
x264 [info]: slice I:97 Avg QP:22.28 size: 6089 PSNR Mean Y:56.55 U:61.56
V:59.61 Avg:57.02 Global:43.73
x264 [info]: slice P:4253 Avg QP:29.48 size: 4216 PSNR Mean Y:38.48 U:44.08
V:41.74 Avg:39.30 Global:35.56
x264 [info]: mb I I16..4: 78.1% 0.0% 21.9%
x264 [info]: mb P I16..4: 15.8% 0.0% 5.3% P16..4: 37.0% 8.6% 4.0% 0.1% 0
.1% skip:29.2%
x264 [info]: final ratefactor: 28.13
x264 [info]: SSIM Mean Y:0.9550230
x264 [info]: PSNR Mean Y:38.884 U:44.470 V:42.139 Avg:39.695 Global:35.642 kb/s:
1021.96

encoded 4350 frames, 34.29 fps, 1022.16 kb/s


performance from run #1
http://kemuri9.net/forumpics/x264_run-1.png

and run #2
http://kemuri9.net/forumpics/x264_run-2.png

there's a clear performance boost from the file data being in the RAM as compared to having to read from HDD.
reading from the HDD is a slow task compared to being able to read from RAM.
This affects every program that performs reading of data, even x264...

[Dark Shikari]

there's a clear performance boost from the file data being in the RAM as compared to having to read from HDD.
blocking for I/O to the HDD is a slow task compared to being able to grab from RAM.
This affects every program that performs reading of data, even x264...I strongly suspect something is wrong with your test, as those results are basically nonsensical. x264 uses far, far, far less hard drive bandwidth than the max at such settings, even with raw video input.

[kemuri-_9]

I strongly suspect something is wrong with your test, as those results are basically nonsensical. x264 uses far, far, far less hard drive bandwidth than the max at such settings, even with raw video input.

the first run is reading from the HDD, the second is not as it's reading from RAM.

i have my procexp refresh rate on 2s intervals, so the actual BW is half the given value.

[Dark Shikari]

the first run is reading from the HDD, the second is not as it's reading from RAM.I'm not stupid. Read my post again and again until you understand what I said.

[MasterNobody]

Jaxel
Can't confirm this behavior here. Can you post all other settings (for example, "Save processing settings..." in VirtualDub). Also does the all resulted encodes have the same length (may be after "possible livelock" warning VirtualDub simply stops encoding farther).

Ranguvar, Dark Shikari
Please, leave tech support of x264vfw to me. I know that most Doom9 members are against it but this thread is exclusively about VfW builds of x264 and so at least in this thread don't blame x264vfw in all sins.

P.S. I am not saying that testing in x264 CLI is bad idea.

[kemuri-_9]

I'm not stupid. Read my post again and again until you understand what I said.

i'm not trying to prove exact numbers
i'm trying to prove the hardware law that reading RAM is always faster than HDD/media,
which you are trying to say x264 is exempt from.

and that's a completely false attempt!

what you seem to be trying to say is either
1. "x264 is too SLOW to be able to recognize speed performance of the RAM"
or
2. "x264 reads too LITTLE DATA to be able to recognize speed performance of the RAM"

now the first case is a little out of my jurisdiction, but with how asm optimized x264 is, i would go to say this is false.

the second case is also false, since x264 often needs to read a lot of data.
- 12 bits/pixel for some few to several 100Ks of pixels on average * anywhere from just 1 to 200000 frames

[Dark Shikari]

i'm not trying to prove exact numbers
i'm trying to prove the hardware law that reading RAM is always faster than HDD/media,
which you are trying to say x264 is exempt from.Reading from RAM is only faster than reading from the disk if the encoder is bottlenecked by the disk. As long as it can read from the disk faster than it can encode the data from the disk, there should be no significant speed cost of reading from the disk.

Furthermore, your 3x lower FPS would mean that x264 is spending 2/3 of its time reading from the disk--meaning it's spending far more time reading from the disk than encoding a frame. Given the settings you used, this is not really possible unless your disk is a large group of kids in your basement who you taught to memorize numbers.

[kemuri-_9]

Reading from RAM is only faster than reading from the disk if the encoder is bottlenecked by the disk. As long as it can read from the disk faster than it can encode the data from the disk, there should be no significant speed cost of reading from the disk.

Furthermore, your 3x lower FPS would mean that x264 is spending 2/3 of its time reading from the disk--meaning it's spending far more time reading from the disk than encoding a frame. Given the settings you used, this is not really possible unless your disk is a large group of kids in your basement who you taught to memorize numbers.

it's windows, reading from a PATA OS HDD which is horribly fragmented
(so in essence you never know, it's environment based too) :rolleyes:

also, i don't remember the exact %...
but on the first run, my CPUs were horribly underutilized at something around 30-40% on average.

2nd run had steady 100% usage across the board.

Edit:
so generally the % speed increase from RAM will not generally be this high (i was quite amazed at how high it was in fact)
but there will be a speed increase of some amount. <--- that's what i'm mostly trying to say...

[Guest]

All this disk/ram performance discussion has veered off topic. Please take it to a PM or a separate thread.

[MasterNobody]

New builds of x264vfw (http://sourceforge.net/projects/x264vfw/):
x264vfw_16_1089bm_16807 (http://sourceforge.net/project/showfiles.php?group_id=213809&package_id=257567&release_id=656407)
Updated installer
x264 core updated to revision 1089 (git-355c445)
ffh264 core updated to revision 16807

and first public release of x64 version:
x264vfw64_16_1089bm (http://sourceforge.net/project/showfiles.php?group_id=213809&package_id=307626&release_id=656414)
This is first public release of x64 version.
Currently it is without decoder.

P.S. Does ffmpeg support Windows x64 (assembler optimizations)? And if not how does people compiles ffdshow tryouts x64 (without optimizations :scared:)?

P.P.S. Used patches and pthread library:
bm_x264_patch_collection.r1089.zip (http://stashbox.org/376780/bm_x264_patch_collection.r1089.zip)
pthreads64.zip (http://stashbox.org/376782/pthreads64.zip)
or mirror at komisar's site (http://komisar.gin.by/x.patch/BugMaster/20090126/)

[Dark Shikari]

P.S. Does ffmpeg support Windows x64 (assembler optimizations)? And if not how does people compiles ffdshow tryouts x64 (without optimizations :scared:)?Most of it does. Most of the new optimizations, such as the ones taken from x264, are in yasm syntax though, and so don't support 64-bit. If you want it to, simply finalize your patch for 64-bit, get it committed to x264, and we'll port it over to ffmpeg.

[akupenguin]

Most of the new optimizations, such as the ones taken from x264, are in yasm syntax though, and so don't support 64-bit.
FFT apparently works on win64, even though ffmpeg's yasm win64 support is far less complete than the pending patch for x264 (e.g. no saving of xmm).

[Dark Shikari]

FFT apparently works on win64, even though ffmpeg's yasm win64 support is far less complete than the pending patch for x264 (e.g. no saving of xmm).How does the saving of xmm work for inline asm? Does gcc somehow automatically detect which regs are clobbered?

[akupenguin]

Does gcc somehow automatically detect which regs are clobbered?
No, you have to put xmm# on the clobber list, just like any other register. (This is also true when mixing inline asm with float (-fpmath=sse) or autovectorization, regardless of calling convention. We just don't have any instances where gcc gets it wrong. yet.) And then gcc will refuse to compile your code when -march doesn't include sse, since it doesn't know it's under runtime detection.

[Gromozeka]

How encode to *.mp4 with x264 vfw:
Render media *.avs (other format) -> x264 -> Haali Matroska muxer (file type mp4)
(log level 'none' in preferences x264 vfw)

http://i40.tinypic.com/2u4sdw8.png

[winnydows]

Hi to all. I develop DirectShow media encoder - Winnydows Commander. Video-audio coding functions present only in a DAILY version (http://www.winnydows.com/request.php?43)) now, but coding already work. Encoder work with installed DirectShow filters-codecs and VFW codecs, so you can use x264vfw for encoding any video file to .264, avi, mkv (ts and mp4 have temporary problems). All filters can be tuned, batch encoding, auto interlace and auto SAR calculation. Possible choose different splitters, decoders, encoders, muxers.

Few screens:
Encoding and video tooltips (http://www.winnydows.com/screenshots/screenshot_19.png)
Decoder settings (http://www.winnydows.com/screenshots/screenshot_20.png)

[movmasty]

Srill cant find a guide for VFW

[ChronoCross]

Srill cant find a guide for VFW

use the CLI in combination with megui and the tutorials located here: http://mewiki.project357.com/wiki/Main_Page

[movmasty]

use the CLI in combination with megui and the tutorials located here: http://mewiki.project357.com/wiki/Main_Page
thanks

[Midzuki]

Originally Posted by movmasty
Srill cant find a guide for VFW

To whom this may interest, and
even though it's somewhat outdated by now:

http://gabextreme.googlepages.com/DeathTheSheep_x264_VfW_guide.html

HTH.

[LoRd_MuldeR]

To whom this may interest, and
even though it's somewhat outdated by now:

http://gabextreme.googlepages.com/DeathTheSheep_x264_VfW_guide.html

That's the guide this entire thread is about (thus the title) and it's linked in the very first (http://forum.doom9.org/showthread.php?p=695028#post695028) post ;)

[Midzuki]

That's the guide this entire thread is about (thus the title) and it's linked in the very first (http://forum.doom9.org/showthread.php?p=695028#post695028) post ;)

Well, the «very first post» in this thread leads to:

http://gabextreme.googlepages.com/x264vfwunited

in which the hyperlink to the mentioned guide is broken. :rolleyes:

It seems LoRd_MuldeR needs more cups of coffee per day. :)

[LoRd_MuldeR]

If you had mentioned that the link on the original web-site is broken then your post would have made more sense to me ;)

[Midzuki]

If you had mentioned that the link on the original web-site is broken then your post would have made more sense to me
OR... you would have tried to find other ways to annoy me. :(

[komisar]

After prolonged inactivity, compiled the latest (1471) version of x264vfw. Supported output to raw/avi/mkv/flv/mp4

http://komisar.gin.by/

http://komisar.gin.by/img/x264vfw_conf1.jpg


P.S.
:D Use you favorite video editor and compress to H264 with no limit...

[roozhou]

I wonder how frame-level multi-threading and mb-tree is implemented in x264vfw.

[komisar]

roozhou
Well as in the CLI-version. VFW used to encode the libx264.

[LoRd_MuldeR]

roozhou
Well as in the CLI-version. VFW used to encode the libx264.

He probably refers to the fact that VfW uses a strict "one frame in, one frame out" paradigm. Hence you can't "see" the next frame without encoding/returning the current frame first. This makes pre-buffering impossible. Well, unless you implement some kind of "hack" that returns empty/dummy frames at the begin of the encode. But that can cause a/v desync, if the host application doesn't compensate...

[roozhou]

He probably refers to the fact that VfW uses a strict "one frame in, one frame out" paradigm. Hence you can't "see" the next frame without encoding/returning the current frame first. This makes pre-buffering impossible. Well, unless you implement some kind of "hack" that returns empty/dummy frames at the begin of the encode. But that can cause a/v desync, if the host application doesn't compensate...
And there is no "packet bitstream" for AVC, so b-frame is also impossible without hacks.

[komisar]

You may ouput encoding to mkv/mp4/raw and use it as you wish (if bframes > 0) or directly output in avi (if bframes == 0).

It is not essential. The main thing is that now you can use any editor that supports output via the DS and you want to encode in the container (mkv/mp4/raw).

[LoRd_MuldeR]

You may ouput encoding to mkv/mp4/raw and use it as you wish (if bframes > 0) or directly output in avi (if bframes == 0).

Well, letting the VfW Codec write the encoded frames to an external file may work, but that's not exactly how VfW/ACM was intended ;)

Most important the VfW Codec you will produce a video-only file, while the actual AVI file written by the host application (which contains video+audio) has to be discarded.

If people are willing to accept those limitations, then they are free to do so. But it's certainly not what the average "newbie" VirtualDub+VfW user expects...

[komisar]

This has already been discussed many times ... Why do we need again for someone to persuade or to dissuade? Let vfw uses the one who needs it ... ;)

[DeathTheSheep]

@LoRd_MuldeR:
You seem to be misunderstanding. The "write to external file" feature is an additional feature which is completely optional. The normal VfW activity is left intact, and encoding as normal works perfectly. Awhile ago there was an almost-negligible few-frame delay when using, for instance, 16 references and 16 b-frames, but this is now mitigated with the "VirtualDub hack" option (which I've found to work with a lot more than just VirtualDub, actually).

The VfW handles the one-frame-in/one-frame-out system rather cleverly and admirably if used normally, and you should notice no problems.

[LoRd_MuldeR]

This has already been discussed many times ... Why do we need again for someone to persuade or to dissuade? Let vfw uses the one who needs it ... ;)

I have no problem with VfW at all. If people want to use x264 VfW they are free to do so.

But there are inherent limitations in VfW, that's a fact. And due to those limitations x264 (and H.264 in general) is usable through VfW only with certain workarounds/hacks (however you want to call it).

It must be allowed to speak out those problems, so people don't get the wrong idea ;)

You seem to be misunderstanding. The "write to external file" feature is an additional feature which is completely optional.

I understood very well. And it's not optional. That's because the AVI produced by the host application will be invalid/desynced -- unless B-Frames are disabled.

So if you want to use B-Frames with x264 VfW the only "fully working" method is using the "external file" workaround...

A while ago there was an almost-negligible few-frame delay when using, for instance, 16 references and 16 b-frames, but this is now mitigated with the "VirtualDub hack" option (which I've found to work with a lot more than just VirtualDub, actually).

Now with all the "lookahead" functionality that has been added to x264, the initial delay can easily reach ~90 frames.

And having to add "hacks" not only to the VfW Codec itself but also to the host application (e.g. VirtualDub) isn't exactly a "pro" argument for VfW ;)

[DeathTheSheep]

That's correct, but if there are no problems with the current implementation for the end user, perhaps we shouldn't dwell on the theoretical? :)

[roozhou]

@DeathTheSheep
Is this a "x264vfw for VirtualDub" or a "x264vfw for all vfw applications"? AFAIK x264vfw does not work with most of vfw applications other than VD when b-frame is used. If you have to hack the host app, why should we stick to vfw?

[Gromozeka]

I use this feature in different programs. now no restrictions as compared with the cli version

[DeathTheSheep]

I think it's safe to call it "full x264vfw for VirtualDub" as well as "limited x264vfw for other vfw applications." "Limited" because if the VirtualDub hack doesn't work in a certain program, there will be slight delay at the beginning of the file proportional to the number of B-frames used, unless another output format is specified. Like LM said, this is an inherent limitation of VfW. However, this build works around it quite nicely with the "hack" and the option of alternative output formats.

Is there a specific program this VfW doesn't work for? If so, there might be a bug to work out.

[Gromozeka]

this vfw for all applications
don't use --vd-hack
if you use -o *.mp4 (mkv,flv,raw) from "add options" vfw not limits b frames and other limits

[poisondeathray]

this vfw for all applications
don't use --vd-hack
if you use -o *.mp4 (mkv,flv,raw) from "add options" vfw not limits b frames and other limits


are you saying this works in all applications?

I just tried in After Effects, and it doesn't.

[DeathTheSheep]

Correct. If you use a different output format than avi, there are no feature limitations. However, if you use avi, you must either use VirtualDub hack or reduce the use of B-frames; otherwise, there will be a slight delay.

It doesn't work in AE? Strange, what settings are you using? Does it crash or produce an error?

[Gromozeka]

are you saying this works in all applications?

I just tried in After Effects, and it doesn't.

How long have you tried? XviD compress well?
I have never worked vfw in Premiere CS3
but rhis version (1471), which works with the-o *. mkv, flv should work.

[poisondeathray]

It doesn't work in AE? Strange, what settings are you using? Does it crash or produce an error?

It renders, but produces an invalid .avi file (just green frames, or none at all) , but no .mp4 file

(In vdub, it produces a "fake" .avi file and the real .mp4 , which is the way I expected it to work)

[DeathTheSheep]

Awkward indeed. Does Xvid work? How about DivX, ffdshow, etc?

[poisondeathray]

How long have you tried? XviD compress well?
I have never worked vfw in Premiere CS3
but rhis version (1471), which works with the-o *. mkv, flv should work.


Well the vfw interface works in AE CS4, because if I do it without b-frames and normal .avi container then it renders fine, no bad frames


Awkward indeed. Does Xvid work? How about DivX, ffdshow, etc?


Yes xvid works fine

[Gromozeka]

(In vdub, it produces a "fake" .avi file and the real .mp4 , which is the way I expected it to work)

yes

latest version Premiere not good work with vfw. but version Premiere 6.5 very fine
This not work and with divX, XviD, its not problem x264 (Premiere cs3)
mp4 work in Premiere 6.5, woblempegvideo wizard

[poisondeathray]

Well it might be only CS4 that does *not* work with the b-frame and .mp4 export option... I'm just reporting observations & giving feedback :)

(and I tried with vdub hack on/off)

[Gromozeka]

Well it might be only CS4 that does *not* work with the b-frame and .mp4 export option... I'm just reporting observations & giving feedback :)

(and I tried with vdub hack on/off)

XviD work fine?
--vd-hack off
you use "--b-frames 6 -o video.mp4"?

[DeathTheSheep]

Aha, well that's certainly still a problem, even if it is only one app. Is it only mp4 output or all external output formats (mkv, flv, etc) that is affected? Is going from B-frames 0 to B-frames 1 sufficient to reproduce the AVI error?

[poisondeathray]

XviD work fine?
--vd-hack off
you use "--b-frames 6 -o video.mp4"?

Yes xvid, and other vfw codecs like UT video codec work fine

I tried vd hack on/off (ie. both ways, it didn't matter)

No I just used 3 b-frames (in the gui) , and -o video.mp4 in the command line box

[Gromozeka]

Yes xvid, and other vfw codecs like UT video codec work fine

I tried vd hack on/off (ie. both ways, it didn't matter)

No I just used 3 b-frames (in the gui) , and -o video.mp4 in the command line box

you use this:
"-o d:\temp\video1.mp4"

[komisar]

poisondeathray, do you try "-o c:\temp\my_video.mp4"? (full pathname)

[Gromozeka]

I use mp4 in After effects CS3 - all work fine
parameters -o C:\video.mp4

[poisondeathray]

you use this:
"-o d:\temp\video1.mp4"


-yes , specifying a non-system directory on a different HDD seems to work, but the fps is 25 (source was 23.976)
- If I add --fps 23.976 to commandline box it seems to correct it
- works with 0,1,3 b-frames and b-pyramid , no black/green frames at beginning

Nice work guys! Any more tests needed?

EDIT: I tested a different HDD, I'll try a different folder on same HDD and see if that works
EDIT: yes it works fine on the same HDD, just different directory path

Summary: for AE CS4, make sure you specify different directory, and fps

[Gromozeka]

-yes , specifying a non-system directory on a different HDD seems to work, but the fps is 25 (source was 23.976)
- If I add --fps 23.976 to commandline box it seems to correct it
- works with 0,1,3 b-frames and b-pyramid , no black/green frames at beginning

Summary: for AE CS4, make sure you specify different directory, and fps

Nice work guys! Any more tests needed?

EDIT: I tested a different HDD, I'll try a different folder on same HDD and see if that works

you test Blue ray compiliant?

--level 4 --subme 7 --crf 3 --bframes 3 --ref 4 --fps 23.976 --keyint 14 --min-keyint 2 --vbv-maxrate 40000 --b-pyramid none --aud --nal-hrd vbr -o C:\video.264
or other parameters

[poisondeathray]

I use slightly different settings, but seems to work. I sent to a friend who has scenarist and he said it passed mui generator check fine. I don't have access to real BD verifier - you have to ask others like shon3i

[Gromozeka]

I use slightly different settings, but seems to work. I sent to a friend who has scenarist and he said it passed mui generator check fine. I don't have access to real BD verifier - you have to ask others like shon3i

:thanks:
great victories in the future

[poisondeathray]

One other point: the --profile and --tune don't seem to pass through (not a big deal, you can set those options manually)

And what is the difference between "extra options" box, vs. the "use command line" box in the GUI ?

[Gromozeka]

One other point: the --profile and --tune don't seem to pass through (not a big deal, you can set those options manually)

And what is the difference between "extra options" box, vs. the "use command line" box in the GUI ?

"extra options" - add parameters to gui
"use command line" use only him parameters and ignored gui parameters

[komisar]

poisondeathray
This options not supported in vfw: FRAMES/SEEK/MUXER/DEMUXER/INDEX/QPFILE/THREAD-INPUT/NOPROGRESS/VISUALIZE/TUNE/PRESET/PROFILE/SLOWFIRSTPASS
"use command line" disable all GUI-options and use only what you enter in edit-box.
"extra options" append you entered options to GUI-option.

[poisondeathray]

Thanks guys :) nice work

But I have another dumb question: how to get log file to print? The console box opens and closes automatically

[komisar]

poisondeathray, you may use "--log-file c:\mu_encode_log.txt" (also --log-file-level supported)

from cli-help: --log-file <string> Save log to file
--log-file-level <int> Log-file level information [2]

[MasterNobody]

One other point: the --profile and --tune don't seem to pass through (not a big deal, you can set those options manually)
They probably would be supported after I make redesign of interface (where profile/preset/tune would be part of interface but most of other options would probably discarded [for advanced user there is command line options]).

[poisondeathray]

Thanks , I forgot to specify path...

[creamyhorror]

PDR, does this mean we can now do (on Windows) what rallymax was trying to achieve?

[poisondeathray]

PDR, does this mean we can now do (on Windows) what rallymax was trying to achieve?

Yes it's definitely looking like that (with the few exceptions that komisar listed several posts above). Need to do some more testing to be sure, and it still needs to be verified by a strict BD verifier. (NAL-HRD patch seems to being very close to officially being commited too)

[dstln]

Thanks for updating this. I haven't yet found a better method to capture to x264 from my card, and this may fix several issues.

[creamyhorror]

Yes it's definitely looking like that (with the few exceptions that komisar listed several posts above). Need to do some more testing to be sure, and it still needs to be verified by a strict BD verifier. (NAL-HRD patch seems to being very close to officially being commited too)
Nice. I hope rallymax won't be too disappointed.

[easy2Bcheesy]

I'm currently encoding 720p30 in real-time in VirtualDub into x264vfw (Bugmaster's last build) on an i7 920 PC. I am using default settings but with CABAC disabled. With CABAC enabled, I drop a lot of frames :( I'm trying both CRF at around 25, and also with set bandwidth of 5mbps.

Bearing in mind it's real-time, it's VFW, it's AVI etc, I'm pleasantly surprised by the quality level but what settings could I work with to improve quality? Also, is there a DirectShow x264 encoder available as fully featured as x264vfw? I'd imagine the option to deal with dual frames simultaneously could improve efficiencies?

[MasterNobody]

I'm currently encoding 720p30 in real-time in VirtualDub into x264vfw (Bugmaster's last build) on an i7 920 PC. I am using default settings but with CABAC disabled. With CABAC enabled, I drop a lot of frames :( I'm trying both CRF at around 25, and also with set bandwidth of 5mbps.

Bearing in mind it's real-time, it's VFW, it's AVI etc, I'm pleasantly surprised by the quality level but what settings could I work with to improve quality? Also, is there a DirectShow x264 encoder available as fully featured as x264vfw? I'd imagine the option to deal with dual frames simultaneously could improve efficiencies?
I hope you don't really use "default settings" without any modifications. At least change Threads to 0 (this auto) and increase B-frames number and Refs (also if possible [you use VirtualDub or its modification] enable VirtualDub Hack).
As for DirectShow x264 encoder the only one I am aware is MONOGRAM x264 Encoder (1.0.5.0) (http://blog.monogram.sk/janos/2009/05/20/monogram-x264-encoder-1050/)

[easy2Bcheesy]

Edit: I've switched to the x264 implementation in ffdshow and can achieve 720p30 real-time capture comfortably with CABAC and lots of other goodies in VirtualDub. I'm using LAME at 192kbps for MP3 compressed audio. The .avi files run fine even in Windows 7 media player.

The only issue I find is that the audio needs to be set +500ms in order to be in sync with the video - something not required with x264vfw.

[Midzuki]

x264vfw r1523 released:

http://komisar.gin.by/

[Blue_MiSfit]

Awesome!

[Blue_MiSfit]

A request, if anyone is maintaining this code:

It would be helpful if in one pass ABR mode, the GUI allowed for target bitrates over 20mbps. I would like up to 100mbps if at all possible. Though I usually just use CRF, ABR/CBR can be useful in certain scenarios ;)

~MiSfit

[buzzqw]

why not use crf 0 ? (or 1 or 2...)

BHH

[MasterNobody]

A request, if anyone is maintaining this code:

It would be helpful if in one pass ABR mode, the GUI allowed for target bitrates over 20mbps. I would like up to 100mbps if at all possible. Though I usually just use CRF, ABR/CBR can be useful in certain scenarios ;)

~MiSfit

Try new versions:
x264vfw_21_1538bm_22856 (http://sourceforge.net/projects/x264vfw/files/x264vfw/21_1538bm_22856/x264vfw_21_1538bm_22856.exe/download)
x264vfw64_21_1538bm_22856 (http://sourceforge.net/projects/x264vfw/files/x264vfw64/21_1538bm_22856/x264vfw64_21_1538bm_22856.exe/download)

I added pseudologarithmic slider for ABR with bitrate from 1 to 999999 kbit/s. Hope this would be enough for anyone ;).

[Midzuki]

Try new versions:
x264vfw_21_1538bm_22856 (http://sourceforge.net/projects/x264vfw/files/x264vfw/21_1538bm_22856/x264vfw_21_1538bm_22856.exe/download)
x264vfw64_21_1538bm_22856 (http://sourceforge.net/projects/x264vfw/files/x264vfw64/21_1538bm_22856/x264vfw64_21_1538bm_22856.exe/download)
:goodpost: && :thanks:
I added pseudologarithmic slider for ABR with bitrate from 1 to 999999 kbit/s. Hope this would be enough for anyone ;).

Now all that we need is an 8192x4608 video source. :D

[Blue_MiSfit]

Thank you!! MUCH appreciated!!

~MiSfit

[Blue_MiSfit]

why not use crf 0 ? (or 1 or 2...)

BHH

You run into the default --qpmin 10 anything below CRF12 in most cases from my experience. Beyond this is really more than is needed for anything but the finest mastering quality. I'm using this as a mezz file to generate everything between ~600kbps 480p and ~9mbps 1080p, and doing this on a massive scale.

So, in my case it's more important to have a predictable output filesize while still keeping good quality. ~50mbps 1080p24 or 1080i60 ABR gives excellent results in the tests I've conducted, with no visible artifacting even when peeked at with the revealing Histogram(mode="luma") in AviSynth. This is all using rather fast settings as well (something close to --tune veryfast).

Thanks again for tweaking the behavior! This overpriced Digital Rapids box just got a lot more useful to me :D

~MiSfit

[Midzuki]

x264vfw r1564 by Komisar has been released:

http://komisar.gin.by/

++++++++++++++++

UPDATE:

x264vfw r1583 has been released
(2010/May/08)

[MasterNobody]

I think it is the time for beta-testing of new GUI for x264vfw with preset/tuning/profile support.
http://i48.tinypic.com/2pzaf4g.png
Build: x264vfw_beta_1613bm_23386.exe (http://www.mediafire.com/file/f5czzmd4oyz/x264vfw_beta_1613bm_23386.exe)

P.S. Beta-period would be one week so please report about found bugs and suggestions earlier.

[Blue_MiSfit]

SWEET :)

This just keeps getting better and better.

Trying now.

Derek

[Blue_MiSfit]

One suggestion - I personally liked having the other tabs for VUI etc. Maybe add a second tab with some of these settings, along with VBV values and other things that are independent from preset / profile / tune



~MiSfit

[MasterNobody]

Updated beta2: x264vfw_beta2_1629bm_23430.exe (http://www.mediafire.com/file/jwtmw1uyyhx/x264vfw_beta2_1629bm_23430.exe)

One suggestion - I personally liked having the other tabs for VUI etc. Maybe add a second tab with some of these settings, along with VBV values and other things that are independent from preset / profile / tune
Sorry, but I don't suggest adding more options to new GUI currently because all other options (in my opinion) are for advanced users only so they can use extra command line.

[MasterNobody]

Release is little bit delayed so here is beta3: x264vfw_beta3_1649bm_23639.exe (http://www.mediafire.com/?5ltdyunboyl)

[MasterNobody]

Official release of new GUI:
x264vfw_23_1659bm_23819.exe (http://sourceforge.net/projects/x264vfw/files/x264vfw/23_1659bm_23819/x264vfw_23_1659bm_23819.exe/download)
x264vfw64_23_1659bm_23819.exe (http://sourceforge.net/projects/x264vfw/files/x264vfw64/23_1659bm_23819/x264vfw64_23_1659bm_23819.exe/download)

[buzzqw]

thanks MasterNobody!

BHH

[Midzuki]

x264vfw r1666 :devil: gets out of the oven

http://komisar.gin.by/

[komisar]

from Current Patches, Where to get them, How they affect speed/output (http://forum.doom9.org/showthread.php?p=1414900#post1414900) thread:

2 komisar - your crazy devil x264vfw build sets mb-tree=0 when use Command line option is off.
D3C0D3R, yes... mb_tree=0 because [warning]: lookaheadless mb-tree requires intra refresh (http://sourceforge.net/projects/x264vfw/forums/forum/770225/topic/3759827)
if you known what you do -- add needed options to "Extra options:"-box...

2 komisar - i always place in extra textbox something like "--rc-lookahead 120" and had in 1659 mb-tree=1, but in 1666 i didnt see any warnings and mb-tree=0
AFAIK this is no other way to turn on MB-Tree only to off it ))
in extra options: "--mbtree --rc-lookahead 100" work... try it... ;)

[Amdh]

Hi there,
I've really enjoyed x264 VFW ability to output to mkv, however I'm experiencing a problem using that feature. Here's what I've done :

I've edited my video as usual, making the needed filtering and I've set x264 VFW to output to mkv, I've added that to VirtualDub's Joblist and I've executed it right from the Joblist. To my surprise, VirtualDub outputed the Fake AVI file and not the MKV. What's wrong ? Please help.

NB. I'm using VirtualDub 1.9.9 and x264 VFW r1688 KMod

[MasterNobody]

Do you use full or relative path for mkv output? If relative than may be your looking for resulting MKV in wrong directory. As for Fake AVI it is always created except when you use "Run video analysis pass"

[Amdh]

Do you use full or relative path for mkv output? If relative than may be your looking for resulting MKV in wrong directory. As for Fake AVI it is always created except when you use "Run video analysis pass"

Could you please explain me the difference between full and relative path ?

I just write -o moviename.mkv and it encodes the MKV to VirtualDub's Folder .. how can I change that ? And by the way, how can I make it output automatically to the same folder as the fake AVI ?

Thanks again for your help.

[komisar]

Amdh
full path: "-o c:\my_video\encoded.mkv" (this works always)

[Midzuki]

r1703 is ready :)

http://komisar.gin.by/

[Midzuki]

r1713 has been released:

http://sourceforge.net/projects/x264vfw/files/

[MatLz]

With more features, also here :
http://komisar.gin.by/

[Midzuki]

This time MasterNobody was faster than Komisar.
Also, for the time being, Komisar's site is down
(or unreachable) :-/

EDIT: Actually, there is some problem between my crappy ISP :mad:
and komisar's web site, I've managed to access komisar.gin.by through a public proxy server.

[komisar]

[2011-01-24] added new command-line options for vfw r1867

Specify RGB to YUV conversion logic (not important if input is already in YUV)

--input-csp-rec ["bt601"|"bt709"] (default "bt601")
--input-csp-scale ["tv"|"pc"] (default "tv")

[J_Darnley]

[2011-01-24] added new command-line options for vfw r1867

Specify RGB to YUV conversion logic (not important if input is already in YUV)

--input-csp-rec ["bt601"|"bt709"] (default "bt601")
--input-csp-scale ["tv"|"pc"] (default "tv")

Why wouldn't you use the existing --colormatrix and --fullrange options for that?

[komisar]

--colormatrix and --fullrange mark output stream
--input-csp-rec/--input-csp-scale convert input stream from host app

[J_Darnley]

Yes, so if you ask for --colormatrix rec709 --fullrange on with RGB video, you will get TV range 601. Nice work.

[komisar]

J_Darnley, "--colormatrix rec709 --fullrange" you known what you do... and yes, you get 601-tv marked as 709-pc...
but with "--input-csp-rec 709 --input-csp-scale pc" you get RGB->YUV converted as you expected marked as "undef"...
"--input-csp-rec 709 --input-csp-scale pc --colormatrix rec709 --fullrange" converted and marked as 709-pc...
This is a "quick-fix" and may changed (maybe using "--colormatrix rec709 --fullrange" for RGB->YUV conversion indicator is better?)
What is better?

P.S. Prior this changes you always get RGB->YUV converted as 601-tv....

[Midzuki]

What ????? :eek:

This time, komisar was faster than Jarod :cool:

r1881 @ komisar.gin.by

-----------

EDIT:

r1882 released on 2011/01/27 O_o

UPDATE:

r1884 released on 2011/01/31

[colinhunt]

May I ask that komisar and MasterNobody take a look at Peter Wimmer's "MVC to AVI Converter" (http://3dtv.at/Downloads/Index_en.aspx) and please try to figure out why it doesn't work with either implementation of x264vfw?

[MasterNobody]

colinhunt
You better readdress this question to Peter Wimmer because this utility doesn't work with most of encoders (both vfw and DirectShow) which I tried so this is not x264vfw specific.

[colinhunt]

colinhunt
You better readdress this question to Peter Wimmer because this utility doesn't work with most of encoders (both vfw and DirectShow) which I tried so this is not x264vfw specific.
Thank you for your reply; I will contact Wimmer.

[Rumbah]

Does anyone know if there is a current version of x264vfw that supports the preset/tune system?

I only found Komisars build and while using the latest x264 version it is horrible ot configure as you have to set every option by hand. And Masternobody's build does not use the latest x264.

[MasterNobody]

Rumbah
I have updated my builds today. Enjoy.

[Rumbah]

Thank you very much!

This way I can quickly determine the matching setting for realtime recording pretty comfortable instead of clicking through all the options by hand.

[Makaveli84]

I'm not sure if this is the place to make such a request, but then again, I'm not sure where else, so here goes:

I use komisar's version, and it seems I can only get rclookahead and mbtree enabled (even in CRF mode for example) through the command line, which would defeat the purpose of using this version for its GUI and ability to set individual settings through it instead of the command line.
Bottom line, komisar, please include the mbtree and rclookahead settings in the GUI (even if for some reason, you wish to leave mbtree disabled by default for all rate control methods.

[komisar]

i plan to refactor gui for vfw... but not so fast... all option will be included in it...

[Makaveli84]

i plan to refactor gui for vfw... but not so fast... all option will be included in it...
Would it be possible meanwhile (until the new GUI is ready) to enable mbtree by default (at least for CRF mode) in an update release?