pantau:

David,

i've just checked the Avid Help again on HD Resolutions etc.; it says (as you also said as far as I remember) that 1080i/50 HDV is 1440 x 1080, as is DNxHD-TR 120.

1080i/50 is 1920 x 1080, as is DNxHD 185 and DNxHD 120

My question is: what do I really gain if I transcode HDV to DNX185 instead of DNxHD-TR 120, would that not mean that the 1440 pixels are simply interpolated to 1920, and therefore no real gain in quality??

What is the difference between DNxHD-TR 120 and DNxHD 120, apart from horizontal resolution?

And, as you were just talking about PCMCIA-Adapters for "serious" notebooks (I'm not saying mine is serious...), is a eSata-Adapter faster than a Firewire 800 one? In terms of throughput (185Mb/sec for DNX185 = 23MB/sec) I do not really understand the problem, even USB should be able to do this, no?

Cheers, maybe you should think of compiling a book out of your forum contributions...

Peter

Ahh... nothing like waking up at the crack of dawn.

Peter,

the 1080i HDV format is anamorphic; it records a frame size of 1440x1080. But if you think about it that is a 4:3 frame aspect ratio (AR). In order to obtain a full width 16:9 HD frame, the 1440 gets stretched via 1.33 pixel aspect ratio upon display. So 1080i HDV frames actually contain "thin people" unless viewed at the 16:9 1920x1080 frame size. In contrast, 720p HDV1, is full raster square pixel (not anamorphic) with 1280x720 16:9 frames.

The TR DNX codecs are intended for vertical editing in HDV2 sequences which create renders with a "thin raster" (hence, TR). This prevents graphics and text from being scaled (1920 to 1440) when rebuilding an HDV stream for output. Therefore, the TR codecs are not well suited for HD-SDI output which is better fed an HD signal at full raster. The standard (non TR) DNX codecs are full raster and are intended for video media and mastering applications.

When you transcode HDV2 (1440h pixels) to DNX (1920h pixels) the process "reshapes" the pixels from anamorphic 1.33 to square 1.0. The pixels are not "interpolated" per se. As far as the "quality gain", it has more to do with the kind of signal that DNX media contains. It's a bit like converting raw onions (HDV) into French onion soup (DNX); the latter tastes alot better.

Drives:

SATA is a direct serial interface with dedicated bandwidth for each "serial lane". Firewire and USB, while also serial digital interfaces, require additional bridging circuitry and arbitration. This is the reason that Avid doesn't allow any other devices on a firewire bus to which a Mojo is attached - they want the bus to be monopolized by Mojo for dedicated full bus bandwidth (and no arbitration).

Mojo aside, current SATA has a spec transfer rate of 300 MB/s while FW400 has 50 MB/s, FW800 has 100 MB/s and USB2 has 60 MB/s. In practice FW400 is often faster than USB2 (for unimportant reasons). FW800 implementations are not all equal and some are not up to snuff. In general, it performs better than FW400. On the other hand, SATA is the most common native hard drive interface presently. It provides the fastest transfer rate with the least arbitration compared to FW and USB. Further, external SATA is as easy and practical to use as USB or FW.

Your observation about USB bandwidth is fine but also ideal. Bench a USB2 drive and you'll see that you'll get varying figures between 30 and 45 MB/s. For just playing back a single stream of continuous DNX 185 it "sort of" works. But NLE's, call media from all over the hard drive in rapid succession and also often dissolve between one stream and another. Sometimes you're requesting 3, 4 or more concurrent streams. Issues like drive latency (response time) come into play in these scenarios. This should provide some insight into how quickly your USB bandwidth maxes out and the interface bogs down. This is why the AV application world is flooded with high performance disk arrays. Other threads discuss arrays in some detail with specific reference to eSATA.

A book... I'd have to get someone to organize my stream of consciousness. Maybe a hybrid book; post production stuff in the top half and cooking metaphores and recipies in the bottom. Maybe a little slither for the accompanying wine suggestion... just fooling around. Anyway, thanks for the compliment (I assume I'm to take it that way.)

David,

