DirectShowSource("dwangoAC-WIP-Epic-Pinball-05.mkv") # YV12 640 x 400
ConvertToYUY2 # Crop can't do odd numbers in YV12
PointResize(Width, Height * 5).Scanlines # add scanline after every 5 lines
#BilinearResize(1280, 960) # resize to final video size (optional)
function Scanlines(clip) {
clip
top = Crop(0, 0, 0, 5).AddBorders(0, 0, 0, 1)
bottom = Crop(0, 5, 0, 0)
bottom = (bottom.Height > 5) ? bottom.Scanlines : bottom.AddBorders(0, 0, 0, 1)
StackVertical(top, bottom)
}
This is the AviSynth version; a custom plugin could be much more optimized.
EDIT: Converting a 320x200 RGB source to 320x1200 and encoding that with ZMBV could be the best solution. The user's gfx card could stretch that without speed penalty.
EDIT: Converting a 320x200 RGB source to 320x1200 and encoding that with ZMBV could be the best solution. The user's gfx card could stretch that without speed penalty.
While I do think that scanlines are a nice alternative to the usual stretching algorithms used in media players (if only because they look closer to how it's actually supposed to be displayed), ZMBV is clearly an excessive measure. There is barely any speed penalty for hardware-accelerated stretching, and all popular systems and stand-alone devices can take advantage of this.
In any case, won't upscaling → adding scanlines → downscaling be a saner option?
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
EDIT: Converting a 320x200 RGB source to 320x1200 and encoding that with ZMBV could be the best solution. The user's gfx card could stretch that without speed penalty.
While I do think that scanlines are a nice alternative to the usual stretching algorithms used in media players (if only because they look closer to how it's actually supposed to be displayed), ZMBV is clearly an excessive measure. There is barely any speed penalty for hardware-accelerated stretching, and all popular systems and stand-alone devices can take advantage of this.
ZMBV was just mentioned for its potential of decreasing the file size. :)
moozooh wrote:
In any case, won't upscaling → adding scanlines → downscaling be a saner option?
Well, MKV (and maybe other containers) can specify a playback size of 1600x1200, which would be automatically reduced by sane players. It'd be the encoder's decision if s/he wants to offer these kinds of files.
To specify the correct aspect ratio. Both values will be reduced to the user's screen size anyway, unless the user has deactivated that option.
(1200 is the number of encoded lines)
You could also just define an aspect ratio and let the player figure out the correct width, but there was one converter (Youtube) that re-calculated the height instead when I uploaded such an MKV. :/
DSS2("dwangoAC-WIP-Epic-Pinball-05.mkv")
Add_PC_Scanlines(960) # only for 640x400
function Add_PC_Scanlines(clip src, int LineCount, bool "spline") {
src
PointResize(Width, Height * 6)
Mask = mt_lutspa(false, "y 6 % 0.01 < 0 255 ?")
mt_lutxy(Mask, "x y * 255 /", U=2, V=2)
y = LineCount
x = y * 4 / 3
return default(spline, false) ? BilinearResize(x, y) : Spline64Resize(Width, y).Spline36Resize(x, y)
}
Needs the MaskTools plugin.
Also instead of 600 MB RAM it takes much less now, though there may be a memory leak - not sure yet.
EDIT: No leak, just the frame cache filling up - use SetMemoryMax to restrict it.
Wait, how does just setting the aspect ratio flag to 4:3 not fix this?
Edit:
After talking to Ilari on IRC, apparently the native resolution is 640x480. Here is a sample:
There is no need to add scanlines!
Wait, how does just setting the aspect ratio flag to 4:3 not fix this?
A CRT screen has a certain look that I want to preserve/emulate. It leaves a bit of space between the drawn lines, so that the aspect ratio becomes 4:3. These "empty" lines are only 20% as high as a drawn line.
Aktan wrote:
After talking to Ilari on IRC, apparently the native resolution is 640x480. [...] There is no need to add scanlines!
Text mode is 640x400: 80x25 characters, each 8x16 pixels in size.
Afaik the game runs in Mode 13h, which is 320x200. A video of the game recorded in DOSBox has that resolution.
The actual game itself actually runs as 320x240 which then gets upscaled to 640x480 due to clock halving and doublescanning being enabled (VGA BIOS sets those options and upscaling is done by VGA card).
I just checked what is the actual size of frame 10.015s into the movie (this is about the time ball has left the plunger lane) using actual raw emulator dump output. It is 640x480.
Note: Some games use different resolution in menus and in actual game. One should look what the resolution is in actual game.
Note: Some games use different resolution in menus and in actual game. One should look what the resolution is in actual game.
Yeah, my bad. The menu was 320x200 while the game is 320x240.
This also explains why some pixels in the video file seemed a bit off.
So this filter doesn't have to be used for most of the run, but it might still be useful for the lower-res parts to make the video uniformly 4:3.
So this filter doesn't have to be used for most of the run, but it might still be useful for the lower-res parts to make the video uniformly 4:3.
I doubt sometimes having scan lines would improve the movie. Also, if you're going for authenticity, how does the computer deal with it? I'm pretty sure it uses a stretching algorithm, so we should use it as well.
Scan lines occur due to limitations in the monitor, and don't have anything to do with the actual image displayed.
I doubt sometimes having scan lines would improve the movie.
But that's what you see on a real CRT.
Scepheo wrote:
Also, if you're going for authenticity, how does the computer deal with it? I'm pretty sure it uses a stretching algorithm, so we should use it as well.
What computer - the emulated one? It doesn't stretch at all, it just writes to the graphic card's video memory. The graphic card generates a signal that contains the brightness information for each electron cannon (R, G & B), and the CRT distributes that evenly across the surface. The lines aren't stretched at all; they just have more or less space between them.
Scepheo wrote:
Scan lines occur due to limitations in the monitor, and don't have anything to do with the actual image displayed.
They increase the image height a bit. Without them the video would have to add black bars at the top and bottom.
Just a bilinear stretching from 400 to 480 doesn't look that good, imo.
What computer - the emulated one? It doesn't stretch at all, it just writes to the graphic card's video memory. The graphic card generates a signal that contains the brightness information for each electron cannon (R, G & B), and the CRT distributes that evenly across the surface. The lines aren't stretched at all; they just have more or less space between them.
So what happens if you were to hook it up to an LCD display? You may consider "what you would see" to be the most authentic. But, considering no encode so far has used filters to make it look like it was being played on an actual television set, it appears that the main view is that the signal, as produced by the graphics card, is the most authentic. And this signal does not contain the scan lines.
So what happens if you were to hook it up to an LCD display?
The same what would happen if you run your LCD monitor not at its native resolution: depending on how it's configured, it either blurs the image over the entire area, or only a few lines are duplicated (like this (background) or this (text)).
Scepheo wrote:
You may consider "what you would see" to be the most authentic. But, considering no encode so far has used filters to make it look like it was being played on an actual television set, it appears that the main view is that the signal, as produced by the graphics card, is the most authentic. And this signal does not contain the scan lines.
On a TV there's always the NTSC standard which defines the maximum number of lines, so in the worst case parts of the recording can be upscaled to that height. Usually that's when interlaced and progressive are used in the same game, and the progressive parts can just be doubled vertically.
The problem is that the PC allows very different vertical resolutions. All resolutions must be converted to a common one. (This was discussed here before.) Even DOSBox doesn't encode them into the same AVI file. You either have to apply some stretching or add black bars, and I think there is another, better alternative.
If the following points apply:
- the TAS is on the PC
- the TAS includes [200 or 400 lines] AND [240 or 480 lines] graphics modes
- the final encode will be a HD encode
...then the method posted above could be used.
The problem is that the PC allows very different vertical resolutions. All resolutions must be converted to a common one. (I think this was discussed somewhere here before.) Even DOSBox doesn't encode them into the same AVI file. You either have to apply some stretching or add black bars, and I think there is another, better alternative.
As much as I may agree with you on the fact that adding black bars is a bad option (it looks hella ugly), I don't feel that adding scan lines is a good option as well. Mostly due to the fact that it makes the encode look inconsistent, as it will have parts with, and parts without scan lines. I therefor feel that stretching is the best option, using whatever algorithm most resembles the actual result on a computer. It may not look as pretty, but it will look a lot more consistent.
As much as I may agree with you on the fact that adding black bars is a bad option (it looks hella ugly), I don't feel that adding scan lines is a good option as well. Mostly due to the fact that it makes the encode look inconsistent, as it will have parts with, and parts without scan lines. I therefor feel that stretching is the best option, using whatever algorithm most resembles the actual result on a computer. It may not look as pretty, but it will look a lot more consistent.
On a real CRT there is a transition period: when the monitor goes blank for a second.
I'm sure we can simulate that too quite easily. :)
But joking aside... different modes will always look slightly different from each other, no matter what solution is chosen. In the end the decision over "which poison" would then lie with the encoder.
If you scale eg. a 320x200 original video material (which is supposed to have an aspect ratio of 4:3) into, let's say 1024x768 (using stretching), then you will be basically emulating what a CRT supporting the latter resolution is doing when the graphics card is sending it a 320x200 pixels image. The blurriness/pixel doubling caused by the uneven stretching is minimized when the final image has a much higher resolution than the original.
Of course it also means that the video would then have to be distributed in that 1024x768 resolution (scaling it down to eg. 320x240 would "antialias" the image, probably in an undesirable way).
If you scale eg. a 320x200 original video material (which is supposed to have an aspect ratio of 4:3) into, let's say 1024x768 (using stretching), then you will be basically emulating what a CRT supporting the latter resolution is doing when the graphics card is sending it a 320x200 pixels image. The blurriness/pixel doubling caused by the uneven stretching is minimized when the final image has a much higher resolution than the original.
Of course it also means that the video would then have to be distributed in that 1024x768 resolution (scaling it down to eg. 320x240 would "antialias" the image, probably in an undesirable way).
Naturally, though 960x720 (720=3*240) is a bit better for HD.
convert_VGA.avsiinfo.txt
AviSynth script to convert video clips to a common resolution. Optionally it can add scanlines and/or remove the 9th column of text characters (disabled, enabled).
There is no need to add scanlines!
