-
Notifications
You must be signed in to change notification settings - Fork 6
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
I just made the setting to hold the frame drop #9
Comments
vs's built-in resize is inefficient. And inserting multiple cpu-filter make it worse. The best solution is develop a new plugin or model to fusion pre-resizing into the process of janai's upscaling. Just like what rife_v2 had done. |
Thanks for sharing. I pushed some updates to the v2 branch based on your previous comments to increase its flexibility. The format of the conf file has been completely redone and I believe it's able to handle all of the scenarios you want without requiring any custom code changes. If you'd like, back up your existing files, download the latest scripts from the v2 branch and try setting it up to see if it can do what you want. Feel free to leave any feedback on the latest changes. I have also started working on benchmarking scripts which will be helpful in setting up the configurations for animejanai. I have been collecting benchmark results here (https://github.com/the-database/mpv-upscale-2x_animejanai/wiki/Benchmarks) but I haven't tested the benchmarking script with the latest changes so it may not be working yet. Once it's working you'll be able to run the benchmark all .bat file which will run a set of benchmarks and generate a benchmark.txt which contains a markdown table which you can paste the results of to the wiki. EDIT: The benchmark script has been fixed and is working again. Please see the wiki for detailed instructions in you're interested in running them. |
I've read the changes. And I'll give you a little bit more feedback here. I think it's better to set it based on the number of pixels rather than the height. #Derive the number of pixels based on 16:9 video (xxxxp) = xxxx * xxxx * 16 / 9 animejanai_v2.conf
animejanai_v2_config.py
However, I think the speed may be disrupted by a large number of pixel counts. |
Tried to benchmark but failed. (I still lack knowledge of coding. I tried pressing "all.bat" but there was no response and I didn't understand where to fix the 'video_path' in .vpy. I'm sorry about this.) Instead, I try every possible combination depending on the situation ** EDIT(04.25) i5 13600k + Geforce RTX 4070 ti /// 30fps 60fps ** EDIT(04.25) : for example simple coding
|
I created a new issue for benchmarking. Can we continue the benchmarking discussion there if you don't mind? #10
That's true. I pushed an update to use video resolution instead of video height in the animejanai conf file. In the code, the resolution isn't used directly, but the total number of pixels is calculated and that is what's used in the comparison. I believe the resize_height_before_upscale property allows you to basically use the scale_to_1080 function as needed? Do you have an example where resize_height_before_upscale doesn't give you enough control? |
I think we need to consider two parts for the size_height_before_upscale property.
For example, suppose I use the size_height_before_upscale function to change (height: 2160 -1081) to 1080 and (height: 1080 - 0) to 720. As you can see, the number of pixels changed differently, and the decimal point occurred. At first, I was going to use only the scale_to_1080 that you created, and I excluded size_height_before_upscale. However, it seems that correcting based on pixels will solve this problem. It seems that size_pixel_before_upscale will be able to cope more flexibly than I set.
The size_height_before_upscale feature is a structure that the user enters while testing it himself. My guess is that if you upscaled at a 16:9 ratio, you'll have to divide it by an integer multiple of 9. If the user enters 700, the quality may be out of order. I think this part should be specified by the creator rather than input by the user. So I subtracted 135 from 1080 (that's a number close to 100) and the number I set is below. **EDIT : (or 540/630/720/810/900/990/1080 also not bad) However, this is also groundless, so your judgment may be correct, so please refer to it. Lastly Regarding the Vanch marking test, I will check it again later when I have time in #10. Thank you for your confirmation. |
I see what you're saying. Maybe this can be handled using a new It would not resize the video to the exact resolution specified. Instead, it would calculate the total pixels specified, and then resize the original video to the largest size possible, with total pixels less than or equal to the total pixels specified. For example, if
This setting would allow you to do a resize and guarantee the total number of pixels is within the limits that your hardware can handle. I believe that's what you are looking for. What do you think? |
Tip: odd number of length is not allowed for subsampling |
Yeah, that's a better solution than I said. If I summarize the tasks that need to be solved, we should look at them like this.
But I found one more thing to worry about here. Targeting pixels alone can exceed the height or length of the monitor's maximum resolution. For example, my monitor has a maximum resolution of 3840 * 2160. For
Attempting upscaling will result in 1656 * 2208 and exceed the maximum height. As far as I know, it doesn't work if the upscaling result exceeds the height and width of 2160p. Therefore, it is necessary to design so that it does not exceed the maximum horizontal and vertical parts. So I'm thinking about using screeninfo to extract the display value of the monitor and then upscale it flexibly in any situation. but, I have something important to do tomorrow, so I'll think about it up to here and give you another opinion next week. If you're thinking of another good way, please comment. EDIT 04/30It would be nice to have a function to extract the resolution information of the monitor using screeninfo.py . This can solve various problems that arise for situations that are vertical videos or vertical monitors. However, if the user has a multi-monitor, additional settings are required for which monitor to target. I've coded animejanai to prepare for videos that play vertically. (1) 2023-04-30 20:21:49 DEBUG Currently, the vertical video upscaling function is deteriorating. Change display_orientation to portrait. (2) 2023-04-30 20:04:30 DEBUG Display_orientation : Portrait Modified to make a vertical version engine. I set it to stop when it exceeds 4k and 70fps. And vertical_engines are marked separately. This is a value set according to the 4070 ti specification, so I think it needs to be modified for others to use. +++edit05.03) line250, line254: Example of a 518400 or lower pixel movie (960 x 540 = 518400, 800 x 600=480000) attach fileI attached the files that have been modified even a little bit. There is also screeninfo. |
This time, I've made optimization after a lot of trial and error.
The amendments are as follows
1. Add "scale_to_540, 675, 810"
Upscale_twice or 60 frame videos above 1080p almost unconditionally get frame drops.
To find a solution to this, I tried to manipulate the "animejanai_v2.conf" data and find a figure that prevents frame drops while preserving the most quality.
In conclusion, I think the frame drop was the best when it was "resize_height_before_first_2x=540", and I started to make a code based on this
scale_to_810: 1440p60 upscaling
scale_to_675 : 1080p60 Upscaling
scale_to_540 : 809p30~540p30 upscale_twice
scale_to_1080: 1079p to 810p upscaling
2. Different engine settings for different situations
Compact / UltraCompact/ SuperUltraCompact (strong.v1)
I used all three of these to make the best combination
30 frames
2159p - 810p >>> resize1080 + UltraCompact >>> 2160p
809p - 540p >>> resize540 + SuperUltraCompact + SpuerUltraCompact >>> 2160p
539p - 1p >>> Compact + UltraCompact >>> 2156p - 4p
60 frames
2159p - 1081p >>> resize810 + SuperUltraCompact >>> 1620p
1080p - 810p >>> resize675 + UltraCompact >>> 1350p
809p - 540p >>> UltraCompact >>> 1618p - 1082p
539p - 1p >>> Compact >>> 1078p - 2p
I am very pleased with this result
rife_cuda.py also I've tried this too. but I think it's going to be hard.
Below is the code I used
I'll mark ###new### for the part where I fixed the code
animejanai_v2.py
animejanai_v2_1.vpy
animejanai_v2.conf
The text was updated successfully, but these errors were encountered: