Dazzle DVC107 video decoder chip info wanted

[AusDaz]

Hi everyone,

Does anyone know for sure which analog video decoder chip is used in the latest Pinnacle Dazzle DVC107?

I have read that some versions of the Dazzle Video Creator Platinum use the ADV7180 chip, which has a very nice feature called "Adaptive Digital Line Length Tracking" or "mini-TBC" which can help stabilize analog video.

Pinnacle haven't been any help (no reply).

[Brad]

NXP (formerly Philips) SAA7113H: http://www.nxp.com/documents/data_sheet/SAA7113H.pdf

Searching for Linux drivers can be a goldmine for this sort of info. My answer is based on the second pic here.

I guess your "some versions" comment for the Platinum is based on the same conflicting info I found doing a search based on your post. A Russian review has photos of one without the Analog Devices chip.

[AusDaz]

Thanks very much for that info. Not what I wanted to see though!

Yes indeed - there is conflicting information regarding the hardware used. Probably because the Dazzle has seen quite a few versions over the years.

That Russian review shows the cheaper Dazzle (DVC100) as using the SAA7113H. The same site has a forum that mentions the DVC130 and DVC170 both use the ADV7180. However, the DVC130 and DVC170 have no 64 bit driver, so are of no use to me.

That same Russian site does show the ADV7180 in the "Pinnacle Video Transfer" device, but I wasn't really wanting to buy a stand-alone capture product.

I enquired about some 2nd hand Dazzle Platinums on ebay, and they were both DVC100s!

Maybe I should broaden my question and ask if anyone knows of a capture product that uses the ADV7180 video decoder or similar. (ADI make a family of devices with similar ADLLT mini-TBC features - The ADV7800 even has a full frame TBC, though it requires external RAM)

[danno78]

Happpage Colossus have a chip from Analog Device with "Adaptive Digital Line Length Tracking". Analog Devices have several chips with TBC but are expensive and are used only in highend reveiver/upscaling devices.

http://www.planetdv.net/Pdfs/XENA_LSe.pdf

[AusDaz]

Thanks danno78,

Can you please tell me which Analog Devices chip they are using in the Colossus?

I just received an email from the Australian BlackMagic Design distributors confirming their Intensity Pro card uses the ADV7180. However they also told me the card doesn't tolerate timebase errors - which makes me think it's been configured for very stable professional equipment.

[danno78]

ADV7441A
http://www.analog.com/static/imported-files/data_sheets/ADV7441A.pdf
ADV7180 it`s only for standard definition. ADV7141A add high definition. Both will perform in the same matter on SD inputs (same specs). So, if the ADV7180 don`t have a real TBC then is unlikely that Collosus can do time base correction.

[AusDaz]

danno78:
Wow that's a complex chip.. Thanks for the info!

There is some confusion about TBC functionality in capture devices. The first step in correcting the video timebase during capture normally uses a PLL that is locked to the Hsync pulses. The loop filter and loop gain of the PLL determine how aggressively it tries to counteract* the timebase variations of the input. Some capture card drivers have a "VCR Input" setting for this exact reason. But setting the PLL to do this will add jitter on very stable sources, as they don't need the correction, but the PLL will see more noise from the increased bandwidth. Video decoder chips have registers for holding these type of settings - they are programmable by the software, though not all software allows for user adjustment of these parameters.

If a capture device has been configured for stable broadcast quality sources, it won't be able to follow the rapid timebase errors from typical VCR video. So people may think the TBC is useless when in fact it is just too slow for their purposes.

Perhaps a better name would be "Timebase Corrected Sampling".. but people can understand what TBC means even if there is no analog output, but just data written into a RAM buffer with no sync pulses. It's a matter of semantics.

* The PLL counteracts the variations by following them - so it matches the Hsync frequency of the video input

[lordsmurf]

it won't be able to follow the rapid timebase errors from typical VCR video. So people may think the TBC is useless when in fact it is just too slow for their purposes.

I will accept this theory, but reject the conclusion.
If it doesn't perform to the expected norms, I don't think it should be considered a TBC.
I've long held this belief with hardware from Sima and others.

Too much confusion is caused by people looking for effective TBCs.
I often think it's intentional deceptive marketing.

[jman98]

With regards to danno78's comments, I can tell you that I have the Colossus and its TBC definitely works. I have some video tapes that my old Hauppauge PVR-350 could not capture correctly that needed a TBC. I don't know what you call it but the top part of the video was kind of bent. These tapes look fine on captures from the Collosus. And I have also recorded some tapes that I think have Macrovision on them but I cannot be 100% sure of that as there is no sign of Macrovision when using the Colossus. Whether it's a "real TBC" or not is completely irrelevant to me as the card has more than exceeded my expectations. However, you do have to turn on TBC. It's not on by default.

[AusDaz]

jman98:
That's very good to know! Thanks for the info

lordsmurf:
Of course I am speaking from an engineering point of view..

What's expected depends if you were capturing from a camera, a gaming console, or tape. I've read of people buying stand-alone TBCs only to find they don't correct the problem adequately. It's difficult to make a one-size-fits-all in this application, because if you optimize for VCR it degrades stable sources.

The solution would be for the manufacturer to allow the user to adjust the parameters to suit the application. If it's too slow - speed it up. At least give the user some options to fix their problem.

I think I might look at buying a Colossus..

[danno78]

I wrote that ADV 7180 which in found Intensity Pro and ADV 7441A which drive Collosus share the same specs for standard definition signals. The later add high definition with HDMI and component. If miniTBC works on one then should be also work on the other. The only possible reason that for Intensity Pro don`t work are the drivers. Maybe BlackMagic has decide to remove the miniTBC feature from driver to protect the own more expensive product. Another good reason is that on Intensity Pro it works but BlackMagic don`t promote this card as TBC capable for the same marketing reason.

Even Analog Devices don`t promote the ADV7441A with true TBC feature and it say miniTBC. Others chips from Analog Devices like ADV7800 are promoted as "Advanced time base correction (TBC) with frame synchronization". Again could be marketing or maybe the ADLLT will help only on light/medium horinzonal jitter and also could be the lack of frame synch.
I don`t have any of these cards and my comments are based on specifications from manufactuer and AusDaz sentance:

I just received an email from the Australian BlackMagic Design distributors confirming their Intensity Pro card uses the ADV7180. However they also told me the card doesn't tolerate timebase errors - which makes me think it's been configured for very stable professional equipment.

[AusDaz]

danno78:
I was browsing the ADV7180 datasheet, and I found this:
---
SQPE, Square Pixel Mode, Address 0x01[2]
The SQPE bit allows the user to select the square pixel mode. This mode is not suitable for poor time-based video sources. This mode is recommended for professional applications only and should not be used with VCR or tuner sources.
---
I'm not sure if the Intensity Pro uses this mode, but it does prove that the way a chip is configured can disable it's advanced features.

[AusDaz]

I've ordered a Hauppauge Colossus card. Hopefully it will live up to my expectations!

[jmac698]

Hmm, some things are coming together for me in the last few days of reading.
Flagging - I think this is missing/weak sync at the top of the frame. I don't know why it's always at the top of the frame, unless it's related to VSYNC as well (if vsync were wrong somehow, perhaps hsync on the first line is expected in the wrong place - a pretty good theory).

Capture cards normally handle horizontal jitter but not so good with flagging, so the missing hsync feature isn't there.

I also see in a TBC manual, there is a setting for synch adaptation rate, where setting slower reduces flagging. This also implies that sync has to be guessed over several lines.

I also just did a test with a capture card and a DVR passthrough. The DVR fixed a flagging issue. So DVR has the missing sync feature.

I think the technical definition of what Mr. Smurf wants in a TBC is;
-fix horizontal jitter
-fix missing hsync (flagging)
-fix missing vsync or odd timing (rolling, jumping picture)

I have a few more theories about vertical sync. One, VCR's by default have some missing video lines, and there is a webpage about an engineer who spent some effort arguing to chip companies to fix this problem. He explains it in detail. Another problem is missing a field; this can make the picture seem to jump by 1 line. And worse, is missing a vsync, which would make the picture jump alot.

Missing one field could be due to the two devices not being "genlocked" or their relative timing is off. This happens often in dropped frames when capturing on PC, in Windows there seems to be a problem with the API, that you have to set a capture frame rate before you capture so you can't just get the frames as they come in, whenever they come in. What virtualdub does is reset the requested framerate based on the actual timing recorded by previous frames in a new request. It seems to me you can still miss frames this way, and I've proven that Virtualdub never works completely.

[AusDaz]

Hello jmac,

Flagging, flagwaving or top-curl is caused by a sudden change in the hsync frequency after the VCR headswitching. I read that it is due to uneven tape stretch causing the hsync frequency to be different at the top of the frame than the bottom.

One explanation is here:

http://www.questronix.com.au/info/info_tbc.htm

Google will find more..

Where did you read that a slower sync setting reduces flagging??? That's the opposite of what happens. You need a FASTER adaptation rate to reduce flagwaving. Many old CRT TVs had the same problem when VCRs first became available. The fix was to modify the TV horizontal sync circuit to speed up it's adaptation rate and widen it's timing window (the sync circuits in TVs are gated to reject noise - the gating time needed to be made wider).

We have heard about DVRs having TBC ability before.. see if you can find out which video decoder chip it uses..

If video capture is going to a file, it seems to me that if the incoming video stream was near the expected rate, you could just pass the data on at whatever speed it was available without dropping frames or changing framerate (the file doesn't care, it's just data). But you might need to resample the audio to compensate for error and prevent lipsync problems. I think Virtualdub does offer these features in the settings. If the video is for display purposes it gets tricky, because you have to feed it frames at a fixed rate. Maybe this is where the Windows problem comes from?

Perhaps vertical jumping or skipped frames can be corrupted vsync.. The top and bottom of the frame is stored near the tape edges, so if a tape has edge damage it can lose a lot of vsync through dropouts. This can also happen when the pinch roller gets worn/dirty or the capstan gets dirty - putting creases down the tape lengthways. It would be possible to make a capture device ignore the loss of vsync for a time (because the frame has a fixed duration and a fixed number of lines, so you can easily make a good guess).

Standard VHS machines do their headswitch about 4 lines before the bottom of the frame, causing a disturbance at the bottom of the picture. The reasoning behind this design was to give the TV longer to resync to the video before the next frame. You can manually adjust the headswitch timing trimpot in the VCR and move that annoying glitch down off the visible area of the picture (my JVC SVHS VCR was made this way at the factory**). But the headswitch has to occur before the vsync pulse or it messes up the sync too much, making the picture unstable.

** Actually, it only operates this way when the "Video Stabilizer" option is selected in the VCR menu. Otherwise, it works the same as any normal VCR and switches before the bottom of the frame.

[AusDaz]

I think I know what they meant in the TBC manual you read..

If the hsync goes missing completely - say.. due to dropouts, the timing of the TBC unit will start to drift off. If it has a fast adaptation rate, it will drift off fast - causing a flagging problem. If it's adaptation rate is slowed down, it is more stable.

This method of fixing sync only applies when it is missing entirely - not when there is a timebase error (sync present but wrong frequency).

An intelligent approach would be to switch modes: Fast if the sync is present, but wrong frequency, and slow or frozen if sync is missing entirely. There are probably TBC units that do it this way.

[jmac698]

Great stuff!
Some good info here
http://www.ronaldsnoeck.com/vcr.htm

My test with flagging on DVR
http://www.digitalfaq.com/forum/video-capture/4381-himage-dvr-4010-a.html

I can take it apart in a bit.

TBC manual
http://support.keywesttechnology.com/downloads/BVTBC/Manual/BVTBC%20Manual.pdf

TRACKING MODE SELECTION
The BVTBC sync tracking speed is user-adjustable. This mode, also known as “VCR MODE”
allows the TBC to compensate for particularly unstable sync inputs (such as VHS and other
TAPE inputs). To access this mode, press the SHIFT button to enter Menu Level 3, as described
above. Once in Menu Level 3, press the FREEZE button—the LEDs will now give a display of
two horizontal lines in LED #1 and a number from 0 to 3 in LED #3. Pressing the up and down
arrows will change the number in LED #3 alternately. This changes the speed at which the TBC
“tracks” sync error changes on the input signal.
As an example, many VHS tapes processed through the TBC will display “flagging” at the top of
the image—this is due to mechanical head errors inducing sync duration and repetition errors. If
the BVTBC is set to it’s fastest response mode, the flagging will be visible to the viewer. By
selecting a slower tracking mode (3 being the slowest), the TBC will have more patience, and
will maintain internal lock for a longer period—the result is the elimination of the “flagging”.
This effect, and others are most always associated with tape—but we don’t rule out other
unstable sync artifacts that can be corrected by this mode. Also, the selected mode varies with
installation; in other words, setting 1 may work for some, and setting 3 might work for others.
Experimenting with this mode will not adversely affect stable sync signal inputs.

An explanation of the problem in Virtualdub and Windows:
http://forums.virtualdub.org/index.php?act=ST&f=6&t=19460&hl=dropped+frames&

This matters because of synchronization between the audio and video streams and because the video stream timing must be declared before the frames are recorded and timing is known....

My script to TRULY test for dropped frames:
http://forum.doom9.org/showthread.php?p=1462931#post1462931

As for dropped/inserted fields, I've seen this many times and it can be corrected with two captures and a script.
Here's an example, captured from a tbc, on a mac
http://www.digitalfaq.com/forum/video-capture/3661-tape-digitized-dropped.html

[pandy]

AFAIR most of the video decoders support pseudo TBC (lile Bt878 UltraLock™ or similar).

[jmac698]

Yes, that is part of the TBC function I'm calling line jitter. They don't seem to work so well with flagging or vertical jitter. I have an Ultralock card and I plan to do a TBC test of my cards.

[AusDaz]

jmac698:
Wow - information overload! Thanks for those links..

That Ronald Snoeck is one seriously smart guy.. but he really should use spellcheck..

Interesting how that DVR didn't just fix the timing, but also cleaned up the noise bar. You don't have to take the DVR apart just because I'm curious...

You have obviously done a lot more work with video capture than I have. Seems the timing problems in Windows are a bit more complex than I thought.. Sounds like the Virtualdub timing workaround keeps the buffering from overflowing or underflowing. Bigger buffers might help a lot with that one. I will read more about it when I actually start my capturing project.

That TBC manual doesn't make sense to me (sounds reversed from what I expected).

Good work on the scripts.

[AusDaz]

pandy:
Thanks for mentioning the BT878 Ultralock - I hadn't heard of it. It looks like the modern DSP refinement of the old PLL technique I mentioned above.

[pandy]

AFAIK TI chips (at least TVP5160 but probably different too) support something like TBC. However all those IC's usually support only line TBC and in very limited way (low memory constraints)

[AusDaz]

Yes they would be quite short length - though the TBCs in high end VCRs are fairly short too, and they do a good job.
The capture driver buffering may help somewhat.

[jmac698]

You can read the text of Ultralock in the 878 datasheet. Hmm, in your quest for that 8170 chip, I thought you knew that such features have been around a long time, and I'm not sure if there's anything new here except maybe flag fixing.

