Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > VapourSynth

Reply
 
Thread Tools Search this Thread Display Modes
Old 20th November 2012, 02:00   #41  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,907
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.
Guest is offline   Reply With Quote
Old 20th November 2012, 03:10   #42  |  Link
Daemon404
Registered User
 
Join Date: Mar 2005
Posts: 128
Quote:
Originally Posted by neuron2 View Post
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.
Daemon404 is offline   Reply With Quote
Old 20th November 2012, 04:15   #43  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,907
Quote:
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'.

Quote:
Originally Posted by Daemon404 View Post
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?

Quote:
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.

Last edited by Guest; 20th November 2012 at 04:32.
Guest is offline   Reply With Quote
Old 20th November 2012, 09:50   #44  |  Link
06_taro
soy sauce buyer
 
Join Date: Mar 2010
Location: United Kingdom
Posts: 164
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.

Last edited by 06_taro; 20th November 2012 at 09:59.
06_taro is offline   Reply With Quote
Old 20th November 2012, 10:14   #45  |  Link
Revgen
Registered User
 
Join Date: Sep 2004
Location: Near LA, California, USA
Posts: 1,545
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.
__________________
Pirate: Now how would you like to die? Would you like to have your head chopped off or be burned at the stake?

Curly: Burned at the stake!

Moe: Why?

Curly: A hot steak is always better than a cold chop.
Revgen is offline   Reply With Quote
Old 20th November 2012, 15:14   #46  |  Link
Daemon404
Registered User
 
Join Date: Mar 2005
Posts: 128
Quote:
Originally Posted by neuron2 View Post
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:

Code:
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.

Quote:
Originally Posted by neuron2 View Post
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?

Quote:
Originally Posted by Revgen View Post
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.

Quote:
Originally Posted by Revgen View Post
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.

Last edited by Daemon404; 20th November 2012 at 15:40. Reason: Clarifications
Daemon404 is offline   Reply With Quote
Old 20th November 2012, 16:00   #47  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,907
Quote:
Originally Posted by Daemon404 View Post
Code:
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.

Quote:
I still do not intend to implement Force FILM.
Why not? It's proven to be quite useful for several types of streams.

Quote:
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.

Last edited by Guest; 20th November 2012 at 16:04.
Guest is offline   Reply With Quote
Old 20th November 2012, 16:12   #48  |  Link
Daemon404
Registered User
 
Join Date: Mar 2005
Posts: 128
Quote:
Originally Posted by neuron2 View Post
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:

Code:
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!

Quote:
Originally Posted by neuron2 View Post
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).

Quote:
Originally Posted by neuron2 View Post
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.

Last edited by Daemon404; 20th November 2012 at 16:12. Reason: s/;/:/
Daemon404 is offline   Reply With Quote
Old 9th December 2012, 02:38   #49  |  Link
Daemon404
Registered User
 
Join Date: Mar 2005
Posts: 128
Just posted Beta4.

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

Full changelog here.

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

URLs in OP.

Last edited by Daemon404; 9th December 2012 at 05:25.
Daemon404 is offline   Reply With Quote
Old 9th December 2012, 04:43   #50  |  Link
Revgen
Registered User
 
Join Date: Sep 2004
Location: Near LA, California, USA
Posts: 1,545
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.
__________________
Pirate: Now how would you like to die? Would you like to have your head chopped off or be burned at the stake?

Curly: Burned at the stake!

Moe: Why?

Curly: A hot steak is always better than a cold chop.

Last edited by Revgen; 9th December 2012 at 04:51.
Revgen is offline   Reply With Quote
Old 9th December 2012, 05:20   #51  |  Link
Daemon404
Registered User
 
Join Date: Mar 2005
Posts: 128
Quote:
Originally Posted by Revgen View Post
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 is offline   Reply With Quote
Old 11th December 2012, 04:12   #52  |  Link
Daemon404
Registered User
 
Join Date: Mar 2005
Posts: 128
Quote:
Originally Posted by Daemon404 View Post
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).
Daemon404 is offline   Reply With Quote
Old 13th January 2013, 23:16   #53  |  Link
mikewando
Registered User
 
Join Date: Nov 2010
Posts: 11
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.

Last edited by mikewando; 13th January 2013 at 23:26.
mikewando is offline   Reply With Quote
Old 14th January 2013, 00:29   #54  |  Link
Daemon404
Registered User
 
Join Date: Mar 2005
Posts: 128
Quote:
Originally Posted by mikewando View Post
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.
Daemon404 is offline   Reply With Quote
Old 14th January 2013, 00:58   #55  |  Link
mikewando
Registered User
 
Join Date: Nov 2010
Posts: 11
Quote:
Originally Posted by Daemon404 View Post
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.
mikewando is offline   Reply With Quote
Old 26th February 2013, 16:55   #56  |  Link
Daemon404
Registered User
 
Join Date: Mar 2005
Posts: 128
Beta5 Released: http://chromashift.org/vs/d2vsource_beta5.zip
ChangeLog here.

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

Quote:
Originally Posted by mikewando View Post
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.
Daemon404 is offline   Reply With Quote
Old 26th February 2013, 17:05   #57  |  Link
paradoxical
Guest
 
Posts: n/a
Thanks for this! Quick question: Have you fixed the limitation about last frame not decoded? If not check out this starting at line 417. Or I can probably try to make a patch for you.
  Reply With Quote
Old 26th February 2013, 17:18   #58  |  Link
Daemon404
Registered User
 
Join Date: Mar 2005
Posts: 128
Quote:
Originally Posted by paradoxical View Post
Thanks for this! Quick question: Have you fixed the limitation about last frame not decoded? If not check out this starting at line 417. Or I can probably try to make a patch for you.
I know. I've just been too lazy to deal with libavcodec's tomfoolery...
Daemon404 is offline   Reply With Quote
Old 26th February 2013, 17:37   #59  |  Link
paradoxical
Guest
 
Posts: n/a
Quote:
Originally Posted by Daemon404 View Post
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.
  Reply With Quote
Old 26th February 2013, 19:02   #60  |  Link
paradoxical
Guest
 
Posts: n/a
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.
  Reply With Quote
Reply

Tags
d2v, dgindex, vapoursynth

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 17:18.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, vBulletin Solutions Inc.