Jump to content

Which Quicktime Movies does Logic like best?


Dick the Flick

Recommended Posts

Hi all

 

I usually run an external Mac with its own software to run Quicktime Movies (Virtual VTR with a Canopus Box on a MacBook) ...... I fire MTC & MMC at the Mac and Virtual VTR acts like a slave. My reason for this is that I like to keep the CPU use on my main DAW down to a minimum as I tend to pound every ounce out of Logic and assume running movies inside the program does add unnecessary number crunching.

 

However, I have recently also been running the QT Movies in Logic as it is quite handy to use while working out principle timing .... positioning bars on action etc. ..... then as the mix builds I move back to using QT's externally.

 

My question is that whilst I'm working in Logic, I'd like to use a low memory QT codec that doesn't hammer the CPU and whilst the obvious thing to use might seem an iPod movie - I quickly realised that the H264 codec actually loads the CPU considerably worse than any other codec-!!

 

What does anyone recommend?

 

Using Quicktime Pro ...... it takes a short time to convert a movie into just about any format and I leave a small low res version sitting on the DAW desktop.

 

I'm not so concerned about picture quality as I have a large screen running my master Quicktimes in DV NTSC but those movies are large files (around 3 gig for a 20 minute reel) .... so something small & quickly transferable would be marvelous.

 

Does anyone have a favourite low memory, easy on the CPU, QT codec for using in Logic?

 

BTW - my reason for attempting this is that after all this time I'm finding it to be a huge advantage whilst working with tempo lists having the movie onboard (almost sketching ideas)...... but having a movie that's on a large screen then gives you a totally different perspective when producing the final result as I find it difficult getting the perspective right for a final mix on a movie score working entirely to a small image.

 

Many thanks in advance.

 

ttfn

Link to comment
Share on other sites

I'm doing some experiments right now, using a 24 minutes video extracted from a dvd, trought MpegStremclip.

I've used the "export in QuickTime" first, using the Apple Intermediate Codec, 50% quality. The .mov file is now a 3,87 Gb file.

Same procedure, but with the "export to DV" now, and the file is a huge 5,38 Gb...

I've created a project in Logic with a bunch of V.I. tracks, some Omnispheres, a pair of Miroslav, some internal synth, just to put some weight on the project itself.

Long story short: there is no difference if I run the AIC file or the DV file, looking at the Cpu monitor in Logic: both push the signal around 50% using only the internal drive of my MBPro.

I know it's a charlatan procedure, but I'm not a guru...

:D

Link to comment
Share on other sites

Thanks Trafficart

 

That's a really interesting experiment. I also use mpeg stream clip for ripping DVD's for showreels ..... it's one of the most useful free applications out there.

 

I am so surpised that Logic manual writers don't take this more seriously.

 

How intriguing to hear you find no difference in CPU load between AIC and DV.

Link to comment
Share on other sites

  • 7 months later...

Dave Earl, while very knowledgeable about Logic, probably doesn't know film scoring. I would never advise asking a client for a PhotoJPEG version of a work print. And there's enough consensus here from people who do this a lot that DV is the way to go.

 

In similar fashion, I don't recommend that anyone ever transcode their own movie files from what the client gives you. Read on...

 

In my film score techniques classes I teach my students to specify (not "request") of the editor the kinds of files that they need. That means QT movies, DV codec, full frame render, etc. And most film composers, not being video transcoding experts, do everyone a disservice (especially themselves) by accepting non-DV movie files and trying to transcode them to other formats themselves. At worst, you can create sync issues. Second worst, you end up submitting draft movies to your client with crappy color because you used some codec (like PhotoJPEG) that can wash out the color. You may not care about the color, but your client will. Film is a visual medium, first and foremost!

 

Of course, there are always exceptions. Some film composers I know are given DVD's which they have to rip in order to get a satisfactory work print. But on the flip side, for every film I've ever scored, I've specified -- and received -- a DV movie file. No fuss, no muss.

 

So... I think it's pretty clear. While there may be 1000 ways to skin a cat, there really is only one foolproof file format/codec combination for movies you're going to score: QT movie, DV codec.

Link to comment
Share on other sites

  • 7 months later...

Hi, I'm new here :D

 

I have a question about the procedure of using DV.

Is it not true that DV is only available as 50/60i? (for PAL/NTSC respectively)

 

The project I am working on is in 24p (23.98) and adding pulldown will mess with my sync, I believe.

 

Is it possible to have DV in true 24p? If so, how? I am using Compressor 3 and I couldn't seem to figure it out.

 

My source video was delivered as h.264 - but it is frame accurate.

I converted to uncompressed 8-bit quicktime - this allowed me to keep 24p.

 

Thanks for the advice.

Link to comment
Share on other sites

I have a question about the procedure of using DV. Is it not true that DV is only available as 50/60i? (for PAL/NTSC respectively)

 

No.

 

The project I am working on is in 24p (23.98) and adding pulldown will mess with my sync, I believe.

 

First, you're working at the frame rate of 23.976, which is commonly rounded up to 23.98. You're not working at 24p (which is not a frame rate).

 

Second... this is not a pulldown situation. No pulldown is needed when working on a 23.976 film. All you need to do is set Logic's frame rate to 23.976. Then, of course, you need to check picture sync with Logic's timecode counter. If the timecode burn in the movie matches with Logic's timecode counter all the way down the film then you're good to go.

 

Is it possible to have DV in true 24p? If so, how? I am using Compressor 3 and I couldn't seem to figure it out.

 

My source video was delivered as h.264 - but it is frame accurate.

I converted to uncompressed 8-bit quicktime - this allowed me to keep 24p.

 

Again, 24p is not a frame rate.

 

Simplest answer to all this: you should ask for a DV copy from the client. That's the easiest, most foolproof way to get the materials you need to work effectively in conjunction with Logic. I always recommend to composers that they NOT mess with the video (via compressor) unless they're a compressor expert. There is too much room for error. And the worst thing a composer can do is deliver music that doesn't sync with picture properly.

 

If you can't get a DV copy then you can certainly run the copy they gave you. Playback of h.264, compared to DV, is going to be somewhat sluggish as computer power is sucked up trying to decode the first few seconds of playback each time you hit play. And there may be hiccups along the way too (picture stalling momentarily). You may also find it difficult to spot picture, because picture lags behind anytime the playhead is moved. You won't find this with DV, and that's why it's highly recommended that you ask for -- and get -- work prints in DV. Reason: DV is not as highly compressed a format as h.264 and requires much less power to decode. It also looks good.

 

Finally, when you say the video is frame accurate, do you mean that it's a full frame render (a picture containing all frames as opposed to a low-quality picture that runs at 23.976 but skips frames)?

Link to comment
Share on other sites

Ditto on DV...

It is rock solid.. Even if your delivered pics aren't in that format, MPEGstreamclip can easily make it so.

I've also been having a lot of success using the ProRes(LT) codec in conjunction with a Blackmagic IntensityPRO PCIe card. Works great for outputting HD content and not bringing the system to its knees.

Down here in PAL world, things are a little different concerning frames rates etc.. I love even number frame rates.. makes calculating anything a snap.

 

Regards,

Matt

Link to comment
Share on other sites

Hi thanks for the replies.

However, neither answered my question.

 

I am very familiar with video codecs and how to use compressor -- I also work as a video editor and cameraman.

I KNOW that I can use H.264 and I KNOW that it uses more processing power. I'm simply asking about the nature of DV.

 

As I understand DV, it contains a fixed number of pixels and is limited to 50/60i (err 59.94i, sorry)

If 24p is not a framerate, what is it? I am aware that it is actually 23.98 fps, however 24 is the accepted way to talk about it.

(Sidebar: there is also what is known as "true" 24 which is actually 24 and not 23.976 fps)

 

According to Wikipedia: http://en.wikipedia.org/wiki/DV

"Tape-based DV variants, except for DVCPRO Progressive, do not support native progressive recording, therefore progressively acquired video is recorded within interlaced video stream using pulldown."

 

Clearly this is not tape-based. However I can't find any option in Compressor to allow me to have a 23.976 progressively scanned video in DV.

When I converted my video from h.264 (24p) to dv, my resulting video was 60i. Therefore this is - in fact - a pulldown issue.

My resulting DV video no longer contained the same number of frames as the original video.

 

By frame accurate (sorry this is a bit vague) I only meant that the h.264 compressed video contains no dropped frames. IE. I had the editor double check that the total number of frames in the h.264 video is the same as the total frames in the ProRes edit.

 

So, if it is possible to have DV show in progressive scan with 23.976 frames per second, please, tell me how this is possible.

Link to comment
Share on other sites

After reading your post, I'm thinking that perhaps cameraman-speak is a slightly different animal from film composer-speak and what they discuss with editors or even amongst themselves, or what we've discussed here in the past related to Logic and frame rates; but within those realms, "24" is not the accepted way to discuss or identify 23.976 fps video. Somewhere a critical distinction needs to be made between 24fps and 23.976 material, and discussing 24 fps as 24 fps, and 23.976 as either 23.976 or 23.98, is the only way to do it. Film composers don't look to establish sync to 24p or read timecode numbers in 24p. A movie file in this frame rate range is either going to be 24 fps or 23.98 fps. And when it comes to syncing to 23.98 material no pulldown is needed. Here I speak from lots of experience working on 23.98 projects, syncing them up, and scoring them.

 

Thus I stand by the information I posted in answer to your questions, though offering insight on codecs is totally out of my bailiwick.

Link to comment
Share on other sites

And when it comes to syncing to 23.98 material no pulldown is needed.

 

