x.264vfw Audio delay/crash with AMD X6 Thuban

[Peterxy]

Hello,
I got a new CPU and since then I get an annyoing 150ms Audio Delay.

Software Vdub MPEG2 1.6.19
Codec x.264vfw Rev. 1195
Lame MP3
Checking the "Vdub hack/flag" and/or not to use "audio interleaving" seems to fix it a little bit on my X6 machine.
But if I put a Phenom II X4 955 in the machine I do not get any Delay. So why did the codec produce this Delay just only with X6 Thuban ???
This are the settings: http://www.abload.de/image.php?img=x264o76z.jpg

So OK, I know that the codec is rather old and tried now the newest X.264vfw build from this website:
http://komisar.gin.by/
But this did not help anything, because it still crashes vdub:
http://www.abload.de/thumb/crash1niax.jpg (http://www.abload.de/image.php?img=crash1niax.jpg)

The Komisar x264vfw build works on my X6 Thuban just only @ slow "Sliced-Mode" and I need to "Disable all CPU optimizations", too.
Certainly thats pretty slow. So, whats going wrong here with Thuban X6 + x264vfw?
- whats the reason for the audio delay and why did newer builds just only work by disabling all CPU Optimizations? :confused:

thx. Olaf

[poisondeathray]

what about trying vdub ? vdub mpeg2 hasn't been updated in a few years

[Peterxy]

I tried vdub 1.9.11 and it crashes, too.
The latest Komisar build that works "stable" on my X6 machine is:
x264vfw.1745kMod.generic.x86.exe
All newer builds crash.

[Sharktooth]

OMG, is there still someone using x264vfw?
get an appropriate GUI that supports x264 or use AVIDemux.

[Peterxy]

Yeah and if enough ppl. think a Dodge is fine - I need a Dodge too, right? :p
Dude, be sure- I have a car and don´t need a new car and I use Avidemux and Mediacoder as well = but all this is not the topic, here.

My question was:
What is causing the Audio Delay and why did newer vfw builds crash @ X6 Thuban.

[Sharktooth]

about the audio delay, welcome to VFW and AVI... about the crashes, ask komisar.
VFW support was REMOVED from x264 for a reason...

[komisar]

Peterxy, do you still something wrong (crash/delay) when use VFW from hence (http://sourceforge.net/projects/x264vfw/)?

[MasterNobody]

Peterxy
There was always delay if you don't use VirtualDub Hack or Direct file output or settings with zero latency. As for why you only found it on X6 is probably because it use more threads so delay increased (but it was there before also if you don't used above variants).

As for crash at least save crash log (VirtualDub have such ability) for more info. And post it on any pastebin site (don't use attach of this forum which need approving). But it looks like not aligned access. May be it is problem with misaligned support if so you can try to add to extra command line "--asm SSE2"

Also try build from http://sourceforge.net/projects/x264vfw/

[Peterxy]

Peterxy, do you still something wrong (crash/delay) when use VFW from hence?
All this builds from sourgeforce did not crash.
With the new vfw build from sourgeforce I get a fine 99% CPU load on the X6. :)
With older vfw builds and also with yours Komisar build 1745 (this works stable) I still get only 70-85% load.

But this new sourgeforce builds do not have any Gui/register cards with all the options - it still has "presets" and requieres to do it all via command line.

As for crash at least save crash log (VirtualDub have such ability) for more info.
What log do you exactly mean?
Do you mean the log from the "advanced" button that appears if it vdub crashes? :confused:

[MasterNobody]

What log do you exactly mean?
Do you mean the log from the "advanced" button that appears if it vdub crashes? :confused:
Yes. Look at your own screenshot, there is save button there.

[Sharktooth]

presets, tunings and levels are all you need. all the advanced settings are for advanced users... that is users that DO NOT USE VFW.
messing with advanced settings usually is done for hardware compatibility and in your case, it's not necessary coz there is no hardware that supports h.264 in AVI.

[Peterxy]

presets, tunings and levels are all you need
Sry Sharktooth, I want to use my own settings and a "Gui-click" is simple if it didn´t require any special english knowledge about the command line and how to make any own settings there. (english is not my native language, ok? :cool: )
I use vdub + x264vfw since several years and I am pleased with this. Now with my new X6 there may be a problem, but this did not mean that I am in hurry to kick x264vfw encoding.


Yes. Look at your own screenshot, there is save button there.
Thank you for the help Masternobody. :)

This is the log:
Disassembly:
67ba56a0: 03660f add esp, [esi+0fh]
67ba56a3: 61 popad
67ba56a4: 43 inc ebx
67ba56a5: 02660f add ah, [esi+0fh]
67ba56a8: 6f outsd
67ba56a9: c8660fdb enter 0f66, 0dbh
67ba56ad: 053007e167 add eax, 67e10730
67ba56b2: 660f71d108 psrlw xmm1, 08h
67ba56b7: 660ff5c7 pmaddwd xmm0, xmm7
67ba56bb: 660ff5cf pmaddwd xmm1, xmm7
67ba56bf: 660f6bc1 packssdw xmm0, xmm1
67ba56c3: 90 nop
67ba56c4: f30f6f1c33 movdqu xmm3, [ebx+esi]
67ba56c9: 660f615c3302 punpcklwd xmm3, [ebx+esi+02h]
67ba56cf: 660fd5c6 pmullw xmm0, xmm6
67ba56d3: 660f6fcb movdqa xmm1, xmm3
67ba56d7: 660fdb1d3007e1 pand xmm3, [67e10730]
67
67ba56df: 660f71d108 psrlw xmm1, 08h
67ba56e4: 660ff5df pmaddwd xmm3, xmm7
67ba56e8: 660ff5cf pmaddwd xmm1, xmm7
67ba56ec: 660f6f15a006e1 movdqa xmm2, [67e106a0]
67
67ba56f4: 660f6bd9 packssdw xmm3, xmm1
67ba56f8: 660ffdd0 paddw xmm2, xmm0
67ba56fc: 660f6fc3 movdqa xmm0, xmm3
67ba5700: 660fd5dd pmullw xmm3, xmm5
67ba5704: 660ffdda paddw xmm3, xmm2
67ba5708: 660f71d306 psrlw xmm3, 06h
67ba570d: 660f67db packuswb xmm3, xmm3
67ba5711: 660f7e18 movd [eax], xmm3
67ba5715: 660f73db04 psrldq xmm3, 04h
67ba571a: 660f7e19 movd [ecx], xmm3
67ba571e: 01f3 add ebx, esi
67ba5720: 01d0 add eax, edx
67ba5722: 01d1 add ecx, edx
67ba5724: 4f dec edi
67ba5725: 7f9d jg 67ba56c4
67ba5727: 5f pop edi
67ba5728: 5e pop esi
67ba5729: 5b pop ebx
67ba572a: c3 ret
67ba572b: 660f7f6c2410 movdqa [esp+10h], xmm5
67ba5731: f30f6f1b movdqu xmm3, [ebx]
67ba5735: f30f6f4b08 movdqu xmm1, [ebx+08h]
67ba573a: 660f615b02 punpcklwd xmm3, [ebx+02h] <-- FAULT
67ba573f: 660f614b0a punpcklwd xmm1, [ebx+0ah]
67ba5744: 660f6fd3 movdqa xmm2, xmm3
67ba5748: 660f6fc1 movdqa xmm0, xmm1
67ba574c: 660fdb1d3007e1 pand xmm3, [67e10730]
67
67ba5754: 660fdb0d3007e1 pand xmm1, [67e10730]
67
67ba575c: 660f71d208 psrlw xmm2, 08h
67ba5761: 660f71d008 psrlw xmm0, 08h
67ba5766: 660ff5df pmaddwd xmm3, xmm7
67ba576a: 660ff5d7 pmaddwd xmm2, xmm7
67ba576e: 660ff5cf pmaddwd xmm1, xmm7
67ba5772: 660ff5c7 pmaddwd xmm0, xmm7
67ba5776: 660f6bda packssdw xmm3, xmm2
67ba577a: 660f6bc8 packssdw xmm1, xmm0
67ba577e: 01f3 add ebx, esi
67ba5780: f30f6f23 movdqu xmm4, [ebx]
67ba5784: f30f6f6b08 movdqu xmm5, [ebx+08h]
67ba5789: 660f616302 punpcklwd xmm4, [ebx+02h]
67ba578e: 660f616b0a punpcklwd xmm5, [ebx+0ah]
67ba5793: 660f6fd4 movdqa xmm2, xmm4
67ba5797: 660f6fc5 movdqa xmm0, xmm5
67ba579b: 660fdb25 pand xmm4, [ebp]
67ba579f: 30 db 30h

Built on Shilpa on Thu Sep 27 00:49:58 2007 using compiler version 1200

Windows 5.1 (Windows XP build 2600) [Service Pack 2]

EAX = 05b26ae0
EBX = 05e785e0
ECX = 05b5dce0
EDX = 00000310
EBP = 05b26ae8
ESI = 00000310
EDI = 00000008
ESP = 06ce8340
EIP = 67ba573a
EFLAGS = 00010202
FPUCW = ffff027f
FPUTW = ffffffff

Crash reason: Access Violation

Crash context:
An out-of-bounds memory access (access violation) occurred in module 'x264vfw'...

...reading address FFFFFFFF...

...while compressing frame 11 from 066c0020 to 025a0020 using codec "x264vfw - H.264/MPEG-4 AVC codec" (VideoSequenceCompressor.cpp:618)...

...while running thread "Processing" (thread.cpp:150).

Pointer dumps:

EAX 05b26ae0: 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010
EBX 05e785e0: 80808080 80808080 80808080 80808080 80808080 80808080 80808080 80808080
ECX 05b5dce0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ESP 06ce8340: 05b5dce8 00000008 00000004 67b788c8 00000000 00000000 00000000 00000000
06ce8360: 00000310 00000000 00000000 00000008 00000008 00000654 00000120 00000d80
06ce8380: 07213650 05b26ae0 0000002d 00000310 13131313 00000000 00000000 00000168
06ce83a0: 05f38420 03e664b0 05e72650 00000294 00000000 00001880 05b26ae0 05b5dce0
EBP 05b26ae8: 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010
05b26b08: 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010
05b26b28: 10101111 10101010 10101111 10101010 10101010 10101010 10101010 10101010
05b26b48: 10101010 10101010 10101010 10101010 11111111 11111111 10101010 10101010

