OT: Cineform HDLink dropping frames on conversion

Cliff Etzel wrote on 6/27/2010, 10:34 PM
There's a serious issue that I"ve run into with Cineforms HDLink utility.

It's become apparent that this has been around since the previous iterations of Neoscene I was working with, but didn't realize til this weekend of the severity of the issue. The utility appears to be causing frame drift/dropping frames during the encode. I have tested and confirmed that it is the utility itself as I was able to drop an m2t file on the Vegas timeline and render out a perfect length CF AVI. I also confirmed that Canopus as well as an issue with their encoder, but not as severe. I rendered an AVID DNxHD clip via MPEG Stream Clip and found it to be flawless in it's encode. Same number of frames as the original and exact same length of time.

As of this time, I can't trust using Cineform's HDLink utility as it stands now - the picture below shows the discrepancy compared to the original and the same clip encoded to AVID's DNxHD. I have opened a tech support ticket with Cineform and hope to hear back from them as soon as possible to resolve this unsettling issue (I was going to use Cineform for a current post production project I have - I now have to consider AVID's DNxHD). I'm hoping this issue can be resolved quickly so I can go back to using NeoScene for DI's.




For those using HDLink - please be aware of this bug especially if working with originals and CF AVI's and using timecode. You will find your time codes do not match.

Cliff Etzel
Solo Video Journalist | Micro Documentary Film Maker
bluprojekt | SoloVJ Blog
--------
Desktop: OS: Win7 x64 | CPU: Q9400 | Mobo: Intel DG33TL | 8GB G.Skill Dual Channel RAM | Boot/Apps Drive: Seagate 160GB 7200RPM | Audio Drive: Seagate 160GB 7200RPM | Video Source: WD Black 2x750GB RAID 0 | Video Card: nVidia GeForce GT 220 1GB

Laptop: Dell Latitude D620 | C2D 2.0Ghz | 4GB G.Skill RAM | OS: Vista x64 | Primary HD: WD 320GB 7200RPM | Video HD: WD 250GB 5400RPM

Comments

farss wrote on 6/28/2010, 1:26 AM
" You will find your time codes do not match. "

They should, that's the whole idea of using timecode. I think the real issue you're facing is that Vegas uses time into file and not source timecode.
Another problem that I've struck over the years is that anything rendered out of Vegas always has the TC set to start at 0:00:00:00 so there's no way to preserve your source TC in DIs or proxies.
There's sort of ways around this assuming that you always work only from captured files and always make the proxies or DIs absolutely identical to the original files.

Bob.
Cliff Etzel wrote on 6/28/2010, 8:14 AM
This isn't a Vegas issue - it's Cineform issue - I also brought the clips into Edius and the same results occurred, so this isn't about doing a workaround in Vegas. Brought into the trial of AVID Media Composer - again, frame counts are different - check with G-Spot - confirms this as well.

Just now, I created a 10 second clip by using the media generator in Vegas Pro. 10 second credit roll - rendered as an m2t, had HDlink encode the file as a CF AVI - placed both on the timeline - 6 frames are missing from the CF AVI for that 10 sec clip - that is a problem IMO

The very fact that frames are being dropped is indicative of a larger issue. How is it a free utility like MPEG Streamclip and AVID's DNxHD can encode a perfect match length wise and number of frames, where as a product that I paid good money (Total $180 - Neo scene plus recent upgrade to latest version) produces a show stopper for professional post production.

That is unacceptable.

Cliff Etzel
Solo Video Journalist | Micro Documentary Film Maker
bluprojekt | SoloVJ Blog
--------
Desktop: OS: Win7 x64 | CPU: Q9400 | Mobo: Intel DG33TL | 8GB G.Skill Dual Channel RAM | Boot/Apps Drive: Seagate 160GB 7200RPM | Audio Drive: Seagate 160GB 7200RPM | Video Source: WD Black 2x750GB RAID 0 | Video Card: nVidia GeForce GT 220 1GB

Laptop: Dell Latitude D620 | C2D 2.0Ghz | 4GB G.Skill RAM | OS: Vista x64 | Primary HD: WD 320GB 7200RPM | Video HD: WD 250GB 5400RPM
Cliff Etzel wrote on 6/28/2010, 9:58 AM
I have confirmed that there is a synch issue with HDLink. I have reproduced the issue several times today.

In Vegas Pro, I have generated a 60 second color NTSC bars with both BITC and absolute frame count. I then added a 1 sec 18db tone beginning at 0 and then at 10 second intervals. I then rendered that as a 1440x1080i m2t file. Used the HDLink utility to convert the m2t to CF AVI - brought both the m2t and CF AVI onto a 1440x1080i timeline in Vegas Pro 9 64 bit. There are 6 frames missing at the end of the CF AVI clip. The audio is also out of synch and the CF AVI has the 0 point audio blip missing. so there's 2 synch problems Cineform needs to address

Since the audio and video are out of synch, this precludes Cineform from any post work for me until they resolve the issue.

I've also read of others who others on the dvinfo forums who have experienced the same issue so mine is not an isolated instance.

AVID's DNxHD DI's encoded through MPEG Stream Clip is recommended until CIneform fixes this issue.


