-
Bizarre pixelization on output
I’m pretty convinced this is an issue with my Digital Betacam deck, but thought I’d present this here just in case someone has had similar experience. I’m outputting through SDI to D-Beta from BM 10-bit uncompressed NTSC files through BlackMagic Deck Control and Decklink Extreme. The files were generated in FCP following capture though Extreme’s SDI input. Speed is not a probelm: system is a G5 2.7/3.5gb ram and two G-Tech 500gb G-Raids striped as raids and fed through a FW800 card and the system’s FW800 port.
On layback to D-Beta I’m getting occasional, sporadic pixelization. This doesn’t show up until I play back; as the deck is recording, I see nothing but pristine imagery. (The stock is fine – I’ve tested several batches.) What’s more, this isn’t repeatable – this pixelization (looking very much like longer-duration “digital hits”) never pops up in the same place. Within these sections, there are often issues with fast pans, fast movement and cut points. There appears to be some kind of big, chunky breakup at the field level, particularly on higher-contrast imagery. Very bizarre, as the original captures are fine.
I’m sending the deck back to the rental facility later this morning but because I’m not very experienced with the Extreme, I’d appreciate feedback if anyone here believes this issue resides more with the system and/or my workflow rather than the deck.
Thanks in advance!
-
10 Replies
-
Hi,
It does sound more like a deck issue. However if you could post a frame grab showing an example of the problem, we might be able to get a better idea of the cause of the problem.
Regards,
Luke Maslen
Blackmagic Design -
I’ve got a frame for you, Luke. New to this forum – how do I post it? Or should I just email it directly to you?
-
Luke,
It is NOT a Deck issue. We swapped out our D-Beta deck for another, exact same model. Same issue.
I then sent a 2-minute test (which I’d attempted to output here with dodgy results) in Apple’s uncompressed 10-bit format to an outside facility running an older G5, FCP 4.5, and AJA box (not sure which) and a SCSI array. This test was successfully laid back to D-Beta (using one of my two weekend rental decks) no less than 5 or 6 times. Stock was the exact item I’d been attempting these outputs with all weekend.
I’m now forced to suspect the problem resides either with my 2 FW800 G-RAIDs or the Decklink Extreme card. Tomorrow I will take the drives to this outside facility and attempt to output my entire 3 hour show (in two 90 minute sections) on their system. Whatever the result, I should be able to decisively identify the culprit then.
Will keep you updated. In the meantime, how can I get that single-frame capture sample to you? What’s your email?
Thanks.
-
Hi,
Thanks. You can post it here by placing it on your web server and then providing a link in the following format:
Alternatively you can email it to support@ blackmagic-design.com (without the anti-spam space).
Regards,
Luke Maslen
Blackmagic Design -
why not output directly from FCP? that is a rock solid workflow. The deck Deck control utility should be as well, but I think there is probably way more user experience outputting directly from FCP…
The drives are also a possibility, but you would see the glitches during output (at least from FCP). your setup is way fast enough, but firewire 800 raid systems do slow down quite a bit as they get full! -
Hi,
Thanks for the frame grab which was very helpful. Grant wandered by my computer just as I opened up your file and he immediately said, “That’s odd. They are DCT blocks. There’s a problem at the deck.” He explained to me that DCP blocks are compression blocks. When you shuttle quickly on the Digibeta, you see a pixelated display made up of many blocks. Those blocks are DCT blocks resulting from compression on the tape. When you shuttle quickly, not all the information can be decompressed fast enough so you see blocks instead. So why are you seeing DCT compression errors?
Grant mentioned there were a few causes that he has seen.
- Reference problems could cause this and so you should check your source of genlock if you are using genlock. Make sure the genlock is in the right format and that the Digibeta is set to use external reference. If you are using the DeckLink card to output a sync signal to the deck, please see the support note How to sync a deck with a DeckLink card to ensure all is configured correctly. You would need to set the deck to use Internal or Auto reference with this arrangement.
- The heads of the deck could be dirty or malfunctioning. However you have tried a second deck so this is unlikely.
- The tape could have a problem and this is quite likely. You could try a new tape and see if the problem goes away. Alternatively you could recreate the tape and see if the problem goes away. You could take the same tape to another Digibeta and see if the problem still occurs when you play back the tape locally, ie with no involvement from a DeckLink card.
- Sometimes the timecode track on the tape could be a problem. Using Assemble Edit, instead of Insert Edit, might overcome this probem.
- There can also be some other rare and weird scenarios, eg audio in the wrong format causing such errors when recorded to tape. You might find that no audio appears to have been recorded when you play back the tape but that DCT blocks appear. This would be an indication of an audio problem but this one is not as common.
I hope this helps to track down the problem. My guess is that it is something to do with your tape and that using a fresh tape will overcome the problem.
Regards,
Luke Maslen
Blackmagic Design -
Hi Paul,
While there is no harm in trying FCP over Blackmagic Deck Control, I don’t think that is where the problem lies as the original post stated: [smoked meat] “as the deck is recording, I see nothing but pristine imagery”
I think the problem is at the deck and, most probably, is with the tape but I have also mentioned some other possibilities in another post here.
Regards,
Luke Maslen
Blackmagic Design -
Hey Luke!
well, as he has swapped decks and also swapped tapes many times, it must be something else right? how about a bad cable or connection. from my experience this is always the last thing anyone checks (and the solution is alway the last thing you check right!)
or maybe reference? is the deck set to external sync or sync on input – yet another fly in the ointment…
but if he is monitoring the deck and all looks good until playback. hmmm.
there is a setting switch on the digibeta to monitor what is recording on the head as opposed to the input (I forget what it’s called – Zelin where are you?)
but I feel for the guy. edit to tape problems are always the most infuriating! -
Hey Paul,
Thanks for your suggestions and, maybe I’ve missed a reference somewhere, but I couldn’t find any mention of swapping tapes. He’s definitely swapped decks so that rules out some potential sources of problems but I can’t find a mention of swapping tapes.
It’s definitely a problem at the deck because it is the deck that generates the DCT blocks. DeckLink cards don’t create or use DCT blocks. However the display of random DCT blocks can just be a configuration thing with the tape’s timecode, deck or reference signal so it will be interesting to hear what he finds with a fresh tape and after checking the reference signal.
Regards,
Luke Maslen
Blackmagic Design -
(The stock is fine – I’ve tested several batches.) from his 1st post.
I thought this meant he tried different tape stock? maybe not.
Reply to this Discussion! Login or Sign Up