Thread call stack:
67ba573a: x264vfw!Configure [67b40000+13d30+51a0a]
67b79729: x264vfw!Configure [67b40000+13d30+259f9]
67d8aaf3: x264vfw!Configure [67b40000+13d30+236dc3]
67b78efe: x264vfw!Configure [67b40000+13d30+251ce]
67b7b338: x264vfw!Configure [67b40000+13d30+27608]
7c920732: ntdll!RtlAllocateHeap [7c910000+105d4+15e]
7c921596: ntdll!wcsncpy [7c910000+10a8f+b07]
7c9206eb: ntdll!RtlAllocateHeap [7c910000+105d4+117]
77c1c86f: msvcrt!_atoldbl [77be0000+3beb8+9b7]
77c1c99b: msvcrt!_atoldbl [77be0000+3beb8+ae3]
77c1ca15: msvcrt!_atoldbl [77be0000+3beb8+b5d]
77c1c603: msvcrt!_atoldbl [77be0000+3beb8+74b]
77c1b501: msvcrt!$I10_OUTPUT [77be0000+3b2ed+214]
77c1b55f: msvcrt!$I10_OUTPUT [77be0000+3b2ed+272]
77c1c06b: msvcrt!_atoldbl [77be0000+3beb8+1b3]
77c1c1a2: msvcrt!_atoldbl [77be0000+3beb8+2ea]
7c921bff: ntdll!RtlInitializeCriticalSection [7c910000+11b2d+d2]
7c929f5d: ntdll!RtlGetNtProductType [7c910000+19e26+137]
7c91d4ea: ntdll!NtAllocateVirtualMemory [7c910000+d4de+c]
7c9280ff: ntdll!RtlReAllocateHeap [7c910000+179fd+702]
7c920732: ntdll!RtlAllocateHeap [7c910000+105d4+15e]
7c920732: ntdll!RtlAllocateHeap [7c910000+105d4+15e]
7c920732: ntdll!RtlAllocateHeap [7c910000+105d4+15e]
7c91e9ab: ntdll!NtWaitForMultipleObjects [7c910000+e99f+c]
7c8094f2: kernel32!CreateFileMappingA [7c800000+946c+86]
7c8095ab: kernel32!WaitForMultipleObjectsEx [7c800000+952a+81]
67d5f477: x264vfw!Configure [67b40000+13d30+20b747]
67d5f477: x264vfw!Configure [67b40000+13d30+20b747]
67d605bd: x264vfw!Configure [67b40000+13d30+20c88d]
67d60782: x264vfw!Configure [67b40000+13d30+20ca52]
67b7c8c5: x264vfw!Configure [67b40000+13d30+28b95]
67b7cadb: x264vfw!Configure [67b40000+13d30+28dab]
67d605bd: x264vfw!Configure [67b40000+13d30+20c88d]
67d65160: x264vfw!Configure [67b40000+13d30+211430]
67b871f8: x264vfw!Configure [67b40000+13d30+334c8]
67da6cb3: x264vfw!Configure [67b40000+13d30+252f83]
67d725d2: x264vfw!Configure [67b40000+13d30+21e8a2]
67b84d98: x264vfw!Configure [67b40000+13d30+31068]
67d79e7c: x264vfw!Configure [67b40000+13d30+22614c]
67b7b00e: x264vfw!Configure [67b40000+13d30+272de]
67b87292: x264vfw!Configure [67b40000+13d30+33562]
67d6048b: x264vfw!Configure [67b40000+13d30+20c75b]
67b7c402: x264vfw!Configure [67b40000+13d30+286d2]
67b6eea6: x264vfw!Configure [67b40000+13d30+1b176]
67b420f3: x264vfw!000020f3
67b4262e: x264vfw!0000262e
67b53453: x264vfw!DriverProc [67b40000+131f0+263]
7c920833: ntdll!RtlAllocateHeap [7c910000+105d4+25f]
7c920833: ntdll!RtlAllocateHeap [7c910000+105d4+25f]
7c80b5b8: kernel32!GetModuleHandleA [7c800000+b529+8f]
7c80b58c: kernel32!GetModuleHandleA [7c800000+b529+63]
7c80b5a1: kernel32!GetModuleHandleA [7c800000+b529+78]
7c925041: ntdll!bsearch [7c910000+14ffb+46]
7c925233: ntdll!bsearch [7c910000+14ffb+238]
7c9255c9: ntdll!RtlHashUnicodeString [7c910000+15465+164]
7c92554a: ntdll!RtlHashUnicodeString [7c910000+15465+e5]
7c9253f5: ntdll!RtlFindActivationContextSectionString [7c910000+15319+dc]
7c925af1: ntdll!RtlDosApplyFileIsolationRedirection_Ustr [7c910000+157a3+34e]
7c925b4f: ntdll!RtlDosApplyFileIsolationRedirection_Ustr [7c910000+157a3+3ac]
7c925707: ntdll!RtlHashUnicodeString [7c910000+15465+2a2]
7c925a00: ntdll!RtlDosApplyFileIsolationRedirection_Ustr [7c910000+157a3+25d]
7c925a65: ntdll!RtlDosApplyFileIsolationRedirection_Ustr [7c910000+157a3+2c2]
7c924859: ntdll!RtlGetLongestNtPathLength [7c910000+147df+7a]
7c923212: ntdll!LdrLockLoaderLock [7c910000+13171+a1]
7c923281: ntdll!LdrUnlockLoaderLock [7c910000+13229+58]
7c923288: ntdll!LdrUnlockLoaderLock [7c910000+13229+5f]
7c92664e: ntdll!LdrGetDllHandleEx [7c910000+165a7+a7]
7c923288: ntdll!LdrUnlockLoaderLock [7c910000+13229+5f]
7c9266f1: ntdll!LdrGetDllHandleEx [7c910000+165a7+14a]
7c92657e: ntdll!LdrLoadDll [7c910000+161ca+3b4]
7c923288: ntdll!LdrUnlockLoaderLock [7c910000+13229+5f]
7c92657e: ntdll!LdrLoadDll [7c910000+161ca+3b4]
7c92659e: ntdll!LdrGetDllHandle [7c910000+16586+18]
7c80e693: kernel32!GetModuleHandleW [7c800000+e63c+57]
7c80e6a3: kernel32!GetModuleHandleW [7c800000+e63c+67]
7c80e693: kernel32!GetModuleHandleW [7c800000+e63c+57]
7c80e6a3: kernel32!GetModuleHandleW [7c800000+e63c+67]
7c80e7ab: kernel32!GetModuleHandleW [7c800000+e63c+16f]
7c80e82b: kernel32!GetModuleHandleW [7c800000+e63c+1ef]
7c80b4b6: kernel32!GetModuleFileNameA [7c800000+b357+15f]
7c80b4cb: kernel32!GetModuleFileNameA [7c800000+b357+174]
7c929bd3: ntdll!LdrGetProcedureAddress [7c910000+19b88+4b]
7c920895: ntdll!RtlImageDirectoryEntryToData [7c910000+10856+3f]
7c929a9c: ntdll!towlower [7c910000+1976c+330]
7c929b3f: ntdll!towlower [7c910000+1976c+3d3]
7c929aeb: ntdll!towlower [7c910000+1976c+37f]
7c929aeb: ntdll!towlower [7c910000+1976c+37f]
7c929aeb: ntdll!towlower [7c910000+1976c+37f]
7c929d27: ntdll!LdrGetProcedureAddress [7c910000+19b88+19f]
7c920833: ntdll!RtlAllocateHeap [7c910000+105d4+25f]
7c920895: ntdll!RtlImageDirectoryEntryToData [7c910000+10856+3f]
7c920833: ntdll!RtlAllocateHeap [7c910000+105d4+25f]
7c920895: ntdll!RtlImageDirectoryEntryToData [7c910000+10856+3f]
7c9137bf: ntdll!RtlConvertUlongToLargeInteger [7c910000+3745+7a]
7c91378b: ntdll!RtlConvertUlongToLargeInteger [7c910000+3745+46]
7c947860: ntdll!LdrAddRefDll [7c910000+37619+247]
7c929aeb: ntdll!towlower [7c910000+1976c+37f]
7c929ba0: ntdll!LdrGetProcedureAddress [7c910000+19b88+18]
7c80ac66: kernel32!GetProcAddress [7c800000+ac28+3e]
7c921538: ntdll!wcsncpy [7c910000+10a8f+aa9]

