Cliff Etzel
June 28th, 2010, 11:15 AM
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 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.
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 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.