Getting the clips from a DVD or Blu-ray?

[l33tmeatwad]

15 bucks ain't going to kill anybody.
DGAVCDec was bad, however issues with DGDecNV are likely due to misuse or misunderstanding something, as the software behaved correctly with all the sources I've put it through, including interlaced AVC Transport Streams, interlaced AVC BDs, MPEG-2 BDs and VC-1 BDs. As these are all set-in-stone standards for the end user, a hardware decoder tailored specifically for decoding these sources is the most reliable way to deal with them, hence why DGDecNV is the best option when possible, even with the price tag attached to it.
Clearly it's not always necessary, particularly with progressive sources now that there is L-Smash Works, but that doesn't mean it doesn't have its usage, nor that it's glitchy, as it's quite the opposite.

Well, it's also relies on a hardware decoder, so it could be driver issues or hardware compatibility as well, not just "user error"...when you start relying on hardware decoders, the variety of hardware and difference in execution of similar tasks can cause issues. The software decoders tend to have less "variety" in decoding errors and for the most part will perform the same across the board. Just keep in mind that just because hardware decoders are made to handle certain footage does NOT mean that it will do a better job compared to regularly updated software decoders. Also, the reason I mentioned the cost is that fact that the original poster specifies little interested in paying for software. As you said, DGDecNV is the best option...if you are using an Nvidia card that supports the features it needs and proves to be compatible with the current version of the software...hardly a "catch all" recommendation when you know nothing of the user's computer.

[mirkosp]

