ThaNeko I don't know how tesa work! But >3 B-frames not good for quality in umh, esa. ref frames =3 its very small! ref frames=5 - 8 better the quality :D

ah ok thx for the info :)

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.

Versions 6_745bm_12293 and 6_745bm_AQ_0.48_12293 of x264vfw Changes (compare to Release Candidate 3): - x264 core updated to svn-745 - ffh264 core updated to revision 12293 P.S. They crash on PC's with SSE2 support so they are not recommended. Use previous versions instead.

Versions 7_747bm_12304 and 7_747bm_AQ_0.48_12304 of 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

Thnx 4 the new release :)

9_763bm_12490 and 9_763bm_AQ_0.48_12490 of x264vfw Changes: - x264 core updated to revision 763 (git-0949975) - Increased compatibility with some buggy applications (nsvate/nsvcap)

You did it man, lived up to the name "BugMaster" thanks a million for the fixing the compatibility issues with nsvcap

Build 14_1016bm_15762 of 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:

Thanks for doing this work for us... Your efforts are very appreciated.

thanhtu5013 If you use VirtualDub or VirtualDubMod then for fixing B-frame encoding lag I would recommend to set "VirtualDub Hack" at the "Main" tab. P.S. There is no such thing as "Packed BitStream" for H.264 (as I know that technique is used only for DivX/XviD).

thanhtu5013 I don't see any missed frames in second video. It has same number of frames as first. Maybe you are referencing to 2 black frames at the begining when opening encoded videos in VirtualDub (you will see them for BOTH videos when new version of x264vfw is installed)? Than it is the known DECODING B-frame lag of x264vfw (you will not see them if open that videos in your DirectShow Player using CoreAVC/ffdshow decoder). Old version of x264vfw also has that DECODING B-frame lag but instead of "2 black frames + 1st frame" it shows "1st frame 3 times" (1 real frame and 2 copies of it) at the begining. Other question. On your newest x264 vfw, "SubPixel refinement" up at "9RDv on all" while the previous up just to 7. Does it means that the quality is better with your newest version ? Probably, yes. This change was made in revision 996 of x264 core: http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=c89bc900a3bf0d4c4c728ad378703970b4f14e18 Rework subme system, add RD refinement in B-frames The new system is as follows: subme6 is RD in I/P frames, subme7 is RD in all frames, subme8 is RD refinement in I/P frames, and subme9 is RD refinement in all frames. subme6 == old subme6, subme7 == old subme6+brdo, subme8 == old subme7+brdo, subme9 == no equivalent --b-rdo has, accordingly, been removed. --bime has also been removed, and instead enabled automatically at subme >= 5. RD refinement in B-frames (subme9) includes both qpel-RD and an RD version of bime.

BugMaster ...I forgot to tell you I watch these videos with VLC Player ( 0.8.6 ). Sorry !... If I open these videos with an another player like Windows Media Player or Media Player Classic, associated with a decoder like CoreAVC or ArcSoft. I can't read without problems of drop frames. So you told right but I knew this already ! My real problem is I don't encode videos to watch them on my computer, if I'll do this, I'll encode x264 videos to a MKV or MP4 container. In France, almost of Internet Companies offers to their customers a "Triple-Play formula" ( Unlimited Internet + Unlimited Téléphone + TV decoder ). It's my case. Maybe in USA that's the same thing. My TV decoder cannot read MKV or MP4 videos, it is able to read MPEG TS and AVI videos. That's why I would mux x264 to AVI with highest performance possible. The both videos I sent you, have the same options about x264 configuration. The only difference is about Subpixel ME Refinement. ( 7 for first video, 9 for the second ) I can read the first video very well with my TV decoder. But I cannot read the second video as well... ( The reading is jerky. I have a lot of drop frames. ) I think this problem could result about B-Frame configuration but it's the same configuration for these both videos... I'll try tomorrow to encode with b-frames options turned off, it's very late in France. P.S: About "VD Hack" option. Does it work with TMPGenc 4.0 Xpress ? I have this software too and it is able to work with VFW codecs as VirtualDub.