ADVC300 color-space of DV output.

[Meow]

I seem to be able to capture it as whatever I wish to capture it in.
The DV stream is dvsd RGB24 according to one package, but UYVY according to another, or YUY2. So my question is:

What is the actual color-space it is supposed to send out when using it in PAL 720x576 25p, from VHS/Hi8 sources on the s-video input?
(and why on earth is that info not ANYWHERE in the specs or documentation?)

[GrassValley_BH]

http://www.adamwilt.com/DV-FAQ-tech.html

The datastream coming in over FireWire is already compressed DV data, so if you do any traditional "capture" you'll end up decompressing and recompressing it. The ADVC looks and acts like a DV camcorder/deck.

[Meow]

http://www.adamwilt.com/DV-FAQ-tech.html

The datastream coming in over FireWire is already compressed DV data

Yes, I know, that's why I'm asking: What is the actual color-space used by the ADVC300 in that stream?
(that info is not in the FAQ you linked to, nor is it mentioned anywhere regarding the ADVC300, which to me is ridiculously weird, even my old cameras mention the colorspace they output)

[GrassValley_BH]

I already told you, it's YCbCr colorspace.

http://www.adamwilt.com/DV-tech.html

But it kind of sounds like you're really asking what codec DV is? DV is Consumer DV codec - the same compression used by consumer miniDV camcorders.

In Microsoft world, the FourCC is dvsd.

It really sounds like your software is wanting to capture and compress the input, rather than simply do a strict data transfer. DV capture is different from traditional DirectShow or VfW capture (which is capture and compress). DV capture is a simple bit-for-bit copy - no recompression or decompression.

[rl2008]

just like any other DV codec ?

Brandon,

Somewhere (I cannot find it right now) you guys made claims that ADVC300 sports this incredible Canopus DV codec, and the idea seemed to be that it is nothing like those other codecs. I remember this being a factor in my purchase of this unit. You seem to be saying here that there is really only one consumer DV codec out there and there is nothing unusual about the compression done by ADVC300 ? Why then are there downloadable playback Canopus DV codecs in the user area ?

regards,

Roman

[Meow]

It really sounds like your software is wanting to capture and compress the input, rather than simply do a strict data transfer. DV capture is different from traditional DirectShow or VfW capture (which is capture and compress). DV capture is a simple bit-for-bit copy - no recompression or decompression.

So, do you know of any free capture software tools out there that store the bit-for-bit copy the ADVC300 outputs?

[THoff]

WinDV does. Any NLE should do it.

[GrassValley_BH]

Hi Roman,

The DV specification defines the rules for the output data. It does not, however, define exactly how that data should be compressed.

It's the same as with MPEG compression. You can have two MPEG-2 streams with the same encoded bitrate, GOP structure, frame size, field order, etc - that look entirely different on playback.

Or back to the food analogies... Peanut butter cookie. You might like the Grandma's peanut butter cookies (these are often the ones sold at tradeshow concessions - for far more than they cost at Costco), someone else might like Otis Spunkmeyer. They're both peanut butter cookies, but they definitely have different qualities to them, while both staying within the rules of being a peanut butter cookie.

The reason for having the playback-only Canopus DV codec is a bit separate. Even though the output is DV-spec, we have our own FourCC identifier for the Canopus DV codec (CDVC). This ensure that when you create a DV file using the Canopus DV codec, it really uses the Canopus DV codec engine, and not the Microsoft DV codec or something else.

Because it has its own identifier, the system doesn't "know" what codec to use for decompressing it unless that codec is installed. It's just like how DivX files won't play back if the system doesn't have the DivX codec installed.

Nowadays our modern applications still use the Canopus DV codec for compression, but the output file is given a DVSD (Microsoft DV) codec identifier, so the file can be played back on any modern Windows system using the built-in Microsoft DV codec.

MPEG doesn't have this whole FourCC thing - the system just knows what codec(s) are installed for decoding MPEG. That's why utilities like MediaPlayer Classic are useful because you could end up having multiple MPEG codecs installed, and not know which one is being used.

