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 > Avisynth Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 11th January 2017, 23:20   #2841  |  Link
davidhorman
I'm the Doctor
 
Join Date: Jan 2004
Posts: 1,351
Quote:
If the input serves packed, then immediately "unpack" it. And pack it again for the output if needed.
That's needlessly wasteful.

Packed RGB(A) has its advantages. Want to copy a whole pixel? With packed RGB32, that's two instructions. With planar, it's several more.
__________________
My AviSynth filters / I'm the Doctor
davidhorman is offline   Reply With Quote
Old 12th January 2017, 00:01   #2842  |  Link
Myrsloik
Professional Code Monkey
 
Myrsloik's Avatar
 
Join Date: Jun 2003
Location: Ikea Chair
Posts: 1,687
Quote:
Originally Posted by davidhorman View Post
That's needlessly wasteful.

Packed RGB(A) has its advantages. Want to copy a whole pixel? With packed RGB32, that's two instructions. With planar, it's several more.
TRIGGER WARNING

I don't care about ancient cpus. Take that!

This thread is now painful to read. Truly painful. I wish I could quote all the stupid assumptions but the most recent example will have to do.

1. The unpack-process-pack method is effectively no more expensive than keeping pixels packed. This is because you generally have to copy memory into a frame in source filters and there's a memcpy at the VfW side too. Ha!

2. To whoever said something about DIB. It's irrelevant because they only go up to rgb32. Doesn't say what everything else should be. Also asking what the early 90s at best thought was a good idea IS NOT A GOOD IDEA.

3. About using the most common input format as the processing format: b64a is the most common rgb64 format. It's BIG STINKING ENDIAN AND YOU DON'T WANT TO GO THERE ON A LITTLE ENDIAN CPU.

4. Individual examples about the pros and cons of different pixel layouts. You know what? (you obviously don't since you post them) IT DEPENDS ON THE ALGORITHM THE INDIVIDUAL FILTERS USE.

5. Planar is still your friend even if there are no direct performance gains. This is because of code sharing between yuv and rgb paths in filters.

6. If you allow unchanged planes to be passed through (as VS does) you'll save a lot of memcpy.

7. Read and write sizes don't matter much as long as they're 16 bits or more. For simple 8 bit filters sse2 can speed things up a lot just by combining loads and stores. With multiple threads and a simple 16 bit filter you'll usually become ram bandwidth limited even without simd.

(EN)CODING TRUTH
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet
Myrsloik is online now   Reply With Quote
Old 12th January 2017, 00:13   #2843  |  Link
davidhorman
I'm the Doctor
 
Join Date: Jan 2004
Posts: 1,351
Quote:
Originally Posted by myrsloik View Post
triggered warning
ftfy.
__________________
My AviSynth filters / I'm the Doctor

Last edited by davidhorman; 12th January 2017 at 00:24.
davidhorman is offline   Reply With Quote
Old 12th January 2017, 08:36   #2844  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 4,993
Regarding 2.: I don't say DIB compatibility is a "good" idea. I only say some people still use "legacy" software which doesn't know it better than that. And if packed RGB would be removed from AviSynth(+), then you could probably not use AviSynth(+) anymore in conjunction with such tools or plugins.

The questions were:

a) Why are there both worlds? – Legacy, compatibility, and different advantages for different kinds of use.

b) Should AviSynth(+) get rid of one? – Only if compatibility with legacy software doesn't matter.
__________________

German doom9 / Gleitz board
MediaFire shares: x265 | VPx | AOM | Xvid

Rémoulade is spoiled
LigH is offline   Reply With Quote
Old 12th January 2017, 09:50   #2845  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 1,469
@pinterf
In the process of avs+ upgrade/improvements, i suggest the following to fill the missing gaps.
It would work the way the new bitdepth functions works : "Do nothing" or return a default value if we are on standard avisynth.

It should be nice to add these missing metadata :
Range mode, result would be : NONE, FULL_RANGE, LIMITED_Y, LIMITED_C.
Two limited modes, because a grey plane can be either a true greyscale plane, or an extract of an RGB plane, or an extract of a YUV plane, in that case it can be a chroma plane.
For YUV mode, LIMITED_Y or LIMITED_C would be the same thing, but i propose the used of LIMITED_Y by default.
Color mode, result would be : NONE, REC601, etc...
MPEG mode, result would be : NONE, MPEG-1, MPEG-2.
Frame mode, result would be : NONE, PROGRESSIVE,INTERLACED.

