Post subject: Scanlines (maybe better than just stretching)
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
In the "Epic Pinball" TAS, the blue android in the background seems to be not tall enough - the artist probably took the monitor's 4:3 screen area into account. The video is 640x400, but should be 640x480 with the correct aspect ratio. Unfortunately just adding 80 lines looks very unnatural. The correct way would be to add one blank scanline after 5 image lines, and scale the result back down to a resolution that the user's monitor can display.
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.
Player (208)
Joined: 7/7/2006
Posts: 797
Location: US
I agree that this issue be addressed in an encode (if not too much hassle). I also noticed that the android was looking a bit stocky.
Post subject: Re: Scanlines (maybe better than just stretching)
Senior Moderator
Joined: 8/4/2005
Posts: 5769
Location: Away
creaothceann wrote:
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.
Post subject: Re: Scanlines (maybe better than just stretching)
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
moozooh wrote:
creaothceann wrote:
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.
Senior Moderator
Joined: 8/4/2005
Posts: 5769
Location: Away
Wait, why specify a playback size that high?
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
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. :/
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
Faster vesion, thanks to the guys at doom9.org:
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.
Publisher
Joined: 4/23/2009
Posts: 1283
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!
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
Aktan wrote:
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.
Publisher
Joined: 4/23/2009
Posts: 1283
But the screenshot I posted looks completely fine. How do you explain that?
Emulator Coder, Skilled player (1140)
Joined: 5/1/2010
Posts: 1217
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.
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
Ilari wrote:
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.
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
Slightly faster version:
function Add_PC_Scanlines(clip src, int LineCount, bool "spline")  {
        src
        o = PointResize(Width, Height * 6)
        BlankClip(o, 2).mt_lutspa(false, "y 6 % 0 == 255 0 ?")
        mt_merge(o, BlankClip(o), PointResize(Width, Height))
        y = LineCount
        x = y * 4 / 3
        return   default(spline, false)  ?\
                 BilinearResize(x, y)    :\
                 Spline64Resize(Width, y).Spline36Resize(x, y)
}
Player (142)
Joined: 7/16/2009
Posts: 686
creaothceann wrote:
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.
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
Scepheo wrote:
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.
Player (142)
Joined: 7/16/2009
Posts: 686
creaothceann wrote:
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.
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
Scepheo wrote:
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.
Publisher
Joined: 4/23/2009
Posts: 1283
I must say though, good work creaothceann on making such an Avisynth script. I may come in handy for me in the future.
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
Thanks. :) I only created the first one though; the others are from this thread: http://forum.doom9.org/showthread.php?t=156658
Player (142)
Joined: 7/16/2009
Posts: 686
creaothceann wrote:
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.
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
Scepheo wrote:
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.
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
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).
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
Warp wrote:
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.
If you replace 'CRT' with 'TFT' then I'd agree. Anyway, that would result in textmode characters without gaps. :/
Warp wrote:
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.
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
convert_VGA.avsi info.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).
Publisher
Joined: 4/23/2009
Posts: 1283
cool, sounds useful