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 10th October 2018, 23:02   #1  |  Link
videoh
Registered User
 
Join Date: Jul 2014
Posts: 587
Does avscompat module support filters taking YUV420P16?

My filter DGHDRtoSDR() is a dual native Avisynth+/Vapoursynth plugin. It takes YUV420P16 from DGSource(). When run in native Vapoursynth everything is fine. However, when run with avscompat it reports "Invalid color space for the input clip" for the DGHDRtoSDR call.

Would it be feasible to modify the avscompat layer to handle this space, or would the changes be too extensive?

It seems strange to me that DGSource() is allowed to deliver YUV420P16 but DGHDRtoSDR is not allowed to accept it.

Last edited by videoh; 10th October 2018 at 23:15.
videoh is offline   Reply With Quote
Old 11th October 2018, 12:53   #2  |  Link
hydra3333
Registered User
 
Join Date: Oct 2009
Location: crow-land
Posts: 517
On a semi related topic and at the risk of asking something already answered (if there's a link please feel free to say so) are there any performance/technical constraints or penalties in loading and using a "same functionality" avisynth filter in avs compatibility layer vs a native vapoursynth version in its own namespace, viz

Code:
core.avs.LoadPlugin(r'C:\x64-avisynth-only\DGDecodeNV_old.dll')
clip = core.avs.DGSource(r'c:\x64\test.dgi', fulldepth=True)
Code:
core.std.LoadPlugin(r'C:\x64-vapoursynth-native\DGDecodeNV_new.dll')
clip = core.dgdecodenv.DGSource(r'c:\x64\test.dgi', fulldepth=True)
I suppose the same performance/technical constraint query also arises for a native vapoursynth filter in compatibility vs native. Thoughts would be much appreciated.

edit: I hope I got that the right way around
hydra3333 is offline   Reply With Quote
Old 11th October 2018, 14:25   #3  |  Link
Myrsloik
Professional Code Monkey
 
Myrsloik's Avatar
 
Join Date: Jun 2003
Location: Ikea Chair
Posts: 1,874
Quote:
Originally Posted by videoh View Post
My filter DGHDRtoSDR() is a dual native Avisynth+/Vapoursynth plugin. It takes YUV420P16 from DGSource(). When run in native Vapoursynth everything is fine. However, when run with avscompat it reports "Invalid color space for the input clip" for the DGHDRtoSDR call.

Would it be feasible to modify the avscompat layer to handle this space, or would the changes be too extensive?

It seems strange to me that DGSource() is allowed to deliver YUV420P16 but DGHDRtoSDR is not allowed to accept it.
It should support the same formats as avs+ if the plugin is detected to be one. I'll try it myself and see why it fails...
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet
Myrsloik is offline   Reply With Quote
Old 11th October 2018, 14:28   #4  |  Link
Myrsloik
Professional Code Monkey
 
Myrsloik's Avatar
 
Join Date: Jun 2003
Location: Ikea Chair
Posts: 1,874
Quote:
Originally Posted by hydra3333 View Post
On a semi related topic and at the risk of asking something already answered (if there's a link please feel free to say so) are there any performance/technical constraints or penalties in loading and using a "same functionality" avisynth filter in avs compatibility layer vs a native vapoursynth version in its own namespace, viz

Code:
core.avs.LoadPlugin(r'C:\x64-avisynth-only\DGDecodeNV_old.dll')
clip = core.avs.DGSource(r'c:\x64\test.dgi', fulldepth=True)
Code:
core.std.LoadPlugin(r'C:\x64-vapoursynth-native\DGDecodeNV_new.dll')
clip = core.dgdecodenv.DGSource(r'c:\x64\test.dgi', fulldepth=True)
I suppose the same performance/technical constraint query also arises for a native vapoursynth filter in compatibility vs native. Thoughts would be much appreciated.

edit: I hope I got that the right way around
The overhead is less than 1% if that's what you mean. Any remaining difference is down to the threading model differences and the fact that VS will never "cheat" and create multiple instances of one filter to increase parallellisation.

=> Unless an actually improved VS port exists it doesn't matter
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet
Myrsloik is offline   Reply With Quote
Old 11th October 2018, 15:28   #5  |  Link
videoh
Registered User
 
Join Date: Jul 2014
Posts: 587
Quote:
Originally Posted by Myrsloik View Post
It should support the same formats as avs+ if the plugin is detected to be one. I'll try it myself and see why it fails...
Thank you.
videoh is offline   Reply With Quote
Old 11th October 2018, 17:13   #6  |  Link
videoh
Registered User
 
Join Date: Jul 2014
Posts: 587
I had an earlier version of Vapoursynth. When I upgraded to R44 avscompat is working in YUV420P16. Sorry for the false alarm.
videoh is offline   Reply With Quote
Reply

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 07:28.


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