Several way to handle them.
A function wich return the status, with NONE returned on not avs+.
A function which manualy set it, "doing nothing" on not avs+.
And the last, the "automatic" way.
The default value, when a clip is created, would be the default value used in functions specifying them.
For exemple, a ConvertYV16 has a default color matrix value, this is this default value which will be used when a clip is created.
Same for all the others tags.
When a function with one or more of these parameters exist is used, the behavior would be the following :
- If the meta data is not NONE, and the parameter is not specified, the value used is the one of the meta data.
- If the meta data is NONE, the meta data get the value of the default value of the parameter if it's not specified.
- If the parameter is specified, the metadata get the value of the parameter.
Some metadata are kept even if the format don't need it.
For exemple, an YUV clip converted to RGB, would it be directly converted, or would it be converted and result put in a different clip, the resulting RGB clip will keep the Color mode. Because this same color mode will be used if converted back to YUV without the color matrix specified in the called function.
Some metadata will be automaticaly changed according what is done, unless a parameter in the function specify it.
For exemple, an YUV clip converted to RGB will have the range parameter changed from LIMITED_x to FULL_RANGE. On the other way, an RGB clip converted to YUV will have the parameter changed from FULL_RANGE to LIMITED_Y (unless parameter specification, of course).
RGB will allways be FULL_RANGE, because it's RGB we're working with, not R'G'B'.
Extracted plane would have the parameter set accordingly.
En extracted plane from RGB or from YUV set to FULL_RANGE will be FULL_RANGE. Y or U/V plane extracted to LIMITED_x will be set accordingly.

Well, i think you see the picture.
What do you think ?
I personnaly think these metadata realy should be present, and adding them is within the actual avs+ improvement way.

Last edited by jpsdr; 12th January 2017 at 09:53.
jpsdr is offline   Reply With Quote
Old 12th January 2017, 10:08   #2846  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 4,993
slightly confused

Does pinterf also develop the legacy AviSynth? If not, he won't be able to implement any features there. Then your requested features will only exist in AviSynth+ at all.

MPEG mode: What does this mean? AviSynth(+) only handles uncompressed video frames. Do you refer to chroma subsampling locations?
__________________

German doom9 / Gleitz board
MediaFire shares: x265 | VPx | AOM | Xvid

Rémoulade is spoiled
LigH is offline   Reply With Quote
Old 12th January 2017, 10:48   #2847  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 817
This is what I found.

VideoInfo struct, defined in Avisynth.h has an image_type property.
It is a bitmap, we have 32 bits for storing video related properties.
This is where BFF, TFF, and FIELDBASED info is stored.

Single bit properties can be checked with VideoInfo::Is(property) function.

Checking for the few existing properties are directly implemented
VideoInfo::IsFieldBased()
VideoInfo::IsBFF()
VideoInfo::IsTFF()

VideoInfo::SetFieldBased(bool fieldbased) is a shortcut for set/clear FIELDBASED flag, something like this:
Code:
void VideoInfo::SetFieldBased(bool isfieldbased)  { if (isfieldbased) image_type|=IT_FIELDBASED; else  image_type&=~IT_FIELDBASED; }
One can set and clear a bit property as:
VideoInfo::Set(property) and VideoInfo::Clear(property)

In avisynth.h these are defined:
Code:
  // Imagetype properties

  int image_type;

  enum {
    IT_BFF = 1<<0,
    IT_TFF = 1<<1,
    IT_FIELDBASED = 1<<2
  };
Then there are some other defines, that are nowhere used. At least not inside avisynth plus.

Based on the CS_xxx naming, maybe these were originally intented to appear in the pixel_type. But as VideoInfo:: pixel_type is directly used for checking/setting the video format, using these chroma placement bits in pixel_type would break plugins and avisynth itself.

Code:
  // Chroma placement bits 20 -> 23  ::FIXME:: Really want a Class to support this
  enum {
    CS_UNKNOWN_CHROMA_PLACEMENT = 0 << 20,
    CS_MPEG1_CHROMA_PLACEMENT   = 1 << 20,
    CS_MPEG2_CHROMA_PLACEMENT   = 2 << 20,
    CS_YUY2_CHROMA_PLACEMENT    = 3 << 20,
    CS_TOPLEFT_CHROMA_PLACEMENT = 4 << 20
  };

