2 Attachment(s)
Thanks to Hodgey from Norway.
The ATI eHome card is confirmed to have the Theater 200 chip on it. Using Graphedit on Windows XP I was able to capture audio and video in uncompressed 720x480 YUV and compressed MPEG2 formats to separate files. The video is pretty much what you would expect, crystal clear and stable with no frame drops. The audio is PCM. The data rate is what you would expect for uncompressed and the bit rate is selectable from the hardware encoder device driver properties sheet. Generic capture software like VirtualDub recognizes the card, but cannot capture audio or video. VLC recognizes the card, and can record, but cannot manipulate its crossbars. So there are problems with it. Perhaps with time these cards will be better understood. Since there are very few true PCI cards with the ATI Theater 200 chip on them, I thought this would be of interest. There are probably a lot more modern motherboards with legacy PCI support than AGP. I'd also like to see how far up the Windows version tree this 32 bit driver will go.. I believe Windows 7x32 worked at one time with the ATI TV Wonder USB2.0 perhaps it will work with this PCI driver as well. -- merged -- Upon further review of cards and pics. It seems the eHome has been redesigned several times, always with the Theater 200 chip, but sometimes without Input jacks for Composite or S-Video. There also appears to be an eHome TV Wonder VE edition. And a number of OEM only cards that did or did not require the Barney dock. I would not recommend people rush out and try finding this specific card at this time. There are too many unknowns about the TV Wonder line. Some have Connexant decoders, some have the earlier Brooktree decoders which Connexant bought out from a University. But there are definitely some OEM cards that have the Theater 200 chip and behave and use the eHome device driver under windows. -- merged -- First an apology to msgohan and hodgey from Norway. I got their names mixed up when referring to the person who put me on to this card. It was msgohan from Vancouver Canada that put me on to the card. I've had quite a lot of good progress on this card. Graphedit and VLC seem to work with it properly.. the VLC crossbar thing was a long standing problem I've had understanding how crossbars work in the default Microsoft User Interface called the "Properties page". I started suspecting there was a method to their madness.. and it finally clicked into focus. A user had a problem with this way back on a Pinnacle 510 usb capture device.. I may revisit that later. Anyhoo.. It does capture audio and video as you can see from the short uncompressed test avi I uploaded. Sync drift does not appear to be a problem in that brief clip and longer sessions I've tried. The device driver appears some what deliberately "hobbled" for what reason I do not know.. but I plan to tweak it and see if its actually much more robust.. or had its wings clipped for a reason. A person reported elsewhere and elsewhen that they got Virtualdub to work with it but couldn't get audio capture to work.. I now think that is a broader misunderstanding of how to use the Microsoft User Interface for setting the audio capture source, independent of VirtualDub. That is its not VirtualDubs fault.. its the way Microsoft presents the control choices. I really haven't tried to understand the TV Wonder branding.. it seemed to be their test field of cards before they turned them into all-in-wonders. The use of the AGP bus seemed to be a cherry on top to enable combining the Theater 200 (or whatever encoder chip that was used with the Radeon chip to be used). Or perhaps it was the other way around, the TV Wonders were Theater 200 test beds before adding them to existing Radeon cards to make them all-in-wonders. In any event the legacy PCI bus seems to have more than adequate bandwidth for SD video capture.. and a much longer life cycle than USB 2.0 at that time. USB was still new back then, and had design limitations, PCI was in version 2.0 and its still appearing on some motherboards with PCI express buses today. The really nice thing is this card (is) a universal PCI card, meaning its both 5 volt and 3.3 volt compatible. That's the two forward and rearward notches in the card edge connector that inserts into the PCI slot. Modern legacy PCI slots aren't suppose to support the 5 volt variant these days due to modern CPU voltages.. of course bridge chips caught up with that.. but its the "norm" to only support 3.3 volt cards these days. Its very good this card is a Universal. I'll add the cabling and dongle situation is "much" simplified with this card. 1. you can use it with virtually any other video card, or in a server "headless" 2. the video connectors are standard, large DIN, RCA and 3.5 mm and could be easily replaced 3. the device driver is literally a single file and inf file, its very simple 4. if it matters (it does) have a Connexant hardware MPEG2 compression chip and compressed capture pin on the driver You don't have to capture "compressed" you can capture "uncompressed" all options are on the table. The device driver gives you direct access to the Theater 200 chip output. Also there doesn't appear to be any kind of "binary blob" that gets uploaded to program any chips.. as happens frequently with things on the other side of a USB bridge chip. Its straight "register" programming. I don't know of any ATI or AMD internal documentation for the Theater 200 chip.. but the linux community could have probably written a driver many years ago by reverse engineering it.. its pretty straight forward. But the focus in "those days" was really on the video chip and not the video capture chip. This card does have an NTSC tuner, so it is Microsoft BDA compatible and was intended to be used by Window Media Center 2004 (XP Edition). I simply put it into a Windows XP + SP3 situation and its been working fine. I guess Windows Media Center for capture might be the logical choice, but then there is the MS-DVR and the DRM variant to contend with. And since Microsoft has end of life'd that platform it will be problematic to support going forward. -- The VirtualDub community and standard file formats for all their logistical problems have open source and can live on and be recovered by many people after the originators have long since ceased to be available. -- merged -- More progress last night. I upgraded the test system through Vista x32 and now Win 7 x32 The device driver from XP works flawlessly on Vista.. and while tweaking the driver did not restore VirtualDub functionality. I think I know why. On Vista it appears the VirtualDub graph attempts to pull video frames from the MPEG2 pin of the device driver model. VirtualDub can't handle compressed video.. it doesn't crash.. but it doesn't decode it either. I seem to recall M402 support for compressed frames in VirtualDub 1.6 and beyond.. but that was very specific to that capture platform.. it probably doesn't extend to this card. So.. Somehow VirtualDub is using the ksproxy to "discover" pins.. and its auto selecting the "wrong" one. I think Directshow works by "hinting" which pins are what.. or the Interface of the pins is tied to a "Class" in the registry which hints to the application which pin to use for video. It could be either an ordering problem (since there are two video pins, one compressed MPEG2, one uncompressed.. or something else). My thoughts are if I tweaked the device driver to "remove" the registration of the MPEG2 video pin as the video Class.. then VirtualDub will "see" the uncompressed video pin and just work like normal. I've had similar problems with Stoik and a number of other video capture applications with this card. In those cases.. weirdly.. they find the preview pin and display video perfectly fine.. but can't capture video.. so its the sum of all these events that make me think its the MPEG2 video pin that is getting in the way of using this card with many other video capture applications. Many video applications from that era expected uncompressed video frames since hardware compressed frames were too expensive to produce for most users.. the hardware compression cards were too expensive.. so they instead captured the uncompressed frames and "expected" to software compress them "after" they were pulled into the application. Its kind of odd that this cheap hardware compression video card, with the unique feature that plain uncompressed video was available might be tripping us up because its "over achieving".. I have no problems capturing and writing multiplexed AVI audio and video using Microsoft GraphEdit "uncompressed video".. but that's not what most people expect and its rather klunky. VLC capture works too.. but it does the same thing.. it defaults to finding the MPEG2 compressed video stream and automatically uses that as its input and writes that stream to a file.. as an MPEG2 stream even when captured through VLC raw... so thats a third confirmation of whats going on. Sort of related.. also confirmed that the Turtle Beach Santa Cruz sound card works under Vista x32.. but you do have to uninstall and reinstall with the last device driver installer package Turtle Beach made available for the Santa Cruz. The Equalizer doesn't work but otherwise the main mixer and all the important functions work just fine. I can't say that of Windows 7 x32 yet however.. the Santa Cruz card is silent after that upgrade, device drivers seems to install and start up.. but just no sound. Anyway that's a distraction.. its not the problem I was working on. In theory the sound capture for VirtualDub would pull from the card itself and doesn't need a sound card for audio capture. Some other sound solution could be used for playback. update: I just had another thought ! ATI MMC installs a software video decoder for MPEG2 which it used for DVD playback and viewing ATI VCR files. These are virgin installs of the operating system sans any MPEG2 decoder. Win7 x32 came with an MPEG2 decoder.. but its not working right now because my video card is an old Intel Extreme 2 XPDM device (865G).. so I have to install a card with XDDM support before it will be totally functional. Its "remotely" a very slim chance.. that VirtualDub isn't working because the frames aren't being decoded.. because there is "no decoder" installed. That's not an ideal scenario.. decode MPEG2 frames only to save them as AVI.. its sort of "fake" uncompressed capture.. but it would be conclusive evidence. I'd still like to "knock out" the MPEG2 video class registration for the pin and see if everything starts working for all the old capture software. |
Have you tried AmaRec 3.10 to capture yet? I've found it to be a bit more flexible with capture devices that don't report like a "standard" SD capture card would. It'll also properly capture from cards that report incorrect frame rate speed. VirtualDub's reporting of capture pins has always been weird. My AverMedia HD DVR HDMI and component inputs show as "S-Video" and "Composite" on VirtualDub's capture screen!
|
I did try to go looking for it.. but gave up shortly after getting lost on the Japanese website.. its maze like.
I'll try again later.. but it just irritated me quite a bit trying to look for it. |
|
Thanks for the link.. Amarec 310 produces an error while trying to open the video window connected to the card.
I got VMR and VMR7 unusuable.. but I didn't have DirectX 9.0c installed.. so I will have to try again later tonight. Those error messages make me think these apps are using the "autobuilder" to snap together filters under the covers rather out of control. I'm surprised to think they might all be this brittle. I thought the point of Directshow was to make programming easier.. not totally absent.. Windows Movie maker works, most Microsoft capture tools work.. but their Graphs are hard coded. This explains a lot about how a bad install of a Third party card could completely trash a system and be unrecoverable.. that and they didn't tend to write uninstallers.. because why would you ever do that <sarcasm> :huh2: -- merged -- I finally did get Amarec 310 to pull uncompressed video.. but it can't pull audio from the card. Many cryptic errors popup when I try to enable audio capture saying it can't find a valid source pin for audio. I absolutely can pull uncompressed video and audio using GraphEdit. I can pull compressed video and audio using VLC. I worked on changing the setup.inf file for the driver and it didn't seem to make a difference. DirectShow COM drivers depend on several default interfaces for discovery.. and I think those may not be implemented properly or altogether missing.. whatever it is this card type can't be used relying upon the buildgraph Class that many flexible tools like VirtualDub rely upon. It makes me sad to give up.. it actually produces very sharp and clear capture files.. but I can't see a way to get Virtualdub to work with it at this time. -- merged -- This thing is like a cat toy.. I just can't give up on. Last night, got WinDVR 5 and WinDVD creator to work with it flawlessly. In fact I was going to play with a Plextor 402 and had left the card installed and they hooked right on to the eHomeWonder card and just worked. The resolution was awful at 352x240 and GraphEdit Remote graph snooping revealed the eHome has (Three) video output pins, MPEG2 352x240 hardware, MPEG2 software and Uncompressed 720x480 (though I think it does PAL at 720x576). The Intervideo WinDVx stuff was connecting to the first video pin. I went back to Win7x86 and VirtualDub lo-and-behold produced a solid "english" info message that the video coming from the card was in a format that VirtualDub could not display. And the Capture Pin menu now displays 352x240 or ma formats.. which coencides with what the Intervideo WinDVx programs were doing.. so that tells me its a video output pin problem. In "effect" we need an output "Crossbar" for VirtualDub as well as an input "Crossbar" for managing the DirectShow/X capture filter inputs and outputs.. who knew? I think LordSmurf (suspected) such a thing might exist a long long time ago.. when he had me look at an old LSI based capture box. Now its confirmed.. such a thing does exist. Probably the super hi-resolution 720x480 direct from the Theater 200 chip was only meant for "testing" the ATI chip since that fed into the Connexant hardware MPEG2 compression chip afterwards.. and in those days.. low bandwidth lo-res was sought after. Its a stroke of luck that the hi-res capture pin is even available. Other than GraphEdit I've not been able to reliably pull from the specific output pin for capture that I want.. but I've a few ideas to try now. If only there were such a thing as a universal video output "crossbar" plug in.. I can see the natural reason it should exist.. but I don't think anybody at ATI would have been "insane" enough to write such a thing. I also don't think I have the skills to write a DirectX9 plugin for it.. gee.. i wish i had the skills. It also appears to have (Three) kinds of audio output pins on the capture filter.. so similar problem there as well. Its annoying to have so much choice in this card.. but so much trouble accessing all the features. |
Quote:
|
VLC fully supported now.
I found that by changing some registry values after the driver was installed I could "hint" to VLC ("these are not the droid pins your looking for..") So now VLC starts up and immediately connects to the video and audio from the eHome.. its looks pretty good. Still no joy with VirtualDub however.. I don't know if its XP SP2 or the versions of Virtualdub I'm trying but it ignores the "hints" not to use the MPEG2 pin. I really thought it would be the other way around.. that I wouldn't be able to get VLC working.. and that Virtualdub would be easier.. oh well. I'm taking a break from the eHome to look at the audio for the Pinnacle 700 usb gdaget.. video works fine with the 700.. but the WaveOut pin isn't exposed in the AVStreaming interfaces.. so Virtualdub can't find the audio. -- I'm failing a lot at learning all these audio APIs Microsoft has come up with.. but haven't found a way to kill hope yet. |
6 Attachment(s)
Any chance you're gonna come back to this one? :)
2005 AnandTech review of ATI eHome TV Wonder's tuner quality, compared to a couple others Dell J4461 OEM card (other #s in eBay listing title: 109-A38000-01 F11236-w F11236/W 102A3800100) Attachment 11063 Attachment 11065 F11236/W H-3 is from the sticker of the Philips TV tuner module. 102A3800100 is the Part Number from the barcoded sticker on the Philips TV tuner module. It also says 000001 after, but I presume this is indicating the Quantity. A quick search for this part # returns Dell's driver page for the model. Quote:
Quote:
Attachment 11064 Did you happen to save any photos of the models you mentioned that use the purple box, John? More links https://forum.videohelp.com/threads/...=1#post1305548 https://download.driverguide.com/dri.../d1599137.html Quote:
ATI 2003: signed 2003-11-03. DriverVer=10/08/2003, 1.17.24.200 (ATI-E-Home_Wonder_Pci.zip from DriverGuide) Dell 2004: signed 2004-08-31. DriverVer=07/27/2004, 1.17.24.223 (TVT1-A02.exe from Dell website) ATI 2005: signed 2005-06-15. DriverVer=06/01/2005, 1.17.24.231 (wxp_mce_ehome-5-03-231-26441.rar including edited INI, from DriverGuide) Contents of Dell's Version.txt Quote:
to add a little more. https://web.archive.org/web/20060321...itvwonder.html ATI eHome Wonder PCI = 100-703153 ATI eHome Wonder w/ FM PCI = 100-703141 (this one has two tuner-type inputs) |
I pretty much learned the "Preview" pin was designed to be "lossy" even though it was outputting Uncompressed frames. Given load, it will "drop" frames when the Capture pin is in danger of falling behind the clock.
This is by design. The "Capture" pin has priority and outputs only compressed frames. They were using a commodity Connexant 878 based chip to perform the compression. This was to comply with the Windows Media Center requirements for a compressed stream. Once I figured that out, I kind of lost interest.. its limited by its device driver.. which I cannot change. I mean if I were smart enough I could pull apart their device driver and make changes to it, then resign it.. but that's a little more work than I'm willing to learn and do. The lower hanging fruit is simply to find more ATI TV Wonder USB2.0N capture boxes, if I want to stay with that T200 chipset. I've changed directions (interests) many times looking at Compressed versus Uncompressed.. whether it is an important thing for me or not. Compressed we have MPEG2 versus MPEG4 (all the variants), which is basically optimized for Interlaced or Not optimized for Interlaced (Progressive). Uncompressed we have full DV25 or Huffyuv. I'm dumbing my expectations down to what is simpler, and doable.. for a large collection of VHS tapes.. and manageable. So that tends to lean towards using a dedicated MPEG2 compression system and that doesn't lean towards PCs for the vast majority.. DVR recorders work on MPEG2 encoding 24x7 and you can offload the finished MPEG2 to a PC later. That is looking like the better solution for me. For those rare, or special tapes I'm still thinking PC capture.. but investigating DV25 Lordsmurf alluded to the YIQ versus 420 question of is DV25 really "enough" for poor quality VHS tapes, EP, EPP ect.. I'm not sure I understand it properly.. but the YIQ equation seems to be in the analog domain, and it "does" say according to Nyquist.. the poor quality of color encoding for EP speed tapes is fully captured by sampling with DV25. If true.. then Canopus or Firewire capture encoders.. which are vastly easier to use under both Windows and Mac may be adequate (For EP or Slower VHS tapes).. and all but effectively "lossless" for that purpose. [ I "can" see the difference when I record with a high quality "Broadcast quality" signal.. not so with a poor quality VHS tape signal. ] DV25 capture would not be appropriate for faster speed VHS SP tapes, or higher resolution tapes like S-VHS, Betamax or Laserdisc. I've spent a long time thinking 422, 420, 411 were of paramount importance.. and I'm questioning that now. It may "depend" on the signal source. Chroma Sub-sampling is a mathematical idea that mostly applies in the Progressive "Digital" domain.. applying it to the "Analog" domain doesn't look right.. Nyquist.. looks better.. YIQ. I've also come around to thinking preparing the signal for capture.. by running it through a TBC, Proc-amp and other filters in the Analog domain before converting it.. was the right thing to do in the first place.. and that heaping all the responsibility on a lowly simple capture dongle.. is near insanity. (Maybe when the tapes were new and SP speed, but not now that they are 35 years old.. signal quality doesn't get put back into a degraded tape by external signal processors.. its merely base lined and stabilized for capture.) So a long winded way of saying.. I don't think I'll be revisiting this capture card for a while. I've some capacitors in a DVR to replace.. and I'm looking at using m.2 to replace some IDE and SATA drives in DVRs. Some more work on Isobuster is knocking at my door.. and I would dearly like to add JVC DVRs to Isobuster extracting support this year. More requests for Philips and Sony DVR support has come in.. but I don't know where to put them in my priority list. Last month I played hookie and collected all of the DVRs TiVo ever allowed to be made and got them syncing with TiVo for their EPG data again.. and that was a learning experience. They have S-Video and Audio inputs and a VHS record function.. and beyond DVD burning could transfer their recordings over the local lan to your PC (automatically on a schedule).. VideoRedo will then re-mux them into normal MPEG2 files. This transfer function works both ways.. you can upload video to the Tivo DVR using Tivo Desktop from a PC, or TivoToGo from a Mac.. so all of that was a revelation to me.. I never knew such things ever existed.. or still do. So I'm keeping busy. Going to play hookie again in a couple weeks and attend the Fully Charged Live event in Austin, TX There are some YouTubers I watch that are going to speak and hold some meetups. I've long thought I'd like to make more videos.. and those guys are so good its exaspirating.. (puts me in my place and teaches me to keep my head down.. rather than waste time on a YouTube channel.. its good Therapy.. Important Therapy) I mean I (am) still looking at appropriate 422 lossless solutions when they make sense, but I don't have a lot of high quality high speed material to throw infinite resources at. For those an ATI capture card or ATI USB device may work.. or one of the AJA, Avid or other cheap refugees from 2003 that can capture in full 422 Uncompressed format. |
As someone whose hobby to-do list is pages long, I fully understand.
4:1:1 itself is more than enough to capture all detail in VHS chroma. The questionable part is how the DV compression is performed and how much you end up stuck with artifacts if you then try to Restore such a capture or re-compress to a 4:2:0 codec for compatibility and size. The implementation differs. Also, Sony models have an IRE bug: they expect 0 IRE Japanese sources, so you can't watch it as-is without seeing milky blacks. |
I use to wonder about DV 4:1:1 and DCT (Discrete Cosine Transform) as well.. I don't know the MPEG2 algorithm well enough to be certain, but I think it roughly starts with a Taylor Series somewhat like a Fourier Series and dumbs the signal down in order to prepare it for some pyscho-visual filtering to remove portions of the image that aren't sensed as well when playing back a series of images (GOP).
If that summary (or guess) is correct.. then DV25 and MPEG2 are "the same" in the first step. They diverge after the common DCT step up front. Somewhere after that step they make the leap from Analog to Digital and then independently decide on which chroma sub-sampling direction to take. For a poor quality signal.. the chroma information simply "isn't there" to be captured.. I think its amplitude is "smushed" (that's a technical term) and is already "blurred". So sampling at DV25 rates gets about the same information as MPEG2 once its digital (for a poor signal). Oversampling with an MPEG2 or 4:2:2 method doesn't put more information back into the flattened signal.. so on poor tapes.. fixing the digital version is going to look "cooked" anyway.. its putting lipstick on a four legged critter.. I'm still thinking. I might be able to "prove" this with some after the fact Vectoscope captures from some old and new test footage.. during playback in Vegas or DV Encoder.. but for now its mostly a thought experiment. It doesn't mean anything discussed before is not correct.. just that "poor quality VHS tapes" never really needed 4:2:2 handling in the first place.. something simpler would do.. This is a "first world problem" since cheap dongles that don't capture well are still to be avoided for entirely different reasons. Poor consistency, poor default set points in their proc-amps (if they have them), poor sound quality (if they do capture sound), noise immunity, or noise injection by their own circuits or cables.. poor driver quality.. ect.. and on and on. Most don't have line or frame level TBC, audio video sound lock or frame drop reporting at all.. and for good or bad hardware compressions on tap in case that is what you want to do. Or sharpness, edge enhancement filters and other specialty filters in silicon. And I see some people demanding 5.1 or 7.1 sound capture.. or that the capture device be new and modern and multi-purpose.. for current HD, Game capture or consistently high resale value.. and cost less than $30, available with Amazon Prime, next day shipping, Black Friday sale.. want fries with that? Maybe 411 - (Critical conservation/frame accurate editing/repair) EP VHS 422 - (Critical conservation/frame accurate editing/repair) SP, S-VHS, Betamax, Laserdisc 420 - (Everyday recording/commercial removal editing/fast, no repair) EP, SP, Betamax, Laserdisc Even cheap 411 will be out of the pocket book range for most casual collectors. Even cheap 422 will be out of the pocket book range for the unskilled, and less likely to follow through to making DVDs, its also very time consuming. Cheap 420 is much more likely to be in everyone's range, but not on the PC.. too complicated, or too many moving parts. A DVR is not a TBC.. but it has many parts that makes it better than a stand alone dongle. The problem up to now has been the failure prone DVD burner, or dwindling DVD media sources.. and how to back "those up".. the assumption they will last 500 years in the back of someones closet.. is laughable.. more likely less than a single lifetime. |
Quote:
Quote:
Quote:
For many people, especially in an era of large HDTVs, the loss from DV conversion is unacceptable. (And, of course, you also have the opposite spectrum of modern viewers: Youtubers that accept crappy quality on phones. But I refuse to accept reduced quality because of their media consumption choices. They're an overly vocal minority of video consumers, with their age skewing to young and broke. In other words, no analog tape library, no funds for nice large HTDVs, therefore no real care about VHS/analog video quality.) Quote:
https://en.wikipedia.org/wiki/Nyquist_frequency https://en.wikipedia.org/wiki/Nyquist_rate https://en.wikipedia.org/wiki/Nyquis...mpling_theorem From an engineering stance, I'm sure it important. But from a video user stance, not so much. Why, you ask? Because the math isn't necessarily the reality of manufactured video capture devices. What "should" be, and what "is", isn't the same. And applicable video matters to me. As interesting as the math of "why" video is, it's really quite immaterial to my daily activities. Even to an advanced video user, Nyquist cannot explain why a Canopus ADVC box has color that looks lost and cooked. Nyquist also applies to audio, where you'll get even more pushback. A good related read: https://www.audiostream.com/content/...esign-services And a good quote from the opening graphs of the article: Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
|
Quote:
Now convert this to 4:2:2 or 4:2:0. Chroma: 360px wide. And to 4:1:1. Chroma: 180px wide. Now let's make a 352-width 4:2:0 version from the source while we're at it, for DVD or similar. Chroma: 176px wide. Why is DV 4:1:1 guilty of the crime of quartering while 352x___ DVDs get off scott free? Quote:
http://www.digitalfaq.com/forum/vide...html#post62896 http://www.digitalfaq.com/forum/news...html#post64495 http://www.digitalfaq.com/forum/vide...html#post57341 |
A lot of it depends on how well the compressor subsamples the color data AND how well the decompressor upsamples that same data.
It can also be perception. Your eyes are more sensitive to luminance, halving it might "hide" the further halved chroma. Real-time DV compressors are likely pretty terrible at 4:1:1 subsampling of analog video, further exaggerated by how noisy the sources are to begin with. Being hardware based, they never saw improvements in their compression algorithms over the years. (the same can be said for hardware MPEG2 encoders vs. the latest optimized software encoders*) The quartered chroma data is even noticeable on some video directly recorded off DV camcorders. *The most obvious byproduct of this is seen in ATSC OTA broadcasting. Years of refinement in MPEG2 codecs allowed stations to cram more subchannels onto one 6Mhz channel. Just a few years ago, you got one HD main channel and maybe 1-2 SD subchannels, today you have major networks sharing transmitters with 2+ HD channels. |
Quote:
Quote:
1. What the human eyes perceives, how the brain interprets it. The brain sees luma, and the color needs to fill the expected palette to give said colors. In fact, 4:4:4 is often seen as "too saturated", because of the backlit nature of viewing devices. Whereas 4:1:1 (in practice) leaves obvious blocks and gaps in the color. 2. What you think you see (or don't see). It's amazing how easily people can fool themself, or convince themself that a problem isn't a problem. The term "good enough" is the excuse used. So the color issues really are obvious -- unless you refuse to acknowledge the issue. This is also why people think they can see a difference between 720p, 1080, 2K, etc -- and yet the viewing device is too small to truly resolve the detail. It's in their head, they've convinced themselves that something is good or bad, and facts (or objective observations) be damned. I actually disagree that Half D1 (352x) is quartered chroma resolution. It's halved (near) half. Simple math will argue half a half is a quarter, but it's not that simple. Video never is. The algorithms have different math to land at that final resolution. And said algorithms from 1990s (Pentium III era) designed DV boxes are primitive. |
Site design, images and content © 2002-2024 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2024 Jelsoft Enterprises Ltd.