Cross-Platform D2V Source for VapourSynth

[Guest]

I've had my say, you've had yours. When you have something working along the lines you describe, I suppose you'll let us all know. I won't be holding my breath.

And BTW, please stop the profanity per forum rule 4. Thank you. I have edited your post.

[Daemon404]

Originally Posted by neuron2

When you have something working along the lines you describe, I suppose you'll let us all know. I won't be holding my breath.

I'll write something this week or next, and maybe add support to VIVTC (we'll see... scary tritical code port), and publish it along with a few other things. I never did say I wouldn't write something to handle it separately (but perhaps bundled).

Anyway, there's no compelling reason to couple the two, since you usually do want the unprocessed video, and VapourSynth has this nice frame metadata (as opposed to *bleck* AVS's hinting).

If anyone has any particularly bad samples, feel free to post them, and I will test them while I write it. I'd appreciate it.

I'm rather surprised people have only been mentioning this sort of thing, instead of the much larger and obvious problem of leading B frames, which I can't seem to stab libavcodec to handle in a nice way no matter what I do, seemingly. Yes, I've tried implementing something similar to what DGDecode does, but libavcodec is having none of that. Help or suggestions are VERY welcome with regards to this.

BTW, perhaps you could be a little less condescending with your posts in the future.

[Guest]

BTW, perhaps you could be a little less condescending with your posts in the future.

Maybe when you stop referring to my work as 'cruft'.

Originally Posted by Daemon404

I'll write something this week or next, and maybe add support to VIVTC (we'll see... scary tritical code port), and publish it along with a few other things. I never did say I wouldn't write something to handle it separately (but perhaps bundled).

Anyway, there's no compelling reason to couple the two, since you usually do want the unprocessed video, and VapourSynth has this nice frame metadata (as opposed to *bleck* AVS's hinting).

You can't move pulldown handling out of the source filter, because the source filter must randomly access and display a numbered frame in the pulled-down stream. I'd be interested to hear if you have a solution for that, maybe you haven't thought it through?

I'm rather surprised people have only been mentioning this sort of thing, instead of the much larger and obvious problem of leading B frames, which I can't seem to stab libavcodec to handle in a nice way no matter what I do, seemingly. Yes, I've tried implementing something similar to what DGDecode does, but libavcodec is having none of that. Help or suggestions are VERY welcome with regards to this.

You can accomplish the job with libavcodec; I have done that several times. What problem are you running into with libavcodec? There are some streams it may struggle with, but for most stuff it works just fine. You just have to know what it does when you feed it nondecodable frames.

[06_taro]

A souce filter is supposed to preserve whatever exists in the souce and convert it into a structure that the downstream filter can handle. If d2vsouce does put those flags as per-frame properties without loosing anything useful or even normally useless (you never know what weird souces may be and what weird things others may want to do, so a normally useless things may accidentally be useful in some cases), and there are filters knowing how to handle them and convert the clips into different forms according to different purposes in a user-friendly way , then everything is fine. Otherwise we cannot leave those flags to a condition in which it is a pain to deal with.

[Revgen]

1) I've had TS captures in the past that contained TFF and BFF frames. Why? I don't know, but that's how it was captured through the Firewire port. DGIndex and DGMPEGDec's ability to tell which frames were TFF and BFF by reading the RFF flags helped me tremendously to deinterlace the video. I've yet to capture such a file for awhile now, but I never know when it might happen again.

2)Also, I've had to encode silent movie captures that contained different framerates. Parts of the silent movie were 20fps, some were 22fps, and some were 24fps. These movies were originally broadcasted hard-telecined to handle the different framerates. And for good reason. It's a hellava lot easier than using RFF flags. I had to IVTC and use RFF flags for each section (via DGPulldown) and join them together in order for the whole movie to play progressively while keeping the same audio soundtrack. If I ever decided to rip these movies from my DVD-R's again and back them up to a different format, I'd need to have those multiple RFF flags read in order to process the video correctly.

I hope the metadata solution works for these issues.

[Daemon404]

Originally Posted by neuron2

You can't move pulldown handling out of the source filter, because the source filter must randomly access and display a numbered frame in the pulled-down stream. I'd be interested to hear if you have a solution for that, maybe you haven't thought it through?

It's not strictly needed in the source filter. You can frame accurately seek within the coded picture, which is indeed what you way want.

Per-frame metadata mat not be entirely sufficient in this case, actually, so what I'm thinking it something like this:

import vapoursynth as vs

core = vs.Core()

ret = core.d2v.Source(input=r'C:\somefile.d2v', nocrop=True)
ret = core.d2v.ApplyRFF(ret, d2v=r'C:\somefile.d2v')

last = ret

This would nicely decouple the two, while allowing you to apply a d2v's RFF flags to an arbitrary clip (useful if you mess up or something). The other option is to use whole-clip metadata, when it is added to VapourSynth (Myrsloik says it's coming!).

Also, to clarify, ApplyRFF would be akin to honoring the RFF flags. I still do not intend to implement Force FILM.

Originally Posted by neuron2

You can accomplish the job with libavcodec; I have done that several times. What problem are you running into with libavcodec? There are some streams it may struggle with, but for most stuff it works just fine. You just have to know what it does when you feed it nondecodable frames.

In my case, when I tried returning the first decodable frame in place of all the leading non-decodable frames, the entire clip ended up being shorter than it was supposed to be, since it was missing 2-3 frames still, somehow. My general method was to still start at the beginning of the first GOP, and decode until frame N, where N is the first decodable frame, and return that in place of the first N frames.

Can you perhaps elaborate on your strategy?

Originally Posted by Revgen

1) I've had TS captures in the past that contained TFF and BFF frames. Why? I don't know, but that's how it was captured through the Firewire port. DGIndex and DGMPEGDec's ability to tell which frames were TFF and BFF by reading the RFF flags helped me tremendously to deinterlace the video. I've yet to capture such a file for awhile now, but I never know when it might happen again.

The d2v file stashes TFF/BFF info, so that is easy to expose.

Originally Posted by Revgen

2)Also, I've had to encode silent movie captures that contained different framerates. Parts of the silent movie were 20fps, some were 22fps, and some were 24fps. These movies were originally broadcasted hard-telecined to handle the different framerates. And for good reason. It's a hellava lot easier than using RFF flags. I had to IVTC and use RFF flags for each section (via DGPulldown) and join them together in order for the whole movie to play progressively while keeping the same audio soundtrack. If I ever decided to rip these movies from my DVD-R's again and back them up to a different format, I'd need to have those multiple RFF flags read in order to process the video correctly.

I'd be grateful if you could supply a sample for testing when I implement this.

[Guest]

Originally Posted by Daemon404

ret = core.d2v.Source(input=r'C:\somefile.d2v', nocrop=True)
ret = core.d2v.ApplyRFF(ret, d2v=r'C:\somefile.d2v')

last = ret

I don't see what you gain from "nicely decoupling" the two, but hey go for it if it pleases you. Having to load a separate plugin, coordinate the D2V filename between them, etc., appears pointless to me and introduces unnecessary complications. The fact is you need that code somewhere, and it is definitely not cruft.

I still do not intend to implement Force FILM.

Why not? It's proven to be quite useful for several types of streams.

In my case, when I tried returning the first decodable frame in place of all the leading non-decodable frames, the entire clip ended up being shorter than it was supposed to be, since it was missing 2-3 frames still, somehow. My general method was to still start at the beginning of the first GOP, and decode until frame N, where N is the first decodable frame, and return that in place of the first N frames.

Can you perhaps elaborate on your strategy?

It's no different from what you described. Have you determined where the missing frames are? You may be missing some at the end.

[Daemon404]

Originally Posted by neuron2

I don't see what you gain from "nicely decoupling" the two, but hey go for it if it pleases you. Having to load a separate plugin, etc., appears pointless to me. The fact is you need that code somewhere, and it is definitely not cruft.

Maintainability. And the idea is to have it in the same plugin (dll/so), and in the same namespace (core.d2v), but a different function name. It's the "VapourSynth Way" to do things. Here's a lazy wrapper:

core.std.LoadPlugin(r'C:\d2vsource.dll')

def betterD2VSource(path):
    ret = core.d2v.Source(input=path)
    ret = core.d2v.ApplyRFF(ret, d2v=path)
    return ret

Maybe I'll even bundle it!

Originally Posted by neuron2

Why not? It's proven to be quite useful for several types of streams.

It doesn't seem like anything but a convenience thing to me. Even the most basic IVTC plugin could do this given proper metadata. And that what this is: IVTC. IIRC, TIVTC even supports doing this in AviSynth (by pointing it at a d2v).

Originally Posted by neuron2

It's no different from what you described. Have you determined where the missing frames are? You may be missing some at the end.

