Creative Communities of the World Forums

The peer to peer support community for media production professionals.

Activity Forums AJA Video Systems Working on a DSR-11 SDI solution

  • Working on a DSR-11 SDI solution

    Posted by Michael on June 10, 2005 at 3:10 am

    This isn’t a post with a question, it’s informational on an solution I’ve been testing… thought you guys might be interested…

    Short of buying a DV deck with an SDI output, a pricey endeavor, I’ve been looking for a solution for FCP to keep me from re-configuring the entire system just to bring something in over firewire. I normally work in Beta SP via component capture on the Io. As you know, the AJA box really doesn’t like any other firewire devices plugged into its bus. So I’ve been playing with a device called the SD-Connect from Convergent Design. Hook the DSR-11 into the SD-Connect, hook the SD-Connect up to the AJA box, and the SD-Connect will convert the 1394 signal into SDI and embed the audio into the SDI stream on the fly. Sounds great but I haven’t worked out the deck control in FCP yet. I have been able to get the SD-Connect to read time code off of the DSR-11, though.

    The other reason to do this is you get to capture DV in 10-bit uncompressed. AJA’s 10-bit uncompressed codec is way WAY cleaner than the DV codec. DV footage captured on my DVX-100a looks extraordinary when encoded in the 10-bit codec.

    If I get it all working, I’ll have an uncompressed SDI solution for my DSR-11 for about $1400 bucks. Not bad! I’m not trying to sell SD-Connect boxes or anything. The interface on the box is horrible, and setup has taken me weeks just to get this far. But I’ll post more about this as the project advances.

    cheers,
    -mjd

    Steve Covello replied 20 years, 10 months ago 4 Members · 8 Replies
  • 8 Replies
  • Steve Covello

    June 10, 2005 at 1:47 pm

    Interesting solution. How ’bout this: if you have a FW800 media drive, try connecting it to your mac via 800 cable, and the IO via the 400 connection. They are two different channels as far as the mac is concerned. Jack the DSR-11 to the 400 port on the back of the 800 drive. See if it works. I have the same equpiment and will try it out myself. [I’m sure someone will chime in saying it won’t work…]. If you only have 400 drives, forget it. Go 800 next time. Worth it.

    About DV footage in 10-bit: DV is a native 8-bit format and is recorded on tape as a 4:1:1 sample. D-1 601 SDI 10-bit is 4:2:2. Your setup — going from FW to 10-bit SDI — is somewhat the same as going from vhs to D-Beta. You gain nothing in the process. Secondly, from what I have read in various posts here that taking DV out of its native 8-bit 4:1:1 state introduces luminance shifts and chroma shifts which changes [for better or worse] what you originally acquired. A strong case for going 10-bit might be if you were planning on doing multiple effect passes. The proof, for you, is invariably the end result. If you’re happy with it, all is well.

    One other thing you will be sacrificing is drive space. 1hour of DV versus 1 hour of 10bit SDI uncompressed is a HUGE difference in media space. A FW transfer from a DV tape to a DV editing system is a transparent transfer, meaning there is no change in the data or picture/sound in the process. So it’s a trade-off one way or the other IMO.

    steve covello
    double wide post

  • Michael

    June 10, 2005 at 8:56 pm

    >Your setup — going from FW to 10-bit SDI — is somewhat the same as going from vhs to D-Beta. >You gain nothing in the process.

    Ah.. but you do! Follow me here. When you capture in FCP via 1394, the raw data gets sent over FireWire, and gets put in a QuickTime wrapper using Apple’s DV codec. Apple’s DV codec is dirty! The edges in footage captured using the DV codec have a lot of crap along them. This is not the fault of DV as a format, it’s not a function of 8-bit or 10-bit, it’s just that the Apple DV codec sucks. By bypassing the DV codec, and recording in uncompressed, there’s a lot (and I mean A LOT) of gunk that gets omitted from the image. I have personally done a test of this. Under controlled circumstances I captured the exact same footage, one in DV via 1394 encoded in the DV codec, one off of a DV deck output SDI and encoded 10-bit uncompressed. The 10-bit uncompressed was clean enough to pull a good chroma key. Try this with DV encoded material. It doesn’t work. Blowing up the image in AE nets a very telling inclusion of artifacts in the DV material. My friends and colleagues traced through every part of the system looking for where the DV was getting degraded. It’s the codec! Try this for yourself, you will be amazed by how much crap the DV codec introduces.

  • Steve Covello

    June 11, 2005 at 3:35 am

    Dude, it ain’t the codec. It’s the way you are manipulating it after you digitize.

    DV video recorded via FW is a data transfer and the codec process is absolutely not involved. The Apple QT is merely a wrapper. Secondly, when you capture in a non-native codec such as SDI 4:2:2 10-bit via Sony, the DV data on tape gets encoded from 4:1:1 to 4:2:2, and 8-bit gets re-quantized to 10-bit (the only system that allows the Sony SDI 4:2:2 codec to be read as a pure data transfer from tape is the Sony Vegas. Sony does not share their codec with FCP like Panasonic does). This is an impure process, though the results could still be fine looking. It’s just not what is actually on tape — see below (goto ‘which codec is better’):

    https://www.adamwilt.com/DV-FAQ-editing.html#codecs

    See test #2 comparison and conclusion at bottom:

    https://www.nattress.com/Chroma_Investigation/chromasampling.htm

    Again, the proof is in the results as you see it. However, everything I have read on this issue points to two conclusions, AFAIC: 1) the difference appears to be inconsequential enough unless you are doing multi-generational graphix, 2) the disk drive space trade-off is generally not worth the expenditure.

    It could be (though unlikely) that you have a lousy FW cable that could be introducing artifacts, or that the DV transfer is actually showing you MORE than the SDI transfer, which accounts for the extra crap you see. Although I have never bought it, I have read that there are special 4:1:1 8-bit DV specific chroma key plugins that supposedly do a darn good job, for DV. Maybe the ‘stock’ keyer just isn’t cutting it? Found this a moment ago:

    https://www.dvgarage.com/prod/prod.php?prod=dvmattefcp

    steve covello
    double wide post

  • Michael

    June 11, 2005 at 8:45 am

    You just helped me solve the damn explaination! It IS the codec! Just not the way I explained it. I’ve been here before at this crossroad, and you just tipped me to what’s happening. When the footage is blown up, it needed to be rendered to play. When the export to AE happens, it needs to be rendered, too. FCP doesn’t pass an exported clip along native, unless you simply open the raw file in AE. Apple does re-compress when it renders, and that’s where the artifacts are introduced. Which actually does make the codec the source of the gunk in the image.

    I first saw this test done at a Final Cut Pro user’s meeting in L.A. At the time, the ProMax tech threw out the theory that allowing more head room by up-rezing to SDI and 10-bit was the reason the footage was cleaner. I grilled him on it during the meeting because his explaination wasn’t logical. How can you add information to an image? I went through the same arguments you were giving me, then started testing and re-testing for months. But no one could or can dispute the results, it was shown on a 100 foot projector in front of us all, there simply wasn’t a question, the uncompressed capture was cleaner. I was so interested that I went home and repicated the test to the same results. I got my friends involved and the only logical explaination we came up with is the codec. Based on what we discussed, we were right! Just wrong in the application of our thinking!

    But I’m back at the same place as far as working in uncompressed though. Any time you add a filter, you’re going to render in the artifacts that are avoided by working in 10-bit.

    As far as drive space, it costs nothing these days. The cost of a good RAID stripe is pennies per gig. Well worth the gain, to me anyway.

    Great discussion!

    -mjd

  • Richard Dee

    June 14, 2005 at 6:52 pm

    I have been wrestling with this same issue for many years, looking for an alterantive to a DSR- series deck with SDI out.

    I too have captured DV material (greenscreen) via DV and SDI and when blowing up the edges in the viewer in FCP or AE you could see stair steps on the DV, and much finer steps on the SDI captures.

    The keying was also better on the SDI material in an umcpmtressed AE sequence.

    ADS makes this brand new API-560 for $900 or less. I am just about to order one and start experimenting. It embeds audio and deck control.

    The other option I read about also does HDV to DHSDI- that is a killer solution- but won’t be won’t be out for a few months, and was $2500 retail.

  • Michael

    June 16, 2005 at 5:32 am

    As we figured out, it’s not that the capture is cleaner, it’s that when you render your green screen that the jaggies start appearing. It’s the render in the crappy codec that causes this, not the DV itself. You’re right though, looking at the end results, the differences are staggering in uncompressed, you’d hardly know you were working with a DV source.

    -mjd

  • Dom Silverio

    June 16, 2005 at 1:58 pm

    [weevie833] “try connecting it to your mac via 800 cable, and the IO via the 400 connection. They are two different channels as far as the mac is concerned.”

    Will not work because they use the same PCI bus.

  • Steve Covello

    June 26, 2005 at 6:14 pm

    Surprise! It does work. SD 8-bit UC.

    steve covello
    double wide post

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy