Cross-Platform D2V Source for VapourSynth

[Daemon404]

So, I was bored and wrote a cross-platform D2V parser and decoder for VapourSynth.

Current Version: 1.2

Windows Binary: https://github.com/dwbuiten/d2vsourc....2-windows.zip - Contains 32-bit and 64-bit binaries.
Source: https://github.com/dwbuiten/d2vsourc...rce-1.2.tar.xz

Known Limitations & Bugs

• Does not support user specified cropping. Would be easy to add, but I disagree with the premise. Use VapourSynth's cropping.
• Needs the full path to the D2V file.
• Probably more I'm forgetting!

Example usage:

import vapoursynth as vs
core = vs.Core()

core.std.LoadPlugin(path=r'C:\Path\To\d2vsource.dll')

ret = core.d2v.Source(input=r'C:\Path\To\my.d2v')

last = ret

Parameters:
input - Full path to input D2V file.
nocrop - Always use direct-rendered buffer, which may need cropping. Provides a speedup when you know you need to crop your image anyway, by avoiding extra memcpy calls.
rff - Invoke ApplyRFF (True by default)
threads - Number of threads FFmpeg should use. Default is 0 (auto).

If you want to contribute, feel free to send a pull request on GitHub.

I can look into what would be needed to port DGIndex to *nix. The last time I looked at the code it was a bit menacing, though. It also relies on a bunch of ASM that would probably be a nightmare to port so we'd have to stick to plain C++ until/unless someone wants to take on that task.

I'll also test building this on OS X when I get home tonight.

[jackoneill]

Originally Posted by Chirico

I can look into what would be needed to port DGIndex to *nix. The last time I looked at the code it was a bit menacing, though. It also relies on a bunch of ASM that would probably be a nightmare to port so we'd have to stick to plain C++ until/unless someone wants to take on that task.

I'll also test building this on OS X when I get home tonight.

There is a "trimmed" dgindex here: http://fraps.servegame.com/movie/. IIRC it did compile in Linux when I discovered it (ages ago).

Okay. Though thinking about it more: Does DGIndex actually give us any benefits over ffms2 with a generated index file these days? I can really only see for possibly cutting streams and demuxing audio, but I'm not sure those features alone are worth myself taking on the effort. Though I can definitely provide you with feedback on building on OS X.

[JEEB]

Originally Posted by Chirico

Okay. Though thinking about it more: Does DGIndex actually give us any benefits over ffms2 with a generated index file these days?

The LAVF mpeg-ts/ps demuxer doesn't really seem to be too stable in order to give frame-exact seeking. It seems to work for some things, and fail at others. Basically the idea of indexing the packet borders for the needed IDR packets from which lavf parsing/decoding can be started seems to work rather well.

Of course, if possible it would be nice for this kind of stuff to be implemented in ffms2 itself, but this is a basic first step towards having cross-platform solutions for various files.

[Daemon404]

Originally Posted by Chirico

Okay. Though thinking about it more: Does DGIndex actually give us any benefits over ffms2 with a generated index file these days? I can really only see for possibly cutting streams and demuxing audio, but I'm not sure those features alone are worth myself taking on the effort. Though I can definitely provide you with feedback on building on OS X.

I haven't had much luck at all using FFMS2 to seek frame-accurately in MPEG-PS or MPEG-TS.

[Daemon404]

Originally Posted by JEEB

Of course, if possible it would be nice for this kind of stuff to be implemented in ffms2 itself, but this is a basic first step towards having cross-platform solutions for various files.

This would mean that FFMS2 has two types of indexing, which is... kinda ~meta~, and somewhat ugly.

Originally Posted by Daemon404

I haven't had much luck at all using FFMS2 to seek frame-accurately in MPEG-PS or MPEG-TS.

Okay, so that is definitely a good reason. Then I'll definitely look into it. Especially from the starting point of that already ported and trimmed-down DGIndex.

So I got it to compile in OS X with the removal of "-Wl,-Bsymbolic" but I just get:

  File "vapoursynth.pyx", line 1016, in vapoursynth.Function.__call__ (build/src/cython/vapoursynth.c:15627)
vapoursynth.Error: 'Cannot initialize decoder.'

Trying to trace the issue now.

[Daemon404]

Originally Posted by Chirico

Trying to trace the issue now.

Yes, I should really add proper error reporting instead of dumping to stdout...

It's probably failing to open the file(s) referenced in the D2V file. I assumed, since this is on OS X, you are using a relative path?

EDIT: As of b7a0ada5, error messages are properly propagated.

Actually I just figured out that it was something stupid on my part. I forgot to change the path in the d2v file from when I generated it on Windows. Works fine now. For anyone who wants it, here is the compiled version for OS X.

Originally Posted by jackoneill

There is a "trimmed" dgindex here: http://fraps.servegame.com/movie/. IIRC it did compile in Linux when I discovered it (ages ago).

The only issue with compiling that is on OS X is the lack of the non-standard fcloseall that it uses which I'm trying to fix now.

[Daemon404]

Originally Posted by Chirico

The only issue with compiling that is on OS X is the lack of the non-standard fcloseall that it uses which I'm trying to fix now.

I compiled it on Windows, and it's not that useful. It fails on MPEG-PS and elementary streams, and only works on some MPEG-TS streams...

Okay. Then I'll look into the full DGIndex instead, then.

[Revgen]

I have a large MPEG2-TS file. And it won't seek past 40,000 frames in VirtualDub with VPY support.

[Daemon404]

Originally Posted by Revgen

I have a large MPEG2-TS file. And it won't seek past 40,000 frames in VirtualDub with VPY support.

It's definitely possible that I messed up large file support. I don't have any very large MPEG-TS on meat this moment, but I'll either generate one or try and test with a large MPEG-PS stream.

Do you know if it gets stuck while decoding linearly too, or if it's solely a seeking problem?

In any case, here is a test build with a possible "fix": <Linked Removed>

The binary is a fair bit bigger due to being built with MinGW this time. If this binary works, I'll work on integrating an MSVC-compatible fix as well.

[Revgen]

It doesn't get stuck decoding linearly. But if I seek past 40,000 frames or stop the playback of the video once it passes that mark, Virtual Dub freezes and I have to shut it down with the task manager.

I tried your "fixed" version. The problem is still there.

[Daemon404]

Originally Posted by Revgen

It doesn't get stuck decoding linearly. But if I seek past 40,000 frames or stop the playback of the video once it passes that mark, Virtual Dub freezes and I have to shut it down with the task manager.

Hmm, so the problem is not what I thought it was. I'm going to have to try and generate a large MPEG-TS file then and try to reproduce.

[Daemon404]

Originally Posted by Daemon404

Hmm, so the problem is not what I thought it was. I'm going to have to try and generate a large MPEG-TS file then and try to reproduce.

OK, as of f16e83a2, it is fixed. I've made a few other fixes, and put a new binary in the original post.

[Revgen]

The fix works. Seeking works now. Thank you.