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. |
10th September 2012, 13:40 | #103 | Link |
Oz of the zOo
Join Date: May 2005
Posts: 208
|
Regarding updating of avisynth plugins: as far as I can see, it's possible to make them native vapoursynth plugins by providing _VapourSynthPluginInit in addition to _AvisynthPluginInit2, so what are the benefits in general?
|
10th September 2012, 13:43 | #104 | Link | |
契約者
Join Date: Jun 2008
Posts: 1,576
|
I don't understand why you need DGIndexNV if you have FFMS2 (which is free and awesome). if you have not very ancient CPU, nvidia decoding is not faster at all and not safe with more than one instance (or if you use some memory eating gpu filters). What are other possible benefits?
Quote:
On the other hand DGMPEGDec Is what I'd like to see too. Not that it is irreplaceable, I'm just so used to it... Last edited by Keiyakusha; 10th September 2012 at 13:52. |
|
10th September 2012, 13:51 | #105 | Link | |
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
Quote:
- interact directly with the VS thread pool (= potentially better multithreading performance, may require some work on the plugin though) - support high bitdepth colorspaces (and some other exotics such as planar RGB) natively - store arbitrary per-frame metadata (such as VFR timestamps) without having to resort to hiding it in obscure ways (the decomb/tfm hinting information is one example of plugins doing that) Last edited by TheFluff; 10th September 2012 at 13:53. |
|
10th September 2012, 13:56 | #107 | Link | |
Professional Code Monkey
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,548
|
Quote:
1. Several filters use planar YUV422 internally and have to pack and unpack. These could quite easily be changed to directly accept planar YUV for a small speedup for YUY2. 2. Many of the same filters in category one are quite general and probably could be extended to full resolution planar YUV support at least with a bit more effort. 3. Native filters can select their best threading model. For example a filter like ColorMatrix probably never updates its conversion tables after initialization so they're safe to share. This means that the filter can be run on several frames in parallel. 4. If you lay off the inline assembler (you can still use yasm+that magic x264 asm.inc file) your plugins will work and compile on every civilized desktop OS from a single codebase. 5. No more hacks.
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet |
|
10th September 2012, 13:59 | #108 | Link | |
Registered User
Join Date: Mar 2012
Location: Texas
Posts: 1,664
|
Quote:
Futhermore, I have a handfull of blu-rays that the movie is cut up into a 100+ segments and it's very easy just to drag the mpls onto DGIndexNV and index the entire movie. BTW I do have an ancient CPU (not for long) . |
|
10th September 2012, 14:11 | #109 | Link |
契約者
Join Date: Jun 2008
Posts: 1,576
|
Hmm, didn't know that. I had impression that it only can work with single segment at one time or something like that. Maybe will try it someday.(I, as many others I guess, just remux the movie first, to make it one) Interlaced streams maybe true. I never saw any interlaced bluray though (or tv broadcasts that is not mpeg2)
Last edited by Keiyakusha; 10th September 2012 at 14:33. |
10th September 2012, 14:40 | #111 | Link |
Guest
Join Date: Jan 2002
Posts: 21,901
|
Also remember that DGDecNV can use the GPU for deinterlacing/resizing and that can bring a substantial speedup. Sure it's not QTGMC but the quality is pretty good and so offers a useful performance point. DGDecNV can load multiple files (including automatically from an MPLS playlist file); it's the old DGAVCDec that could open only one file.
Regarding DGMPGDec, it contains an internal Invoke call, which I assume is the source of the problem with Vapoursynth. I'd like to understand the problem better though. Is it only an issue for 1088 streams that get cropped automatically to 1080? Obviously we can't enable cropping in the GUI as that will trigger an Invoke("crop") in DGDecode, but if we have a non-1088 stream with no cropping enabled in the GUI does everything work? Last edited by Guest; 10th September 2012 at 14:53. |
10th September 2012, 15:38 | #112 | Link |
Registered User
Join Date: Mar 2012
Location: Texas
Posts: 1,664
|
I tried DGMPGDec with a true 1080 stream (cropping disabled) and it gave me the following error:
Code:
Invoke not fully implemented, tried to call: crop but I will pretend it doesn'texist Avisynth Error: escaped IScriptEnvironment::NotFound exceptions are non-recoverable, crashing... *edit* Just to be sure I tried DGMPGDec (same settings as before) with both a NTSC DVD stream and a 720p60 stream and they both worked. Last edited by Reel.Deel; 10th September 2012 at 16:12. |
10th September 2012, 16:21 | #114 | Link | |
Moderator
Join Date: Feb 2005
Location: Spain
Posts: 6,890
|
Just yesterday I make some test with r3.
With r5 (I never can download r4): Quote:
Reload r3 and work fine.
__________________
BeHappy, AviSynth audio transcoder. |
|
10th September 2012, 16:32 | #116 | Link | |
Professional Code Monkey
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,548
|
Quote:
If not I have no idea why you're getting that error since no dependencies have changed.
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet |
|
10th September 2012, 16:41 | #117 | Link | |
Guest
Join Date: Jan 2002
Posts: 21,901
|
No, it's coded as 1088. DGIndex hides that from you. It it were not coded as 1088, then the Invoke() call would not be made. If you are still adamant that it is 1080, then please post a sample.
Quote:
|
|
10th September 2012, 17:45 | #119 | Link |
soy sauce buyer
Join Date: Mar 2010
Location: United Kingdom
Posts: 164
|
Did some tests, and *.avs.MPEG2Source(d2v=r"d2vpath") works for SD sources.
BTW, I encountered "QWaitCondition: Destroyed while threads are still waiting" when finishing a session if I use Core() instead of Core(threads=1). Only occurs in r5. Last edited by 06_taro; 10th September 2012 at 17:47. |
10th September 2012, 19:29 | #120 | Link |
Professional Code Monkey
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,548
|
That warning is harmless. It's just that I haven't made the destruction of the threadpool completely correct.
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet |
Tags |
speed, vaporware, vapoursynth |
Thread Tools | Search this Thread |
Display Modes | |
|
|