Bill Lee
Forum Replies Created
-
Or can you do a quicktime straight out of PP?
Except that from personal experience it never seems to work right, and will lose its programmed slide transitions at some stage of the QT movie. This is with Word 2004 (prior to some recent Word updates so it may work now). This was attempted on a number of computers, so is less likely to be an issue with just one computer.
When I’ve exported out a QT file, all looks good until minutes later when the transitions seem to disappear and end up at straight cuts when imported into an FCP timeline.
It may work for you and is certainly worth trying, but you need to check all of the QT movie to ensure the PPT transitions are still working.
Bill Lee
-
Read the Guide that comes with MPEG Streamclip: it will give you a little bit of information without getting too technical. You can even print it out.
Even more simply put:
-
Bill Lee
November 6, 2006 at 7:12 am in reply to: connect external TV monitor to play back FCP stuff?I always troubleshoot the basic setup with iMovie HD – it either works or it doesn’t and you avoid the myriad settings that can make it not work in FCP.
After you get the setup right:
Good: Computer -FireWire-> DV-Deck -composite video->Television
Good: Computer -FireWire-> DV-Deck -stereo audio->TelevisionBetter: Computer -FireWire-> DV-Deck -S-Video->Television
Better: Computer -FireWire-> DV-Deck -stereo audio->Amplifier and SpeakersBest: Computer -FireWire-> DV-Deck -component video->Broadcast-Monitor
Best: Computer -FireWire-> DV-Deck -stereo audio->Amplifier and SpeakersThen Shut it all down. Power Up the DV Deck first, then the computer. Run iMovie HD and see if it talks to your deck and can capture and output video. If so, then your FireWire chain is correct. Then run FCP.
Apart from that, Like What Shane Said.
Bill Lee
“iMovie: the Go/No-Go guage of FireWire FCP workflow” -
It depends on a lot of factors, such as codec, number of tracks in use, what you consider “Sluggish” (i.e. compared to what?), number of filters and the filters themselves.
Are you attempting to use 8-bit uncompressed off a single FireWire 800 disk? If so, you need to read the following web pages from Blackmagic’s web site: https://www.blackmagic-design.com/support/detail.asp?techID=61, even if you don’t use a Decklink card. Notice that it doesn’t even mention FireWire drives.
What is even more important to understand is https://www.blackmagic-design.com/support/detail.asp?techID=30. Notice that Uncompressed 8-bit NTSC requires a sustained read rate of at least 20MB/sec per stream. Which is about the speed I get from the FireWire 800 disk on my desk. So, to do a cross dissolve is going to require at least 40MB/sec and if you are compositing multiple tracks, then the requirements just keep stacking up.
Since you have a Quad G5, you should be able to add another internal 3.5″ disk to the existing one, or add a SATA PCI-e expansion card and use at least two or more external SATA drives RAIDed together for speed (and possibly reliability). Or you could buy a PCI-e SCSI card and attach some RAIDed SCSI disks instead.
It looks like you will have to spend some money to get adequate performance on your system if you want to use 8-bit uncompressed – are you sure you can’t do this with an compressed format?
Bill Lee
-
Blackmagic Support: Why are there multiple 8-bit codecs?
Blackmagic Support: Warning message during driver installationThe Blackmagic guys also have their own forum on Creativecow, and they keep a close eye on the postings made there.
Bill Lee
-
What would be the best way to setup daisy chained firewire drives and have them simulataneously accesible from 2 to three Macs. Is there a firewire solution?
There is no best way to do what you ask with FireWire, since I woud not recommended FireWire-based drives in this case.
Apple brought out XSan for a reason, and the principle reason was to do as you describe.
The problem with Firewire drives is, although they use peer-to-peer communications (unlike USB) the headers for the drives are used and cached by only one of the computers that is attached to them, to prevent two computers writing to the same location at the same time, and corrupting the disk structures as well as the data on the drive. The last computer that wrote to this drive would be the winner, but that is likely to irrevocably damage whatever you are trying to work with.
There are alternatives to Xsan, that use the computers that are part of that SAN to manage the co-ordination of whose computer it is to write to a disk while all others can read-only.
The reason I say that FireWire disks are not recommended is that they have slow read/write times, quite unsuitable for multiple access due to their IDE-FireWire or SATA-FireWire electronics which limits their speed. OK for plug-and-play direct connect, not so good for fast speeds. Example: I get about 9MB/sec from my FireWire 400 drives, and about 18MB/sec doing Finder copies. I was getting above 45MB/sec with inbuilt SATA drives.
One other possibility is a NAS or a file server on 1Gbit Ethernet, but I haven’t played with any that are fast enough for reliable multi-user access.
Bill Lee
-
[alphami] “After I select the destination for both the Audio and Video and after I click “subit” a box appears saying “unable to locate background process”.”
https://docs.info.apple.com/article.html?artnum=93234 -
[Alexander] “This test demonstrates exactly what we should NOT do, ie re-encoding to the same codec.
I’m arguing that re-encoding to another codec without understand what is happening to your video can be worse than re-encoding back to the same codec. In the case of using DV in the Apple Uncompressed Presets it can be demonstrably worse.
Why would we ever go back to DV?
Because of the KISS principle for most people. You are not ‘most people’, since you don’t need to go back to DV. Most people do (here I’m guessing), since they need to go back to DV tape at some stage, meaning that at some time they do have to run their video back into a DV encoder. If they don’t need to tap off a different output format before doing this, then they would be crazy not to do the whole thing in a DV sequence. Provided they follow some very simple steps, such as deleting any nested sequence render files and re-rendering the outermost sequence before final delivery, then they won’t run into more of the subtle problems caused by switching codecs, and yet can maintain the same quality gained by using an intermediate lossless codec.
In your post you mention that DV artifacts will not show when > un-compressed (they are hidden).
No, I said that DV artifacts will show when the DV NTSC clip is placed in an uncompressed timeline. You can’t get these artifacts out of the video, since they have now become part of the video. I’m sorry if I managed to give you that impression.
I assume we go un-compressed only when COMPLETELY finished (text aside), and then to delivery codec.
You can use an uncompressed sequence at any time, as long as you don’t have intermediate DV render files being used in this sequence. Just remember there are uncompressed sequences and Uncompressed Presets as supplied by Apple. They are not one and the same thing, since the Apple-supplied Uncompressed Presets are a subset of the huge set of possible uncompressed sequences.
DV is DV, there is not much we can do about the carried-over DV artifacts, so we are forced to accept them, part of the codec.
Very true, all we can try to to is to not make them worse by introducing more artifacts, such as would be caused by re-encoding them as DV. But sometimes we are forced to do at least one re-encode to DV in order to get our output format if this format is required to be DV.
Most of my work is for DVD delivery
Then dump your DV encoded clips into a lossless codec sequence before outputting it to your favourite compression program instead of taking it out as DV. What about video with each frame encoded as lossless PNG, or even the Animation codec? The down side of this may be the inability to play back in real time using that codec. You can use the Apple-supplied Uncompressed Preset for DV NTSC, as long as you remember to do two things: 1) Move the frame up/down one pixel to retain the correct field dominance, and 2) crop rather than scale from the 720 x 486 to a 720 x 480 frame size to avoid scaling issues.
Personally I feel that if you started with DV video, then DV and DVD are a reasonable match for quality and artifacts, and that it is usually not necessary to export as uncompressed as an intermediary step between DV and MPEG-2. Quality preservation from time spent on tweaking the MPEG-2 encoder to give better quality output far outweighs the quality loss from one more DV encode (IMHO). Subtle things like small amounts of black and white restore allow bits that might otherwise be wasted on detail in dark/light areas to be used to provide better detail in the midrange.
The whole point of going to uncompressed from DV for me is to avoid the gamma shift that T-L Compressor creates.
(https://docs.info.apple.com/article.html?artnum=304182)
See also Step 10) in (https://www.kenstone.net/fcp_homepage/basic_build_dvd_in_dvd_sp.html)
You can adjust the gamma as a filter in the Compressor presets.The mpeg2 codec uses the field order of the source material, and I have not seen a field order problem with this method.
I believe that is because the MPEG-2 video on a DVD can have either upper or lower field dominance and will play back correctly. Compressor and then DVD Studio Pro might be sensing which field dominance is set in the video output from FCP and they both respect that setting and maintain it through to the final DVD (or maybe the default settings happened to be the right ones). As the Apple article on field dominance says, field dominance is how the data laid down on media is interpreted by the player as to which field should be shown first.WRT scaling, Compressor’s presets for say mpeg2 for NTSC rescales to 720×480 size for 4:3 and Automatic size for 16:9, so the frame size of the un-compressed T-L is compensated for”
I believe this is where your video is being damaged, if it scales from (720 x 486) to (720 x 480) instead of cropping off the extra three scan lines top and bottom. Temporaly-separated scan lines are being interpolated and thus you will end up with a fields containing a mix of the other field.
Try it and see. Open a Photoshop file 720 x 486, with every second pixel row white and every other pixel row black. Now go to Image>Image Size and rescale it to 720 x 480. Do some white scan lines now appear where the black lines previously were? And vice versa? And do other scan lines now have a grey appearance, showing a mixing of two adjacent fields?
16:9 is just a flag to tell the player how to stretch the 720 x 480 frame.
In Compressor, you can crop the frame by those six pixels before you start the conversion, so you can work around the fact that D1 NTSC frame sizes are different to the DV NTSC frame sizes. It is unclear as to whether Compressor might be detecting the D1 frame size and automatically cropping it to 720 x 480 to make it suitable for DVD, so that you may not be seeing any scaling issues.
Bill Lee
-
Oops, a typo on my part made it look like I was against exporting video FROM Compressor, where I really meant (and the context shows) that the issue was about exporting TO Compressor directly from FCP. My fault in not making it clear enough that it was about exporting to the Compressor application from the File>Export>Using Compressor menu option: ” swore not to export directly from Compressor again” should probably have read ” swore not to export directly from Export>Using Compressor again”
You should use the output of Compressor. Really. It has been getting better and better over time.
I note that even Alexander still keeps the habit of working around a fault of FCP 3 that almost certainly doesn’t still exist in FCP, which is the core of the comment I was making. Keeping track of when that fault was cured was not enough, since I was running across this problem with people using FCP 3 long after it had been fixed in a later version. The other benefits of exporting as a reference movie more than make up for the inconvenience of this separate reference movie to me anyway.
Bill Lee
-
> Some sort of bug bounty available?
I know I’d settle for “Apple fixing the bug in a short time.”
Bill Lee