thanks for that heap of information, right after (new world) dawn...

doxilia:

When you transcode HDV2 (1440h pixels) to DNX (1920h pixels) the process "reshapes" the pixels from anamorphic 1.33 to square 1.0. The pixels are not "interpolated" per se. As far as the "quality gain", it has more to do with the kind of signal that DNX media contains. It's a bit like converting raw onions (HDV) into French onion soup (DNX); the latter tastes alot better.

I'm starting to catch up, but to be honest I don't really believe into "reshaped" pixels, at least not as much as in french onion soup. An uncoded HDV2 frame is 1440x1080, if I want to transcode it to DNX, I'll need 1920x1080, right? I do not see any other possibility to get there apart form interpolation. At the end, if we are talking about pixels, there is no anamorphic or square to me, just a pixel. Anamorphic or square is something which comes in at the display stage, squeezing the pixels (or not) on the monitor, TV-set etc., or am I wrong?

So in terms of information (real, not interpolated resolution) I would say it should be o.k. if I finish editing on TR DNX 120 on my laptop, and let the guys from TV then transcode this to whatever format they like, to put it out on digibeta?

doxilia:

Your observation about USB bandwidth is fine but also ideal. Bench a USB2 drive and you'll see that you'll get varying figures between 30 and 45 MB/s. For just playing back a single stream of continuous DNX 185 it "sort of" works. But NLE's, call media from all over the hard drive in rapid succession and also often dissolve between one stream and another. Sometimes you're requesting 3, 4 or more concurrent streams. Issues like drive latency (response time) come into play in these scenarios. This should provide some insight into how quickly your USB bandwidth maxes out and the interface bogs down. This is why the AV application world is flooded with high performance disk arrays. Other threads discuss arrays in some detail with specific reference to eSATA.

You're quite right on that, I've just benchmarked my drives (trying to become an expert too...), and found for my internal one a lousy average of 29MB/s (16ms access time), and my tiny little USB-drive 22MB/s (18ms access). Anyway, as there are no PCMCIA-cards which combine firewire (I need it to connect my camera) and eSata, I'll try the firewire 800 first. I guess there are drives which connect through firewire 800 and eSata, if I'll find out that the firewire 800 was not enough.

doxilia:

thanks for the compliment (I assume I'm to take it that way.)

Definitly a compliment,
cheers,

Peter

"Cheers, maybe you should think of compiling a book out of your forum contributions...

Peter"

 

 

This comes close...

http://www.avid.com/resources/whitepapers/hdworkflowWP3.pdf?featureID=886&marketID=

 

 

not the same as a real online expert, but thanks for the hint...

Just for the record about Mojo.

Mojo does not need the bandwith of firewire or the PCI-card (which is there Mojo put the requirement, I need its own PCI-bus segment).

The problem is this. If two PCI-cards share the same PCI-segment, they can not use it at the same time. If card one use it, it is not available for card two. You can think that the second card got a red trafic light.

Mojo need green light everytime, because a delay of 2ms will miss one field and the playback is worthless, especialy if You need to play back to tape.

(Credits for the trafic ligth example: Dom Q. Silverio).

berga:

Just for the record about Mojo.

Mojo does not need the bandwith of firewire or the PCI-card (which is there Mojo put the requirement, I need its own PCI-bus segment).

The problem is this. If two PCI-cards share the same PCI-segment, they can not use it at the same time. If card one use it, it is not available for card two. You can think that the second card got a red trafic light.

Mojo need green light everytime, because a delay of 2ms will miss one field and the playback is worthless, especialy if You need to play back to tape.

(Credits for the trafic ligth example: Dom Q. Silverio).

Anders,

Good clarification. I guess 1394a offers 400 Mb/s bandwidth while Mojo occupies ~ 250 Mb/s at most (for a 1:1 UC SD stream). Dom's red/green light metaphor is a good "arbitration" descriptor. I seem to recall seeing traffic light type animations (at some point in the distant past) to illustrate communications in electronics classes.

Ah, maybe it comes from DMV tests.

David.

pantau:

I'm starting to catch up, but to be honest I don't really believe into "reshaped" pixels, at least not as much as in french onion soup. An uncoded HDV2 frame is 1440x1080, if I want to transcode it to DNX, I'll need 1920x1080, right? I do not see any other possibility to get there apart form interpolation. At the end, if we are talking about pixels, there is no anamorphic or square to me, just a pixel. Anamorphic or square is something which comes in at the display stage, squeezing the pixels (or not) on the monitor, TV-set etc., or am I wrong?

So in terms of information (real, not interpolated resolution) I would say it should be o.k. if I finish editing on TR DNX 120 on my laptop, and let the guys from TV then transcode this to whatever format they like, to put it out on digibeta?

Peter

Hi Peter,

Work has kept me away from the forums lately.

You have a good point. Going from 1440 1.33 PAR to 1920 1.0 PAR is a form of interpolation. But it isn't a simple interpolation in the "linear best fit" sense. Unless someone is familar with Fourier transforms, on which much image compression is based, I tend to assume that people think of interpolation as a "bad thing". So when I talk of "reshaping pixels" in going from 1440 MPEG compression to 1920 DNX compression, there is a complex IDCT -> DCT process taking place. If this sounds like rubish, simply put, it is about expanding (decompressing) and truncating (compressing) polynomials in a function describing the content of a frame.

Note however that the pixels are indeed of a specific shape; either square or rectangular (haven't come across any donut shaped ones yet). Get close enough to a large screen SD TV and you'll see them; they are rectangular. On an HD LCD panel, on the other hand, they are square. With 40" + screens this is quite visible. These of course are the displays not the images but they are designed to "fit" the images intended for them.

In the end, your transcoding to DNX TR for laptop editing keeps things a little lighter than going with regular DNX; this helps. However, if the TV folks are transcoding your DNX TR to "whatever they like", your images will, in a sense, go through TWO codec cycles, rendering your programs third generation. If the TV station is mastering HDCAM or DigiBeta from your HDV footage and they are using Avid, there's a good chance that they wouldn't alter your footage codec further than your first DNX full raster pass. But there's always a chance that they may put it into another codec if they are just going out to DBeta.

BTW, had any French onion soup lately? Actually, current Montreal weather calls more for beer and calamari!

Well, I'm off to my local Avid retailer to see what Avid has come up with at NAB. Check out that new Mojo in person.

David.

doxilia:

In the end, your transcoding to DNX TR for laptop editing keeps things a little lighter than going with regular DNX; this helps. However, if the TV folks are transcoding your DNX TR to "whatever they like", your images will, in a sense, go through TWO codec cycles, rendering your programs third generation. If the TV station is mastering HDCAM or DigiBeta from your HDV footage and they are using Avid, there's a good chance that they wouldn't alter your footage codec further than your first DNX full raster pass. But there's always a chance that they may put it into another codec if they are just going out to DBeta.

Hi David,

thanks again, I surrender... I'll transcode it all to DNX185 and get a decent harddisk...

By the way, Berga in an other thread was explaining me why I should render DV50 instead of DV25; how would this be in the HD-world? What format should one render in a DNX185 project? 1:1? That would mean huge files...

cheers & have fun at NAB...

Peter

hi
this thread is so full of useful info, thx to you all!

I have a 90min Project shot entirely on HDV 1080i.
I have to deliver a SD-PAL for broadcast and a HD-QT for telecine.
The SD I plan to playout downconverted via Mojo on Digibeta- sounds easy so far!
To the telecine I plan to deliver as QT-files in DNxHD after having colour corrected on an MCA.
(its a lowbudget documentary- there is a small company here in Berlin, they scan directly from QTs and do the de-interlace before, how they do it is their secret, but they came up with amazing results for a test sequence I sent them (w/o CC)

Still -before I go on- I have two Columbo-like questions:

1.why would I go for DNxHD180 instead 120-its both not 10bit....
2.will my AVID SCSI LVD 320 drives have enough throughput unstriped? ( I just learned about the rather complicated way to migrate striped volumes)

thx for ur input
magus

pantau:

Hi David,

thanks again, I surrender... I'll transcode it all to DNX185 and get a decent harddisk...

By the way, Berga in an other thread was explaining me why I should render DV50 instead of DV25; how would this be in the HD-world? What format should one render in a DNX185 project? 1:1? That would mean huge files...

Hi Peter,

busy summer. Good choice on the 185. In the SD world, one often uses different codecs for video and graphics. In particular, one can use DV25, DV50 or 1:1 (UC). When footage has been acquired in DV25, it is often desireable to use 1:1, if you can, or DV50 for graphics. With v5.5, 1:1 is an option even without hardware assist but hard drive bandwidth is required for uncompressed SD. DV50 is a 4:2:2 codec and although it uses compression, graphics in DV50 are considerably better than DV25 which results in flickering whites in text (particularly in credit rolls).

In the HD world, the story is a little different. DNX is a codec that is designed for both video and graphics. In AXP, there is no option for 1:1 in HD and indeed that would create huge files. In fact, in the Avid framework, only Nitris solutions can produce and playback uncompressed HD. Use DNX 185 for all your transcoding, consolidating and rendering in AXP when working with 1080i/50.

Hope this helps, David.

Magus,

Your HDV 1080i/50 should playback out of a Mojo SDI just fine for DBeta mastering. However, if I were you, I would transcode the 90 min to DNX 185 prior to mastering.

For the telecine (I assume you mean that your HD files are going to be transferred to film), DNX QT files is a good choice. Telecine facilities often mount media (QT) files as DPX sequences for input into IT. So to answer your questions:

1) Use DNX 185 10 bit. The 10 bits are considerably more important than the 185 bit rate. When your 90 min HDV sequence is locked; transcode to DNX 185x (10 bit) on MCA. Although your acquisition source is HDV 25 8 bit, using the lowest compression and highest color space in producing DPX files will result in a better filmout.

2) No. DNX 185 is roughly equivalent to uncompressed SD in terms of bandwidth. Single drives can't deliver the necessary throughput for either of these, you need a 4 drive stripe array at a minimum for a working solution. This is rather inexpensive to do these days with SATA II drives and there are several post on the topic in this forum. I've commented on several of them including two posts raised to permanent status by moderators.

Cheers, David.

David,

all questions answered... thanks a lot & best whishes for the busy summer...

Peter

doxilia:

Mojo aside, current SATA has a spec transfer rate of 300 MB/s while FW400 has 50 MB/s, FW800 has 100 MB/s and USB2 has 60 MB/s. In practice FW400 is often faster than USB2 (for unimportant reasons). FW800 implementations are not all equal and some are not up to snuff. In general, it performs better than FW400. On the other hand, SATA is the most common native hard drive interface presently. It provides the fastest transfer rate with the least arbitration compared to FW and USB. Further, external SATA is as easy and practical to use as USB or FW.

btw David,

do you have an idea if eSATA drives work as well with PCMCIA eSATA-Cards? I'm thinking of buying Seagates external eSATA drive (http://www.seagate.com/products/retail/esata/), but it comes with a PCI-card, so I couldn't use it with my laptop. I haven't seen any e-SATA drives designed for laptops yet (there's one from teac, but it 2,5"").

cheers,
Peter

Peter,

there is nothing specific about externalizing SATA drives and using them with desktops. You can attach 1 drive or an array to a desktop via a PCI controller or do the same with a laptop and PC-card/ExpressCard controllers. Packaging a controller into PCI type (desktop) or PC card type (laptop) is not an issue. The performance that these devices will yield from your drive(s) depends on the interface and the host. For example, it would be expected that a PC-card interface on a laptop might not yield the same performance as the same controller interfaced via PCI-X 133; but the solution exists. If you want to use an eSATA drive/array with a laptop buy a controller such as either of the two in the links below (choice will depend on your laptop).

http://www.addonics.com/products/host_controller/adexc34-2e.asp

http://www.addonics.com/products/host_controller/adcbsar5-2e.asp

You can attach any single drive or up to 5 port multiplied drives to each port on these controllers.

David.