It's not just any hardware. In order to work it just needs an Nvidia GPU with VP2 or better. As long as it has that, the decoded results will be identical regardless of the specific hardware.
Moreover, you are overlooking an important fact: decoding of AVC is specifically standardized (MPEG-2 decoding can differ since the standard doesn't state exactly how the decoded result should look), so regardless of software or hardware decoder, as long as a given Profile@Level is supported, the decoded result has to be bit identical in order for the implementation to be standard compliant. Any further difference is not due to decoding but further processing; for instance, dithering in case of higher bitdepth content which needs to be brought to 8bit, or debanding or whatever other processing a filter AFTER the decode would be doing.
However the former case (dithering) is not a case here since BDs are 8bit to begin with, and since no further processing is done by the decoder, as far as the latter case goes, it's all up to the user to employ whichever avisynth filters they would see fit, if any.
So yes, hardware decoders and software decoders will in fact do an IDENTICAL job at decoding, otherwise something is very wrong with their implementation of the standard. The only difference would be in the speed they'd be running at, which of course depends on the hardware the user has at disposal.

[l33tmeatwad]

It's not just any hardware. In order to work it just needs an Nvidia GPU with VP2 or better. As long as it has that, the decoded results will be identical regardless of the specific hardware.

What that is true, it does not mean it's free from errors, and if there happens to be an error in the stream (in case of TS streams) some hardware decoders do not handle that that well. Obviously on Blu-ray you shouldn't have that kind of issue.

Moreover, you are overlooking an important fact: decoding of AVC is specifically standardized (MPEG-2 decoding can differ since the standard doesn't state exactly how the decoded result should look), so regardless of software or hardware decoder, as long as a given Profile@Level is supported, the decoded result has to be bit identical in order for the implementation to be standard compliant. Any further difference is not due to decoding but further processing; for instance, dithering in case of higher bitdepth content which needs to be brought to 8bit, or debanding or whatever other processing a filter AFTER the decode would be doing.

Where did I ignore this? All I stated was there is room for error based on the software's compatibility with the hardware device based on how the system uses it with the drivers.

So yes, hardware decoders and software decoders will in fact do an IDENTICAL job at decoding, otherwise something is very wrong with their implementation of the standard. The only difference would be in the speed they'd be running at, which of course depends on the hardware the user has at disposal.

I don't really see the point in encouraging a highly limited way of handling footage for the small percentage of time in which it proves to be more useful (interlaced AVC footage), considering a very small amount of content will tend to fall into that category to begin with (especially if you don't bother to mention the fact that it is limited to Nvidia hardware as well). Additionally I'm not going to tell someone to go out and buy a video card so they can use a method to decode the footage just because it can handle the 1% of footage they will encounter that is interlaced.

[mirkosp]

And so since interlaced content is rare, automatically FFMS2 is the best option to suggest even when L-Smash Works is out there, free for all, and better? I still don't get that.
One thing is me defending the best option out there, another is suggesting the third one when there is a free and better close second, now.

[l33tmeatwad]

And so since interlaced content is rare, automatically FFMS2 is the best option to suggest even when L-Smash Works is out there, free for all, and better? I still don't get that.
One thing is me defending the best option out there, another is suggesting the third one when there is a free and better close second, now.

I never said it was BETTER, but it definitely is more convenient to use (especially if you don't have an Nvidia graphics card).

[mirkosp]

L-Smash Works does not require any specific GPU.

[l33tmeatwad]

...even when L-Smash Works is out there, free for all, and better?

Details please, there does not seem to be adequate documentation that I can find on this.

[mirkosp]

I already linked it before:

Also, I will have to say that FFMS2 is a bad idea for direct BD AVC (and not just that), and remuxing isn't a solution to fix the problem, since it's not related to the container, hence why I suggest L-Smash Works now; here's a more indepth explanation (keep in mind that ffms2 relies directly on libav). For progressive content, L-Smash Works is a safe option, for interlaced content, only DGDecNV is truly safe.

For instance, H.264 allows IDR-picture without SPS/PPS.
For such IDR-pictures in TS, we can't treat as keyframe (random access point) but libavfomrat returns them as keyframe.
So, the result will be broken when the current SPS/PPS in extradata doesn't match (and libavcodec shall not update AVCodecContext.extradata).
This case is frequently present in BD m2ts.
LWLibavVideoSource can handle correctly this case.

L-Smash Works has its own internal workarounds to make this all work correctly, whereas ffms2 depends entirely on libav, which doesn't handle this properly. As this is a common occurrance in AVC BDs (yes, progressive ones as well), it makes L-Smash Works the preferrable suggestion now that it exists, if a free solution is desired.

[l33tmeatwad]

I already linked it before:

Also, I will have to say that FFMS2 is a bad idea for direct BD AVC (and not just that), and remuxing isn't a solution to fix the problem, since it's not related to the container, hence why I suggest L-Smash Works now; here's a more indepth explanation (keep in mind that ffms2 relies directly on libav). For progressive content, L-Smash Works is a safe option, for interlaced content, only DGDecNV is truly safe.

For instance, H.264 allows IDR-picture without SPS/PPS.
For such IDR-pictures in TS, we can't treat as keyframe (random access point) but libavfomrat returns them as keyframe.
So, the result will be broken when the current SPS/PPS in extradata doesn't match (and libavcodec shall not update AVCodecContext.extradata).
This case is frequently present in BD m2ts.
LWLibavVideoSource can handle correctly this case.

L-Smash Works has its own internal workarounds to make this all work correctly, whereas ffms2 depends entirely on libav, which doesn't handle this properly. As this is a common occurrance in AVC BDs (yes, progressive ones as well), it makes L-Smash Works the preferrable suggestion now that it exists, if a free solution is desired.

I seemed to have overlooked the link in your first post. Well this is rather new and I have not heard of it before, thank you for the links and information. Also, this would have been nice information to quote the first time around rather than a side note and a link the first post, helps it to not get overlooked as easily !

Might I recommend a sticky with this kind of information? Things like this sometimes slide in under the radar and it would be useful to have a listing of alternative methods of handling this type of footage since the org guide lacks this kind of information at the current moment. I personally haven't researched anything new in the past 6 months, thus easily missed certain things that came out in that time frame. I personally am glad there is a more accurate alternative that isn't reliant on a graphics card chipset since my current machine has an ATI card, thus making DGDecNV quite useless.

Additionally, could we get the stickies cleaned up a bit? Half of them are so outdated it's not even funny, this forum looks like a graveyard of information...I understand the org guide is being updated, but having some basic software information and advice on new methods of handling certain types of media would be extremely useful and probably handle a good chunk of the questions that come through the forum.