[Peterxy]

May be it is problem with misaligned support if so you can try to add to extra command line "--asm SSE2"
Wow thanks, you are right it really seems to work now if I add this extra command. :eek:
Have not tried a whole movie, but I test it right now.

[Dark Shikari]

Now that is an interesting crash! It's crashing in x264_mc_chroma_sse2_misalign, a function written for Phenom CPUs using the "misaligned SSE" feature. The "misaligned SSE" feature, however, must be set to enabled or else it will crash.

x264, of course, enables this when it inits its threads...

But if something is broken in a calling app that messes up this flag, problems might occur...

My guess is that Virtualdub is mucking with the SSE control flags via stmxcsr/ldmxcsr. I'm not sure if the responsibility here is x264's to re-set the flags on every entry point, or whether Virtualdub should be fixed to not muck with them and break things.

[Peterxy]

yea, it is somehow interesting that it still happens on my X6 and that it seems I am the first guy having this strange bug. :p
The good news is; the bug is gone with the extra command.

There was always delay if you don't use VirtualDub Hack or Direct file output or settings with zero latency.
Ok, enabling "VirtualDub Hack" seems not to slow down encoding speed and obvisously helps. But what is at last the best and "most sure" work aorund to avoid the Delay?
Disabling "audio/video interleaving" seems to work very good, but results in a slower encoding time, because vdub writes the audio stream after video encoding and this takes extra time.
If I enable "audio/video interleaving" and set "audio block placement" preload 0 - did this also fix the Delay?
(I tried this and seems there is no delay, but I m not sure if it was still luck & really helps)
What do you mean with with "zero latency" and "Direct file output"?

[LoRd_MuldeR]

But what is at last the best and "most sure" work aorund to avoid the Delay?

Not using x264 through the antiquated Video for Windows (VFW) API :p

If you don't want to use x264 from the command-line, there are zillions of GUI's you can choose from:
http://forum.doom9.org/forumdisplay.php?f=78

[MasterNobody]

