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. |
|
|
Thread Tools | Search this Thread | Display Modes |
3rd October 2010, 06:53 | #21 | Link | |
Registered User
Join Date: Feb 2010
Location: New York
Posts: 116
|
Quote:
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. |
|
3rd October 2010, 09:34 | #22 | Link | |
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:
|
|
3rd October 2010, 10:25 | #23 | Link |
brainless
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. |
3rd October 2010, 13:07 | #24 | Link |
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. |
4th October 2010, 10:01 | #25 | Link | |
Registered User
Join Date: Mar 2009
Location: Germany
Posts: 5,769
|
Quote:
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). |
|
4th October 2010, 18:18 | #27 | Link |
brainless
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. |
6th October 2010, 14:22 | #28 | Link | ||
Registered User
Join Date: Dec 2003
Posts: 33
|
Quote:
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:
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. |
||
11th October 2010, 15:30 | #29 | Link | |
Registered User
Join Date: Dec 2002
Location: UK
Posts: 1,673
|
Quote:
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. |
|
18th October 2010, 02:32 | #30 | Link | |
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* 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:
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. |
|
18th October 2010, 03:52 | #31 | Link | |
Registered User
Join Date: Jan 2006
Posts: 1,867
|
Found a hint as to why 240p is captured in modern video decoders:
Quote:
|
|
Thread Tools | Search this Thread |
Display Modes | |
|
|