Capturing LDTV 240p/288p s-video from retro game consoles

[radorn]

I'm using DScaler recording function to record 240p NTSC and 288p PAL video from Nintendo 64.
My problem is that I don't seem to get such an option.
The program does have an LDTV "deinterlacing" mode called oldgame, which treats each field as a full frame, as it should be, but when it's about capturing, I don't have such an option.
I only get 4 options:
capturing odd fields
capturing even fields
capturing blended fields
or capturing interlaced.

What I want is capturing the full 50fps of PAL and 60fps of NTSC LDTV modes.
I could record interlaced and then somehow work out the way of separating the fields, but my system is too slow and I suffer from dropped frames in interlaced mode.
I'm also not using vdub and others because the drivers don't seem to work in my current system but DScaler's direct access to the bt878 card does.
I'm using huffyuv as codec with the fastest settings.

[Ghitulescu]

Am I mistaking or the N64 has only composite and S-Video outputs? In this case they should be NTSC/PAL compatible, that means you can safely use interlaced for capturing.

[radorn]

Thanks for trying to help, but you are missing the point.

Do you know what LDTV is? the standard display mode in NTSC and PAL analog video signals is indeed interlaced, but all retro consoles use something else most of the time. Something called, LDTV (Low Definition TeleVision, as opposed to SDTV, Standard... etc).
In this "mode" vertical sync signal's amplitude is shifted slighty so instead of each field falling in a different physical place of your CRT, they are displayed on top of the previous one. always the same place.
This provides a half resolution picture, but PROGRESSIVE. These modes are commonly known as 240p@60hz for NTSC (480/2) and 288p@50hz for PAL (576/2).
This has been in use for ages by old game consoles and tv attatched computers, and I would like to capture video in this format.
I just need a capture program that allows for it.
DScaler, which I'm using to access my bt878-based card, has a "deinterlace" mode called OldGame, which does just that... it interprets each field as a standalone frame, just half the resolution of a "standard" one, but unfortunatelly doesn't seem to offer the same capability for capturing, even if I have it activated.

I COULD "SAFELY" capture in interlaced and then find a way to restore the half resolution progressive "field-frames" IF my computer could do it without dropping massive ammounts of frames, but it can't.

[Ghitulescu]

I'm missing the point. Really. Unless you're talking about a sort of hardware BOBing (like that used for playing VCDs, which are also 288p bzw. 240p), yes, indeed, I'm missing the point. Because it's illegal to use video signals other than PAL/SECAM/NTSC to feed a normal TV set, which TV set has no "game adapter" or a "game setting". Because a TV is obliged to fulfil the requirements of one or more TV standards, and these are NTSC/PAL/SECAM. Like any other cable or device that connects to a TV set.

In case it's a hardware BOBing, then you can safely capture one field only (and probably resize the width to 352, or double the heigth).

PS: while I have no idea how N64 works, other old computers (like Sinclair, Commodore etc.) used the same principle as said above.

PS2: Hopefully you're not talking about this LDTV, right? -> http://uncyclopedia.wikia.com/wiki/LDTV :)

[pandy]

In this "mode" vertical sync signal's amplitude is shifted slighty so instead of each field falling in a different physical place of your CRT, they are displayed on top of the previous one. always the same place.

VSYNC amplitude is same - only timing relations are different - it is more like 524 or 526 (PAL 624 or 626) lines video without half line (interlace) - both fields are exactly the same, video frequency is usually bit lower/higher than specified by PAL or NTSC standard but analog TV can deal with such signal without problems.

Capture can be difficult because You need special capture mode (ie different than standard 525/625 lines).

[2Bdecided]

Because it's illegal to use video signals other than PAL/SECAM/NTSC to feed a normal TV set, which TV set has no "game adapter" or a "game setting".An interesting use of the word "illegal" - will the police be around?! :)

Anyway, you'd be amazed what standard TVs will happily display, including these vintage non-interlaced modes.

Until recently, some video encoder chips would still happily generate these modes if required - you just had to set the registers correctly. e.g. this one:
http://www.datasheetcatalog.org/datasheet/Conexant/mXtxsur.pdf
see section 3.1.7. Sadly no relevant waveform images in this document, though I'm sure I've seen one in the spec for another chipset.

Cheers,
David.

[Robert Martens]

Anyway, you'd be amazed what standard TVs will happily display, including these vintage non-interlaced modes.

I can't offer any DScaler advice to the OP off the top of my head, but I can confirm that I've seen this behavior with my own equipment.

All of my Super Nintendo and Playstation games (I've toyed with several, but Secret of Mana and Silent Hill come to mind as examples), and a few PS2 titles (namely Ico) seem to use this "LDTV" output mode. When connected to my old NTSC CRT TV, whether by its composite or component inputs, you can plainly see what appears to be only one field. There's a line of picture data, then a blank space, another line of the picture, another blank, and so on. The field is rock solid, in stark contrast to normal interlaced content, where the lines look like they're scrolling (either up or down, depending on how your eye/brain catches them).

I've also connected the same consoles to my plasma display, which pops up a little info box when you switch to a given input, describing the signal coming in. It shows 1920x1080i, 1280x720p, and 720x480i/p for most TV that I watch, but in the case of these older game systems it shows 720x240. That is, at least until the game switches graphics modes, whereupon the box pops up again; the aforementioned Silent Hill uses 240 lines for the game itself, but 480 for the inventory and map screens. Rather annoying, and one of the reasons I've elected to keep the old TV.

Testing the capture of these signals with my Liquid Pro breakout box, I found that it decides to store every two fields as one frame, even when they have the same alignment. I wouldn't have thought the video signal could be 720x240 and also 60Hz (I'd have expected 30), but the plasma's info pop-up says "720x240 @60Hz", and when examined by eye after a SeparateFields(), each field does indeed appear to be unique.

I'm not familiar with DScaler yet, but I have all these game systems lying around, including an N64; I could play with it for a bit and see if I can offer any assistance.

[Revgen]

If you own the games you are trying to capture, you can rip the game using a game copier, and use an emulator like UltraHLE, Nemu64, or Project64. Project64 is the best one. http://www.pj64-emu.com/

The 3 most prominent copiers are z64, c64, and Doctor V64. They aren't sold anymore, so you'll have to search for one on ebay.

After that, you can use a DirectX capping app like FRAPS to capture the 3D content through the emulator.

[TheSkiller]

the aforementioned Silent Hill uses 240 lines for the game itself, but 480 for the inventory and map screens.Yes, I experienced the same kinds of behaviours (especially with the game Silent Hill of which I'm a big fan btw). But when it comes to capturing these signals, everything is pretty much the same like always (576/480 lines at 25/30 fps), except that the synchronisation seems to be rather weird causing VirtualDub having to kick in resync heavily after about 30 seconds of recording making the first 2:30 minutes of recording slightly out of sync (this doesn't seem to happen to capture devices that have integrated audio capture). I noticed this with various capture devices with both PAL and NTSC Playstation 1 games.

But those fields don't have to be aligned so that the captured *frame* looks progressive, they can (and do) switch between phase shifted and "progressive" (technically they're interlaced as all signals are, even if every other field is a duplicate of the previous one).

Edit: As long as there is not a part in the captured video that was rendered in "interlaced/full line mode" one can use the following to kill the phase shifts without damage.
PointBob() #part of the MVbob package
SelectEven()

[Ghitulescu]

Illegal is often used in standards to define values or aspects that are not allowed to exist. Besides, the police[wo]men are not allowed to interpret the law (that should be the core business of the justice), ideally they should act only in clear cases.

The ability to do a thing has nothing to do with the enforcement of a standard or a law.

[radorn]

the video signals output by n64, psx etc, most of the time doesn't differ from standard SDTV in anything but the fact that each field is projected in the same position of the screen instead of alterating positions. that is, it's progressive and not interlaced.
NTSC LDTV = 240p
PAL LDTV = 288p
AND each field is as a full frame, just half the usual resolution.
I could capture it as interlaced and then try to find how to separate the fields into the proper 240p@60hz or 288p@50hz, but my system's performance causes too much framedropping when capturing interlaced. I don't want to use the options for disregarding either field as this would mean losing half the frames, as in LDTV each field is a frame in itself.

If someone knows how to do this, be it with DScaler or whatever, please, do tell.

anyway, there are games for these systems that sometimes also use standard interlaced modes, most of the time for menus.
For example, n64's turok2 hirez is 480i/576i, but not so PD's hirez, which only augments horizontal resolution but is still 240p/288p.
Majora's Mask uses interlaced mode for the appointment book screen, but ldtv for the rest of the game.
I haven't played that much psx, but I have seen many 480i menus, for example in gran turismo.
I have read that snes can also do 480i, but that it hampers performance so much that it's only seldomly used, for menus in very few games or some text games and such.

@Robert Martens: I'm interested in knowing what plasma is that you talk about.

[Robert Martens]

technically they're interlaced as all signals are, even if every other field is a duplicate of the previous one

That may be the case for some games, but after my admittedly less-than-expert testing I find it depends on the game. Using Silent Hill as the example once more, I captured footage through the aforementioned breakout box as Lagarith YUY2 in VirtualDub (which was a pleasant discovery, as what I'd gathered from the Liquid user community was that the box didn't work outside of the NLE; turns out it's just another DirectShow capture device). It has integrated audio capture, and the resulting file plays back without any sync issues as far as I can tell.

When I load it in AviSynth, however, and do a SeparateFields(), I find that although most frames are essentially duplicates (with only slight variations introduced by analog capture noise), I'll sometimes have three or four fields in a row that are different. They exhibit "tearing", as I believe it's called, where there's a switch to a new image partway through drawing the first one. I'd tend to think this is the result of the game engine itself either switching or duplicating frames, as necessary, and not any problem with the video signal or capture device, only because there are certain parts of SH that feature dramatically smoother image rates. I'd have to play through the game again to find them, but if I remember correctly the piano room in the school, where you get the silver medallion, is one of them. As soon as you enter, the camera moves, and everything seems much more fluid. The bathrooms, also in the school, feature this behavior as well, I think.

And then there's the inventory and map screens; the PointBob function, which I appreciate you pointing out to me, works well enough on gameplay, but shows chunky text and graphics in the inventory. Trimming to those segments of the clip and doing a proper deinterlacing produces much clearer results.

Then there are other games, like Tomb Raider, which I tried earlier today, which seems to be largely progressive segmented frame, where pairs of fields represent two halves of the same time sample, despite being spread across frame boundaries (the bottom field of one frame goes with the top field from the next, I don't know what I'm screwing up to make it do that).

But don't get me wrong, I don't profess any expertise in the field of video engineering, I'm just intrigued by the results I've been getting while experimenting with these tools. If it would help better explain myself, I'd be happy to share a few snippets of my current captures, and produce new ones, if that's allowed under Doom9 rules. I know the games themselves are copyrighted content, but does the video generated by the consoles qualify as well?

@Robert Martens: I'm interested in knowing what plasma is that you talk about.

It's an Emerson PL-P42W-10A, which talk of the internet suggests is a rebadged Samsung (I see the model number PN42B400 come up, but I couldn't tell how accurate that is). Nothing special, just a Black Friday Wal-Mart special that I got as a Christmas gift last year. At only 1024x768, it's not top of the line, but considering the bitrates my cable TV uses, it's not the end of the world for image quality.

And as a gift, I got it for free, so I'm most certainly not complaining. :)

I'm sorry to say I'm not set up with DScaler just yet. Got it to display video from my capture device, but audio is problematic, and the software is locking up regularly. VirtualDub can see and capture both video and audio from this thing, though, so I'm fairly confident it's just a configuration issue that I need to sort out.

If I may ask a stupid question though, radorn, you say you have a BT878 based device, have you tried the "BT8X8 Tweaker (http://server4.doom9.org/index.html?/capture/bt_tweaker.html)" option in VirtualDub? I stumbled across it earlier today when fiddling with some capture settings of my own, and it seems like it might allow VDub to access your device. Somehow. I have no experience with that, and really I'm still a newbie when it comes to capture hardware, so take that with a grain of salt.

[radorn]

well, I have reached a probably unsurprising conclusion.
It doesn't matter how the field timing/sync is in the input signal, the bt878 will always capture full interlaced frames. It just doesn't offer a way of capturing fields separatelly, or at least the drivers dont, or something like that.
The only way of restoring the proper LDTV stream is postprocessing, so I have no other way than try to get interlaced captures to work at a reasonable rate and separate fields later.

...unless someone knows otherwise...

[Ghitulescu]

As I said, there are no fields in the PAL/NTSC/SECAM except for displaying purposes. The smallest addresable unit is the frame*. Due to technical limitations of the video-chain in the '40ies they split the frame in two fields. How a particular device outputs a single field depends on its settings and/or its designer, but what it would output would always be a frame if the signal has to be NTSC/PAL/SECAM compatible. It seems to be a great confusion here concerning progressiv vs. interlaced and what a system requires vs. what the content is.
Example: PAL-spedup movies are progressive in content (both fields of a frame describe a full film frame), yet they are sent interlaced over composite/S-video.
Whether a device makes use of one field only or a full frame, it doesn't matter, it would send always two fields if NTSC/PAL/SECAM-compatible (the second field might be black, the copy of the first, or simply the other half of the image).
Because of the first paragraph above, most chip producers (especially for consumer class chips) see no reason in spending R&D resources to achieve something that rarely happens in practice.
So capture interlaced and discard the second field.

*while there are studio mixers that are able to combine the first field of the last frame of the first videoclip with the second field of the first frame of the second videoclip (blending), there is none AFAIK that would change the TF into BF or vice-versa.

[radorn]

Ghitulescu, have you ever played N64, PSX, Saturn, SNES, Megadrive/genesis, NES, MasteSystem, PC-Engine...?
I suggest you to connect that to a reasonably sized CRT and look closely at the screen and you'll soon realize that the picture is half resolution PROGRESSIVE compared to the usual interlaced projection. Plus, the other field is not "black, the copy of the first, or simply the other half of the image" as you suggest, but a standalone frame of it's own. They may be fields in PAL/NTSC terminology, but with just a little adjustement of the vertical sync signal, instead of projecting each field at an alternate height, they are all projected in the same place (progressive), thus, each field becomes a frame of it's own, even if it's technically a field according to the SDTV standard.

Given the performance of these old systems, most of the time they aren't capable of matching render rate (FPS) to screen refresh rate (50/60), so some consecutive "field-frames" (a term I just coined for the occasion) may have the same contents, but that's not always the case.
Discarding one set of "fields" is not an option to me.

[Ghitulescu]

There is not a 4th alternative to output progressive video with the aid of an interlaced system. It's either:

1 field with the whole image + 1 black field
1 field with the whole image + 1 copy of the same (line doubling)
1 half of the image + another half (like PAL-spedup for movies)

On the console itself is written PAL or NTSC and the connectors allow it to be connected to one of these TV sets. As long as PAL or NTSC is written onto it, it should be interlaced and one of the aforementioned mechanisms is used to provide an interlaced frame out of a progressive image.

Citing a net source (for NTSC):
235x224 to 640x480 flicker free interlaced screen resolution.

It doesn't matter if you believe me or not. Irrespective of your opinion the N64 outputs interlaced TV signals. Either way of the 2 variants you are ok by capturing the frame and keeping one field only, the 3rd variant allows you to combine both fields into one progressive frame.

[Robert Martens]

radorn, I'm still banging my head against the wall trying to get DScaler to work with my capture device, but I'm not sure I'd be able to help you in any event. Thanks to this, I don't think you have a choice but to capture interlaced:

But those fields don't have to be aligned so that the captured *frame* looks progressive, they can (and do) switch between phase shifted and "progressive" (technically they're interlaced as all signals are, even if every other field is a duplicate of the previous one).

After some more testing, it finally clicked in my brain, and I think I understand this now; the consoles all put out interlaced signals, but sometimes both fields contain content representing the same vertical alignment. The CRT TV I was looking at is, it seems, phase shifting them to the same vertical position upon display, the plasma takes said phase shift into consideration when calculating the dimensions to display in its info box, and my capture device simply grabs the signal as is, accounting for the different results when viewing the signal through different devices.

I went ahead and put together a little comparison a few minutes ago, uploaded it to Mediafire, and only then had this little epiphany. Anyone interested in the sample clip can get it at http://www.mediafire.com/?20fivzn69ek1gv5 if they're so inclined.

It took me longer than I'd have liked, but I think the principle at work here has seeped through my thick skull after all. I appreciate everyone taking the time to explain this!

[radorn]

Thanks for the capture and high res video, Robertm, specially since I don't have a cam to do it myself. Let's hope stubborn know-it-all Ghitulescu can see it now.

F-zero X is a specially well suited game for this, since it's a known fact that one of it's strong points in the technical area is that it renders a very stable 60/50 (NTSC/PAL) frame rate with all 30 ships on screen, a goal for which the development team sacrificed a lot of texturing on the ships, complexity of environments, etc.

Ghitulescu, you can clearly see that the screen is non-interlaced, with black spaces between lines (since they are now projected at the same height always), and then the capture where you can clearly see the weave "artifacts" resulting of each "field" having picture information (ie, there's no "black fields"), and which is distinct from the other filed (so it's not a copy of the previous one NOR it's complement).
As I said, in LDTV each field functions as a separate consecutive frame (which may or may not contain actual new content depending on the rendering rate of the device generating the signal), but unlike standard video, all fields are projected at the same height instead of alternating, thus providing a PROGRESSIVE display, which is achieved by a compatible shift on the vsyc signal.

So, to use your same words: irrespective of your opinion the N64 outputs interlaced sdtv AND PROGRESSIVE LDTV.
Have a nice day.

For further material, if you can, robert, Majora's Mask seamlessly switches from 240p to 480i when you enter the bomber kid's notebook of appointments. It'd be worth to film that to show the difference to Ghitulescu ;)

[Robert Martens]

Actually, what I took away from my results was that Ghitulescu was correct; although the content of each field represents the same vertical position, the signal itself is still interlaced. Somewhere in that signal is a control flag (I'm woefully ignorant of the proper terminology here) that tells the display device "shift every bottom field up, so you draw them in the same spot as the top fields", or something similar. The TVs accomodate the instruction, and display things in the proper place upon receiving the signal, but capture devices--at least the ones you and I are using--ignore that information, and capture the video as is.

Of course, I could be completely wrong again, and I'm twisting my inferences into another tangled mess it'll take me years to unlearn. I can never tell.

I have a copy of Majora's Mask on hand, as a matter of fact, though I'm not sure I have any saved games on the cart or if I'll have to start from scratch. Actually, I have some Silent Hill recordings that show such a switch, but I'm now under the impression that, as TheSkiller tried to explain to me earlier, it's all interlaced, all the time, and the only thing changing is the phase, so I'm not sure what value they have.

In any event, you're welcome for the clips, for what they're worth.

[radorn]

there's no such "flag", robert.
in crts the vsync and hsync signals are "simple" sawtooth waveforms. at any given time, it's the voltage in these signals that deflects the electron beam from the canon and moves it across the screen's surface.
To achieve interlaced projection, the the level range of the vsync signal (50/60hz) is shifted.
Let's say (and I'm aware this description is highly inaccurate) that, for a PAL signal, we divide the full voltage range that the signal goes through (the amplitude) in 625 discrete points, each representing the discrete V values that the signal would have at the start of each line of a whole interlaced frame.
For the odd field, the aforementioned discrete values of V would be 1, 3, 5, 7... 625 and for the even field they would be 2, 4, 6, 8... 624.
That would cause the fields to be projected at different phisical places of the screen, creating the standard interlaced projection.
For LDTV, it would be as simple as using an identical range for all fields instead.
Analogue video is just a bunch of lines. there's no inherent interlacing in it other than what's caused by the proper sync signals.
In fact, analogue SDTV video is actually a continuous "line", a stream of voltage variances in 1 or more wires, projected as a series of lines on a CRT by moving the electron beam arround the screen some 15 thousand times from left to right and 50-60 times from top to bottom, and that movement is controlled by 2 sawtooth waveforms called vertical and horizontal sync.

Of course there's a lot more detail to it than that, but the insistence of ghitlescu in saying that it's impossible to evade interlacing is just wrong.

What I think that happens is that most capture hardware is designed to assume interlacing, so the sync signal information is not used in full. that is, the only thing it takes from the sync signals is to know WHEN lines and frames start and end. it's internal hardware synchronizes to that and generates it's own clock for the ADC sampler, but disregards the actual voltage values along the lenght of the wave.

This brings me to clarify my earlier interest in your plasma screen that seems to detect LDTV projection, robert.
I don't own anything other than CRTs so far (unless you cout my nintendo ds :p), so I have no experience with these, but after learning what LDTV was, I became a bit paranoid about buying some LCD/LED/Plasma/whatever sometime in the future and finding out it can't tell LDTV apart from SDTV. Your plasma being able to distinguish it got me interested ;) It probably has a good vsync "sensor"

[Robert Martens]

That would cause the fields to be projected at different phisical places of the screen, creating the standard interlaced projection. For LDTV, it would be as simple as using an identical range for all fields instead.

"Flag" was perhaps a poor choice of word on my part, but that "level range" you mentioned is what I was talking about; I understand that analog signals have no actual metadata carried with them, the way video files stored on a hard drive do, but there's nonetheless some portion of the signal that dictates how the display device is meant to show the video.

I've been extremely happy with the Emerson so far, but as I'm sure you can imagine, if the best you've got is composite connections from these older consoles, the results aren't exactly mindblowing. Component's a different story, but I'll still be hanging on to my old Trinitron until it drops dead.

[radorn]

Well, I got S-Video at least, and PAL color is not as bad as NTSC, specially when it comes to bleeding of the red color, for example, so picture quality is quite good.
N64 could be moded to RGB too, although rgb capturing hardware is expensive and I wonder how well will most flatscreens handle it.

Anyway, I may have to slighty correct myself on how odd/even fields are generated.
The input sync signals probably don't drive the CRT cannon deflectors directly in most setups, but rather the circuitry regenerates the signal, in which process the provided (IF it is provided) amplitude shifted vsync is regenerated and perhaps the shift is considered as noise (which would make it poinless to even provide it like that) since the regeneration is precisely intended to correct transmission errors.
It is undeniable, though, that the sync waveforms that go into the deflectors are amplitude shifted to achieve the correct positioning of each field in an interlaced display, but perhaps the way to signal that on the input video signal is not quite the same.

http://digital.ni.com/public.nsf/websearch/17A032D78871F03086256B610057C984?OpenDocument

That looks like a signaling for odd-even differentiation, and could be what the crt circuitry uses to shift the amplitude of the vsync it generates to drive the deflectors.

In this fashion, perhaps what makes LDTV work is using the same signaling (either odd or even) on all fields instead of alternating them.

I may be saying nonsense here though.

What I know for sure is that in n64 and all earlier TV game/computer systems, the most used display mode is LDTV, 240p for NTSC and 288p for PAL, where each field contains actual picture information (ie, not black/empty), where this information is independent of the previous projected field (ie, not a copy or complement of the previous one), and with a progressive projection, that is, one on top of the other.

Finally, I would like to quote wikipedia on this
http://en.wikipedia.org/wiki/Low-definition_television
Older video game console and home computers generated a nonstandard NTSC or PAL signal which placed both fields on top of each other. This is equivalent to 240p and 288p respectively. Conversely, the FCC forbade TV stations from broadcasting in this format. The Video CD format was introduced on such a console (CD-i), and it likewise uses a progressive LDTV signal (352×240 or 352×288), which is half the vertical resolution of SDTV.

With the introduction of 16-bit game consoles, 480i was supported for the first time, but rarely used due to limited memory and processing power. Thus, 240p remained the primary format used through the Playstation era.

More recent game systems tend to use only properly interlaced NTSC or PAL in addition to higher resolution modes, except when running games designed for older, compatible systems in their native modes. The PlayStation 2 generates 240p/288p if a PlayStation game calls for this mode, as do many Virtual Console emulated games on Wii.

There's a couple of links at the end of the article I'm sure I will be reading when I have some time to spare.

[scharfis_brain]

without having read the whole thread:

just capture such footage in interlaced mode (ie: 576i25 or 480i30).
(This will ensure having captured ALL data that was sent by the device)
Afterwards you just can use an AVISynth script to serialise the fields with separatefields().
Since the fields should belong to the same vertical position, no bobbing between the fields shall occur.
If it still does, you need to apply crop/addborders to the even or to the odd fields in order to align its vertical postion.

[radorn]

already reached that conclussion a few posts ago, but thanks, scharfis ;)
the problem is my system's performance is rather poor and I get massive framedropping... I'm working on improving that.

anyway, we definitelly need some solid info on how NTSC and PAL LDTV "modes" differ from the standard ones.

[Ghitulescu]

there's no such "flag", robert.
in crts the vsync and hsync signals are "simple" sawtooth waveforms. at any given time, it's the voltage in these signals that deflects the electron beam from the canon and moves it across the screen's surface.
To achieve interlaced projection, the the level range of the vsync signal (50/60hz) is shifted.
Let's say (and I'm aware this description is highly inaccurate) that, for a PAL signal, we divide the full voltage range that the signal goes through (the amplitude) in 625 discrete points, each representing the discrete V values that the signal would have at the start of each line of a whole interlaced frame.
For the odd field, the aforementioned discrete values of V would be 1, 3, 5, 7... 625 and for the even field they would be 2, 4, 6, 8... 624.
That would cause the fields to be projected at different phisical places of the screen, creating the standard interlaced projection.
For LDTV, it would be as simple as using an identical range for all fields instead.
Analogue video is just a bunch of lines. there's no inherent interlacing in it other than what's caused by the proper sync signals.
In fact, analogue SDTV video is actually a continuous "line", a stream of voltage variances in 1 or more wires, projected as a series of lines on a CRT by moving the electron beam arround the screen some 15 thousand times from left to right and 50-60 times from top to bottom, and that movement is controlled by 2 sawtooth waveforms called vertical and horizontal sync.

Of course there's a lot more detail to it than that, but the insistence of ghitlescu in saying that it's impossible to evade interlacing is just wrong.

What I think that happens is that most capture hardware is designed to assume interlacing, so the sync signal information is not used in full. that is, the only thing it takes from the sync signals is to know WHEN lines and frames start and end. it's internal hardware synchronizes to that and generates it's own clock for the ADC sampler, but disregards the actual voltage values along the lenght of the wave.

There is something there but not a flag as robert said. The vsynch signals are different so the display/recording device would know what to do with the incoming signal. There is no way to intentionally mix the TF with the BF, accidental (interferences, transmission errors) ones are solved with the arrival of the next field. In other words, each field has its own vsynch signal which decides what type it is (TF or BF).

Even if the consoles might mimic the progresive signal by sending only one field only (with the associated vsynch) the displaying device (or the recording one) would artificially recreate the missing field (black), unless the frame/field rate would be too low to be synched to it (it shouldn't occur, otherwise it won't be used).

[pandy]

there is no interlace pulses so TV work in progressive way - both fields are displayed in same place - not shifted by half each other.

[scharfis_brain]

even with a slowish 500MHz Processor one should be able to capture full sized video without framedropping.

Have a look for VirtualVCR and HuffYUV.

[radorn]

Even if the consoles might mimic the progresive signal by sending only one field only (with the associated vsynch) the displaying device (or the recording one) would artificially recreate the missing field (black), unless the frame/field rate would be too low to be synched to it (it shouldn't occur, otherwise it won't be used).

Ghitlescu, seriously, are you doing it on purpose or what?
Why do you insist in this missing field shit?
ALL THE FIELDS COMING OUT FROM THE CONSOLE contain PICTURE, ALL 50 FOR PAL AND ALL 60 FOR NTSC.
THERE'S NO MIMICKING, ARTIFICIAL RECREATION OR CRAP.
Yes, I use all caps because you are driving me mad with this.

Make me a favor and take some old tv attatched computer or console, capture fullframes and you'll see how each field contains actual picture, which contains differen data than the earlier one (unless the rendering rate can't keep up with screenrefresh), and then look at the same signal in a CRT, preferably a decently sized one so it's easy to see.
It's amazing how you keep insisting in these theories about empty, repeated or complementary fields. These, specially (or specifically) the last one, may be used for broadcast signals and DVDs for speeding up 24fps cinematographic material up to PAL framerate, but old tv computer and game consoles work differently most of the time.

even with a slowish 500MHz Processor one should be able to capture full sized video without framedropping.

Have a look for VirtualVCR and HuffYUV.

I'm already using huffyuv, and I find no difference in speed between virtualvcr and dscaler, but vvcr is harder to set up since dscaler has builtin support and advanced controls for bt878 and with vvcr I have to use the vfw controls and I get a constant stream of failures.
it's probably a problem with the OS installation. Need to get arsed and reinstall and see if I can make it better this time. I probably should be using win98 and not XP on this computer, but I find win98 insufficient for my daily computer usage. I need a new computer so I can have xp/7 in it and use win98 on this one for specific purposes.

[2Bdecided]

Ghitlescu, seriously, are you doing it on purpose or what?
Why do you insist in this missing field shit?
ALL THE FIELDS COMING OUT FROM THE CONSOLE contain PICTURE, ALL 50 FOR PAL AND ALL 60 FOR NTSC.
THERE'S NO MIMICKING, ARTIFICIAL RECREATION OR CRAP.
Yes, I use all caps because you are driving me mad with this.Ghitulescu isn't trolling you, but I'm amazed that he continued to keep his blinkers on while everyone else in the thread clearly gets what's happening.

It's not metadata or waveform voltages that drive this in the analogue video signal. It's actually very very very basic...

The signal has two types of sync pulses - one that says "this is the start of a line", and another that says "this is the start of a field". That's it.

The TV has two voltage sources which drive the position of the electron beam: One which increases linearly to drive the electron beam across the screen (horizontal deflection), and another which increases linearly to drive the electron beam down the screen (vertical deflection).

The horizontal deflection circuit is designed to increase the voltage from 0 to full in about 1/15625th of a second, and the vertical deflection circuit is designed to increase the voltage from 0 to full in about 1/50th of a second.

A sync separator grabs the sync pulses out of the analogue video signal. When it finds a line sync pulse, it resets the horizontal deflection circuit to 0. When it finds a field sync pulse, it resets the vertical deflection circuit to 0.

So the sync pulses in the analogue video signal directly drive the position of the electron beam as it scans the tube.

How do you get interlacing? You put alternate field-sync pulses half way along a line. That's it. That way, you get one field sitting half a line down from the other field.

How do you get progressive? You put all field-sync pulses at the start of a line (or the same position on a line). Then all fields line-up.


It's fractionally more complicated than that - few TVs let the deflection circuits free-run - most include PLLs in there fed by the sync pulses, to make them more stable and help them to work even if a spike of interference knocks out a sync pulse or two.

It's not "clever" at all - it's designed to make early TVs as "simple" as possible. The analogue video signal itself is the "clever" part. Problem is, modern digital devices aren't simplistically "driven" by the analogue signal (like CRTs are/were) - they assume they know what the signal should look like, and which bits they need to process. Anything non-standard can confuse them.


Sadly by the time the digitised video hits AVIsynth, the different sync pulse timing is long gone, and you'll have to figure out the best choice of separatefields(), changefps(), and bob() yourself for each scene.

A smart filter might be able to figure it out from the content (e.g. Didee's clever bobbers look for "bob typical" artefacts - LD progressive video won't have any) - I wonder if someone will write one? ;)

Alternatively, though the chipsets (at best) are treating it all as interlaced video, I bet somewhere deep in the capture device there's a flag or event or timer that says "this isn't quite normal interlaced video" - if you could get a driver to access this and pop a flag in the digital video stream to mark this which AVIsynth could later read (e.g. a white dot in the unused half line!), that would be perfect.

Cheers,
David.

[jmac698]

Wow, the confusion here. The c64 and probably other old consoles produce *only* odd NTSC fields/ bottom fields/ even PAL fields. This is 720x240 at 60Hz. The vertical sync is in the middle of the last line. So my guess is the capture driver is creating a false 480i signal by two *frames* of these bottom fields. Therefore the way to postprocess would be to split the odd and even lines then interleave them in time. So

assumebff() *true for most capture cards and avi*
separatefields() *get the 240p fields as each frame*
a=selectodd *get the first frames mod 2*
b=selecteven *get the second frames mod 2*
interleave(a,b) *put them together into 240p*
assumefps(59.94) *change to 240p @ 60hz*

Step through and if motion ever seems backwards, use assumetff.

I don't have a good explanation of why digital video decoders display such a signal, except that they don't care that only odd vsync's are present and just assume the second one is even. Anyhow it just works. I have a copy of all the standards somewhere but I'm not reading it now.

http://sites.google.com/site/h2obsession/CBM/C128/Interlace

And yes these machines can truly create 60 frames/sec. You can write a simple basic program to flash the screen and examine the captured output to verify.

This is also explained clearly on Wikipedia
http://en.wikipedia.org/wiki/Interlace

Since each field became a complete frame on its own, modern terminology would call this 240p on NTSC sets, and 288p on PAL. While consumer devices were permitted to create such signals, broadcast regulations prohibited TV stations from transmitting video like this.

Sidenote: I would guess that some people here are older engineers that grew up learning electronics in an analog way. There's nothing wrong with that - but I've seen how misunderstandings happen before, it's the way you learned and encoded information as rules of thumb that lead to an approximation that works in your practical work, however very few people know exactly how something works, but they try to explain it in terms of the rules of thumb, approximations, and memorized trivia they have learned.
This can create a mental block, as someone could say something true yet you disregard it because of a rule you learned. For example getting confused about "illegal" signals.
The only way to understand something truly is with a questioning, open mind, and re-examining assumptions. And such a thing is rarely required so we don't have practice in it.
There is nothing wrong with your approximation 99% of the time except in highly technical discussions like these!

[jmac698]

Found a hint as to why 240p is captured in modern video decoders:

The fast locking algorithm locks onto the first vertical sync it encounters, regardless
of where the internal timing counters expect a vertical sync to occur. It also disables
the hysteresis that is used for the field detection logic. As soon as the even/odd field is
detected, the field signal is updated to reflect that status.
The purpose of including this feature in chips is to enable the product to be marketed to e.g. security multiplexers/cameras that show several cameras at once. The fast locking allows you to switch between different sources that aren't genlocked and get the earliest possible video frame.

[Gser]

Emulators PERIOD. No analog noise - no interlacing - pick your rendering resolution - Anti-aliasing

[Ghitulescu]

Wow, the confusion here. The c64 and probably other old consoles produce *only* odd NTSC fields/ bottom fields/ even PAL fields.
Thanks!