Long (40 min +) AVI files created by Matrox RT.X2 in Premiere Pro CS5

[subwoofer]

Will upload one file to Google Drive later today and leave it accessible for a few days. Will post the link here.

--
Joachim

[subwoofer]

Leaving it up for 48 hours or so: https://drive.google.com/file/d/1v8kzQKqUKSMDXrcPh-97ugDLYsXAWM2Q/view?usp=sharing

~6.8GiB

[poisondeathray]

DGIndexNV was able to index the whole file , 52929 frames, and seek to the end 00:35:17.120. Frames look good and you can scrub through the clip, very snappy because it's GPU accelerated.

But this requires avisynth or vapoursynth, a compatible Nvidia card, and $15 for the license. (Unfortunately the free version DGIndex didn't work - it works on MPEG2 video, but there was some issue with AVI container). avisynth/vapoursynth frameserve uncompressed video, so you'd typically encode to an intermediate format to import into your NLE (e.g dnxhd, prores etc...) . I know, it's stupid - matrox was supposed to be the intermediate format . It's also possible to frameserve a virtual file with avfs (a "fake" avi) , but there is more overhead (slower), and it bogs down if you have many clips. The "physical" file route is more responsive

[subwoofer]

That is promising. I will have to find out if the video card in the laptop will play nice with DGIndexNV.

Now we have established that the datastream is present, intact and recoverable, we can optimize the procedure. I will have to be chaperoned through the first conversion, methinks, not familiar with all the tools.

[subwoofer]

Looks like I'm in luck. The NVS5400M in the laptop has a VP4 engine, so it should play with DGIndexNV. Will have a fiddle later today. Any free alternatives to DGIndexNV?

[poisondeathray]

I tried a bunch of tools and nothing else worked properly

DGIndex mentioned above is the free "ancestor" of DGIndexNV. DGIndex only supports MPEG2 and CPU decoding only (DGDecodeNV supports other formats incl. AVC, VC1, HEVC if your card supports it) . But DGIndex had problems with AVI container parsing. If you were able to somehow remux into a different container (MPEG-PS, MPEG-TS or elementary m2v) , DGIndex might work. I tried a bunch of remuxing tools , but none worked properly

LSmash and FFMS2 (other source filters for avisynth / vapoursynth) both index the file too - but they both had problems



Another benefit of DGSource, is it decodes as proper YUV . Matrox decoder decodes as RGB. The actual MPEG2 stored format is YUV. When you use matrox, the YUV=>RGB conversion is done in a progressive fashion, so on interlaced sources, you get interlaced chroma errors (colored notching or combing). Even if you could get it to decode the entire video run time, I wouldn't use the matrox software decoder. I don't know if the old matrox hardware boxes suffer from that

[subwoofer]

Would it be rude to ask you for the actual steps or script you used to do it? I got distracted yesterday, so I just started installing the tools an hour ago. A few mishaps with python before vapour synth would install, but I have almost everything now. 15 bucks for a tool is no biggie...

Edit: License ordered, but I understand it may take a few days.

[Truthler]

I have never used HDV, because I considered it backward technology in a comparison with memory card and HDD based camcorders.

[subwoofer]

Couldn't agree more, but dealing with archive footage here from a different source.

[poisondeathray]

Would it be rude to ask you for the actual steps or script you used to do it? I got distracted yesterday, so I just started installing the tools an hour ago. A few mishaps with python before vapour synth would install, but I have almost everything now. 15 bucks for a tool is no biggie...

Edit: License ordered, but I understand it may take a few days.

Are you are Mac OS ? There are some intricacies and differences with the Mac version of vapoursynth that I'm not familiar with

There is a dedicated Mac vapoursynth thread here
https://forum.doom9.org/showthread.php?t=175522

The basic steps (for any platform) are to index the file first. DGIndexNV.exe is the standalone indexer (GUI) . If you open a file (drop and drag, or file=>open), then index it (file=>save project, or F4) , it will create the .dgi file which is the index or project file. It's essentially a text file with additional information on the frames, frametypes, GOP makeup (you can check with a text editor). It can take a minute or two to index longer files, that's normal. There are ways to batch index files if you have many files (eg. command line for loops)

A script (in vapoursynth or avisynth) is also just a text file. It references the video. You create a plain text file and write the script. You can perform additional filtering or processing if you want. It's well worth learning about avisynth or vapoursynth when you have time, very versatile and powerful video/audio processing tool.

Change the .txt extension to .vpy. That script (.vpy for vapoursynth, .avs for avisynth) can be opened natively in vdub2 or any programs that support it (e.g. ffmpeg can be compiled with vapoursynth and avisynth support --enable-avisynth --enable-vapoursynth, and the majority of publicly distributed ffmpeg binaries usually have avisynth support enabled by default). The .vpy or .avs "looks" like a video in that other program. If you drop a .vpy or .avs in vdub2, it will open right up as a video. There are dedicated script editors with previews and additional functions (avspmod for avisynth, vapoursynth editor for vapoursynth), but nothing like a full featured NLE

For vapoursynth, DGSource can be loaded natively, or as an avisynth plugin. Apparently, newer versions of avisynth can run natively on linux, Mac OS too now . I only use the Windows version

eg. vapoursynth script

import vapoursynth as vs
core = vs.get_core()
core.std.LoadPlugin(r'PATH\DGDecodeNV.dll')
clip = core.dgdecodenv.DGSource(r'PATH\BN2019_akt2.dgi')
clip.set_output()

eg. avisynth script

LoadPlugin("PATH\DGDecodeNV.dll")
DGSource("PATH\BN2019_akt2.dgi")

If you wanted to encode interlaced in ffmpeg you have to use the correct switches and possibly interpret the file in PP or whatever editor depending on the intermediate format you choose (PP interprets the interlaced flag correctly and automatically only for certain formats) . Or if you wanted to use high quality deinterlacer (QTGMC), you can make a 50p file

There are GUI's that support vapoursynth and avisynth and DGIndexNV, such as staxrip, megui, hybrid . Hybrid used to be completely cross platform, I think selur stopped supporting mac os for hybrid

[subwoofer]

Thanks for breaking it down for me! Running the transcoding on a Windows box, to avoid any further complications. I will add deinterlacing to the vapoursynth script, and possibly a pixel aspect ratio conversion before recoding to some suitable intermediate codec.

At least I have the files playing in DGIndexNV now, so almost there!

--
Joachim

[subwoofer]

Getting close, installed latest vapoursynth and StaxRip and made a .vpy file

import vapoursynth as vs
core = vs.get_core()
core.std.LoadPlugin(r'c:\Program Files\DGIndexNV\DGDecodeNV.dll')
clip = core.dgdecodenv.DGSource(r'BN2018_akt1.dgi')
clip.set_output()

but I get this error

Script Error

Python exception: DGSource: Cannot open index file!

Traceback (most recent call last):
  File "src\cython\vapoursynth.pyx", line 2244, in vapoursynth.vpy_evaluateScript
  File "src\cython\vapoursynth.pyx", line 2245, in vapoursynth.vpy_evaluateScript
  File "D:\Barnas2018\footage\BN2018_akt1_temp\BN2018_akt1_source.vpy", line 2, in <module>
    SourceFileLoader('clip', r"D:\Barnas2018\footage\BN2018_akt1.vpy").load_module()
  File "<frozen importlib._bootstrap_external>", line 462, in _check_name_wrapper
  File "<frozen importlib._bootstrap_external>", line 962, in load_module
  File "<frozen importlib._bootstrap_external>", line 787, in load_module
  File "<frozen importlib._bootstrap>", line 265, in _load_module_shim
  File "<frozen importlib._bootstrap>", line 702, in _load
  File "<frozen importlib._bootstrap>", line 671, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 783, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "D:\Barnas2018\footage\BN2018_akt1.vpy", line 4, in <module>
    clip = core.dgdecodenv.DGSource(r'BN2018_akt1.dgi')
  File "src\cython\vapoursynth.pyx", line 2069, in vapoursynth.Function.__call__
vapoursynth.Error: DGSource: Cannot open index file!

Did I take a wrong turn somewhere? I am guessing the "r" before a path means relative, but removing it in LoadPlugin() changes nothing

[subwoofer]

But it works in vdub2, so I might use that instead, despite YUV -> RGB colour space conversion.

[poisondeathray]

Did you get the paths correct for the vapoursynth script ? vapoursynth is picky for full paths and syntax including upper case / lowercase

But it works in vdub2, so I might use that instead, despite YUV -> RGB colour space conversion.

There is no YUV => RGB color space conversion in vdub2 , if you just load an avs or vpy script (the preview is a RGB converted preview, but the underlying video is the native pixel format)

[subwoofer]

So I stand corrected, when I started fiddling with options it sure looked like vdub2 was working in YUV...

All is well then, just waiting for a transcode (slow computer) to see how it all worked out. Any way to transplant QTGMC into vdub2? I know it will be even slower, but that computer is not my daily driver, it usually just functions as an iTunes layout box.

[poisondeathray]

So I stand corrected, when I started fiddling with options it sure looked like vdub2 was working in YUV...

If you just load a script and do nothing, it will be the native pixel format

But what video compression you select might change that pixel format (there might be some conversions in between)

In vdub classic, if you had video=>full processing mode, that always mean RGB conversion. You had to choose video=>fast recompress to bypass that. Not so in vdub2.

In vdub2 you can check with a "null transform" filter and "show image formats" to see what pixel formats are actually used and between each filter if any vdub2 filters are being used . Also most compression choices usually have another "pixel format" button with some options

All is well then, just waiting for a transcode (slow computer) to see how it all worked out. Any way to transplant QTGMC into vdub2? I know it will be even slower, but that computer is not my daily driver, it usually just functions as an iTunes layout box.

QTGMC cannot be transplanted anywhere, because of so many .dll dependencies and prerequisites (eg. it would be nice if ffmpeg could get it). It can only run in avisynth and vapoursynth

Vapoursynth has native multithreading, but for avisynth+ you have to enable multithreading with prefetch(x) and guess the proper amount. Usually the number of physical cores is a good starting point for most types of scripts. You can use avsmeter to measure and tweak script speeds

[aedipuss]

wouldn't it be easier to just ask for the original tapes and re-capture them over? i realize it's just a kid's concert but at least you'd be starting over with 1st gen material.

[subwoofer]

wouldn't it be easier to just ask for the original tapes and re-capture them over? i realize it's just a kid's concert but at least you'd be starting over with 1st gen material.

Maybe, if the tapes still exist. I would need to borrow some means of playing the tapes and dig for a computer with the right interfaces too. So, maybe.

But this journey has really been much less about the content of the files than it has been about the altruism in finding a method to play the files. There now is a searchable solution online for whenever someone really has to get to some archieved material ingested by an RT.X2 card and no tapes exist. Many may have been led to believe that the files they archived were actually following a standard and would be easily accessible at a later stage, not knowing playback was tightly bound to hardware. And to make matters even worse, the files don't even play with Matrox' own VfW codecs!

I still need to figure out some stuff with vapoursynth, but for now I think we're in good shape.

--
Joachim

[DB83]

I have not downloaded the file (would take too long for me). Neither do I know the intrecies (sp?) of ffmpeg. So what follows is another wild one.


Given that the file(s) are proprietory would it not be possible to re-stream them leaving the video as is, changing the audio to what was on the tape in the first place, and then packing in to a .mov container as what a 1:1 transfer would have created ?


But atleast you now have the basis for playable files. Probably too late for those writing on that other forum some years ago. The 'pleasures' of legacy hardware

[subwoofer]

With some (a lot???) of AviSynth- and ffmpeg-foo I guess that is probably doable, my tactic is to deinterlace and recode with H264 with a higher bitrate than the original, the generational loss - although present - should be minimal. Particularly since progressive is easier on the codec* than interlaced.

*) EBU had an interesting demo on IBC many many moons ago when H264 was still an infant, showing the efficiency of the encoder. High entropy reference material, encoded as 720p50, 1080i25 and 1080p50. As bitrate was reduced, 1080i started showing huge artifacts at several Mbps before 1080p. Encoders should have improved by then, but still.

