Actually, Intensity is capturing the HDV footage using up greater disk space with no better quality. If this workflow is one you desire than great, but don't try to tell us that HDV footage looks better captured from the intensity card than firewire because it doesn't. At best, it looks the same. Captured HDV footage can be up-rezzed through output. It is silly, in my opinion, to recompress it during capture.

For live, then I agree; it is currently the best solution for full HD from the V1. But for tape, you're best just capturing the footage through firewire or importing/transfering the files off of the Sony hard drive if you have that option.

I uprezzed to 1920x1080 (from 1440 HDV) using CF, and side-by-side it looks much better than the original HDV. To make it harder, I was doing some very red direct sunset, with dark foreground and clear skies. Huge gradient range. In the CS3 beta, the uprezed, 10-bit Prospect output, even from the HDV, is very nice indeed, and from an editors viewpoint, it blows the original out of the water.

If uprezed compressed video looks better using CF, you can be sure that capturing directly from the HDMI port via Intensity and CF, will be SPECTACULAR in comparison. No way it couldn't. Not to mention being upped to 10-bit for much smoother color gradients. You can't get that without the uprez and 10-bit conversion. CF really is good.

Well it all kind of comes down to the decoder.

With a camera there is a decoder chip designed for high quality decodes of the mpeg2 stream. That stream is decoded and upconverted and sent out the HDMI port to a new format of your choice.

Most NLE systems on the other hand depend on software decoders to decode the mpeg2 file which it puts in a decompressed buffer. Some NLE's work with this decompressed RGB buffer.

HD mpeg2 can suffer from bad encoders and decoders just like DVD's can. In the world of mpeg2 no two encoders and decoders are exactly alike. With DV the format was pretty standard so it was safe to say that across the board DV was DV. Mpeg2 is very complex and sometimes some realtime software decoders may not do the best to reduce the macro blocks and recreate the RGB image.

The HDMI port may also do a better job at upconverting the signal because it wants to send the highest quality decoded RGB image to a HDTV.


In a lot of ways it follows one of the same arguments from Cineform which is that by capturing to their format the quality will hold up better. By using Cineform you are pretty much doing the same thing as HDMI expect Cineform uses it's own high quality decoder and saves the decoded results via firewire into their format. This has been known to sometimes give a little bit higher of quality because the mpeg2 is already decoded with the highest level of quality and put into a format that will hold up better to editing. It does this so the NLE doesn't have to use it's decoder which may or may not be the greatest.

I cannot confirm this for sure yet or not but the HDMI port may also be upconverting the chroma. Cineform already does it by interpolating the chroma and turning it into 4:2:2. Of course this isn't as good as raw 4:2:2 color but it helps a little. HDMI may also upconvert the signal to 4:2:2 to try to send the highest signal it can to a HDTV. So by capturing a HDV tape via HDMI it may tryt to at least smooth out the chroam so the edges are not jagged. Again I have not been able to confirm this. I do however know that this always helped me a lot with DV footage. I used to capture DV tapes of bluescreen footage via component to uncompressed and while there may not been any extra chroma detail the chroma was smoothed out so there were no jagged edges. This pretty much had the same effect as blurring the chroma channels in a NLE but then I didn't have to wait for it to render.

John B.,

Converting HDV to 4:2:2 is a good thing, trust me. Besides, it's pixel-shifting 960x1080 to 1440, then you output and it pixel-shifts again to 1920 on those displays. And it's clean. I like working with captured footage at 1920 and it apparently looks great!

heath

I have some clips captured from tape via HDMI and Firewire but I don’t know where or how to post it. Today I captured a clip uncompressed and rolled tape at the same time. So I can show you the same clip captured uncompressed and HDV.

Can you upload it to an FTP? I might be able to put it on my .mac.

heath

A one minute and thirty-nine second uncompressed clip is eleven point six gigs. So far all the send it sites max out at two gigs. I will have to cut it down.

Ron,

Yowza! How about making it a 10 second clip?

Thanks,

heath

I have some clips captured from tape via HDMI and Firewire but I don’t know where or how to post it. Today I captured a clip uncompressed and rolled tape at the same time. So I can show you the same clip captured uncompressed and HDV.

Ron, are you compressing using BM's compression or not at all? I believe their codec has been compared to CF's and the latter came up much better in tests.

By the space you mentioned you used for capture, you'd easily save a bundle on RAID HDDs and then storage space by capturing via the HDMI port and using CF to very lightly compress those giant files! It seems from Cineform's own testing and that of others, you'd be hard pressed to see much of a difference in the quality of the final output, but would definitely be smiling at the amount you saved by using a premiere compression algorithm (even at a measly $500)!

Sorry it took so long to get back internet connection down.

Yes I am using the BM’s compression codec. It looks good to me but I am not always the best judge. I would like you guys to take a look. I just have to find a way to get it to you. Maybe I should start with some pics.

Converting HDV to 4:2:2 is a good thing, trust me. Besides, it's pixel-shifting 960x1080 to 1440, then you output and it pixel-shifts again to 1920 on those displays.

heath

1) HDV is automatically converted to 4:4:4 inside your NLE so, if you are simply editing HDV, there is no advantage to decoding it before a frame is needed. (In fact, it's a waste of storage space and increases disk bandwidth requirements.)

If you are editing in FCP, or any Avid product, there is no advantage to not using native HDV editing.

2) The V1 doesn't use "pixel shifting" -- if it did H. rez. would be increased by only about 115%. Both H and V interpolation is used, which increases both H and V significantly -- to about 775-lines for each.

Since you have, at most, 800 pixels of H information it is a waste of storage space, disk bandwidth, and CPU computer power to "handle" 2X that number. A 1440x1080 path is more than enough rez.

(Remember, the V1 the CMOS chips are not "over-sampling" the HDV format the way HDCAM CCDS over-sample HDCAM. In fact, strictly speaking, they under-sample the HDV format.)

3) At the point where an anmorphic format (non-square pixels) is "converted" to 1920 (square pixels), "pixel-shifting" is not used. Simple scaling is used to "spread" the 1440 pixels over 1920 pixels.

The goal is to record the image before compression!

HOWEVER, it's not that simple. The CFHD codec itself is not the only thing CineForm has going. When Connect HD gets HDV via FW and is decoded -- and then converted to 4:2:2 -- really good upconversion math is used. So BEFORE the decoded image is compressed to CFHD, it is "enhanced" by the software in Connect HD. This is why CFHD may look better than letting FCP do the decoding.

Plus, you get the option of 2-3 pull-down removal. So although Aspect HD costs more than Intensity, it does more and it works on a laptop.

John B.,

Converting HDV to 4:2:2 is a good thing, trust me. Besides, it's pixel-shifting 960x1080 to 1440, then you output and it pixel-shifts again to 1920 on those displays. And it's clean. I like working with captured footage at 1920 and it apparently looks great!

heath

Heath, the camera doesn't pixel shift; it acquires pixels at 960 x 1080 on the sensor block and interpolates, stores them at 1440 x 1080 on tape, and then displays them at 1920 by 1080 at a PAR of 1.333.
However, you're right; acquiring at 4:2:2 short GOP or no GOP vs acquiring at 4:2:0 long GOP provides for a better editing experience in almost all situations. In fact, even though it's 8 bit data, capturing at 10 bit and editing at 10 bit provides a much better and malleable image. This is why many pro's capture with an AJA, Bluefish, or BMD card instead of using firewire. Additionally, you avoid the software decode of the .m2t on your computer, which has an impact on the quality of your image.
You might recall the 4:2:2 Sheer video images compared to the Firewire images we had on the HDV tour. The 4:2:2 ingest is significantly more robust when pushed than is the 4:2:0 image.
Another way of looking at it is that *every* NLE developer has an intermediary codec available for HDV content. Some won't allow editing of HDV without the intermediary. There is a reason they spent the time/money to develop the intermediary.
It's a better output and editing experience.

Yeah I read that it just scans twice and literally puts the image together which makes a 1920X1080 image with 4:2:2 color space before any kind of compression. That HDMI port is looking nice.

Sorry but I can't see the advantage of capture HDV via anything apart from firewire, other than speed.
The HDV capture gets you a bit image of what's on the tape, from there on you can convert that to anything / apply chroma tweaking etc without the need for large, fast RAID drives.
On top of that the mpeg-2 has to be decoded somewhere, either by a VCRs hardware or in the PC's software, one is forced to do it in realtime, the later has all the time it needs to do the best possible job.
I'm not questioning the value of using a DI, just how you get from HDV to the DI. Sure decoding the HDV in a VCR's hardware to 10 bit 4:2:2 and feeding that down HD-SDI is going to give you a faster workflow than capturing native HDV and convertering to 10bit 4:2:2 in software but doing it in software would be a heck of a lot cheaper and could yield even better results.

Firewire is definitely cheaper, and arguably easier. If you have a DR60 or similar, it's significantly faster, too.
However, capturing via an AJA Xena, there is some chroma smoothing that takes place, which is entirely subjective, of course, but I prefer it.
For full-length and/or dramatic projects (yeah, only done a couple with the V1) it's a sweet look.
If it's just a fast capture, edit, spit it out, we use the Firewire and/or DR60 to transfer the footage. The content we're spitting out to cable providers such as ESPN etc are all just firewire captures, printed to either HDCAM or on data DVD as one of several file formats.

he content we're spitting out to cable providers such as ESPN etc are all just firewire captures, printed to either HDCAM or on data DVD as one of several file formats.
Spot, are you using an intermediary codec like Cineform or edting staight captured HDV on the timeline? And also, are you using Vegas, FCP or both.

I am looking to make the switch to FCS2 from Vegas, as I just received a new 2.66 Quad core MACPRO. And I was wondering about capture and conversion in FCP in regards to HDV video. And if I would need a intermedairy codec or can edit straight HDV footae on teh FCP timeline. Of course this will be the new FC Studio 2 verison which isn't released yet.

And just so you know, I will be running Bootcamp and Vegas/SF9 on Win XP.

Spot,

Thanks for correcting me! I need to brush up on the still-new ClearVid technology.

heath

"mpeg-2 has to be decoded somewhere"

Bob's 100% correct which is why the post-HDV compressed capture path is very different than the pre-HDV compressed path.

Once you get Bob's point, the issues become two-fold: WHEN and HOW.

WHEN:

1) In camera
2) During capture to intermediate
3) During editing

The earlier you do it -- the bigger the source files and the greater the disk bandwidth load on the computer.

But what about 10-bits? Totally irrelevant with FCP. If you want to work with 10-bits -- use FCP 10-bit mode. The video information is neither enhanced or preserved while waiting to be used, if its stored as 10-bits.

But what about 4:2:2? Again totally irrelevant with FCP. FCP always decodes to 4:4:4 internally. Once again, video information is neither enhanced or preserved while waiting to be used, if its stored as 4:2:2.

But, what about the "difficulty" of editing long GOP video? This is a trade-off: yes more CPU cycles must be used to decode on the fly. But, on a laptop, CPU cycles are very available. What's not available is the much greater storage required AND the need to move this rapidly. That's why CineForm warns that unless you want to be disk-bound, you need a RAID.

But what about the re-compressing FX to HDV. This myth has no basis. MC and Xpress Pro both force all renders to DNxHD. FCP never re-uses renders for the final output. Color has an option to render to ProRes rather than HDV.

HOW: this is the real issue. How good is the decode, the upsampling to 4:2:2 or 4:4:4, and the conversion to 10-bits if wanted. And, do some methods tweek the chroma better. If i had raised this issue, it would be called "measurbating" because we have no real way to measure the claims. :)

However, interlaced MPEG-2 does have inherent chroma issues that can be solved various ways. So, it's possible for different decoders to output video that looks different.

Bob assumes that software may do it better than software. But, Apple has long been known to do a bad job -- at least for AIC. CineForm has long been known for doing a very good job. Avid, may or may not do a good job. I'll bet they do a good job.

So there MAY be a "quality" advantage to using something other than native HDV, but it's not for the reasons usually posted.

If you edit long form with MC and Xpress Pro, there is a huge reason to stay native. Both MC 2.7 and Xpress Pro 5.7 support Smart GOP Splicing. No need to wait for conforming before exporting HDV. And, since the BD and HD DVD creation software imports HDV and places it -- without recompression -- on optical disc, it means you have a very fast way of distributing HD versions of your project during production.

Bottom-line, all the measurable issues favor native HDV editing. Others can measurebate on the "quality" issues they see.