View Full Version : Cross-Platform D2V Source for VapourSynth


Daemon404
5th November 2012, 04:11
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/d2vsource/releases/download/v1.2/d2vsource-1.2-windows.zip - Contains 32-bit and 64-bit binaries.
Source: https://github.com/dwbuiten/d2vsource/releases/download/v1.2/d2vsource-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.

Chirico
5th November 2012, 17:49
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
5th November 2012, 18:24
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).

Chirico
5th November 2012, 18:28
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
5th November 2012, 18:56
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
5th November 2012, 19:02
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
5th November 2012, 19:05
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.

Chirico
5th November 2012, 19:36
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.

Chirico
6th November 2012, 02:09
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
6th November 2012, 02:37
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.

Chirico
6th November 2012, 02:41
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 (http://www.sendspace.com/file/olb5yp) is the compiled version for OS X.

Chirico
6th November 2012, 14:45
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
6th November 2012, 18:20
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...

Chirico
6th November 2012, 18:50
Okay. Then I'll look into the full DGIndex instead, then.

Revgen
9th November 2012, 07:20
I have a large MPEG2-TS file. And it won't seek past 40,000 frames in VirtualDub with VPY support.

Daemon404
9th November 2012, 09:13
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
9th November 2012, 11:26
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
9th November 2012, 19:20
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
9th November 2012, 22:37
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
10th November 2012, 02:16
The fix works. Seeking works now. Thank you.

lil'jerry
16th November 2012, 20:46
IJust wanted to say thanks for providing this. After seeing the announcement for AvxSynth I was thinking of porting DGIndex to something cross-platform but got discouraged by the fact that it's a huge mass of spaghetti code. But after seeing this post, I've started up again a few days ago this time starting from scratch and just re-implementing core features (generating d2v files, demuxing video/audio, d2v fixer, etc.) and leaving out all the other cruft (AC3 decoding, audio resampling, cropping filter, luminance filter, etc). Right now, I have d2v generation and demuxing working and I'm getting identical results to DGIndex in my limited tests. I'm trying to finish up the last few features I want supported and trying to test it as much as possible. Should have something by mid next week for others to test and I'll throw the code up on github. It's written for Qt and uses ffmpeg libs for parsing/demuxing of the streams.

Guest
19th November 2012, 13:50
IJust wanted to say thanks for providing this. After seeing the announcement for AvxSynth I was thinking of porting DGIndex to something cross-platform but got discouraged by the fact that it's a huge mass of spaghetti code. But after seeing this post, I've started up again a few days ago this time starting from scratch and just re-implementing core features (generating d2v files, demuxing video/audio, d2v fixer, etc.) and leaving out all the other cruft (AC3 decoding, audio resampling, cropping filter, luminance filter, etc). Right now, I have d2v generation and demuxing working and I'm getting identical results to DGIndex in my limited tests. I'm trying to finish up the last few features I want supported and trying to test it as much as possible. Should have something by mid next week for others to test and I'll throw the code up on github. It's written for Qt and uses ffmpeg libs for parsing/demuxing of the streams. Please rename the tool as I prefer to keep the DG imprimatur for my stuff. Thank you.

lil'jerry
19th November 2012, 15:21
Yes, it will be called something different such as D2VCreator since it shares no code but only shares a similar-looking GUI and a subset of functionality of the DGIndex/DVD2AVI programs.

Guest
19th November 2012, 15:45
Great, thanks very much and good luck with the project!

lil'jerry
19th November 2012, 21:36
Hey Daemon in looking at your code it seems you ignore the "field operation" flag in the D2V file. Are you planning to support this?

Daemon404
19th November 2012, 22:13
Hey Daemon in looking at your code it seems you ignore the "field operation" flag in the D2V file. Are you planning to support this?

I'm not sure. Its use seems rather dubious... it doesn't do anything that can't be done elsewhere, as far as I can see?

As a side note, new beta is posted, this time with a MinGW build as well, which has inline assembly and should be faster.

Changlog here, because I'm lazy: https://github.com/dwbuiten/d2vsource/compare/beta2...beta3

Keiyakusha
19th November 2012, 22:18
Daemon404
Hi. You mentioned gui before, but I don't see it. It is not yet ready, right?
Anyway I want to make feature request for it - please don't forget some kind of indication where vobs,cells start/end so we can easily cut exactly at these points. Of course if cutting will be part of the subset at all.

Daemon404
19th November 2012, 22:23
Daemon404
Hi. You mentioned gui before, but I don't see it. It is not yet ready, right?
Anyway I want to make feature request for it - please don't forget some kind of indication where vobs,cells start/end so we can easily cut exactly at these points. Of course if cutting will be part of the subset at all.

I didn't. I think you meant lil'jerry. :)

lil'jerry
19th November 2012, 22:24
I'm not sure. Its use seems rather dubious... it doesn't do anything that can't be done elsewhere, as far as I can see?

How is it dubious? The force film operation is quite useful for soft telecined input files so you don't have to IVTC. Unless your just skipping all the field repeats in decoding anyway.

Hi. You mentioned gui before, but I don't see it. It is not yet ready, right?


I'm working on a cloned DGIndex/DVD2AVI right now as I announced above.

Daemon404
19th November 2012, 22:33
How is it dubious? The force film operation is quite useful for soft telecined input files so you don't have to IVTC. Unless your just skipping all the field repeats in decoding anyway.

As it is right now, neither VapourSynth nor d2vsource has a concept of a 'field'. I do not feel it is worth the complexity of adding this to d2vsource to achieve something you can easily do outside of it, in the same 'perfect' way. There's no value-add for this feature, as far as I can tell...

lil'jerry
19th November 2012, 22:40
So then how are you decoding mpeg-2 files with RFF flags set? Are you just always ignoring the repeats or what? ffms2 has the rffmode option that still works under Vapoursynth just as it does under Avisynth. That Vapoursynth has no concept of a field seems irrelevant.

Daemon404
19th November 2012, 22:41
So then how are you decoding mpeg-2 files with RFF flags set? Are you just always ignoring the repeats or what?

FFmpeg's stuff handles this, AFAIK.

lil'jerry
19th November 2012, 22:43
FFmpeg's stuff handles this, AFAIK.

So then you are pushing through 29.97 with frame repeats even with soft telecine? That seems silly to do. As I mention above, ffms2's rffmode works even under Vapoursynth so that these field repeats can be ignored so IVTC isn't needed.

Keiyakusha
19th November 2012, 22:45
I didn't. I think you meant lil'jerry. :)

woops, sorry! yes, lil'jerry! :scared:

Daemon404
19th November 2012, 22:46
So then you are pushing through 29.97 with frame repeats even with soft telecine? That seems silly to do.

Again, this is EASILY worked with outside of d2vsource, and I do not want to fill it with unrelated cruft. Why are people so obsessed with ~everything done in the source filter~? I have very purposely not implemented several of DGDecode's bloat features. It sounds to me like all this feature accomplishes is adding a slight convenience, in exchange for a lot more complexity.

EDIT: It is feasible, however, to return rff flags as part of the frame metadata for other filters. Like hinting in AVS.

Myrsloik
19th November 2012, 22:46
So then you are pushing through 29.97 with frame repeats even with soft telecine? That seems silly to do. As I mention above, ffms2's rffmode works even under Vapoursynth so that these field repeats can be ignored so IVTC isn't needed.

HAHAHA!

Got ya!

I deleted the rff code from the vs side of ffms2 because I was lazy. NANANA:p

jackoneill
19th November 2012, 22:53
So then you are pushing through 29.97 with frame repeats even with soft telecine? That seems silly to do. As I mention above, ffms2's rffmode works even under Vapoursynth so that these field repeats can be ignored so IVTC isn't needed.

OR, you could just open a progressive DVD with d2vsource and see that it ignores those flags.

TheFluff
19th November 2012, 22:58
So then you are pushing through 29.97 with frame repeats even with soft telecine?

The other way around. ffmpeg ignores repeat fields when decoding, so you get only the coded frames. If you want to add the "missing" fields in the correct places you can do so by examining the frame PTS's, I believe. Or if you want to make your life easy just put the repeat_pict number in a per-frame property.

Guest
20th November 2012, 00:13
I find this discussion amusing. The source filter is the last one to know about the RFF flags, so if repeated fields are going to be honored, that is the right place to do it. And to coordinate with random access by frame number...it has to take into account the repeats. This stuff is hardly "cruft", if you want to do things in a half-assed way, fine, it's your choice, but don't try to blame someone that has done the right thing.

There are lots of streams with irregular pulldown and ones with mixtures of hard and soft pulldown. If you want to have a hope of processing those correctly, you are going to need to honor repeat flags.

Daemon404
20th November 2012, 00:40
I find this discussion amusing. The source filter is the last one to know about the RFF flags, so if repeated fields are going to be honored, that is the right place to do it.

I respectfully disagree. It adds needless complexity to a source filter. The better idea is add it to the frame metadata in VapourSynth, and have a separate filter handle it (IVTC filter, perhaps). There is absolutely no reason to burden the source filter with this, whose job is not to mess with the frames.

And to coordinate with random access by frame number...it has to take into account the repeats.

Um, no. There's is no reason you need RFF flags for "proper" random access. In fact, you shouldn't even have to 'expand' them at all. I'm curious how you define "proper" here.

This stuff is hardly "cruft", if you want to do things in a half-assed way, fine, it's your choice, but don't try to blame someone that has done the right thing.

"Right thing" is subjective here, and you also seem to be bogged down in AviSynth's and its filters' limitations. Your way is merely one way to do it. And for what it's worth, DGDecode has plenty of cruft. It's like a bunch of stuff that just happens to have a source filter in it. How many people actually think BlindPP(), Deblock(), LumaYV12(), or the pp, showQ, cpu, cpu2, etc params of MPEG2Source() are even useful in 2012? Were they ever useful? It's cruft-level is libpostproc-like (which actually does something similar).

There are lots of streams with irregular pulldown and ones with mixtures of hard and soft pulldown. If you want to have a hope of processing those correctly, you are going to need to honor repeat flags.

I've been working with hybrid material (in YATTA, anime obviously) with all sorts of crap like that for about about a decade now. As I said, there is absolutely no reason to handle this in the source filter when you have standard metadata for frames.

P.S. You should take a look at how I'm actually using FFmpeg before you make such statements in the future.

Guest
20th November 2012, 02:00
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
20th November 2012, 03:10
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
20th November 2012, 04:15
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'. :)

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
20th November 2012, 09:50
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
20th November 2012, 10:14
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
20th November 2012, 15:14
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.

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?

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.

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
20th November 2012, 16:00
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
20th November 2012, 16:12
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!

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).

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
9th December 2012, 02:38
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 (https://github.com/dwbuiten/d2vsource/compare/beta3...beta4).

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

URLs in OP.

Revgen
9th December 2012, 04:43
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
9th December 2012, 05:20
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
11th December 2012, 04:12
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
13th January 2013, 23:16
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
14th January 2013, 00:29
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
14th January 2013, 00:58
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
26th February 2013, 16:55
Beta5 Released: http://chromashift.org/vs/d2vsource_beta5.zip
ChangeLog here (https://github.com/dwbuiten/d2vsource/compare/beta4...beta5).

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

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.

paradoxical
26th February 2013, 17:05
Thanks for this! Quick question: Have you fixed the limitation about last frame not decoded? If not check out this (http://cekirdek.pardus.org.tr/~ismail/ffmpeg-docs/api-example_8c-source.html) starting at line 417. Or I can probably try to make a patch for you.

Daemon404
26th February 2013, 17:18
Thanks for this! Quick question: Have you fixed the limitation about last frame not decoded? If not check out this (http://cekirdek.pardus.org.tr/~ismail/ffmpeg-docs/api-example_8c-source.html) 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...

paradoxical
26th February 2013, 17:37
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.

paradoxical
26th February 2013, 19:02
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.

Daemon404
26th February 2013, 19:07
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.

Welcome to the wonderful world of libavcodec. \o/

paradoxical
26th February 2013, 19:19
Actually the issue wasn't on libavcodec. The decoding code was getting caught in an infinite loop for some of the streams on the last frame. Why some did and some didn't is weird, but once I changed the logic the decoding worked on all streams. Diff file for the changes is here (https://www.dropbox.com/s/coqidk0pjuuyp9b/patch.txt). It's actually a pretty small change.

Daemon404
26th February 2013, 19:30
Actually the issue wasn't on libavcodec. The decoding code was getting caught in an infinite loop for some of the streams on the last frame. Why some did and some didn't is weird, but once I changed the logic the decoding worked on all streams. Diff file for the changes is here (https://www.dropbox.com/s/coqidk0pjuuyp9b/patch.txt). It's actually a pretty small change.

I'll poke it a bit tonight or tomorrow morn.

Thanks!

Do you have a name/email I can put in the git history as the author?

paradoxical
26th February 2013, 19:31
If you want I can send you an actual pull request through github.

Daemon404
26th February 2013, 19:33
If you want I can send you an actual pull request through github.

Sweet. Go for it.

paradoxical
26th February 2013, 19:39
Done. :)

Daemon404
26th February 2013, 20:05
Done. :)

Merged. It'll be in beta6 (or v0.1... bugs are getting low now). Whenever that is.

paradoxical
26th February 2013, 21:58
Cool. Glad to have helped that get solved. :)

Daemon404
13th March 2013, 03:17
So I've written a working prototype of a D2V creation utility in Perl, and it seems to work cross-platform. I'll have to get off my ass and write it properly in C so I can release it soon... ;)

Revgen
13th March 2013, 15:17
Good news. Glad to hear.

Keiyakusha
21st May 2013, 11:10
So I've written a working prototype of a D2V creation utility in Perl, and it seems to work cross-platform. I'll have to get off my ass and write it properly in C so I can release it soon... ;)

I'm trying to hold myself, but looks like I can't do it anymore. So I have to ask, was there any progress on that?
Just want to mention that if people don't post much, doesn't means they don't need it :o

Daemon404
22nd May 2013, 22:05
I'm trying to hold myself, but looks like I can't do it anymore. So I have to ask, was there any progress on that?
Just want to mention that if people don't post much, doesn't means they don't need it :o

Mostly just laziness and busyness are holding it up. Moving between continents and hectic work schedule. But mostly, I need to get up the motivation to write the large amount of boilerplate code that the libavformat and libavcodec cumbersome APIs require to do anything. I'll set a tentative date of "before June 1st^H^H^H^H^H^H^H^Hmid june.".

For now, here's my horrible hacky perl script: https://gist.github.com/dwbuiten/5630882

It's pretty broken, hacky, inefficient, and is missing several features, but the basic idea is there.

Thanks for the wake up call!

opteronup
21st August 2013, 11:25
Please help me to compile this package on Arch linux.

When I try to compile this package, I receive this error:

==> Starting pkgver()...
==> Updated version: vapoursynth-plugin-d2vsource-git 20130428.a6741ad-1
==> Starting build()...
CXXFLAGS/LDFLAGS checking...
checking for libavformat...
checking for libavcodec...

settings...
CXX = g++
LD = g++
STRIP = strip
CXXFLAGS = -Os -ffast-math -Wall -D__STDC_CONSTANT_MACROS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I. -I./vs -I./core -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -fPIC -fexcess-precision=fast -DQT_SHARED -I/usr/include/vapoursynth -I/usr/include/qt4 -I/usr/include/qt4/QtCore
LDFLAGS = -shared -Wl,-Bsymbolic -fPIC
LIBS = -lavformat -lavcodec -lvapoursynth
LIBNAME = libd2vsource.so
install path = /home/user/Downloads/vapoursynth-plugin-d2vsource-git/pkg/vapoursynth-plugin-d2vsource-git/usr/lib/vapoursynth
configure finished.
g++ -Os -ffast-math -Wall -D__STDC_CONSTANT_MACROS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I. -I./vs -I./core -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -fPIC -fexcess-precision=fast -DQT_SHARED -I/usr/include/vapoursynth -I/usr/include/qt4 -I/usr/include/qt4/QtCore -c vs/applyrff.cpp -o vs/applyrff.o
g++ -Os -ffast-math -Wall -D__STDC_CONSTANT_MACROS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I. -I./vs -I./core -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -fPIC -fexcess-precision=fast -DQT_SHARED -I/usr/include/vapoursynth -I/usr/include/qt4 -I/usr/include/qt4/QtCore -c vs/d2vsource.cpp -o vs/d2vsource.o
vs/d2vsource.cpp: In function ‘const VSFrameRef* d2vGetFrame(int, int, void**, void**, VSFrameContext*, VSCore*, const VSAPI*)’:
vs/d2vsource.cpp:51:28: error: ‘av_frame_unref’ was not declared in this scope
av_frame_unref(d->frame);
^
vs/d2vsource.cpp: In function ‘void d2vFree(void*, VSCore*, const VSAPI*)’:
vs/d2vsource.cpp:86:28: error: ‘av_frame_unref’ was not declared in this scope
av_frame_unref(d->frame);
^
vs/d2vsource.cpp: In function ‘void d2vCreate(const VSMap*, VSMap*, void*, VSCore*, const VSAPI*)’:
vs/d2vsource.cpp:122:23: error: ‘AVCodecContext’ has no member named ‘get_buffer2’
data->dec->avctx->get_buffer2 = VSGetBuffer;
^
make: *** [vs/d2vsource.o] Error 1
==> ERROR: A failure occurred in build().
Aborting...
I think the reason is incompatibility with newer versions of ffmpeg, but I'm not sure. I tried with these versions of ffmpeg - 1.1.5, 1.2.2 and 2.0.

Please help!

Thanks in advance.

jackoneill
21st August 2013, 12:14
Your ffmpeg is probably not new enough rather than too new (though I thought 2.0 was pretty new...? With ffmpeg releases, who knows.)

I recommend you build the latest ffmpeg from git somewhere (~/, or /opt/) with --enable-static --disable-shared, and make d2vsource use that.

opteronup
21st August 2013, 18:29
Thanks, jackoneill.

I tried with git version of ffmpeg. Now I receive this error:

==> Starting build()...
CXXFLAGS/LDFLAGS checking...
checking for libavformat...
error: libavformat checking failed.
error: libavformat/avformat.h might not be installed or some libs missing.
==> ERROR: A failure occurred in build().
Aborting...

I have used --disable-shared --enable-static, as you said. I only did not change the directory, I removed my ffmpeg and installed git version of ffmpeg.

jackoneill
21st August 2013, 20:16
Thanks, jackoneill.

I tried with git version of ffmpeg. Now I receive this error:



I have used --disable-shared --enable-static, as you said. I only did not change the directory, I removed my ffmpeg and installed git version of ffmpeg.

Uh... run it like this:

PKG_CONFIG_PATH=$ffmpeg_prefix/lib/pkgconfig/ ./configure

where $ffmpeg_prefix is whatever prefix you passed to ffmpeg's configure (the default is probably /usr/local).

opteronup
21st August 2013, 23:01
Absolutely the same error. :angry:

Do you have a compiled d2vsource package? I do not know which distribution you use but I think I can convert it.

jackoneill
22nd August 2013, 11:21
Absolutely the same error. :angry:


Okay... tell me exactly what commands you used to download, compile and install ffmpeg. If you used a PKGBUILD just paste that. Also the config.log from d2vsource.

opteronup
22nd August 2013, 15:00
I have used this PKGBUILD for d2vsource

# Maintainer: Gustavo Alvarez <sl1pkn07@gmail.com>

_plug=d2vsource
pkgname=vapoursynth-plugin-${_plug}-git
pkgver=20130226.1dd663c
pkgrel=1
pkgdesc="Plugin for Vapoursynth: ${_plug} (GIT version)"
arch=('i686' 'x86_64')
url="https://github.com/dwbuiten/${_plug}"
license=('GPL')
depends=('vapoursynth')
provides=("vapoursynth-plugin-${_plug}")
conflicts=("vapoursynth-plugin-${_plug}")
makedepends=('git')
source=("git://github.com/dwbuiten/${_plug}.git")
md5sums=('SKIP')
_gitname="${_plug}"

pkgver() {
cd "${_gitname}"
echo "$(git log -1 --format="%cd" --date=short | tr -d '-').$(git log -1 --format="%h")"
}

build() {
cd "${srcdir}/${_gitname}"

./configure --install="${pkgdir}/usr/lib/vapoursynth" --extra-cxxflags="$CXXFLAGS"
make
}

package(){
cd "${srcdir}/${_gitname}"
make install
install -Dm644 README "${pkgdir}/usr/share/doc/vapoursynth/plugins/${_plug}/README"
}

this for ffmpeg 1.1.5, 1.2.2 and 2.0:

# $Id$
# Maintainer: Gerad Munsch <gmunsch@unforgivendevelopment.com>
# Previous maintainer: Rudolf Polzer <divVerent[at]xonotic[dot]org>
# Original maintainer: Ionut Biru <ibiru@archlinux.org>
# Contributor: Tom Newsom <Jeepster@gmx.co.uk>
# Contributor: Paul Mattal <paul@archlinux.org>

# NOTE: This package was derived from 'ffmpeg-full', with some additional codecs
# enabled, and brought up to date to extra/ffmpeg.

# NOTE before flagging this out of date: this PKGBUILD is supposed to have the
# same ffmpeg version as extra/ffmpeg. Once that one got updated, this one
# needs too.

pkgname=ffmpeg-full-extra
pkgver=2.0
pkgrel=1
epoch=1
pkgdesc="Record, convert, and stream audio and video (all codecs; compatible to extra/ffmpeg)"
arch=('i686' 'x86_64')
url="http://ffmpeg.org/"
license=('GPL' 'custom:UNREDISTRIBUTABLE')
depends=('alsa-lib' 'bzip2' 'fontconfig' 'faac' 'lame' 'libtheora' 'libva' 'sdl' 'x264' 'libass' 'libbluray' 'libcaca' 'libiec61883' 'openal' 'twolame' 'libavc1394' 'xvidcore' 'schroedinger' 'v4l-utils' 'speex' 'opus' 'libvpx' 'jack' 'opencore-amr' 'rtmpdump' 'openjpeg' 'libmodplug' 'gsm' 'libpulse' 'vo-aacenc' 'vo-amrwbenc' 'celt' 'gnutls' 'libdc1394' 'libfdk-aac' 'libcdio-paranoia' 'libaacplus' 'libvorbis' 'zlib')
makedepends=('libvdpau' 'yasm' 'pkg-config')
conflicts=('ffmpeg' 'ffmpeg-full' 'ffmpeg-git' 'ffmpeg-full-git')
provides=('ffmpeg' 'qt-faststart')
source=(http://ffmpeg.org/releases/ffmpeg-$pkgver.tar.bz2 'UNREDISTRIBUTABLE.txt')
sha256sums=('940e1bc4f3e185364099b4ba60d4b952615a4232c5641baa3e9f45d4d748130c'
'e0c1b126862072a71e18b9580a6b01afc76a54aa6e642d2c413ba0ac9d3010c4')

[[ "$CARCH" == i686 ]] && _asm='--disable-asm'

build() {
cd ffmpeg-$pkgver

msg "Starting configure..."
./configure \
--enable-shared \
--disable-debug \
--disable-static \
--prefix=/usr \
$_asm \
--enable-avresample \
--enable-bzlib \
--enable-dxva2 \
--enable-fontconfig \
--enable-gnutls \
--enable-gpl \
--enable-iconv \
--enable-libass \
--enable-libbluray \
--enable-libcaca \
--enable-libcdio \
--enable-libcelt \
--enable-libdc1394 \
--enable-libfaac \
--enable-libfdk-aac \
--enable-libfreetype \
--enable-libgsm \
--enable-libiec61883 \
--enable-libmodplug \
--enable-libmp3lame \
--enable-libopencore-amrnb \
--enable-libopencore-amrwb \
--enable-libopenjpeg \
--enable-libopus \
--enable-libpulse \
--enable-librtmp \
--enable-libschroedinger \
--enable-libspeex \
--enable-libtheora \
--enable-libtwolame \
--enable-libv4l2 \
--enable-libvo-aacenc \
--enable-libvo-amrwbenc \
--enable-libvorbis \
--enable-libvpx \
--enable-libx264 \
--enable-libxvid \
--enable-nonfree \
--enable-openal \
--enable-openssl \
--enable-postproc\
--enable-runtime-cpudetect \
--enable-vaapi \
--enable-vda \
--enable-vdpau \
--enable-version3 \
--enable-x11grab \
--enable-zlib \

msg "Starting make"
make
make tools/qt-faststart
make doc/ff{mpeg,play,server}.1
}

package() {
cd ffmpeg-$pkgver
make DESTDIR="$pkgdir" install install-man
install -D -m755 tools/qt-faststart "$pkgdir/usr/bin/qt-faststart"
install -D -m644 "$srcdir"/UNREDISTRIBUTABLE.txt "$pkgdir/usr/share/licenses/$pkgname/UNREDISTRIBUTABLE.txt"
}

# How to audit the ./configure flags:
#
# cut -c 3- <<'# EOF' | sh
# cd src/ffmpeg-1.2
# export DISABLED='
# # debugging flags follow:
# --enable-coverage
# --enable-extra-warnings
# --enable-ftrapv
# --enable-memalign-hack
# --enable-memory-poisoning
# --enable-random
# --enable-xmm-clobber-test
# # we do not want this:
# --enable-cross-compile # not cross building
# --enable-gray # slow
# --enable-hardcoded-tables # no advantage
# --enable-lto # slow build
# --enable-pic # not our job to decide this
# --enable-shared # handled by options before --prefix
# --enable-small # we want SPEED instead
# # this stuff does not build:
# --enable-frei0r # circular dependency
# --enable-libaacplus # does not build from AUR: configure.ac:8: error: "AM_CONFIG_HEADER": this macro is obsolete.
# --enable-libflite # configure fail: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../lib/libflite.a(au_alsa.o): In function "audio_open_alsa": (.text+0x20): undefined reference to "snd_pcm_hw_params_sizeof"
# --enable-libilbc # configure fail: /tmp/ffconf.lccg5Ux6.c:1:18: fatal error: ilbc.h: No such file or directory
# --enable-libnut # link fail: /usr/bin/ld: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../lib/libnut.a(muxer.o): relocation R_X86_64_32S against ".rodata" can not be used when making a shared object; recompile with -fPIC
# --enable-libsoxr # only as -git in AUR
# --enable-libstagefright-h264 # not in AUR
# --enable-libopencv # circular dependency
# --enable-libutvideo # compile fail: libavcodec/libutvideodec.cpp:64:18: error: "UTVF_RGB24_WIN" was not declared in this scope
# --enable-libxavs # does not build from AUR: /usr/bin/ld: common/i386/deblock.o: relocation R_X86_64_32 against ".rodata" can not be used when making a shared object; recompile with -fPIC
# # this stuff is not for linux/x86:
# --enable-avisynth # windows only
# --enable-sram # not x86
# --enable-thumb # not x86
# '
# ./configure --help | perl -ne 'for(/--enable-([0-9a-z-]+)\s/) { if($ENV{DISABLED} !~ /^--enable-$_\b/m) { print " --enable-$_ \\\n"; } }' | sort -u
# EOF

# vim:set ts=2 sw=2 et:

and this one for ffmpeg git:

# Maintainer: Rudolf Polzer <divVerent[at]xonotic[dot]org>
# Original maintainer: DrZaius <lou[at]fakeoutdoorsman[dot]com>

pkgname=ffmpeg-full-git
pkgver=0.51608.495ed19
pkgrel=1
pkgdesc="Record, convert, and stream audio and video (all codecs; git version)"
arch=('i686' 'x86_64')
url="http://ffmpeg.org/"
license=('GPL' 'custom:UNREDISTRIBUTABLE')
depends=('faac' 'lame' 'libtheora' 'libva' 'sdl' 'x264' 'libass' 'libbluray' 'libcaca' 'libiec61883' 'openal' 'twolame' 'libavc1394' 'xvidcore' 'schroedinger' 'v4l-utils' 'speex' 'opus' 'libvpx' 'jack' 'opencore-amr' 'rtmpdump' 'openjpeg' 'libmodplug' 'gsm' 'libpulse' 'vo-aacenc' 'vo-amrwbenc' 'libsoxr-git' 'celt' 'gnutls' 'libdc1394' 'libfdk-aac' 'libcdio-paranoia')
makedepends=('git' 'yasm' 'libnut-git' 'utvideo' 'pkg-config')
conflicts=('ffmpeg' 'ffmpeg-git' 'ffmpeg-full')
provides=('ffmpeg' 'ffmpeg-git' 'qt-faststart')
source=('git://git.videolan.org/ffmpeg#branch=master'
'UNREDISTRIBUTABLE.txt')
sha256sums=('SKIP'
'e0c1b126862072a71e18b9580a6b01afc76a54aa6e642d2c413ba0ac9d3010c4')

_gitname="ffmpeg"

pkgver() {
cd "$srcdir/$_gitname"
microver="$(git log -1 --pretty=format:%h )"
minorver="$(git rev-list --count HEAD)"
echo "0.$minorver.$microver"
}

build() {
cd "$srcdir/$_gitname"

msg "Starting configure..."
./configure \
--disable-shared \
--enable-debug \
--enable-static \
--prefix=/usr \
--enable-avresample \
--enable-bzlib \
--enable-fontconfig \
--enable-gnutls \
--enable-gpl \
--enable-libass \
--enable-libbluray \
--enable-libcaca \
--enable-libcdio \
--enable-libcelt \
--enable-libdc1394 \
--enable-libfaac \
--enable-libfdk-aac \
--enable-libfreetype \
--enable-libgsm \
--enable-libiec61883 \
--enable-libmodplug \
--enable-libmp3lame \
--enable-libnut \
--enable-libopencore-amrnb \
--enable-libopencore-amrwb \
--enable-libopenjpeg \
--enable-libopus \
--enable-libpulse \
--enable-librtmp \
--enable-libschroedinger \
--enable-libsoxr \
--enable-libspeex \
--enable-libtheora \
--enable-libtwolame \
--enable-libutvideo \
--enable-libv4l2 \
--enable-libvo-aacenc \
--enable-libvo-amrwbenc \
--enable-libvorbis \
--enable-libvpx \
--enable-libx264 \
--enable-libxvid \
--enable-nonfree \
--enable-openal \
--enable-openssl \
--enable-vaapi \
--enable-vda \
--enable-vdpau \
--enable-version3 \
--enable-x11grab \
--enable-zlib \

msg "Starting make"
make
make tools/qt-faststart
make doc
}

package() {
cd "$srcdir/$_gitname"
make DESTDIR="$pkgdir" install install-man
install -D -m755 tools/qt-faststart "$pkgdir/usr/bin/qt-faststart"
install -D -m644 "$srcdir"/UNREDISTRIBUTABLE.txt "$pkgdir/usr/share/licenses/$pkgname/UNREDISTRIBUTABLE.txt"
}

# How to audit the ./configure flags:
#
# cut -c 3- <<'# EOF' | sh
# cd src/ffmpeg
# export DISABLED='
# # debugging flags follow:
# --enable-coverage
# --enable-extra-warnings
# --enable-ftrapv
# --enable-memalign-hack
# --enable-memory-poisoning
# --enable-random
# --enable-xmm-clobber-test
# # we do not want this:
# --enable-cross-compile # not cross building
# --enable-gray # slow
# --enable-hardcoded-tables # no advantage
# --enable-lto # slow build
# --enable-pic # not our job to decide this
# --enable-shared # handled by options before --prefix
# --enable-small # we want SPEED instead
# # this stuff does not build:
# --enable-frei0r # circular dependency
# --enable-libaacplus # does not build from AUR: configure.ac:8: error: "AM_CONFIG_HEADER": this macro is obsolete.
# --enable-libflite # configure fail: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../lib/libflite.a(au_alsa.o): In function "audio_open_alsa": (.text+0x20): undefined reference to "snd_pcm_hw_params_sizeof"
# --enable-libilbc # configure fail: /tmp/ffconf.lccg5Ux6.c:1:18: fatal error: ilbc.h: No such file or directory
# --enable-libopencv # circular dependency
# --enable-libstagefright-h264 # not in AUR
# --enable-libxavs # does not build from AUR: /usr/bin/ld: common/i386/deblock.o: relocation R_X86_64_32 against ".rodata" can not be used when making a shared object; recompile with -fPIC
# # this stuff is not for linux/x86:
# --enable-avisynth # windows only
# --enable-dxva2 # windows only
# --enable-sram # not x86
# --enable-thumb # not x86
# '
# ./configure --help | perl -ne 'for(/--enable-([0-9a-z-]+)\s/) { if($ENV{DISABLED} !~ /^--enable-$_\b/m) { print " --enable-$_ \\\n"; } }' | sort -u
# EOF

# vim:set ts=2 sw=2 et:

And this is config.log when I build with ffmpeg 1.2.2:

all command lines:
--install=/home/user/Downloads/vapoursynth-plugin-d2vsource-git/pkg/vapoursynth-plugin-d2vsource-git/usr/lib/vapoursynth --extra-cxxflags=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4

---------------------------------
CXXFLAGS/LDFLAGS checking...
int main(void){ return 0;}
g++ conftest.cpp -o conftest -Wall -D__STDC_CONSTANT_MACROS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I. -I./vs -I./core -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -fPIC
0
int main(void){ return 0;}
g++ conftest.cpp -o conftest -Os -ffast-math -Wall -D__STDC_CONSTANT_MACROS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I. -I./vs -I./core -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -fPIC
0
int main(void){ return 0;}
g++ conftest.cpp -o conftest -Os -ffast-math -Wall -D__STDC_CONSTANT_MACROS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I. -I./vs -I./core -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -fPIC -fexcess-precision=fast
0

---------------------------------
checking for libavformat...
#include <libavformat/avformat.h>
int main(void){avformat_find_stream_info(0,0); return 0;}
g++ conftest.cpp -o conftest -Os -ffast-math -Wall -D__STDC_CONSTANT_MACROS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I. -I./vs -I./core -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -fPIC -fexcess-precision=fast -DQT_SHARED -I/usr/include/vapoursynth -I/usr/include/qt4 -I/usr/include/qt4/QtCore -lavformat -lavcodec -lvapoursynth
0

---------------------------------
checking for libavcodec...
#include <libavcodec/avcodec.h>
int main(void){avcodec_find_decoder(AV_CODEC_ID_NONE); return 0;}
g++ conftest.cpp -o conftest -Os -ffast-math -Wall -D__STDC_CONSTANT_MACROS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I. -I./vs -I./core -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -fPIC -fexcess-precision=fast -DQT_SHARED -I/usr/include/vapoursynth -I/usr/include/qt4 -I/usr/include/qt4/QtCore -lavformat -lavcodec -lvapoursynth
0
---------------------------------
setting
---------------------------------
CXX = g++
LD = g++
STRIP = strip
CXXFLAGS = -Os -ffast-math -Wall -D__STDC_CONSTANT_MACROS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I. -I./vs -I./core -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -fPIC -fexcess-precision=fast -DQT_SHARED -I/usr/include/vapoursynth -I/usr/include/qt4 -I/usr/include/qt4/QtCore
LDFLAGS = -shared -Wl,-Bsymbolic -fPIC
LIBS = -lavformat -lavcodec -lvapoursynth
SRCDIR = .
LIBNAME = libd2vsource.so
libdir = /home/user/Downloads/vapoursynth-plugin-d2vsource-git/pkg/vapoursynth-plugin-d2vsource-git/usr/lib/vapoursynth

I think there is a problem with libdir. I also noted that in file "configure" from d2vsource on line 74 the libdir is "/usr/local/lib/vapoursynth" but on my Arch linux vapoursynth libs are in "/usr/lib/vapoursynth". I changed that from "/usr/local/lib/vapoursynth" to "/usr/lib/vapoursynth", but something modifies it during compilation. After compilation libdir is again "/usr/local/lib/vapoursynth".

jackoneill
22nd August 2013, 16:14
Uh, according to the config.log you pasted, the libavformat and libavcodec checks succeeded.

opteronup
22nd August 2013, 20:06
I managed to compile d2vsource with ffmpeg 2.0.1.

Thanks, jackoneill.

The problem with git version of ffmpeg was that my vapoursynth was built with ffmpeg 1.2.1.
I didn't know that I must use the same ffmpeg for compile vapoursynth and d2vsource.
Then I tried to build vapoursynth with ffmpeg git but I also received errors.
And now I used ffmpeg 2.0.1 to compile vapoursynth and d2vsource and everything works fine.

Mystery Keeper
17th November 2013, 15:40
Please read several posts starting from this one:
http://forum.doom9.org/showthread.php?p=1653750#post1653750
Not sure, but it seems that d2v.Source hangs if requested a frame with number beyond the real source length.

handaimaoh
17th November 2013, 16:40
Yeah, the filter simply doesn't handle such a case. It seems to just assume that any frame number it is given is in the valid range. I'll send them a pull request real fast with a fix.

If you want a compile a test version to try the fix I have it here (https://github.com/handaimaoh/d2vsource ). If it works, I'll do the pull request up. Fix in the getframe functions was to add:

if (n >= d->d2v->frames.size()) {
n = d->d2v->frames.size() - 1;
}

Gavino
17th November 2013, 16:57
Yeah, the filter simply doesn't handle such a case. It seems to just assume that any frame number it is given is in the valid range.
Normally, the Avisynth cache filter (inserted automatically after all script filters) will ensure that all frame requests actually received by your filter are in range.

However, I guess that does not apply in Vapoursynth. (?)
(and it's still bad practice anyway for a source filter)

handaimaoh
17th November 2013, 17:01
Well it's just a quirk of the API like Myrsloik says. It's such a simple thing to check for though. And as he says, it's going to be changed.

I'm going to change it for r22, that's why I didn't notice all the crashes you were getting.

Also, I've fixed the check once again to be a ">=" as it was originally.

handaimaoh
17th November 2013, 17:58
I've created a pull request that fixes this issue and set it off.

StainlessS
17th November 2013, 18:03
n = (n<0) ? 0 : (n>= vi.num_frames) ? vi.num_frames - 1 : n; // Range limit frame n


In Avisynth speak.

handaimaoh
17th November 2013, 18:08
n = (n<0) ? 0 : (n>= vi.num_frames) ? vi.num_frames -1 : n; // Range limit frame n


In Avisynth speak.

Yeah that would work as well. I just forgot about using the VSVideoInfo. Probably more elegant that way too. Fixed up the pull request to be like this instead. Looks like:

// Range limit n
n = (n < 0) ? 0 : (n >= d->vi.numFrames) ? d->vi.numFrames - 1 : n;

Gavino
17th November 2013, 18:58
Probably more elegant that way too.Even more elegant is

n = min(vi.num_frames-1, max(0,n));

which is what the Avisynth Cache filter uses.

Daemon404
17th November 2013, 20:00
Please see: https://github.com/dwbuiten/d2vsource/pull/8#issuecomment-28655105

Mystery Keeper
17th November 2013, 21:39
In my opinion it is not wise to omit a guard based on assumption that it won't be needed in the next release. It might be broken later. Or some other software might misuse the library interface. Since the check is only made once per frame - 'tis a quite welcome and non-hindering precaution.

Daemon404
17th November 2013, 21:55
In my opinion it is not wise to omit a guard based on assumption that it won't be needed in the next release. It might be broken later. Or some other software might misuse the library interface. Since the check is only made once per frame - 'tis a quite welcome and non-hindering precaution.

Sorry, scattering basic sanity checks over every single plugin for VapourSynth, because it was once a bug in the core, is retarded. It negates the point of a framework. It's a hack.

Maybe I should also add a check to make sure water is wet too.

Myrsloik
17th November 2013, 22:04
In my opinion it is not wise to omit a guard based on assumption that it won't be needed in the next release. It might be broken later. Or some other software might misuse the library interface. Since the check is only made once per frame - 'tis a quite welcome and non-hindering precaution.

I don't intend to change the behavior back ever. This change is permanent since it makes sense and slightly simplifies plugin writing. It also means that not all plugins have to be littered with the same check again and again. Or more exactly as many different versions of the check as there are coders on doom9.

On the subject of backseat coders (which we've been having quite a few of recently), the correct answer is:
if (d->vi->numFrames && d->vi->numFrames <= n)
n = d->vi->numFrames -1;
Number of people posting in this this thread who got it right: 0

StainlessS
17th November 2013, 22:43
Best place for check on having video is in constructor, not getframe. Guess it means -ve n is ok then.


Number of people posting in this this thread who got it right: 0

Maybe so.

lansing
17th November 2013, 22:54
may we be expecting a 64bit version soon?

Daemon404
18th November 2013, 15:13
may we be expecting a 64bit version soon?

Done. As of Beta 6, the windows zip contains both 32bit and 64bit builds.

ChangeLog here (https://github.com/dwbuiten/d2vsource/compare/beta5...beta6).

I also SHOULD get to writing the d2v creation utility... life is busy. Meh. There's still this (https://gist.github.com/dwbuiten/5630882), though.

Mystery Keeper
19th November 2013, 19:53
This video (http://www.mediafire.com/?34e84dlmb707chd) makes VapourSynth crash near the end when loaded with D2V Source. Other d2v projects don't, so the bug most likely is not in VS.

Daemon404
23rd November 2013, 22:58
This video (http://www.mediafire.com/?34e84dlmb707chd) makes VapourSynth crash near the end when loaded with D2V Source. Other d2v projects don't, so the bug most likely is not in VS.

I'll look into it on Monday.

Mystery Keeper
29th November 2013, 02:23
Hope this crash report (http://paste.org.ru/?esc0vc) can help.

Daemon404
29th November 2013, 11:22
Hope this crash report (http://paste.org.ru/?esc0vc) can help.

Sorry, I've been busier this week than expected. I've filed an issue (https://github.com/dwbuiten/d2vsource/issues/9) for it, and will poke it this weekend (I am currently on a transatlantic flight after a week of work).

Mystery Keeper
30th November 2013, 17:24
The former crash report was for x64 version. Here's one for x32 (http://paste.org.ru/?0hl67n).

TurboPascal7
30th November 2013, 21:37
The former crash report was for x64 version. Here's one for x32 (http://paste.org.ru/?0hl67n).

Please google what x32 means.

Mystery Keeper
30th November 2013, 21:55
Please google what x32 means.
It was produced by x32 VirtualDub, using x32 VapourSynth, using x32 d2vsource. No idea why it sees all my physical memory, but if you compare memory addresses in the report - they are all 32bit long. Why do you even bother saying something insulting, not helping and irrelevant to the topic?

turbojet
30th November 2013, 22:20
While I understand what you mean Mystery Keeper, x86 is technically correct. x32 is a linux only ABI (https://en.wikipedia.org/wiki/X32_ABI)

Mystery Keeper
30th November 2013, 22:26
Yup. Got it. Or course, I meant 32-bit version.

Daemon404
1st December 2013, 23:57
Sorry, I've been busier this week than expected. I've filed an issue (https://github.com/dwbuiten/d2vsource/issues/9) for it, and will poke it this weekend (I am currently on a transatlantic flight after a week of work).

It's been 'fixed' in the git repo. I want to add one more thing before I make a new release, so wait a day or so.

Mystery Keeper
2nd December 2013, 00:25
Sure. As long as it takes. Thank you for your hard work!

Daemon404
5th December 2013, 18:14
New binaries.

Changelog here (https://github.com/dwbuiten/d2vsource/compare/beta6...beta7).

Mystery Keeper
5th December 2013, 18:44
No more crashes. Thank you!

Mystery Keeper
17th February 2014, 03:41
Running with rff=False does not change the framerate when it should.

Myrsloik
17th February 2014, 08:49
Running with rff=False does not change the framerate when it should.

Ignoring rff has no obvious framerate. It's only when you have a mode like force film where excess fields are discarded you get a nice ratio that makes sense.

Mystery Keeper
17th February 2014, 12:09
If video is not hard telecined and I tell the source filter to discard unneeded fields - isn't that an obvious case to change frame rate?

jackoneill
17th February 2014, 22:31
If video is not hard telecined and I tell the source filter to discard unneeded fields - isn't that an obvious case to change frame rate?

Ignoring rff is not the same thing as dgindex's "force film" option. Ignoring rff means you get exactly what is in the stream. That could be 100% 30 fps, or 100% 24 fps, or a mix. You don't know.

lansing
20th February 2014, 21:58
The multithread speedup really shocked me today. On my 720x480 dvd it ran at whopping 2800-3000fps! :eek:

When I change d2vsource's internal threads=1, speed drops to 1200-1300fps. Well, it's still a lot faster than mpeg2source in avisynth+ though, as it only ran at 530fps, don't know why.

Sangan
19th January 2016, 12:00
Hi, when I try to install (Mac OS 10.9), I get this error:$ make
g++ -Os -ffast-math -Wall -D__STDC_CONSTANT_MACROS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I. -I./vs -I./core -I/usr/local/Cellar/ffmpeg/2.8.5/include -I/usr/local/Cellar/vapoursynth/29/include/vapoursynth -I/usr/local/Cellar/zimg/2.0.2/include -c vs/applyrff.cpp -o vs/applyrff.o
vs/applyrff.cpp:239:87: error: use of undeclared identifier 'nfMakeLinear'
...out, "applyrff", rffInit, rffGetFrame, rffFree, fmSerial, nfMakeLinear, ...
^
1 error generated.
make: *** [vs/applyrff.o] Error 1

Is there a way to work this out?

Are_
19th January 2016, 12:38
Use non-git version. I think it is because you need vapoursynth git installed, but that line is said to be wrong in d2vsource code anyway. So you better wait for the fix (and install git vapoursynth), or install an older version.

bilditup1
2nd February 2016, 07:10
So, I was bored and wrote a cross-platform D2V parser and decoder for VapourSynth.

Current Version: Beta 7

Windows Binary: https://github.com/dwbuiten/d2vsource/releases/download/beta7/d2vsource_beta7.zip - built with GCC 4.8.2 (MinGW-w64 v3.0.0) and FFmpeg. Contains 32-bit and 64-bit binaries.
Source: https://github.com/dwbuiten/d2vsource/


Latest VapourSynth apparently needs updated versions of a few source filters, including d2v. Are you still maintaining this, Daemon? Has someone else taken it up?

jackoneill
30th April 2016, 15:39
https://github.com/dwbuiten/d2vsource/releases/tag/v1.0

Daemon404 is indisposed, so I compiled the list of changes in his stead:

* Fix opening of d2v files and video files with non-English characters in Windows.
* Attach various properties to the frames.
* Make ApplyRFF work fully according to the H.262 standard.
* Fix seeking directly to the last frame.
* Add some sanity checks for the settings section of d2v files.

STJAM
21st May 2016, 16:56
I apologize for my lack of understanding of pulldown but I believe Mystery Keeper is correct RFF option appears not to be working.
Adding fpsnum/fpsden like ffms2 or lsmas might be appropriate.

jackoneill
21st May 2016, 21:41
I apologize for my lack of understanding of pulldown but I believe Mystery Keeper is correct RFF option appears not to be working.
Adding fpsnum/fpsden like ffms2 or lsmas might be appropriate.

What exactly isn't working? If it's the "force film" feature you want, that doesn't exist in d2vsource.

STJAM
22nd May 2016, 20:16
The RFF mode seems to be stuck in forced film operation. RFF= True/False makes no difference. A video which is soft-telecined 100% Film it works great but for a video less than 100% lets say 99% a few frames may not be decimated. Consequently audio and video will be out of sync.
I have also found it necessary to add
c = core.std.AssumeFPS(clip = c, fpsnum=24000,fpsden=1001)
to all of my scripts something I have not normally found necessary with Beta 7. The durations and frame counts can be way off. I more then likely doing something wrong since no one else has chimed in. I will experiment some more and hopefully understand.

jackoneill
22nd May 2016, 21:27
The RFF mode seems to be stuck in forced film operation. RFF= True/False makes no difference. A video which is soft-telecined 100% Film it works great but for a video less than 100% lets say 99% a few frames may not be decimated. Consequently audio and video will be out of sync.
I have also found it necessary to add
c = core.std.AssumeFPS(clip = c, fpsnum=24000,fpsden=1001)
to all of my scripts something I have not normally found necessary with Beta 7. The durations and frame counts can be way off. I more then likely doing something wrong since no one else has chimed in. I will experiment some more and hopefully understand.

There is no "forced film" feature here. No fields will ever be discarded. Can you share a small video where the rff parameter makes no difference? Also one where the video duration/frame count is off. Or is it the duration of frames that is off? Either way, video samples are needed to determine what is wrong.

Keiyakusha
16th June 2016, 20:57
Hey guys, DGIndex (The GUI) has 2 options for YUV-RGB conversion

Inside the DGindex application their meaning is:
PC scale: Levels should be expanded for display
TV scale: Levels should NOT be expanded for display

In other words they do not flag the source content, but rather the operation that must be performed.

a) PC option selected in GUI writes YUVRGB_Scale=1 in D2V file (= Yes, convert levels)
b) TV option writes YUVRGB_Scale=0 in D2V file (= No, do not convert)

In case A, D2VSource reads the value 1 and flags the video as Fullrange, which leads to levels not being expanded in VS Editor preview
In case B, D2VSource reads the value 0 and flags the video as LimitedRange, which leads to the correct output. But this will not happen because you want PC to be selected in DGindex gui since most of the time you do want to expand levels.
So it assumes that the flag is for source content, not for the desired operation on it.

Maybe D2VSource should ignore this flag or at least reverse its behaviour? Since it is too late to fix DGIndex gui button text/meaning
Edit: or maybe this is VS Editor is doing something it is not supposed to? Anyway, I find the current behavior to be confusing.

jackoneill
16th June 2016, 21:50
Apparently you can ask mpeg2source to output RGB, so try that and see what it does with YUVRGB_Scale.

Keiyakusha
16th June 2016, 22:06
Apparently you can ask mpeg2source to output RGB, so try that and see what it does with YUVRGB_Scale.

If you ask for RGB24 output from mpeg2source:
YUVRGB_Scale=1 --> RGB with correct levels (they will be expanded)
YUVRGB_Scale=0 --> RGB with TV levels (dull image)
In other words it performs the same as DGindex GUI.

Regardless of this option, input is always assumed to be TVscale, just the operation on it differs. So if VS property reflects the current state of the video, current D2VSource behavior should be incorrect.

jackoneill
17th June 2016, 12:21
The metadata tells you what is in the stream. From that you deduce what you should do with it when you convert to RGB. The metadata does not tell you directly what to do.

Keiyakusha
17th June 2016, 14:12
The metadata tells you what is in the stream. From that you deduce what you should do with it when you convert to RGB. The metadata does not tell you directly what to do.

Exactly. But the flag in .D2V file has an opposite meaning. And D2VSourse insn't aware of it.

To sum it up:

we have limited range dvd
we set PC levels in DGindex gui because we want to preview it right and in case of mpeg2source RGB24 output - we want it to be converted right
In this case YUVRGB_Scale=1 is written in D2V file
D2VSource reads it and sets metadata "fullrange" (which is not)
VS Editor (and possibly other tools) reads metadata, sees fullrange and not performing levels expansion.

So I think whatever D2V source should ignore this D2V flag, or reverse its behavior.
Edit: Personally I like ignoring, because in this case unflagged YUV would probably be assumed TVscale, which is what we have most of the time - so less confusion.

Mystery Keeper
17th June 2016, 14:37
VS Editor (and possibly other tools) reads metadata, sees fullrange and not performing levels expansion.Starting with r6, VS Editor is using VS internal format conversion for preview.

Keiyakusha
17th June 2016, 14:45
Starting with r6, VS Editor is using VS internal format conversion for preview.

Not sure what do you mean. I am of course using r8. I haven't followed VS editor closely, but I believe how the conversion performed is irrelevant. As long as you honor metadata - you get wrong output because if DGindex is set up correctly, D2Vsource outputs limited range flagged as fullrange

BTW, we can also see in DGindex docs that the meaning of PC/TV scale option is not what D2Vsource expects.

Keiyakusha
17th June 2016, 15:18
Here (http://i.imgur.com/J3vp1RF.jpg) is a fancy picture for you

jackoneill
17th June 2016, 15:49
Here (http://i.imgur.com/J3vp1RF.jpg) is a fancy picture for you

Sorry. I thought you misunderstood things, but in fact DGIndex is thinking about this backwards, as explained in a section of the manual I hadn't read before.

hydra3333
19th June 2016, 03:03
Hello.
The first post shows
Windows Binary: https://github.com/dwbuiten/d2vsource/releases/download/beta7/d2vsource_beta7.zip - built with GCC 4.8.2 (MinGW-w64 v3.0.0) and FFmpeg. Contains 32-bit and 64-bit binaries.

https://github.com/dwbuiten/d2vsource/releases shows
Downloads
1.33 MB d2vsource-1.0-windows.zip https://github.com/dwbuiten/d2vsource/releases/download/v1.0/d2vsource-1.0-windows.zip

I should be using v1.0 ?

Reel.Deel
19th June 2016, 04:04
I should be using v1.0 ?

Yes. 1st post has not been updated.

cwk
25th July 2016, 20:14
When attempting to 'make' the D2V Witch on Ubuntu 14.04, I'm getting this error:

src/D2VWitch.cpp:88:59: error: no matching function for call to ‘std::vector<int>::erase(__gnu_cxx::__normal_iterator<const int*, std::vector<int> >)’
audio_ids.erase(audio_ids.cbegin() + j);
^
src/D2VWitch.cpp:88:59: note: candidates are:
In file included from /usr/include/c++/4.8/vector:69:0,
from src/D2VWitch.cpp:24:
/usr/include/c++/4.8/bits/vector.tcc:134:5: note: std::vector<_Tp, _Alloc>::iterator std::vector<_Tp, _Alloc>::erase(std::vector<_Tp, _Alloc>::iterator) [with _Tp = int; _Alloc = std::allocator<int>; std::vector<_Tp, _Alloc>::iterator = __gnu_cxx::__normal_iterator<int*, std::vector<int> >; typename std::_Vector_base<_Tp, _Alloc>::pointer = int*]
vector<_Tp, _Alloc>::
^
/usr/include/c++/4.8/bits/vector.tcc:134:5: note: no known conversion for argument 1 from ‘__gnu_cxx::__normal_iterator<const int*, std::vector<int> >’ to ‘std::vector<int>::iterator {aka __gnu_cxx::__normal_iterator<int*, std::vector<int> >}’
/usr/include/c++/4.8/bits/vector.tcc:146:5: note: std::vector<_Tp, _Alloc>::iterator std::vector<_Tp, _Alloc>::erase(std::vector<_Tp, _Alloc>::iterator, std::vector<_Tp, _Alloc>::iterator) [with _Tp = int; _Alloc = std::allocator<int>; std::vector<_Tp, _Alloc>::iterator = __gnu_cxx::__normal_iterator<int*, std::vector<int> >; typename std::_Vector_base<_Tp, _Alloc>::pointer = int*]
vector<_Tp, _Alloc>::
^
/usr/include/c++/4.8/bits/vector.tcc:146:5: note: candidate expects 2 arguments, 1 provided



Here's my ffmpeg and gcc version info:

chris@jupiter:/storage/code/vsynth/D2VWitch$ ffmpeg -version
ffmpeg version N-81036-g2b14204 Copyright (c) 2000-2016 the FFmpeg developers
built with gcc 4.8 (Ubuntu 4.8.4-2ubuntu1~14.04.3)
configuration: --enable-gpl --enable-version3 --enable-shared --enable-nonfree --enable-postproc --enable-libfaac --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora --enable-libvorbis --enable-libx264 --enable-libxvid
libavutil 55. 28.100 / 55. 28.100
libavcodec 57. 50.100 / 57. 50.100
libavformat 57. 42.100 / 57. 42.100
libavdevice 57. 0.102 / 57. 0.102
libavfilter 6. 47.100 / 6. 47.100
libswscale 4. 1.100 / 4. 1.100
libswresample 2. 1.100 / 2. 1.100
libpostproc 54. 0.100 / 54. 0.100


Any ideas?

jackoneill
25th July 2016, 20:37
Any ideas?

Yes. You're in the wrong thread. :P Anyway, I'll fix that shortly. In the meantime, replace "cbegin" with "begin".

xekon
4th December 2016, 20:22
I am new to vapoursynth, so for the last couple days I didnt know where the problem was originating, and Ive been reinstalling and tinkering trying to narrow it down. I believe its the d2v source plugin.

here is a screenshot of the output:
http://i1208.photobucket.com/albums/cc361/xekon/vsedit_zpsfhnn5j8x.jpg

same d2v file in Avisynth/AvsPmod using MPEG2Source:
http://i1208.photobucket.com/albums/cc361/xekon/avsp_zps5cuhuhkh.jpg

I read through the entire post here, hoping to figure it out on my own, and tried adding the ApplyRFF but it did not change the result.

import vapoursynth as vs
core = vs.get_core()
ret = core.d2v.Source(input=r'/media/sf_enc/005s.d2v')
ret = core.d2v.ApplyRFF(ret,d2v=r'/media/sf_enc/005s.d2v')
ret.set_output()

I have a attached a couple small samples, need anything else and I would be happy to test or provide it. Any help is greatly appreciated.

http://www.mediafire.com/file/1azgp6i418wbwj1/enc001.7z
http://www.mediafire.com/file/wl90qp7t4d1o518/enc005.7z

xekon
4th December 2016, 20:37
I just noticed that under my windows build of vapoursynth and vsedit that the d2v source plugin appears to be working:

http://i1208.photobucket.com/albums/cc361/xekon/vseditgood_zpsawdoobtw.jpg

So it is only a problem on my linux builds, I have tried on both Ubuntu server 16.04.1(x264 output) and Kubuntu 16.04.1

I really need this to work on my linux builds because I primarily use linux and I plan to use GNU Parallel to do parallel encoding across multiple machines.
Any help is greatly appreciated, please let me know if you need me to test or provide anything further, I am stumped at what could be the problem.

From a clean/fresh install of kubuntu-16.04.1-desktop-amd64 I used the following script to install Vapoursynth/Vsedit/Plugins:

before executing the script I installed prereqs:
sudo apt-get install openssh-server
sudo apt-get update
sudo apt-get dist-upgrade
sudo apt-get install git libxvidcore-dev mercurial cmake build-essential yasm libass-dev python3-pip python3-dev cython3 autoconf libtool pkg-config
sudo apt-get install libmagick++-dev qt5-default libfftw3-dev nasm libpng-dev libsndfile1-dev zlib1g-dev libopencv-dev ocl-icd-libopencl1 opencl-headers

chmod +x ~/VSInstall && ./VSInstall


https://sites.google.com/site/jakzite/VSInstall
http://pastebin.com/wDttQwHP

Are_
4th December 2016, 21:00
Did try your sample and encountered the same problem, I fixed it with rff=False:

import vapoursynth as vs
core = vs.get_core()

clip = core.d2v.Source("005s.d2v", rff=False)

clip.set_output()

xekon
4th December 2016, 21:06
YAY! I didn't realize RFF was applied by default, since the syntax looked the same between my windows and ubuntu builds.

I also didnt realize rff=False was a parameter, only that you could use the ApplyRFF.

This fixed it for me too, thank you so much, I really appreciate it!

jackoneill
9th December 2016, 12:08
I am new to vapoursynth, so for the last couple days I didnt know where the problem was originating, and Ive been reinstalling and tinkering trying to narrow it down. I believe its the d2v source plugin.

here is a screenshot of the output:

[...]

I have a attached a couple small samples, need anything else and I would be happy to test or provide it. Any help is greatly appreciated.

http://www.mediafire.com/file/1azgp6i418wbwj1/enc001.7z
http://www.mediafire.com/file/wl90qp7t4d1o518/enc005.7z

Using your two samples, I was unable to reproduce the garbled output. However, I did discover that ApplyRFF is broken in some way. Please test again with my fork (https://github.com/dubhater/d2vsource). It's possible the same bug manifested in a different way on your computer.

xekon
10th December 2016, 02:29
jackoneill, I tried your fork, upon loading the sample in VSedit that I provided here, and pressing F5 to generate a preview, it at first appeared to be a proper frame, no graphical anomilyies.

But if you use the seek bar to change a frames a few times, it appears I still get the garbled output.

Both your fork, and the d2vsource I was originally using, output good frames (no garbled picture) if I add 'rff=False' from this:
import vapoursynth as vs
core = vs.get_core()
ret = core.d2v.Source(input=r'/media/sf_enc/005t.d2v')
ret.set_output()

to this:

import vapoursynth as vs
core = vs.get_core()
ret = core.d2v.Source(input=r'/media/sf_enc/005t.d2v', rff=False)
ret.set_output()

could It be something to do with my install method?
I shared it here: http://pastebin.com/wDttQwHP
running kubuntu 16.04.1

jackoneill
10th December 2016, 14:07
jackoneill, I tried your fork, upon loading the sample in VSedit that I provided here, and pressing F5 to generate a preview, it at first appeared to be a proper frame, no graphical anomilyies.

But if you use the seek bar to change a frames a few times, it appears I still get the garbled output.

Both your fork, and the d2vsource I was originally using, output good frames (no garbled picture) if I add 'rff=False' from this:
import vapoursynth as vs
core = vs.get_core()
ret = core.d2v.Source(input=r'/media/sf_enc/005t.d2v')
ret.set_output()

to this:

import vapoursynth as vs
core = vs.get_core()
ret = core.d2v.Source(input=r'/media/sf_enc/005t.d2v', rff=False)
ret.set_output()

could It be something to do with my install method?
I shared it here: http://pastebin.com/wDttQwHP
running kubuntu 16.04.1
I don't see anything wrong in your install method.

Perhaps you should load the new d2vsource plugin directly, to be sure you're testing the right one.

Does it only happen with random access, or can you get the garbled images by moving one frame at a time with the right arrow? If yes, can you get the garbled images by using vspipe instead of vsedit?

vspipe 005t.py 005t.y4m --y4m

xekon
10th December 2016, 16:05
I just made sure to remove the original d2vsource:
sudo rm /usr/local/lib/libd2vsource.so
sudo rm /usr/local/lib/libd2vsource.la
sudo rm /usr/local/lib/vapoursynth/d2vscan.pl
sudo rm /usr/local/lib/vapoursynth/d2vsource.so

at this point I could no longer use core.d2v.Source()

I then reinstalled your fork, same result, I tried pressing the right arrow key, as i go frame by frame, roughly half of them display garbled.

I would be happy to explicitly load your plugin if you need, what is the code to do that?

wasnt sure how to view the output of 005t.y4m so i did this:
vspipe --y4m 005t.vpy - | x264 --demuxer y4m - --output 005t.mkv

here is a video without using rff=False, oddly the output is not garbled like it is in vapoursynth, there just appears to be some kind of interlacing visible(look at raditz black hair as the frame zooms out.)
http://www.mediafire.com/file/8g7285x2dlr99cc/005t.mkv

here is one using rff=False, this one does not show interlacing or garbled output in vsedit.
http://www.mediafire.com/file/58hi1wgvxil80ia/005t_rff_False.mkv

jackoneill
10th December 2016, 22:37
After updating everything, I figured it out. The problem is not in d2vsource but in VapourSynth's resizer, which vsedit uses to convert to RGB for display.

Just for future reference, this is how you load a plugin manually:

core.std.LoadPlugin("/some/place/libd2vsource.so")

xekon
10th December 2016, 22:43
Right on Jackoneill! way to go dude.

Mystery Keeper
10th December 2016, 23:08
After updating everything, I figured it out. The problem is not in d2vsource but in VapourSynth's resizer, which vsedit uses to convert to RGB for display.With resizer itself or with the way I use it?

jackoneill
11th December 2016, 11:04
With resizer itself or with the way I use it?

The resizer itself. vsedit is not required to reproduce the bug. See https://github.com/vapoursynth/vapoursynth/issues/256

xekon
30th January 2017, 03:13
so I'm trying to compile this as a DLL for use on windows, having never used mingw or msys before, was hoping somebody could help.
$ ./autogen.sh
./autogen.sh: line 3: autoreconf: command not found

JoeyMonco
30th January 2017, 03:40
You don't have autotools installed.

JoeyMonco
30th January 2017, 03:43
oh I just assumed that was part of the msys2 package, i will have to try and figure out how to get that installed then, thank you.

Or maybe your PATH isn't set up correctly? *shrug*

xekon
30th January 2017, 05:46
Thank you JoeyMonco, your posts steered me in the correct direction, after a couple google searches I found that you have to install autotools using pacman
now it gets stuck running configure:

$ ./configure
checking for VapourSynth... no
configure: error: Package requirements (vapoursynth) were not met:

No package 'vapoursynth' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables VapourSynth_CFLAGS
and VapourSynth_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

JoeyMonco
30th January 2017, 05:52
And the location to the PKG_CONFIG_PATH as the error states.

xekon
30th January 2017, 05:54
what do I need to set VapourSynth_CFLAGS and VapourSynth_LIBS to? seems that would be the easier route, no .pc file needed.

export VapourSynth_CFLAGS=what goes here?
export VapourSynth_LIBS=and what goes here?

jackoneill
30th January 2017, 12:50
what do I need to set VapourSynth_CFLAGS and VapourSynth_LIBS to? seems that would be the easier route, no .pc file needed.

export VapourSynth_CFLAGS=what goes here?
export VapourSynth_LIBS=and what goes here?

For the CFLAGS you need the folder where VapourSynth.h is. For the LIBS you just need a harmless string to make configure happy (it can't be empty).


VapourSynth_CFLAGS="-I/some/folder"
VapourSynth_LIBS="-L."

xekon
30th January 2017, 14:23
thank you so much jackoneill, i got your other post showing me the workaround as well.
but for the sake of learning I would still like to try building this, I made those changes and have successfully ran ./configure now

now when I tried to run 'make' i was getting TONS of 'undefined reference to `std::__cxx11::basic_string' messages.
I resolved those by opening all the .cpp .hpp files in the d2vsource folder and adding the following to the top of each file:
#define _GLIBCXX_USE_CXX11_ABI 0


Here is my current install routine:
1. msys2-x86_64-20161025.exe http://msys2.github.io/
install to c:\msys64

2. win-builds-1.5.0.exe http://win-builds.org/doku.php/download_and_installation_from_windows
select "Cygwin or MSYS" and "x86_64", on the next page click process in the top right corner.

3. download d2vsource-master and vapoursynth-master, extract and place into C:\msys64\
you should have the following directory structure:
C:\msys64\d2vsource-master\autogen.sh
C:\msys64\vapoursynth-master\include\VapourSynth.h

4. open the MSYS2 MinGW 64-bit shell, enter the following to install autotools:

pacman -S make pkgconfig autoconf automake autogen libtool mingw-w64-x86_64-gcc
pacman -Syuu


5. update your "PKG_CONFIG_PATH", to view its current value enter:
echo ${PKG_CONFIG_PATH}

update it to include win-builds files, also set vapoursynth flags/libs:

export PKG_CONFIG_PATH="/mingw64/lib/pkgconfig:/mingw64/share/pkgconfig:/opt/windows_64/lib64/pkgconfig"
export VapourSynth_CFLAGS="-I/vapoursynth-master/include"
export VapourSynth_LIBS="-L."


6. navigate to the d2vsource folder and build the project:

cd /d2vsource-master
./autogen.sh
./configure
make
make install

Pat357
2nd February 2017, 20:14
pacman -S mingw-w64-x86_64-gcc
should've been be installed with GCC, but maybe you have another version hanging around ?

If the above doesn't work, try
pacman -S --force mingw-w64-x86_64-gcc

xekon
3rd February 2017, 02:09
Thank you Pat357, I tried the force command as you showed, and it reinstalled that package, but I am still getting the same errors, is there a way to "force" when running make? something like: "make --force mingw64"?
looking at my shell prompt I can see its in MINGW64 mode, it shows it on the end of my command prompt in purple, just before the directory im currently in.

I updated my current complete install routine in my previous post, have uninstalled and reinstalled a few times so far: https://forum.doom9.org/showpost.php?p=1795225&postcount=155

here is the error message I am getting when running 'make'

$ make
CXX src/core/compat.lo
CXX src/core/d2v.lo
CXX src/core/decode.lo
CXX src/vs/applyrff.lo
CXX src/vs/d2vsource.lo
CXX src/vs/directrender.lo
CXX src/vs/vapoursynth.lo
CXXLD libd2vsource.la
src/core/.libs/compat.o:compat.cpp:(.text+0xde): undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)'
src/core/.libs/d2v.o:d2v.cpp:(.text+0x2c2): undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)'
src/core/.libs/d2v.o:d2v.cpp:(.text+0x3c5): undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)'
src/core/.libs/d2v.o:d2v.cpp:(.text+0x491): undefined reference to `operator delete[](void*, unsigned long long)'
src/core/.libs/d2v.o:d2v.cpp:(.text+0x4e1): undefined reference to `operator delete(void*, unsigned long long)'
src/core/.libs/d2v.o:d2v.cpp:(.text+0x11f1): undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)'
src/core/.libs/d2v.o:d2v.cpp:(.text+0x1b56): undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)'
src/core/.libs/d2v.o:d2v.cpp:(.text+0x1be1): undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)'
src/core/.libs/d2v.o:d2v.cpp:(.text+0x1bf7): undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)'
src/core/.libs/d2v.o:d2v.cpp:(.text+0x1c0d): undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)'
src/core/.libs/d2v.o:d2v.cpp:(.text+0x1c23): more undefined references to `std::__throw_out_of_range_fmt(char const*, ...)' follow
src/core/.libs/d2v.o:d2v.cpp:(.text+0x1cf4): undefined reference to `operator delete[](void*, unsigned long long)'
src/core/.libs/decode.o:decode.cpp:(.text+0x3cc): undefined reference to `operator delete(void*, unsigned long long)'
src/core/.libs/decode.o:decode.cpp:(.text+0x3f4): undefined reference to `operator delete(void*, unsigned long long)'
src/core/.libs/decode.o:decode.cpp:(.text+0x1034): undefined reference to `operator delete(void*, unsigned long long)'
src/vs/.libs/applyrff.o:applyrff.cpp:(.text+0x76b): undefined reference to `operator delete(void*, unsigned long long)'
src/vs/.libs/applyrff.o:applyrff.cpp:(.text+0x58): undefined reference to `operator delete(void*, unsigned long long)'
src/vs/.libs/directrender.o:directrender.cpp:(.text+0x24): more undefined references to `operator delete(void*, unsigned long long)' follow
collect2.exe: error: ld returned 1 exit status
make: *** [Makefile:502: libd2vsource.la] Error 1

also here is the output from checking gcc version gcc -v:
xekon@xekon-PC MINGW64 /d2vsource-master
$ gcc -v
Using built-in specs.
COLLECT_GCC=C:\msys64\mingw64\bin\gcc.exe
COLLECT_LTO_WRAPPER=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-6.3.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
--target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap
--with-arch=x86-64 --with-tune=generic --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared --enable-static --enable-libatomic
--enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug
--disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry
--disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64
--with-isl=/mingw64 --with-pkgversion='Rev1, Built by MSYS2 project' --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld
Thread model: posix
gcc version 6.3.0 (Rev1, Built by MSYS2 project)

jackoneill
6th February 2017, 21:59
Does it help to know that those missing symbols are part of the standard C++ library (libstdc++)? I have no idea how to fix the problem.

Pat357
7th February 2017, 18:24
Since some important bugs have been fixed in d2vsource since v1.0 was released,
I've compiled both ffmpeg and d2vsource from git (6021968)

See https://github.com/dwbuiten/d2vsource/commits/master for changes since d2vsource v1.0

Commits on Dec 24, 2016

@dwbuiten

Merge pull request #31 from dubhater/master
dwbuiten committed on GitHub on 24 Dec 2016

Commits on Dec 9, 2016

@dubhater

applyrff: Make it actually work

dubhater committed on 9 Dec 2016
Commits on Aug 13, 2016

@dubhater

d2vsource: Avoid double free

dubhater committed on 13 Aug 2016
Commits on Aug 9, 2016

@dubhater

Remove outdated comment
dubhater committed on 9 Aug 2016

Commits on Jul 25, 2016

@dwbuiten

Merge pull request #29 from dubhater/master

dwbuiten committed on GitHub on 25 Jul 2016
Commits on Jun 21, 2016

@dubhater

d2vsource: Fix inverted _ColorRange frame property

dubhater committed on 21 Jun 2016


Here are the latest windows binaries (x86 & x64) compiled under Mingw64 using GCC v6.3.0 :

http://www33.zippyshare.com/v/4GGpY6Yb/file.html

Let me know if you have problems with this version.
All credits go to dwbuiten & dubhater for all the coding.

Pat357
7th February 2017, 19:16
here is the error message I am getting when running 'make'

I agree that your problem has to do with libstdc++.a.
Can you find this file in /ming64 ? If no were's it on your system ?

Open a MSYS2 console and do pacman -Syu to update everything, just to be sure.

I've seen similar errors after this lib got updated and you use other libs which were compiled before the update i.e 2 different versions can give this error.
Make sure you recompile ffmpeg and ALL it's libs to make sure they all use the latest libstdc++.a (you can temporally rename libstdc++.dll.a)
How do you configure ffmpeg ?

further set LIBS="-lstdc++" right before configure (for d2vsource) like this :
./autogen.sh
[[ -f Makefile || -f config.log ]] && make distclean
LDFLAGS+=" -static-libgcc -static-libstdc++" CXXFLAGS+=" -static-libgcc" \
LIBS="-lstdc++" ./configure ## (yes on the same line)
make
make install

Try this and let me know.
You can also try my compile ;-)

Daemon404
19th February 2017, 20:28
Binaries for 1.1 are in the OP.

Somehow I'm not dead.

KingLir
19th February 2017, 23:29
Binaries for 1.1 are in the OP.


Thanks! Can't build on macOS, getting this after autogen and configure:

$ make
CXX src/core/compat.lo
CXX src/core/d2v.lo
CXX src/core/decode.lo
src/core/decode.cpp:450:45: warning: 'codec' is deprecated
[-Wdeprecated-declarations]
if (dctx->fctx->streams[i]->codec->codec_type == AVMEDIA...
^
/usr/local/Cellar/ffmpeg/3.2.4/include/libavformat/avformat.h:893:21: note:
'codec' has been explicitly marked deprecated here
AVCodecContext *codec;
^
src/core/decode.cpp:491:13: warning: 'avcodec_decode_video2' is deprecated
[-Wdeprecated-declarations]
avcodec_decode_video2(dctx->avctx, out, &av_ret, &dctx->inpkt);
^
/usr/local/Cellar/ffmpeg/3.2.4/include/libavcodec/avcodec.h:4812:5: note:
'avcodec_decode_video2' has been explicitly marked deprecated here
int avcodec_decode_video2(AVCodecContext *avctx, AVFrame *picture,
^
/usr/local/Cellar/ffmpeg/3.2.4/include/libavcodec/avcodec.h:1578:16: warning:
'convergence_duration' is deprecated [-Wdeprecated-declarations]
typedef struct AVPacket {
^
/usr/local/Cellar/ffmpeg/3.2.4/include/libavcodec/avcodec.h:1630:13: note:
'convergence_duration' has been explicitly marked deprecated here
int64_t convergence_duration;
^
src/core/decode.cpp:510:25: warning: 'avcodec_decode_video2' is deprecated
[-Wdeprecated-declarations]
int r = avcodec_decode_video2(dctx->avctx, out, &av_ret...
^
/usr/local/Cellar/ffmpeg/3.2.4/include/libavcodec/avcodec.h:4812:5: note:
'avcodec_decode_video2' has been explicitly marked deprecated here
int avcodec_decode_video2(AVCodecContext *avctx, AVFrame *picture,
^
/usr/local/Cellar/ffmpeg/3.2.4/include/libavcodec/avcodec.h:1578:16: warning:
'convergence_duration' is deprecated [-Wdeprecated-declarations]
typedef struct AVPacket {
^
/usr/local/Cellar/ffmpeg/3.2.4/include/libavcodec/avcodec.h:1630:13: note:
'convergence_duration' has been explicitly marked deprecated here
int64_t convergence_duration;
^
/usr/local/Cellar/ffmpeg/3.2.4/include/libavcodec/avcodec.h:1578:16: warning:
'convergence_duration' is deprecated [-Wdeprecated-declarations]
typedef struct AVPacket {
^
/usr/local/Cellar/ffmpeg/3.2.4/include/libavcodec/avcodec.h:1630:13: note:
'convergence_duration' has been explicitly marked deprecated here
int64_t convergence_duration;
^
6 warnings generated.
CXX src/vs/applyrff.lo
src/vs/applyrff.cpp:192:36: error: expected expression
data->fields.push_back({ i, Progressive });
^
src/vs/applyrff.cpp:193:36: error: expected expression
data->fields.push_back({ i, Progressive });
^
src/vs/applyrff.cpp:196:40: error: expected expression
data->fields.push_back({ i, Progressive });
^
src/vs/applyrff.cpp:197:40: error: expected expression
data->fields.push_back({ i, Progressive });
^
src/vs/applyrff.cpp:200:44: error: expected expression
data->fields.push_back({ i, Progressive });
^
src/vs/applyrff.cpp:201:44: error: expected expression
data->fields.push_back({ i, Progressive });
^
src/vs/applyrff.cpp:207:36: error: expected expression
data->fields.push_back({ i, tff ? Top : Bottom });
^
src/vs/applyrff.cpp:208:36: error: expected expression
data->fields.push_back({ i, tff ? Bottom : Top });
^
src/vs/applyrff.cpp:211:40: error: expected expression
data->fields.push_back({ i, tff ? Top : Bottom });
^
9 errors generated.

Cary Knoop
20th February 2017, 03:30
New version works great!

I have to remind myself to take care when filenames contain spaces.

jackoneill
20th February 2017, 12:56
Thanks! Can't build on macOS, getting this after autogen and configure:
src/vs/applyrff.cpp:211:40: error: expected expression
data->fields.push_back({ i, tff ? Top : Bottom });
^
9 errors generated.

Oops. Try this:

make clean && ./configure CXXFLAGS='-std=c++11' && make

KingLir
20th February 2017, 13:07
Oops. Try this:

make clean && ./configure CXXFLAGS='-std=c++11' && make


Thanks! Works.

sl1pkn07
20th May 2018, 22:17
this is ok with the latest ffmpeg 4?


diff --git a/src/core/d2v.hpp b/src/core/d2v.hpp
index f87b1a0..ecdae78 100644
--- a/src/core/d2v.hpp
+++ b/src/core/d2v.hpp
@@ -68,7 +68,7 @@ static const int idct_algo_conv[8] = {
FF_IDCT_AUTO,
FF_IDCT_AUTO,
FF_IDCT_AUTO,
- FF_IDCT_XVIDMMX,
+ FF_IDCT_XVID,
FF_IDCT_SIMPLEMMX
};

diff --git a/src/core/decode.cpp b/src/core/decode.cpp
index b563697..11a0fef 100644
--- a/src/core/decode.cpp
+++ b/src/core/decode.cpp
@@ -242,12 +242,6 @@ decodecontext *decodeinit(d2vcontext *dctx, int threads, string& err)
/* Set the thread count. */
ret->avctx->thread_count = threads;

- /*
- * Enable EMU_EDGE so that we can use buffers that are
- * not padded by 32 pixels.
- */
- ret->avctx->flags |= CODEC_FLAG_EMU_EDGE;
-
/* Use refcounted frames. */
ret->avctx->refcounted_frames = 1;

sl1pkn07
2nd June 2018, 21:31
done in upstream

lansing
24th July 2018, 23:35
Can this plugin works with D2VWitch to index video like this so I can skip a step?

core.d2v.Source(r"my_video.ts")

Also I have problem opening d2v made by dgindex when the video path in the d2v is non English because the dgindex d2v is in ANSI encoding instead of utf-8.

jackoneill
25th July 2018, 12:24
Can this plugin works with D2VWitch to index video like this so I can skip a step?

core.d2v.Source(r"my_video.ts")


That would be nice. It's on my to do list.


Also I have problem opening d2v made by dgindex when the video path in the d2v is non English because the dgindex d2v is in ANSI encoding instead of utf-8.

That's unlikely to be fixed in any way. Does DGIndex have a feature you need that D2V Witch doesn't have?

lansing
25th July 2018, 15:02
That's unlikely to be fixed in any way. Does DGIndex have a feature you need that D2V Witch doesn't have?

Yeah I know this is a dgindex problem that have been existed since the beginning. I just wanna see if it would be easy enough to fix it on this end.

ChaosKing
25th July 2018, 16:44
You don't have to use the full path in d2v. Just uncheck "Use full paths" in options in dgindex and only the file name will be stored.

lansing
25th July 2018, 21:34
You don't have to use the full path in d2v. Just uncheck "Use full paths" in options in dgindex and only the file name will be stored.

The problem is still there if my file name is non English.

lansing
26th July 2019, 09:57
I'm trying to stress my new Ryzen 3900x with this filter, but I was never able to get cpu utilization over 25%. And setting threads count to 10 is 200fps faster than leaving it at auto, is there something wrong?

Selur
17th July 2021, 15:28
Trying to build d2vwitch using:
### d2vwitch
if echo "$args" | grep -q -i -w -E 'all|d2vwitch'
then
mkdir build
cd build

top="$PWD"
export PATH="$top:$PATH"
export PKG_CONFIG_PATH="$top/libs/lib/pkgconfig"

git clone --depth 1 https://github.com/dubhater/D2VWitch
git clone --depth 1 https://github.com/FFmpeg/FFmpeg
git clone --depth 1 https://github.com/vapoursynth/vapoursynth

build_nasm

cd FFmpeg
./configure --prefix="$top/libs" \
--enable-gpl \
--enable-version3 \
--disable-encoders \
--disable-muxers \
--disable-outdevs \
--disable-programs \
--disable-doc \
--disable-debug \
--disable-xlib \
--disable-sdl2 \
--extra-cflags="-ffunction-sections -fdata-sections"
make $MAKEFLAGS
make install

cd ../D2VWitch
autoreconf -if
vapoursynth_CFLAGS="-I../vapoursynth/include" \
vapoursynth_LIBS=" " \
LDFLAGS="-Wl,--gc-sections" \

./configure
make $MAKEFLAGS
strip d2vwitch
cp -f d2vwitch ../..
cd ..

cat <<EOL >../d2vwitch-sources.txt
https://github.com/dubhater/D2VWitch
$(git -C D2VWitch rev-parse HEAD)

https://github.com/vapoursynth/vapoursynth
$(git -C vapoursynth rev-parse HEAD)

https://github.com/FFmpeg/FFmpeg
$(git -C FFmpeg rev-parse HEAD)
EOL

cd ..
rm -rf build
fi
see: https://github.com/Selur/HybridDeploy

problem is, the build stops at:
checking for vapoursynth... no
configure: error: Package requirements (vapoursynth) were not met:

No package 'vapoursynth' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables vapoursynth_CFLAGS
and vapoursynth_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.


Any idea what am I missing? This did work before,..

Cu Selur

jackoneill
18th July 2021, 20:00
I think you need to put something that is not whitespace in vapoursynth_LIBS. „-L.” should be harmless.

Selur
19th July 2021, 04:48
Thanks for the suggestion, but using "-L." sadly didn't change much:
+ cd ../D2VWitch
+ autoreconf -if
configure.ac:17: installing './compile'
configure.ac:10: installing './config.guess'
configure.ac:10: installing './config.sub'
configure.ac:6: installing './install-sh'
configure.ac:6: installing './missing'
Makefile.am: installing './depcomp'
+ vapoursynth_CFLAGS=-I../vapoursynth/include
+ vapoursynth_LIBS=-L.
+ LDFLAGS=-Wl,--gc-sections
+ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for g++... g++
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of g++... gcc3
checking for grep that handles long lines and -e... /bin/grep
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... no
checking for _LARGEFILE_SOURCE value needed for large files... no
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for vapoursynth... no
configure: error: Package requirements (vapoursynth) were not met:

No package 'vapoursynth' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables vapoursynth_CFLAGS
and vapoursynth_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
full log: https://rentry.co/wwf6b
it stops with the same error. :(

Cu Selur

jackoneill
21st July 2021, 20:38
cd ../D2VWitch
autoreconf -if
vapoursynth_CFLAGS="-I../vapoursynth/include" \
vapoursynth_LIBS=" " \
LDFLAGS="-Wl,--gc-sections" \

./configure


Perhaps you need a backslash on the empty line as well. Or just put the assignments and the call to configure on the same line. (And use vapoursynth_LIBS="-L.")

Selur
22nd July 2021, 15:33
cd ../D2VWitch
autoreconf -if
vapoursynth_CFLAGS="-I../vapoursynth/include" vapoursynth_LIBS="-L." LDFLAGS="-Wl,--gc-sections" ./configure
make $MAKEFLAGS

get's me further but still fails, see: https://paste.ee/p/7KJ4O

jackoneill
23rd July 2021, 16:04
I guess it's time to update that code to match the changes in ffmpeg.

Jukus
12th October 2021, 10:35
https://github.com/dwbuiten/d2vsource/issues/48