Hope that helps to clear things up a bit.

[rl2008]

codecs and formats jungle

Brandon,

Yes, your explanation clarifies things. In fact after I sent this message I realized the hole in my thinking. However, I would like to throw a few related questions at you that came up when I bough the 300 and installed NEO that came with it. I suspect they are puzzling more people.

1. Capture. When I run ADVC300 capture into EDIUS, clips normally go into Bin (I know they can go into timeline, but I want to focus on saving files for later use). At the same time corresponding files are saved into project folder on HD.
1a. What format are these files in project folder ?
1b. Are they being uncompressed (when received from OHCI) and then recompressed (when saved to HD) by EDIUS, or is that a direct flow of DV data ?
1c. Is there any advantage in exporting clips from Bin (better quality ?)
1d. Can one manipulate clips in Bin a bit, lat's say trim them better, maybe split them different way (call it library maintenance work), and then export them out for later use ?
1e. If one wants to export clips from bin, what is the best choice of output format, taking into account original compression loss and possibly limitations of internal representation in EDIUS, but trying to maintain the best quality that is left.
1f. Batch capture really does not apply to pulling VHS data in through ADVC300, does it ?

2. Internal representation. Can you comment on the internal representation EDIUS uses for video data ? I was told it is 8 bit per component. No fractions, fixed or floating ? What happens to 10 bit (or deeper) input data when it is imported into EDIUS ? Truncation ? Could you point me to any specifications that define or describe uncompressed 10 bit (or deeper) formats that EDIUS can import. There are specific reasons that have to do with images I use at work, not the VHS stuff I'm playing with at home.

3. Output. Once again, if you have a handy link that describes some of the output formats you guys export (you seem to have good links :-) I would like to learn more.
3a. But there is another codec issue there. Could you please comment on the choices and differences between them when it comes to exporting to DVD. There is the built-in encoder (is that Canopus HQ ?) that comes with EDIUS, even NEO. Then there is ProCoder. Same encoder in both ? Different ? What are practical differences, especially in terms of the encode quality (to recall your correct comment on differences between various encoders producing the same output format).

thanks,

Roman

[GrassValley_BH]

Hi again Roman,

1. Capture to the Bin or directly to the Timeline, either results in a captured file (or group if automatic division is on) on the disk. Bin items are just "pointers" to the actual clip file(s) on the disk.

1a. They're whatever format the capture is in.
For OHCI-based DV capture, then they are DV AVIs.
For HDV capture, if you select native MPEG-2 TS for capture, then they are native HDV .m2t files, if you select Canopus HQ, then the streams are decoded and recompressed to Canopus HQ and saved as Canopus HQ AVI files.
For analog and SDI capture via EDIUS-supported hardware, then it's whatever format you choose in the Input Settings - Uncompressed, Canopus Lossless, Canopus HQ, or Canopus DV.

1b. DV and native HDV captures are direct transfers (data copy, no recompression).

1c. No, though from the Bin you can "apply" an alpha or luma matte to a clip and generate a Canopus HQ clip with foreground or background and alpha channel.

1d. No, you need to use a timeline to do this.

1e. You can't really "export" directly from the Bin, aside from the matte function and conversion to Canopus HQ. Anything else requires putting the clip(s) on a timeline first.
The best choice of output format really depends on what your intended use for the clip is. There's no global answer aside from uncompressed YUYV.

1f. Correct, batch capture requires timecode and device control. In the case of capture through an ADVC500 or lower, you can't really control the deck, and you're getting free-run timecode, so batch capture won't work.
If your VHS deck had a RS-422 timecode output and you had an ADVC700 or ADVC3000, then you'd be able to batch capture from it.
But realistically, most people just capture the entire tape and then edit it down. It's less wear on the heads and tape that way.

