Register MPEG2Source from DGMPGDec 2.0.00 to AVS and VS as Additional Source Filters

[JJKylee]

DGDecode.dll(MPEG2Source) in DGMPGDec 2.0.00 (released on Dec 23, 2020) now supports 64 bit and is dual.

Please register MPEG2Source in Apps Management so that users can make use of them in place of D2Vsource(AVS) and d2vsource(VS) natively in StaxRip.

How

1. Put the 64 bit DGDecode.dll file in %startup_dir%Apps\Plugins\Dual\DGDecode.
2. Create items for MPEG2Source in Apps Management AviSynth and VapourSynth sections.
3. Add MPEG2Source items in AVS Profiles and VS Profiles respectively.

AVS:
MPEG2Source = MPEG2Source("%source_file%")

VS:
MPEG2Source = clip = core.dgdecode.MPEG2Source(r"%source_file%")
(Plz, refer to this)

Of course LoadPlugin should be automatically put when MPEG2Source filter is activated.

4. Add MPEG2Source to DGIndex and D2V Witch preprocessors (in Settings) as an additional source filter.
5. (Optional) Set MPEG2Source as the default source filter for d2v.

[JJKylee]

Meanwhile, DGMPGDec is updated to 2.0.01:

*Fixed decode crash with 64-bit DLL in Vapoursynth mode when stream has RFF flags. The UV pitch was getting set wrong.

It's here or here(VideoHelp).

[stax76]

I've worked on it using 2.0.01 and there is a problem with the staxrip preview using vapoursynth, it shows blackness, encoding with x265 works and mpv.net too.

[stax76]

mpv and mpv.net cannot open the _view.vpy script either.

[stax76]

It's caused by the resize line:

clip = clip.resize.Bicubic(format = vs.COMPATBGR32)

[JJKylee]

I found some critical bugs in DGMPGDec 2.0.01 while testing it with the 2.1.7.0 release version.

The decoder does not start in VS MPEG2Source, and there's a DGIndex/DGDecode mismatch in AVS.

[VS]

[AVS]

Both AVS and VS are portable versions as in the factory settings.

---

I think we should wait until they are fixed.
I'm going to report the bugs on the DG Tools forum for this.

Sorry about my hastiness. 😓

[stax76]

I'm not getting this error, only problem is dgdecode.MPEG2Source does not define Primaries and Transfer clip info, that's what was causing the problem, it should be possible to workaround it.

[JJKylee]

Pretty weird.
I'm really curious what caused these errors in my case.
Maybe a different source video/d2v file?
Then what about the version mismatch b/w DGIndex and DGDecode?
Food for thought. ☹️

[JJKylee]

I figured out the cause of my errors.

It was due to the text encoding (UTF8 with BOM) of the d2v file generated by the DGIndex preprocessor in StaxRip when the system codepage is 65001(UTF-8).

DGIndex.exe (the GUI app) and DGDecode.dll do not recognize this as a valid d2v file although it was generated by DGIndex.exe itself via CLI in StaxRip.

But on the other hand, the d2v file generated by DGIndex in GUI is saved in the correct text encoding (UTF-8 without BOM).

Only after I correct the text encoding to UTF-8 without BOM can I see no errors - both in StaxRip (AVS and VS) and DGIndex.exe. And preview works OK with my sample video.

But like you said, there may be other bugs. So we'd better wait until they are fixed.

[JJKylee]

And D2VSource(AVS) and d2vsource(VS) also fail to read the BOM-prefixed d2v file.
No wonder considering they are mod versions of MPEG2Source.

I tried using the old DGIndex.exe (ver. 1.5.8) instead, but I get the same problem: CLI generated d2v text encoding has BOM.

All in all, I guess the main factor is the system codepage UTF-8.
I'm kind'a surprised that no one has ever reported about this bug over the last 10 years. 😮

[videoh]

I cannot get a BOM using either GUI or CLI. Maybe staxrip edits the D2V file and saves it with a BOM? Please follow up at DG forum.

http://rationalqm.us/board/viewtopic.php?f=7&t=987

Maybe wait until the problem is understood before claiming a "critical bug" in some specific software. We don't know where that BOM is coming from. There is no code in DGIndex to write one.

[JJKylee]

You're right about it, @videoh.
It was a bug with StaxRip.

I posted an issue(#435) about this bug.

I admit that I made a hasty conclusion about it.
It didn't occur to me at first that an external exe call from StaxRip could make this kind of text encoding problem. 😢

[stax76]

@JJKylee

It took a while but the blackness/color issue is solved. I can now investigate the text encoding issue.

[JJKylee]

For your reference, DGIndexNV preprocessors created from an empty Command Line Demuxer template (as mentioned in the Wiki document) do not have this BOM issue with the output dgi file. Hope it helps when you look into it.

[stax76]

I think there is code in staxrip that changes the d2v file depending on if it's something like film or not, maybe that's what added the BOM.

[stax76]

Yes, it was staxrip writing the file with BOM. The code was changed just days ago as part of a major text encoding rewrite.