Canopus ADVC-100 has a TBC after all

[amaipaipai]

Who knew, the forum Nº1 favorite capture device has a TBC in it.

We all know the ADVC-110 doesn't have a TBC, the ADVC-300 does [1][2] and ADVC-100 is different from ADVC-110.

The samples are made with the ADVC-100 and a MyGica X8507 that uses a Conexant cx23885.
avs script:

DirectShowSource("E:\sample-5556.00.avi")
ConvertToYV12(interlaced=true)
TFM()
TDecimate()
Subtitle("ADVC-100", lsp=10, size=30, font="Courier New", text_color=$ffffff, align=3,610,310)

Don't know if this apply to every ADVC-100 out there. We know that there are ones that were pulled out the shelfs for unknown reasons, my board model is TPB-SA V0.

[redwudz]

Interesting.

My ADVC-100 died a year ago and I consigned it to the big trash heap in the sky. I enjoyed it while it worked, but we must all move on.
I had an early model that did ignore Macrovision. I now use a Diamond VC-500 and finished up my VHS tape to MKV conversions.

For other ADVC-100 users out there, good to know.

[amaipaipai]

To bad you trash it, the fix is quite simple (it doesn't mean it's easy).
My own died a few weeks ago, last time I used it was fine then all of a sudden, dead. Before dying however, the device has stop working a few times while I tried to capture something.

The cause it's pretty common, the AC adapter start to leak AC current in to the ADVC-100 main board, the responsible is a big electrolytic capacitor inside the AC adapter. The main board only works with DC by the way, this leaked current start to damage two voltage regulators, one of those regulate the voltage to the board main processor. If any one reading this still has an ADVC-100, you can trash the AC adapter and get another one (5VDC@2A) before the worst happens. You'll notice that your AC adapter has a problem when you notice horizontal pink/purple lines across the screen or strange transparent lines around the visible area.

Once the damage takes place, the voltage regulator start to oscillate, this cause the component to heat up to a point that exceed his own limits and I mean burning hot, I still have the part number mark on my finger. This oscillation also makes the main processor to oscillate and to heat up pretty fast, sometimes also causing the main processor lock up or stop responding.



The maintenance procedure is as follows:

A. Do not use the the original AC adapter.
1. Remove the board and cook it in the oven for an hour at 75 ºC (167 F) to remove any humidity left in the board and to release mechanical stress, the board will expand a little and avoid bending or warping of the main board during the maintenance.
2. Replace the blue marked part (the voltage regulator marked as U27), I don't have a part number neither I have access to any schematics. My measurements show that the input is about 4.5 VDC and output 1.2~2 VDC, since the part it's damaged is impossible to trust this values but is the best we got. My best guest it's a LDO regulator, SOT-223-3 package 1.2 VDC out. I've replace it with a part from another board with same output voltage characteristics.
3. Check the main 3.3VDC regulator, if it's 3.3VDC ok, otherwise replace it.
4. Across the board there are small 3.3 VDC Ricoh RH5RE33A regulators, make sure that the output is 3.3 VDC, otherwise, replace it.
5. I did a recap on my board, you can replace it all but the ones with a red circle on it, they are polymer capacitors, this capacitors use a solid polymer. Unless they are damaged, they don't need replacement.[1][2]
6. For my recaps I always use polymer capacitors, in case of standard electrolytic ones, electrolytic capacitor shelf life is very short, it ranges from 2 to 3 years so it requires voltage treatment before you put then to use. I've attached some technical documents with more details.

The ADVC-100 should be working again, it wasn't my intention to make a tutorial about how to fix the ADVC-100 so I didn't capture the actual noise, after the fix, you see some white lines across the screen like the ones bellow (they are simulated just to give an idea):


You have to replace decoupling ceramic capacitor bellow the Philips SAA7114 video decoder, is a big one, you can't miss it.

That's it.

[lordsmurf]

No.

I'm getting rather tired of all the Philips SAA7114 related posts, which suddenly appeared in the past few years, as it takes a simpleton view of what a TBC is and does. Chipsets alone do not determine the ability of quality of devices, nor is a true TBC provided by a single chip. The sudden SAA-7114 loving that I'm seeing online most definitely has its origins in marketing by some companies proclaiming their devices to have TBCs -- "TBCs" that do nothing, or near nothing, on closer inspection and independent testing. Neither line timing nor otherwise. It does not replace the need for S-VHS VCR TBCs, nor external TBCs, and does nothing for consumer analog sources as has been discussed at sites like this for 15+ years now.

Is that SAA-7114 used in actual TBCs? Some, yes. Is that chipset alone a TBC? Absolutely not.

Furthermore, the claim that the ADVC-300 has a TBC has been disproven many times, again in terms of "meaningful TBC for consumer analog sources", and was merely Canopus taking marketing advantage of a term that is very loosely defined.

So again, no.

And that overlooks the dangerous decade-old mythical claim that baking a computer card helps it in any meaningful way. Best case is a board that works temporarily, worst case is you start a fire or hurt yourself. The method usually fails more than not. It reminds me of the "stick your HDD in the freezer" myth.

[amaipaipai]

No.

I'm getting rather tired of all the Philips SAA7114 related posts, which suddenly appeared in the past few years, as it takes a simpleton view of what a TBC is and does. Chipsets alone do not determine the ability of quality of devices, nor is a true TBC provided by a single chip. The sudden SAA-7114 loving that I'm seeing online most definitely has its origins in marketing by some companies proclaiming their devices to have TBCs -- "TBCs" that do nothing, or near nothing, on closer inspection and independent testing. Neither line timing nor otherwise. It does not replace the need for S-VHS VCR TBCs, nor external TBCs, and does nothing for consumer analog sources as has been discussed at sites like this for 15+ years now.

Is that SAA-7114 used in actual TBCs? Some, yes. Is that chipset alone a TBC? Absolutely not.

Furthermore, the claim that the ADVC-300 has a TBC has been disproven many times, again in terms of "meaningful TBC for consumer analog sources", and was merely Canopus taking marketing advantage of a term that is very loosely defined.

So again, no.

Yes.
Previous posts here and in the df forum has only one side of the story, there is no samples, no tests, nothing. Now people have samples to look in to and make their own minds about. As people can see, it does a pretty good job at it and it doesn't have the DV 4:1:1 chroma subsampling limitation.
What is or isn't, it really doesn't matter, it get the job done, end of story.

And that overlooks the dangerous decade-old mythical claim that baking a computer card helps it in any meaningful way. Best case is a board that works temporarily, worst case is you start a fire or hurt yourself. The method usually fails more than not. It reminds me of the "stick your HDD in the freezer" myth.

I don't know what you are talking about.
The baking part on my text it's related with electronic maintenance, it won't fix anything, this is a required procedure to avoid the PCB crack or delamination caused by moisture expansion as described in the standard IPC/JEDEC-J-STD-033C[1]. Also, this is a required procedure on any fiberglass PCB before you do any selective soldering or desoldering[2][3].

Another thing about decade old boards it's that ceramic capacitors degrade/changes over time and to recover it, you have to preheat the board than apply 125 ºC on each and every ceramic capacitor on the board to heal it[4].

All this are trade secrets people don't know about, it has nothing to do with with whatever video or forum post people "teach" on how to recover your Xbox, PS3/4 or VGA by cooking it in an oven.

[DB83]

In the other topic you decided to dig up just to refer to this topic I made some contribution.

I described the differences I had seen with my own eyes between a basic capture and one done with a ADVC 300.

Now I have looked at your samples. In fact I have looked at them more than once. Actually, unless I am looking for the wrong things so be as kind as to highlight them, I see no difference between the two other than the ADVC having richer colour/better contrast.

lordsmurf is a long-time respected contributor here and, yes, he does have a dislike about DV boxes but I still respect his opinion.

[amaipaipai]

That topic it's fixed.

I believe you are looking at the wrong places, pay attention to the pink text on both, you'll see the text shaking side to side in the cx23885 sample, once you got that, look around to notice that the whole screen is waving. Also make sure your player doesn't have any screen stabilizer. Besides the brand ADVC-100 it's not ADVC-110 or ADVC-300, they have a different hardware inside and the ADVC-100 has different board models.

On the capture issue, the ADVC also has more details, the cx23885 has a more soft look.

lordsmurf it's an old friend, come on. Because I disagree with him it doesn't mean I don't respect him. On the story related with ADVC-100, yes I respectfully disagree unless he can provide something to prove otherwise. The guy don't need to prove anything to me or anyone, I'm talking about the claim he does about it, why he dislike it?
There's some story behind it? Can he show us something? There's something to watch and compare?

I don't see this as a "win / loose" situation, instead I see as a new discussion about a "hot topic" with clear evidence for people to compare and make their own decision.

[lordsmurf]

I see no difference between the two other than the ADVC having richer colour/better contrast.

There is a difference, but I'm not sure what to attribute it to. Conexant (CX, BT) is essentially an internal version of the EZcap/EZcrap card. Not in chipset or anything, just in general craptastic performace. So a truer comparison would be to known quality cards. So what I see here is interesting, but completely inconclusive.

notice that the whole screen is waving.

Yes, that's it exactly. But my problem is that lousy capture cards can actually induce timing errors, and I don't trust Conexant chips. CX/BT has always been bottom of the barrel, going back to the 90s.

why he dislike it? There's some story behind it?

Two reasons:

(1) Canopus was more about marketing that anything else. They wanted to be a Sony, cashing in on name recognition alone, often distorting facts in the claims made for their products. Stuff like "audio lock" was false nonsense, possibly written by somebody that didn't understand what that actually meant. Many newbies latched on to those things, and usually further distorted it into more nonsense like the 'telephone game'.

(2) DV loses too much color data, by quartering to 4:1:1. Meaning I'm not against PAL use, only the NTSC. Halving color alternating is far more acceptable, and is what DVD does, 4:2:0.

That's really it.

- I don't like video myths.
- I don't like needlessly harming color quality, seeing as how color is already stored pretty rotten on consumer analog formats.

All this are trade secrets people don't know about, it has nothing to do with with whatever video or forum post people "teach" on how to recover your Xbox, PS3/4 or VGA by cooking it in an oven.

If you have the proper equipment for those procedures, that's fine. But you can't use the same oven in your kitchen, which is what 99% of readers would do.

I see as a new discussion about a "hot topic" with clear evidence for people to compare and make their own decision.

All I've really seen in the thread is this quick mention:
"You have to replace decoupling ceramic capacitor bellow the Philips SAA7114 video decoder, is a big one, you can't miss it."

I'm still not sure how that alters the chip, unless it ... I don't know ... supercharges it? I'm guessing here, but it reads as it the chip doesn't do any timing correction when underpowered? I'm still not seeing it as being that easy. And that assumes it wasn't simply a bad test showing the difference between a bad capture card and a good one (albeit with lossy DV issues).

I've pulled apart lots of TBCs over the years.

I've also researched almost every claim of "it's a TBC!" over the years, having bought many capture cards, broadcast TBCs, DVD recorders, and various devices. More than once, I've lost money chasing down these phantoms. Most are disappointments, some hugely so. I was the person that discovered the ES10 had passthrough some 10-15 years ago, back when I was doing DVD recorder research.

So if you're finding TBC performance, I'm all for it. But the SAA7114 is getting undeserved kudos as of late, and I've seen several others let down by its performance when it was fully tested. It's just a chip, not a TBC unto itself.

[JVRaines]

And that overlooks the dangerous decade-old mythical claim that baking a computer card helps it in any meaningful way. Best case is a board that works temporarily, worst case is you start a fire or hurt yourself. The method usually fails more than not. It reminds me of the "stick your HDD in the freezer" myth.

I can only speak from my experience, but I once reflowed a video card in my oven, figuring I had nothing to lose, and it ran fine for another year or so until I sold it.

[lordsmurf]

And that overlooks the dangerous decade-old mythical claim that baking a computer card helps it in any meaningful way. Best case is a board that works temporarily, worst case is you start a fire or hurt yourself. The method usually fails more than not. It reminds me of the "stick your HDD in the freezer" myth.

I can only speak from my experience, but I once reflowed a video card in my oven, figuring I had nothing to lose, and it ran fine for another year or so until I sold it.

Yes, there's always success stories, needles in haystacks. I've done some pretty goofy stuff, but I knew it was risky, and more likely to fail than not. I've even started fires, experiments gone wrong, but it was in a controlled workspace. I'm all for using things in ways not intended/imagined, or life/hardware hacking, etc. But the most important aspect is to always know the odds and risks. Sometimes you can defy them, but usually not.

Congrats on the video card, it was like winning a few hundred bucks on a lottery ticket.

[amaipaipai]

Two reasons:

(1) Canopus was more about marketing that anything else. They wanted to be a Sony, cashing in on name recognition alone, often distorting facts in the claims made for their products. Stuff like "audio lock" was false nonsense, possibly written by somebody that didn't understand what that actually meant. Many newbies latched on to those things, and usually further distorted it into more nonsense like the 'telephone game'.

(2) DV loses too much color data, by quartering to 4:1:1. Meaning I'm not against PAL use, only the NTSC. Halving color alternating is far more acceptable, and is what DVD does, 4:2:0.

That's really it.

- I don't like video myths.
- I don't like needlessly harming color quality, seeing as how color is already stored pretty rotten on consumer analog formats.

I don't know any background history on Canopus, all I know is that Canopus was big in Japan back in the days. Yes, I'm aware of DV 4:1:1 chroma subsampling, the ADVC-100 doesn't have this limitation, that is why I've choose a red scene for the sample.

If you have the proper equipment for those procedures, that's fine. But you can't use the same oven in your kitchen, which is what 99% of readers would do.

Yes, I do.
That is why I'm against video tutorials showing people cooking PCB boards with their mom's oven.

All I've really seen in the thread is this quick mention:
"You have to replace decoupling ceramic capacitor bellow the Philips SAA7114 video decoder, is a big one, you can't miss it."

