|
|
| phaeron |
| Posted: Apr 21 2008, 11:30 PM |
 |
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
New test build is up:
http://www.virtualdub.org/beta/VirtualDub-...1.8.1-test8.zip
http://www.virtualdub.org/beta/VirtualDub-...test8-AMD64.zip
http://www.virtualdub.org/beta/VirtualDub-....1-test8-src.7z
This contains a bunch of bug fixes, but there are two major new features in this build -- they're unrelated feature-wise, but I did them together because they both depended upon a specific change in the rendering back-end (multiple output buffers).
The first is multithreaded video compression. It is disabled by default, but you can enable it in Options > Preferences > Threading by setting the video compression thread count to '1'. What this does is push the video compressor to a separate thread so that it can run in parallel with the video decompressor and video filters; if you have a fairly balanced workload on both sides you can get close to 100% on a dual core system. It won't help you if you are disk bound, only if you are CPU bound, and it doesn't apply to capture mode. The thread count can't currently be set above 1, although I'm close to being able to flip this on for keyframe-only codecs like Huffyuv (it unfortunately won't be possible for delta compression). I'm interested in hearing if people see regressions in B-frame compression or videos with pad frames when multithreading is enabled -- the multithreading support piggybacks onto existing code to support B-frame compression, and although it seems to work right now, there are probably bugs lurking.
The second new feature is better support for interlaced video preview -- specifically, bob and sequential non-interlaced modes, in addition to the previously available weave mode in Options > Preview Field Mode. Like the capture mode was already doing, the preview path now queues video frames with the display code for better timing. This only works for the output pane and it only really works well right now if you have both the Direct3D and Vertical Sync (Vsync) options enabled in Options > Preferences > Display. If you have video that was truly filmed at 50/60Hz or non-interlaced video captured from an old game console, though, you should see a significant increase in motion fluidity with these settings.
Other miscellaneous bugs fixed: UYVY/YUY2 crop bug fixed, AVI indexing preferences fixed.
|
|
| sonical |
| Posted: Apr 22 2008, 05:10 PM |
|
|
Advanced Member
Group: Members
Posts: 143
Member No.: 23118
Joined: 23-February 08
|
Thanks for the test8  But along those improvements it is surprisingly buggy as well (as hell)... It realy hit me with a hammer a few seconds after starting for the (very) first time:)
Didn't test much - just loaded a non interlaced mjpeg avi and observed the divine beauty of every even (or maybe odd) lines of the second (output) pane getting not updated (whenever playing back) and various weird effects when switching to other preview modes. Some of modes even looked somewhat right (but they probably shouldn't as the source is not interlaced..?).
It seems that real mode is not reset to progressive at startup while the "preview mode>" setting seems to be set to it. Just switching the setting to something else and then back to progressive fixes things.
(edit+)
There was an additional weirdness with the mode when being in progressive mode: after changing some preferences, first time a run video playback - output pane was again not updating every other line. However stopping and running again fixed this %-)
Seems some used variable(s) doesn't get allways initialized
Also why is the interlaced (TFF/BFF) modes called "non-interlaced"?
Anyways thanks for the improvements! |
|
| phaeron |
| Posted: Apr 23 2008, 07:02 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Whoops. Yeah, it was an uninitialized variable (specifically, the interlaced and allow-conversion fields), but this also revealed a bug where the GDI minidriver didn't handle fields properly. Here's an update:
http://www.virtualdub.org/beta/VirtualDub-...1.8.1-test9.zip
http://www.virtualdub.org/beta/VirtualDub-...test9-AMD64.zip
http://www.virtualdub.org/beta/VirtualDub-....1-test9-src.7z
It's not that the interlaced mode wasn't being reset, it's that the display code thought that it was always interlaced. This corresponds to a mode that is still only available in capture mode, which is video at frame rate with interlaced scaling; not sure if it's worth actually caring about since it looks like keeerap.
The non-interlaced modes are correctly named. They correspond to field rate, non-interlaced video that has been captured as interlaced, because video capture devices don't normally let you configure them to capture fields independently and weave them together even though there often isn't any field distinction (they're encoded at 262 scanlines, not 262.5). The non-interlaced options split the frames back apart again, but without the vertical jitter that you'd normally get from bob mode. Essentially it lets you make up for the fact that capture devices don't let you capture non-interlaced video as non-interlaced.
Non-interlaced video is troublesome in general, and not all capture devices gracefully handle it, depending on the deviation from normal 480i. Sometimes you'll get annoying cases where the capture device suddenly skips cadence and effectively switches field order, which screws up attempts to restore progressive output since there's no way to tell from the DirectShow stream which field actually arrived first. If the signal is marginal enough then the capture device might not even be able to lock; when I tried to capture the output of an Atari 130XE I was unable to do so with the GameBridge and had to use the Plextor. Some TVs don't even take non-interlaced video well -- I have an old Samsung 17" LCD monitor that simply displays non-interlaced video as interlaced and the result is pretty nasty.
|
|
| phaeron |
| Posted: Apr 28 2008, 08:23 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
I split the thread, because I hadn't realized earlier that I had started pushing out 1.8.1 test builds in the 1.7.x thread. Whoops....
New build. Wasn't going to do this, but I pushed out a build for other reasons, so why not....
http://www.virtualdub.org/beta/VirtualDub-....8.1-test10.zip
http://www.virtualdub.org/beta/VirtualDub-...est10-AMD64.zip
http://www.virtualdub.org/beta/VirtualDub-...1-test10-src.7z
No major new features. A couple of more scopes are tagged in the real-time profiler (pre-filter and post-filter blit). SSE3, SSSE3, and SSE4.1 are now detected and configurable, but only SSE4.1 is used at the moment and only in the 8-bit (YCbCr) resampler -- however you can expect to see about a 20-25% speedup there. Several more simple video filters have been reimplemented with C versions and are now re-enabled in the AMD64 build, although they may not be as fast as the 32-bit versions (they may also be faster, because frankly some of the 32-bit asm implementations actually sucked, looking at them seven years later). Suggestions for more tech to re-enable in 64-bit are welcome, except for 32-bit codecs and plugins, which involve hairy levels of IPC with the 32-bit build instead of just porting code.
If you are going to try building this version, be aware that this version is the first that requires YASM, or to be more specific, YASM 0.7.0. In theory, this means that it can also be built using VC++ Express, without MASM... but I haven't tried doing that yet. I did verify via Filemon that MASM is not invoked during the build process anymore. |
|
| sonical |
| Posted: Apr 28 2008, 10:57 PM |
|
|
Advanced Member
Group: Members
Posts: 143
Member No.: 23118
Joined: 23-February 08
|
Hooray! Thanks for the test10!
Yet what about the problem that we discussed regarding strange codec support and palettized avi-s? I am still too lazy to start using any of those file sharing services, so cannot share any of the videos (MS video1 cram 8bit) that pushes a bad bahaviour out of vdub.
So for those who are curious about te problem here goes a part of original message desribing it:
~~~~~~~~~~~~~~~~
Seems DV is now working fine - however I managed to find another whole
bunch of problems with handling palettized oldschool videos. This time with
MS-Video1 (cram-flavour). And there is definite different behaviour
between <1.7.0 and >=1.7.0 versions.
I have also untouched example video ~2Mbyte from old sierra's game
(one of the first huge cd-rom rpg with video - kings quest number
whatever).
Behaivour oddities regarding 1.6.19 are a whole bunch of different
problems previewing (different problems with "point sampling" rescale
and filter preview) and cueing, as well as inability to play it.
Newer versions just doesn't play or display anything at all with error
message "codec does not support RGB output. This is very unusual."
~~~~~~~~~~~~~~~~
Newer versions (1.7.x and 1.8.x) also display "cannot find compatible target format for decompression" in the status line while scrubbing around.
Seems that some additional post-video-decoding format conversion routine from palletized to truecolor just doesn't get selected.
Just checked what if I use various palettized BMPs as a source - everything works fine (excellent). Using 181test10 I saved a long run of frames from DV video, using a filter to resize to a lovely 320x200 "fullscreen" to BMPs, then converted them using batch processing (irfanview) into 256 "full color" and even 16 color ones, and then loaded back. All works well in all preview windows including filters.
Still feel shocked about what I did (and observed) - kind of deep nostalgia seeing 320x200 video in 256 or 16 colors - like FLI and FLIC files that 3d studio did save...
By the way - why not to add a FLI loader to a virtualdub? I know it sounds pervert - but there still are hundreds of oldschool animations in them around the world |
|
| phaeron |
| Posted: Apr 29 2008, 07:19 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Well, that was a PITA. I officially hate BITMAPINFOHEADER.
http://www.virtualdub.org/beta/VirtualDub-....8.1-test11.zip
http://www.virtualdub.org/beta/VirtualDub-...1-test11-src.7z
http://www.virtualdub.org/beta/VirtualDub-...est11-AMD64.zip
FLI? Haven't seen one in a long time myself... the only reason I added ANIM was because of nostalgia when I stumbled across Leo Schwab's bouncing-Amiga-ball-with-unicycles video again, which I HAD to get working. The last time I saw a FLIC file was a lame-o video that came with some ancient Windows 3.1 app. Besides, fccHandler already wrote an input plugin for it.
|
|
| sonical |
| Posted: Apr 29 2008, 09:47 AM |
|
|
Advanced Member
Group: Members
Posts: 143
Member No.: 23118
Joined: 23-February 08
|
"Your official hate can be used against you in a court of law(nmoving)"
Thanks and now everything works fine - tested in all preview windows (under filters, too) and playback. Also saved it out recompressed into some random mpeg4-based codec - all goes well.
Regarding FLIc support - for me it's just about those same old good crystal polygonal spheres rocking around checkerboard and some other daunting object. Or 3d rotating text "Investment". Or exploding one, with "Marketing", also in 3D. Well and I also have been having many intimate moments with 3d-studio (under dos of course), so remember having a huge heap of FLIcs somewhere that were forgotten for some N-teen years already I used flic because I had my own fli-loader in pascal, so could make animated sprites out of them.
So I definitely would be happy to load FLIcs into vdub - where does fcchandler keeps that plugin as I cannot google up any around..? VirtualDub Mod that I have here handy is 1.6.19-based and seems not being able to load FLIcs... |
|
| Barough |
| Posted: Apr 30 2008, 05:31 AM |
|
|
Advanced Member
Group: Members
Posts: 95
Member No.: 22677
Joined: 24-December 07
|
@ sonical
fcchandler normally keeps his plugins here, but not this time
http://fcchandler.home.comcast.net/~fcchandler/
--------------------
 |
|
| phaeron |
| Posted: Apr 30 2008, 06:22 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
He did it as a test, so it's not really one of his officially released plugins. Remember, it's not his job to fill in for all the things I'm too lazy to do.
|
|
| fccHandler |
| Posted: May 1 2008, 11:29 AM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
http://fcchandler.home.comcast.net/FLIC.zip
--------------------
May the FOURCC be with you... |
|
| sonical |
| Posted: May 1 2008, 02:22 PM |
|
|
Advanced Member
Group: Members
Posts: 143
Member No.: 23118
Joined: 23-February 08
|
Hi and thanks a lot, fcchandler! Great job and it works excellently! Where did You find that DANCER.FLI or 1989? Also nice that You preserved the correct dos capitalization of the file name :-] Is it some demo file from adesk animator or maybe some sigggraph entry of those years?
By the way - media player classic of some recent version does render fli (at least this one) wrong - verticaly flipped. Probably nobody tested it with this vintage format If I remember correctly FLI did have the same bizzare v-flipped image orientation as in BMP... So the fli decoder that MPC uses probably just doesn't flip it back to normal..
Thanks again and now I am realy gona start digging up old dusty rusty flics I have made or collected back in the days :-] |
|
| GrofLuigi |
| Posted: May 1 2008, 11:25 PM |
|
|
Advanced Member
Group: Members
Posts: 148
Member No.: 340
Joined: 22-September 02
|
Test versions of VirtualDub after 1.8.1-test7 crash shortly after starting save avi in fast recompress mode. Avisynth (simple script), DGIndex and Picvideo mjpeg codec involved.
Will provide more info if necessary.
| CODE |
VirtualDub crash report -- build 29750 (release)
--------------------------------------
Disassembly:
00567a00: 890d00000000 mov [00000000], ecx
00567a06: 81c4fc040000 add esp, 000004fc
00567a0c: c21c00 ret 001c
00567a0f: cc int 3
00567a10: 6aff push 0ffh
00567a12: 6818685a00 push 005a6818 (RtlUnwind@16+daec)
00567a17: 64a100000000 mov eax, fs:[00000000]
00567a1d: 50 push eax
00567a1e: 64892500000000 mov fs:[00000000], esp
00567a25: 83ec6c sub esp, 6ch
00567a28: 53 push ebx
00567a29: 55 push ebp
00567a2a: 56 push esi
00567a2b: 8bf1 mov esi, ecx
00567a2d: 8b4634 mov eax, [esi+34h]
00567a30: 33db xor ebx, ebx
00567a32: 33ed xor ebp, ebp
00567a34: 385e4c cmp [esi+4ch], bl
00567a37: 57 push edi
00567a38: 895c2418 mov [esp+18h], ebx
00567a3c: c744241c010000 mov dword ptr [esp+1ch], 00000001
00
00567a44: 8944242c mov [esp+2ch], eax
00567a48: 885e4d mov [esi+4dh], bl
00567a4b: 7525 jnz 00567a72 (VDVideoCompressorVCM::CompressFrame+62)
00567a4d: 8b4e28 mov ecx, [esi+28h]
00567a50: 3bcb cmp ecx, ebx
00567a52: 750b jnz 00567a5f (VDVideoCompressorVCM::CompressFrame+4f)
00567a54: 395e24 cmp [esi+24h], ebx
00567a57: 7419 jz 00567a72 (VDVideoCompressorVCM::CompressFrame+62)
00567a59: 895c241c mov [esp+1ch], ebx
00567a5d: eb13 jmp 00567a72 (VDVideoCompressorVCM::CompressFrame+62)
00567a5f: 83c0ff add eax, 0ffh
00567a62: 3bc3 cmp eax, ebx
00567a64: 894634 mov [esi+34h], eax
00567a67: 7406 jz 00567a6f (VDVideoCompressorVCM::CompressFrame+5f)
00567a69: 895c241c mov [esp+1ch], ebx
00567a6d: eb03 jmp 00567a72 (VDVideoCompressorVCM::CompressFrame+62)
00567a6f: 894e34 mov [esi+34h], ecx
00567a72: 8b4e38 mov ecx, [esi+38h]
00567a75: 3bcb cmp ecx, ebx
00567a77: 7412 jz 00567a8b (VDVideoCompressorVCM::CompressFrame+7b)
00567a79: 8b6e44 mov ebp, [esi+44h]
00567a7c: c1fd02 sar ebp, 02h
00567a7f: 8bc1 mov eax, ecx
00567a81: 03e9 add ebp, ecx
00567a83: d1f8 sar eax, 1
00567a85: 3be8 cmp ebp, eax
00567a87: 7d02 jge 00567a8b (VDVideoCompressorVCM::CompressFrame+7b)
00567a89: 8be8 mov ebp, eax
00567a8b: 3bcb cmp ecx, ebx
00567a8d: 8bbc2490000000 mov edi, [esp+90]
00567a94: 8a07 mov al, [edi] <-- FAULT
00567a96: 88442413 mov [esp+13h], al
00567a9a: 0f84a1020000 jz 00567d41 (VDVideoCompressorVCM::CompressFrame+331)
00567aa0: f6460802 test [esi+08h], 02h
00567aa4: 0f8597020000 jnz 00567d41 (VDVideoCompressorVCM::CompressFrame+331)
00567aaa: b867666666 mov eax, 66666667
00567aaf: f7e9 imul eax, ecx
00567ab1: c1fa03 sar edx, 03h
00567ab4: 8bca mov ecx, edx
00567ab6: c1e91f shr ecx, 1fh
00567ab9: 8d540a01 lea edx, [edx+ecx+01h]
00567abd: 8d442414 lea eax, [esp+14h]
00567ac1: 50 push eax
00567ac2: 8b4654 mov eax, [esi+54h]
00567ac5: 8d4c241c lea ecx, [esp+1ch]
00567ac9: 51 push ecx
00567aca: 89542428 mov [esp+28h], edx
00567ace: 8b542424 mov edx, [esp+24h]
00567ad2: 52 push edx
00567ad3: 57 push edi
00567ad4: 50 push eax
00567ad5: 53 push ebx
00567ad6: 8b9c24a4000000 mov ebx, [esp+a4]
00567add: 53 push ebx
00567ade: 8bce mov ecx, esi
00567ae0: e82bf7ffff call 00567210 (VDVideoCompressorVCM::PackFrameInternal)
00567ae5: 8b4c2414 mov ecx, [esp+14h]
00567ae9: 8bc1 mov eax, ecx
00567aeb: 2bc5 sub eax, ebp
00567aed: 99 cdq
00567aee: 33c2 xor eax, edx
00567af0: 2bc2 sub eax, edx
00567af2: 3b442420 cmp eax, [esp+20h]
00567af6: 0f8e70020000 jle 00567d6c (VDVideoCompressorVCM::CompressFrame+35c)
00567afc: 83 db 83h
00567afd: 7c24 jl 00567b23 (VDVideoCompressorVCM::CompressFrame+113)
00567aff: 1c db 1ch
Built on Aegis on Tue Apr 29 00:12:25 2008 using compiler version 1400
Windows 5.2 (Windows XP x86 build 3790) [Service Pack 2]
EAX = 00000001
EBX = 00000000
ECX = 00000000
EDX = 00567a10
EBP = 00000000
ESI = 003efee0
EDI = 00000000
ESP = 0826fcb8
EIP = 00567a94
EFLAGS = 00010246
FPUCW = ffff027f
FPUTW = ffffffff
Crash reason: Access Violation
Crash context:
An out-of-bounds memory access (access violation) occurred in module 'VirtualDub'...
...reading address 00000000...
...while running thread "Processing" (thread.cpp:159).
Pointer dumps:
EDX 00567a10: 1868ff6a 64005a68 000000a1 89645000 00000025 6cec8300 8b565553 34468bf1
ESI 003efee0: 005dbedc 00149898 00000000 0044006c 00000028 012d79a0 00000044 01370b98
ESP 0826fcb8: 01370be8 07f70048 0826fd84 005dbedc 02079150 00000000 00000000 00000001
0826fcd8: 004c822b 00000000 00000000 00000001 005c4a80 0826fda4 00000000 012d81c8
0826fcf8: 00000000 0826fda4 004c968c 012d8780 034a0000 004c985a 01366568 0136670c
0826fd18: 00000000 7c81f1d0 0826fdde 012d6930 012d6950 01370be8 0826fd84 0826fd78
Thread call stack:
00567a94: VDVideoCompressorVCM::CompressFrame()
004c822b: VideoSourceAVI::_isKey()
004c968c: VideoSourceAVI::streamGetFrame()
004c985a: _catch$?streamGetFrame@VideoSourceAVI@@UAEPBXPBXI_N_J2@Z$0()
00466927: VDThreadedVideoCompressor::ProcessFrame()
00466e91: VDThreadedVideoCompressor::ExchangeBuffer()
004682ac: VDDubProcessThread::WriteVideoFrame()
004685af: VDDubProcessThread::WriteVideoFrame()
76aa4f8c: WINMM!timeGetTime [76aa0000+4f60+2c]
004689d8: VDDubProcessThread::ThreadRun()
77e4bef7: kernel32!RaiseException [77e40000+bebb+3c]
77e4bef7: kernel32!RaiseException [77e40000+bebb+3c]
7c826feb: ntdll!NtDuplicateObject [7c800000+26fdf+c]
77e64519: kernel32!DuplicateHandle [77e40000+244b4+65]
77e6452a: kernel32!DuplicateHandle [77e40000+244b4+76]
77e6452a: kernel32!DuplicateHandle [77e40000+244b4+76]
0045c4c0: VDThreadInitHandler()
004f744a: VDThread::StaticThreadStart()
00582cd8: _callthreadstartex()
00582d7d: _threadstartex@4()
77e64849: kernel32!GetModuleHandleA [77e40000+2476a+df]
-- End of report
|
(Sorry for pasting the report - I zipped the crashinfo.txt but can see no attach button)
GL
|
|
| fccHandler |
| Posted: May 2 2008, 12:47 AM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
| QUOTE (sonical @ May 1 2008, 10:22 AM) | | Where did You find that DANCER.FLI or 1989? |
I'm pretty sure she came from a BBS. I still have a little collection of FLI files from the BBS days, plus some others I made myself (raytraced objects mostly).
| QUOTE | | If I remember correctly FLI did have the same bizzare v-flipped image orientation as in BMP... |
Actually FLIs were coded from the top down, which was perfect for DOS VGA. It's Windows GDI that flips everything. 
Not all code paths in the FLIC plugin have been tested, so if you see anything weird let me know. But start a new thread so as not to hijack this one.
--------------------
May the FOURCC be with you... |
|
| phaeron |
| Posted: May 2 2008, 08:14 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
| QUOTE | | Test versions of VirtualDub after 1.8.1-test7 crash shortly after starting save avi in fast recompress mode. Avisynth (simple script), DGIndex and Picvideo mjpeg codec involved. |
Got it, will be fixed in next drop. I have to work out a rare assert in the multithreaded compression code first, though.
|
|
| sonical |
| Posted: May 2 2008, 04:12 PM |
|
|
Advanced Member
Group: Members
Posts: 143
Member No.: 23118
Joined: 23-February 08
|
So far I could add just a few minor fixes that could be worked out in 181:
* preview panes doesn't get updated when pasting. For example when I add a section of video (f.ex. 88 frames 0--87) to the end (@88), timeline knob stays in the same place (say frame 88) but preview stays "blue" (empty) and frame information stays the same "masked" "88 [M]".
* The end frame "masked" marking doesn't allways appear. To get the glitch with 100% repeatability just use mouse wheel to cue around end. If you cue to the end frame by frame (wheel down), the [M] sign will appear (OK), yet stepping back (one wheel step up) one frame and then again down to the masked (last) frame the [M] will not be shown.
> I'm pretty sure she came from a BBS. I still have a little collection of FLI files from the BBS days, plus some others I made myself (raytraced objects mostly).
Aaah lovely BBS times - I almost forgot I had my own bbs on maximus5 with a huge collections (40MB, 60MB and then 105MB HDD) of MODs, STMs, demos/intros and FLIs
|
|
|
