|
|
| olnima |
| Posted: Feb 1 2008, 08:02 AM |
 |
|
Advanced Member
Group: Members
Posts: 204
Member No.: 17204
Joined: 12-November 05
|
Just tried it out, "subset.length" does exactly what I want, thank You very much for your help.
Olnima
P.S.: Just a question: I found
"VirtualDub scripting language reference, v0.7".
Is this the latest documentation?
I ask, because "subset.length" and "video.length" aren't described there.
|
|
| trodas |
 Posted: Feb 2 2008, 06:58 PM |
|
|
Advanced Member
Group: Members
Posts: 88
Member No.: 22291
Joined: 22-October 07
|
I would like to say one point about the scaling. First at all, take the picture of Dalailama and scale it down using nearest neighbour way. You get this:
Conclusion - you can trick the scale routines, if you want to. But the original image was ready and made for the trick of "disappearing" - and it was also of very poor quality, when come to depth of it. It was very, very gray to start with.
Also the scale down to 129 pix wide from 258 - exactly halving it to make the trick.
My observation over the years is - that with the scale picture usualy lost some brightness and contrast. So my scale-down Photoshop macro containing +4 to brightness and +6 to contrast - and of course sharpen +40 - if the scale is drastic, +15 if it is small.
I think my photos (sorry, only booring computer stuff, porn later  )
http://capsmod.net/forum/viewthread.php?ti...&extra=page%3D2
http://capsmod.net/forum/viewthread.php?ti...&extra=page%3D1
http://capsmod.net/forum/viewthread.php?ti...&extra=page%3D2
http://trodas.wz.cz/index.php?act=ST&f=16&t=337&s=
http://capsmod.net/forum/viewthread.php?ti...&extra=page%3D1
http://capsmod.net/forum/viewthread.php?ti...&extra=page%3D1
http://capsmod.net/forum/viewthread.php?ti...&extra=page%3D1
http://capsmod.net/forum/viewthread.php?ti...&extra=page%3D1
http://capsmod.net/forum/viewthread.php?ti...&extra=page%3D1
http://capsmod.net/forum/viewthread.php?ti...&extra=page%3D1
http://capsmod.net/forum/viewthread.php?ti...&extra=page%3D1
...somewhat confirm that this is the correct way to go.
phaeron - as far as the v1.8.0-test2 go, I did not find anything different (yet) - no new error - good - except one problem with the DirectShow input filter. When movie is loaded using your filter, then the preview does not work. There is only the white-bloack gradient when seeking and when stop, then there is the frame on witch one stop previously in the VDub, check there:
(no, at the moment - considering the seeking - are the credits there, not the start of the unplug scene, right?)
But I will continue to use the testing version, just to be able submit some (hope usefull) bugreports  The bug is related ONLY to the DirectShow input plugin. It never happen with normaly opened file.
PS. I forget to mention that the preview worked well with the DirectShow input plugin with VDub 1.7.7 build 28312, IIRC.
--------------------
"It is dangerous to be right in matters on which the established authorities are wrong." - Voltaire
...just keep folding, just keep folding... :) my config - my caps |
|
| phaeron |
| Posted: Feb 2 2008, 09:32 PM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
I'll take a look at what's going on with the DirectShow input plugin.
As for the scaling issue, that's expected behavior. Nearest neighbor mode picks the nearest available pixel, and it turns out that when you use a scaling factor of 2:1, the sampling point is exactly in the middle of each 2x2 block of pixels. Which pixel is picked depends on the convention used by the scaler, and depending on whether the scaler rounds up or down in each axis you can get any of the four pixels. No single convention is any better than the other -- if you were to make such an argument, I could simply flip the picture to negate it. The only behavior that is clearly worse is not being consistent between each 2x2 block, which you'll sometimes see in 3D accelerators, but that's not happening here.
|
|
| mariushudea |
| Posted: Feb 2 2008, 11:01 PM |
|
|
Advanced Member
Group: Members
Posts: 54
Member No.: 22873
Joined: 19-January 08
|
Since trodas posted a picture with the resize filter, i remembered I wanted to ask if this is by design or a bug...
The resize filter no longer adjusts the preview window when the sizes are changed. IN VIrtualdub 1.6.15, when I changed a value and pressed Tab moving the focus to another control, the preview window would show the changes.
I kind of got used to instant preview and now I have to click on Hide preview and click again the Preview button to see the new preview.
|
|
| phaeron |
| Posted: Feb 3 2008, 01:07 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
You just have to hit apply (Alt+A), not hide and show the preview. This was a change I made a while back.
The reason I made this change is that it was too easy to accidentally add extra digits onto one of the numbers and then hit Tab or otherwise click on another control, at which point the program would either crash or bring the entire system to its knees processing a 480320x240 bitmap.
|
|
| phaeron |
| Posted: Feb 4 2008, 06:38 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
@trodas: The filter preview bug is a bug in the DirectShow input driver. I'll post a fixed version in the thread for that plugin.
|
|
| rfmmars |
| Posted: Feb 4 2008, 06:32 PM |
|
|
Advanced Member
Group: Members
Posts: 324
Member No.: 5438
Joined: 29-July 03
|
I don't use this filter very much however using ACDsee plugin gives a black screen using 1.8.1 Test, will try 1.8.2 test.
EDIT: Same problem with 1.8.2 Test
Richard
photorecall.net |
|
| mariushudea |
| Posted: Feb 5 2008, 02:10 AM |
|
|
Advanced Member
Group: Members
Posts: 54
Member No.: 22873
Joined: 19-January 08
|
Virtualdub 1.8.0-test2
Tools > Create test video ... > 3:2 Pulldown (TFF)
Video > Framerate > Inverse telecine (...) > Reconstruct from fields - adaptive
Video > Compression >x264 Encoder > Multipass - First Pass
File > Save as AVI
Progress window shows 800 frames being processed
Show output video doesn't work, show compressed output doesn't work.
After encoding completed:
Video > Compression > x264 Encoder > Multipass - Nth Pass
File > Save as AVI
Virtualdub stops working with the following error:
Messages say:
2nd pass has more frames than 1st pass 1000 vs 798.
Note the 798 value, the status window said 800 before, the second time the window doesn't appear.
After both windows are closed Virtualdub is usable.
If the Inverse telecine option is not selected, both 1st pass and 2nd pass work and the output is shown (not sure about the decompressed output, probably not because x264 can't decode).
small visual bugs
I'm not sure if Virtualdub uses an input buffer, in the Performance tab I see only AVI output buffering.
I use Huffuv a lot and I was wondering, would implementing an input buffer (i'm thinking something like 64-128MB - I have 2GB of memory installed) help compression speed?
When I set the output buffering to the maximum value, it speeds up conversions to Huffyuv with probably about 10-15%
My usual work with Huffyuv involves converting several small clips to huffyuv and applying logo on them, then joining together the pieces and compressing to xvid.
|
|
| phaeron |
| Posted: Feb 5 2008, 07:46 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Alright, new build:
http://www.virtualdub.org/beta/VirtualDub-...1.8.0-test6.zip
http://www.virtualdub.org/beta/VirtualDub-...test6-AMD64.zip
http://www.virtualdub.org/beta/VirtualDub-....0-test6-src.7z
Don't worry about the missing releases; they're being used in another thread.
@rfmmars:
| QUOTE | | I don't use this filter very much however using ACDsee plugin gives a black screen using 1.8.1 Test, will try 1.8.2 test. |
Err... ACDsee plugin?
@mariushudea:
| QUOTE | 2nd pass has more frames than 1st pass 1000 vs 798.
Note the 798 value, the status window said 800 before, the second time the window doesn't appear.
After both windows are closed Virtualdub is usable. |
The goofy UI behavior is from the x264 codec opening its own error window and then returning a generic error to VirtualDub. For some reason codec authors never feel the need to actually label their dialogs as coming from the codec. 
I found and fixed the bug that caused the wrong number of frames to be reported to the codec, so try this build. I used r736 of x264 to test.
Visual bug is fixed.
| QUOTE |
I'm not sure if Virtualdub uses an input buffer, in the Performance tab I see only AVI output buffering.
I use Huffuv a lot and I was wondering, would implementing an input buffer (i'm thinking something like 64-128MB - I have 2GB of memory installed) help compression speed?
When I set the output buffering to the maximum value, it speeds up conversions to Huffyuv with probably about 10-15%
|
It does have an input buffer, but it's very small (~2MB) and doesn't act the same way as the write buffer. I'm not sure how much an input buffer would help.
The only real way in which read/write buffers help is in reducing the amount of seeking that the hard drive does. Seeks are death to hard drive performance -- a hard drive that does more than 20MB/sec at sequential I/O can drop to under 2MB/sec throughput under heavy seeking. For this reason, it is very advantageous to keep seeks low by feeding it large requests at a time. In practice, a chunk size between 1-4MB is enough to reduce seeks low enough to be a non-issue; the remainder of the buffer is only necessary to keep the CPU from waiting on the hard drive to process a chunk, and so somewhere between 4-16MB is about max needed.
An input buffer would probably help somewhat, but there are a few additional factors. One, the write buffer itself helps a lot because there's generally only two streams active (read + write) and by keeping its own I/O blocked, it frees up big blocks of time for the reader to get lots of back-to-back requests in. The main cause of seeking during any sort of copy-like operation is the read and write streams fighting over the same hard drive, which is the main reason that the file copy in Windows Explorer has historically sucked for big files. Two, there are generally two read operations active on the input file -- video and audio -- and that makes it tougher to buffer the input. If done improperly, the buffering can lower performance by reading too much extra data that must be thrown away. This can be disastrous over a network. Three, buffering tends to involve an additional memory copy, which can eat CPU.
There are a couple few interesting scenarios that enhanced input buffering could address. It would lower the system impact whenever something else needs the disk -- VirtualDub can be quite a disk hog -- and it can also lower the system swap-o-rama effect by reducing the strain on the disk cache.
It's interesting to think about, but I hadn't gotten around to actually ever trying to improve it.
|
|
| rfmmars |
| Posted: Feb 5 2008, 06:04 PM |
|
|
Advanced Member
Group: Members
Posts: 324
Member No.: 5438
Joined: 29-July 03
|
Besides ACDsee giving a black screen, the same problem exits with "Autolevel" which is a hack of ACDsee. with "Autolevels" thing may look ok when closing the filter box it, but will either go black or lock the timeline, uncheck it and the timeline unlocks.
Also simular problems with "DNR mmx"
I had a Xvid file which when imported gave a MP3 stream error, when I burned the DVD, it had a linera audio offset. Importing the same file into VD 1.67 the message was that the clip had a audio offset and gave me the amount and solution, please make a change back to this error message for the next release.
The above tested with VD 1.8.6 Test
Thx
Richard |
|
| Gromozeka |
| Posted: Feb 5 2008, 07:16 PM |
|
|
Unregistered
|
| QUOTE | | I found and fixed the bug that caused the wrong number of frames to be reported to the codec, so try this build. I used r736 of x264 to test. |
Phaeron, you used r736 of x264 to test from this:
http://www12.atwiki.jp/lunatilia/pages/70.html
This build have much big bug's
or this:
http://sourceforge.net/projects/x264vfw/
This build have not bug's and very good functionality
Igor |
|
| phaeron |
| Posted: Feb 6 2008, 05:01 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
@Gromozeka:
Huh? What makes you say that? I used the one off the SourceForge site. In any case, those bugs don't matter if the issue in question is resolved on both builds.
@rfmmars:
| QUOTE | | Besides ACDsee giving a black screen, the same problem exits with "Autolevel" which is a hack of ACDsee. |
Ah, I know what you're talking about now. If you could, please be explicit about the exact name of the filter you're using -- a download link would be even better. The reason I was confused is that ACDsee is a well-known image viewing application that does not, as far as I know, function as a VirtualDub plugin.
The issues with the filters you've raised is likely a compatibility problem with the new filter system that supports YCbCr filtering. I think I know how to fix this, though. It's definitely a release blocker.
| QUOTE | | I had a Xvid file which when imported gave a MP3 stream error, when I burned the DVD, it had a linera audio offset. Importing the same file into VD 1.67 the message was that the clip had a audio offset and gave me the amount and solution, please make a change back to this error message for the next release. |
Which error message are you receiving, exactly? If it's this one:
| CODE | [!] AVI: Stream 1 (audio) has a non-zero start position of 65536 samples
(+1486 ms). VirtualDub does not currently support a non-zero start time
and the stream will be interpreted as starting from zero. |
...that, as far as I know, is unchanged in 1.8.0. If you're not getting this message when 1.7.x did, please use the Tools > Create Sparse AVI... function to produce an analysis file of the AVI and post it somewhere or email it to me so I can figure out what's going on.
| QUOTE | | The above tested with VD 1.8.6 Test |
<nitpick>1.8.0 test-6, not 1.8.6 test.</nitpick> |
|
| Gromozeka |
| Posted: Feb 6 2008, 07:01 AM |
|
|
Unregistered
|
phaeron
| QUOTE | | Huh? What makes you say that? I used the one off the SourceForge site. In any case, those bugs don't matter if the issue in question is resolved on both builds. |
For information Bugnaster's just in case |
|
| phaeron |
| Posted: Feb 6 2008, 09:25 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
http://www.virtualdub.org/beta/VirtualDub-...1.8.0-test7.zip
http://www.virtualdub.org/beta/VirtualDub-...test7-AMD64.zip
http://www.virtualdub.org/beta/VirtualDub-....0-test7-src.7z
Changes in this version:
- Fixed compatibility problems with filters. (Technical details: XRGB8888 is now always forced to be bottom-up on entry to a filter unless that filter supports the new format arbitration.)
- The filter dialog now shows [C] next to a filter when implicit conversion is happening. The three cases that can cause this: the filter doesn't support the direct input format, the filter doesn't support format arbitration and the incoming RGB32 bitmap is top-down in memory, and precise crop is active on a YUV input with a rect that doesn't fall nicely on block boundaries.
- More AVI reindexing fixes.
|
|
| kkdd |
 Posted: Feb 6 2008, 01:35 PM |
|
|
Member
Group: Members
Posts: 28
Member No.: 22993
Joined: 5-February 08
|
phaeron
you are the man
TNX very very much
you are doing a good job with VirtualDub-1.8.0-test7
TNX |
|