2. EDIUS's native processing space is YCbCr 4:2:2 color sampling, 8-bit. Some processes like chroma key can temporarily use a larger space, but the "general" working space is YCbCr 4:2:2.
Any input that's greater than 8-bit precision will be downconverted to 8-bit precision during EDIUS's processing.
EDIUS will only capture 8-bit data, even with the EDIUS HD system which supports HD-SDI 10-bit I/O (because HD-SDI is so).

3. Okay, you got me on this one... I thought we had a nice list somewhere, but I can't find it offhand. Download the EDIUS manuals from the EDIUS Training site and there should be a list in there. Here's a brief summary from memory:
AC3, PCM WAV, DV AVI, DV stream, MPEG (MPEG-1, MPEG-2, System, Program, Transport streams), Uncompressed YUVY, Canopus HQ, Canopus Lossless, Canopus HD (DVCPRO HD)*, P2*, XDCAM*, QuickTime(?), Windows Media, and a bunch of other stuff through ProCoder Express for EDIUS**
* requires EDIUS Broadcast
** requires EDIUS Pro or EDIUS Broadcast (ie, not Neo)

3a. For DVD, you need to create DVD-compliant MPEG-2. There are three ways you can do that - EDIUS's native MPEG-2 exporter, the Speed Encoder, and through ProCoder Express for EDIUS.
As I understand it, both EDIUS's native MPEG exporter and ProCoder Express for EDIUS (PCE for EDIUS) use the same MPEG encoder algorithm.
The Speed Encoder theoretically cannot achieve the same quality level as the other two because of its grid nature, but whether or not you'll see a difference really depends on your target material and it's also way faster on multi-core systems.

[2Bdecided]

In answer to the original question, PAL DV is YV12 (YUV 4:2:0) colour space - but the sampling points for the chroma are different from DVD YV12 (YUV 4:2:0). In DV, the chroma samples are coincident with the luma samples; in MPEG, they're in between.

With that sorted, can I ask two even more difficult questions please?

1. Does the ADVC range use interlaced YV12, progressive YV12, or both?
2. Does the captured chroma meet Rec.601 coefficients, Rec.709 coefficient, or does it just match whatever I capture?

Question 1 is really important, because the chroma should be decoded to RGB (or even YUV 4:2:2) differently depending on which it is. YV12 chroma is bad enough without decoding it incorrectly.

(This doesn't apply to NTSC, where DV chroma is YUV 4:1:1 and all chroma values are co-sited with luma values vertically - so people in the USA and Japan don't have to worry about this, hence it's really difficult finding someone who can answer this question!).

Cheers,
David.

[Meow]

In answer to the original question, PAL DV is YV12 (YUV 4:2:0) colour space - but the sampling points for the chroma are different from DVD YV12 (YUV 4:2:0). In DV, the chroma samples are coincident with the luma samples; in MPEG, they're in between.

With that sorted, can I ask two even more difficult questions please?

1. Does the ADVC range use interlaced YV12, progressive YV12, or both?
2. Does the captured chroma meet Rec.601 coefficients, Rec.709 coefficient, or does it just match whatever I capture?

Which is exactly why I asked. So it's YCbCr. It's stunning that Canopus doesn't mention the exact specs anywhere.
I think it uses progressive YCbCr.

Is this the same David from the old r3mix forum? Boy were you behaving stupid back then.

[GrassValley_BH]

Adam Wilt's DV FAQ, Technical section has info on it.

The ADVC uses Consumer DV compression, which means Rec.601 space (709 is for HD).

You guys are confusing me because you're referencing the ADVC as if it's providing some kind of uncompressed video stream to the system. It provides a compressed DV stream.

[2Bdecided]

Thanks Brandon. I take it you mean the ADVC samples the chroma exactly as defined in the DV specs, i.e. U and V on alternate lines...

http://www.mir.com/DMG/chroma.html

...which is different from MPEG-2 interlaced and non-interlaced sampling, but should be handled correctly by any compliant DV codec.

Cheers,
David.

[GrassValley_BH]

Correct! :)