Right, no pulldown is wanted because that would give me more frames per second and I don't want that.

However, to get a video shot in 23.976 frames per second into DV it must have pulldown added -- at least, according to the research I have done. Therefore I don't think that DV is really a good thing to use in order to score this project.

 

Unless, of course, somebody can correct me and tell me it is possible to have DV show progressive frames at 23.976 frames per second.

Link to comment
Share on other sites

Not sure if this is going to help, but here goes... At bottom is a screenshot of a trailer I worked on last year. Note the info in the info box at right from the QT player (accessible via CMD-I). It shows exactly what I requested from the client: DV codec, picture at the frame rate of their FCP session, full picture size, full frame render, and so on. So here's proof that it's entirely possible to obtain a DV movie at 23.98. These are the specs typical of what I ask for from editors, and the DV part is nothing novel. The question remains how you get this kind of material to work with, but as I said before that's out of my bailiwick.

1134171309_Screenshot2012-01-16at6_26_14PM.png.e6626682bf03cb7f0e7779adcddb304f.png

Edited by ski
Link to comment
Share on other sites

Thanks!

That screenshot provided the missing piece for me. I was trying to convert to a DV Stream...but what I needed was a Quicktime with the DV/DVCPRO codec.

 

In case anybody is wondering...

In compressor add a new preset for a quicktime movie. Then select settings. You want the DV/DVCPRO option - which then allows you to select frame rate and scan mode, etc.

 

3.jpg.7df742a75ca51979b0c092daeb338b4a.jpg

Link to comment
Share on other sites

In case anybody is wondering...

In compressor add a new preset for a quicktime movie. Then select settings. You want the DV/DVCPRO option - which then allows you to select frame rate and scan mode, etc.

Hey tawfer,

You should be aware that depending on the extent to which the original h.264 video was compressed, you can possibly see some pretty severe timing differences between what you end up with in the conversion to DV and what the original FCP sequence file had. Might not be a problem if you're underscoring or spotting ambience that doesn't need to be to-the-frame accurate, but if you're spotting short sound effects that need to be dead on to a specific frame, (eg a hammer strike or something) it can potentially be an issue.

Link to comment
Share on other sites

You should be aware that depending on the extent to which the original h.264 video was compressed, you can possibly see some pretty severe timing differences between what you end up with in the conversion to DV and what the original FCP sequence file had. Might not be a problem if you're underscoring or spotting ambience that doesn't need to be to-the-frame accurate, but if you're spotting short sound effects that need to be dead on to a specific frame, (eg a hammer strike or something) it can potentially be an issue.

 

Even for composers (where frame accuracy can indeed be an issue, particularly for animation), what fader8 points out is exactly why I recommend so strongly against a composer trying to do any kind of transcoding themselves unless they REALLY know what they're doing with codecs. Yes, sometimes it's inevitable that you can't get the type of movie file you really need from the client; at that point you may have to do some transcoding (i.e., processing the movie file so that it becomes encoded with a different codec). But when it's possible, get them to give you the type of file you need and that way there won't be any potential for sync issues. And that type is...

 

DV

Link to comment
Share on other sites

exactly why I recommend so strongly against a composer trying to do any kind of transcoding themselves unless they REALLY know what they're doing with codecs.

And even if you are an absolute guru with codecs, you may be receiving a file compressed by some "free" windows video conversion crapware and the file has no idea how many frames were in the original. I had to deal with one of these last year where after 10 minutes into the video, it would fall out of sync with the original camera audio I received. I couldn't fix it in one pass either because after that it would swing around! Late, then early, then really late, ugh. Pain in the ass.

Link to comment
Share on other sites

A great thread with tons of information. I just like to add my 2 cents:

 

Regarding the CPU burden of various video formats. With the old G5 and its limited resources, h.264 was almost impossible to use if you had already a very "demanding" project running. Now with the Intel multi-cores, it doesn't seem to be a problem anymore.

 

Another shift happens with the delivery mechanism. It seems that more footage is pushed now over the net with sufficient up and download speeds. Those videos most likely end up to be h.264 and not DV, especially for longer videos.

 

As Ski mentioned in his posts, it is important that you are proactive and specify your format needs. Once you educate yourself on that video subject and get some real life experience, you will be surprised that some video editors might know less than you about that topic. This is especially true in low budget movies with an inexperienced crew.

Link to comment
Share on other sites

yup. thanks fader8. I'm aware that there is the possibility of dropped frames.

My editor has told me that there weren't any in the original h.264 encode.

 

With compressor I did a timecode burn and then double checked with quicktime that the timecode burn was accurate to the timecode embedded in the DV movie - which also matches the timecode for the H.264. I also checked that the total frames for the movie is equal the total frames in the Final Cut sequence.

 

I think that is a sufficient check that there are no dropped frames.... or, rather, I hope that it is.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...