Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ConvertToYV1* are notably slower than ConvertToYV24 when converting from RGB #19

Closed
magiblot opened this issue Aug 6, 2018 · 9 comments

Comments

@magiblot
Copy link

magiblot commented Aug 6, 2018

Hi there,

I have experienced some issues with the performance of the ConvertToYV12 and ConvertToYV16 functions (and their ConvertToYUV4xx equivalents).

In summary, doing a RGB->YV24->YV1* conversion path results in a higher processing speed than a direct RGB->YV1* conversion, in my IvyBridge (up to AVX) processor. I have made some measurements which show what I'm saying (the numbers are average FPS measured with AVSMeter):

imatge

I used the following source to run these tests. Then I added the Convert calls below:

ImageSource("tivissa-turisme-terres-ebre-ribera-catalunya-2.jpg",end=400)

The picture (1746x1200) can be found here: http://www.turismeriberaebre.org/municipi/tivissa/tivissa-turisme-terres-ebre-ribera-catalunya-2/. However, the issue is not exclusive to image sources.

Cheers.

@pinterf
Copy link
Owner

pinterf commented Aug 8, 2018

Good catch, reproduced, for me speed penalty is 2x (Source: colorbars).
I suppose the result of the internal RGB->444 conversion is not cached while when you convert it to 444 by a separate script filter, the clip is cached.
444->420 conversion is done by using three internal filters (Y copy, and U and V are the results of the appropriately parameterized resizers), all of them has the 444 clip as input.
Probably this step would benefit if the 444 clip is cached. But I need to investigate it further.

@magiblot
Copy link
Author

magiblot commented Aug 8, 2018

Interesting. Do you think this may be a regression? I would like to try to reproduce this on older versions later when I get home.

@pinterf
Copy link
Owner

pinterf commented Aug 10, 2018

It was always working in avs+ like that, classic avs was not affected probably due the different caching mechanism.
Anyway, problem was fixed in 4c06703
Thanks for your good eyes.

@magiblot
Copy link
Author

magiblot commented Aug 10, 2018

You are welcome. Thank you for working so hard!

@magiblot
Copy link
Author

In my previous example there is another performance issue: ImageSource. In 64-bit AviSynth, it runs at ~17 fps for me when called just like above. On the other hand, ColorBars runs at ~150 fps (or 130 with staticframes=false). More interestingly, the following runs at ~210 fps:

ImageSource("tivissa-turisme-terres-ebre-ribera-catalunya-2.jpg",end=0)
Loop(4000)

However, ImageSource can also read image sequences so it's a bit more complex case than ColorBars.
This is issue is not as crucial, though.

@pinterf
Copy link
Owner

pinterf commented Aug 27, 2018

Fixed, for some reason it was removed some years ago here: fe9dab1

@magiblot
Copy link
Author

magiblot commented Aug 27, 2018 via email

@pinterf
Copy link
Owner

pinterf commented Aug 28, 2018

Don't know. A quick search: http://avisynth.nl/index.php/Filter_SDK/Env_Invoke
InternalCache and Cache are synonyms in Avs+

@magiblot
Copy link
Author

That link is clear enough. Thank you very much.

@pinterf pinterf closed this as completed Dec 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants