| Printable Version of Topic
Click here to view this topic in its original format |
| Unofficial VirtualDub Support Forums > Testing / Bug Reports > Virtualdub 1.9.x Test Thread |
| Posted by: phaeron Aug 3 2009, 12:49 AM |
| I'm going to start a new test thread in parallel to the 1.9.9 thread that's going on: http://www.virtualdub.org/beta/VirtualDub-1.9.X-test32.zip http://www.virtualdub.org/beta/VirtualDub-1.9.X-test32-AMD64.zip http://www.virtualdub.org/beta/VirtualDub-1.9.X-test32-src.7z This is from a parallel branch where I'm doing feature work and more experimental stuff in preparation for 1.9.6+. As usual, I can't provide any guarantees about what's going in or when it'll be done, but I can say that I'm starting to go through the feature backlog. Do not re-request features that you have already asked for, because they're already in the backlog. I'm still running down the list and figuring out which ones are easier to implement. The main reason I'm starting up this thread, however, is that there is a very experimental change in this branch, namely the ability to run video filters multithreaded. Unlike other recent changes to the video filter system, such as 3D acceleration, filters do not need to be rewritten to take advantage of this feature -- the VirtualDub filter API is such that existing filters can be run in parallel. Others have in fact already implemented this before, but I'm a bit late in doing so because it wasn't until after the major filter system rewrites I did for multi-sourcing and 3D acceleration that this was possible in VirtualDub's implementation. Notes on the current implementation:
Change list for this build:
|
| Posted by: jpsdr Aug 4 2009, 08:44 PM |
| Hello. Test with some of my own filters and internal : Input : An avisynth script of DGDecode, output YV12. Color deapth : In YV12, out YUY2. Thread : 1, filter both on auto. My own IVTC automatic IVTC, produce actualy an output of IVTC 2. My own YV12 -> YUY2 convert. IVTC internal My own saturation. resize internal output huffyuv. VDub is at 0% CPU, 161Mo of mermory used, and 100% done but still in progress since half an hour ! To try to eventualy reproduce it, i'll send you by email the job list and all the necessary. BTW, do you intend to make IVTC and Deinterlace work on YV12 ? If no, where can i find the yadif algorithm ? EDIT : I was expecting more than 4-5 threads in the task manager... |
| Posted by: pintcat Aug 4 2009, 10:38 PM |
| Same for me. When VDub reaches 100% the job isn't done. It just keeps going and going... (tested with DV video 720x576 4:3, resized to 720x540 1:1; video compressed with XviD 2-pass, but the 1st pass could not be finished). |
| Posted by: phaeron Aug 5 2009, 04:52 AM |
| I did say it was very experimental. Anyone actually seeing any speedup? And as for threading, by default VirtualDub clamps the thread count to 4 when set to Auto. This is because it's pretty hard to actually get any real parallelism above that level unless you have an insane set of filters, and it could consume a tremendous amount of memory if it tried to thread too far. |
| Posted by: jpsdr Aug 5 2009, 07:19 AM |
| Hello. I know it was experimental, so i've experiment it. I thought you wanted problem to be reported. But, as i'm having an i7 965, i'll try this evening the following : Same chain filter (around 6-7 filters) between 1.9.5-test4 and 1.9.X with threads put to 8, as it's the number of "core" i'm having. I'll tell you if i see speedup. Nevertheless, without the ending time (as i'm doing other stuff on my normal PC while the dedicated video PC is running), it may be a little hard... |
| Posted by: jpsdr Aug 5 2009, 07:45 PM |
| Ok, test done. I've done the folowing : Create a batch process of around 6 filters with 1.9.X. version. (The one i've send to you). Copy the job file into the directory of the 1.9.5-test4 version. This way, in theory, as there was no filter using/producing random data, each version should do exactly the same thing, and should produce exactly the same file. Version 1.9.X configured with threads at "1", filter thread at "8", and frame on "auto". Version 1.9.5 configured with threads at "1". Version 1.9.5 : Process time around 14mn. Version 1.9.X : Process time around 9-10mn. Version 1.9.X produce a 33205 frames file, 1.9.5 produce a 33206 frames file. I assume the difference of 1 is because the 1.9.X is stalled on the last frame, and don't finalise the batch. BUT....!!!!!! I've discover something absolutely abnormal. The file size produced by the 1.9.5 is 16Go, and the file size produced by the 1.9.X is 8Go !!!!!!! I realy doubt the last frame has 8Go size. And, for a 720x576 huffyuv file of 33206 frame, the expected size is around 8Go. So, i don't know wich it is, but there is a problem in the 1.9.5, there isn't in the 1.9.X... In the package i've send to you, i think you have all you need to try to investigate/reproduce the problem. |
| Posted by: phaeron Aug 6 2009, 04:47 AM |
| I fixed a couple of bugs that caused hangs if smart rendering or B-frames were enabled. Test-2 is now up. I did a test with a subset of the filters that I could run from your example, and I got bit exact video between 1.9.5 and 1.9.X. There were several major bugs in the new video processing code in 1.9.X test-1, though, so who knows. About the size difference, the only thing I could think of is that something really bad happened like the entire half of the video was blanked out. Incidentally, you have good taste in anime (Crest of the Stars). |
| Posted by: jpsdr Aug 6 2009, 08:38 AM |
| Yes, Crest/Banner has been a great discovery form me. I've try to make my own fansub DVD, unfortunately, even on the japanese DVDs, video is a real mess (in therm of telecine), so, i'll not be able to do what i'm usualy do : IVTC and accelerate to 25fps, to have like a pure PAL telecine. Of course, the only interest on that it's to NOT have to deinterlace, and having in final a true progressive picture, and finaly a better result than a standard NTSC-PAL transcoding, wich produce interlaced frames. And of course, upscaling 480->576 is better when done on progressive frames. |
| Posted by: jpsdr Aug 6 2009, 06:14 PM |
| Ok, tested the test2 version, with same job. 1.9.X : Process time around 9mn, and end correctly. 1.9.5 : Process time around 12mn. Both produced a 8.01Go file, wich is the size expected, don't know what happened yesterday. What is the "Video filter process-ahead" option for ? (Was on auto during test). What does it do ? If i increase it, will it increase the CPU usage ? I mean, during my test i'm only around 25% CPU usage, so i thought maybe there is way to increase CPU usage, and speed up things. Keep the good work. |
| Posted by: phaeron Aug 7 2009, 06:10 AM |
| The process ahead option is needed since having more than one frame in flight is the only way to run most chains in parallel. Let's say that you had a filter chain that contained filters A, B, and C. Each filter is a 1:1 filter like blur, where one frame in produces one frame out. If I request frame 2 from C, it requests frame 2 from B, which requests frame 2 from A. Filters A, B, and C then process frame 2, in that order. There is no room for parallelism here, because only one filter can run on the frame as it goes through the chain. If you have three threads and three frames, though, then you can run the filters in parallel on different frames. For instance, you could have C working on 3, B working on 4, and A working on 5. Now the filters can work like an assembly line on frames flowing through. This is how VirtualDub runs the filter chain on multiple threads without requiring the filters to be rewritten for multithreading. The moral of the story is that you will typically want the process-ahead setting set to the number of threads in use. This is what the Auto setting does. Note that this only helps if you have filters that are somewhat balanced. If you have a bunch of quick filters and one really, really slow filter, you're going to be completely bottlenecked by the slow filter. The only way to get around that would be to run that one filter in parallel, and that's not something that I support right now (and isn't possible for all filter algorithms). |
| Posted by: jpsdr Aug 7 2009, 12:22 PM |
| Found out something. Put display of input and output. Put swap input/output. Choose color depth input in high deep color, chek with the 3 last. color depth output RGB24. Put a simple filter (Brightness). Pane display is messed up. |
| Posted by: phaeron Aug 8 2009, 04:26 AM |
| Can't reproduce. Are all of those steps needed? I can't imagine that the swap input/output makes a difference. Also, what source are you using? There aren't many codecs that support those last three formats, so you'd have to be using an Avisynth script or some other case where VirtualDub sees an uncompressed input (in this case, it will allow any conversion path). |
| Posted by: jpsdr Aug 8 2009, 08:08 AM |
| Can't also reproduce at home, was produced at work. Input video is uncompressed RGB32. Something again maybe with video driver... |
| Posted by: chornobyl Aug 21 2009, 10:05 AM |
| don't remember how but i crasher it VirtualDub crash report -- build 32759 (release) http://pastebin.com/m6eda4c77 |
| Posted by: jpsdr Sep 20 2009, 02:01 PM |
| Hello. Always still planed for 1.9.6+ (or any 1.9.X) or not ? About version number : what about make an 1.09.07 and then after an 1.10.01 ? |
| Posted by: Jam One Sep 20 2009, 06:24 PM |
| ...What about " 1.9.6.2 ; 1.9.6.5 ; 1.9.6.x "... ? |
| Posted by: stephanV Sep 20 2009, 06:39 PM |
| You can just do 1.10.x without making it 1.09.06. There has been 1.5.10 in the past for example. Adding 0's just makes it look ugly. |
| Posted by: MaxS Sep 21 2009, 04:26 AM |
| Just go with 2.0 There is no law saying 1.9 and 2.0 should be hugely different. |
| Posted by: jpsdr Oct 9 2009, 04:47 PM |
| As i was making some test with my new build of filters, i've encounter this crash : VirtualDub crash report -- build 32759 (release) -------------------------------------- Disassembly: 0051bb20: ee out dx, al 0051bb21: ff db 0ffh 0051bb22: 397500 cmp [ebp+00h], esi 0051bb25: 7409 jz 0051bb30 0051bb27: ff7500 push dword ptr [ebp+00h] 0051bb2a: e8c28e0900 call 005b49f1 0051bb2f: 59 pop ecx 0051bb30: 8d85f0feffff lea eax, [ebp-110] 0051bb36: 3985e8feffff cmp [ebp-118], eax 0051bb3c: 740c jz 0051bb4a 0051bb3e: ffb5e8feffff push dword ptr [ebp-118] 0051bb44: e8a6950900 call 005b50ef 0051bb49: 59 pop ecx 0051bb4a: 8b4df4 mov ecx, [ebp-0ch] 0051bb4d: 8b4550 mov eax, [ebp+50h] 0051bb50: 5f pop edi 0051bb51: 5e pop esi 0051bb52: 5b pop ebx 0051bb53: 64890d00000000 mov fs:[00000000], ecx 0051bb5a: 83c548 add ebp, 48h 0051bb5d: c9 leave 0051bb5e: c3 ret 0051bb5f: dd442404 fld qword ptr [esp+04h] 0051bb63: 51 push ecx 0051bb64: dc0520625e00 fadd qword ptr [005e6220] 0051bb6a: 51 push ecx 0051bb6b: dd1c24 fstp qword ptr [esp] 0051bb6e: e85d8d0900 call 005b48d0 0051bb73: 59 pop ecx 0051bb74: 59 pop ecx 0051bb75: e9868e0900 jmp 005b4a00 0051bb7a: dd442404 fld qword ptr [esp+04h] 0051bb7e: 51 push ecx 0051bb7f: dc0520625e00 fadd qword ptr [005e6220] 0051bb85: 51 push ecx 0051bb86: dd1c24 fstp qword ptr [esp] 0051bb89: e8428d0900 call 005b48d0 0051bb8e: 59 pop ecx 0051bb8f: 59 pop ecx 0051bb90: e9a18e0900 jmp 005b4a36 0051bb95: 57 push edi 0051bb96: 53 push ebx 0051bb97: 8b7c2414 mov edi, [esp+14h] 0051bb9b: 8b44240c mov eax, [esp+0ch] 0051bb9f: f7e7 mul eax, edi 0051bba1: 8bc8 mov ecx, eax 0051bba3: 8b442410 mov eax, [esp+10h] 0051bba7: 8bda mov ebx, edx 0051bba9: f7e7 mul eax, edi 0051bbab: 03c3 add eax, ebx 0051bbad: 8b5c2418 mov ebx, [esp+18h] 0051bbb1: 83d200 adc edx, 00h 0051bbb4: f7f3 div eax, ebx <-- FAULT 0051bbb6: 8bf8 mov edi, eax 0051bbb8: 8bc1 mov eax, ecx 0051bbba: 8b4c241c mov ecx, [esp+1ch] 0051bbbe: f7f3 div eax, ebx 0051bbc0: 8911 mov [ecx], edx 0051bbc2: 8bd7 mov edx, edi 0051bbc4: 5b pop ebx 0051bbc5: 5f pop edi 0051bbc6: c21400 ret 0014 0051bbc9: 8b442404 mov eax, [esp+04h] 0051bbcd: f764240c mul eax, dword ptr [esp+0ch] 0051bbd1: 89442404 mov [esp+04h], eax 0051bbd5: 8bca mov ecx, edx 0051bbd7: 8b442408 mov eax, [esp+08h] 0051bbdb: f764240c mul eax, dword ptr [esp+0ch] 0051bbdf: 03c1 add eax, ecx 0051bbe1: 83d200 adc edx, 00h 0051bbe4: 3b542410 cmp edx, [esp+10h] 0051bbe8: 7313 jnc 0051bbfd 0051bbea: f7742410 div eax, dword ptr [esp+10h] 0051bbee: 8bc8 mov ecx, eax 0051bbf0: 8b442404 mov eax, [esp+04h] 0051bbf4: f7742410 div eax, dword ptr [esp+10h] 0051bbf8: 8bd1 mov edx, ecx 0051bbfa: c21000 ret 0010 0051bbfd: b8ffffffff mov eax, ffffffff 0051bc02: baffffffff mov edx, ffffffff 0051bc07: c21000 ret 0010 0051bc0a: 55 push ebp 0051bc0b: 8bec mov ebp, esp 0051bc0d: 83ec14 sub esp, 14h 0051bc10: 56 push esi 0051bc11: 8b750c mov esi, [ebp+0ch] 0051bc14: 33c9 xor ecx, ecx 0051bc16: 3bf1 cmp esi, ecx 0051bc18: 57 push edi 0051bc19: c645ff00 mov byte ptr [ebp-01h], 00h 0051bc1d: 7f17 jg 0051bc36 0051bc1f: 7c db 7ch Built on Aegis on Wed Aug 05 21:23:21 2009 using compiler version 1400 Windows 5.1 (Windows XP x86 build 2600) [Service Pack 3] EAX = 00000000 EBX = 00000000 ECX = 00000000 EDX = 00000000 EBP = 0012fc78 ESI = 00c65ffc EDI = 005f0400 ESP = 0012fc50 EIP = 0051bbb4 EFLAGS = 00210246 FPUCW = ffff027f FPUTW = ffffffff Crash reason: Integer Divide-by-Zero Crash context: An integer division by zero occurred in module 'VirtualDub'. Pointer dumps: ESI 00c65ff8: 00000000 00000000 005f0400 00000000 00000000 00c65940 00000000 00000002 EDI 005f0400: 46414456 65746c69 432e7372 656e6e6f 29287463 6e49203a 696c6176 6f732064 ESP 0012fc50: 00c65ed0 ffffffff 0051f3c0 00000000 00000000 005f0400 00000000 0012fc84 0012fc70: ffffffff ffffffff 00c65ffc 0046740b 00000000 00000000 00009c44 00c65ed0 0012fc90: 0012fd60 00000000 008ed560 0000007d ffffffec 00000110 00000100 0047abc0 0012fcb0: 7e3a8e53 7e3ac24e 7e3ac291 001503d8 ffffffec 00000100 00000000 00009c44 EBP 0012fc78: 00c65ffc 0046740b 00000000 00000000 00009c44 00c65ed0 0012fd60 00000000 0012fc98: 008ed560 0000007d ffffffec 00000110 00000100 0047abc0 7e3a8e53 7e3ac24e 0012fcb8: 7e3ac291 001503d8 ffffffec 00000100 00000000 00009c44 00000000 00c65ed0 0012fcd8: 0012fcf0 7e3ac2d0 001503d8 ffffffec 00000100 00000000 0012fd04 7ca3b18e Thread call stack: 0051bbb4: VDFractionScale64() 0051f3c0: VDFraction::scale64ir() 0046740b: VDProjectUI::SetVideoFiltersAsk() 7e3ac24e: USER32!DefWindowProcA [7e390000+1c17e+d0] 7e3ac291: USER32!DefWindowProcA [7e390000+1c17e+113] 7e3ac2d0: USER32!SetWindowLongW [7e390000+1c2bb+15] 7ca3b18e: SHELL32!DragAcceptFiles [7c9d0000+6b169+25] 0046d63d: VDProjectUI::MenuHit() 0046de10: VDProjectUI::MenuHit() 7e399488: USER32!GetWindowLongA [7e390000+945d+2b] 7e3a8d8b: USER32!DefWindowProcW [7e390000+18d20+6b] 0047a5c0: VDUIFrame::DefProc() 0046ec21: _catch$?MainWndProc@VDProjectUI@@IAEJIIJ@Z$0() 7e399488: USER32!GetWindowLongA [7e390000+945d+2b] 004663c0: VDProjectUI::WndProc() 0047ac75: VDUIFrame::StaticWndProc() 7e398734: USER32!GetDC [7e390000+86c7+6d] 7e398816: USER32!GetDC [7e390000+86c7+14f] 7e3989cd: USER32!GetWindowLongW [7e390000+88a6+127] 7e3aa43b: USER32!PeekMessageA [7e390000+1a340+fb] 7e3996c7: USER32!DispatchMessageA [7e390000+96b8+f] 00452bb6: WinMain@16() 005b99cb: __tmainCRTStartup() 7c817077: kernel32!RegisterWaitForInputIdle [7c800000+1702e+49] -- End of report Happen only when my new build of filters is present, and when doing Video -> Filters when no video is loaded. Doesn't happen with my old build, doesn't happen when a video is loaded, doesn't happen on 1.9.6. |
| Posted by: phaeron Oct 10 2009, 04:44 AM |
| Caused by uninitialized variable, so it worked by chance. Fixed in 1.9.7 test-4. |
| Posted by: Barough Feb 9 2010, 02:36 PM |
| @ phareon Any plans on adding the fixes etc. that u made up to now into the v1.9.x branch? Also do u plan on making the Video Compression threads option like the filter threading. |
| Posted by: phaeron Feb 10 2010, 04:08 AM |
| I'm not going to backport the fixes from the experimental branch into 1.9.x -- too risky. No current plans on increasing the video codec threading support. If I did, it would only be possible for codecs that lack delta frames, like Huffyuv and Lagarith. |
| Posted by: Barough Feb 10 2010, 06:29 AM |
| Thnx for the reply. I think u misunderstood me about the fixes, I meant backport the fixes from the 1.9.5+ Stable releases into the Experimental branch and not the other way around. There's been a lot of fixes since the v1.9.x Experimental Test 2 u released. But i really hope to see the new filter threading feature etc. to show up in a Stable release in a near future. |
| Posted by: phaeron Feb 11 2010, 07:45 AM |
| Oh, sorry. The thread's been split a bit with the external encoder stuff, but I've cross-integrated the fixes and uploaded test-8. |
| Posted by: Barough Feb 11 2010, 11:11 AM |
| Thnx |
| Posted by: phaeron Mar 8 2010, 04:25 AM |
| Test-9 added -- main change is that I've fixed several serious bugs in the external encoder path on Windows 98 and NT4.0. There is now also a vdlaunch.exe/vdlaunch64.exe stub to work around some annoying deficiencies in the pre-Vista Win32 API. Import/export of encoder settings didn't make it into this build, but I still want to put that in before release. |
| Posted by: Gromozeka Mar 8 2010, 10:46 AM | ||
External encoders\x264.exe -o "%(tempvideofile)" --stdin yuv --crf 23.0 --level 4.1 --aq-mode 4 --subme 9 --qpmin 17 --qpmax 27 --trellis 2 --psy-rd 0.4:0.4 --keyint 250 --min-keyint 2 --ref 5 --mixed-refs --bframes 3 --b-adapt 2 --weightb --direct auto --deblock -1:-1 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --deadzone-inter 21 --deadzone-intra 11 --ipratio 1.4 --pbratio 1.4 --nr 0 --scenecut 40 --qcomp 0.65 --me umh --merange 8 --thread-input --threads auto - %(width)x%(height) --fps %(fpsnum)/%(fpsden) Cannot launch external program. The program launch helper vdlaunch.exe is mising |
| Posted by: phaeron Mar 9 2010, 04:34 AM |
| Oops, that was dumb. Reuploaded with packaging step fixed. |
| Posted by: Gromozeka Mar 9 2010, 07:00 AM | ||
work fine |
| Posted by: Gromozeka Mar 9 2010, 06:53 PM |
This feature ''Process partial output when render is aborted'' not save when VirtualDub close  |
| Posted by: phaeron Mar 10 2010, 05:21 AM |
| Fixed in test-10. |
| Posted by: Gromozeka Mar 10 2010, 05:55 AM | ||
Thanks may be you add external encoder for capture? |
| Posted by: phaeron Mar 12 2010, 04:45 AM |
| Not something I'd planned for the next major release. Can't think of a reason why it couldn't be done, though. |
| Posted by: olnima Mar 12 2010, 11:31 AM | ||
Goooooood idea... |
| Posted by: Barough Mar 12 2010, 01:25 PM | ||||
Yeah, sound like a good idea 4 sure. |
| Posted by: John I. Mar 13 2010, 04:56 AM |
| Hello, A minor bug, the feature Options/Preferences/Batch/Show status window for batch operations is not saved after exiting VirtualDub (all versions of 1.9.X) Thanks for all the great work. |
| Posted by: phaeron Mar 13 2010, 07:04 AM |
| Thanks, fixed. |
| Posted by: pureocean Mar 13 2010, 04:16 PM |
| Minor bug: File menu -> "Run video analysis pass" can't save XViD 1 pass. Therefore, I can using classic method as "Save AVI". Working. Video filter thread+progress-ahead settings: Auto. My CPU: AMD Phenom II X3 710 Really really increased encoding speed in 1.9.X-test10(exp). Especially xvid 1pass. Thanks to your efforts. P.S.: I hope, major relase (2.x) support will internal import MP4 and MKV file format with multi audio streams. |
| Posted by: phaeron Mar 14 2010, 09:43 PM |
| Yeah, I discovered this problem a while ago. There are two use cases for that feature: running filters in analysis mode, and running codecs in analysis mode. Only one of those two cases is covered, and I need to split the command. I assume you're just saying that the with-codec mode is missing, and not that there was a change in behavior from earlier versions? |
| Posted by: pureocean Mar 14 2010, 11:23 PM | ||
Yes. Codec mode's file is missing. I selected Compression->XViD->Twopass-1st pass. VDub can't create Xvid-1pass file. Unnecessarily continues encode progressing. I am just tried to 1.9.X-test10-expermential. Beforehand I was using 1.9.9.-test10-stable. XviD 1st pass file could creat. Thank you very much for Virtualdub project. Incredible software and very useful. |
| Posted by: dloneranger Mar 16 2010, 06:35 PM |
| I have a few questions about the test version 1) Multiple filter chains running at the same time If the filter list includes a gpu filter (vdshader etc) am I correct in assuming that it's going to be a bottleneck If so, should the video filter threading be set to 1 thread before rendering a file using a gpu filter? 2) fcchandler In the changelog there's an entry "The preferred handler (fccHandler) field in the video stream is now ignored by default for consistency" Could you give a description of this please, the whys and reasons for enabling or disabling it Thanks |
| Posted by: phaeron Mar 17 2010, 03:52 AM | ||||
No, you can still benefit from multiple threads -- VirtualDub can run all of the other CPU-based filters on another frame in parallel to the one that's busy in the GPU filter. By the way, vdshader is not a GPU filter. It uses shader syntax, but it still runs the shader on the CPU. gpufilterdx is the one that can use the GPU.
There are two pertinent fields in the video stream. The biCompression field is required and identifies the format, whereas the fccHandler field is optional and identifies the codec that was used to create the stream. The reason that I disabled the use of the fccHandler field is that it led to unexpected behavior where two files that used the same format would open with different codecs. For instance, you could have two XviD files where one would decode with XviD and the other one would decode with ffvfw, just because different codecs were used to encode it. This was particularly problematic when trying to tweak decoding settings on one of the codecs. |
| Posted by: dloneranger Mar 17 2010, 04:40 AM |
| Thanks for the clarifications |
| Posted by: John I. Mar 19 2010, 10:11 PM |
| Hello, There is a problem when a video is edited (any format) and is previewed in any filter. for example: a video capture of 150,000 frames, i would like to cut the first 100,000 frames, keep the next 20,000 frames, and discard the last 30,000. |_________100,000____________|__20,000__|___30,000___| When i try to adjust the brightness & contrast or use any other filter on the remaining 20,000 frames, what the filter preview displays is completely different from what is displayed on the time line. This also applies to 1.9.9 |
| Posted by: phaeron Mar 20 2010, 03:09 AM |
| There is a known limitation where the edit state of the timeline won't be reflected in the preview if you're using a filter afterward that changes frame rate (IVTC in reduce or deinterlace in double mode). Otherwise, it should show the edited timeline. I just tried it in 1.9.8 and it seems to be working fine. What exactly are you seeing? Just that the edits aren't showing up, or that the frame images themselves are wrong? |
| Posted by: John I. Mar 20 2010, 02:46 PM |
| Hello, The frame images themselves are wrong. I'm using only one filter (the internal Brightness & Contrast). No frame rate conversion. * For a test, - take a full length movie (DIVX, MPEG2, XVID etc.. don't make any difference), - select and delete from the beginning the first half ~70,000 frames of the movie at the nearest key frame, - add internal brightness & Contrast filter, - open its preview window, - hold the frame slider and move from beginning to end. * Another test, the same movie, delete the first 4000 frames, and follow the same above steps. The first frame in the filter preview window might be the same as the first one on the time line, but when holding the slider from beginning to end, the display stops at a frame and doesn't show the following frames. Another observation, If the number of the deleted frames is increased, the undisplayed frames also increase. |
| Posted by: dloneranger Mar 20 2010, 05:08 PM |
| It looks like the preview window is getting the deletions applied incorrectly An easy way to check is to make a very short test clip of say 100 frames of motion (no fade outs etc) Delete the middle, leaving just the first 5 frames and the last 5 frames Now add a filter with a preview window and go through frame by frame The preview will be incorrect on frame 5 and after |
| Posted by: Gromozeka Mar 20 2010, 09:43 PM |
| Hello I using command line for DVD encoding, but can not push this External encoders\ffmpeg -f rawvideo -s %(width)x%(height) -i - -f yuv4mpegpipe - | mpeg2enc.exe -o "%(tempvideofile)" --multi-thread 2 --verbose 0 --video-bitrate 5500 --format 9 --aspect 2 --ratecontroller 0 --quantisation 3 --interlace-mode 0 --motion-search-radius 32 --reduction-4x4 1 --reduction-2x2 1 --max-gop-size 15 --video-norm p --intra_dc_prec 8 --no-constraints --custom-quant-matrices tmpgenc --b-per-refframe 2 VirtualDub not compressed Phaeron, where mistake? |
| Posted by: phaeron Mar 21 2010, 01:02 AM |
| Alright, figured it out -- it was a slightly different bug than I was thinking of. Try 1.9.9-test11 in the 1.9.9 test thread. |
| Posted by: John I. Mar 21 2010, 09:04 AM |
| Hello, OK. I've done extensive testing using the 1.9.9-test11 on a 3hr video capture i couldn't work on before, and applied over 50 edits to the video. The time line is now displayed correctly in any filter preview. Thanks. Will this be applied to the 1.9.X branch to use the filter threading feature ? It does make a big difference on a quad core CPU. Thanks again. |
| Posted by: phaeron Mar 21 2010, 06:22 PM |
| The preview window still works single-threaded because there are additional considerations when that window is up (the filter's execution has to be synchronized against its filter dialog). I haven't come up with a solution yet for allowing other filters to multi-thread in this situation. |
| Posted by: phaeron Mar 22 2010, 04:03 AM |
| Okay, test-11 is up. I added import/export for external encoder profiles since that's the last thing that was missing that I felt was essential to the feature. An important thing to know about this feature is that it will attempt to store a relative path to the executables if you have them in the same directory or under the directory that you're saving the .vdprof file into, which makes it easier to cart around a portable encoder setup. |
| Posted by: Gromozeka Mar 22 2010, 10:40 AM | ||
Thanks, phaeron works fine Help me with this line (line not work in VirtualDub) mencoder -rawvideo - -o "%(tempvideofile)" -of rawvideo -mpegopts format=dvd -srate 48000 -ofps %(fps) -ovc lavc -oac lavc -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:keyint=15:trell:mbd=2:precmp=2:subcmp=2:cmp=2:dia=-10:predia=-10:cbp:mv0:vqmin=3:vb_qfactor=1.25:vb_qoffset=0:vqcomp=0.75:dc=8:vstrict=0:vrc_maxrate=8800:vbitrate=7000:aspect=4/3 |
| Posted by: stephanV Mar 22 2010, 10:59 AM |
| You are setting an audio encoder, this could be the problem. Check mencoder documentation. |
| Posted by: Gromozeka Mar 22 2010, 11:08 AM | ||
I'm delete -oac lavc But i think the problem - input yuv |
| Posted by: stephanV Mar 22 2010, 11:11 AM |
| Well you'd have to check mencoder documentation how to pipe raw input to it. |
| Posted by: Gromozeka Mar 22 2010, 11:36 AM | ||
I read documentation, but don't know how do it |
| Posted by: v0lt Mar 22 2010, 02:35 PM | ||
Thank you for adding the field "Command arguments"! |
| Posted by: Gromozeka Mar 22 2010, 02:50 PM |
| Phaeron, this option not work? Why? mencoder -rawvideo on:fps=%(fps) -nosound -mpegopts format=dvd -srate 48000 -ofps 25 -ovc lavc -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:keyint=15:trell:mbd=2:precmp=2:subcmp=2:cmp=2:dia=-10:predia=-10:cbp:mv0:vqmin=3:vb_qfactor=1.25:vb_qoffset=0:vqcomp=0.75:vstrict=0:vrc_maxrate=8800:vbitrate=7000:aspect=4/3 -of rawvideo -o "%(tempvideofile)" |
| Posted by: phaeron Mar 23 2010, 04:44 AM |
| Check the log (F8) -- it'll have any error output as long as you have log stdout/stderr enabled for that encoder. Also, make sure you have a build of mencoder that works properly with stdin input. Some of the command-line apps have builds floating around with busted stdin support on Windows because they're lacking a magic statement to force binary mode. |
| Posted by: Gromozeka Mar 23 2010, 11:30 AM | ||
This is work ffmpeg -i 1.avs -f yuv4mpegpipe - | mencoder - -of mpeg -o 1.mpg -nosound -mpegopts format=dvd -srate 48000 -ofps 25 -ovc lavc -oac lavc -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:keyint=15:trell:mbd=2:precmp=2:subcmp=2:cmp=2:dia=-10:predia=-10:cbp:mv0:vqmin=3:vb_qfactor=1.25:vb_qoffset=0:vqcomp=0.75:dc=8:vstrict=0:vrc_maxrate=8800:vbitrate=5000:aspect=4/3 |
| Posted by: Gromozeka Mar 23 2010, 12:16 PM |
| Phaeron, this must be work? but ... External encoders\ffmpeg -f rawvideo -s %(width)x%(height) -i - -f yuv4mpegpipe - | mencoder - -of mpeg -o "%(tempvideofile)" -nosound -mpegopts format=dvd -srate 48000 -ofps 25 -ovc lavc -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:keyint=15:trell:mbd=2:precmp=2:subcmp=2:cmp=2:dia=-10:predia=-10:cbp:mv0:vqmin=3:vb_qfactor=1.25:vb_qoffset=0:vqcomp=0.75:vstrict=0:vrc_maxrate=8800:vbitrate=5000:aspect=4/3 External encoders\ffmpeg -f rawaudio -i - -acodec ac3 -ar 48000 -ac 2 -vol 384 -ab 192k "%(tempaudiofile)" External encoders\ffmpeg -i "%(tempvideofile)" -vcodec copy -i "%(tempaudiofile)" -acodec copy -f vob "%(outputfile)_final.mpg" -r %(fps) ffmpeg & mencoder: http://rapidshare.com/files/367123528/ffmpeg_mencoder.rar.html |
| Posted by: pureocean Apr 3 2010, 04:59 AM | ||
| About Test11 (build 33621): It shows the following report, even if the setting is turned off(Warn when non-zero starting offset is detected):
|
| Posted by: phaeron Apr 3 2010, 05:24 AM |
| Two different things: a non-zero stream offset is not the same as the bits per sample field. |
| Posted by: pureocean Apr 3 2010, 08:00 PM | ||
Thank you for info. If possible, you can add this turn-off setting? That is important: Smart rendering (all included: Full processing, Normal or Fast recompress modes) don't working. Filename (same with mentioned mp3 caution): supernatural.s05e16.hdtv.xvid-fqm I cut a few frames. Selected XViD single-pass (Quantizer: 2)... VDub can saving properly but blocked when it comes to processing in the cut off frames. VDub 1.8.8's smart rendering feature is working properly. |
| Posted by: Barough Apr 10 2010, 05:02 AM |
| @ Avery When u have the time, do u think u could backport all the v1.9.9 Stable fixes into the 1.9.x Dev. branch and make a new Test Build available. |
| Posted by: MaxS Apr 12 2010, 06:51 AM | ||
\Kasumi\source\a_stretchrgb_mmx.asm (line 252):
mm7 is never used after that... |
| Posted by: phaeron Apr 13 2010, 05:16 PM |
| Yeah, it's unused. Bit misnamed, because what I'm really using in that function is a 0x00FF word mask, and not a red/blue mask. |
| Posted by: blob2500 Apr 13 2010, 09:25 PM |
| Excuse me, is test13 the last "official" test version? I download it from this link http://www.virtualdub.org/beta/VirtualDub-1.9.X-test13.zip (I found it changing for curiosity 11 with 13 and it worked !  ) but there isn't a link / changelog in first post. |
| Posted by: phaeron Apr 15 2010, 03:53 AM |
| Sometimes I make quick test releases for specific people to look at. I've updated the links on the first page to test14 anyway, though. Hasn't been synced to 1.9.9 yet, but does contain some IVTC filter improvements. |
| Posted by: blob2500 Apr 15 2010, 11:16 AM |
| Thanks for your reply |
| Posted by: Loadus Apr 16 2010, 12:07 AM |
| I have two encoder profiles on the list but the export dialog only shows the first one? Using test 14 ... EDIT: Superawesomemaximus feature btw |
| Posted by: phaeron Apr 16 2010, 04:01 AM |
| The export dialog shows encoding sets, not encoders. |
| Posted by: Loadus Apr 16 2010, 04:39 AM | ||
I'll demonstrate with pics, it'll be faster: Sets I have (there are many more, I just added the DVD for this demo):  Selecting mp4 in the export dialog:  All it gives me is the DVD (latest addition) and nothing else (and it will encode using the DVD):  I'm doing something wrong, just don't know what. |
| Posted by: Gromozeka Apr 16 2010, 02:14 PM |
| Loadus its old bug, but Avery not fix him |
| Posted by: Loadus Apr 17 2010, 05:56 PM | ||
It will be fixed due time, don't worry. Remember, Phaeron is doing this on his free time. ^^ I just wanted to report it, just so it was on record. |
| Posted by: phaeron Apr 18 2010, 04:35 AM |
| Indeed, it's now fixed in test-16. I've synced the 1.9.X branch to fixes in the 1.9.9 stable release. In addition, this version has support for using 2+ threads for video compression when only key frames are in use. This includes key frame only codecs such as Huffyuv, and it also includes other codecs when the key frame interval is forced to one. (XviD does not work for this, because it ignores the key frame request flag.) I've also tweaked the IVTC filter a bit to better match older versions with the pre-filter algorithm. |
| Posted by: Loadus Apr 18 2010, 04:41 AM | ||
You are zhe mastar. ^^ Well, I thought I'd go get some sleep tonight but *fubar* it, I'm gonna write some encoder sets.  :D |
| Posted by: BugMaster Apr 18 2010, 03:49 PM | ||
About keyframe forcing. I tried to add it support to x264vfw but in result have to disable it due the VirtualDub bug (at least it is the bug in my opinion). The bug reveal itself that even without using keyframe forcing VirtualDub ask first frame to be keyframe and probably due the using of "VirtualDub hack" technique (return of 1-byte 0x7f frames with XVID fourcc to inform about delayed frames due buffering) it ask to make few next frames (depends on the number of delayed frames) also keyframes until first real frame is returned. |
| Posted by: Barough Apr 18 2010, 04:26 PM | ||
Thnx a lot 4 the sync with the 1.9.9 stable Avery. |
| Posted by: dloneranger Apr 18 2010, 06:15 PM |
| Any chance of modifying the ivtc filter for duplicate removal of 1-in-6 frames as well as 1-in-5 [edit] nevermind, f_itvc was pretty easy to fixup for the task |
| Posted by: phaeron Apr 18 2010, 09:43 PM | ||
Hmm. I don't think it's a bug, but it's an ugly ambiguity. The problem is that the introduction of the frame skew between input and output means that it is ambiguous as to whether the key frame request flag means to force a key frame for the input frame or for the output frame. VirtualDub's interpretation is that this affects the frame being output, i.e. setting the flag should cause the key frame flag to be set on the output. It would be pretty easy to change this to the other interpretation of having the flag apply to the input frame, but even backwards compatibility issues aside I'm not sure that makes more sense. However, there is another piece of information the codec can use: ICM_COMPRESS_FRAMES_INFO will also be sent with a key rate interval of 1 when VirtualDub is trying to do this, so that would be another indicator that all frames should be made key frames. Incidentally, even if this all did work out, the result would be an XviD or H.264 stream that contained all I-frames... not sure how interesting that is, given that there are decent codecs available designed for I-frame only operation. |
| Posted by: DanskDranker Apr 18 2010, 10:27 PM |
| Will the new version be 2.0??? |
| Posted by: BugMaster Apr 19 2010, 06:56 AM | ||
From http://msdn.microsoft.com/en-us/library/dd742972%28VS.85%29.aspx dwFlags Flags used for compression. The following value is defined: ICCOMPRESS_KEYFRAME - Input data should be treated as a key frame. So from my point it must apply to input frame. But any way I also can't enable this feature even if you fix it in new versions (due the complitability with old VirtualDub versions). So you can don't bother with it. This was only information to you about doubtful behaviour. |
| Posted by: phaeron Apr 20 2010, 04:17 AM | ||||
I haven't decided yet. Does it matter?
I'll agree with that, but note that the the documentation for ICCOMPRESS_KEYFRAME passed to the ICCompress() function is different, and the interface doesn't allow for any frame skew for which the distinction would matter. We're already dealing with an out-of-band mechanism in order to implement the frame delay. I don't think it would be much of a problem to switch the behavior, because normally XviD and x264vfw are used with the key frame interval disabled, and anyone who tried to use otherwise would have discovered that it doesn't work. In any case, the worst error is that you get a few extra I-frames at the beginning of a sequence. However, I just realized that there is another problem with doing this, which is that it makes actually implementing a key frame delay difficult in that you may not be able to tell whether you need to reset the interval until several frames after you already needed to do it. For instance, if the codec has a delay of 3 and you are trying to hit a key frame interval of 2, it would be impossible to react quickly enough to manage the interval properly, because if the codec initiates a key frame on its own it's already 2-3 frames too late to change the incoming flags. Given the circumstances, I'll change the error message in the multithreading code to just indicate an incompatibility, as it isn't fair to blame to codec for this. That having been said, if you could implement the specific case of lKeyRate=1 in the ICM_COMPRESS_FRAMES_INFO message and all frames marked as ICCOMPRESS_KEYFRAME, that would be an unambiguous case that would make this situation work. Edit: One other thing I forgot to mention -- the threaded compressor is fine with a drop frame (size=0, flags=!AVIIF_KEYFRAME) even in multithreaded mode. |
| Posted by: jpsdr Apr 20 2010, 08:52 AM | ||
Does it mean in 'Threading -> Video compression threads', value can be 2 or more for Huffyuv and lagarith codec ? I'm having an i7@980 (6 cores + HT), what value do you suggest i can use for video filter threading ? I'm thinking 8 for video filter threading and 4 for Video compression threads (wich will make the maximum 12 avaible on my CPU). Video process ahead, should it be left to auto, or is there an optimal value ? |
| Posted by: phaeron Apr 21 2010, 03:18 AM |
| Yes, it does. However, whether or not that is useful depends on whether the rest of the pipeline can feed all of those codecs. The decompression half is not currently multithreaded. |
| Posted by: jpsdr Apr 28 2010, 07:38 AM |
| I've made some work with this version, to discover a problem. (Now, i must redo everything... ) All my outpout videos were 1 frame shorter. Settings was to 8 threads/frames for video filter, 4 for compression output. Audio was on none/direct stream copy. My input files were avisynth scripts. Color was either YV12/YV12 or YV12/YUY2 Output was either lagarith or Huffyuv. Video were atround 32000 frames size. I've not been able to reproduce the problem with a little (100) video test clip created by VDub. |
| Posted by: fredgiblet Apr 28 2010, 08:16 AM | ||
We need to know if we need to start planning our 2.0 release party. |
| Posted by: jpsdr Apr 28 2010, 05:14 PM |
| I've redone half of my videos, with exactly the same processing, and no problem, so, it's realy related to this release. |
| Posted by: John I. Apr 28 2010, 08:02 PM |
| VirtualDub 1.9.x-test16 is losing frames. Settings: ---------------- Video compression threads= 1 Video filter threading= Auto Video filter process-ahead= Auto Source= AVI (Uncompressed) 27 frames. ---------------- When re-compressing using 'Full processing mode': Case 1: Codec= (XVID 1 Pass) Output = 22 frames (5 Frames lost) Case 2: Codec= (XVID 2 Pass) Output = 22 frames (5 Frames lost) Case 3: Codec= (DIVX 1 Pass) Output = 23 frames (4 Frames lost) Case 4: Codec= (DIVX 2 Pass) Output = 23 frames (4 Frames lost) Case 5: Codec= (Uncompressed) Output= 27 frames (NO LOSS) Full Processing ---------------- Case 6: VirtualDub 1.9.9 (Any Codec) Output= 27 frames (NO LOSS) |
| Posted by: mayhem Apr 28 2010, 11:17 PM |
| Yup, its not isolated, just did two quick little test videos, one was 112 frames and the other 142 frames and after processing with test16 they came out as 108 and 139, losing 4 frames, and 3 frames respectively. This was in full process mode with threading enabled, although even after setting the filter threading to disabled this still occured. After setting the compressor threading to 0 behaviour returned to normal. |
| Posted by: phaeron Apr 29 2010, 05:04 AM |
| Yeah, this was caused by some changes I tried to make to fix some annoying issues with the B-frame delay queue code. Basically, it was a bit sketchy in one-thread mode, and it became unreliable in multithreaded mode (100% CPU lockups). I'm trying to rewrite it. |
| Posted by: DanskDranker Apr 29 2010, 03:38 PM |
| Build 33732 is not good. It does not .Pass file when I have they started to convert my video into Xvid Twopass 1st pass, but it does in build 32817 |
| Posted by: phaeron Apr 30 2010, 04:20 AM |
| Uh, in English? |
| Posted by: phaeron Apr 30 2010, 05:11 AM |
| Pushed out another release with an attempted fix for some of the frame dropping issues. Also, I figured out and fixed the problem that was causing Run Video Analysis Pass to not run the video codec like it does in 1.9.9. |
| Posted by: Barough Apr 30 2010, 11:44 AM |
| Thnx for the new Build. |
| Posted by: John I. Apr 30 2010, 02:45 PM | ||
Frame dropping issue is resolved. Thanks phaeron |
| Posted by: pureocean Apr 30 2010, 06:54 PM |
| @phaeron: Thank you very much for build 33740. Xvid 1pass problem is fixed. If you can fix to Smart Rendering, i would be very grateful. Thank you for all your efforts. |
| Posted by: DanskDranker Apr 30 2010, 10:05 PM |
| Thank You. It works great now Edit: It works not 100%, so here is a crash report VirtualDub crash report -- build 33740 (release) -------------------------------------- Disassembly: 00421ca0: 53 push ebx 00421ca1: c644242c01 mov byte ptr [esp+2ch], 01h 00421ca6: e8e5260600 call 00484390 00421cab: 84c0 test al, al 00421cad: 7517 jnz 00421cc6 00421caf: 8b4c2410 mov ecx, [esp+10h] 00421cb3: 3bcb cmp ecx, ebx 00421cb5: 885c2424 mov [esp+24h], bl 00421cb9: 7407 jz 00421cc2 00421cbb: 8b11 mov edx, [ecx] 00421cbd: 8b4204 mov eax, [edx+04h] 00421cc0: ffd0 call eax 00421cc2: 32c0 xor al, al 00421cc4: eb2f jmp 00421cf5 00421cc6: 8b442410 mov eax, [esp+10h] 00421cca: 0fb6500c movzx edx, byte ptr [eax+0ch] 00421cce: 8b4810 mov ecx, [eax+10h] 00421cd1: 8b4008 mov eax, [eax+08h] 00421cd4: 53 push ebx 00421cd5: 53 push ebx 00421cd6: 52 push edx 00421cd7: 50 push eax 00421cd8: 51 push ecx 00421cd9: 8bce mov ecx, esi 00421cdb: e8a0fcffff call 00421980 00421ce0: 8b4c2410 mov ecx, [esp+10h] 00421ce4: 3bcb cmp ecx, ebx 00421ce6: 885c2424 mov [esp+24h], bl 00421cea: 7407 jz 00421cf3 00421cec: 8b11 mov edx, [ecx] 00421cee: 8b4204 mov eax, [edx+04h] 00421cf1: ffd0 call eax 00421cf3: b001 mov al, 01h 00421cf5: 8b4c241c mov ecx, [esp+1ch] 00421cf9: 897d00 mov [ebp+00h], edi 00421cfc: 5f pop edi 00421cfd: 5d pop ebp 00421cfe: 5e pop esi 00421cff: 5b pop ebx 00421d00: 64890d00000000 mov fs:[00000000], ecx 00421d07: 83c418 add esp, 18h 00421d0a: c3 ret 00421d0b: cc int 3 00421d0c: cc int 3 00421d0d: cc int 3 00421d0e: cc int 3 00421d0f: cc int 3 00421d10: 6aff push 0ffh 00421d12: 6850005f00 push 005f0050 (RtlUnwind@16+161a) 00421d17: 64a100000000 mov eax, fs:[00000000] 00421d1d: 50 push eax 00421d1e: 64892500000000 mov fs:[00000000], esp 00421d25: 83ec08 sub esp, 08h 00421d28: 53 push ebx 00421d29: 55 push ebp 00421d2a: 56 push esi 00421d2b: 57 push edi 00421d2c: 8b7c2428 mov edi, [esp+28h] 00421d30: 33db xor ebx, ebx 00421d32: 8bf1 mov esi, ecx 00421d34: 8b4f40 mov ecx, [edi+40h] <-- FAULT 00421d37: 895c2428 mov [esp+28h], ebx 00421d3b: 395e6c cmp [esi+6ch], ebx 00421d3e: 895c2420 mov [esp+20h], ebx 00421d42: 0f8407010000 jz 00421e4f 00421d48: 385c242c cmp [esp+2ch], bl 00421d4c: 7419 jz 00421d67 00421d4e: 8b07 mov eax, [edi] 00421d50: 8b10 mov edx, [eax] 00421d52: 8bcf mov ecx, edi 00421d54: ffd2 call edx 00421d56: 8b4e68 mov ecx, [esi+68h] 00421d59: 3bcb cmp ecx, ebx 00421d5b: 7407 jz 00421d64 00421d5d: 8b01 mov eax, [ecx] 00421d5f: 8b5004 mov edx, [eax+04h] 00421d62: ffd2 call edx 00421d64: 897e68 mov [esi+68h], edi 00421d67: 8b0d847e6700 mov ecx, [00677e84] 00421d6d: 3bcb cmp ecx, ebx 00421d6f: 7411 jz 00421d82 00421d71: 8b01 mov eax, [ecx] 00421d73: 8b10 mov edx, [eax] 00421d75: 53 push ebx 00421d76: 681ca86600 push 0066a81c 00421d7b: 68f42f6000 push 00602ff4 00421d80: ffd2 call edx 00421d82: 8b4624 mov eax, [esi+24h] 00421d85: 8b28 mov ebp, [eax] 00421d87: 89442410 mov [esp+10h], eax 00421d8b: 8b5c2410 mov ebx, [esp+10h] 00421d8f: 896c2414 mov [esp+14h], ebp 00421d93: c703dc2f6000 mov dword ptr [ebx], 00602fdc 00421d99: 8b4c2428 mov ecx, [esp+28h] 00421d9d: 85c9 test ecx, ecx 00421d9f: c6 db 0c6h Built on Aegis on Thu Apr 29 21:55:10 2010 using compiler version 1400 Windows 6.1 (Windows Vista x64 build 7601) [Service Pack 1, v.153] EAX = 0ca3fec4 EBX = 00000000 ECX = 0250d368 EDX = 024f5238 EBP = 0ca3ff08 ESI = 0250d368 EDI = 00000000 ESP = 0ca3fe70 EIP = 00421d34 EFLAGS = 00010246 FPUCW = 027f FPUTW = ffff Crash reason: Access Violation Crash context: An out-of-bounds memory access (access violation) occurred in module 'VirtualDub'... ...reading address 00000040... ...while running thread "Processing" (thread.cpp:179). Pointer dumps: EAX 0ca3fec0: 0250d1d0 0ca3fefc 005f0220 00000000 004215b9 00000000 0250d1d0 024fcfb8 ECX 0250d368: 00603038 00000060 00000000 000005a0 0250d068 024f8c68 0250d130 01000001 EDX 024f5238: 024ea6a4 00000000 6e616801 024ec4d8 0250dd00 00000000 0000061c 00000000 ESI 0250d368: 00603038 00000060 00000000 000005a0 0250d068 024f8c68 0250d130 01000001 ESP 0ca3fe70: 00000001 0250d368 0ca3ff08 0250d368 776bf9b5 760c014d 0ca3fec4 005f0050 0ca3fe90: ffffffff 00422bda 00000000 00000001 0250d368 0250d368 00424403 00000001 0ca3feb0: 0250d1d0 0250d30c 006028dc 00000000 0250d1d0 0ca3fefc 005f0220 00000000 0ca3fed0: 004215b9 00000000 0250d1d0 024fcfb8 004ee587 0ca3ff14 00000001 00000000 EBP 0ca3ff08: 0ca3ff48 0052d90b 024fcfb8 0061fb08 00000000 0062fca0 000000b3 0062fc88 0ca3ff28: 00602e94 0062fca0 000000b3 0062fc88 00602e94 0ca3ff70 005f7dfd 00000000 0ca3ff48: 0ca3ff80 005d643e 0250d1d0 c078f129 00000000 024fcfb8 024fcfb8 c0000005 0ca3ff68: 0ca3ff54 0ca3fa48 0ca3ffc4 005d9c60 ccbd2d99 00000000 0ca3ff94 005d64e3 Thread call stack: 00421d34: VDDubVideoProcessor::WriteFinishedVideoFrame() 776bf9b5: ntdll!NtSetEvent [776a0000+1f9a0+15] 760c014d: KERNELBASE!SetEvent [760b0000+1013d+10] 00422bda: VDDubVideoProcessor::RunPathFlushCompressor() 00424403: VDDubVideoProcessor::WriteVideo() 004215b9: VDDubProcessThread::ThreadRun() 004ee587: ?$VDProtectedAutoScope1::?$VDProtectedAutoScope1() 0052d90b: VDThread::StaticThreadStart() 005d643e: _callthreadstartex() 005d64e3: _threadstartex@4() 75293e5d: kernel32!BaseThreadInitThunk [75280000+13e4b+12] 776d9df2: ntdll!RtlInitializeExceptionChain [776a0000+39d8f+63] 776d9dc5: ntdll!RtlInitializeExceptionChain [776a0000+39d8f+36] -- End of report |
| Posted by: DanskDranker May 1 2010, 05:52 PM |
| Something News??? |
| Posted by: phaeron May 1 2010, 11:11 PM |
| Perhaps you could be a bit patient while I debug this? Update: Please try test-18. In local testing, it passes XviD smart rendering stress testing on 0/1 threads and Huffyuv recompression on 0-2 threads. |
| Posted by: pureocean May 2 2010, 04:47 AM |
| @phaeron: Smart rendering is working now. Anyomore, no need to using VDub1.8.8 for it. Thank you very much for fix. There exists a minor bug: Although selected Fast Compress with Smart Rendering, if there is filters, Smart Rendering don't working. If filters is removed, Smart Rendering properly working. (I'm sorry my bad english.) |
| Posted by: DanskDranker May 3 2010, 05:51 AM |
| Thank You Now it works 100%  |
| Posted by: phaeron May 4 2010, 05:20 AM |
| I fixed the frame mapping with normal/fast recompress mode with filters enabled... but I'm not sure if it will fix the smart rendering issue. Try test-19. |
| Posted by: pureocean May 4 2010, 06:59 AM | ||
Thank you for your interest. I tried new update(test19 - build 33769). No change. Smart rendering+filters issue still exist. Only, If it's removed from filters menu, can work smart rendering. I using always this filter for navigation: http://pic.leech.it/i/61cce/4804f64exampl.gif I'm sorry to waste your time. I'll be glad you fixed your opportune time. |
| Posted by: phaeron May 5 2010, 06:12 AM |
| Alright, I see the real problem now. I'm starting to think I should just block this case. The problem is that the filters can also affect the frame mapping, and you're trying to use the filter system in a half-enabled state where it remaps frames but doesn't process them, which is a bit hard to deal with. |
| Posted by: Loadus May 7 2010, 02:08 AM |
| @Phaeron: Can you add an option into the alias format -filter: Full Luma (Y: 0-255, C: 16-240) Thanks for this filter btw ^^ |
| Posted by: phaeron May 7 2010, 03:54 AM |
| Sorry, no. I would have to double the number of YCbCr formats to do that. |
| Posted by: Loadus May 7 2010, 04:11 AM | ||
Nou pänik, I'll use the Levels filter for the luma. |
| Posted by: pureocean May 7 2010, 06:13 AM | ||
Actually, I don't want to apply filters (brightness) to video. My interest for filter: clearly navigation. Of course, I know that this filter not to be progress in the Direct Stream Copy or Fast Recompress+Smart Rendering mode. Problem: If the filters were not removed, Fast Recompress+Smart Rendering doesn't work. Virtualdub, trying to apply the filter. I mean, Virtdualdub think Full Progress Mode is selected. Smart Rendering working in VirtualDub 1.8.8 (Even if any filter forgotten the filters menu). Minor bug #2: Doesn't work "warn if no audio is written". |
| Posted by: jpsdr May 7 2010, 10:29 AM | ||
I don't know what you want to do, but if it can be usefull, i've made a Saturation/Hue/Brightness/Contrast filter where you can check if you want to allow full range (0-255). Nevertheless, actualy it's not selective, it allow it on all channels, Y and C, or none. Nevertheless, it's an upgrade i can do to this filter (separate channels). Is is what you're looking for ? |
| Posted by: Loadus May 7 2010, 12:44 PM | ||||
Yes. I have some clips that have gone through multiple edit stations (mac > PC > mac etc) and the color ranges in some are fubar maximus. Having an option to scale either luma or chroma would be neat. Sadly, on some material the color information is clipped. : / |
| Posted by: jpsdr May 7 2010, 05:25 PM |
| You can find the last version of my filters here : http://rapidshare.com/files/384646916/Filtres_JPSDR.rar Hope it'll do what you're looking for. |
| Posted by: DanskDranker May 7 2010, 11:39 PM | ||
Hello. What can we use your filters to??? |
| Posted by: jpsdr May 9 2010, 07:12 AM |
| It was for Loadus who searched a filter where you can have 0-255 level for Y. |
| Posted by: DanskDranker May 10 2010, 04:24 AM |
| OK. |
| Posted by: jpsdr May 10 2010, 05:27 AM |
| Now, if in my filters there is things wich interest you, because there is more than a filter doing what Loadus was looking for, don't hesitate. After, they are more little things or basic tools usefull for me, than big filters doing extraordinary things. What could be interesting, it's that my deinterlace and IVTC filter work directly on YV12 format, without upscaling or anything, i consider that YV12 can be interlaced. |
| Posted by: v0lt May 14 2010, 12:25 PM |
| phaeron Is it possible to encode video in two passes using external encoders? |
| Posted by: Gromozeka May 14 2010, 02:05 PM |
| Phaeron You can add capture with external encoders? |
| Posted by: phaeron May 15 2010, 08:03 PM |
| @v0lt: If the encoder supports it, you should -- but you'll have to drive it manually, same as usual. @Gromozeka: Not for this pass. |
| Posted by: v0lt May 16 2010, 08:19 AM | ||
phaeron
no automatic What do you think about this variant? http://img404.imageshack.us/img404/4668/eeesmod.png |
| Posted by: phaeron May 16 2010, 06:12 PM |
| There's a lot more required than just UI work. |
| Posted by: Gromozeka May 16 2010, 07:28 PM |
| Phaeron, you can do work port from ffmpeg to other encoders? External encoders\ffmpeg -f rawvideo -s %(width)x%(height) -i - -f yuv4mpegpipe - | mencoder.exe (xvid_encraw.exe, mpeg2enc.exe and other) |
| Posted by: v0lt May 16 2010, 07:43 PM | ||
I understand. Still, I unloaded the pictures. For the future. Maybe http://img24.imageshack.us/img24/1623/eeepmod.png This is only an idea. But I have not brought it to the end. One of the variants turned out like this. http://img80.imageshack.us/img80/6865/eeesmod2.png |
| Posted by: Gromozeka May 16 2010, 08:29 PM |
| volt I think that its very difficult |
| Posted by: phaeron May 18 2010, 04:17 AM | ||
No. The pipe that you're using is a feature of the command processor (cmd.exe), and it's not as simple in this case because I need to maintain the pipes and monitor all of the processes involved. That's a lot more work and complexity than I want to take on at this time. Why are you trying to pipe multiple processes, btw? |
| Posted by: Gromozeka May 18 2010, 02:01 PM |
| Because Virtualdub without ffmpeg not pipe to mencoder.exe, xvid_encraw.exe Hcenc - best mpeg2, but not eat pipe P.S: Phaeron, why this not work? External encoders\xvid_encraw.exe -type 0 -csp yv12 -single -cq 3,0 -smoother 0 -vhqmode 4 -masking 2 -max_key_interval 250 -quality 6 -vhqmode 4 -qtype 0 -noclosed_gop -max_bframes 1 -bvhq -bquant_ratio 100 -bmin 4 -bmax 10 -avi "%(tempvideofile)" xviD_encraw here: http://rapidshare.com/files/388850573/xvid_encraw.rar.html Input options: -i string : input filename (stdin) -type integer: input data type (yuv=0, pgm=1, avi/avs=2) -w integer: frame width ([1.2048]) -h integer: frame height ([1.2048]) -csp string : colorspace of raw input file i420, yv12 (default) -frames integer: number of frames to encode Output options: -dump : save decoder output -save : save an Elementary Stream file per frame -o string : save an Elementary Stream for the complete sequence -avi string: save an AVI file for the complete sequence -mkv string: save a MKV file for the complete sequence |
| Posted by: phaeron May 19 2010, 04:00 AM |
| You're missing the parameters to set width/height/framerate/frame count, but even then I can't get this build to take a stdin stream properly. It just keeps encoding 0 frames. |
| Posted by: Gromozeka May 19 2010, 07:19 AM | ||||||
This parameters unnecessary this parameters work fine from comand line:
but why |
| Posted by: Loadus May 22 2010, 01:28 AM | ||||
When you pipe raw video, the encoder needs the framesize and fps parameters. |
| Posted by: v0lt May 24 2010, 06:02 PM |
| phaeron What do you think about the support yuv4mpegpipe? Here are some of the format http://wiki.multimedia.cx/index.php?title=YUV4MPEG2. Choosing a input format for Video can do for the tab as well as Audio. |
| Posted by: phaeron May 25 2010, 05:47 AM |
| Good idea, but a little bit weird. |
| Posted by: Gromozeka May 25 2010, 06:53 AM | ||
Phaeron
not? its very good idea, because yuv4mpegpipe support mencoder, mpeg2enc, xvid_encraw and other comand line encoders! but yuv support only ffmpeg and x264 |
| Posted by: v0lt May 25 2010, 04:21 PM |
| Phaeron sample of source code - http://git.ffmpeg.org/?p=ffmpeg;a=blob;f=libavformat/yuv4mpeg.c;hb=HEAD |
| Posted by: UGC May 26 2010, 03:59 AM |
| not sure if this is a joke or not after reading the forum post about "Foo", but I downloaded VirtualDub-1.9.X-test19-AMD64, and for capture, I have about 8 selections for video labeled "Foo#1-8", and about 50 labeled the same way for the audio capture?- which makes it unusable for me because I don't know which one to select on the audio. I only have 1 capture card, and about 8 audio inputs to pick from. What gives? |
| Posted by: Gromozeka May 26 2010, 12:07 PM |
| I add to vdub xvid_encraw (other version) and creat divx preset (speed compress with analog xvidvfw + 15%) External encoders\xvid_encraw.exe -i stdin -single -cq 3,0 -max_bframes 1 -bvhq -quality 6 -vhqmode 4 -qtype 0 -noclosed_gop -lumimasking -smoother 100 -bquant_ratio 100 -bquant_offset 100 -max_key_interval 300 -imin 2 -imax 2 -pmin 3 -pmax 4 -bmin 4 -bmax 10 -threads 2 -w %(width) -h %(height) -framerate %(fps) -o "%(tempvideofile)" avi External encoders\lame.exe -m j -q 0 -v -h --vbr-new -V 6 -b 8 -B 192 - "%(tempaudiofile)" mp3 External encoders\ffmpeg.exe -i "%(tempvideofile)" -vtag DX50 -vcodec copy -i "%(tempaudiofile)" -acodec copy "%(outputfile)_result.avi" external encoders there: http://rapidshare.com/files/391722547/External_encoders.exe.html Phaeron, you can add to virtualdub view command line with statistics encoding? http://www.radikal.ru |
| Posted by: v0lt May 26 2010, 05:48 PM | ||||
it works:
but it does not work :
Log: Mux: Cannot open file "mux_AVI.script": Mux: The system cannot find the path specified. |
| Posted by: stephanV May 26 2010, 09:31 PM | ||
does it work if you use
|
| Posted by: v0lt May 27 2010, 02:53 AM | ||||||
stephanV
also not working phaeron Please make a variable "vdpath". Åxample:
You can also add a variable "encpath". Maybe someone need. Åxample:
A working folder let it be equal to the output folder. Logs will be convenient to write. machine translation |
| Posted by: stephanV May 27 2010, 07:03 AM |
| Strange, cause it works here. A single dot is the dos/unix replacement for working directory. Is your working directory actually the virtualdub path? |
| Posted by: v0lt May 27 2010, 01:25 PM |
| stephanV I checked the working directory = output directory. I thought and decided that this is normal, but I want the variables "vdpath" and "encpath". |
| Posted by: phaeron May 29 2010, 05:26 AM |
| Sorry, been a bit busy with work and stuff.... The current directory is not guaranteed, folks. It getting set to the output directory is a side effect of the Windows common file dialog. %(vdpath) makes sense, but I'm not sure what %(encpath) would be. Did you mean something like %(outputdir)? BTW, I found where "Foo" was coming from. Turns out it's from some test code I put into the 1.9.X branch and forgot to take out. It's been removed in test-20. |
| Posted by: v0lt May 29 2010, 06:49 AM | ||||||
I've already said this is normal. I initially did not like, but if you do %(vdpath), then all is well.
OK! Variable %(vdpath) is very much needed. It is necessary to configure encoders were not tied to a specific VirtualDub folder. %(åncpath) is sometimes possible to calculate.
Hmm. Path %(outputdir) so current. Maybe someone should be. |
| Posted by: stephanV Jun 2 2010, 09:02 AM | ||
I had a crash when using only an external video encoder, in the encoder set audio and muxer were '(none)'.
It also seems temporary files are not deleted. Is this intentional? |
| Posted by: v0lt Jun 2 2010, 03:42 PM | ||
stephanV
I wanted to write the same thing. Helps to disable the sound track (Audio->No Audio). But it's not the best solution. |
| Posted by: v0lt Jun 2 2010, 04:16 PM |
| phaeron Request: Please make an option for multiplexer "Delete temporary video and audio files". |
| Posted by: phaeron Jun 3 2010, 05:58 AM |
I've added four new macros in test-21:
All of these macros do not have a trailing backslash, so you'd use them like this: %(outputdir)\filename. I hate directory macros that end in backslashes (i.e. Visual Studio 2010). In the event that a path is used which does not have any directory on it, the macros give "." instead. If an encoding set does not have an audio encoder, the encoding now proceeds without the audio path, like any other video-only export. The temp video/audio files are now deleted on completion. |
| Posted by: Loadus Jun 3 2010, 06:57 AM | ||
Awesome. Gotta update my sets right away. Thanks for these! ^^ EDIT: The %(hostdir) is meant to be used in the command arguments, right? So I can't use it like this (x264.exe residing in VirtualDub's folder):  Would be cool to make the encoder profiles "portable" ... : ) |
| Posted by: jpsdr Jun 3 2010, 07:32 AM |
| Why use b-pyramid strict, when the encode (with keyint 999) is obviously not for blu-ray ? |
| Posted by: stephanV Jun 3 2010, 10:11 AM | ||
| Perhaps this is not the thread for x264 settings discussion... I have done some more experimenting with the external encoder feature now and must say it is coming out really nice. I have some questions to ask and reports to make though: 1. The crash is fixed. Yay! 2. To encode video-only a muxer still must be selected, otherwise the temp video file gets deleted and the result is a 0 byte file. I don't know if you can change this, but it would be appreciated. 3. Right now it is also not possible to encode audio only (VirtualDub gives an error for this). Not a high priority, but would be nice to have anyway. 4. %(samplingrate) is in Hz, while Lame expects kHz. Now, Lame also accepts WAV but I needed this for a test and there might be other encoders that need this as well. Perhaps the macro could be split in %(samplingrateHz) and %(samplingratekHz) or an operation like %(samplingrate/1000) could be made possible perhaps. 5. When using the Raw audio option, valid video and audio files are produced but never muxed and temporary files are not deleted either (tested with oggenc2 and lame). When using the raw options in the encoder but having VirtualDub feeding it a WAV header the files do get muxed but obviously you get the 'chirp' of the header in the audio. I'll post the commandlines here
6. First I thought I was crazy and point 5 didn't really happen anymore, but it seems when closing VirtualDub the Raw audio setting doesn't stick and VirtualDub changes it to WAV. 7. The Raw output is signed and little-endian, correct? Thanks for this feature! |
| Posted by: Loadus Jun 3 2010, 12:07 PM | ||
Those are experimental settings for the iPhone. (Not to be used, or read on this example) |
| Posted by: Jam One Jun 3 2010, 12:17 PM |
| A bug with Direct-X Pixel Shaders / effect files: After changing the preview&output panes aspect ratio the changed image is corrupt. If AR corrected to make the image wider -> garbage or empty space is added. If AR corrected to make the image narrower -> portion of image is cut off. Nature of FX pixel shader effect file: Color correction. Versions affected: all recent Virtualdub 1.9.x builds. Were the earlier versions affected: no, obviously not. I use the FX file for colorspace conversion on Wide-Gamut monitor, that means I use it always, so I would have known for sure if some previous version would have failed =)) |
| Posted by: v0lt Jun 3 2010, 01:18 PM | ||
Thank you Another question: What makes an option "Bypass compression" in the settings of the audio encoder? |
| Posted by: v0lt Jun 3 2010, 01:36 PM | ||
For a long time like this can (see picture). http://img192.imageshack.us/img192/3343/vdx264.png full encoder path = "c:\Program Files\VirtualDub-1.9.X\tools\x264\x264.exe" For your case in the field "Program" should only write "x264.exe". |
| Posted by: Loadus Jun 3 2010, 04:26 PM | ||
Ah. Should've figured that one. Heh. Thx muchos. ^^ |
| Posted by: phaeron Jun 4 2010, 08:10 AM |
| Alright, I think I resolved a lot of the last batch of issues in test-22. The raw audio format is actually whatever the pipeline is currently set to. With compressed input you are likely to get mono/stereo 16-bit signed little endian, but that isn't guaranteed -- you could get 8-bit unsigned if that's what is coming in or that's what the codec produces (unlikely). |
| Posted by: Jam One Jun 4 2010, 09:47 AM |
I'd like to express my thanks, and confirm everything works OK now! |
| Posted by: stephanV Jun 4 2010, 11:11 AM |
| Thanks for the update. The video and audio only feature is very useful for debugging commandlines as well. Point 5 in my previous post still remains, though. |
| Posted by: phaeron Jun 5 2010, 06:23 AM |
| Try test-23... I fixed a couple of bugs that were probably responsible for the raw audio problems. |
| Posted by: Gromozeka Jun 5 2010, 06:35 AM |
| phaeron when add yuv4mpeg? |
| Posted by: stephanV Jun 5 2010, 07:48 AM | ||
It works now. I don't want to come over abusive cause you have already done a lot of work on this and it's very much appreciated, but I had an idea to make the bitrate more easily configurable. If you make two macros called %(videobitrate) and %(audiobitrate) and allow these values to be configured via File > export > external encoder, it would be easier than fiddling in the encoder profiles each time. Let me know what you think. It's not a big deal if you don't want to do it. |
| Posted by: phaeron Jun 7 2010, 06:02 AM | ||||
Stop asking for the same thing over and over. First warning.
I don't want to hard code in specific options like that... I was thinking of something a bit more flexible, but hadn't worked out the details yet. |
| Posted by: Gromozeka Jun 7 2010, 07:12 AM | ||
Phaeron
 |
