Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Capturing Video

Reply
 
Thread Tools Search this Thread Display Modes
Old 3rd October 2010, 06:53   #21  |  Link
Robert Martens
Registered User
 
Join Date: Feb 2010
Location: New York
Posts: 116
Quote:
Originally Posted by radorn View Post
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.
Robert Martens is offline   Reply With Quote
Old 3rd October 2010, 09:34   #22  |  Link
radorn
Registered User
 
Join Date: Dec 2003
Posts: 33
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/web...4?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
Quote:
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.
radorn is offline   Reply With Quote
Old 3rd October 2010, 10:25   #23  |  Link
scharfis_brain
brainless
 
scharfis_brain's Avatar
 
Join Date: Mar 2003
Location: Germany
Posts: 3,653
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.
__________________
Don't forget the 'c'!

Don't PM me for technical support, please.
scharfis_brain is offline   Reply With Quote
Old 3rd October 2010, 13:07   #24  |  Link
radorn
Registered User
 
Join Date: Dec 2003
Posts: 33
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.

Last edited by radorn; 4th October 2010 at 03:16.
radorn is offline   Reply With Quote
Old 4th October 2010, 10:01   #25  |  Link
Ghitulescu
Registered User
 
Ghitulescu's Avatar
 
Join Date: Mar 2009
Location: Germany
Posts: 5,769
Quote:
Originally Posted by radorn View Post
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).
Ghitulescu is offline   Reply With Quote
Old 4th October 2010, 16:45   #26  |  Link
pandy
Registered User
 
Join Date: Mar 2006
Posts: 1,049
there is no interlace pulses so TV work in progressive way - both fields are displayed in same place - not shifted by half each other.
pandy is offline   Reply With Quote
Old 4th October 2010, 18:18   #27  |  Link
scharfis_brain
brainless
 
scharfis_brain's Avatar
 
Join Date: Mar 2003
Location: Germany
Posts: 3,653
even with a slowish 500MHz Processor one should be able to capture full sized video without framedropping.

Have a look for VirtualVCR and HuffYUV.
__________________
Don't forget the 'c'!

Don't PM me for technical support, please.
scharfis_brain is offline   Reply With Quote
Old 6th October 2010, 14:22   #28  |  Link
radorn
Registered User
 
Join Date: Dec 2003
Posts: 33
Quote:
Originally Posted by Ghitulescu View Post
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.

Quote:
Originally Posted by scharfis_brain View Post
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.

Last edited by radorn; 6th October 2010 at 14:33.
radorn is offline   Reply With Quote
Old 11th October 2010, 15:30   #29  |  Link
2Bdecided
Registered User
 
Join Date: Dec 2002
Location: UK
Posts: 1,673
Quote:
Originally Posted by radorn View Post
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.
2Bdecided is offline   Reply With Quote
Old 18th October 2010, 02:32   #30  |  Link
jmac698
Registered User
 
Join Date: Jan 2006
Posts: 1,867
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
Code:
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/h2obses...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

Quote:
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!

Last edited by jmac698; 18th October 2010 at 03:48.
jmac698 is offline   Reply With Quote
Old 18th October 2010, 03:52   #31  |  Link
jmac698
Registered User
 
Join Date: Jan 2006
Posts: 1,867
Found a hint as to why 240p is captured in modern video decoders:
Quote:
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.
jmac698 is offline   Reply With Quote
Old 18th October 2010, 11:16   #32  |  Link
Gser
Registered User
 
Join Date: Apr 2008
Posts: 418
Emulators PERIOD. No analog noise - no interlacing - pick your rendering resolution - Anti-aliasing
Gser is offline   Reply With Quote
Old 18th October 2010, 12:51   #33  |  Link
Ghitulescu
Registered User
 
Ghitulescu's Avatar
 
Join Date: Mar 2009
Location: Germany
Posts: 5,769
Quote:
Originally Posted by jmac698 View Post
Wow, the confusion here. The c64 and probably other old consoles produce *only* odd NTSC fields/ bottom fields/ even PAL fields.
Thanks!
Ghitulescu is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 09:35.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.