Thread: Avisynth+
View Single Post
Old 12th January 2017, 16:15   #2854  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 1,100
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