You can use to open some wmv or asf file
cool right?
thx you,fcchandler!
| Printable Version of Topic
Click here to view this topic in its original format |
| Unofficial VirtualDub Support Forums > News / Announcements > VirtualDub-MPEG2 1.6.15 |
| Posted by: meilin Oct 6 2005, 02:54 AM |
| Download it from fcchandler's home page You can use to open some wmv or asf file cool right? thx you,fcchandler! |
| Posted by: Gral Oct 6 2005, 03:40 AM |
| Now i can open WMV9 file and save it as AVI without recompress ! Great !  (1.6.10 - build 23784) (1.6.11 - build 23777) ??? |
| Posted by: fccHandler Oct 6 2005, 06:58 AM | ||||
Um, yes and no. You're going to run into problems if the WMV uses B-frames, or its audio is VBR. But I guess you'll see what I mean soon... 
For each new version, my build number always starts from Avery's build number and increments from there. This strategy started a long time ago because I was lazy, and now it's too late to change it. I actually have no idea how many times I've built VirtualDub-MPEG2 and its earlier variants, because I didn't keep copies of every build. With this version, it looks like I made more builds of my copy of 1.6.10 than he made in his transition from 1.6.10 to 1.6.11, so this time my build number went backwards! |
| Posted by: phaeron Oct 6 2005, 07:12 AM | ||||
It's not terribly important, since the build number is only used as additional ID, but... the version2.bin file that the build tool (Asuka) maintains contains a separate line for each machine that compiles. If you take a look at it, you can see all of the computer names I've used. Asuka simply adds all of the build numbers from the individual machines, so all you need to do to maintain monotonic build numbers is to merge this file. The only time I've run into problems is when I try to integrate between branches, because then I have the same build line getting incremented on different branches. The build number is pretty handy for detecting when someone is using a non-standard build, I might add. |
| Posted by: fccHandler Oct 6 2005, 07:59 AM | ||||
I know it now, but I didn't in the beginning. To fix it now, I would either have to let it increment independantly from now on, starting from this current number (which would be misleading), or invent some random build number to increment from (which would be false) because I didn't keep most of my old versions. Oh well. I did release a version once with the same build number as yours, and I remember it caused a bit of confusion so I definitely won't do that again.
Yes it is, which reminds me... Why do you freeze the build number with that tricky file (which I won't name)? Some time ago (1.6.8 maybe) I noticed that my builds weren't incrementing, and it took me forever to track that down and kill it. Is it supposed to work like that? Because it seems to be the very opposite of what you would want to happen. |
| Posted by: lantern Oct 7 2005, 12:21 PM |
| I keep getting a crash when I am using VDub-Mpeg2 v1.6.11 when I open a wmv file and begin to encode it to an AVI, if I click the Perf tab in the encoding window. Here is the crashlog: VirtualDub-MPEG2 crash report -- build 23777 (release) -------------------------------------- Disassembly: 004c63a0: 06 push es 004c63a1: 8b17 mov edx, [edi] 004c63a3: 8bcf mov ecx, edi 004c63a5: ff12 call dword ptr [edx] 004c63a7: 8b4e08 mov ecx, [esi+08h] 004c63aa: 85c9 test ecx, ecx 004c63ac: 7405 jz 004c63b3 (InputFileAVI::InitStriped+263) 004c63ae: 8b01 mov eax, [ecx] 004c63b0: ff5004 call dword ptr [eax+04h] 004c63b3: 85ff test edi, edi 004c63b5: 897e08 mov [esi+08h], edi 004c63b8: 7518 jnz 004c63d2 (InputFileAVI::InitStriped+282) 004c63ba: 8d4c2414 lea ecx, [esp+14h] 004c63be: e881960100 call 004dfa44 (MyMemoryError::MyMemoryError) 004c63c3: 68648f5600 push 00568f64 004c63c8: 8d4c2418 lea ecx, [esp+18h] 004c63cc: 51 push ecx 004c63cd: e869f00500 call 0052543b (_CxxThrowException@8) 004c63d2: 8b4e08 mov ecx, [esi+08h] 004c63d5: 8b11 mov edx, [ecx] 004c63d7: ff5208 call dword ptr [edx+08h] 004c63da: 84c0 test al, al 004c63dc: 7513 jnz 004c63f1 (InputFileAVI::InitStriped+2a1) 004c63de: 8b4e08 mov ecx, [esi+08h] 004c63e1: 85c9 test ecx, ecx 004c63e3: 7405 jz 004c63ea (InputFileAVI::InitStriped+29a) 004c63e5: 8b01 mov eax, [ecx] 004c63e7: ff5004 call dword ptr [eax+04h] 004c63ea: c7460800000000 mov dword ptr [esi+08h], 00000000 004c63f1: 8b4c241c mov ecx, [esp+1ch] 004c63f5: 5f pop edi 004c63f6: 5e pop esi 004c63f7: 5d pop ebp 004c63f8: 5b pop ebx 004c63f9: 64890d00000000 mov fs:[00000000], ecx 004c6400: 83c418 add esp, 18h 004c6403: c20400 ret 0004 004c6406: 90 nop 004c6407: 90 nop 004c6408: 90 nop 004c6409: 90 nop 004c640a: 90 nop 004c640b: 90 nop 004c640c: 90 nop 004c640d: 90 nop 004c640e: 90 nop 004c640f: 90 nop 004c6410: 8b4920 mov ecx, [ecx+20h] 004c6413: 8b01 mov eax, [ecx] 004c6415: ff6024 jmp dword ptr [eax+24h] 004c6418: 90 nop 004c6419: 90 nop 004c641a: 90 nop 004c641b: 90 nop 004c641c: 90 nop 004c641d: 90 nop 004c641e: 90 nop 004c641f: 90 nop 004c6420: 8b4920 mov ecx, [ecx+20h] 004c6423: 8b01 mov eax, [ecx] <-- FAULT 004c6425: ff6010 jmp dword ptr [eax+10h] 004c6428: 90 nop 004c6429: 90 nop 004c642a: 90 nop 004c642b: 90 nop 004c642c: 90 nop 004c642d: 90 nop 004c642e: 90 nop 004c642f: 90 nop 004c6430: 8b4920 mov ecx, [ecx+20h] 004c6433: 8b01 mov eax, [ecx] 004c6435: ff6014 jmp dword ptr [eax+14h] 004c6438: 90 nop 004c6439: 90 nop 004c643a: 90 nop 004c643b: 90 nop 004c643c: 90 nop 004c643d: 90 nop 004c643e: 90 nop 004c643f: 90 nop 004c6440: 83ec20 sub esp, 20h 004c6443: 53 push ebx 004c6444: 55 push ebp 004c6445: 56 push esi 004c6446: 8b742430 mov esi, [esp+30h] 004c644a: 8b06 mov eax, [esi] 004c644c: 8b5808 mov ebx, [eax+08h] 004c644f: 57 push edi 004c6450: 8b780c mov edi, [eax+0ch] 004c6453: b8ffffff7f mov eax, 7fffffff 004c6458: 894628 mov [esi+28h], eax 004c645b: 894610 mov [esi+10h], eax 004c645e: 8b07 mov eax, [edi] 004c6460: 8bcf mov ecx, edi 004c6462: 895c2410 mov [esp+10h], ebx 004c6466: ff5010 call dword ptr [eax+10h] 004c6469: 8bea mov ebp, edx 004c646b: 8b17 mov edx, [edi] 004c646d: 8bcf mov ecx, edi 004c646f: 89442428 mov [esp+28h], eax 004c6473: ff5214 call dword ptr [edx+14h] 004c6476: 3bea cmp ebp, edx 004c6478: 8b4c2428 mov ecx, [esp+28h] 004c647c: 89442420 mov [esp+20h], eax 004c6480: 89542424 mov [esp+24h], edx 004c6484: 894c2418 mov [esp+18h], ecx 004c6488: 0f8fe2000000 jg 004c6570 (InputFileAVI::_InfoDlgThread+130) 004c648e: 7c08 jl 004c6498 (InputFileAVI::_InfoDlgThread+58) 004c6490: 3bc8 cmp ecx, eax 004c6492: 0f83d8000000 jnc 004c6570 (InputFileAVI::_InfoDlgThread+130) 004c6498: 8b442418 mov eax, [esp+18h] 004c649c: 8b db 8bh 004c649d: 97 xchg eax, edi 004c649e: b000 mov al, 00h Windows 5.1 (Windows XP build 2600) [Service Pack 2] EAX = 0055cc40 EBX = 00300384 ECX = 00000000 EDX = 7c90eb94 EBP = 0012f4fc ESI = 00b723b8 EDI = 0012f538 ESP = 0012f4c4 EIP = 004c6423 EFLAGS = 00010206 FPUCW = ffff027f FPUTW = ffffffff Crash reason: Access Violation Crash context: An out-of-bounds memory access (access violation) occurred in module 'VirtualDub'. Pointer dumps: EAX 0055cc40: 004fc280 0045ef60 004d5760 004d5570 004c60f0 004c55e0 004c5710 004c5680 EBX 00300380: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 EDX 7c90eb90: 90909090 24a48dc3 00000000 0024648d 90909090 24548d90 c32ecd08 9cec8b55 EDI 7c90eb90: 90909090 24a48dc3 00000000 0024648d 90909090 24548d90 c32ecd08 9cec8b55 ESP 0012f4c0: f3509b9c 00483a07 0012f538 004839ca 00000000 77d48734 00300384 00000113 0012f4e0: 00000000 00000000 004839ca dcbaabcd 00000000 0012f538 004839ca 0012f568 0012f500: 77d5418d 004839ca 00300384 00000113 00000000 00000000 00000113 00300384 0012f520: 00804fb0 00000014 00000001 00000000 00000000 00000010 00000000 ffffffff EBP 0012f4f8: 004839ca 0012f568 77d5418d 004839ca 00300384 00000113 00000000 00000000 0012f518: 00000113 00300384 00804fb0 00000014 00000001 00000000 00000000 00000010 0012f538: 00000000 ffffffff 00000000 00000001 00000000 00000000 0012f518 0012f0e8 0012f558: 0012f650 77d70467 77d541b0 00000000 0012f5b0 77d53fd9 00000000 004839ca Thread call stack: 004c6423: InputFileAVI::isOptimizedForRealtime() 00483a07: DubStatus::StatusPerfDlgProc() 77d48734: USER32!GetDC [77d40000+86c7+6d] 77d5418d: USER32!PrivateExtractIconExW [77d40000+13edb+2b2] 77d53fd9: USER32!PrivateExtractIconExW [77d40000+13edb+fe] 77d484fc: USER32!000084fc 77d485a4: USER32!000085a4 77d6e571: USER32!DefDlgProcA [77d40000+2e54f+22] 77d48734: USER32!GetDC [77d40000+86c7+6d] 77d48816: USER32!GetDC [77d40000+86c7+14f] 77d4b89b: USER32!GetParent [77d40000+b72f+16c] 77d5f3e3: USER32!SendMessageA [77d40000+1f39a+49] 00483bbd: DubStatus::StatusDlgProc() 77d4c331: USER32!SetRectEmpty [77d40000+c2e2+4f] 77d48734: USER32!GetDC [77d40000+86c7+6d] 77d5418d: USER32!PrivateExtractIconExW [77d40000+13edb+2b2] 77d53fd9: USER32!PrivateExtractIconExW [77d40000+13edb+fe] 77d4eb3e: USER32!CallNextHookEx [77d40000+eb03+3b] 77d484fc: USER32!000084fc 77d485a4: USER32!000085a4 77d54204: USER32!DefDlgProcW [77d40000+141e2+22] 77d48734: USER32!GetDC [77d40000+86c7+6d] 77d48816: USER32!GetDC [77d40000+86c7+14f] 77d4eaad: USER32!EnableMenuItem [77d40000+ea2f+7e] 77d489cd: USER32!GetWindowLongW [77d40000+88a6+127] 77d61b4d: USER32!AppendMenuA [77d40000+21adf+6e] 77d48a10: USER32!DispatchMessageW [77d40000+8a01+f] 77d5e097: USER32!IsDialogMessageW [77d40000+1dfbc+db] 77d6c6ab: USER32!IsDialogMessage [77d40000+2c661+4a] 0048a5b1: guiCheckDialogs() 0048a610: VDModelessDialogHookW32() 77d618f4: USER32!UnhookWinEvent [77d40000+2187d+77] 77d4ea9e: USER32!EnableMenuItem [77d40000+ea2f+6f] 77d4ebf3: USER32!CallNextHookEx [77d40000+eb03+f0] 7c90eae3: ntdll!KiUserCallbackDispatcher [7c900000+ead0+13] 77d61b4d: USER32!AppendMenuA [77d40000+21adf+6e] 77d5e0fa: USER32!CallMsgFilterW [77d40000+1e0a6+54] 77d5e016: USER32!IsDialogMessageW [77d40000+1dfbc+5a] 77d6c6ab: USER32!IsDialogMessage [77d40000+2c661+4a] 0048a5b1: guiCheckDialogs() 004a3120: VDProjectUI::UIRunDubMessageLoop() 0049e8cf: VDProject::RunOperation() 7c9106eb: ntdll!RtlAllocateHeap [7c900000+105d4+117] 00524acf: _heap_alloc() 00477e51: SaveAVI() 00490d6f: SaveAVI() 004a0735: VDProjectUI::MenuHit() 77d49488: USER32!GetWindowLongA [77d40000+945d+2b] 77d4b3a7: USER32!DefWindowProcW [77d40000+b33c+6b] 004a9a41: VDUIFrame::DefProc() 004a23bb: VDProjectUI::MainWndProc() 77d48734: USER32!GetDC [77d40000+86c7+6d] 77d484fc: USER32!000084fc 77d485a4: USER32!000085a4 77d49488: USER32!GetWindowLongA [77d40000+945d+2b] 004a1f6e: VDProjectUI::WndProc() 004a9d04: VDUIFrame::StaticWndProc() 77d48734: USER32!GetDC [77d40000+86c7+6d] 77d48816: USER32!GetDC [77d40000+86c7+14f] 77d489cd: USER32!GetWindowLongW [77d40000+88a6+127] 77d4ca67: USER32!PeekMessageA [77d40000+c96c+fb] 77d496c7: USER32!DispatchMessageA [77d40000+96b8+f] 004909a6: WinMain@16() 00527ecf: WinMainCRTStartup() 7c816d4f: kernel32!RegisterWaitForInputIdle [7c800000+16d06+49] -- End of report |
| Posted by: fccHandler Oct 7 2005, 06:31 PM |
| Confirmed. I'll add this to my bug list. Thanks for the report. |
| Posted by: phaeron Oct 8 2005, 04:20 AM | ||
The build number in the executable has to match the build number in the symbols file, or the crash-time debugger won't work. I used to have problems generating final builds because if I didn't do everything in the right sequence and edit/revert the right files at the right time the build numbers would be wrong on one or more of the platform builds, causing crash dumps to break. The build release script (release.bat) used to sync and then revert the version2.bin file to do that, but adding the autobuild.lock file was a cleaner way to do it. Environment variable would have been even better, but by default Visual Studio doesn't pass on the calling environment when invoking the build. There's no reason to ship that file, so I've changed the build process to remove the file before building the final archives. |
| Posted by: fccHandler Oct 8 2005, 08:16 AM |
| Thanks. I've also noticed that if I download the source, delete autobuild.lock, and make one build on my computer, the resulting build number is the same as yours. I have to make two builds before it increments by one. (The current VirtualDub-MPEG2 1.6.11 / 23777 has been built four times.) Not terribly important, just I thought I'd mention it. |
| Posted by: fccHandler Oct 9 2005, 04:40 AM |
I uploaded a http://fcchandler.home.comcast.net/stable which fixes the crash posted by lantern above. My derived "InputFileWMV" class wasn't as well derived as I thought...  In other news, it turns out that my earlier post about B-frames may be incorrect. I'm not actually sure that WMV9 Standard uses them, and I haven't had any problems using Direct Stream Copy. The WMV9 "Advanced Profile" codec can use B-frames, but this codec isn't supported by Microsoft's VCM implementation and can't be used in VirtualDub at all. VBR WMA9 is still a problem, even while playing and seeking on the timeline. This part definitely needs more work. P.S. I'm moving this thread to the "News" section, so it can be the official VirtualDub-MPEG2 1.6.11 thread. |
| Posted by: KornX Oct 11 2005, 10:16 AM |
| hey fcchandler the new possibility to open wmv files is amazing... perfect to look at HD wmv files... KornX |
| Posted by: marindd Oct 12 2005, 06:17 PM |
| VirtualDub-MPEG2 crash report -- build 23787 (release) -------------------------------------- Disassembly: 09a04f40: 03c9 add ecx, ecx 09a04f42: 03c9 add ecx, ecx 09a04f44: 03c9 add ecx, ecx 09a04f46: 33d2 xor edx, edx 09a04f48: 895dc4 mov [ebp-3ch], ebx 09a04f4b: 8bd8 mov ebx, eax 09a04f4d: 894db4 mov [ebp-4ch], ecx 09a04f50: 8975b8 mov [ebp-48h], esi 09a04f53: 897dbc mov [ebp-44h], edi 09a04f56: 8b7b0c mov edi, [ebx+0ch] 09a04f59: 8d77e7 lea esi, [edi-19h] 09a04f5c: b8ffffffff mov eax, ffffffff 09a04f61: 8bcf mov ecx, edi 09a04f63: d3e8 shr eax, cl 09a04f65: 8b0b mov ecx, [ebx] 09a04f67: 85f6 test esi, esi 09a04f69: 894da8 mov [ebp-58h], ecx 09a04f6c: 0f8e4e060000 jle 09a055c0 09a04f72: 2345a8 and eax, [ebp-58h] 09a04f75: 8bce mov ecx, esi 09a04f77: f7de neg esi 09a04f79: 8945b0 mov [ebp-50h], eax 09a04f7c: 83c620 add esi, 20h 09a04f7f: d3e0 shl eax, cl 09a04f81: 8b4b04 mov ecx, [ebx+04h] 09a04f84: 894da4 mov [ebp-5ch], ecx 09a04f87: 8bce mov ecx, esi 09a04f89: 8b75a4 mov esi, [ebp-5ch] 09a04f8c: d3ee shr esi, cl 09a04f8e: 0bc6 or eax, esi 09a04f90: 8945ac mov [ebp-54h], eax 09a04f93: 8b45b0 mov eax, [ebp-50h] 09a04f96: 8b75ac mov esi, [ebp-54h] 09a04f99: 83fe03 cmp esi, 03h 09a04f9c: 0f8414010000 jz 09a050b6 09a04fa2: 8d4fec lea ecx, [edi-14h] 09a04fa5: 85c9 test ecx, ecx 09a04fa7: 0f8e85050000 jle 09a05532 09a04fad: 8b7304 mov esi, [ebx+04h] 09a04fb0: d3e0 shl eax, cl 09a04fb2: f7d9 neg ecx 09a04fb4: 83c120 add ecx, 20h 09a04fb7: d3ee shr esi, cl 09a04fb9: 0bc6 or eax, esi 09a04fbb: 03c0 add eax, eax 09a04fbd: 8d3400 lea esi, [eax+eax] 09a04fc0: 0fbeb6e3caa709 movsx esi, byte ptr [esi+9a7cae3] <-- FAULT 09a04fc7: 8975ac mov [ebp-54h], esi 09a04fca: 85f6 test esi, esi 09a04fcc: 0f84e8010000 jz 09a051ba 09a04fd2: 0fb6b400e1caa7 movzx esi, byte ptr [eax+eax+9a7cae1] 09 09a04fda: 8975c4 mov [ebp-3ch], esi 09a04fdd: 0fb6b400e2caa7 movzx esi, byte ptr [eax+eax+9a7cae2] 09 09a04fe5: 0fb68400e0caa7 movzx eax, byte ptr [eax+eax+9a7cae0] 09 09a04fed: 03f8 add edi, eax 09a04fef: 83ff20 cmp edi, 20h 09a04ff2: 7233 jc 09a05027 09a04ff4: 897b0c mov [ebx+0ch], edi 09a04ff7: 8b4b04 mov ecx, [ebx+04h] 09a04ffa: 8b7b10 mov edi, [ebx+10h] 09a04ffd: 890b mov [ebx], ecx 09a04fff: 8b4f08 mov ecx, [edi+08h] 09a05002: 894dd0 mov [ebp-30h], ecx 09a05005: 8b45d0 mov eax, [ebp-30h] 09a05008: 0fc8 bswap eax 09a0500a: 8945d0 mov [ebp-30h], eax 09a0500d: 8b7dd0 mov edi, [ebp-30h] 09a05010: 8b4b10 mov ecx, [ebx+10h] 09a05013: 83c104 add ecx, 04h 09a05016: 897b04 mov [ebx+04h], edi 09a05019: 8b7b0c mov edi, [ebx+0ch] 09a0501c: 83c7e0 add edi, 0e0h 09a0501f: 894b10 mov [ebx+10h], ecx 09a05022: 8b03 mov eax, [ebx] 09a05024: 8945a8 mov [ebp-58h], eax 09a05027: 897dcc mov [ebp-34h], edi 09a0502a: 8d47e1 lea eax, [edi-1fh] 09a0502d: 8bcf mov ecx, edi 09a0502f: 8945b0 mov [ebp-50h], eax 09a05032: bfffffffff mov edi, ffffffff 09a05037: d3ef shr edi, cl 09a05039: 85c0 test eax, eax 09a0503b: 897da4 mov [ebp-5ch], edi 09a0503e: 8b db 8bh 09a0503f: 7d db 7dh Windows 5.1 (Windows XP build 2600) [Service Pack 2] EAX = 8e65ddf4 EBX = 0c00df98 ECX = 00000000 EDX = 00000000 EBP = 0c00d8b0 ESI = 1ccbbbe8 EDI = 00000034 ESP = 0c00d854 EIP = 09a04fc0 EFLAGS = 00010293 FPUCW = ffff027f FPUTW = ffffaaaa Crash reason: Access Violation Crash context: An out-of-bounds memory access (access violation) occurred in module 'xvidcore'... ...while running thread "Processing" (thread.cpp:150). Pointer dumps: EBX 0c00df98: ae205aba c732e6c2 00000000 00000034 097f1f38 097f0020 001c2000 00000000 ESP 0c00d850: 0012fa8c c732e6c2 ae205aba d6399736 00000aba 00000000 0c00d900 00000100 0c00d870: 0c00d900 00000303 00000303 00000004 0023ae5b 00000000 00000000 00000000 0c00d890: 00000000 00000000 0c00db80 00000302 09a0f02b 0c00db80 09a0f20b 0a777748 0c00d8b0: 00000008 09a0f005 00000000 00000000 00000085 09a38df0 00000000 00000000 EBP 0c00d8b0: 00000008 09a0f005 00000000 00000000 00000085 09a38df0 00000000 00000000 0c00d8d0: 00000001 00000005 0c00df98 00000300 00001800 00000180 09dc55c0 0c00da00 0c00d8f0: 0c00d900 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0c00d910: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Thread call stack: 09a04fc0: xvidcore!xvid_decore [099c0000+3f684+593c] 09a0f02b: xvidcore!xvid_decore [099c0000+3f684+f9a7] 09a0f20b: xvidcore!xvid_decore [099c0000+3f684+fb87] 09a0f005: xvidcore!xvid_decore [099c0000+3f684+f981] 09a0ee73: xvidcore!xvid_decore [099c0000+3f684+f7ef] 09a0e172: xvidcore!xvid_decore [099c0000+3f684+eaee] 09a0ee8e: xvidcore!xvid_decore [099c0000+3f684+f80a] 09a0eeb5: xvidcore!xvid_decore [099c0000+3f684+f831] 09a022be: xvidcore!xvid_decore [099c0000+3f684+2c3a] 09a021e2: xvidcore!xvid_decore [099c0000+3f684+2b5e] 099ffc33: xvidcore!xvid_decore [099c0000+3f684+5af] 7c915041: ntdll!bsearch [7c900000+14ffb+46] 7c915233: ntdll!bsearch [7c900000+14ffb+238] 7c9155c9: ntdll!RtlHashUnicodeString [7c900000+15465+164] 7c915d7d: ntdll!RtlValidateUnicodeString [7c900000+15c72+10b] 7c915db4: ntdll!RtlValidateUnicodeString [7c900000+15c72+142] 7c9153f5: ntdll!RtlFindActivationContextSectionString [7c900000+15319+dc] 7c915041: ntdll!bsearch [7c900000+14ffb+46] 7c915233: ntdll!bsearch [7c900000+14ffb+238] 7c9155c9: ntdll!RtlHashUnicodeString [7c900000+15465+164] 7c915d7d: ntdll!RtlValidateUnicodeString [7c900000+15c72+10b] 7c915db4: ntdll!RtlValidateUnicodeString [7c900000+15c72+142] 7c9153f5: ntdll!RtlFindActivationContextSectionString [7c900000+15319+dc] 7c915041: ntdll!bsearch [7c900000+14ffb+46] 7c915041: ntdll!bsearch [7c900000+14ffb+46] 7c915233: ntdll!bsearch [7c900000+14ffb+238] 7c9155c9: ntdll!RtlHashUnicodeString [7c900000+15465+164] 7c915d7d: ntdll!RtlValidateUnicodeString [7c900000+15c72+10b] 7c915db4: ntdll!RtlValidateUnicodeString [7c900000+15c72+142] 7c9153f5: ntdll!RtlFindActivationContextSectionString [7c900000+15319+dc] 7c915af1: ntdll!RtlDosApplyFileIsolationRedirection_Ustr [7c900000+157a3+34e] 7c915b4f: ntdll!RtlDosApplyFileIsolationRedirection_Ustr [7c900000+157a3+3ac] 7c9153f5: ntdll!RtlFindActivationContextSectionString [7c900000+15319+dc] 7c915707: ntdll!RtlHashUnicodeString [7c900000+15465+2a2] 7c915a00: ntdll!RtlDosApplyFileIsolationRedirection_Ustr [7c900000+157a3+25d] 7c915a65: ntdll!RtlDosApplyFileIsolationRedirection_Ustr [7c900000+157a3+2c2] 7c9169a5: ntdll!RtlMultiAppendUnicodeStringBuffer [7c900000+1671b+28a] 7c91691d: ntdll!RtlMultiAppendUnicodeStringBuffer [7c900000+1671b+202] 7c916924: ntdll!RtlMultiAppendUnicodeStringBuffer [7c900000+1671b+209] 7c910833: ntdll!RtlAllocateHeap [7c900000+105d4+25f] 7c9169a5: ntdll!RtlMultiAppendUnicodeStringBuffer [7c900000+1671b+28a] 7c910732: ntdll!RtlAllocateHeap [7c900000+105d4+15e] 7c910732: ntdll!RtlAllocateHeap [7c900000+105d4+15e] 7c910732: ntdll!RtlAllocateHeap [7c900000+105d4+15e] 7c9106ab: ntdll!RtlAllocateHeap [7c900000+105d4+d7] 7c9106eb: ntdll!RtlAllocateHeap [7c900000+105d4+117] 7c910732: ntdll!RtlAllocateHeap [7c900000+105d4+15e] 7c910732: ntdll!RtlAllocateHeap [7c900000+105d4+15e] 7c911596: ntdll!wcsncpy [7c900000+10a8f+b07] 7c9106eb: ntdll!RtlAllocateHeap [7c900000+105d4+117] 7c9169a5: ntdll!RtlMultiAppendUnicodeStringBuffer [7c900000+1671b+28a] 7c916924: ntdll!RtlMultiAppendUnicodeStringBuffer [7c900000+1671b+209] 7c916924: ntdll!RtlMultiAppendUnicodeStringBuffer [7c900000+1671b+209] 7c9168a6: ntdll!RtlMultiAppendUnicodeStringBuffer [7c900000+1671b+18b] 7c9105c8: ntdll!RtlFreeHeap [7c900000+1043d+18b] 7c910551: ntdll!RtlFreeHeap [7c900000+1043d+114] 7c91056d: ntdll!RtlFreeHeap [7c900000+1043d+130] 7c911b09: ntdll!RtlLogStackBackTrace [7c900000+11ae4+25] 7c9105c8: ntdll!RtlFreeHeap [7c900000+1043d+18b] 7c910551: ntdll!RtlFreeHeap [7c900000+1043d+114] 7c91056d: ntdll!RtlFreeHeap [7c900000+1043d+130] 7c910d5c: ntdll!wcsncpy [7c900000+10a8f+2cd] 7c91056d: ntdll!RtlFreeHeap [7c900000+1043d+130] 7c9119e6: ntdll!RtlDeleteCriticalSection [7c900000+1188a+15c] 7c91056d: ntdll!RtlFreeHeap [7c900000+1043d+130] 7c911962: ntdll!RtlDeleteCriticalSection [7c900000+1188a+d8] 7c9105c8: ntdll!RtlFreeHeap [7c900000+1043d+18b] 7c910551: ntdll!RtlFreeHeap [7c900000+1043d+114] 7c91056d: ntdll!RtlFreeHeap [7c900000+1043d+130] 7c911970: ntdll!RtlDeleteCriticalSection [7c900000+1188a+e6] 7c90da54: ntdll!NtFreeVirtualMemory [7c900000+da48+c] 7c918331: ntdll!RtlReAllocateHeap [7c900000+179fd+934] 7c925eac: ntdll!RtlDestroyHeap [7c900000+25d96+116] 7c913281: ntdll!LdrUnlockLoaderLock [7c900000+13229+58] 7c913288: ntdll!LdrUnlockLoaderLock [7c900000+13229+5f] 7c913288: ntdll!LdrUnlockLoaderLock [7c900000+13229+5f] 7c91a08b: ntdll!LdrUnloadAlternateResourceModule [7c900000+1a029+62] 7c91056d: ntdll!RtlFreeHeap [7c900000+1043d+130] 7c91e882: ntdll!LdrDisableThreadCalloutsForDll [7c900000+1ddab+ad7] 7c91e85c: ntdll!LdrDisableThreadCalloutsForDll [7c900000+1ddab+ab1] 7c917326: ntdll!LdrUnloadDll [7c900000+1718b+19b] 7c917304: ntdll!LdrUnloadDll [7c900000+1718b+179] 7c917304: ntdll!LdrUnloadDll [7c900000+1718b+179] 7c80aa7f: kernel32!FreeLibrary [7c800000+aa66+19] 77d5e5d9: USER32!FindWindowA [77d40000+1e581+58] 7c90eae3: ntdll!KiUserCallbackDispatcher [7c900000+ead0+13] 77d494be: USER32!GetWindowLongA [77d40000+945d+61] 77d4b903: USER32!SendMessageW [77d40000+b8ba+49] 77d56623: USER32!IsDlgButtonChecked [77d40000+165fc+27] 10007b26: xvidvfw!DriverProc [10000000+6464+16c2] 100079ae: xvidvfw!DriverProc [10000000+6464+154a] 099db7a9: xvidcore!xvid_encore [099c0000+1b760+49] 1000785a: xvidvfw!DriverProc [10000000+6464+13f6] 1000685f: xvidvfw!DriverProc [10000000+6464+3fb] 099ff6b9: xvidcore!xvid_decore [099c0000+3f684+35] 100066eb: xvidvfw!DriverProc [10000000+6464+287] 7c910833: ntdll!RtlAllocateHeap [7c900000+105d4+25f] 7c910833: ntdll!RtlAllocateHeap [7c900000+105d4+25f] 7c80b5b8: kernel32!GetModuleHandleA [7c800000+b529+8f] 7c80b58c: kernel32!GetModuleHandleA [7c800000+b529+63] -- End of report |
| Posted by: fccHandler Oct 13 2005, 02:45 AM | ||
The Xvid codec crashed. Do you know what Xvid version you have? Try removing it, and installing a different version of Xvid. |
| Posted by: Moitah Oct 25 2005, 01:54 AM |
I'm seeing something weird with chroma in http://www.moitah.net/misc/enc16.m2v (720x480 interlaced). Open the video, add a resize filter (720x240 nearest neighbor) to discard half the fields. Use Ctrl+G to jump to frame 145. Press the right arrow key twice to arrive at frame 147. You should see this: Press the left arrow key once to go to frame 146, and then the right arrow key again to go to 147 again. This shows now:  Notice the chroma is off, here is the difference between the 2 decodings of frame 147:  You can keep reproducing by going back 1 frame/forward 1 frame to get one result, or going back 2 frames/forward 2 frames to get the other result. EDIT: I guess this is a known bug discussed in the VirtualDub-MPEG2 1.6.10 thread? |
| Posted by: neuron2 Oct 25 2005, 03:47 AM |
| . |
| Posted by: neuron2 Oct 25 2005, 03:47 AM |
| I confirm your result with VirtualDub MPEG2. I used the internal deinterlace filter with discard field 2 instead of the resize. Very interesting. (It doesn't happen with DGMPGDec.) |
| Posted by: fccHandler Oct 25 2005, 08:30 AM |
| Confirmed, and thanks for posting the clip. I'll see if I can figure out what causes this. Update: I believe I've found the problem. Hopefully I can upload a fix tonight. |
| Posted by: Elias Nov 18 2005, 01:35 PM |
| The latest VirtualDub-MPEG2 build can direct stream copy wmv movies to avi (thanks a lot fcchandler!). Is it possible to do some changes with the fourcc code (MP43/S-Mpeg 4 version 3) to something like XviD and then import the avi file with MP4Box to mp4? |
| Posted by: stephanV Nov 18 2005, 02:11 PM |
| MS-MPEG4 is not MPEG4 compatible, so i dont see the sense in that... |
| Posted by: fccHandler Dec 5 2005, 06:24 PM | ||
My belief was wrong. I didn't find the problem a month ago, but until today I haven't had time to work on it. I finally found the bug and uploaded a fix. To explain, the MMX version of my 4:2:0 to 4:2:2 upsampling function accepts a "progressive_frame" parameter which is declared as a "bool". Apparently "bool" is an 8-bit value in C++, meaning its upper 24 bits are undefined. The ASM function was treating it as a 32-bit DWORD value. Aargh... |
| Posted by: KornX Dec 5 2005, 11:06 PM |
| @ fcchandler have you received any mail from microsoft like Avery has regarding the wmv/asf support?  KornX |
| Posted by: fccHandler Dec 6 2005, 03:42 AM |
| No. I don't expect Microsoft is aware of me, or that they would even bother. Besides, they now offer the full http://www.microsoft.com/windows/windowsmedia/format/asfspec.aspx on their site, and it's public knowledge. |
| Posted by: KornX Dec 6 2005, 12:19 PM |
| oh, i wasn't aware of this document... anyway, thx for the info.. KornX |
| Posted by: one2one Dec 16 2005, 04:23 PM |
| i need help. VirtualDub-MPEG2 crash report -- build 23787 (release) -------------------------------------- Disassembly: 06859f60: 40 inc eax 06859f61: 8b4004 mov eax, [eax+04h] 06859f64: d3e8 shr eax, cl 06859f66: 09442444 or [esp+44h], eax 06859f6a: eb13 jmp 06859f7f 06859f6c: 8b4c2440 mov ecx, [esp+40h] 06859f70: 8b4104 mov eax, [ecx+04h] 06859f73: 8b4c2460 mov ecx, [esp+60h] 06859f77: f7d9 neg ecx 06859f79: d3e8 shr eax, cl 06859f7b: 89442444 mov [esp+44h], eax 06859f7f: 8b4c2444 mov ecx, [esp+44h] 06859f83: 83f901 cmp ecx, 01h 06859f86: 756d jnz 06859ff5 06859f88: 83c4e4 add esp, 0e4h 06859f8b: 8b4c2474 mov ecx, [esp+74h] 06859f8f: 8d8424a0000000 lea eax, [esp+a0] 06859f96: 8944240c mov [esp+0ch], eax 06859f9a: 83c1ff add ecx, 0ffh 06859f9d: 8d8424a4000000 lea eax, [esp+a4] 06859fa4: 89442410 mov [esp+10h], eax 06859fa8: 8d8424a8000000 lea eax, [esp+a8] 06859faf: 8bd5 mov edx, ebp 06859fb1: 89442414 mov [esp+14h], eax 06859fb5: 8d44243c lea eax, [esp+3ch] 06859fb9: 89442418 mov [esp+18h], eax 06859fbd: 8b44245c mov eax, [esp+5ch] 06859fc1: e89682ffff call 0685225c 06859fc6: 83c41c add esp, 1ch 06859fc9: 8b8d10450100 mov ecx, [ebp+14510] 06859fcf: 33d2 xor edx, edx 06859fd1: f7f1 div eax, ecx 06859fd3: 33c9 xor ecx, ecx 06859fd5: 898d3c450100 mov [ebp+1453c], ecx 06859fdb: 89442450 mov [esp+50h], eax 06859fdf: 89542464 mov [esp+64h], edx 06859fe3: 898d40450100 mov [ebp+14540], ecx 06859fe9: 898d34450100 mov [ebp+14534], ecx 06859fef: 898d38450100 mov [ebp+14538], ecx 06859ff5: c7443710000000 mov dword ptr [edi+esi+10h], 00000000 <-- FAULT 00 06859ffd: 33c9 xor ecx, ecx 06859fff: 894c3718 mov [edi+esi+18h], ecx 0685a003: c7443714000000 mov dword ptr [edi+esi+14h], 00000000 00 0685a00b: 894c371c mov [edi+esi+1ch], ecx 0685a00f: 33c9 xor ecx, ecx 0685a011: c7443708000000 mov dword ptr [edi+esi+08h], 00000000 00 0685a019: 894c2458 mov [esp+58h], ecx 0685a01d: 33c9 xor ecx, ecx 0685a01f: c744370c000000 mov dword ptr [edi+esi+0ch], 00000000 00 0685a027: 894c245c mov [esp+5ch], ecx 0685a02b: c7043700000000 mov dword ptr [edi+esi], 00000000 0685a032: c7443704000000 mov dword ptr [edi+esi+04h], 00000000 00 0685a03a: c7843778010000 mov dword ptr [edi+esi+178], 00000000 00000000 0685a045: c784377c010000 mov dword ptr [edi+esi+17c], 00000000 00000000 0685a050: c7843770010000 mov dword ptr [edi+esi+170], 00000000 00000000 0685a05b: c7 db 0c7h 0685a05c: 8437 test [edi], dh 0685a05e: 7401 jz 0685a061 Windows 5.1 (Windows XP build 2600) [Service Pack 2] EAX = 000000c0 EBX = 073f6574 ECX = 00000007 EDX = 0000007f EBP = 07110080 ESI = 074481f4 EDI = 00069980 ESP = 07d1e4ec EIP = 06859ff5 EFLAGS = 00010216 FPUCW = ffff027f FPUTW = ffffaaaa Crash reason: Access Violation Crash context: An out-of-bounds memory access (access violation) occurred in module 'xvidcore'... ...while running thread "Processing" (thread.cpp:150). Pointer dumps: EBX 073f6570: 00000000 00000001 00000001 00000001 00000001 00000001 00000001 00000001 ESP 07d1e4e8: 0012fa8c 0814e7e4 24f0c608 00000000 ffffffe0 00000000 aa972cb0 387b0000 07d1e508: d50fc03c 00000011 0744b358 0004e580 07110080 f84a1242 b2bdd879 073f96d8 07d1e528: 0000001e 07d1ed88 d50fc03c 00000008 074b1b74 0000001f 00000010 00000001 07d1e548: 00000011 00000000 00000001 07110080 00000000 00000002 00000001 068501e8 EBP 07110080: 00000019 00000000 00000005 00000000 00000005 00000000 07124700 00000000 071100a0: 00000001 00000001 00000000 00000000 00000000 00000000 00000000 00000000 071100c0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 071100e0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Thread call stack: 06859ff5: xvidcore!xvid_decore [067f0000+5ebb0+b445] 068501e8: xvidcore!xvid_decore [067f0000+5ebb0+1638] 0681cefb: xvidcore!xvid_encore [067f0000+2ceb0+4b] 0684ebe5: xvidcore!xvid_decore [067f0000+5ebb0+35] 013b8bc8: xvidvfw!DriverProc [013b0000+891c+2ac] 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] 7c80b4b6: kernel32!GetModuleFileNameA [7c800000+b357+15f] 7c80b4cb: kernel32!GetModuleFileNameA [7c800000+b357+174] 7c921538: ntdll!wcsncpy [7c910000+10a8f+aa9] 7c921596: ntdll!wcsncpy [7c910000+10a8f+b07] 7c9206eb: ntdll!RtlAllocateHeap [7c910000+105d4+117] 7c920732: ntdll!RtlAllocateHeap [7c910000+105d4+15e] 7c920732: ntdll!RtlAllocateHeap [7c910000+105d4+15e] 7c9206ab: ntdll!RtlAllocateHeap [7c910000+105d4+d7] 7c9206eb: ntdll!RtlAllocateHeap [7c910000+105d4+117] 7c920732: ntdll!RtlAllocateHeap [7c910000+105d4+15e] 7c921596: ntdll!wcsncpy [7c910000+10a8f+b07] 7c9206eb: ntdll!RtlAllocateHeap [7c910000+105d4+117] 7c920732: ntdll!RtlAllocateHeap [7c910000+105d4+15e] 7c920732: ntdll!RtlAllocateHeap [7c910000+105d4+15e] 7c9206ab: ntdll!RtlAllocateHeap [7c910000+105d4+d7] 7c9206eb: ntdll!RtlAllocateHeap [7c910000+105d4+117] 7c91d4ea: ntdll!NtAllocateVirtualMemory [7c910000+d4de+c] 7c9280ff: ntdll!RtlReAllocateHeap [7c910000+179fd+702] 7c921bff: ntdll!RtlInitializeCriticalSection [7c910000+11b2d+d2] 7c92825d: ntdll!RtlReAllocateHeap [7c910000+179fd+860] 7c921538: ntdll!wcsncpy [7c910000+10a8f+aa9] 7c921596: ntdll!wcsncpy [7c910000+10a8f+b07] 7c9206eb: ntdll!RtlAllocateHeap [7c910000+105d4+117] 7c947860: ntdll!LdrAddRefDll [7c910000+37619+247] 0050aec2: VDResamplerSeparableCubicRowStageMMX::Process() 0050af65: VDResamplerSeparableCubicColStageMMX::Process() 00509e17: VDResamplerSeparableStage::ProcessComplex() 75ec18a8: MSVFW32!ICSendMessage [75ec0000+187d+2b] 75ec4c09: MSVFW32!ICCompress [75ec0000+4ba6+63] 004ae882: VideoSequenceCompressor::PackFrameInternal() 004ae536: VideoSequenceCompressor::packFrame() 75ec18a8: MSVFW32!ICSendMessage [75ec0000+187d+2b] 75ec4c4d: MSVFW32!ICDecompress [75ec0000+4c10+3d] 0047f6f6: Dubber::WriteVideoFrame() 0047f024: Dubber::WriteVideoFrame() 0047fc6f: Dubber::ThreadRun() 7c91d919: ntdll!NtDuplicateObject [7c910000+d90d+c] 7c80e07b: kernel32!DuplicateHandle [7c800000+e016+65] 004df628: VDThread::StaticThreadStart() 005285ff: _threadstartex@4() 7c80b50b: kernel32!GetModuleFileNameA [7c800000+b357+1b4] -- End of report |
| Posted by: snoclowNIX Jan 3 2006, 11:14 PM |
| Just wanted to get this straight. VirtualDub-MPEG2 is for MPEG2 > AVI only, correct? So you can work with MPEG2 files? |
| Posted by: fccHandler Jan 8 2006, 05:17 AM | ||||
Your Xvid codec crashed; I don't know why. Try installing a different version, or a different build of the Xvid codec.
Yes. Plus the latest version has experimental support for opening ASF/WMV files. Some other minor changes are detailed in the http://fcchandler.home.comcast.net/stable/changelog.html for VirtualDub-MPEG2. |
| Posted by: kewl Jan 8 2006, 07:21 AM |
| Request to fccHandler ----------------------------- Hi, in the next version could the state of the 'Honor "repeat first field" ' flag, which is at the moment enabled by default, be remembered? I don't want it to be enabled by default when I use ' ddub.exe /p <filename1> <filename2> ' and I haven't found any solution. The thing is that I'm converting MPEG2 NTSC and Virtualdub MPEG2 1.6.11 believes it is 29.97fps when this flag is ON. |
| Posted by: ant Jan 8 2006, 04:21 PM |
| http://fcchandler.home.comcast.net/stable/ still shows .11, is .12 coming out soon? |
| Posted by: fccHandler Jan 8 2006, 06:05 PM |
| @kewl: True NTSC video doesn't use "repeat first field" flags, and it is 29.97 fps. But if you're using VirtualDub-MPEG2 to process a DVD movie, I recommend switching to DGMPEGDec instead. @ant: I'm not planning a 1.6.12 build, because I haven't had a chance to play with Avery's new version, and I prefer to wait until it's declared stable. |
| Posted by: kewl Jan 8 2006, 11:08 PM | ||
Thanks for your response fccHandler. I've tried DGMPEGDec following your comments (I knew DVD2AVI but not this one). However I'll stick to VirtualDub-MPEG2 and use a 'inverse telecine' first in my script. I get a very acceptable result like that actually. (I have around 40 NTSC DVD videos to process and I need an automated solution) |
| Posted by: siim258 Jan 29 2006, 10:26 PM |
| This WMV stuff is cool. Thanks fccHandler. However, there is one other feature I would like to see. It is the option to import MP3 track to the video. Right now the only option is to decode the MP3 to WAV and then re-encode it to MP3 again. It would be awsome if I could directly copy the audio stream from an MP3 audio file (for obvious reasons). I know there are versions of VirtualDub that do allow me to import MP3, but they don't support WMV, so I'm stuck. So fccHandler what do you think, can it be done? Sorry if this subject has already been discussed. |
| Posted by: fccHandler Jan 30 2006, 04:58 AM |
| You could add a WAVE header to the beginning of the .mp3 file, effectively converting it into a compressed .wav which contains your mp3 data; VirtualDub will accept it then. Offhand I'm not sure what program can do this, but I'm guessing Besweet can. The ability to import .mp3 and .ac3 files directly is an oft-requested feature that I definitely want to implement in the future, but currently I'm not doing any work on VirtualDub-MPEG2. Let's just say I'm taking an extended vacation from all things VirtualDub related.  |
| Posted by: siim258 Jan 30 2006, 02:54 PM |
| Awsome Thanks It worked. I didn't even think of it like that Anyway, should anyone else need to do this, know that it can be done I didn't use this Besweet program, but a different release of VirtualDub. http://files.digital-digest.com/downloads/files/virtualdub/vdub_mp3_freeze.zip to be exact. That version of VirtualDub allows you to import an MP3 audio track (not sure about AC3 yet). Then I just saved the WAV file from VirtualDub while keeping the audio track on Direct stream copy. That successfully wrote an WAV header in the beginning of the file but keeping the rest of the file in MP3 format. Superb. Thanks again fccHandler. |
| Posted by: Pharaoh Atem Feb 16 2006, 10:28 AM |
| VirtualDub-MPEG2 installer is now online! If you wish use it, just click on the link below this text! |
| Posted by: ant Mar 30 2006, 08:40 AM | ||
OK, when do you expect the next version of MPEG-2? |
| Posted by: KornX Apr 9 2006, 05:45 PM |
| fcchandler said sth about stopping the dev of Vdub MPEG2 it`s sad, but his choice... KornX |
| Posted by: fccHandler Apr 11 2006, 06:02 AM |
| Sorry I've delayed responding to your posts. VirtualDub-MPEG2 development hasn't stopped forever, but it's true that I haven't touched the source code since December. The latest version 1.6.11 currently does everything that I want it to do, and I still use it daily. I just haven't been motivated (yet) to update my code to keep up with Avery's latest builds. I probably will update it soon, and I'll post here when I do. |
| Posted by: squid_80 Apr 11 2006, 10:33 PM |
| If you get around to it, you might want to update ac3acm too; they finally fixed the low volume issue in ac3enc. Patch: http://mplayerhq.hu/pipermail/ffmpeg-devel/2006-April/010175.html I've tried it out and seems to work as expected. |
| Posted by: fccHandler May 3 2006, 05:02 AM |
| I've finally updated http://fcchandler.home.comcast.net/stable to version 1.6.14. (Hope I didn't break anything...) I've also added the low volume fix to http://fcchandler.home.comcast.net/AC3ACM. Enjoy.  |
| Posted by: peter100m May 3 2006, 11:15 AM |
| Thanks a lot fccHandler... will try it out. |
| Posted by: KornX May 3 2006, 08:09 PM |
| thx great news checked your page every day KornX |
| Posted by: Pharaoh Atem May 5 2006, 01:38 AM |
| I have updated my installer of VirtualDub-MPEG2 to the latest version now! If anyone wants it, just look below! |
| Posted by: manolito Jun 8 2006, 08:37 PM |
| VirtualDub-MPEG2 1.6.1.5 has been available at fccHandler's site for more than one week now! About time to make an announcement here... Cheers manolito |
| Posted by: fccHandler Jun 8 2006, 11:46 PM |
| OK... Hear ye! Hear ye! http://fcchandler.home.comcast.net/stable is now available! Tell all your friends! 100% FREE! I've also updated the thread title. Enjoy. |
| Posted by: Loadus Jun 8 2006, 11:55 PM |
| lol. Thanks fcchandler (again) for the coolest mod of Vdub. |
| Posted by: Spikedude Jun 10 2006, 07:31 AM |
| Hi, While using this OWNAGE mod of virtualdub, I tried opening a WMV9 file only to be greeted by this error message "Couldn't locate decompressor for format WMV3 (UNKNOWN). VIrtual Dub requires a Video For Windows (VFW) Compatible codec to decompress video. Direct Show codecs are not suitable" My intents are opening the wmv9, doing a direct stream copy to avi and then prooceeding to insterting that avi and another audio stream and a sub stream to an OGM. Any help is aprreciated. the file info is as follows Video: Windows Media Video 9 640x480 23.98fps 1324Kbps [Raw Video 0] Audio: Windows Media Audio 48000Hz stereo 85Kbps [Raw Audio 1] UPDATE: Upon instalation of Windows Media Video 9 VCM I was able to open the file and save it as avi, the avi workd GREAT, seeking is fine, sound sinchronization is perfect, there is only one thing that worries me, the avi file is a bit smaller then the original WMV9 , and is about 1 second shorter WMV = 222,152,180 bytes AVI = 221,680,200 bytes anyone know what might be the cause of this? I have watched both version an they seem identical, im just being corious. 2nd UPDATE: I opened both files on Vdub-mpeg2, they both have the exact amount of frames and last the exact same time, I guess M$ windows being stupid. thnx |
| Posted by: fccHandler Jun 10 2006, 08:01 AM |
| You can avoid that error by installing the VCM version of Windows Media Video 9, but Microsoft keeps moving it and it's tricky to find. Try this direct link: http://download.microsoft.com/download/9/8/a/98a6cb2d-6659-485e-b1f9-2c0d9bf6c328/wmv9VCMsetup.exe. BTW, you shouldn't need the codec for doing a direct stream copy. |
| Posted by: Spikedude Jun 10 2006, 08:06 AM |
| Thnx you answered a milisecond later after I had found the answer via mi amigo google, thnx anyways man, this program is a life saver, i have over 600 files in wmv9 and need to add subs and audios to all of them thnx |
| Posted by: Spikedude Jun 10 2006, 08:08 AM |
| I have to go to sleep as its 4:07 here in FL, and my mom just woke up and is blaming it on my loud typing, keep this program alive, it ownz |
| Posted by: fccHandler Jun 10 2006, 08:18 AM | ||
The AVI container probably has less overhead than WMV. As for the duration, it might vary depending on which tool you are using to measure the duration of the original WMV. (Perhaps there is some slop introduced when rounding to the nearest second.) However, the AVI and WMV should both show the same duration in VirtualDub-MPEG2. Crap, you keep editing your post! Go to sleep now; it's the same time here in Georgia. |
| Posted by: Moitah Jul 3 2006, 10:17 PM |
| I noticed the WMV/ASF parser in VirtualDub-MPEG2 has trouble opening files that play fine in other software. I started learning the ASF file format a few days ago and thought I would try to improve the ASF parser in VirtualDub-MPEG2. The changes are: 1) Find the "Stream Properties Object" if it's located inside an "Extended Stream Properties Object". The ASF spec describes why in section 8.2.2.1: There are cases in which it is desirable to keep all products prior to but not including Windows Media Player 9 Series from recognizing a particular stream. For some scenarios, see sections 8.2.3 through 8.2.9. This is done by embedding the Stream Properties Object for that stream inside the Extended Stream Properties Object for the same stream (see section 4.1). 2) Select the appropriate stream when the header contains information about multiple streams of the same type (e.g. 2 video streams, 2 audio streams). When recording streaming videos (with http://tetora.orz.ne.jp/forum/gasdown/download.cgi for example), it's common to see this because the server may have higher or lower bitrate streams available depending on your connection speed. The recorded files have "Stream Properties Objects" for all of the streams that were in the original file, but the recorded file only has 1 of each stream in the "Data Object" (there is padding where the other streams originally were). 3) Handle files where the padding length isn't correct. Section 8.2.15.1 in the ASF spec: The Padding length field in the packet parsing section of an ASF packet shall accurately reflect the amount of padding at the end of the packet. However, as noted in section 5.2.2, ASF reader implementations should be prepared to handle cases when this value is zero and to infer the correct value from the size of the payloads. The files I changed can be downloaded http://www.moitah.net/misc/VirtualDub-MPEG2-WMV_Fix_01.zip. I uploaded a sample WMV file that was affected by all 3 of these issues: http://www.moitah.net/misc/mt_trlonline_rt66564_start_416f.wmv. You'll see fragment reassembly errors in a few places, this isn't because I broke the code but because the file really is messed up. Interestingly WMP plays it fine, I'm going to see if I can figure out how WMP reassembles the fragments. EDIT: There's also audio/video synchronization problems with that sample file if you seek, again this wasn't something I broke (you can run the file through Windows Media Stream Editor to make it open in the offical VirtualDub-MPEG2 and you will see the same thing). |
| Posted by: fccHandler Jul 4 2006, 12:06 AM |
| Thanks for your interest, and your work! I'll comment on these issues one by one... 1) I'm not sure why we would want to do this, if these streams aren't meant to be seen (as the spec implies). I'll have to go back and read up on what they're talking about here... 2) I haven't seen one of these myself yet, but indeed if the spec allows it, then it should be addressed. 3) I have seen these, but at the time I deliberately avoided fixing the problem because it caused errors to appear elsewhere. I believe WMP works by not throwing any errors, and just forging ahead to the next packet. (It is streaming after all.) But I also believe that VirtualDub-MPEG2 is far too rigorous about what it expects to find inside a packet. That's a legacy from Avery's original code, but I'm sure it can be made more robust. I just haven't really messed with it in a while... The audio/video desync is typically due to VFR or VBR (or both). I don't know if it will ever be possible to fix that within VirtualDub's framework. |
| Posted by: Moitah Jul 4 2006, 12:29 AM |
| 1) It's meant to be seen, just not by older versions of Windows Media Player. I think this is because mutually exclusive streams (same content, just different bitrate) aren't supported by the older versions. So these extra streams need to be hidden from older versions, but newer versions which support mutual exclusion know where to look to find the Stream Properties for the extra streams. 3) If you have a file that doesn't work right after changing the way the parser handles padding, I'd like to take a look at it if you don't mind. |
| Posted by: fccHandler Jul 4 2006, 12:59 AM | ||||
By that logic, it isn't meant to be seen by us either. Every version of WMP supports the video and audio stream types, which is all we are interested in. From the spec, it sounds like this mechanism is supposed to hide media of other types from players which may not support those types (cf. section 8.2.3). Also, support for mutually exclusive streams has been part of the ASF spec since the beginning. AFAIK the streams aren't hidden in this manner, and older versions of WMP do support them.
The movie you posted, for example. I only made a slight change just now and didn't really expect it to work. Do the changes in your version allow it to open that movie? If so, I will definitely look into incorporating your changes into VirtualDub-MPEG2. |
| Posted by: Moitah Jul 4 2006, 01:18 AM | ||||
I'm not sure what the reason is, then. I just wanted to see why this file wasn't loading in VirtualDub-MPEG2 even though it played in Windows Media Player. After messing with the code and looking at the file structure in http://thozie.de/dnn/AVIMaster.aspx, I realized there were Stream Properties objects for the lower bitrate audio/video streams in the Header Object, and the Stream Properties for the higher bitrate audio/video streams (the ones we want) were inside the Extended Stream Properties Object.
Yes, it opens in my version. The other 2 changes I made are required as well for the file to open. Like I said, you will get fragment reassembly errors at places in this file, but that's another issue (it would happen with the method of parsing used in the official version assuming the padding length were filled in correctly). |
| Posted by: fccHandler Jul 4 2006, 01:32 AM | ||
That does seem strange. I haven't looked inside the file to the depth you have, but I probably will now. And I'll definitely be looking at your code. Thanks! |
| Posted by: Moitah Jul 4 2006, 01:36 AM |
| I think I found the explanation. Section 8.2.4.1: When creating content with bit rate mutually-exclusive video streams in which the streams have different frame sizes, all but one of the streams in the mutual exclusion relationship shall be hidden from earlier implementations according to the manner described in section 8.2.2, and the Advanced Mutual Exclusion Object shall be used to describe the mutual exclusion. Note, however, when all video streams have the same frame size, the Bitrate Mutual Exclusion Object shall be used, and no streams need to be hidden. So the older versions did support mutual exclusion but only if the frame size for all streams were the same. In my demo file, the lower bitrate stream is 320x240 and the higher bitrate stream is 416x312. |
| Posted by: fccHandler Jul 4 2006, 01:49 AM |
| Yes, that explains it perfectly. (In fact, I was just about to post the same thing.) It also explains why the little change I made didn't work; it assumed the wrong frame size. It also explains why your movie isn't playable with older versions of WMP. I tried opening it in WMP 6.4 and there was no video or audio at all. |
| Posted by: fccHandler Jul 4 2006, 06:17 AM | ||
I don't know why yet, but so far it's always because the "Offset Into Media Object" is less than the expected position. If you change line 1929 to say... if (Offset_Into_Media_Object > fragment_point) ...then there won't be reassembly errors. This still keeps to the spirit of Avery's comment above that line, which only expresses his fear of missing a fragment. I sometimes get a warning at the end of the clip about the WMV9 codec leaving the MMX state active, and it's suggested that I contact the codec vendor. (Not likely!) I've also discovered that the open source MPlayer plays your movie perfectly with no complaints. We may be able to learn a lot from a study of their source code. |
| Posted by: Moitah Jul 4 2006, 07:09 AM | ||
I noticed the same thing. I figured out how Microsoft's parsers reconstruct the Media Object in this case. They assume the Offset_Into_Media_Object value is correct, even if it means overwriting some previous data. I figured this out by fixing the file with Windows Media Stream Editor and inspecting one of the frames that previously had reassembly errors. I changed VirtualDub-MPEG2's code to work the same way, and the file plays perfectly. You can download the new code http://www.moitah.net/misc/VirtualDub-MPEG2-WMV_Fix_02.zip. I guess it could be done more efficiently (without the extra buffer allocation/memcpy I added) but this was more of a proof of concept. |
| Posted by: fccHandler Jul 4 2006, 09:00 PM | ||||
Great job figuring this out.
You're right; I don't like creating an intermediate object buffer. We already have a buffer we can use to assemble objects (lpBuffer sent by the caller), it's just a royal pain trying to constantly track our position in there, and make sure we don't go out of bounds, etc. I've modified the first version of your code, and it seems to work well with your movie: http://fcchandler.home.comcast.net/InputFileWMV.cpp |
| Posted by: Moitah Jul 4 2006, 09:16 PM |
| Just tested your code, works fine here as well. The only other problem I'd like to fix is that it won't open incomplete files. It's easy enough to make it start parsing the Data Object even if it's incomplete, but I want to make sure only complete Media Objects are indexed (right now a Media Object is indexed after just the first fragment is seen). I didn't think this would be too difficult but I've been working on it a few hours now (not a lot of code, but it's not working right and I'm having trouble figuring out what's going wrong). EDIT: After taking a break and coming back, I finally realized what the problem was. I'll upload the code a bit later after I clean it up. |
| Posted by: Moitah Jul 4 2006, 10:08 PM |
| http://www.moitah.net/misc/VirtualDub-MPEG2-WMV_Fix_04.zip (based on the cpp you posted earlier) adds support for incomplete files. I removed the prompt that asked if you want to open the incomplete file and replaced it with a warning message using VirtualDub's warning log window. During indexing, only complete Media Objects are added. EDIT: Fixed a bug that caused false "missing fragment" errors on some files, reuploaded the code. It was the part in ReadData where I added "if (bytes < 0) break;", which was fine, except the same thing should have been done for compressed payloads as well. It turns out that before I started messing with the code, it already did this (in the loop condition) but I removed it when I was changing the padding behavior. |
| Posted by: Moitah Jul 5 2006, 03:54 AM |
| I checked through a bunch of random WMVs I had collected (probably 100 or so). The official 1.6.15 release worked on the majority of them but had problems with a few due to incompleteness, one due to a bunch of video stream headers (but only one video stream inside the data object), and two due to incorrect padding values (one of which also has a very large percentage of frames where the fragments overlap). The newest code worked on all of them, I didn't find any regressions . |
| Posted by: fccHandler Jul 5 2006, 06:11 AM |
| You may rest assured, your changes will be in the next release of VirtualDub-MPEG2. Thank you for your work. First I want to clean up some things though. I'm not happy with the "rewind" bit I added in ReadData; I want to find a more elegant way to handle this. Also, I guess no one's discovered this yet, but I accidentally released VirtualDub-MPEG2 with some experimental code to import AC3 and MP3 audio streams directly. (I had intended to remove this code before zipping the packages, but I forgot.) It kinda works OK as is, but I hope to spend the next few days improving this feature. |
| Posted by: fccHandler Jul 5 2006, 09:14 PM |
| @Moitah: I had some time today to examine your new code. I really don't like using an array of ASFSampleInfo structures for parsing, but I don't see any way to avoid it and still ensure complete objects. So... since we're committed to going that route, I figured we shouldn't need all those other silly arrays. See if the following revision works for you: http://fcchandler.home.comcast.net/InputFileWMV.cpp |
| Posted by: Moitah Jul 5 2006, 11:52 PM |
| I didn't like the idea either, but I figured it wasn't worth complicating the code over 4k of memory (and only during indexing). I haven't compiled it yet but I looked over the code and it looks good. I do see one problem, you must have gotten the code before I fixed that little "if (bytes <= 0) break;" bug in ReadData. You can remove that check and move it to the loop condition (i.e. "while ((bytes > 0) && Number_Of_Payloads--) {"). |
| Posted by: Moitah Jul 6 2006, 12:48 AM |
| http://www.moitah.net/misc/VirtualDub-MPEG2-WMV_Fix_05.zip your latest code with that bugfix and some cleanup. |
| Posted by: fccHandler Jul 6 2006, 05:15 AM | ||
Look again; I moved it to the bottom of the loop. It will never be <= zero upon entry to the loop, or at the "continue" instruction. I moved it because I have an irrational phobia about multiple test conditions on one line, especially loop test conditions. It's just a thing I have... |
| Posted by: Moitah Jul 6 2006, 05:16 AM |
| Oh, ok . |
| Posted by: Moitah Jul 7 2006, 02:10 AM |
| Is the "ASF_VBR_FIX" code something you added? If so, why didn't it work (if its not too much to try to explain)? EDIT: Just uncommented the #define and it worked fine on the few files I tried... |
| Posted by: fccHandler Jul 7 2006, 03:49 AM | ||
Yes, it was a failed attempt to make proper seeking work in files with VBR WMA9 audio. As I understand it, VirtualDub (like VFW) seeks based on the concept of "samples," in which every video and audio sample has the same duration. There is a fixed linear relationship between samples and time in VirtualDub's world. In a compressed audio stream, the "samples" are blocks of compressed audio. MPEG and AC-3 audio blocks are indeed always the same duration, but apparently VBR WMA blocks are not! This totally breaks the linear relationship between samples and time that VirtualDub expects. Example: VirtualDub wants to get the sample corresponding to time t, and calculates that it will be sample number x. Then it simply goes and asks the input driver for sample x. As an input driver, we don't really have control over this; we just give VirtualDub what it wants. But because WMA samples can have different durations, we may be returning samples which are temporally way off from where VirtualDub thinks they are. Incidentally, the same can be said about Windows Media Video samples (frames). They are not necessarily all the same duration, and again this violates VirtualDub's expectations. In essence, my code was a verbose (and slow) attempt to translate time to samples and vice versa for VBR WMA and VFR WMV, and somehow fake out VirtualDub's engine. It didn't really work, and I don't know if it ever will.  |
| Posted by: Moitah Jul 7 2006, 04:15 AM |
| Great information, thanks. It did seem to work pretty good on "mt_trlonline_rt66564_start_416f.wmv", though, and another file I tried (the audio on both of them was way off without ASF_VBR_FIX). It wasn't perfect, I figured because the audio blocks are a lot longer than video frames. In "mt_trlonline_rt66564_start_416f.wmv", for example, there are ~11 video frames for every block of audio, so for any video frame the closest audio block might be up to ~5.5 frames away in terms of presentation time (on average, since you say the block durations vary), if I understand this correctly. But being within a few hundred milliseconds is a lot better than being completely off isn't it (the difference between being annoying and unwatchable)? |
| Posted by: fccHandler Jul 7 2006, 04:37 AM |
| Holy crap, you're right! Something we changed (or maybe something Avery changed) since I added that code has actually made it work better. At the time I wrote it, I was using an old ABBA video for testing ASF_VBR_FIX, but it stuttered and repeated samples like a broken record, and I gave up on it. I just dug up the same video and it doesn't do that now with ASF_VBR_FIX enabled. Might be time to revisit this... |
| Posted by: phaeron Jul 7 2006, 06:35 AM |
| I might have fixed some bugs in the code that attempts to compensate for partial block offsets when attempting to decompress from a position within a compressed block. That'd have to be a mighty long block, though. Other than that, the main addition I did in this department was to add the TimeToPositionVBR() and PositionToTimeVBR() functions. Implementing those should get accurate sync when decompressing a VBR audio track. This wouldn't have magically fixed anything, though, since you have to add them to the audio stream. |
| Posted by: Moitah Jul 7 2006, 06:48 AM |
| I've been studying the ASF_VBR_FIX code some more. I think the audio part is great. I don't see how the video part would work though (this is supposed to help for VFR streams?). Searching through VirtualDub's code, it looks like TimeToPosition is only used for the audio stream, so it wouldn't have any effect on the video stream, and I can't imagine the modified KeyFrame functions helping either. |
| Posted by: fccHandler Jul 7 2006, 07:23 AM |
| Simple answer; it was a project that was never finished. IIRC, originally the ASF_VBR_FIX code was a good deal more involved than what remains now, but I deleted a lot of it out of frustration. I only left behind a skeleton of it with the idea that I might return to it one day. Your discovery that it sort of works now is kind of a shock to me. You realize I haven't done any of the things I had intended to do these past few days? I've been too occupied with InputFileWMV.cpp... |
| Posted by: Moitah Jul 7 2006, 07:32 AM |
| I see. Well, I will keep testing the audio part. I think there might be a bug somewhere (I get ACMERR_NOTPOSSIBLE near the end of playback sometimes if I didn't start playback from the beginning) but I'm going to see if I can track it down. |
| Posted by: Moitah Jul 7 2006, 08:08 AM | ||||
Got it. VirtualDub\source\Audio.cpp, line 1680, replace:
With:
The old code assumed each audio block was the same length, and calculated the end of the subset wrong, causing blocks past the end of the stream to be requested. EDIT: Actually, the blocks past the end of the stream don't get requested from ASFReadStream::Read, I guess some other part of the code is checking the boundaries and throwing an error before it gets that far. I'm not sure . But whatever was happening seems to be fixed now.EDIT2: I'm improving this to keep track of the error and compensate. EDIT3: Looks like there's more code that assumes fixed-duration audio blocks, so although the above code helps I think overall it still doesn't work properly . |
| Posted by: fccHandler Jul 7 2006, 08:25 AM |
| Wow, you are changing Avery's code now? Rock on, dude. It's too late for me and I am way too sleepy to post any sort of sensible comment right now... |
| Posted by: Moitah Jul 7 2006, 08:29 AM |
| Hahaha . I know what you mean, but thankfully this fix wasn't too hard. |
| Posted by: Moitah Jul 8 2006, 02:21 AM |
| Now that I've become more familiar with the way audio is handled in VirtualDub, I think the best thing to do is enable ASF_VBR_FIX as it is now (just the audio part) and don't touch Avery's code. The audio support is going to be broken either way, but at least with ASF_VBR_FIX it manages to work a bit better by some miracle. I might still try to play with Avery's code for fun, but any changes would be too risky to include in VirtualDub-MPEG2. |
| Posted by: fccHandler Jul 8 2006, 08:10 AM |
| FYI, I've moved the off-topic stuff in this thread to its own thread in the Off-Topic forum. Since ASF_VBR_FIX seems to be the way to go, I'll see if I can find time to improve it. My ugly brute force TimeToSample function can certainly be improved, plus I'd like to look into implementing those VBR functions that phaeron mentioned earlier... But for now, I'll probably just release what we have as is. Recently FredThompson informed me that 4:2:2 MPEG-2 decoding is totally broken. I have that fixed now, and I want to get the fix out ASAP. |
| Posted by: Moitah Jul 8 2006, 08:34 AM |
| Your TimeToSample code is good enough IMHO . I think it's only called once per subset at the beginning of each dub (EDIT: if you're only using the audio part of ASF_VBR_FIX), so I doubt it's slowing anything down. Have you taken a look at VirtualDubMod's code? I looked over it briefly, I'm pretty sure the same problem exists with Vorbis in MKV and they found a solution for it. |
| Posted by: fccHandler Jul 8 2006, 09:09 AM | ||
Not in a long time. I tend to think it isn't relevant anymore; VirtualDub has progressed leaps and bounds since they modified it. Anyway, I haven't the vaguest clue how Vorbis is structured. |
| Posted by: Moitah Jul 8 2006, 04:55 PM |
| Thanks for the new release . |
| Posted by: i4004 Jul 8 2006, 08:14 PM |
| try the <shift+arrow> (to jump on kfs) on this(july 08) build. seems to be broken. works ok in 1.6.11 also, (perhaps related to above mentioned) when i load wmv with the error i posted image of previously, scrubbing is not working ok ("decoding" number is lower than "preloading" frame number?). it's not really working at all. "file info" says plenty of kfs exist in the file. that reminds me of something else(which is obviosuly not fcc or moitah's fault); are those reports on "decoding" and "preloading" frames there just to slow system down a bit, as this fetching is working faster on 1.4.xx, so i get the feeling this report is taking more time than decoding itself. (obviosuly, not just with wmv but any mpeg4 avi..) |
| Posted by: Moitah Jul 8 2006, 08:18 PM |
| It's only broken for ASF(WMV) files. It's because the *KeyFrame functions return the wrong result with ASF_VBR_FIX enabled. I still think it should only be enabled for the audio code. |
| Posted by: i4004 Jul 8 2006, 08:25 PM |
| these were not asf files. then again, what's the difference? isn't wmv just another name for asf? WMV is generally packed into an Advanced Systems Format (ASF) container. http://en.wikipedia.org/wiki/Windows_Media_Video ah, i see you've parenthesized 'wmv' near the asf now. how does that change anything? it worked in 1.6.11 which means it's broken now. (i'm talking about ok files and keyframe search) on broken file scrubbing is not working at all. |
| Posted by: fccHandler Jul 8 2006, 08:32 PM |
| Seeking to keyframes sometimes b0rks even without ASF_VBR_FIX. I've often thought it could be due to the presence of B-frames, but I have no way to prove it. All the information I've seen from Microsoft seems to suggest that B-frames are only used in Advanced Profile streams, and disabled by default. (And of course, VirtualDub-MPEG2 doesn't support Advanced Profile because there's no VFW codec for it.) Anyway, I'm still working on this stuff. Have patience. |
| Posted by: fccHandler Jul 9 2006, 09:27 PM |
| I think Avery did fix my ASF_VBR_FIX code, though he didn't know it (and neither did I). The InputFileASF class is derived from InputFileAVI, so it borrows heavily from Avery's base AVI code. It looks like the new VBR time and position functions are being mapped through AudioSourceAVI to the regular time and position functions in AVIReadStream. Since ASFReadStream is derived from AVIReadStream, it also benefits from this. In other words, I don't need to implement the VBR functions because they're implemented already (in a roundabout way). I believe i4004's problem is due to the ASF_VBR_FIX code being applied to the video stream (originally intended to fix VFR). I've decided to remove this for now. But even without that, it still doesn't seek to keyframes correctly, i.e., it doesn't always display the correct picture when you seek. It reminds me of what happens when you try to seek in an Xvid file created without "packed bitstream." I'm beginning to think that there may be a one frame lag in the VCM WMV9 codec. Perhaps it is a Microsoft hack to deal with B-frames in VFW? |
| Posted by: Moitah Jul 9 2006, 10:35 PM |
| Yeah, B-frames would certainly explain weird seeking behavior. Did you find out for sure whether or not there were B-frames in your video (I saw your thread on Doom9)? I'm tempted now to write a tool to parse VC-1 to figure out the frame types (looks like the frame type is one of the first values in the frame headers, I can reuse the BitStream class I wrote for MPEG4 Modifier, and I already wrote an ASF parser in C# that's almost complete enough to be used for this purpose ). |
| Posted by: fccHandler Jul 10 2006, 12:12 AM | ||
Nope. But if zambelli is right, then it shouldn't be possible for any of my homemade videos to have B-frames in them. Yet I've found two in which the behavior is very suspicious. (It was these videos that prompted my post on Doom9.) They behave something like this: Let's say frame 500 is a keyframe, and frame 501 is a delta frame. I seek ahead to frame 700, 701, 702, then jump back to 501. The picture I see now is actually broken; it's composed of random blocks from both frames 501 and 702. It must be either a P-frame which isn't being reconstructed correctly (presumably VirtualDub's fault), or it might be a B-frame for which the decoder hasn't received both references. I tend to favor the latter theory, because my gut instinct says there's no mistake in VirtualDub's code. I wonder too about the coding order of the frames in a WMV with B-frames. Are they coded in display order, or are future references sent first (as in MPEG)? Curiously, the ASF spec says that presentation times should only increase (section 8.2.16). Yet coding B-frames in display order doesn't sound very sensible, especially for a streaming format. I seem to remember downloading the VC-1 specs when they were released. I guess I'll just have to dig those up and research all this junk. Ugh...  |
| Posted by: fccHandler Jul 10 2006, 02:32 AM |
Hmm... I just remembered that VirtualDub can display the frame sizes graphically; I don't know why I didn't think of this before. The trick is to set the video to Direct Stream Copy and then hit F5. In the status window, click the Video tab. Here is what I saw in my ABBA video: The pattern strongly suggests that every odd frame is a B-frame! And it's like that through the whole video, and many of my others too. One video appears to have two B-frames between every third frame, like maybe I was messing with the registry value at the time. Yet if I Direct Stream Copy the ABBA video to an AVI it plays fine. Since it's clearly not a "packed bitstream," I'm even more convinced that the Microsoft decoder must have a one frame lag, just like MPEG decoders. This is um, enlightening, and discouraging at the same time. It's starting to look like seeking will always be b0rked, because of how this codec works. |
| Posted by: fccHandler Jul 10 2006, 04:08 AM | ||
Correction to the above... What I have is a http://www.smpte.org/smpte_store/standards/pdf/s421m.pdf of SMPTE 421M dated August 23, 2005. I don't know to what extent this early draft may differ from the http://www.smpte.org/news/press%5Freleases/003_06.cfm approved last April. I had never actually read this draft before; it actually sounds a lot like MPEG, or at least, they use a lot of the same terms. They do state in this draft that the reference frames must precede the B-frames in the VC-1 stream, exactly like MPEG. However, I'm still not precisely sure how this VC-1 bitstream is packaged in the ASF container, and it doesn't appear that any of the VC-1 documentation is going to help, since it's conceived to be container agnostic. Rats. This is liable to require some reverse engineering, and I'm not sure it's worth the trouble. |
| Posted by: Moitah Jul 10 2006, 04:19 AM | ||
| I was wondering how it was packaged in ASF as well. I found this (http://wiki.multimedia.cx/index.php?title=Understanding_VC-1): The video data should be packaged with "extradata" which is attached to the end of a BITMAPINFOHEADER structure and transported in the ASF file. The format of the extradata is as follows:
And then I assume each ASF frame contains only the VC-1 "picture" data (not sure). Since the picture type is very close to the beginning of each picture, it seems likely (unless they made huge changes) that it would still be in the same place as described in the proposed draft. |
| Posted by: fccHandler Jul 10 2006, 04:31 AM |
| Well, my ABBA video has four bytes following the BITMAPINFOHEADER: 0x4E, 0xB9, 0x1A, 0x11 From your link, this indicates Main Profile, but they don't say what the rest of it means in this case. |
| Posted by: Moitah Jul 10 2006, 04:50 AM |
| What is the width and height of the ABBA video (it's not 742x418 is it )? |
| Posted by: fccHandler Jul 10 2006, 05:08 AM |
| 320 x 240. Nice try. EDIT: Remarkably, I was able to clear enough web space to put the whole video up, should you want to examine it. It won't be there for long though: http://fcchandler.home.comcast.net/ABBA.wmv |
| Posted by: Moitah Jul 10 2006, 07:45 AM | ||||
| http://www.moitah.net/misc/abbafl.txt The code I used was:
By looking at the SMPTE draft I knew there would be either 2, 3, or 4 bits before the picture type, I tried each of them to see which one worked. There are 42 I-frames listed in the .txt file which is the same number that I counted in the video in VirtualDub-MPEG2, so it appears correct. Note that you only parse the picture type using the VLC method if you know there are B-frames in the stream. I don't know this for sure so it's possible that I should have only been reading the 4th bit from the left. I tried this and there were 42 "1" bits (number of I-frames). However, if this were the correct method of parsing, it seems odd that the 3rd bit would flip on/off in the pattern that it does. Knowing this and seeing the frame size graph you posted, I feel pretty safe saying there are B-frames in this file. |
| Posted by: fccHandler Jul 10 2006, 10:40 PM |
| Interesting stuff. Your text file begins I, P, B, I. If this were an MPEG, the display order would be I, B, P, I. The same should be true of WMV9 based on the draft, but the presentation times of these frames are 0, 33, 66, 100. I've been trying to understand how this can be, and I've come up with another theory... Nowhere in the ASF spec do they actually define the meaning of their term "presentation time." It's a bit of a stretch, but perhaps it means the time at which the media objects are presented to the decoder (if any), and NOT necessarily the time at which the pictures and sound are rendered to the user. This makes more sense if you consider that, unlike MPEG, the coded objects in the ASF container are supposed to be opaque to some extent. The media objects can be any format, even uncompressed. If true, this would also explain why the VFW WMV9 decoder needs a one frame lag. |
| Posted by: Moitah Jul 10 2006, 11:04 PM |
| I'm not sure if I'm reading your post correctly but are you saying there would only be lag if the frames were written in decoding order? The way I understand it, there would be lag either way: 1 frame if the frames were in decoding order, [maximum consecutive b-frames] if the frames were in display order. |
| Posted by: fccHandler Jul 10 2006, 11:15 PM |
| Yes, there will always be lag when B-frames are involved. I wasn't suggesting otherwise. The mystery was whether WMV9 implements this lag internally and breaks VFW rules. I'm pretty sure now that it does, and that's why you sometimes see the wrong frame displayed in VirtualDub-MPEG2. |
| Posted by: KornX Aug 5 2006, 04:31 PM |
| @fcchandler in the newest build 24600 i can not navigate through wmv files as in previous versions... holding shift and moving the slider with the mouse seems as if the frames shown are no key frames... and by holding shift and pressing left and right sometimes nothing happens... KornX |
| Posted by: KornX Nov 23 2006, 07:32 PM |
| Will we see a new version of Vdub MPEG2? Is fcchandler gone? Have is missed sth.? KornX |
| Posted by: phaeron Nov 24 2006, 05:52 AM |
| You'll have to be patient, I'm afraid. If he's still working on it, I'm sure you'll hear about it here. |
| Posted by: fccHandler Dec 16 2006, 11:16 AM |
| @KornX: Sorry my friend, but I'm not really working on it anymore. The source code and binaries will stay on my site though, for as long as I continue to own the site. The truth is, I'm rather bored with the whole digital video thing nowadays. It has dominated my life for the past five years or so, but now it's just getting old. The magic has gone away... I sincerely doubt that I will ever update VirtualDub-MPEG2 again. But the source code will always be there if anyone else wants to pick up the torch. Best wishes, fccHandler |
| Posted by: Moitah Dec 17 2006, 04:17 AM |
| http://www.moitah.net/misc/VirtualDub-MPEG2-1.6.15-ASFSeekFix.zip of the latest VirtualDub-MPEG2 without the ASF_VBR_FIX code. It fixes seeking to keyframes. |
| Posted by: KornX Dec 18 2006, 09:10 PM |
| ah moitah thx alot, much appreciated... what have you changed? KornX |
| Posted by: Moitah Dec 19 2006, 02:50 AM |
| I only disabled some experimental code that was supposed to allow accurate seeking through ASF/WMV files with VBR audio (it also changed the way seeking to video frames was done, for what reason I'm not sure, but this is what caused the problems when trying to seek to keyframes). |
| Posted by: KornX Dec 19 2006, 12:18 PM |
| ah i see nice many thx... KornX |
| Posted by: kewl Dec 26 2006, 12:20 PM |
| ffchandler thanks for this wonderful mod and for the great achievement! phaeron -> why don't you integrate the mpeg2 reader into the official version? especially now that fcchandler is retiring. If not you probably have a good reason, what is it? This mod is very very good and useful, it shouldn't die like this. |
| Posted by: Randolph Carter Jan 23 2007, 08:51 PM |
| Hi, ffchandler ! Thank you so much for your work... I had a really good time with your releases and they were very usefull for my work and hobby... I hope that someone will carry on your project and I wish you the best for the future...,  Randolph |
| Posted by: raymond Apr 10 2007, 02:10 PM |
| Does anybody compile VirtualDub v1.6.17 with mpeg2 import function? On http://fcchandler.home.comcast.net/stable/ there are only the 1.6.15 build. thanks |
| Posted by: DarrellS Apr 10 2007, 09:26 PM |
| While you are waiting for either an updated VDub-MPEG2 or for Phaeron to emplement MPEG2 support and WMV support, you can always use an Avisynth script to open these files in 1.7.1 |
| Posted by: longnose May 23 2007, 03:43 PM |
| Maybe someone with coding/proggin skills could pickup the mpeg2 & wmv code from VirtualdubMPEG2 and merge it with the newer codebase. Millions of users would appreciate it for sure . |
| Posted by: lwc Jun 26 2007, 02:07 PM |
| When I choose to import audio ("wav, mp3, ac3"), I only manage to import WAV (otherwise it complains it's not a WAV file). Why is that? Also, I really would admire the author if he let us also import MP2 audio files. |
| Posted by: fccHandler Jun 26 2007, 09:38 PM | ||||
The MP3 and AC-3 import functions are very simplistic, and might not always work. In particular... The detection part will fail if the audio file doesn't begin with a clearly recognizable MP3 or AC-3 audio frame, OR a valid ID3v2 tag leading to a clearly recognizable MP3 frame. It will not search for these elements; they must be present right at the beginning of the file. If not, then my code gives up immediately, and relinquishes the file to VirtualDub's default WAVE loader. This sounds like what is happening to you. But even if the detection part succeeds, the parsing part will fail if the audio uses a variable bitrate, because the parser assumes that all audio frames will be the same size. In this case, the result will probably be garbage, or a crash. I haven't spoken much about this in public, because the MP3 and AC-3 import functions were a private experiment of mine, and it was an accident that they were compiled into the public release of VirtualDub-MPEG2 1.6.15.
MP2 support probably wouldn't be difficult to add; the code to modify is in AudioSource.cpp. I didn't write in MP2 support myself, I guess because I've never had an ACM MP2 codec installed on my system. I'd like to improve the audio import functions, but I haven't touched the source code in a LONG time, and I can't promise that I'll get around to it any time soon. |
| Posted by: PhotoRuler Jul 24 2007, 12:13 AM |
| @fccnomorehandler What a year: 3.8. my Mother died. Reason: Age. 6.30. my girlfriend died. Reason: Brainstroke (would you say so in english too?). Now VD-MPEG2 died. Reason: I'm rather bored with the whole digital video thing nowadays. It seems to be useless, to argue with the third reason as well as with the first two. It sounds so final! What a pitty!!!!! Here: http://www.rulernet.de/ (Video-Freaks) you will live forever!!! As I told you years ago, here in Germany you are a hero! All those timing problems don't apply to our CCIR-Standard (25fps). The skew of 80ms (2 frames) we learned to ignore. No, my friend, I do not ask you to become unbored with the whole digital video thing :-) No, my friend, I do not ask you to waste power with your PC (I'm a fan of Al Gore)! No, my friend, I do not ask you to make the world a bit better with VD1.7 MPEG2. No, my friend, I do not ask you to.......... No, I'm down on my knees and I'm crying: PLEASE, PLEASE, PLEASE, PLEASE, PLEASE!!!!! With love of a video freak Ronie |
| Posted by: neuron2 Jul 24 2007, 01:55 AM |
| . |
| Posted by: i4004 Jul 24 2007, 07:51 PM |
| he's bored and wants vdub-mpeg2 1.7.x.... |
| Posted by: neuron2 Jul 24 2007, 09:43 PM |
| . |
| Posted by: i4004 Jul 25 2007, 03:20 AM |
| DGMPGDec is too hard to use. too complex. loading mpeg to vdub-mpeg2 is straightforward.... i myself don't mind the indexing portion of dgmpgdec(in the end, vdub-mpeg2 takes time to load mpeg too...), but splitting video from audio(in order to process it) is rather unnatural to somebody who's accustomed to avisource()...or vdub users. would be easier if vdub could load mp2... hm..but it seems vdubmod indeed can load mp2 audio. well...timing couldn't be better; i just have a big .ts file that needs compression....now dgmpgdec is easier to use... |
| Posted by: fccHandler Jul 25 2007, 07:58 AM |
| Once VirtualDub 1.7.x is declared stable, I will release VirtualDub-MPEG2 1.7.x. It might even be able to import MPEG Layer II as a separate stream. Wait and see. |
| Posted by: i4004 Jul 25 2007, 01:31 PM |
| acm mp2 codec can be found here http://briefcase.yahoo.com/bc/timltaylor/lst?&.dir=/Archive&.src=bc&.begin=9999&.view=l&.order=&.done=http%3a//briefcase.yahoo.com/bc/timltaylor/lst%3f%26.dir=/Archive%26.src=bc%26.view=l (search for "QDesign_CoDec ", add '.exe' on the end upon saving) |
| Posted by: squid_80 Jul 25 2007, 01:53 PM |
| Or from the sticky in the codecs forum: http://www.geocities.com/wilbertdijkhof/qmpeg_mp2.zip |
| Posted by: blob2500 Aug 28 2007, 12:09 PM |
| Hi! In Virtualdub-mpeg2 (with file avi with mp3 audio loaded): Audio Direct Stream Copy selected, Menu File->Save Wav chosing mpeg audio (.mpa, .mp2, .mp3) in menu, the file out it's not a real mp3 file but it's an actual wav file container (the header of file is a RIFF/WAV) with incorrect .mp3 extension. This type of file is already present with its correct exstension ".wav" in saving menu option. It's a bug? I think it isn't correct.. Thank you.. and thanks FccHandler for the development of your program (excuse me for my english..) |
| Posted by: foxidrive Aug 28 2007, 12:56 PM |
| Is it a VCD file? In VeeDub threads it is mentioned that the mp2 audio in MPEG files has to be decoded to a WAV because of timing issues, but this may not apply here. |
| Posted by: blob2500 Aug 28 2007, 01:15 PM |
| No, it's not a vcd file. Each avi file with mp3 audio.. The correct extension of audio file pcm in wav or mp3 in wav is ".wav", no ".mpa/.mp3" ".mp3" (or generic .mpa) extension is correct if mp3 audio is not into wav container. PCM into wav container -> .WAV extension is correct (option present in vdub-mpeg2 option) MP3 into wav container -> .WAV extension is correct (option present in vdub-mpeg2 option) MP3 into wav container -> .MPA/.MP3 extension is not correct! (option present in vdub-mpeg2 option) MP3 into native mpa container -> .MPA/.MP3 extension are correct (option not present in vdub-mpeg2 option) |
| Posted by: fccHandler Aug 28 2007, 06:20 PM |
| It's a bug. The output of "Save WAV" is always a RIFF/WAVE file, regardless of the extension. Those other extensions are for importing audio files, and they shouldn't appear in that dialog. Thanks for pointing it out. |
| Posted by: yawnmoth Aug 30 2007, 04:51 AM | ||
DGMPGDec requires you make a *.d2v file, which is just as - if not more time-consuming - then letting VirtualDub MPEG-2 parse the MPEG2 file, itself. I don't know about you, but I, personally, prefer it when the video I want to load loads instantaneously, just as *.avi's do. Anyway, on the subject of VirtualDub-MPEG2... if I open a few *.vob's, one after the other, VirtualDub-MPEG2 usually crashes. No idea why. Is this a known problem? |
| Posted by: neuron2 Aug 30 2007, 05:55 AM |
| . |
| Posted by: fccHandler Aug 30 2007, 06:00 AM | ||
Nope, I've never heard of that problem. If it crashes again, please follow the instructions and save a crash report, then post the full contents here. |
| Posted by: yawnmoth Oct 9 2007, 04:35 AM | ||||||||
The problem I described earlier doesn't manifest itself all the time, however, today, it did (I'm still using 1.6.15 - I didn't know a new version had been released). Here's the crashinfo.txt file:
I had opened a *.vob and was trying to extract select scenes from it by hitting Shift + left / right arrow and then incrementing / decrementing by individual frames to get the most frame selection possible so that I could delete it. edit: here's what the Windows XP Crash Report thing said:
|
| Posted by: fccHandler Oct 9 2007, 05:41 AM |
| Thanks for the crash log. It's very strange that it crashed in "get_bits()", because that is a function which is called thousands of times for every MPEG that anyone has ever opened in VirtualDub-MPEG2... My recommendation is to get the latest version. There was at least one rare MPEG crash situation which was fixed in a later update. If the latest version of VirtualDub-MPEG2 1.6.19 crashes with the same .vob file, please post the crashlog from that. |
| Posted by: danstorey Jul 12 2008, 12:34 AM |
| Please help. Am trying to convert MPEG2 to use with Windows Movie Maker but when I use program the following message pops up when trying to import video: Couldnt locate decompressor for format 'WMV2' (unkown) VirtualDub requires a Video for Windows (VFW) compatible codec to decompress video. DirectShow codecs, such as those used by Windows Media Player, are not suitable. Any suggestions? |
| Posted by: Placio74 Jul 12 2008, 01:17 AM | ||
You can use ffdshow VfW wrapper. ffdshow video encoder configuration > Decoder > Codec and set support for required codecs (in this case WMV2/8). http://img387.imageshack.us/my.php?image=ffdshowvfwwmvwx0.jpg |