Question regarding frame accuracy and editing amv's.

[boagz1]

Hey guys. I was wondering what exactly is meant when people on this site and others talk about frame accuracy with certain plugins and functions. For example, it is said that things like L-smash-works plugin for avisynth and DGDecNV are better than DSS2 for blu ray footage due to their better frame accuracy. If I load a blu ray file into avspmod and use DSS2 and encode it with virtualdub (save it as an avi with utvideo codec or something) what will be the difference when editing compared to using DGDecNV?

[l33tmeatwad]

DSS2 would be "frame accurate" in terms of seeking, but it won't decode the footage as accurately as the other solutions. I don't really know how to explain it well aside from simply saying it comes down to the technical details of how Blu-ray video is encoded which is different than your typical H.264 encode you find online and how directshow filters decode this footage vs how they should actually be decoded.

[boagz1]

Okay well thanks for the attempt meatwad. Well let me ask you this, does the decoding from DSS2 result in worse picture quality than others? Or when editing your footage and syncing your music and video does the rendered out video maybe have timing issues or something due to the use of DSS2? Those are the biggest problems I would worry about.

[mirkosp]

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.

[boagz1]

Wow thank you. Very good explaination and I very much appreciate you taking the time to explain this to me. Much obliged.