| Posted by: stephanV Jun 7 2010, 08:41 AM | ||||||
I'm not speaking for phaeron here, but while your enthusiasm and testing in this forum is appreciated you also have to know when to stop. phaeron has made it clear a few times that he's not very fond of implementing this particular feature. He will do it if he finds it is needed, but he might find it isn't or doesn't know yet when. Here is a quote from http://www.virtualdub.org/blog/pivot/entry.php?id=299.
Thanks for your understanding. |
| Posted by: Gromozeka Jun 7 2010, 09:41 AM |
| stephanV This your truth phaeron Sorry, Phaeron. |
| Posted by: UGC Jun 18 2010, 10:30 PM | ||
FYI: in VirtualDub-1.9.X-test23-AMD64, the "Foo" is gone, but replaced with a list a mile long starting from A-Z for the audio selection during capture. I have about 4 selections for each input. |
| Posted by: phaeron Jun 19 2010, 07:06 AM |
| Try test-24. |
| Posted by: mattyou Jun 20 2010, 10:23 PM |
| Hi Phaeron, Thank you so much for this test24 version, I am using virtualdub since a lot of years, that's a really great tool, but since the version 1.8 or 1.9, it was freezing randomly at 99% during Xvid 2nd pass encoding, and that was loosing a lot of time for me. I decided some days ago to test the version 1.9.9 but it was freezing randomly too during big job queues. Yesterday I visited the forum for the first time and I decided to test the beta version test24 and my job queue is stable since 24 hours ! So here I am to congratulate you Phaeron for your great job !!! Have a good day and long life to Virtualdub ! Matt. |
| Posted by: v0lt Jul 10 2010, 07:34 AM |
| phaeron What do you think about sorting (manual or automatic) in the "Configure External Encoders"? |
| Posted by: v0lt Jul 10 2010, 07:36 AM |
| Bug: I wrote in the field "Program" value "tools\lame\lame.exe". Then I exported the settings in that file to the same record. But when I imported, the value was changed to "D:\tools\lame\lame.exe" . |
| Posted by: phaeron Jul 11 2010, 09:56 PM |
| Added sorting in test-25. Er, program name without an absolute path is bad. That means it is resolved relative to the current directory, which is unpredictable (it's changed by the file dialog). What base path did you intend for this to be resolved against? The reason for the behavior on import/export is that any relative path in the profile is resolved against the location of the profile file itself. I did this so that you could ship a profile with an encoder and the path in the profile would be automatically resolved on import. |
| Posted by: v0lt Jul 12 2010, 03:09 AM | ||||
phaeron
Thanks
Yes, I would not want to VD corrected the correct relative paths. In this case, VD mistake. Absolute path - "c:\Program Files\!media\VirtualDub-1.9.X\tools\lame\lame.exe" Relative path - "tools\lame\lame.exe" After the export/import - "D:\tools\lame\lame.exe" |
| Posted by: dloneranger Jul 12 2010, 05:37 AM | ||||
| Bug Use video stream fcchandler option isn't saved correctly
should be
|
| Posted by: dloneranger Jul 13 2010, 05:20 AM | ||
| Crash report Open virtualdub select menu - video - full processing select menu - video - color depth - 4:4:4 planar YcbCr (yv24) open a video - any will do, but this one is 576,320 Click button - scene forward Crash - access violation [edit] also with 4:2:2 ycbcr (uyvy) 4:2:2 ycbcr (yuy2)
|
| Posted by: phaeron Jul 13 2010, 06:43 AM | ||
Pushed up fixes in test-26. The scene detector crash was in the stable branch as well, so that will also be fixed in 1.9.10.
Actually, that's something I never actually supported. It might happen to work, but it's by chance. If the current directory changes, it breaks. I can add support for program-relative paths, though. |
| Posted by: v0lt Jul 13 2010, 01:59 PM | ||||||
phaeron
This feature was very useful. Not remove it.
I changed the working path in the shortcut, but the encoders continue to work. 
Loadus already asked that. But I was dissuaded. http://forums.virtualdub.org/index.php?act=ST&f=15&t=17508&st=150#entry79591 |
| Posted by: dloneranger Jul 14 2010, 11:20 AM |
| Bug report test-26 New audio display only shows waveform of one channel |
| Posted by: phaeron Jul 15 2010, 04:31 AM |
| Fixed in test-27. |
| Posted by: dloneranger Jul 18 2010, 05:18 PM |
| Bug report --------------------- Problem Setting the video colour depth (menu - video - colour depth) This only affects the next file opened - ok, can live with that Saved jobs have the video depth set after the video is loaded This results in the wrong depth being used in saved jobs --------------------- Reason If you open a video and it's decoded badly (slanted etc) You can change the colour depth to one that works correctly and drag the video in again Now the video shows correctly Edit and queue the job The job will be processed incorrectly as the requested colour depth is ignored This can result in a bad (slanted etc) output file --------------------- Fix Moving VirtualDub.video.SetInputFormat to above VirtualDub.Open fixes the problem |
| Posted by: John I. Jul 19 2010, 05:27 PM |
| There are two points, and the first has intrigued me for quite some time, and I'm not sure if these are bugs or by design. (Using Virtualdub up to 1.9.10 (X) build 33815) The first, is the contrast filters in Virtualdub (whether internal or external.) When applying a contrast filter to a frame (increase), the bright end is increased, while keeping the dark end in place. On the other hand, applying contrast in TMPGEnc, Adobe Premier, Photoshop, Paintshop etc..., the bright end is increased and the dark end is decreased. (1) Original frame histogram: |______iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii_____| (2) Contrast in Virtualdub: |______iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii_| (3) Contrast in other Video and Image applications: |_iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii_| If one needs to achieve this in Virtualdub, two sliders will have to be used. The brightness decreased, and contrast increased. Now, also in reverse , when decreasing contrast, and all the way approaching the 0%, the image becomes darker until totally black. (1) Original frame histogram: |_iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii_| (2) Contrast in Virtualdub: |_iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii__________________| (3) Contrast in other Video and Image applications: |______iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii______| Again, both the two sliders will have to be applied to reach the desired effect. _______________ The second, is the curve editor display. If a blend is applied to any filter, and the curve editor display is enabled, going into filters for further adjustments to any filter, causes the curve editor display to alternate between normally showing the curve and no curve displayed with only the gray background of Virtualdub showing. This also happens without modifying any filter. (Try CTR+F then ESC.) |
| Posted by: Jam One Jul 19 2010, 06:25 PM |
| It's good to hear that. That means brightness and contrast work in the best way they could have. |
| Posted by: John I. Jul 19 2010, 07:24 PM |
| Does that mean that the least contrast should be black ? |
| Posted by: phaeron Jul 20 2010, 05:11 AM |
| The reason for the brightness/contrast filter working this way is historical -- it's just the way that I implemented it, not having seen how other programs work. As for the curve editor, I can't seem to reproduce this. Any specific filter count or order of operations needed to trigger it? |
| Posted by: Jam One Jul 20 2010, 05:50 AM |
| Regarding the VIDEO, "contrast" controls the transfer function, i.e. the White Level "brightness" controls the Black Level. That's the way it should be. "The least contrast" should ideally (but not necessarily, in real world) be "the level of brightness". |
| Posted by: John I. Jul 20 2010, 06:28 AM |
| phaeron, I am aware of what you mean, as I've been using virtualdub since V 1.3, and this is why I presented it as 'not sure if it is a bug or by design'. As I didn't want to impose my understanding of 'Contrast', I did a search on the net to double check my knowledge, and I found some intersting links such as the following: http://en.wikipedia.org/wiki/Contrast_%28vision%29 Is it possible to offer both sliders behaviors as choices in the 'Brightness & Contrast' Dialog ? ---- For the curve Editor: if the blended filter is not the first in order in the Filter list, the curve editor starts exhibiting this behavior. The simplest setup that triggers this is: - Open any AVI. - Add 'Brightness & Contrast' Filter only (No need to adjust settings.) The Curve display is stable. - Add 'NULL Transform' as 2nd filter (No need to adjust settings.) The Curve display is stable. - Move the 'NULL Transform' up to be first in order. Now, if you go in and out of the filters list, the curve editor keeps disappearing and reappearing. - Move the blended 'Brightness & Contrast' to first position, and the curve editor becomes stable again. |
| Posted by: Jam One Jul 20 2010, 11:08 AM | ||||
1)
Yes, it does. 2) You may wish to read more about Displays, particularly about displays adjustment and calibration. What you refer to is sometimes called "linear contrast", where the luminosity "rotates" around the middle-gray (middle power) level/point. This method is a tradition for Photo-editing. But Video is a different realm. One of the points in its difference is Video is destined for Displays solely. And displays normally sport the abovementioned behavior. 'Contrast' is just a familiar name given to the power-of-transfer-function control. 'Brightness' is just a familiar name given to the "zero level" of the transfer function. Note that the 'black level' is a term which requires some understanding of its relation to the certain medium. What is black on TV display is not supposed to be black on PC display (it is supposed to be dark-gray on PC). |
| Posted by: v0lt Jul 20 2010, 01:23 PM |
| To heap. Old cosmetic bug: http://img43.imageshack.us/img43/7246/vdpevframe.png I already wrote about this, but there was no answer. |
| Posted by: John I. Jul 20 2010, 08:41 PM | ||||||
| Jam One, I'm not opposed to your technical description and justification that the
particularly, when this method is meant to prevent the generation of non-existing artifacts in the output. But, even when set this way, the filter has side effects:
Perhaps I didn't clarify in the first place that I was aiming at the general users who could have a washed out video or capture at their hand and are only aware of the common use of a contrast control, hence, my proposal to
Mentioning the Virtualdub help leads me to another suggestion. Phaeron, in the help file, you recommend the use of 'Levels' over "Brightnes/Contrast. Is it possible to add a Histogram display of after the controls are applied in both filters ? This will ensure that users work within the safe limits, specially, when only having the preview window as a reference could be misleading in cases such as aging monitors, and badly or misconfigured displays. |
| Posted by: Jam One Jul 20 2010, 09:55 PM |
| John I., I'd like to assure you I, in turn, am not opposed to the point of yours! I was kind of explaining some ideas "alternative" to photographic customs. 'Levels' filter is capable of matching your exact need - adjusting that very sort of contrast you wish. |
| Posted by: phaeron Jul 21 2010, 05:56 AM |
| Fixes queued for the curve editor and menu item description bugs. |
| Posted by: Loadus Jul 22 2010, 10:25 PM | ||
Well, you shouldn't use Brightness/Contrast // Levels at all for correction work. At least not on a (linear or) gamma workspace (meaning the normal editing space VirtualDub and sRGB use). |
| Posted by: John I. Jul 22 2010, 11:48 PM |
| Loadus, If I shouldn't, then, you are pointing me to ... ? |
| Posted by: John I. Jul 24 2010, 10:03 PM |
| phaeron, There is another issue with curve editor (Cosmetic ? Practical ?) On a 1600 X 1200 display and higher, it is very very difficult to see the dark red hairline defining the current frame. Is there any possibility of doubling its width (maybe at high resolutions only), and / or making the color brighter ? I use the curve editor extensively on video captures of scientific experiments exposures and the current line at high resolution, is causing a lot of eye strain (can barely be seen.)  Now, for a long due 'Thank you Phaeron' for implementing the feature of 'auto saving the Virtualdub main window dimensions & position.' I asked for this when I was a previous member of the forum (July 2005.) |
| Posted by: phaeron Jul 25 2010, 03:59 AM |
| What do you mean? I use 1920x1200, and I can see it just fine. Okay, seriously.... That seems like a reasonable request. Do you have any of the scaling parameters set in Windows, like the high DPI or large font setting? I'm wondering whether I should key this off of one of those, or if it needs to be a program-specific setting. |
| Posted by: John I. Jul 25 2010, 06:55 AM |
| phaeron, I work in two modes 1600x1200 & 2048x1536. The display is set to 120 DPI , 144 DPI respectively. The Font Size is NORMAL in both cases. |
| Posted by: Jam One Jul 25 2010, 11:08 AM | ||
| My monitor is 1920x1200 @ 94 dpi. The latter value achieved with a ruler / scale calibration in "Desctop properties". Most of fonts are in "normal" size. Some are in between "normal" and "big". I see EVERYTHING perfectly fine & clear & in real sizes. No "thin dark lines". All lines are sharply distinguishable. Making lines "thick" will make them "s&#@", according to what I see. P.S.: My monitor gamma etc. is hardware-calibrated. P.P.S.: John I. -- do you REALLY believe the monitor's resolution can be 120/144 dpi??? Both of these altogether??? I bet you should set your resolution more carefully. This is about monitor's PHYSICAL resolution, NOT your own idea of beauty. To double-check the monitor's settings open the Word, set page layout to 100% size, take a ruler, measure the Word's rulers drawn above the page and to the left. I have perfect MATCH. Do you? _______________
No, It doesn't. There is a bunch of "Helps"/"Guides"/"Tutorials" regarding the desktop/monitor's settings in Windows. Some basic things should be obeyed prior to blaming VirtualDub and calling to spoil its interface. |
| Posted by: dloneranger Jul 25 2010, 03:27 PM | ||
He never asked to make it 'thick' I have the same problem with the audio display's dark-blue on black To solve that I just used a lighter shade of blue I can't see how making the line a bit more vivid would be harmful |
| Posted by: Jam One Jul 25 2010, 06:39 PM |
| ...Dark blue on black... Dark red lines... Where ?...  Seems like I've got some totally different software  No, I can't believe this! I believe you're ought to tune your monitors. |
| Posted by: dloneranger Jul 26 2010, 12:11 AM |
| I'm so glad your eyes are perfect and don't have any sort of colour blindness But to me this blue is nearly indistinguishable from the black (it's actually RGB(0, 32, 64) in the sourcecode) http://img189.imageshack.us/i/vdubdarkblue.png/ I'm also willing to consider that thin red lines may be hard to distinguish for other people |
| Posted by: John I. Jul 26 2010, 12:49 AM | ||
| Jam One, I wonder why is this negative approach ? In life, there are so many people who have different screens, different settings, different needs, and different vision requirements which could be different from yours. I ask, what harm could that do to you, specially with the way Phaeron is investigating it ?
You'll most likely retain how your display is setup. If I didn't already know how busy Phaeron is, I would have asked (if possible) to change the curve editor to have a light background and all the numbers, lines, and wave shapes to have dark colors (similar to this page or to a book.) Please be more considerate to other people's conditions and needs. I also have no objection sharing my display specs to provide more info to Phaeron and to you. http://www.keithmay.org/equipment/Sony_CPD-G520/Sony_CPD-G520_Spec_sheet.pdf dloneranger, As you kindly provided an image for the audio display, can you also provide one for the curve editor, just to put our vision conflicts at rest ? |
| Posted by: dloneranger Jul 26 2010, 01:42 AM |
| http://img806.imageshack.us/i/vdubcurve.png/ There you go |
| Posted by: John I. Jul 26 2010, 01:47 AM |
| dloneranger, Thank you. |
| Posted by: dloneranger Jul 26 2010, 02:08 AM |
| @John.I See if this is any better http://rapidshare.com/files/409080542/Virtualdub-JohnI.zip.html I've tweaked the marker lines a bit |
| Posted by: John I. Jul 26 2010, 02:37 AM |
| dloneranger, Yes, the yellow line although is still thin, but is better and easier to distinguish from the black background. |
| Posted by: dloneranger Jul 26 2010, 02:52 AM | ||
Made it a bit thicker http://rapidshare.com/files/409083872/VDub-JohnI.zip.html |
| Posted by: John I. Jul 26 2010, 03:15 AM |
| dloneranger, Very much better. It is about the size of the dots on the curve, which makes it very convenient for extensive curve editing. Thank you. I hope Phaeron implements this as a per user choice. I wonder, if the curve editor background and other colors can be adjusted or altered as well ? |
| Posted by: dloneranger Jul 26 2010, 03:21 AM |
| Shouldn't be too difficult - but this is the wrong thread for longer discussion Better start a new thread in "general", or you can email me at dloneranger67@gmail.com |
| Posted by: John I. Jul 26 2010, 03:51 AM |
| I think there is no need to start a new thread. I believe it is better to continue with the current development, considering that the request has already been placed and is being handled by Phaeron. On the other hand, I appreciate your offer very much, and specially your effort to provide a modified executable sample. Thank you dloneranger. |
| Posted by: phaeron Jul 27 2010, 05:59 AM |
| A full color configuration dialog is something I've avoided as of yet. Am I correct that the changes in question are: brighten the active cursor colors in both the audio and curve editors, and widen it on the curve editor? |
| Posted by: John I. Jul 27 2010, 06:11 AM | ||
Phaeron,
You are correct. But, when I mentioned 'a per user', I was talking about the curve editor cursor width, which could be dependent on screen resolution, or manual as a single setup in Preferences (Normal or double width cursor.) As far as the discussion went regarding this point, it was obvious that there are users who prefer to have the cursor display as it is now, like Jam One, and I believe that they are also correct, because this is how they are comfortable with the display. - As for the colors, I didn't mean a full color configuration dialog, I was suggesting a permanent change to a light background such as white or light gray and dark colors for the numbers, lines, points, and wave shapes which would be clearer and less eye straining 'health wise.' Please note that there are other benefits to the light background, for example if we capture an image of the curve editor, then invert the colors and produce a negative, we will be able to see the existing vertical lines at each frame position. |
| Posted by: jpsdr Sep 8 2010, 07:21 AM |
| What's the status of 1.9.X version compared to the fixes of the stable new 1.9.10 version ? |
| Posted by: dloneranger Sep 13 2010, 04:00 PM |
| Is the filter sdk's section "Creating time-varying filters" correct? There's a thread about filters not working correctly when edits have been used (cut/paste/delete etc) http://forums.virtualdub.org/index.php?act=ST&f=2&t=19167&st=0#entry81432 The sdk says "If the filter needs to track post-edit frame numbers instead, such as applying a fade at a predetermined time, then it should use output frame numbers instead." Then there's an example showing a bob doubler, and expected frame numbers However, in debugging, all the destination variables are the same as the source? (I'm not seeing the expected output frame numbers of times/framenumbers for edits or eg the bob doubler) |
| Posted by: phaeron Sep 13 2010, 10:50 PM | ||
Almost all of the fixes in 1.9.10 had been integrated across, but not the curve editor UI fix, and I don't remember which test releases had what, so I just uploaded test-29 with everything integrated. In general, you can check the change list to see what has gone over.
The filter SDK is old at this point; the plugin SDK supercedes it. The specific change involved here is that current versions of VirtualDub apply edits on the timeline after the filters, whereas previous versions mostly treated it as pre-filters. I say "mostly" because that's usually the way it worked, but there were icky cases where it didn't and the result was a bit of a mess that only got worse as I tried to add more features to the filter system. Filters can still see frame number changes in the frame information but that won't occur unless an upstream filter is doing so, like a interlacing filter. |
| Posted by: dloneranger Sep 13 2010, 10:57 PM |
| Ah, actually, I did mean the latest plugin sdk - my mistype (That's still in the help for the latest plugin sdk) So, there isn't a way for a filter to get the final finished frame number now, if there are any edits on the timeline? |
| Posted by: phaeron Sep 16 2010, 07:02 AM |
| No, and here's why: the mapping isn't 1:1 anymore. The simplest case is if you use cut-and-paste to duplicate a section. OK, that's a corner case that almost no one does. The more evil case is if you have a downstream filter that is sampling multiple source frames per output frame, such as a motion blur filter. Let's say you have scrubbed to frame 10. There are two filters in the chain, filter A and filter B. Filter B needs a window of five frames, so it requests frames 8-12 from the upstream filter A. If we denote each request by (output, final), then we get this: (8, 10) (9, 10) (10, 10) (11, 10) (12, 10) So far, so good. But what if frame 8 was requested instead? Then the requests look like this: (6, 8) (7, 8) (8, 8) (9, 8) (10, 8) Notice that in both cases we are requesting frame 10 from the upstream, but there are two different requests for it: (10, 10) and (10, 8). We have two choices as to how to solve this. The first solution is to consider (10, 10) and (10, 8) to be the same frame. This has the undesirable side effect that the filter sees a delta between the source and output frame numbers that depends upon the delay after the filter. The second solution is to consider the two to be different frames. Well, that has a rather huge downside of prohibiting any frame caching between any two of the downstream frames, so it means that filter B causes 5x the frame requests to filter A. Even if you're willing to take that performance hit in order to allow for generalized source frame windows, you run into the problem that many VirtualDub filters do internal frame caching and don't necessarily work properly unless the incoming frame sequence is single stepped forward. That makes it difficult or impossible to cleanly step backwards in order to recompute the frames with different output frame numbers. Basically, in order to move the filter system forward, I felt it was necessary to remove the capability for filters to see all the way forward in the filter chain, and make the data flow strictly forward. There were too many contradictions and problems otherwise. |
| Posted by: v0lt Sep 16 2010, 01:21 PM |
| The past year in the dialogue "About" in the line of copyright |
| Posted by: dloneranger Sep 16 2010, 03:23 PM | ||
Yeah, it's understandable how it works We had a play in the other thread with using filters+curves instead to get a logo to fade in over the first few seconds But that gets clobbered if you edited/pasted frames into the section 'you think' would be affected by the curve as virtualdub now does a jedi mind trick on you and slips the pasted frames in after the curves are applied (using the original source curve levels) |
| Posted by: dloneranger Oct 14 2010, 05:12 PM |
| Mousewheel doesn't alter position control when mouse is over the curve control ParameterCurveControl.cpp LRESULT CALLBACK VDParameterCurveControlW32::WndProc(UINT msg, WPARAM wParam, LPARAM lParam) This is eating the message case WM_MOUSEWHEEL: return 0; --------------------------------------- Also, mousewheel in filter preview window, when mouse is over image isn't passed to position control FilterPreview.cpp BOOL FilterPreview::DlgProc(UINT message, WPARAM wParam, LPARAM lParam) Is something like this correct? case WM_MOUSEWHEEL: if (mhwndPosition) return SendMessage(mhwndPosition, WM_MOUSEWHEEL, wParam, lParam); break; |
| Posted by: phaeron Oct 23 2010, 08:11 AM |
| Yup, those changes look about right; I'll throw them in. I need to double-check why the parameter curve control eats the mouse wheel messages, though -- might have been to resolve a message loop somewhere. |
| Posted by: jpsdr Oct 24 2010, 11:33 AM |
| Pb with 31 version : can't open avisynth scripts anymore... Go back to 30 version : Work fine. |
| Posted by: v0lt Oct 24 2010, 01:36 PM |
| @phaeron I have a request. You can do so by pasting the two files fps test was carried out only by 3 or 4 digits after the decimal point? The resulting fps taken from the first file. Feature can be optional. Åxample: http://img137.imageshack.us/img137/301/vdfpsproblem.png |
| Posted by: pureocean Oct 25 2010, 07:56 AM |
| Minor bug; Test-31 (33841) can't open WAV file as external audio (pcm, 48 khz, stereo, 16 bit). Error: ...is of an unknown or unsupported file type. Test-30 (33836) can open. |
| Posted by: phaeron Oct 30 2010, 11:07 PM |
| Typo screwed up the filename detection... try test-32. |
| Posted by: levicki Oct 31 2010, 02:24 PM |
| Not sure if this has been brought up (it is minor anyway): 1.9.10 build 33836: - Encoder Edit dialog tab order is screwed up -- Command Arguments edit box is at the end of tab order instead of in sync with its correct physical position on screen. Also, I have a suggestion. Some of us use bitrate for encoding and vary it depending on the resolution. Obviously, it wouldn't be very feasible to create that many different encoder presets. It would be nice if Configure External Encoders window would get two edit boxes -- one for video, and another one for audio bitrate which could then be passed to external encoders as %(vbitrate) and %(abitrate) respectively. Yes, I am aware that for some encoders it is possible to use constant quality setting and leave out bitrate completely. I just prefer being able to calculate bitrate precisely using my own formula, and to be able to estimate file size by knowing bitrate in advance so I can tweak it if need be. |
| Posted by: pureocean Oct 31 2010, 06:01 PM | ||
@phaeron: Thank you for fix. |
| Posted by: Loadus Nov 15 2010, 03:28 PM |
| @phaeron: Feature request maximus. This might've been asked before but I'm throwing it in there just for general annoyance. Layers. In the Filters dialog - the ability to process the image in different "threads", like layers in image editing.  Clicking the "Add layer" adds another filterchain that can be blended into the original footage using "Blend" dialog. This would enable fairly complex compositing effects on video. I'm currently using Emiliano Ferrari's Blend filter to do these operations, but it enables only one additional filter chain for blending. : / Any thoughts on this? |
| Posted by: v0lt Nov 15 2010, 05:18 PM |
| @Loadus in this topic requests are not considered |
| Posted by: Loadus Nov 15 2010, 06:10 PM | ||
Ah. Got to post it to the dev area then. : / |
| Posted by: dloneranger Dec 19 2010, 11:50 PM |
| Bug If the audio display is turned on with compressed audio Message displays 'audio display is disabled...' correctly, but the area that the display would appear in still accepts ctrl-dragging with the mouse to offset the audio |
| Posted by: -vdub- Apr 29 2011, 09:45 AM |
| ffchandlers matroska.vdplugin v2.8 (with prefs AVI option selected for fcchandler to search in codec streams) Virtualdub v1.10.1_test32 xpsp3 (x86 32bit) Feedback for test versions 7 to 32 (and to all other current versions as of post date) (didn't post elsewhere so not to spam forum) Previously with test version7 i loadeda mkv file (H264+AC3) i was given a chance to save the index file that i assume fcchandler made when parsing the mkv when first loaded. Since i have deleted this file by mistake and upon loading never asked since asked or have ability to save it. Reason for this since large mkv files and maybe other containers take an age to load. Idea would be to have a menu option to save this index would mean loading in an instance. Read on another forum External Encoders ui to have this ability. To import graphs from graphstudio and graphedit. It would then be very simple task to make and use them available with virtualdub to encode with. Is it possible to expand further on this to make this available also for decoders. Abulity to build graphs and insert them has to be another easy way to work with virtualdub. Appreciate if is a problem such as the filters won't play correctly. I expect internal ones wouldbe ok just those external ones. Maybe have it to start with so those are disabled, and if need filter use properties on componments in the graph. And add ffdshow there if need more. |
| Posted by: ale5000 Apr 29 2011, 09:11 PM | ||
There isn't any 1.10.1_test32, just 1.10.1_test7. To have the option to save the index, you must check "Ask for extended options after this dialog" when you open a video. |
| Posted by: -vdub- Apr 30 2011, 09:20 AM | ||
Your correct and yesterday had many projects on the go. I did try all current and some older versions. Then after posting i did add this, to encapsulate all recent versions.
Didn't try extended options since mkv with v1.10.0 loaded ok and well did the same for the rest. Just tried now and do see options there. Maybe better these been on preferences also, such as to always save idx file or not optional. * Also for the suggestions to use graphs from graph studio and graphedit for importing. Also if had abilty to export them this would just be the ultimate icing on the cake for virtualdub. Andmiles ahead maybe of any other video editing tool, they all should have this ability. Also able to connect to graphstudio and graphedit would make for all codec filter tasks to be so simple.* If i have posted this to incrorrect location on the forum. Could you please move these suggestion to more appropiate location, thanks |
| Posted by: ale5000 Apr 30 2011, 07:59 PM | ||||
Just open extended options, enable index creation, then press "Save as default". Extended options cannot be on preferences because are different for every input plugin.
|
| Posted by: -vdub- Apr 30 2011, 08:30 PM | ||||
Thanks no problem now it's set to make an idx automaticaly. Done so from the extended setting option on its popup after the file loaded. |
| Posted by: -vdub- Apr 30 2011, 09:15 PM | ||||
So it can be done from direct show plugin that is good. Phaeron are you reading this post ? What do you think of this idea ? Do you think it is possible to do for directshow filters and codecs etc that is available with graphstudio and graphedit ? There are loads of filters and codecs etc we could use with virtualdub, atm we just don't have access to them at all. Having the ability to import and export graphs for use in virtualdub would be a perfect sollution. |
| Posted by: phaeron May 1 2011, 01:30 AM |
| I've fixed the external encoder dialog tab order bugs in my dev tree. I have something in the works for the video filters but I'm not ready to reveal it yet. DirectShow custom graph support is possible, but it can't just be any graph -- the plugin needs a specific graph with sample grabbers to pull the video and audio out at the ends. In particular, it CAN'T use multiplexer or renderer filters that would be used for previewing or transcoding the graph in GraphEdit. I haven't done work lately on the DS plugin, but I plan to circle back to it at some point (still need to figure out why MediaDet can't handle MPEG-2 video). |
| Posted by: -vdub- May 1 2011, 03:12 AM | ||
Phaeron i wrote a few suggestions a few times here but kept coming back to the mpeg-2 problem. Together with the virtualdub ds filter multiplexer, video render and file writer that are essential right now. This is the best way i can see this, which means you dropping mpeg-2 fixing for now. Since that maybe the stumbling block for not continuing with ds filter having to fix that first. If leave the ds filter mpeg-2 problem to one side for now. Since everyone uses fcchandler or ffdshow mpeg-2 with virtualdub. I know myself fcchandler has no problems with ps while yes .ts is a problem with any plugin or without. Can see a need to fix this for all the hd streams that are .ts. If you know hd is ok with those one problem less for now. Sure you will find problem in the future, but not worth worrying about it and scaring you away from working with other parts of the code. Or even pull out mpeg-2 part and make it a standalone filter, could be a sollution. Now to the next problem of using graphs and ds filter needing to control the multiplexer, video renderer and file writer. Build a simple or advanced graph editor into the virtualdub ds filter. Then this graph editor would work in exactly the same way as any other graph editing tool would. For choosing and controlling the 'inserted filters' with all property pages etc allowable for use etc. This would be the easiest and maybe the only way this could be done. Then while a graph is build virtualdub can use the filters it needs to use. And still the graph will work. Sure that means no import or export of filters from other graph tools. Then who cares since have one for use in virtualdub. Would be nice if also the virtualdub graph editor was like others where we can drag around the boxes to connect and same way or better to disconnect (even disconnect a connection using the right mouse button !). HAve option for removing added favourite filters. Can be done for others only through registry, thought graph studio would have made this better even. Also when not connectable a quick time out no waiting as long as with graph edit. Sure you also could see many possibilties for virtualdub if was coded into virtualdub. Such as the user will have full control over all of their system installed filters, codecs and more. Just not so for the multiplexer, video render or file writer. Which on the face of it is nothing to worry about. Even if the multiplexer had property page made available for options it has. What else could a virtualdub user need. Ok maybe someway to interface all this better with avisync filters for direct use, or maybe use avisync filters as can be done now with virtualdub filters without an avs_cript needed. Oh could this be one of those filter ideas you have yet to revealed !! |