|
|
| IanB |
| Posted: Nov 2 2009, 07:56 AM |
 |
|
Avisynth Team Member
Group: Members
Posts: 121
Member No.: 22295
Joined: 23-October 07
|
| QUOTE (NeXT @ Nov 2 2009, 07:17 AM) | | Hm, I heard many times, that 'DSS2 is frame accurate, while DirectShowSource is generally not'.. |
DSS2 is written by Haali as part of his splitter and renderer package. It uses special hooks into his renderer for retrieving the frame data.
It always runs in ConvertFPS=True mode. It absolutely relies on the start time stamp of delivered frames. Any seek forward upto 100 frames is done the hard way by reading forwards 1 frame at a time. It maintains a hard cache of the 10 most recent frames retrieved. When a more extensive seek is required the position is set 10.001 milliseconds early, i.e. a small preroll, it then waits for and delivers the frame that claims to start at the appropriate time.
Any seek within -10 and +100 frames of the current position is guaranteed 100% accurate.
All other seeks depend on the reliability of the Start time stamp of the delivered frames. When using Haali's own splitter these are 100% guaranteed. For other splitters you take your chances.
Regular DirectShowSource currently relies of the standard Avisynth cache for covering small backwards seeks and will read forwards upto 30 frames. It currently does not use any preroll on seeks, so may miss the target if the next delivered frame is later than expected. In ConvertFPS=True mode this is corrected on the subsequent GetFrame call, for frame mode the error is continued until the next seek.
In summary DSS2 maximises your chances for frame exact seeking and a future version of regular DirectShowSource may incorporate some of DSS2's tweaks. But fully accurate random positioning with DirectShow will always be dependant on the components used in the current graph.
|
|
| NeXT |
| Posted: Nov 2 2009, 10:16 AM |
|
|
Advanced Member
Group: Members
Posts: 41
Member No.: 24145
Joined: 31-August 08
|
IanB, thanks for excellent explanation!
Am I correct, that in case of linear seek, DirectShowSource and DSS2 (and DSInput Driver) should all be frame-accurate? |
|
| IanB |
| Posted: Nov 2 2009, 08:29 PM |
|
|
Avisynth Team Member
Group: Members
Posts: 121
Member No.: 22295
Joined: 23-October 07
|
| QUOTE (NeXT @ Nov 2 2009, 09:16 PM) | | Am I correct, that in case of linear seek, DirectShowSource and DSS2 (and DSInput Driver) should all be frame-accurate? |
Yes, if you only ever ask for frames in a contiguous linear order there can never be a problem.
Problems can only occur when stepping back further than the cache can service (Dss2 10 to lots*, Dss 0 to lots*) or stepping forwards a big jump (Dss2 100, Dss 30)
*lots - depends on other cache usage and total size of cache (SetMemoryMax) |
|
| NeXT |
| Posted: Nov 2 2009, 08:35 PM |
|
|
Advanced Member
Group: Members
Posts: 41
Member No.: 24145
Joined: 31-August 08
|
Hmm, in that case I think it's okay for me to switch back to DirectShowSource (DSInput Driver is not a good solution for me because I need to downsize source video, and don't want to do unnecessary colorspace conversions). For my current task I only need contiguous linear order and ability to resize. |
|
| phaeron |
| Posted: Nov 3 2009, 04:27 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
The DirectShow input driver should let you select the color space directly -- it hooks up to the input setting in Video > Color Depth.
|
|
| NeXT |
| Posted: Nov 3 2009, 09:16 AM |
|
|
Advanced Member
Group: Members
Posts: 41
Member No.: 24145
Joined: 31-August 08
|
Yes, but I also need to resize video before encoding, so if I resize via VD, I have to go RGB32.
On the other hand, BicubicResize() in AviSynth can do it in YV12, so I can perform [Source] -> Bicubic Resize -> [Lagarith encode] in YV12 only. |
|
| phaeron |
| Posted: Nov 4 2009, 03:59 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
VirtualDub has been able to resize in YV12 for some time now.
|
|
| NeXT |
| Posted: Nov 4 2009, 03:54 PM |
|
|
Advanced Member
Group: Members
Posts: 41
Member No.: 24145
Joined: 31-August 08
|
Oops, guess I missed it. 
Now there are no showstoppers for me in using DSInput Driver im my pipeline.
Tested it, and it works okay. Thanks! |
|
| v0lt |
 Posted: May 10 2010, 05:39 AM |
|
|
Advanced Member
Group: Members
Posts: 119
Member No.: 26125
Joined: 5-September 09
|
phaeron
Please make all filename extensions by default.
DirectShow input driver -> DirectShow input driver (*.*) |
|
| phaeron |
| Posted: May 18 2010, 05:21 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
v0.6 is up -- fixes a funny bug that was causing file opens to take a loooooong time on some systems.
| QUOTE |
Please make all filename extensions by default.
|
I'd rather not do this, because it will cause VirtualDub's open dialog to show all files even though you still can't open them without specifically choosing the DirectShow input driver. That's the problem I really need to come up with a solution for.
|
|
| dloneranger |
| Posted: May 18 2010, 02:17 PM |
|
|
Moderator
Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07
|
Does 0.6 include the forced stream detection that's in a previous beta version?
[edit]
Ah, yes I see in the source that it does
--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3 |
|
| v0lt |
| Posted: May 28 2010, 01:46 PM |
|
|
Advanced Member
Group: Members
Posts: 119
Member No.: 26125
Joined: 5-September 09
|
| QUOTE (phaeron @ May 18 2010, 05:21 AM) | | I'd rather not do this, because it will cause VirtualDub's open dialog to show all files even though you still can't open them without specifically choosing the DirectShow input driver. That's the problem I really need to come up with a solution for. |
The easiest way when you add extensions to the type of "All types (.avi, .mpg, ...)" to ignore the mask "*.*"
And IMHO the last item "All types (*.*)" in the ComboBox "Files of type" better to rename to "All files (*.*)". |
|
| Jam One |
| Posted: May 28 2010, 07:06 PM |
|
|
Advanced Member
Group: Members
Posts: 580
Member No.: 25518
Joined: 8-May 09
|
| QUOTE (v0lt @ May 28 2010, 04:46 PM) | | "All files (*.*)". |
You mean you want to see text files altogether with Excel's spreadsheets, HTMLs and what not ???
|
|
| v0lt |
| Posted: May 29 2010, 06:15 AM |
|
|
Advanced Member
Group: Members
Posts: 119
Member No.: 26125
Joined: 5-September 09
|
| QUOTE (Jam One @ May 28 2010, 07:06 PM) | | You mean you want to see text files altogether with Excel's spreadsheets, HTMLs and what not ??? |
You do not understand. See picture.
 |
|
| Jam One |
| Posted: May 29 2010, 08:08 PM |
|
|
Advanced Member
Group: Members
Posts: 580
Member No.: 25518
Joined: 8-May 09
|
I do mean exactly what I mean!
"All files" in Windows means ALL FILES.
"All types" is rather logical - it stands for all files VirtualDub CAN ever OPEN. |
|
