last day (15 days later) » 

17:31
12
Q: Why would any "local" video signal be "interlaced" instead of progressive?

KyndelAs I had understood things, "interlaced" video was nothing but a clever way to save data bandwidth by only sending every other line, swapping between starting on line 0 and 1 for every frame, in order to exploit the fact that TVs worked physically in a way which made this work. But why would a ga...

You have to also consider the amount of digital bandwidth available for the computer to convert a bit-mapped display into a real-time analog video signal.
I "guess" it "pays off" to "save" "bandwidth" even with "local" "connections".
The chances are the best for the monitor/tv being able to handle interlaced as the first choice., so you can see what you are doing. You can then tell the console to change the video format to something else, and revert back to the interlaced format if the format wasn't supported.
@ThorbjørnRavnAndersen Before ED or HD TVs, you were kind of expecting your standard TV to work with both standard interlaced formats, and also work with non-standard progressive signals of C64 or NES.
The point is that for analog TVs, there was no alternative. You wanted to connect any kind of computer to an analog TV in the 80s, you had to send an interlaced signal, because no other format was accepted. Though most home computer cheated and only sent the first half-image, halving vertical resolution.
17:31
@Justme That is not how I remember it (that in itself does not say much though). As late as the Wii initial signal was interfaced, and progressive modes had to be explicitly enabled with falling back if it could not be seen. I guess there was good reason for Nintendo not going progressive immediately. I had a Sony Triniton which could handle everything the Wii could show.
@ThorbjørnRavnAndersen That's because it will output 480i SD format to standard TV, and through component cable, it can output 480p ED format, which is in no way compatible with standard SD TVs. That's equivalent of feeding a 1080p signam to a TV or monitor that can only support 1080i or 720p.
@dirkt But sending only one half-image means you are sending progressive. Like C64 and NES do. So you don't have to send interlaced signal to a TV, most worked fine with C64 and NES progressive.
@Justme it's a matter of definition: the TV accepts interlaced, with each half-image being progressive. So if you are only sending one half image all the time, you are only sending every second line all the time, and you are loosing the vertical resolution of the TV mode, which is interlaced. The signal itself is still interlaced: It uses the vertical blanking bumps to decide between even/odd half-image. No way around that. And yes, it works fine, but again: the whole "point" is that the TV doesn't accept anything else.
@dirkt The signal itself is either interlaced (half offset between fields) or progressive (no half offset between fields). What contents is sent in each field is another matter. You can send 240p progressive, or you can send 480i interlaced fields with same 240p content on both fields, or send 480i interlaced fields with actual 480i content. I will again repeat, most home computers and consoles such as C64 did not send interlaced signal, but non-interlaced, so TV can't and will not show that as interlaced. E.g. PAL C64 sends non-interlaced signal with exactly 312 lines in each field, so 288p.
The channel bandwidth is the same regardless of whether or not there's an antenna involved.
@hobbs No it really isn't, because the composite video must be bandwidth limited due to RF channel usage. NTSC has that limit at 4.2 MHz and there are 3 different channel bandwidths for PAL, and e.g. passing composite video between devices in a TV studio or from game console to TV does not need to have the same limitations as RF signal. Even less relevant if you use S-Video or component YPbPr or RGB interface.
17:31
@justme you are just using a different definition. For me, a signal is interlaced if it allows to send different fields for half-images, and if there is an indicator that determines which half image it is. Which is the case for the analog TV signal, and which is the only format the TV understands, so you got to use it. For you, a signal is interlaced if it actually contains both half images. And according to your definition, the point the OP is asking about actually never happened - very few computers actually sent both half images, so the "local" signal was always "progressive".
@dirkt No I am not using a different definition. Either the electrical video signal itself defines an interlaced format (312.5 lines per field) such as standard TV broadcast or non-standard non-interlaced format (312 lines per field) such as C64 and NES so it can't be interlaced. Even if C64 and NES would send standard interlaced format, they likely would send same data on both odd and even fields, so it would flicker due to interlacing, which is the reason they do not even send an interlaced signal, and TVs generally understands that non-standard non-interlaced signal just fine.
@Justme have a look at e.g. this. The signal contains a different number of pre- and post-equalizing pulses on vertical sync depending on the field. The C64/NES/Apple send this format, and they send the number of pulses for one field all the time. So e.g. instead of sending a second "odd" field, they send the even field again. But it still contains the marker for even/odd. Your "non-standard non-interlaced" signal is an interlaced signal., with all the markers. That's where your definition differs from mine. EOT?
@dirkt But that's exactly where you are wrong. You seem to assume that C64 or NES sends out a signal that can contain markers for even/odd fields, but it would require field length of 312 and a half lines to get 625 lines per two fields to have an half line offset for the interlacing. They don't. They output exactly 312 lines per field or 624 lines per two fields so it can't contain information to distinguish odd/even fields as it is a non-interlaced signal where all fields are identical and have no half line offset. The key part making the interlace is having 625 lines per two fields.
@dirkt: Many computers never output mid-line sync pulses, instead generating horizontal and vertical sync independently and producing a composite sync pulse by xor'ing them together, which cases horizontal-sync edges to occur somewhat late within the vertical sync pulse.
@Justme: Unfortunately, not all video chip designers understood this, and some offer an "interlace" mode which alternates between e.g. 261.5 and 262.5 lines rather than using a consistent field rate.
@Justme You are again back to your definition "it's non-interlaced because all fields are identical". But each field contains the marker that says "start on the even line" by virtue of timing and sync pulses. You could equally well make identical fields that all start on the odd line. And since you can do that, and since the signal still contains only half the possible lines, it's an interlaced signal (according to my definition, but not yours). It does not have to contain different fields to be an interlaced signal. I am sorry, I can express it any simpler... No really EOT.
17:31
@dirkt It will not be interlaced if you draw only on even lines or only on odd lines, because then the each field must have a length of integer amount of lines, as interlaced requires each field to be integer plus half a line in length for them to have offset of half a line between fields. Which is why C64/NES both output 288p/240p non-interlaced syncs where each field is half a line shorter than standard 576i/480i interlaced TV broadcast. I also can't express it any more simpler than that, but that is how these devices work.
It is not really a compression, it is a tradeoff between spatial resolution and temporal resolution. Most modern videos on YouTube have about half the temporal resolution of an amateur VHS recorded in mid-90s. A good digital deinterlacing of such video would preserve the original 50 or 60 FPS of the VHS and interpolate the missing alternating lines.

last day (15 days later) »