Last edited by pinterf; 12th January 2017 at 10:50.
pinterf is online now   Reply With Quote
Old 12th January 2017, 11:08   #2848  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 817
Quote:
Originally Posted by LigH View Post
slightly confused

Does pinterf also develop the legacy AviSynth? If not, he won't be able to implement any features there. Then your requested features will only exist in AviSynth+ at all.
In avisynth.h there are a couple of VideoInfo:: functions that smartly fallback to return a default value when the relevant function does not exist in avisynth linkage.

Thus using this avisynth.h in your plugin development you can use the new functions (VideoInfo::BitsPerComponent(), etc...) and it won't crash when your plugin is used with classic avisynth or pre-high bit depth avisynth plus. You needn't distinct whether your target audience uses newer avisynth plus or classic avisynth.

Possibly specialized image_type getter and setter functions could work in such a way, but one could use the all-compatible VideoInfo::Set and Clear
pinterf is online now   Reply With Quote
Old 12th January 2017, 11:09   #2849  |  Link
Groucho2004
 
Join Date: Mar 2006
Posts: 3,601
Quote:
Originally Posted by tuanden0 View Post
Can someone help me the filter fft3dGPU crashed if I use SetFilterMTMode("FFT3dGPU", 3)
Apart from instability/crashing, running fft3dgpu multi-threaded is pointless. The speed does not increase and the GPU memory consumption goes through the roof.

I suggest you use FFT3DFilter from here. Multi-threaded, it will be faster than fft3dgpu.

Last edited by Groucho2004; 12th January 2017 at 13:15.
Groucho2004 is offline   Reply With Quote
Old 12th January 2017, 11:24   #2850  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 1,469
Quote:
Originally Posted by LigH View Post
Do you refer to chroma subsampling locations?
Yes, and it seems that some features allready exist, this one seems to be already included.
jpsdr is offline   Reply With Quote
Old 12th January 2017, 12:58   #2851  |  Link
ajp_anton
Registered User
 
ajp_anton's Avatar
 
Join Date: Aug 2006
Location: Stockholm/Helsinki
Posts: 751
So from the planar/packed discussion, it seems that:
Packed is only needed for output. Otherwise it's easier (shared code with planar YUV) and faster (non-ancient CPUs only?) to process. Therefore IMO planar should be the default RGB format with ConvertToRGB24 etc, and Avisynth should only convert to packed before outputting (can it detect if whatever's at the other end wants packed or if it supports planar?). There should also be a "packed"-named bool argument when converting to any RGB format, in case an old filter requires it. What do you think?
ajp_anton is offline   Reply With Quote
Old 12th January 2017, 13:35   #2852  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 5,261
Quote:
There should also be a "packed"-named bool argument when converting to any RGB format, in case an old filter requires it.
With default true, unless intent is to break nearly everything ever written.
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???
StainlessS is offline   Reply With Quote
Old 12th January 2017, 14:16   #2853  |  Link
tuanden0
Registered User
 
Join Date: Oct 2016
Posts: 59
@Groucho2004:

That was great, no crashed with MT mode 3 and I can use the fft3dgpu setting for fft3dfilter.
tuanden0 is offline   Reply With Quote
Old 12th January 2017, 16:15   #2854  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 980
Quote:
Originally Posted by LigH View Post
Regarding 2.: I don't say DIB compatibility is a "good" idea. I only say some people still use "legacy" software which doesn't know it better than that. And if packed RGB would be removed from AviSynth(+), then you could probably not use AviSynth(+) anymore in conjunction with such tools or plugins.

The questions were:

a) Why are there both worlds? – Legacy, compatibility, and different advantages for different kinds of use.

b) Should AviSynth(+) get rid of one? – Only if compatibility with legacy software doesn't matter.
I think you're kinda missing the point here. Supporting everything under the sun plus the kitchen sink is of course "good" for the end user, but it's not free - it adds complexity, both to the user and to the programmer, and it adds maintenance costs (work on an enthusiast project may be free as in beer, but it has a non-monetary price nevertheless). If one standard way of doing things is agreed upon, the process of interacting with the filtering framework is streamlined and eased for everyone - people using it, people writing filters for it and people maintaining the framework itself. That is highly desirable.