Cliff Etzel
Solo Video Journalist | Micro Documentary Film Maker
bluprojekt | SoloVJ Blog
--------
Desktop: OS: Win7 x64 | CPU: Q9400 | Mobo: Intel DG33TL | 8GB G.Skill Dual Channel RAM | Boot/Apps Drive: Seagate 160GB 7200RPM | Audio Drive: Seagate 160GB 7200RPM | Video Source: WD Black 2x750GB RAID 0 | Video Card: nVidia GeForce GT 220 1GB

Laptop: Dell Latitude D620 | C2D 2.0Ghz | 4GB G.Skill RAM | OS: Vista x64 | Primary HD: WD 320GB 7200RPM | Video HD: WD 250GB 5400RPM
kkolbo wrote on 6/28/2010, 11:30 AM

I have also confirmed your results with HDLink although I am not getting as many dropped frames. Clearly a major problem. I have also sent an email to Cineform Tech Support.

Sounds like you like the AVID CODEC. If you still want to use Cineform then using the free script Proxy Stream you can use Vegas Pro to do the conversion instead of HDLink. It isn't quite as fast a HDLink but close. 11 minute clip, HDLink 3:48, Proxy Stream/Vegas 4:26. The nice part is you get all of the frames :-)

David Newman wrote on 6/28/2010, 1:16 PM
Work with support, it is not general issue. HDLink does not loose sync with camera sources. While it does not seem to like the M2T outputs from Vegas, I have confirmed this, that is not the workflow which HDLink was designed. I have retested with camera sources and video and audio are in sync. Nor have anything changed in a long time in HDV conversions.

David Newman
CTO, CineForm

P.S. Keith, thank you for your polite communication with support.

P.P.S Cliff learn from Keith, no reason to raise hell on multiple web site, give us a chance to help you.
farss wrote on 6/28/2010, 1:36 PM
"This isn't a Vegas issue - it's Cineform issue - I also brought the clips into Edius and the same results occurred, so this isn't about doing a workaround in Vegas. Brought into the trial of AVID Media Composer - again, frame counts are different - check with G-Spot - confirms this as well."

I never said this was a Vegas issue. What I said was frame count should not matter, loosing a couple of frames off the head or tail will not mean you cannot do a match back to source timecode. If you think it does matter then you have not grasped this kind of workflow.

Bob.

kkolbo wrote on 6/28/2010, 1:43 PM
David,

The format that has been an issue is actually .h264. The camera footage that I have been using to test and get odd results from are from the Go Hero Pro HD camera. On clips longer than 7 minutes, it truncates the audio long before the end of the clip. On the shorter clips is where I found the strange behavior of the Cineform file being a few frames shorter than the original. The audio was in sync with the picture, but somewhere along the way frames were dropped making it all shorter.

Would sending you some files help? Jake can contact me at anytime.

BTW, I understand that making anything work with the myriad or variants of .h264 is probably not practical, especially for a camera in this low price category, but if you want to play with it, I will help anyway I can. (Trip to California?) :-)
Cliff Etzel wrote on 6/28/2010, 1:45 PM
David - I apologize for coming off harsh - it wasn't directed at you personally.

It's extremely frustrating to have this kind of thing arise when I have over 300GB of M2Ts staring at me and a looming deadline with a commissioned documentary project I am about to start editing.

I haven't heard anything from tech support and given that combination of things, it can come across as such.

Please accept my apologies if you were personally offended.

Cliff Etzel
Solo Video Journalist | Micro Documentary Film Maker
bluprojekt | SoloVJ Blog
--------
Desktop: OS: Win7 x64 | CPU: Q9400 | Mobo: Intel DG33TL | 8GB G.Skill Dual Channel RAM | Boot/Apps Drive: Seagate 160GB 7200RPM | Audio Drive: Seagate 160GB 7200RPM | Video Source: WD Black 2x750GB RAID 0 | Video Card: nVidia GeForce GT 220 1GB

Laptop: Dell Latitude D620 | C2D 2.0Ghz | 4GB G.Skill RAM | OS: Vista x64 | Primary HD: WD 320GB 7200RPM | Video HD: WD 250GB 5400RPM
PerroneFord wrote on 6/28/2010, 1:58 PM
Bob,

If he's got dialog at the front of a clip and the beginning of it is cut off in the transcode that is most certainly an issue. But this is a bit more tricky than that.

I've examined the output from this oddity and it's somewhat insidious.

The Video portion is being truncated at the end of the file. However the audio is being time shifted forward. Such that if you match the original and the converted clips up at the head, the converted is shorter and the audio is truncated at the front by a different amount than the video, knocking them out of sync. If you were trying to do a match back after cutting a proxy, neither the audio or the video would lock back up. That's huge.
farss wrote on 6/28/2010, 3:14 PM
" If you were trying to do a match back after cutting a proxy, neither the audio or the video would lock back up. That's huge. "

Agreed and I'm not dissmissing this as a serious issue however even without that issue, even with frame accurate proxies if you are not preserving source timecode then you have a fundamental problem and any other problem is purely secondary.

My current project has everyone working from what are in effect proxies. They're DVCAM dubs from HDCAM. DV dubs would be useless as generally DV dubs do not preserve TC. Images look and sound the same on DV and DVCAM, if you don't understand the finer points of the difference between DV and DVCAM tapes in this workflow you can be in for a nasty shock right at the end of the process. This is the kind of thing I'm trying to alert Cliff to.

Bob.