When using DSS2 to load direct BD footage, you could have decode issues which will affect quality (if it happens, you'll see some "blocks" out of place), and frame accuracy and audio sync isn't always ensured (which means you might have audio desync and frames out of order... in a 5-4-3-2-1 countdown you could get 5-2-3-4-1).
Notice the could and might. These won't always happen, so you might be safe. But here's some more thorough explanations in case you're interested.
For starters, the uncertainty it all brings isn't nice, since video decoding with H.264 is deterministic by standard: a frame will always look the same, no matter the decoder or seek order ─ any difference will be either due to a decode bug or other filtering/processing after the decode. So for AVS needs, you'll just want the pure decoded frame with no extra filtering.
DSS2 however relies on your direct show setup, which means any further processing your Direct Show filter which has the priority in the chain for the given file would do during playback will be done to the file.
Another thing to keep in mind is that if you upgrade/change filters in your DS setup (which you should actually be doing every few months, when updates and improvements are available), you might have a different result with the same exact avs, depending on the upgrades/changes done.
But most importantly, Direct Show is meant purely for playback, and frame accuracy when seeking isn't required, since the decode is linear after you seek to a given frame. During playback you'll click on a certain point of the timeline (like 3 minutes 30 seconds), and just play from there, not caring about hitting a precise frame, so Direct Show is optimized without thinking about delivering an exact frame when one is requested out of order (this is played further in most players, where by default you can't even seek to specific frames, but just to keyframes, in order to have faster seeking).
Avisynth doesn't quite work that way, so if you have further filtering (especially if temporal), you are in for surprises (out of order frames and/or decode bugs).
But even without further filtering there are chances you'll still get out of order frames depending on how you handle the avs after that, which is why even with just dss2 on its own things are risky.
If still intend to use DSS2 after these warnings, then here's all the advice I can give you.
The avs you use DSS2 within should not have any other thing done, not even a resize or trim: nothing else. Only the DSS2 line loading the footage (potentially the loadplugin line before that, but you should just keep DSS2 in autoload).
In virtualdub, just do a straight up uncompressed or intra-only lossless/lossy compression. Uncompressed is the safest, intra-only could be risky, especially with lossy filters, but should still be ok if you force the codec to use a single thread/core in the encode. The key here is to make sure that the whole thing gets requested and encoded linearly from frame 0 to the end, so any multithreading optimization will play against you, as will any encoding technique which relies on temporal information (as would be for any B or P frame).
This way you should most likely have a source decoded correctly which you can reliably filter and edit on. Feel free to import that file in another avs and do further filtering, or just import it in your NLE for editing needs. But don't ever trim or resize or anything directly in the avs, and avoid using the avs without first saving a lossless, because otherwise you are likely to incur in the issues I mentioned in the beginning of the post.