Pro video blog…Produced by Philip Johnston DoP/Editor

Multicam HM100

I put my hand up and admit I was wrong, the MPEG 2 file that comes from the JVC HM100 does indeed work with multicam…on the timeline…1920 x 1080 50i…2 cameras…no rendering ! The down side to this is if you add even a one second crossfade to the video track you will be waiting 2 minutes for each ONE second to render !Multicam HM100 timeline

As you can see from my test there is not even a green line let alone a red line above the timeline. As a further test I tried 4 HD camera angles but that was asking a but much from the system and it stuttered.

This was edited on FInal Cut Pro 6, ingested from the SDHC card inserted into a n SD card reader and plays back from the card itself.

I had to test this for Terry who was going to suggest the JVC HM100s and FCP as a multicam workflow for a colleague.

Remember if you bring the SDHC file in via the card reader it will bring it in as separate files unless you filmed one continues take as you would if you are going to use it with multicam.

author

Having been working in the video business since 1988 I have amassed a great amount of knowledge of both the kit and production values over the last 30 years.

7 thoughts on “Multicam works with JVC HM100 MPEG 2 file using FCP-6

  1. Your initial thoughts on this camera pretty much put me off buying it. The big attraction was a drag and drop workflow. I would have worn the cameras faults with the inclusion of that huge plus. This whole codec thing is getting out of hand.
    I am wondering if things like iframe will clear the waters , or just add to the murk.
    Jack Atley

  2. Thanks for testing this! I’ve just done a quick a test myself with two separate pieces of footage from an EX-1 (so identical properties to the HM100). They were both full res 1080P25. I simply blobbed two of them together into a multicam clip and threw it on the timeline.

    On a 24″ white iMac (couple of generations old) I get green render bars but the footage still plays back smoothly. Same thing for both an XDCam timeline and ProRes. I then tested the 3-Way color corrector and colorista. 3 Way still gave me green render lines, but colorista forced it into orange. When I did execute a render, it seemed to take longer on the ProRes timeline than the XDCAM.

    And it’s still fairly smooth playback when the timeline is open ganged with the viewer window.

    I tried a cross-fade, about 5 secs for a 25f crossfade. My results seem better – maybe because I’m using progressive material instead of interlaced?

    Now going to try 3 cam multiclip!!

    Terry

  3. Dear Terry,
    I have now tested both EX-3 and HM100 material in FCP-7 straight off the card into FCP. The EX-3 was 720p 50 and the HM100 was 1920 x 1080 50i. Both sat on the timeline without any green lines using Mulitcam. I don’t think you should run 3 streams of HD into Multicam as you may find the SATA drives wont be able to sustain the data rate.

  4. Dear Jack,
    iFrame will indeed add to the murk for a start it’s 960 x 540 30fps so as you can see right away it’s a non standard HD codec. This is what Devin Coldewey from the Washington Post had to say about iFrame…

    Devin Coldewey
    TechCrunch.com
    Wednesday, October 14, 2009; 3:34 PM
    Yesterday, word got out of Apple’s new iFrame standard, which purports to expedite video editing by keeping the video in “the same format used on a computer.” Really, it’s nothing but a resolution and wrapper. So why am I losing my mind over it? Because the way iFrame is being positioned and propagated is misleading and harmful to consumers. Oh I know, what an alarmist, right? It’s just a video format! But with personal video becoming more and more ubiquitous and invading class after class of gadgets, these former trivialities are becoming more important by the day.And for once, we are actually gravitating towards a couple unified standards in both encoding and resolution ¿ and then Apple butts in with this ugly stepchild of a format.

  5. I think maybe we’re trying to do different things. Even with a 3 clip multiclip, only 1 clip is active at any point in time so I don’t think the load on a machine is that much bigger. The original challenge was to film a 5 minute event with 3-4 cameras, syncing them up by manually finding a common in-point (i.e. clapperboard), and creating a multiclip, not a multiclip sequence.

    If you’ve got 3 XDCAM video track running on top each other I can see you’re gonna have problems, although disk access shouldn’t be an issue as it still only tops out at 105 Mbps which is about the same as a single ProRes stream? The load on the processor might be a different story.

    Sorry I didn’t mean to confuse things with my accidental capitalising of the ‘F’ in iFrame. I meant a generic i-frame codec, not Apple’s new and very bizarre non-HD ‘HD codec’.

    Cheers

Leave a Reply

Your email address will not be published. Required fields are marked *