Cool to see my work finally complete and published! Thanks for the prompt judging and processing! I noticed the publication page says it obsoletes the previous run, even though this was meant to be a new branch (and Samsara accepted it that way). Was the decision changed, or is this an error? Also, if you'll excuse the nitpick, the description mentions stuff from the NES version that aren't in Round Game in the SNES version, namely minibosses and cutscenes of Wario trying to discourage Toad. The SNES version doesn't have minibosses, and the cutscenes are different -- in Round Game they just show Toad moving through the overworld map, and the cutscenes with actual dialogue were moved to the SNES-exclusive VS COM mode, with different dialogue.
Sorry I didn't mention it right away. The reason I suggested testing this on 512px mode of PSX and/or A2600 is to see how it compares after ARC. Because ARC is what makes them inherently not pixel-perfect. And heavy ARC is what may kill things really hard (slight fractional ARC too tho). But since we don't target 1x anymore, it also has to go 2x with pixel first, and then shrink or stretch width without changing height, because height isn't meant to be stretched by fractional factor. Finally, this test image has a lot of almost-white on a lot of almost-black, which means color changes are almost pure luma too. Good comparison would be going from chroma to no chroma (or vice versa), because detail loss is the most apparent there. As long as there's a lot of chroma, even changes from one chroma color to another won't make the loss apparent. EDIT: I'm switching between the 2 resulting images above at 1000% zoom I can't tell which one is better.
ControlLanguage: AviSynthAviSource("kain.avi") # 560x240 (512,240 framebuffer) PointResize(1120, 480).LanczosResize(640, 480) one = ConvertToYV12(chromaresample="point", matrix="rec601") two = ConvertToYV12(chromaresample="lanczos", matrix="rec601") #Aktan's method ConvertToRGB64() three = ConvertToYUV420(matrix="rec601", chromaresample="point").ConvertBits(bits=8, dither=0) four = ConvertToYUV420(matrix="rec601", chromaresample="lanczos").ConvertBits(bits=8, dither=0) ExtractV()
YV12, Point
YV12, Lanczos
Aktan's Method, Point
Aktan's Method, Lanczos
After doing this, I realize that this game as probably a bad pick for this because it's dark and kind of dull. For this type of content (full 3D), the differences between point and lanczos sampling is nearly indistinguishable to me. Aktan's method vs straight to YV12 has differences that are a little more different though - if you zoom in a LOT, you can see that there seems like a very slight increase in contrast for the strictly YV12 route, vs smoother gradients in Aktan's (expected because of dithering). The difference is very small though and you've gotta squint.
I think that this sampling may have a bigger effect for pixel-y games. Anyone want to recommend a 2D, 512px mode PS1 game? Someone should test A2600.
Test 1: Do we need to convert from RGB to YV24 to YV12 to preserve quality, versus converting directly from RGB to YV12?
The script has had this "double" conversion for some time now, and Aktan recalls that it was likely originally done because there was a bug in AviSynth that caused direct conversions to YV12 (4:2:0) to either ignore parameters, or suffer some other type of quality loss. There is mention of an issue that sounds quite similar in official Avisynth documentation on this page: http://avisynth.nl/index.php/Sampling#RGB_-.3E_YUY2_conversion. Relevate quote:
(In v2.58, the [0 1 1] kernel was used to interpolate chroma. This is technically wrong and results in a 0.5 pixel right shift of the chroma, but it was originally done for performance reasons.)
RGB -> YV12,PointLanguage: AviSynthwide = AviSource("E:\xtreme\2Xtreme.avi") wide1 = wide.ConvertToYV12(chromaresample="point") wide2 = wide.ConvertToYV24(chromaresample="point").ConvertToYV12(chromaresample="point") # Extract chroma planes for comparison since luma should remain unaffected and will make comparison more difficult. wide1.ExtractU() wide2.ExtractU()
RGB -> YV24,Point -> YV12,Point
XORing these planes together in Paint.net yields a uniformly black (0,0,0) image, meaning that the planes are identical, and the trip through YV24 did not make a difference.
Let's test the internal order of operations of the convert functions to ensure that the transfer function is performed first, then resizing.
RGB -> YV24,Point -> YV12,LanczosLanguage: AviSynthwide = AviSource("E:\xtreme\2Xtreme.avi") wide3 = wide.ConvertToYV24(chromaresample="point").ConvertToYV12(chromaresample="lanczos") wide4 = wide.ConvertToYV12(chromaresample="lanczos") wide3.ExtractU() wide4.ExtractU()
RGB -> YV12,Lanczos
XORing these planes together in Paint.net yields a uniformly black (0,0,0) image, meaning that the planes are identical, and that converting directly to YV12 preserves the desirable order of operations.
Test 2: Increasing bit depth prior to color space conversion, dithering, and other assorted goodies courtesy of Aktan.
Aktan provided a technique for colorspace conversion that might improve accuracy:
Code as posted produces:Language: AviSynthAviSource("E:\xtreme\2Xtreme.avi") # Assume RGB32 source ConvertToRGB64() # ConvertToYUV444(matrix="Rec709", chromaresample="point") # Might be needed? Needs testing ConvertToYUV420(matrix="Rec709", chromaresample="lanczos") # Conversion from 16-bit RGB to YUV 4:2:0 16-bit ConvertBits(bits=8, dither=0) # Reduce back to 8-bit color with dithering, bits=10 for our encodes in 10-bit color ExtractU()
Code with optional conversion to YUV444 enabled:
XORing these planes together shows that they are identical, so the trip to 444 (as with the previous test) appears unnecessary.
Here is the full image using Aktan's method:
Here is the full image, converted directly to YV12 with Lanczos:
Here is the XOR of these two images:
Very unsurprisingly they are different (there is dithering going on). No conclusion, subjective difference would have to be examined. Take the two images into paint.net, put them on separate layers, and switch between them if you want to try to determine which is subjectively better.
Sure, here's what I had in mind to add to it: "This new TAS of Doc Louis's Punch-Out!! improves sparring by incorporating a newly discovered Instant Knock-Out to the game. Saving 3 seconds from Sparring's previous TAS."
just came across this, and am surprised to have not seen it materialize here yet https://www.youtube.com/watch?v=NuYGNlidKfw&ab_channel=Sample
When encoding a movie, does the starting frame and ending frame get captured. I often wondered this, since you start on frame zero, which isn't anything...so it makes me wonder if the encoding stops when it reaches the end frame, with nothing captured. I've tried to confirm this with visual queues but I guess I don't have a good playback app to look at individual frames.
Option Explicit
Dim Frames, Segments, SegLength, i
Dim Output
If WScript.Arguments.Count = 2 Then
Frames = WScript.Arguments.Item(0)
Segments = WScript.Arguments.Item(1)
Else
Wscript.Echo "Usage: vidsplit.vbs <frames> <segments>"
Wscript.Quit
End If
SegLength = (Frames \ Segments) + 1
For i = 0 To Segments - 1
Output = Output & vbCrLf & CStr(i * SegLength) & " " & CStr(SegLength)
Next
Wscript.Echo Output
Wscript.Quitset segments=6
set threads=16
echo Encoding video...
".\programs\ffprobe" -hide_banner -v error -select_streams v -of default -show_entries stream=nb_frames encode.avs >> ".\temp\info.txt"
for /f "tokens=2 delims==" %%G in ('FINDSTR "nb_frames" "%~dp0temp\info.txt"') do (set frames=%%G)
set concat=".\temp\concat_modern.txt"
break > %concat%
for /f "tokens=1,2" %%G in ('cscript -nologo "programs\vidsplit.vbs" %frames% %segments%') do (
set start=%%G
set length=%%H
set name=video_modern_!start!.mkv
set filepath=.\temp\!name!
start "!start!" ".\programs\x264_x64" --threads %threads% --stitchable --seek !start! --frames !length! --sar "%VAR%" --crf 20 --keyint 600 --ref 16 --no-fast-pskip --bframes 16 --b-adapt 2 --direct auto --me tesa --merange 64 --subme 11 --trellis 2 --partitions all --no-dct-decimate --input-range pc --range pc -o "!filepath!" --colormatrix smpte170m --output-csp i444 --profile high444 --output-depth 10 encode.avs
echo file '!name!' >> %concat%
Timeout /T 3 /NoBreak > NUL
set previous=!next!
)
:MODERNLOOP
tasklist | find /i "x264_x64.exe" >nul 2>&1
IF ERRORLEVEL 1 (
GOTO MODERNCONTINUE
) ELSE (
Timeout /T 300 /Nobreak
GOTO MODERNLOOP
)
:MODERNCONTINUE
ffmpeg -y -hide_banner -safe 0 -f concat -i %concat% -c copy .\temp\video.mkv
:: Muxing ::
[....]
The "MODERNLOOP" thing is a process checking loop. While the encoding instances are doing their thing, the main global.bat file spins in this loop. Every 5 minutes, it checks to see if there are any x264 instances left running. If there are, it waits another 5 minutes. If not, then the videos are done and ready to be put together.
You may have noticed a "modern_concat.txt" file that got created earlier in the process. This is a text file that gets built up by getting filenames during the encoder instance loop, and is later fed into ffmpeg. ffmpeg has a special muxing tool built in called a "concat demuxer". What this does is, rather than concatenating videos in a more traditional way and then re-encoding them as one video, you can take a bunch of videos that all have the exact same properties (dimensions, framerate, colorspace, encode parameters, etc), and just "play" them back-to-back into a container. This allows you to combine disparate segments into a single video without any extra processing. There is a little tiny bit of inefficiency here since the encoder will naturally have to stop the GOPs in each segment at the seams, but losing just 5 full-sized GOPs only ever accounts for a few hundred kilobytes in the end product (I've tested this).
Should you bother with this?
For fun I tested splitting videos up with an old 4-core intel processor from 2011, and found that doing it didn't provide any speed benefits at all. For native-sized encodes, x264 is able to fully saturate about 8 threads already, so splitting it up didn't help a ton in my case.
If you have a normal consumer 4-core processor, this probably won't help you at all. I am interested in hearing from anyone with consumer-grade CPUs trying this out and seeing performance increases, though. If you've got a hexacore or octacore processor however, you might be able to use this to speed stuff up. I would recommend trying two segment encoding for either 6- or 8-core processors. You can set the threads for both higher than the actual amount of logical cores than you have available, like each instance could have 8 or even 16. Ultimately, you would need to test various parameter combinations to try and hone in one an effective combination.
For HD videos, this probably isn't worth it unless you've got over 20 cores. On my machine a 4k encode with the right settings can saturate all 20 cores, and x265 can do that even more effectively. If you've got really serious numbers though, splitting up HD encodes will net exactly the same benefits as the SD encodes enjoy.
I learned that FFMPEG will default to YUV 4:2:0 as opposed to the newer 4:4:4 but how do you change it so that FFMPEG will use 4:2:0?
Edit: Should use x264vfw/x264 8 Bit-10 Bit for final encodes?
How do merge the split video files? I do not want it to remain split.
What is a good AVISynth/FFMPEG Command for Lanzcos resizing Sega Saturn footage?