--
Joachim

[subwoofer]

Aaaaand.... One last hurdle. DGIndexNV did not extract the audio. I´ll start digging into AviSynth+ to find out how to extract it, unless someone has any suggestions. It is there when I try to play the original AVI file, but DGIndexNV does not seem to notice that it´s there.

[poisondeathray]

Aaaaand.... One last hurdle. DGIndexNV did not extract the audio. I´ll start digging into AviSynth+ to find out how to extract it, unless someone has any suggestions. It is there when I try to play the original AVI file, but DGIndexNV does not seem to notice that it´s there.

You mentioned you had external recorded audio

It usually demuxes the audio, automatically. It didn't recognize it in this case. You can ask the author to have a look. I suspect he'd do it - if it was a common usage case (this is not a common usage case, but you never know, he might be bored)

Other tools only recognized ~10min worth of audio

[subwoofer]

I have, but flying the flag of altruism let's pretend I don't... With no clapper it is much easier to sync external sound when you have an audio reference.

Mediainfo also says 10:21 of audio, so let's assume that is why the other tools only extract ~10 minutes.

I tried adding WavSource("BN2018_akt1.avi") to the avs file, only gave clicks, at least in vdub2. Tried adding .ssrc(48000) but htat threw an error.

[poisondeathray]

Yes many tools will report a duration of ~10min . But some report the correct duration. eg. gspot reports correct duration 35+ min. A constructed directshow graph (graphstudio) also lists correct duration , and you can use this in avisynth by referencing a video and audio graph with DirectShowSource - but I already explored this route earlier - the video and audio are useless after ~10min . The A/V splitter is looking linearly, but the 2nd part of this is organized differently, hidden away . It doesn't matter if you swap splitters, decoders, etc.. because they look linearly

You need to parse hex offsets and look at low level data, that's what DGIndexNV does for the indexing step. The 2nd part is hidden from most tools, they don't know where to look. DGIndexNV is probably not looking for audio in this modified AVI structure , but it has the best chance of succeeding. It's worth asking DG, the worst that can happen is he says no.

[subwoofer]

I have already sent him an email, we´ll have to wait and see what comes out of it.

[aedipuss]

the file seems really weird. the file's metadata says it's 29.97i.

"xmp:MetadataDate="2019-01-28T22:56:19+01:00" xmp:ModifyDate="2019-01-28T22:55:55+01:00"
xmpDM:videoFrameRate="29.970030"
xmpDM:altTapeName="BN2019"
xmpDMhotDate="2019-01-28T21:20:44Z"
xmpDM:audioCompressor="Uncompressed"
xmpDM:videoPixelAspectRatio="17280/12960"
xmpDM:videoFieldOrder="Upper"
xmpDM:videoAlphaMode="none"
xmpDM:audioSampleRate="48Â 000"
xmpDM:audioSampleType="16Int"
xmpDM:audioChannelType="Stereo"
xmpDMtartTimeScale="30000"
xmpDMtartTimeSampleSize="1001"
xmpDM:tapeName="BN2019"
xmpDM:logComment="">
<xmpMM:History>
<rdf:Seq>
<rdf:li
stEvt:action="saved"
stEvt:instanceID="xmp.iid:4A807C014223E9118480A458 842CD018"
stEvt:when="2019-01-28T22:55:55+01:00"
stEvtoftwareAgent="Adobe Premiere Pro 4.0"
stEvt:changed="/metadata;/content"/>
<rdf:li
stEvt:action="saved"
stEvt:instanceID="xmp.iid:4B807C014223E9118480A458 842CD018"
stEvt:when="2019-01-28T22:56:19+01:00"
stEvtoftwareAgent="Adobe Premiere Pro 4.0"
stEvt:changed="/metadata"/>
</rdf:Seq>
</xmpMM:History>
<xmpDM:videoFrameSize
stDim:w="1440"
stDim:h="1080"
stDim:unit="pixel"/>"


the 10:21 long part i could re-encode to mp4 is a bunch of repeated frames and lots of tearing of the upper 1/4. but the audio's fine



[Attachment 56166 - Click to enlarge]

[subwoofer]

Sounds like my starting point... Reindexing with DGIndexNV has fixed the video - which btw is 1080i25. The metadata in the file is absolutely all over the place.