I'm still not sure how that alters the chip, unless it ... I don't know ... supercharges it? I'm guessing here, but it reads as it the chip doesn't do any timing correction when underpowered? I'm still not seeing it as being that easy. And that assumes it wasn't simply a bad test showing the difference between a bad capture card and a good one (albeit with lossy DV issues).

I've pulled apart lots of TBCs over the years.

To understand that and to look for specific technical details, google "self healing capacitors" there are tons of documents about it amonte the ones I've shared on the previous post. I've also given more info about it at this post:
https://forum.videohelp.com/threads/388166-Panasonic-VCR-issues-what-could-it-be#post2513291

Much of this are trade secrets between technicians, when we spot stuff like this we know what to look for and what to do. I don't do it in every and each board I repair, only if necessary.

I've also researched almost every claim of "it's a TBC!" over the years, having bought many capture cards, broadcast TBCs, DVD recorders, and various devices. More than once, I've lost money chasing down these phantoms. Most are disappointments, some hugely so. I was the person that discovered the ES10 had passthrough some 10-15 years ago, back when I was doing DVD recorder research.

So if you're finding TBC performance, I'm all for it. But the SAA7114 is getting undeserved kudos as of late, and I've seen several others let down by its performance when it was fully tested. It's just a chip, not a TBC unto itself.

Again, I'm not willing to start a fight and get in to the merit if the chip or the ADVC-100 is a "perfect" or "ideal" TBC or not, it works. It get the job done, it might not be perfect but it's good enough for many people out there.

Many of this technology and knowledge are dying, some are dead already, I'm from the time that composite video was the HDMI of today, can you believe it?
All I'm doing is to try to share some knowledge so this dead technology might last a little bit longer.

[lordsmurf]

Yes, I'm aware of DV 4:1:1 chroma subsampling, the ADVC-100 doesn't have this limitation, that is why I've choose a red scene for the sample.

Not correct. DV is fixed at 4:1:1 NTSC, or 4:2:0 color, and the Canopus ADVC boxes are DV hardware encoding, so it is limited to those colorspace specs.

That is why I'm against video tutorials showing people cooking PCB boards with their mom's oven.

Good.

Again, I'm not willing to start a fight and get in to the merit if the chip or the ADVC-100 is a "perfect" or "ideal" TBC or not, it works. It get the job done, it might not be perfect but it's good enough for many people out there.

That's just it. Too many claimed "TBCs" are super narrow in scope, only working in specific scenarios. And it doesn't help that TBC is such a wide term. Both at VH and digitalFAQ, and other sites, I've often mused that I sometimes wonder if my toaster could claim to have a TBC.

Many of this technology and knowledge are dying, some are dead already, I'm from the time that composite video was the HDMI of today, can you believe it?

I prefer "legacy", sometimes "antique" or "retro", unless it's just a total POS (like most consumer VHS VCRs from 90s/00s).

But I'd argue that TBC are still current, very in demand items.

All I'm doing is to try to share some knowledge so this dead technology might last a little bit longer.

Whatever you find is good to share, but my main concern is that the hobby/field still has many newbies, and they can easily get confused. It's bad enough that your average shady fly-by-night service, or Best Buy or B&H salesman, feeds them a diet of BS. But sites like digitalFAQ have a higher standard, and VH should have a higher standard (and I've always treated it as such), and we need to be careful about throwing around the term TBC too easily and liberally.

[jagabo]

I'm aware of DV 4:1:1 chroma subsampling, the ADVC-100 doesn't have this limitation

Yes, it does. And it's visible in your sample. Unfortunately you didn't provide the original caps but even with your YV12 reencoded videos you can see the loss of chroma resolution:


[Attachment 47264 - Click to enlarge]

On the left is the Cx23885 cap, the right the ADVC100 cap. On the top is the U channel, the bottom the V channel, both contrast stretched to make the differences more obvious. In the CX cap you can see individual letters in the word "Daddy". In the ADVC cap they have blurred together. There's also lots of block and line artifacts in the latter.

[amaipaipai]

lordsmurf - I believe that ADVC-100 uses NTSC 4:2:0, any recommended free DV codec to do a side by side comparison?

jagabo - I still got the ADVC-100 capture, need to recapture the other one, I'll upload latter.
YV12 it's a disaster on it self, I don't like it but it's the only format my TV and bluray player accept. All I see is a big mess, the line artifacts is related with the decoupling capacitor that causes this jail bar noises, the screen it's in B&W because the ADVC doesn't understand PAL-M:


They are not so obvious in the sample, but if they are still there, some other caps need to be replaced.

Maybe it's time for you to get the old lady jagabo
This is a raw capture from the ADVC-100 from a ISDB-T digital TV source using S-Video, it has a lot of pink and red to test.

https://mega.nz/#!a0ZGRLaL!brwdhJhdhELiPo209uWB12iVvugw_KcV51jyBrb0No0

[jagabo]

You need to provide a Conexant cx23885 capture of the same source to see the differences. But you'll find a YUV 4:2:2 cap has more saturation of all those small colored objects on her apron, and less bleeding around the edges of her pink shirt.

[lordsmurf]

lordsmurf - I believe that ADVC-100 uses NTSC 4:2:0

No, DV is 4:1:1 NTSC, and 4:2:0 PAL. There is no variant, no choice in the matter. That is it, period.

from a ISDB-T digital TV source using S-Video

Errors are far more obvious and pronounced when starting from the already color-lossy VHS format.

The problem I have with your samples is the randomness of it all. That's not how testing is conducted. You need some that are repeatable to yourself, and to others. You must eliminated variables. For example, the DOF of the green in that last image makes it moot, and the fleeting source (satellite transmission) is neither replicable to yourself or others.

[amaipaipai]

You need to provide a Conexant cx23885 capture of the same source to see the differences. But you'll find a YUV 4:2:2 cap has more saturation of all those small colored objects on her apron, and less bleeding around the edges of her pink shirt.

Sorry, I'm not home yet.

No, DV is 4:1:1 NTSC, and 4:2:0 PAL. There is no variant, no choice in the matter. That is it, period.

That's the thing, somebody at Canopus did something good (or bad) then. I'll ask again, there is any trust DV codec I can use to do a comparison?

Errors are far more obvious and pronounced when starting from the already color-lossy VHS format.

The problem I have with your samples is the randomness of it all. That's not how testing is conducted. You need some that are repeatable to yourself, and to others. You must eliminated variables. For example, the DOF of the green in that last image makes it moot, and the fleeting source (satellite transmission) is neither replicable to yourself or others.

That is why this is a "hot topic", the sources I have are random, the FTA signal comes this way. If you take the jagabo "old lady" friend, that thing is progressive all the way and recorded like that by the ADVC-100, the sample it's a raw DV format and it doesn't look like a DV to me or anyone else.

Maybe I can use the Avisynth "ColorBars(720,480)" function and somehow, find a way to generate a S-Video signal to be captured by the ADVC.
I believe this can be replicable by anyone.

[amaipaipai]

Here is your files jagabo.
More uploads later.

[amaipaipai]

Now for the DV test, this is the default setup for the cx23885, I can't change it, the only thing I can change is the video standard NTSC, PAL, PAL-M, etc.


The image source used comes from this site:
http://codecs.onerivermedia.com/
http://codecs.onerivermedia.com/images/results/source_1080.png

The player it's a Zinwell ZBT-620A, photo mode, S-video output the player offers no setup in photo mode. The DV sample was generated with Cedocida DV Codec V 0.2.3 using avisynth and virtualdub 1.10.4, encoded with DV settings.
Script:

function PadHeight(clip image, int width, int height, int AR_WIDTH, int AR_HEIGHT)
{
	# the frame is wider than we want, pad the top and bottom

	# calculate what final height we need
	nh = width * AR_HEIGHT / AR_WIDTH

	# calculate the top and bottom borders
	tb = (nh - height) / 2
	bb = nh - height - tb
	AddBorders(image, 0, tb, 0, bb)
}

function PadWidth(clip image, int width, int height, int AR_WIDTH, int AR_HEIGHT)
{
	# the frame is taller than we want, pad the left and right

	# calculate the final width we need
	nw = height * AR_WIDTH / AR_HEIGHT

	# calculate the left and right borders
	lb = (nw - width) / 2
	rb = nw - width - lb
	AddBorders(image, lb, 0, rb, 0)
}
ImageSource("E:\source_1080.png")
ConvertToRGB32() # Cedocida DV codec requirement

# if you want 16:9 change these values to 16 and 9
AR_WIDTH = 4
AR_HEIGHT = 3

width = last.width
height = last.height

((width * AR_HEIGHT) > (height * AR_WIDTH)) \
	? PadHeight(last, width, height, AR_WIDTH, AR_HEIGHT)\
	: PadWidth(last, width, height, AR_WIDTH, AR_HEIGHT)

tw = 720
th = 480

PointResize(tw, th)

This is the result image:


The DV 4:1:1 encoded output:


The ADVC-100 S-Video 4? (RAW):


The cx23885 S-Video 4:2:2 (RAW), converted with Lararith Lossless Codec with YUY2 setting:


I'll upload the samples latter.

[amaipaipai]

The samples.

Just to make it clear, the script was used to match the player output. The player doesn't offer any settings or adjustments for photo mode.

[lordsmurf]