They're missing at the beginning on the stream I tested, which DGDecode handles correctly. I might try and read avconv.c/ffmpeg.c to see what they do, but they're also kind of weird on these cases, I think. I haven't tested FFMS2.

[Daemon404]

Just posted Beta4.

Quick summary of things:

• 4:2:2 Support
• MPEG Transport Stream PID Support (Multi-stream)
• RFF Support (See README)
• Bug Fixes!

Full changelog here.

At some point I plan to enable sliced threading for the MPEG1/2 decoding, and frame threading for RFF application.

URLs in OP.

[Revgen]

Good news. The RFF flags seem to be working. I tried one of my silent movies with 20fps and 24fps sections and the pulldown flags are being properly honored.

Bad news. The GCC Beta4 build seems to be broken. It just hangs when I try to load it. MSVC Beta4 build works fine.

[Daemon404]

Originally Posted by Revgen

Bad news. The GCC Beta4 build seems to be broken. It just hangs when I try to load it. MSVC Beta4 build works fine.

I asked someone else to build it this time, as my usual box I build the MinGW stuff on was down. I'll rebuild it / test on Monday.

[Daemon404]

Originally Posted by Daemon404

I asked someone else to build it this time, as my usual box I build the MinGW stuff on was down. I'll rebuild it / test on Monday.

New MinGW binary up in OP, with a critical bug too.

I've tested this binary to work on Windows 7.

Not going to bother posting Visual Studio builds now, as theyre a fair bit slower than MinGW builds (even though they're ~2.5x smaller).

[mikewando]

It might be worth noting which version of libavcodec this requires (especially in the configure script) since Ubuntu 12.10's libavcodec-dev is evidently too old.

For others trying to compile on 12.10 I grabbed the 9.1 tarball from http://libav.org/download.html and that worked for me, but I had to add --enable-pic to my configure line when building libavcodec; d2vsource complained otherwise.

Edit: Tried it out and it seems to work fine for my purposes. Thanks a lot for the work! Looking forward to a future where I can keep my whole workflow in 64bit Linux.

[Daemon404]

Originally Posted by mikewando

It might be worth noting which version of libavcodec this requires (especially in the configure script) since Ubuntu 12.10's libavcodec-dev is evidently too old.

For others trying to compile on 12.10 I grabbed the 9.1 tarball from http://libav.org/download.html and that worked for me, but I had to add --enable-pic to my configure line when building libavcodec; d2vsource complained otherwise.

I generally follow git master. As for --enable-pic, I figured that was common knowledge, since PIC is kind of required for Linux shared libraries. I suppose I could note it.

[mikewando]

Originally Posted by Daemon404

I generally follow git master. As for --enable-pic, I figured that was common knowledge, since PIC is kind of required for Linux shared libraries. I suppose I could note it.

Of course PIC makes sense, but I didn't know libavcodec builds without -fpic by default. I'm not sure how common that is; I try to generally avoid building my own libraries as much as possible. I also wanted to note it for other people who may have no idea what the error message is really telling them.

At any rate I think the most helpful thing would just to have the configure script spit out that it requires libavcodec >= 0.9.0, or whatever its current requirement is, since it's entirely possible for libavcodec/avcodec.h to exist and have been found and still fail the configure check.

[Daemon404]

Beta5 Released: http://chromashift.org/vs/d2vsource_beta5.zip
ChangeLog here.

Highlights: Open GOP seeking now works properly in all cases!

Originally Posted by mikewando

At any rate I think the most helpful thing would just to have the configure script spit out that it requires libavcodec >= 0.9.0, or whatever its current requirement is, since it's entirely possible for libavcodec/avcodec.h to exist and have been found and still fail the configure check.

Sure.

Thanks for this! Quick question: Have you fixed the limitation about last frame not decoded? If not check out this starting at line 417. Or I can probably try to make a patch for you.

[Daemon404]

Originally Posted by paradoxical

Thanks for this! Quick question: Have you fixed the limitation about last frame not decoded? If not check out this starting at line 417. Or I can probably try to make a patch for you.

I know. I've just been too lazy to deal with libavcodec's tomfoolery...

Originally Posted by Daemon404

I know. I've just been too lazy to deal with libavcodec's tomfoolery...

Well, I think I know where the fix needs to be. Testing now and if it works I'll send you a patch shortly.

So this is odd. The fix I made works for certain clips to get all frames whereas others crash when reading the last frame. Continuing to debug it.