Nobody has suggested that input or output of packed RGB should not be supported. Not even VS goes that far, despite a wholehearted desire to throw out everything old. As you say, there are still important legacy systems that you kinda have to deal with that only support packed.

What has been proposed is to only use planar RGB internally, and automatically pack/unpack on input and output. The reasons for this are as follows:

1. Packed 8-bit RGB is an oddity in 2017. Literally everything else is planar - higher bitdepth RGB, YUV, YCgCo, etc. If you switch to planar as a standard, there is a not insignificant number of filters that can be adapted to use the same code path for all colorspaces, which is pretty huge for maintenance.

2. It's essentially free. Packing or unpacking is barely more expensive than copying the frame, and as Myrsloik points out you almost always have to do that at each end of your filter chain anyway.

3. It has performance benefits, especially for filters that want to treat some components differently or pass them through unchanged. Some filters could in theory benefit from packed, but since those benefits are 8-bit RGB only that's almost completely irrelevant, and it is likewise theoretically possible to rewrite the algorithm to benefit from planar instead.


Now, to fully reap these benefits you must standardize on planar, or you're still left with the whole legacy codepath maintenance garbage. Hence, if you want to support legacy RGB filters you should pack/unpack automatically on input/output from those. That should hopefully give people an incentive to update their filters to avoid the (admittedly rather minor) performance hit.
TheFluff is offline   Reply With Quote
Old 13th January 2017, 09:02   #2855  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 4,993
OK, understood ... "internally", for the core filters, this would surely be a good idea, assuming that the benefits are as obvious as you explain them (which I would probably agree with). You may just need to repack not only for the final output to the calling application, but also for plugins supporting packed RGB and addressing frame content directly (if this is included in your statement "automatically pack/unpack on input and output", you already considered that). And new plugins working in RGB space will surely be written to support it in planar organization as well when compatibility specifically to AviSynth+ is desired.
__________________

German doom9 / Gleitz board
MediaFire shares: x265 | VPx | AOM | Xvid

Rémoulade is spoiled
LigH is offline   Reply With Quote
Old 13th January 2017, 10:00   #2856  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 1,469
Quote:
Originally Posted by pinterf View Post
Based on the CS_xxx naming, maybe these were originally intented to appear in the pixel_type. But as VideoInfo:: pixel_type is directly used for checking/setting the video format, using these chroma placement bits in pixel_type would break plugins and avisynth itself.

Code:
  // Chroma placement bits 20 -> 23  ::FIXME:: Really want a Class to support this
  enum {
    CS_UNKNOWN_CHROMA_PLACEMENT = 0 << 20,
    CS_MPEG1_CHROMA_PLACEMENT   = 1 << 20,
    CS_MPEG2_CHROMA_PLACEMENT   = 2 << 20,
    CS_YUY2_CHROMA_PLACEMENT    = 3 << 20,
    CS_TOPLEFT_CHROMA_PLACEMENT = 4 << 20
  };
I didn't read properly.
Do you mean that these bits are already used for something else, so i can't use them for checking the chroma placement ?
jpsdr is offline   Reply With Quote
Old 13th January 2017, 11:35   #2857  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 817
These chroma placement bits are defined but nowhere used.
At many places VideoInfo.pixel_type is checked and set directly. (like vi.pixel_type == VideoInfo:: CS_YUV420P16, or vi.pixel_type=VideoInfo:: CS_YV12)
If we put chroma placement bits in VideoInfo.pixel_type then all these comparison will fail because they modify the pixel_type constants. The bits could be masked out before comparison like VideoInfo::IsColorSpace does now, but I think for the placement (and any other) metadata we should use the image_type property in order not to break existing plugins.
pinterf is online now   Reply With Quote
Old 13th January 2017, 12:23   #2858  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 1,469
Ok, thanks for the clarification.
jpsdr is offline   Reply With Quote
Old 17th January 2017, 21:35   #2859  |  Link
chummy
Registered User
 
Join Date: Aug 2014
Posts: 39
Hello, so i have a script with MFlowBlur which works with SET Avisynth MT but cannot make avisynth+ MT work on it.

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("ffvideosource", 3)
SetFilterMTMode("RGtools", 1)
chummy is offline   Reply With Quote
Old 17th January 2017, 21:53   #2860  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 5,261
Chummy, Pinterf will want some kind of script he can test, post the whole script including MFlowBlur().
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???
StainlessS 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 17:47.


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