is any trust DV codec I can use to do a comparison?

Since the DV codec is in the hardware, your question doesn't make sense.

The DV 4:1:1 encoded output:

No it's not. In fact, I have no ideas what that is supposed to be showing.

The ADVC-100 S-Video 4? (RAW):

It's not RAW. It's processed to DV in the hardware, and the DV color hit is very obvious. Vibrance is lost, artifacting in the color stripes.

[amaipaipai]

Since the DV codec is in the hardware, your question doesn't make sense.

I don't have any DV hardware around to use, so the source has to be software encoded.

The DV 4:1:1 encoded output:

No it's not. In fact, I have no ideas what that is supposed to be showing.

It's showing what happens when you encode the source with a DV codec.

The ADVC-100 S-Video 4? (RAW):

It's not RAW. It's processed to DV in the hardware, and the DV color hit is very obvious. Vibrance is lost, artifacting in the color stripes.

RAW meaning it was cut as is, direct from hardware. The stripes are not so obvious with the encoded DV sample.

What this show is that the output of ADVC-100 it's something else, not standard 4:1:1 DV or the hardware are smoothing something out.
I don't know.

[lordsmurf]

I don't know.

Well, I know.

What you're seeing is typical DV with color loss and artifacting.

And while the minor timing correction is interesting, it's unavailable for practical application. Also inconclusive findings.
And again a mere single chip isn't a TBC.
And the thread title is misleading, false assertion.

[poisondeathray]

Looks like some issues in your test setup. Different resize algorithm in your "simulated" DV

You are point resizing (nearest neighbor) the original image to feed into a software DV encoder , but it doesn't look like you're using that same source for the ADVC-100 or cx23885 test . For example, you can see the jaggies in the black lines of ferrari bumper, but not the ADVC-100 or cx23885 test, that's strong evidence that something different is used

Here is a DV test. I used your avs script, with spline36resize instead of pointresize, and ConvertToYV411 . ffmpeg to encode

This image is taken from the DV video attached below. It's opened natively as the original 4:1:1 using ffms2. (If you decode to 420, or 422, or your DV decoder is incapable of true 411 output there is quality loss). Then it's upsampled to RGB using bicubic.

[Attachment 47276 - Click to enlarge]

The framing and AR in your script is slightly different than your HW examples, and obviously different contrast, saturation - but you can tell that the similar amount of color blurring is present along colored edges

You can conduct these types of test in the absence of DV compression too, just by using avisynth, because it supports 4:1:1. So you can "see" the degradation from a full RGB image without lossy compression issues

[amaipaipai]

Looks like some issues in your test setup. Different resize algorithm in your "simulated" DV

You are point resizing (nearest neighbor) the original image to feed into a software DV encoder , but it doesn't look like you're using that same source for the ADVC-100 or cx23885 test . For example, you can see the jaggies in the black lines of ferrari bumper, but not the ADVC-100 or cx23885 test, that's strong evidence that something different is used.

I saw no point to feed a DV encoded source in to something that will re-encode it back to DV again.

What I did was to resize the "source_1080.png" to be compatible with the the DV codec, than encode it so we can have a reference. The original "source_1080.png" was used in the player and from there the S-Video signal was used by the ADVC-100 and cx23885 to capture it.

Here is a DV test. I used your avs script, with spline36resize instead of pointresize, and ConvertTo411 . ffmpeg to encode

I don't like to use any "spline" to downsize anything, that is why I've chosen pointresize, to see defects instead of hidden them by a filter.

function downup(clip a, string r) {
  w=a.width
  h=a.height # corrected from a.width
  return r=="16" ? a.spline16resize(w/2,h/2).spline16resize(w,h) :\
         r=="36" ? a.spline36resize(w/2,h/2).spline36resize(w,h) :\
         r=="64" ? a.spline64resize(w/2,h/2).spline64resize(w,h) : 0
}

function x(clip a, string r, int l) {
  return l>0 ? a.x(r, l-1).x(r, l-1) : a.downup(r)
}

blankclip(100,32,32).invert
addborders(32,32,32,32)

stackhorizontal(\
  last.subtitle("original"),\
  x("16",8).subtitle("spline16"),\
  x("36",8).subtitle("spline36"),\
  x("64",8).subtitle("spline64")\
)

pointresize(width*2,height*2)

This image is taken from the DV video attached below. It's opened natively as the original 4:1:1 using ffms2. (If you decode to 420, or 422, or your DV decoder is incapable of true 411 output there is quality loss). Then it's upsampled to RGB using bicubic.

[Attachment 47276 - Click to enlarge]

This is how your video looks like decoded here.


Adjusting to your changes, Cedocida codec still show the same issue:


Taking aside the levels that I've no control of, you sample looks much closer to the ADVC-100 output.

