Canon 5D2 support? at DVinfo.net

Mark Hahn · January 18th, 2009, 02:14 AM

I downloaded the Neo HD trial and converted a standard 5D2 .mov file using HDlink, which is the program flow I expect to use.

The video result was awesome, played in my players, and edits great in Premiere CS3. The audio was a different story. Every clip I converted had a few seconds of buzzing and then silence.

Is this something in my system or do the 5D2 files not work yet?

If you want to see an example, download one of LaForet's raw files, like MVI_0492.MOV. If you want me to make it available for download myself, let me know.

David Newman · January 18th, 2009, 10:42 AM

Official support is coming in version 4 or NEO, we fortunate that the base tools in v3.x already work pretty well the the video conversion. Audio was another matter. Many pro users are not using the audio at all, as it is not high quality, but we do intend to support it. We currently don't have a easy work around for the audio.

Jay Bloomfield · January 18th, 2009, 06:14 PM

A temporary workaround is to convert the file with NEO HD, as you did, which gives you the video. Then download the freeware MPEG StreamClip:

Squared 5 - MPEG Streamclip video converter for Windows XP/Vista

1. Use MPEG StreamClip to export the audio only (MP4 AAC will do) to a file.

2. Then use your NLE to recombine the Cineform video track and the "good" audio track and re-render it as a new Cineform file. Make sure you delete the original "bad" audio track that you get from the Cineform conversion, before re-rendering.

3. The problem with splitting the audio and video is that you can end up with two files that are slightly different lengths on the timeline and the audio will be out of sync, without some further tinkering.

This workflow gets you Cineform video with computer RGB color (0-255) and the audio. Of course, if you don't care about the color issue, you can just use MPEG Streamclip and render as Cineform, but you do need NEO HD installed to do so.

Craig Davidson · January 18th, 2009, 09:46 PM

Quote:

Originally Posted by David Newman

Official support is coming in version 4 or NEO, we fortunate that the base tools in v3.x already work pretty well the the video conversion. Audio was another matter. Many pro users are not using the audio at all, as it is not high quality, but we do intend to support it. We currently don't have a easy work around for the audio.

David, there is a simple work-around - ReMaster.. ;-)

Jay Bloomfield · January 20th, 2009, 06:08 PM

The more a looked at that workflow, the more I realized that for most NLEs, the MPEG_Streamclip step is extraneous. Just open the Cineform AVI (CFHD video with "bad" audio) and then open the original MOV file from the 5D MKII( h.264 video with "good" audio). Then just turn off the "bad" audio track and the h.264 video track.

David Newman · January 20th, 2009, 06:23 PM

Quote:

Originally Posted by Jay Bloomfield

The more a looked at that workflow, the more I realized that for most NLEs, the MPEG_Streamclip step is extraneous. Just open the Cineform AVI (CFHD video with "bad" audio) and then open the original MOV file from the 5D MKII( h.264 video with "good" audio). Then just turn off the "bad" audio track and the h.264 video track.

Yes I was thinking of suggesting that. We will get the audio correct in NEO HD v4.

Jay Bloomfield · January 20th, 2009, 10:10 PM

@David,

I read over the most recent entry in your blog and I you're the first person that has posted a logical explanation of the 5D MKII is really doing with regard to the "super" ends of the histogram.

One thing that I wasn't completely clear about, is whether you are sure that the MOV files are really 16-235? I'm reading (probably incorrectly) that what you said as the MOV file itself is 16-235 and color space conversions by NLEs are even reducing this further (~30-220). Other people have looked at the blog and concluded that the MOV files are 0-255, but are being misinterpreted as 16-235 by all decoders and then further altered by NLEs (through color space conversion) to ~ 30-220:

http://prolost.blogspot.com/

Daniel Browning · January 21st, 2009, 12:41 AM

Quote:

Originally Posted by David Newman

We currently don't have a easy work around for the audio.

I created a simple perl script that does the following:

Examine all MOV files in the current directory.
Create one AVS file for each MOV
Each AVI file just contains DirectShowSource()
CoreAVC decodes video and audio correctly
Add the AVS to Virtualdub batch
Virtualdub encodes to Cineform (I'm using Canopus codec)
When all the files are done, execute the batch

The full dynamic range is preserved, audio works, but Virtualdub is kinda slow.

Taroen Pasman · January 21st, 2009, 08:12 AM

Quote:

Originally Posted by Daniel Browning

I created a simple perl script that does the following:

...
Examine all MOV files in the current directory.
Create one AVS file for each MOV
Each AVI file just contains DirectShowSource()
...

Sorry for the dumb question, I'm a total noob...
I've been working with the Neo HD trial in combination with CoreAVC but I keep ending up with clipped output (especially crushed blacks).
When I re-wrap with QuickTimePro (to mp4) I keep the detail in the dark area's but the editing in Vegas is then terribly slow. I can't process the resulting mp4 files in Neo (timecode error)...

Could you explain how to execute these 3 steps?
2: How do I create an AVS file?
3: How can I check if only the directshowsource is within the avi file?

*edit*
It seems I've solved the problem by deïnstalling Quick-Time. I've tried to change the merit of the directshow filter but that didn't work. After deïnstalling QuickTime CoreAVC CineForm + CoreAVC render the correct colours it seems...

David Newman · January 21st, 2009, 09:57 AM

Taroen, try the latest NEO HD, with the last version some system weren't using CoreAVC even though it was installed.

David Newman · January 21st, 2009, 10:18 AM

Quote:

Originally Posted by Jay Bloomfield

@David,

I read over the most recent entry in your blog and I you're the first person that has posted a logical explanation of the 5D MKII is really doing with regard to the "super" ends of the histogram.

One thing that I wasn't completely clear about, is whether you are sure that the MOV files are really 16-235? I'm reading (probably incorrectly) that what you said as the MOV file itself is 16-235 and color space conversions by NLEs are even reducing this further (~30-220). Other people have looked at the blog and concluded that the MOV files are 0-255, but are being misinterpreted as 16-235 by all decoders and then further altered by NLEs (through color space conversion) to ~ 30-220:

ProLost

I have an even clearer picture off what is happening since that blog post. All the discussions of 16-235 vs 0-255, are thinking Studio RGB to Computer systems RGB when the fault is occurring in the YUV space before any RGB transform -- set the RGB mode will not fix the truncation as YUV to RGB math typically assumes YUV data has display black at 16. However most AVC decoders are reacting to a wrong flag in the bit-stream and are stretching the standard 16-235 YUV data out to 0-255 (you can see the gap in the decoded RGB parade, showing the range has been stretched), place the YUV display black 0. I believe CoreAVC is simply ignoring this "stretch the range" flag.

Jay Bloomfield · January 22nd, 2009, 11:46 AM

Everyone is claiming that the QT 7.6 update has fixed this issue with the 5D MKII, so all this may be moot.

As to your explanation, I agree that just because people have documented histograms below 16 and above 235, doesn't necessarily mean that those histograms are faithfully translated through every step in the workflow from camera to NLE. Incorrect mapping could give you a similar result.

David Newman · January 22nd, 2009, 11:57 AM

Yes. I believe the 5D is marked as full range, and now the QT update it acknowledging that.

Jay Bloomfield · January 22nd, 2009, 06:40 PM

A couple more minor items. If you are using CoreAVC decoder in conjunction with Cineform to do the conversions, make sure that the CoreAVC decoder is set to "PC (0-255)" for both Input levels and Output levels and not "Auto Detect". Also, an examination of the waveforms comparing both the original MOV file and the converted Cineform file, using both Vegas 8.0c & Premiere CS3, both show both sources now (after installation of QT 7.6) at cRGB levels, but the waveforms are not quite the same. I guess that this is to be expected.

David Newman · January 22nd, 2009, 06:47 PM

I'll have to update my blog -- good find.

January 18th, 2009, 02:14 AM	#1
Mark Hahn Major Player Join Date: Dec 2008 Location: Laguna Niguel, CA Posts: 277	Canon 5D2 support? I downloaded the Neo HD trial and converted a standard 5D2 .mov file using HDlink, which is the program flow I expect to use. The video result was awesome, played in my players, and edits great in Premiere CS3. The audio was a different story. Every clip I converted had a few seconds of buzzing and then silence. Is this something in my system or do the 5D2 files not work yet? If you want to see an example, download one of LaForet's raw files, like MVI_0492.MOV. If you want me to make it available for download myself, let me know.

January 18th, 2009, 10:42 AM	#2
David Newman CTO, CineForm Inc. Join Date: Jul 2003 Location: Cardiff-by-the-Sea, California Posts: 8,095	Official support is coming in version 4 or NEO, we fortunate that the base tools in v3.x already work pretty well the the video conversion. Audio was another matter. Many pro users are not using the audio at all, as it is not high quality, but we do intend to support it. We currently don't have a easy work around for the audio. __________________ David Newman -- web: www.gopro.com blog: cineform.blogspot.com -- twitter: twitter.com/David_Newman

January 21st, 2009, 09:57 AM	#10
David Newman CTO, CineForm Inc. Join Date: Jul 2003 Location: Cardiff-by-the-Sea, California Posts: 8,095	Taroen, try the latest NEO HD, with the last version some system weren't using CoreAVC even though it was installed. __________________ David Newman -- web: www.gopro.com blog: cineform.blogspot.com -- twitter: twitter.com/David_Newman

January 22nd, 2009, 11:57 AM	#13
David Newman CTO, CineForm Inc. Join Date: Jul 2003 Location: Cardiff-by-the-Sea, California Posts: 8,095	Yes. I believe the 5D is marked as full range, and now the QT update it acknowledging that. __________________ David Newman -- web: www.gopro.com blog: cineform.blogspot.com -- twitter: twitter.com/David_Newman

January 22nd, 2009, 06:47 PM	#15
David Newman CTO, CineForm Inc. Join Date: Jul 2003 Location: Cardiff-by-the-Sea, California Posts: 8,095	I'll have to update my blog -- good find. __________________ David Newman -- web: www.gopro.com blog: cineform.blogspot.com -- twitter: twitter.com/David_Newman

January 18th, 2009, 06:14 PM	#3
Jay Bloomfield Major Player Join Date: Feb 2008 Location: Voorheesville, NY Posts: 433	A temporary workaround is to convert the file with NEO HD, as you did, which gives you the video. Then download the freeware MPEG StreamClip: Squared 5 - MPEG Streamclip video converter for Windows XP/Vista 1. Use MPEG StreamClip to export the audio only (MP4 AAC will do) to a file. 2. Then use your NLE to recombine the Cineform video track and the "good" audio track and re-render it as a new Cineform file. Make sure you delete the original "bad" audio track that you get from the Cineform conversion, before re-rendering. 3. The problem with splitting the audio and video is that you can end up with two files that are slightly different lengths on the timeline and the audio will be out of sync, without some further tinkering. This workflow gets you Cineform video with computer RGB color (0-255) and the audio. Of course, if you don't care about the color issue, you can just use MPEG Streamclip and render as Cineform, but you do need NEO HD installed to do so.

January 20th, 2009, 06:08 PM	#5
Jay Bloomfield Major Player Join Date: Feb 2008 Location: Voorheesville, NY Posts: 433	The more a looked at that workflow, the more I realized that for most NLEs, the MPEG_Streamclip step is extraneous. Just open the Cineform AVI (CFHD video with "bad" audio) and then open the original MOV file from the 5D MKII( h.264 video with "good" audio). Then just turn off the "bad" audio track and the h.264 video track.

January 20th, 2009, 10:10 PM	#7
Jay Bloomfield Major Player Join Date: Feb 2008 Location: Voorheesville, NY Posts: 433	@David, I read over the most recent entry in your blog and I you're the first person that has posted a logical explanation of the 5D MKII is really doing with regard to the "super" ends of the histogram. One thing that I wasn't completely clear about, is whether you are sure that the MOV files are really 16-235? I'm reading (probably incorrectly) that what you said as the MOV file itself is 16-235 and color space conversions by NLEs are even reducing this further (~30-220). Other people have looked at the blog and concluded that the MOV files are 0-255, but are being misinterpreted as 16-235 by all decoders and then further altered by NLEs (through color space conversion) to ~ 30-220: http://prolost.blogspot.com/

January 22nd, 2009, 11:46 AM	#12
Jay Bloomfield Major Player Join Date: Feb 2008 Location: Voorheesville, NY Posts: 433	Everyone is claiming that the QT 7.6 update has fixed this issue with the 5D MKII, so all this may be moot. As to your explanation, I agree that just because people have documented histograms below 16 and above 235, doesn't necessarily mean that those histograms are faithfully translated through every step in the workflow from camera to NLE. Incorrect mapping could give you a similar result.

January 22nd, 2009, 06:40 PM	#14
Jay Bloomfield Major Player Join Date: Feb 2008 Location: Voorheesville, NY Posts: 433	A couple more minor items. If you are using CoreAVC decoder in conjunction with Cineform to do the conversions, make sure that the CoreAVC decoder is set to "PC (0-255)" for both Input levels and Output levels and not "Auto Detect". Also, an examination of the waveforms comparing both the original MOV file and the converted Cineform file, using both Vegas 8.0c & Premiere CS3, both show both sources now (after installation of QT 7.6) at cRGB levels, but the waveforms are not quite the same. I guess that this is to be expected.