View Full Version : The 4 Second problem (HD100+FCP5.0.4)


Pages : 1 [2]

Alexei Kidel
January 14th, 2007, 05:22 PM
I don't know if you've already tried this, but capturing with DVHSCap and then converting the resultant .m2t files into AIC Quicktimes with MPEG Streamclip gives uniformly excellent results. AIC is supposed to be visually lossless and the advantage of capturing with DVHSCap is that you can capture every single frame that has been recorded on your tape. No losses. No gaps. It eliminates the "lottery".

It might be worth a try until Apple updates FCP to capture HDV 720p25 properly.

I've given the full detailed workflow for capturing and working in AIC with 720p25 in this post:

http://www.dvinfo.net/conf/showpost.php?p=598747&postcount=5


Thank you so much for posting this solution. I have just started a documentary production and opted to shoot on the JVC. Given that the subject matter is unpredictable, I cannot always allow for pre-roll. Your method using DVHSCap and MPEG Streamclip has worked flawlessly.

My only question at the moment is whether there is any reason for transcoding to AIC as opposed to something like DVC PRO HD? I don't really have a storage space issues to worry about. What is going to give me best results?

I have shot in 720 25p. If all goes well I will be editing on a G5 with FCP (version 5.1.2).

Alexei Kidel
January 14th, 2007, 05:25 PM
Hi David

Thanks for this, very helpful.

I have tried installing DVHSCap through the firewire sdk from apple, someone also sent me just the app by email. However, I can't seem to get it to work.

I double click on the emailed file, it enlarges like its going to launch but does not. I cannot find it from the sdk installation.

If you can point me in the right direction that would be good!

Thanks.

Trevor

Hi there. I clicked on the link in David's post and after registering (for free) I was able to download the Firewire SDK kit.

Here's the link:

http://developer.apple.com/sdk/#FireWireX

Hope this helps.

David Knaggs
January 15th, 2007, 02:19 AM
I double click on the emailed file, it enlarges like its going to launch but does not. I cannot find it from the sdk installation.

If you can point me in the right direction that would be good!

Hi Trevor.

I installed mine about 18 months ago, so these following steps are from (possibly foggy) recall, but hopefully they will help you get there:

1/ Go to the link http://developer.apple.com/sdk/#FireWireX
2/ Scroll down the page until you get to "FireWire SDK 20 for Mac OS X (DMG)".
3/ Download that.
4/ From memory, I might have double-clicked the downloaded icon on my desktop. I think it then installed itself in a folder called "Developer" which is found under "Macintosh HD". (Failing that, just do a search in the Finder for "DVHSCap" and it should locate the right folder for it.)
5/ Locate the icon "DVHSCap" and drag it into the Dock.

You should be set to go.

David Knaggs
January 15th, 2007, 03:42 AM
My only question at the moment is whether there is any reason for transcoding to AIC as opposed to something like DVC PRO HD? I don't really have a storage space issues to worry about. What is going to give me best results?

Hi Alexei.

When I first started using this camera (July 2005) I initially transcoded the .m2t files into DVCPRO HD Quicktimes and dragged them into an SD timeline (DVCPRO50 gave really good results with DVCPRO HD files).

I found DVCPRO HD to be an excellent codec.

However I changed to Apple Intermediate Codec (AIC) after Tim Dashwood posted his results from his tests into AIC (if you search this forum you will find them) about a year ago. Tim posted his results after Apple updated the AIC (codec). Apparently, the original AIC wasn't very good.

Points to note about AIC:

1. It is supposed to be visually lossless.
2. It gives best results with progressive footage (apparently there might be problems when using interlaced footage - 1080i) so it is perfect for the JVC GY-HD100 series of cameras.
3. It gives much smaller file sizes than DVCPRO HD (although that's not a concern in your case).
4. Most importantly, it allows you to work with the full 1280 X 720 pixels that your camera provides.

This last point is crucial for me. I am certainly not a codec expert (such as a Graeme Nattress or an Adam Wilt) but my understanding of DVCPRO HD is that it works with 960 X 720 pixels. This is perfect for the Panasonic cameras for which this codec was designed. I believe (feel free to correct me if I have incorrect data about this) that the Varicam sensor is 960 X 720 pixels. I imagine that the DVCPRO HD codec then "stretches" the 960 and makes it 1280 for editing.

And I remember reading that the HVX200 has a sensor size of 960 X 540. Perhaps the camera then uses pixel shifting or "spacial offset" technology to then record the image at 960 X 720 (same as the Varicam) which is then perfect for the DVCPRO HD codec.

In my opinion (and I stress that it is purely an opinion) DVCPRO HD gives excellent results with the JVC camera and is PERFECT for the 960-pixels-wide sensors of the Panasonic HD cameras. But AIC is a "better fit" for the JVC camera (GY-HD100 series) because it uses ALL of the pixels which the camera is recording. Why record 1280 pixels of width only to throw 320 of them away?

Looking at it in terms of total pixels:
Apple Intermediate Codec = 1280 X 720 = 921,600 pixels
DVCPRO HD codec = 960 X 720 = 691,200 pixels

So you are "throwing away" nearly a quarter of a million pixels (230,400 pixels, to be precise). This is a loss of 25% of your pixels.

That's why, as a JVC user, I now prefer AIC over DVCPRO HD. And, if I were using one of Panasonic's excellent range of HD cameras, I would exclusively work with DVCPRO HD. It's purely a matter of "horses for courses".

Mind you, this only applies when I'm transcoding. These days I prefer to work in native HDV 720p25 and export my DVD assets (my current 720p25 projects are for DVD) directly from the timeline using Compressor.

Trevor Allin
January 15th, 2007, 03:43 AM
Great thanks!

I have found dvhscap and have used it, it seemed to record fine. I then took it into streamclip and fixed the time code breaks (1). Only trouble is that now when I try and convert it to hdv25p apple, stream clip says "error can't find the first frame!'

If I didn't know that my mac and software were inanimate objects I would think this was personal!

Trevor

Drew Curran
January 15th, 2007, 04:07 AM
My only question at the moment is whether there is any reason for transcoding to AIC as opposed to something like DVC PRO HD? I don't really have a storage space issues to worry about. What is going to give me best results?



Alexei
DVCPRoHD reduces the size of your footage from 1280x720 to something like 990x720 (i forget the exact size). This is not noticable to everyone.

Andrew

edit: David beat me to it

Drew Curran
January 15th, 2007, 04:13 AM
Mind you, this only applies when I'm transcoding. These days I prefer to work in native HDV 720p25 and export my DVD assets (my current 720p25 projects are for DVD) directly from the timeline using Compressor.

What do you mean "this only applies when I'm transcoding"?

Do you find HDV easier to work with? I tend to find it very slow to render out to SD DVD.


Andrew

Sergio Barbosa
January 15th, 2007, 04:15 AM
Hi Trevor, that error in streamclip is nasty, I've had that happening to me once. Perhaps you started capturing too early on the tape, and at that point, the tape wasn't sufficiently stretched or so...
My advice #1 is not to convert it to Apple HDV25p, but to AIC instead, for the reasons David mentioned in the last post, and because the Apple HDV codec, in my opinion is not so good yet - eg. if you shot something with lots of motion, the hd100 might have actually recorded it just fine, but once you transcode it to the apple hdv codec, large compresion artifacts are going to start showing up...I've witnessed that. Of course, this even happens when you're editing nativeley on FCP, and, for instance, you apply color correction.
Advice #2 is: in streamclip, instead of selecting the entire clip to export, try to select for instance after the first 10 seconds until the end - you may have to search fot *that* portin of the footage that streamclip will let you convert... then rtecapture what's left.

I don't think it's personal, but it sure feels like it, somtimes!
Sergio.

Trevor Allin
January 15th, 2007, 04:21 AM
Hi

Ok, the googly has left the computer and I am now converting thefile in stream clip. I fixed the timed code before exporting but it still says that there are four data breaks.

Does this mean that there might be a camera problem as well as a capture problem?

Thanks

Trevor

David Knaggs
January 15th, 2007, 04:23 AM
Only trouble is that now when I try and convert it to hdv25p apple, stream clip says "error can't find the first frame!'

Hang in there, Trevor, you are almost there.

Perhaps you could try moving your "in" point on MPEG Streamclip and see if that makes a difference. Failing that, you could eliminate the in and out points and just transcode the entire clip.

Or you could use "Apple Intermediate Codec" rather than "Apple HDV 720p25".

Otherwise, just carefully re-check over each step I gave in the original workflow and verify that you have followed it correctly.

Good luck.

By the way, I don't recommend exporting from MPEG Streamclip by transcoding into HDV 720p25. Your image has already suffered degradation when the camera's encoder applied MPEG-2 as it recorded the tape. MPEG-2 is a very aggressive codec and putting it through a second bout of MPEG-2 compression when exporting from MPEG Streamclip (as Apple HDV 720p25) will introduce more artifacts and a general image degradation. It's better to use another codec when exporting from MPEG Streamclip such as AIC, Uncompressed, DVCPRO HD or even an SD codec (if your final output is going to be in SD).

David Knaggs
January 15th, 2007, 05:09 AM
What do you mean "this only applies when I'm transcoding"?
Do you find HDV easier to work with? I tend to find it very slow to render out to SD DVD.

Hi Andrew.

Gosh, this is getting to be a busy thread. There were 4 extra posts done during the time I was answering Trevor's post!

By "transcoding" I simply meant "capture as an .m2t file and transcode that into a Quicktime using MPEG Streamclip".

I prefer capturing natively (HDV 720p25) in FCP and then working in a native HDV 720p25 timeline. I then directly export the DVD assets (.m2v and .ac3 files) directly from the timeline using Compressor.

I prefer this method because it gives "theoretical best quality". I once covered the reasons for this at length in another thread, but my understanding of FCP is that it actually works with the timeline in 4:4:4 (Uncompressed) and only applies the render files permanently if you export as Quicktime.

Therefore if you capture natively through FCP (which does NOT transcode or degrade the image any further - it simply puts a Quicktime wrapper around it) and work in a native timeline (no further alteration and, internally, treated as 4:4:4) then the only compression your images have received is from the camera's MPEG-2 encoder when you originally recorded your tape.

So directly exporting from your timeline using Compressor then introduces the only other compression required for a DVD and here you have great control over the quality (you can bump up the bitrates and also alter the GOP structure, plus you can add Compression Markers in your original FCP timeline at points where there is a lot of motion).

Then just import the already-encoded assets into DVD Studio Pro.

The Compressor export does take a bit of time, but this method really does give the best quality (in my personal experience).

I don't recommend exporting your timeline sequence as a Quicktime and then importing into Compressor (because it introduces an extra step of compression when making the Quicktime).

The very fastest method I know of to make an SD DVD is to export an AIC Quicktime and encode it in iDVD. It's really fast encoding! (But not the best quality.)

Drew Curran
January 15th, 2007, 05:39 AM
I prefer capturing natively (HDV 720p25) in FCP and then working in a native HDV 720p25 timeline. I then directly export the DVD assets (.m2v and .ac3 files) directly from the timeline using Compressor.



Thanks David

I used this process also until i was hit by the timnecode break issue in FCP during a long edit (2.5hrs of captured material). When I played the clips back there was breaks all over the place, and important bits missing. I used DVHSCap and got around these problems. Until then I was producing only 5 to 10 minute promotional movies, so the FCP timecode thing didn't seem to affect me.

How do u avoid the TC problem?

With HDV I noticed fairly slow render times when exporting using compressor to SD DVD's. I also noticed that I had fewer realtime effects during editing on the timeline using native HDV.

I was lead to an article stating that HDV is processor intensive, which advised using AIC or DVCPROHD instead. I've now reverted to using DVHScap and Streamclip, and have noticed vastly improved rendering and RT effects in FCP. I also avoid the TC break issues during capturing.


Andrew

Trevor Allin
January 15th, 2007, 06:09 AM
Hi david

Thanks for this. I will try exporting it as AIC. The only difficulty I have for this particulr project is that I have 19 tapes (3 camera shoot) and I have captured 17 of them as 720p already.
On the next project I will definately use AIC instead.

This current export ended up with 12 data breaks! I am wondering though if the tape is struggling because I have played it so often trying to capture it. I am hoping this might be the cause of the problem rather than a camera fault.

Trevor

Trevor Allin
January 15th, 2007, 07:10 AM
Update

I spoke to JVC here in the UK and they have said that I have to send the camera into them and they have an upgrade that will 'fix' the problem.

I think it is as I suspected, both an FCP problem and, in my case, a camera problem.

Trevor

Jonathan Nelson
January 15th, 2007, 02:01 PM
Update

I spoke to JVC here in the UK and they have said that I have to send the camera into them and they have an upgrade that will 'fix' the problem.

I think it is as I suspected, both an FCP problem and, in my case, a camera problem.

Trevor

Well if you have a camera problem, then I also have a camera problem because my hd100 does the same exact thing. It has been the story of my life.

I wonder if this update really does fix the problem. I woulnt mind sending mine in to get an update if one is available in usa.

David Knaggs
January 15th, 2007, 02:07 PM
How do u avoid the TC problem?

The only workable method I know of for this (with HDV 720p25 footage) is to set the TC GEN switch to REC before recording the tapes. It somehow makes it easier for FCP to capture a full clip (rather than arbitrarily break it into 2 or 3 smaller clips with 7-second gaps). I cover this fully under the heading "SECOND WORKAROUND" in this post:

http://www.dvinfo.net/conf/showpost.php?p=598747&postcount=5

But working in AIC and exporting via Compressor into SD DVD assets has given me terrific results in the past so I fully understand your sticking to that workflow (DVHSCap-MPEG Streamclip) and we can only hope that Apple updates FCP to fix these capturing problems soon.

Alexei Kidel
January 15th, 2007, 03:57 PM
Hi Alexei.
....snip....


Dear David,

I can't thank you enough for helping me out. I have just shelled out a fair whack on all this new gear and was dreading spending late nights fighting with the computer. The transcoding to DVCPRO HD gave me some problems, but the AIC solution seems to working a treat. I will be converting all my rushes this way and after making a backup of all of them, hopefully, FCP will be very happy with them.

Once again, many thanks!

Trevor Allin
January 15th, 2007, 05:11 PM
Hi Jonathan

When I phoned JVC the tech guy got me to hold in the focus assist on the side of the camera and also the status button at the same time. This brought up version information that told the tech guy that my camera needed the upgrade.

May be if you get that info and phone JVC they will be able to do something. Over here in the UK it is a free upgrade so I suspect it would be there too.

I think the tech guys optimism about 'fixing' the problem is abit OTT, though I hope I am wrong. From all these threads and experience there seems definatley to be an FCP problem as well.

I love my HD101 but boy has it been a whole lot of time and trouble.

Trevor

Alex Bowles
February 25th, 2007, 12:29 PM
Hi all,

When I first called JVC about this problem, hey told me I wouldn't be able to get a clean import unless I was using the HD-110, or the HD-100 with the 'A' firmware upgrade and FCP 5.1.

I've gotten this done (firmware upgrade was already done.) Short story is, no joy. I read another post that says 5.1.3 offers hope, but again, JVC said this was supposed to be fixed in 5.1...

The story I'm getting now is that there must be something wrong with my camera in particular, and that I should send it in for repairs.

Two things seem dubious here; (1) judging from this length of this string, I'm hardly alone. (2) They've made no guarantees that the repairs, which I'll need to pay for, will actually work, as the root issue seems to be on the Mac side (details below.)

Instead, I'm simply moving away from the camera. But here are some bits of information I picked up that may be useful to folks still working with it.

1. Incompatibility with Apple

The problem seems to be Mac only. JVC says that has to do with the 'very literal' way OSX deals with incoming transport streams. I wasn't sure what this meant, but apparently it's more stringent than I/O for Win-Tel systems. In other words, the root of the problem is a Mac-specific architecture issue over which JVC has no real control.

Folks using this camera with Premier, Vegas etc. have confirmed that Win-Tel systems don't run into this issue.

JVC did not try to explain why other equipment makers were able to negotiate both Mac and Win-Tel I/O successfully.

2. Video Flags

Apparently, JVC attempted to remedy the situation with improvements to the way the transport streams are flagged by the encoder (i.e. in-camera.)

These were incorporated in the 'A' firmware upgrade. Accordingly (and this is per JVC) tapes recorded on a pre-upgrade HD-100 will still demonstrate the problem, even if the capture deck has been upgraded, and the user is running 5.1. In my experience they both fail, but this the JVC line.

3. Uncompressed Output

None of this has any bearing if you're using the uncompressed component out, and using FCP to manage direct-to-disk capture.

Right now, the camera is doing good service as a signal generator as I get the bugs worked out of a RAID-based DDR solution. But unless I divest myself from FCP (unlikely) I'm unable to rely on it for work that's done on tape.

Hope this helps.

Brandon Lindauer
April 19th, 2007, 05:49 PM
Just an update to this quite annoying issue...

I just spent several days at NAB and was able to talk to an Apple guy at the JVC booth, we talked about the problem then he reffered me to one of the actual FCP engineers down at the Apple booth.

Seems that basically the HD100 sends its stream in a "different" way than most firewire cameras. The engineer made reference to a bandwidth issue. And since HDV has a very low bitrate this confused me and he started speaking techno mumbo jumbo.

Anyway, he also said that because the JVC sends information in the way that it does, FCP is not able to "reliably" recieve the information. Apparently there are apple engineers working as liasons to JVC, attempting to solve this problem.
Yes they are aware of the Problem.
No its not fixed in FCP 6.
Yes it is on the list, but as the gentleman said... "its a V E R Y long list!"

Just thought you all might want to know.

What really got me was the exhibit at the JVC booth with the Apple guy demoing how great FCP and the JVC gear work seamlessly together, knowing full well that this problem exists. Eh, go figure.

Alexei Kidel
April 19th, 2007, 06:10 PM
Thank you very much for updating on this issue.

What a pain, I really had hopes for FCP6. Oh well, back to continuing with the workaround.

I'm almost finished a documentary using the workaround and it's not been the best solution to be transcoding to AIC, but I have to say it's worked on the whole. The one thing that really annoyed us was the default audio setting on MPEGstreamclip. All of our audio was boosted by 6db.

Apart from this the camera has been a treat to work with. When the scene is well lit the picture is a joy.

Robert Castiglione
April 19th, 2007, 06:15 PM
I think that there are serious issues in not openly disclosing the difficulties with capture. There are of course many people who do not read boards like this. A bit of corporate honesty would be desirable.

Rob