The framing and AR in your script is slightly different than your HW examples, and obviously different contrast, saturation - but you can tell that the similar amount of color blurring is present along colored edges

You can conduct these types of test in the absence of DV compression too, just by using avisynth, because it supports 4:1:1. So you can "see" the degradation from a full RGB image without lossy compression issues

Yes, the framing it's different, it's just a simulation, trying to mimic the player output.

Jagabo developed that script, the guy is very smart, the script it's very handy. I wish I could use a image as a background or maybe a "zoom in" of the actual footage instead of pure black bars.

The idea was to see the performance of this two devices, that's all, nothing serious.
But thank you for your feedback, it was important!

[poisondeathray]

I saw no point to feed a DV encoded source in to something that will re-encode it back to DV again.

I'm just explaining why you see some of the larger differences, like blocky color edges

This is how your video looks like decoded here.

This is because your decoder isn't decoding it as 4:1:1 which is the the native NTSC format - so you're actually seeing some additional notching artifacts. Compare it to the one I posted earlier. You are using 2 resize steps to get to an RGB image, instead of 1 . More quality loss. Most decoders will use nearest neighbor for the 1st step, causing blocky color edges

The truth is most NTSC DV decoders will output 4:2:2, so most will look like that screenshot you posted. If you opened it up in some NLE for example. Only with something like avisynth / vapoursynth / ffmpeg can you usually manipulate 4:1:1 as 4:1:1

Adjust to your changes, Cedocida codec still show the same issue:

This is because cedocida does not accept 4:1:1 input . Most DV ENcoders do not. So there is an extra chroma resize step (from 422 or 420 to 411) , extra quality loss. You don't have control over that resize step (the codec does it) and it looks like the resize is done with nearest neighbor, which causes the blocky color edges

Note - sometimes you want blocky edges, instead of smooth. Sometimes in post production, it's worse to have smooth edges as the intermediate. It's better to have more control, more options

[amaipaipai]

Thank you poisondeathray

[amaipaipai]

Cedocida doesn't offer too much to play with.


Specially in Windows 10, there is no option to change the decoding settings.
We need this on Windows 10.

[poisondeathray]

Cedocida doesn't offer too much to play with.

Specially in Windows 10, there is no option to change the decoding settings.

Not very many DV Decoders/Encoders can accept /output 4:1:1.

Cedocida is VFW only, not directshow (ie. it won't be used in a directshow player, like mpchc)

ffmpeg based ones typically can. For example, open that video in mpchc (I have mine configured with lav decoder, which uses ffmpeg libraries), and it looks like the screenshot I posted in terms of color edges and fewer blocky edges

You can use ffms2 in avisynth, that will open NTSC DV as 4:1:1 . Then you can upsample the chroma (and convert to RGB) using whatever algorithm. By default , avisynth uses bicubic for everything, that's exactly what was used for the screenshot.

If you look at your decoded image of "proper_ntsc_dv.avi" vs. the one I posted with ffms2 earlier, you will notice additional artifacts. Look especially at the vertical diagonals. But your image is what you would get with 99% of software, professional tools included like NLE's. And the main reason is that extra chroma resize step before RGB for a preview or screenshot



Eitherway, 4:1:1 is bad. There is just too much color information missing. But you can use various workflows to make it look "less bad", fewer conversions in terms of the up/downsampling "behind the scenes" certainly helps

[amaipaipai]

More on splines, this is why I don't use it to downscale anything:

##################################
## Source: https://forum.doom9.org/showthread.php?t=172483
function DownSize(clip C, int wid, int hgt)
{
    return C.Spline64Resize(wid, hgt)
}
strHalfsize = "Spline64" ## DownSize resize method
#strHalfsize = "same as upsize" ## (gUseHalfSize = false)
global gUseHalfSize = True ## set to True to use DownSize for all downsizing

reps=256 ## DownSize+upsize repetitions

reps3=16 ## max nnedi3 reps (due to memory limits)

A = ImageSource("0.png", start=0, end=1)
\	.ConvertToYV12(matrix="Rec709", chromaresample="spline16")
X = BlankClip(A)

B = ImageSource("3.png", start=0, end=1)
\	.ConvertToYV12(matrix="Rec709", chromaresample="spline16")

C = ImageSource("1.png", start=0, end=1)
\	.ConvertToYV12(matrix="Rec709", chromaresample="spline16")

D = ImageSource("4.png", start=0, end=1)
\	.ConvertToYV12(matrix="Rec709", chromaresample="spline16")

## all images 160x128

A = StackHorizontal(
\	A
\ /*, A.ResizeNnedi3(Min(reps3, reps)) */
\ , A.ResizeS64(reps)
\ , A.ResizeS36(reps)
\ , A.ResizeS16(reps)
\ )

B = StackHorizontal(
\	B
\ /*, B.ResizeNnedi3(Min(reps3, reps)) */
\ , B.ResizeS64(reps)
\ , B.ResizeS36(reps)
\ , B.ResizeS16(reps)
\ )

C = StackHorizontal(
\	C
\ /*, C.ResizeNnedi3(Min(reps3, reps)) */
\ , C.ResizeS64(reps)
\ , C.ResizeS36(reps)
\ , C.ResizeS16(reps)
\ )

D = StackHorizontal(
\	D
\ /*, D.ResizeNnedi3(Min(reps3, reps)) */
\ , D.ResizeS64(reps)
\ , D.ResizeS36(reps)
\ , D.ResizeS16(reps)
\ )

Z = StackHorizontal(
\	X.Subtitle("original", align=5, size=C.Height/4)
\ /*, X.Subtitle("nnedi3\nx"+String(Min(reps3, reps)), align=5, lsp=0, size=C.Height/4) */
\ , X.Subtitle("S64\nx"+String(reps), align=5, lsp=0, size=C.Height/4)
\ , X.Subtitle("S36\nx"+String(reps), align=5, lsp=0, size=C.Height/4)
\ , X.Subtitle("S16\nx"+String(reps), align=5, lsp=0, size=C.Height/4)
\ )

return StackVertical(Z.Crop(0, 24, 0, -16), A, B, C, D)
\ .Subtitle("downsize mode = " + strHalfsize, align=2)

##################################
function ResizeS16(clip C, int count)
{
	 R = C.Spline16Resize(2*C.Width, 2*C.Height)

	 R = (gUseHalfSize)
	 \ ? R.DownSize(C.Width, C.Height)
	 \ : R.Spline16Resize(C.Width, C.Height)
	 
	 return (count <= 0) ? C : R.ResizeS16(count - 1)
}
 
##################################
function ResizeS36(clip C, int count)
{
	 R = C.Spline36Resize(2*C.Width, 2*C.Height)

	 R = (gUseHalfSize)
	 \ ? R.DownSize(C.Width, C.Height)
	 \ : R.Spline36Resize(C.Width, C.Height)
	 
	 return (count <= 0) ? C : R.ResizeS36(count - 1)
}
 
##################################
function ResizeS64(clip C, int count)
{
	 R = C.Spline64Resize(2*C.Width, 2*C.Height)

	 R = (gUseHalfSize)
	 \ ? R.DownSize(C.Width, C.Height)
	 \ : R.Spline64Resize(C.Width, C.Height)
	 
	 return (count <= 0) ? C : R.ResizeS64(count - 1)
}
 
##################################
function ResizeNnedi3(clip C, int count)
{
	 R = C.UUNnedi3EnlargeYV12(2*C.Width, 2*C.Height, -1)

	 R = (gUseHalfSize)
	 \ ? R.DownSize(C.Width, C.Height)
	 \ : R.Spline64Resize(C.Width, C.Height)
	 
	 return (count <= 0) ? C : R.ResizeNnedi3(count - 1)
}

##################################
### high quality enlarge (simplified version - YV12 only)
##
## @ wid, hgt - new width & height (no enlargement by default)
## @ speed	 - if > 0, tune for speed; if < 0, tune for quality;
##					default = 0 (medium)
##
function UUNnedi3EnlargeYV12(clip C, int "wid", int "hgt", int "speed")
{
	 Assert(C.IsYV12,
	 \  "UUNnedi3Enlarge: source must be YV12")

	 wid	 = Max(16, Default(wid, C.Width))
	 hgt	 = Max(16, Default(hgt, C.Height))
	 speed  = Default(speed, 0)

	 nns	 = (speed<0) ? 4 : ((speed>0) ? 2 : 3)
	 qual	= (speed<0) ? 2 : 1
	 zfact  = Max(Float(wid)/C.Width, Float(hgt)/C.Height)
	 rfact  = (zfact >32.0001) ? 64
	 \		: (zfact >16.0001) ? 32
	 \		: (zfact > 8.0001) ? 16
	 \		: (zfact > 4.0001) ?  8
	 \		: (zfact > 2.0001) ?  4
	 \		: 2
	 xshift = -(0.5 * rfact - 0.5)

	 ## avoid subtle color shift (only visible after many passes)
	 Y  = C.nnedi3_rpow2(rfact, nns=nns, qual=qual, cshift="Spline64Resize", 
	 \						 fwidth=wid, fheight=hgt)
	 UV = C.Spline64Resize(wid, hgt, src_left=xshift, src_top=-0.5)
	 return YToUV(UV.UToY, UV.VToY, Y.ConvertToY8)
}