yea, it is somehow interesting that it still happens on my X6 and that it seems I am the first guy having this strange bug. :p
You not the the first, there was similar bug report here (http://forums.virtualdub.org/index.php?act=ST&f=15&t=19520).
The good news is; the bug is gone with the extra command.
It probably will be fixed in next komisar's build without need of extra command line.

Ok, enabling "VirtualDub Hack" seems not to slow down encoding speed and obvisously helps. But what is at last the best and "most sure" work aorund to avoid the Delay?
"VirtualDub Hack" is the most effective way to fix it when encoding in VirtualDub or it forks.
Disabling "audio/video interleaving" seems to work very good, but results in a slower encoding time, because vdub writes the audio stream after video encoding and this takes extra time.
If I enable "audio/video interleaving" and set "audio block placement" preload 0 - did this also fix the Delay?
(I tried this and seems there is no delay, but I m not sure if it was still luck & really helps)
It may be masks problem sometimes but don't really fix it (it still there but may be not so obvious).
What do you mean with with "zero latency" and "Direct file output"?
I mean these options from new GUI (or "-o <filename>" / "--output <filename>" extra command line option):
http://i51.tinypic.com/9r7wpt.png

[Peterxy]

Thank you a lot Masternobody for the great help.
So, is this switch only for the new Gui or can this zerolatency also be used in this Komisar builds? (the gui didn´t have such zerolatency box/flag)
I tried it in the command line but the komisar console opens and still says:
x264vfw (error): Unknown option or absent argument

Edit: I removed the first (") and last (") but now it says:
could not open output file.

What must I do?

[sneaker_ger]

I assume this is the same as "--tune zerotency"? If yes, it's probably not something you'd want to use:
--bframes 0 --force-cfr --no-mbtree --sync-lookahead 0 --sliced-threads --rc-lookahead 0

[komisar]

Peterxy, please check new release...

p.s. for output to file use-o d:\my_video\test.mp4 in "Extra options:"
use full pathname for output file (d:\my_video\test.mp4)
"test.mp4" may be "test.mkv"|"test.avi"|"test.flv"|"test.264"

[sneaker_ger]

Half OT: Newest experimental offers stdout btw. (http://www.virtualdub.org/blog/pivot/entry.php?id=326).

[Peterxy]

This is really pretty great service, it works fine now and thank you very much Komisar for fixing it.
Output file works, too. :thanks:

I have got still one last question about the CPU Threath usage X4 vs X6.
This is the CPU usage with X4 & X6:
http://www.abload.de/thumb/x264sa66.jpg (http://www.abload.de/image.php?img=x264sa66.jpg)
The X6 did have a noticeable lower CPU Usage, but nevertheless the X6 is a little bit faster then the X4 at same clock speeds (43minutes vs. 35minutes).
I know that there were B-Frames flags that are not able to do full hyperthreathing, but I do not use any B-Frames.

So I am just curiuos if this is a typical and normal CPU usage on Hexacore machines?
Is there anything I can do to improve Threath usage even more on X6 to speed up things a little bit -without losing quality?
My base settings are this: http://www.abload.de/image.php?img=x264o76z.jpg


Half OT: Newest experimental offers stdout btw..
thx. you for the link, but it seems they do not update MPEG2 mod or so? I read something about --sync-lookahead 0, is it usefull to add it, too?

[sneaker_ger]

zerolatency implies sync-lookahead 0, see my post on the last page.

There are quite a few input plugins (http://forums.virtualdub.org/index.php?act=ST&f=7&t=12664) - inlcuding mpeg2 - available. But doing it komisar's way is probably easier anyways.

[nm]

I do not use any B-Frames.

Is there a reason for that aside from the sync issue with AVI and VFW?

Is there anything I can do to improve Threath usage even more on X6 to speed up things a little bit -without losing quality?
My base settings are this: http://www.abload.de/image.php?img=x264o76z.jpg

6 threads are optimal for a quad core CPU. Use 9 threads for 6 cores.

[Peterxy]

Is there a reason for that aside from the sync issue with AVI and VFW?
Omg, I have not known that there is such a plugin.
This was a very good advice - I tried now vdub 1.9.11 + MPEg2 plugin and CPU ujsage is now @90%.
Encoding speed is a lot faster. :thanks:

Seems, my old Vdub MPEg2 was a big bottleneck, too.

Is there a reason for that aside from the sync issue with AVI and VFW?
There is no special reason, the source material are mostly DVB-T Streams and I do not get better quality with B-frames here, it still "takes" more encoding time. The most visual enhance I get if i play around with Psy, Trellis, VAQ, Deblocking values and so on with the blocky/noisy source MPEgs. The final End Size don´t matter that much on 8GB Duallayer. (as so long it is smaller as the original DVB-T file)

[LoRd_MuldeR]

Not using B-Frames will cripple the compression efficiency significantly!

Of course by throwing enough bitrate on it, you'll get good quality, even with such crippled settings. But then you might keep it MPEG-2 instead of re-encoding from the beginning ;)

An 8 GB Dual-Layer media should be more than enough to store a complete movie at the usual broadcast bitrates, especially when it's from DVB-T.

(BTW: It's a common mistake to compare encoder options at bitrates that are far too high and then draw the misleading conclusion that it makes no difference)

[Peterxy]

Endsize of the encodings is around 1.2GB @1500kb bitrate and I mostly put 6 movies on a Dualayer.
You may consider that German DVB-T did not mean HDTV. But the x265 encodings look finally a lot better as the original DVB-T streams. They do not have anymore blocking or ugly artefacts on cam movement like the original MPEg stream, because x264 did have good visual tweaks to avoid/circle around all this.
You can not add more details on low quality source, but you can minimize annyoing things like artefakts.
So, if the source quality is not that good the settings should be balanced in that way that it has good encoding speed without too much loss even if doing this may waste some MB/efficiency.

[LoRd_MuldeR]

Endsize of the encodings is around 1.2GB @1500kb bitrate and I mostly put 6 movies on a Dualayer.

Still, with B-Frames you'd get a significant higher compression efficiency, which means you could get away with a significant lower bitrate (i.e. put more movies on a disc) for the same visual quality.

You may consider that German DVB-T did not mean HDTV. The x265 encodings look a lot better as the original DVB-T streams. They do not have anymore blocking or ugly artefacts on cam movement like the original MPEg stream, because x264 did have good visual tweaks to avoid/circle around all this.

This is impossible by definition. Each re-encoding step to a non-lossless format unavoidably causes a certain generation loss!

At best the generation loss can be minimized, but never can the re-encoded video look better than the original. Detail that isn't in the source, can't magically be restored in the re-encoded clip.

Only exception is when your source has a very specific defect that can be "repaired" using filters. Using H.264 "In-Loop" deblocking to fix blocks in the original is NOT a good idea though...

[Didée]

DVB-T usually is such bad quality that I wouldn't even consider recording it, even less re-encoding it. But then - if the source is of sufficiently bad quality, it is quite possible that you can't see much worthwhile difference between "more efficient" and "less efficient" x264 settings. "More efficient" means you end up closer to the original crappola. "Less efficient" means you end up a little farther from the original crappola, and get a little more of new AVC crappola introduced. In both cases, the end result is crappola. They might smell a little different, but both do smell.

[Peterxy]

Still, with B-Frames you'd get a significant higher compression efficiency, which means you could get away with a significant lower bitrate (i.e. put more movies on a disc) for the same visual quality.
I think you missunderstand me. Enabling B-Frames slows down the encoding speed, but I don´t want to wait any longer as necessary if I recode such DVBT-things. And as so long the final encoding looks still "visual" good for me - it is fine for me. :)

[Peterxy]

And if we can now go back to topic:

The Crashes and Delay :) is meanwhile complettly gone :):):) with the following combination:
# Bugfixed Komisar build and/or Masternobody sourgeforce builds
# Vdub 1.9.11
# MPEG2 plugin
CPU Speed/Usage is fine, too.

So finally I would like to say very much thanks to all the very helpfull ppl. here.
:thanks:

[LoRd_MuldeR]

I think you missunderstand me. Enabling B-Frames slows down the encoding speed, but I don´t want to wait any longer as necessary if I recode such DVBT-things. And as so long the final encoding looks still "visual" good for me - it is fine for me. :)

You know that x264 has two different B-Frame decision methods ("--b-adapt 1" and "--b-adapt 2") with the latter being signification better but also significant slower (especially with high "--bframes" value)? Still using "--b-adapt 1" should be better than not using b-frames at all. Moreover "--bframes" higher than 4-5 usually won't improve things any further and thus will only be slower for no benefit.

[ajp_anton]

DVB-T usually is such bad quality that I wouldn't even consider recording it, even less re-encoding it.
Depends... Some channels here broadcast at DVD-like quality. In fact, with one TV show that I both recorded and had the DVD, the broadcast was better.

[Dark Shikari]

I think you missunderstand me. Enabling B-Frames slows down the encoding speed, but I don´t want to wait any longer as necessary if I recode such DVBT-things. And as so long the final encoding looks still "visual" good for me - it is fine for me. :)Disabling B-frames is a horrible speed/compression tradeoff. Use a faster preset instead.