And it didn't fix the noise, I think the noise is only in one field and my other program has some deinterlacing going on that hides it. That's why I have to it again with a real capture (couldn't cause of some technical problem.s)

[AusDaz]

Yes I've been reading the 878 datasheet.. Ultralock seems a lot like the ADI ADLLT.

A few weeks ago I repaired my only usable SVHS deck, and since then my capture project has been held back while I search for information on updating the capture device.

The ADV7180 chip seemed to be the best bet for getting the combined capture/TBC device I want. This was based on a lot of searching where I tried to find the reason behind the very good TBC performance of some DVcams. I never did find the exact technical reason for their good TBC abilities, so I went with the ADI family of chips because their ADLLT feature seemed the most likely candidate.

[pandy]

Not sure how this is important for You but ADI also offer (IMHO) best analog and AD processing - second on my list is TI then Philips then... rest of the world

[AusDaz]

Yes, I have faith that ADI products can deliver the needed performance... Their DDS chips have been going great in one of my receiver projects for about 8 years now, and I recently bought some more for future SDR experiments.

[AusDaz]

The Colossus is installed and working, and appears to be stabilizing the captured video timebase to a large degree.

To get to this stage, I had to use the TBC registry edit from this page:
http://forums.sagetv.com/forums/showthread.php?t=52718&page=76

A driver bug?

The Colossus driver has a "VCR Input" option in the ShowBiz Device Settings/Properties/Video Decoder menu, but it won't stay set! Every time the check box is enabled, it immediately clears. This appears to be a driver bug, related to the device properties window refreshing. I have emailed Hauppauge support about it - still no answer after a few days.

The Colossus handles loss of HSYNC quite well.. A lot better than it handles loss of VSYNC, which results in one or both fields repeating the previous field from a frame buffer. It handles flagwaving (tearing) better than my analog TV, but it needs to do even better to cope with really bad tapes. Maybe if Hauppauge can fix their driver "VCR Input" option, it may improve things. The Colossus currently doesn't cope with the (non-standard?) video from my VCR menu!

Room for improvement:

My JVC SVHS VCR has had a severe fast jitter problem since it was new. The Colossus is making an attempt to correct these timebase errors, but it leaves fine jitter (about 1 pixel worth) on vertical picture edges. A good quality Panasonic standard VHS deck appeared to have far less jitter than the JVC (but worse flagwaving with a bad test tape). This jitter problem needs further investigation - it could be related to tape transport, higher bandwidth, or an electronics problem. Some improvement has since been made by modifying the "Impedance Roller".

Hauppauge could improve the VHS capture performance of their Colossus driver by changing it to make smart guesses about missing VSYNC, and by fixing the broken "VCR Input" driver option and/or optimizing the hardware settings further. A manual override setting for incoming video standard would avoid the need for the MPEG encoder chip to reset after video loss (it currently senses video standard automatically). There are more settings hidden in the registry than are available in the capture options, but at the time of writing no further performance improvement could be obtained by tweaking some of them.

[AusDaz]

I have heard back from Hauppauge after contacting them again.

They told me me that the "VCR Input" option was only a Microsoft driver property that was being exposed, and it "has no meaning". The person who replied wasn't aware that the Colossus driver has a TBC (Timebase Correction) option in the registry.

I sent back a list of feature requests that would greatly assist people who were using the Colossus for capture from videotape. They will pass them on to the developers.

The suggestions included:

* A selection of HSYNC adaptation rates
* Improving how the driver handles missing sync and loss of video to reduce frame drops
* Options to enable and disable the ADV7441A CTI (Chroma Transient Improvement) and DNR (Dynamic Noise Reduction) features
* Options for selection of the ADV7441A Luma and Chroma shaping filter bandwidths

Hopefully they can add at least some of these to future driver releases. Some of them may already be available via registry editing.

In the meantime, I am developing my own video stabilizer solution which should help a lot. The basic idea is to use a microcontroller and some cheap hardware to strip the sync from the video and re-insert a cleaned and dropout compensated version of the original sync to help the capture card do it's thing.

[Brad]

Related to the thread topic: I bought a Dazzle DVC80 off of eBay and cracked it open. The back side indicates the board is the same as the DVC50 which lacked (or hid) audio inputs.


[Attachment 17451 - Click to enlarge]

[Attachment 17452 - Click to enlarge]

Chips:

• Philips SAA7113H
• Zoran USBvision ZR36504 (video compressor & USB functionality)

I sort of forgot how limited USB devices were when this one was released. Anyway, for general info here is a list of some more devices using Philips SAA711x with a Zoran USBvision chip, modified from an array in a Linux driver. Additionally, some pages say the DVC90 uses the USBvision, while there are photos in the link in post #2 showing it with an eMPIA chip.

SAA7113 - Xanboo
SAA7113 - Belkin USBView II
SAA7111 - USBGear USBG-V1 resp. HAMA USB
SAA7113 - D-Link V100
SAA7111 - X10 USB Camera
SAA7113 - Hauppauge USB-Live Model 600
SAA7113 - Zoran Co. PMD (Nogatech) AV-grabber Manhattan
SAA7111 - Nogatech USB-TV (NTSC) FM
SAA7113 - PixelView PlayTv-USB PRO (PAL) FM
SAA7113 - ZTV ZT-721 2.4GHz USB A/V Receiver
SAA7111 - Hauppauge WinTv-USB USA
SAA7111 - Hauppauge WinTv-USB
SAA7111 - Hauppauge WinTv-USB (NTSC)
SAA7111 - Hauppauge WinTv-USB (SECAM)
SAA7111 - Hauppauge WinTv-USB (NTSC) FM
SAA7111 - Hauppauge WinTv-USB (PAL) FM
SAA7111 - Hauppauge WinTv-USB (PAL) FM
SAA7113 - Hauppague WinTv USB (NTSC) FM Model 602 40201 Rev B285
SAA7113 - Hauppague WinTv USB (NTSC) FM Model 602 40201 Rev B282
SAA7113 - Hauppauge WinTv-USB II (PAL) FM Model 40201 Rev B226
SAA7113 - Hauppauge WinTv-USB II (PAL)
SAA7113 - Hauppauge WinTv-USB II (PAL) MODEL 566
SAA7113 - Hauppauge WinTv-USB (SECAM) 4D23
SAA7113 - Hauppauge WinTv-USB (SECAM) Model 40209 Rev B243
SAA7113 - Hauppauge WinTv-USB (PAL) Model 40204 Rev B283
SAA7113 - Hauppauge WinTv-USB (NTSC) FM Model 40211 Rev B123
SAA7113 - Hauppauge WinTv-USB III (PAL) FM Model 568
SAA7113 - Hauppauge WinTv-USB III (PAL) FM Model 573
SAA7113 - Hauppauge WinTv-USB III (PAL) FM Model 40219 Rev B252
SAA7113 - Camtel Technology USB TV Genie Pro FM Model TVB330
SAA7113 - Digital Video Creator I
SAA7111 - Global Village GV-007 (NTSC)
SAA7113 - Dazzle DVC-50 (NTSC)
SAA7113 - Dazzle DVC-80 (PAL)
SAA7113 - Dazzle FUSION (SECAM)
SAA7111 - Pinnacle Studio PCTV USB (SECAM)
SAA7111 - Pinnacle Studio PCTV USB (PAL) FM
SAA7111 - Miro PCTV USB
SAA7111 - Pinnacle Studio PCTV USB (NTSC) FM
SAA7113 - Pinnacle Studio PCTV USB (PAL) FM
SAA7113 - Pinnacle Studio PCTV USB (NTSC) FM
SAA7113 - Pinnacle Studio PCTV USB (PAL) FM
SAA7113 - Pinnacle Studio Linx Video input cable (NTSC)
SAA7113 - Pinnacle Studio Linx Video input cable (PAL)
SAA7113 - Pinnacle PCTV Bungee USB (PAL) FM