Firewire output of Hardware MPE - I give up

Ok... I'll forget about IEEE1394 output of hardware MPE.
I suspect it isn't likely to be resolved in CS.anything.
The technical challenge of routing a DV signal from the CPU/GPU
back through a firewire channel may be an insurmountable hurdle.
But it's really tough to let go of your pet peeve.
If nVidiAdobe were to develop a companion card to the primary GPU
that allowed realtime SDI and Component output of hardware MPE
to a broadcast monitor and/or deck, I would gladly buy one in a second...
regardless of cost.
Using third-party hardware and sequence presets, or employing the
suggested hinky workaround using a consumer grade monitor that
requires monthly attention to maintain its color calibration using
third-party hardware and software, or any other suggested approach
I have read here are IMHO, all flimsy second-tier dead ends.
Multiple monitors and/or Reference monitor in Premiere Pro
http://forums.adobe.com/thread/744683
With CS6 perched on the horizon, It seems Adobe is in the perfect position
to continue its inexorable march toward taking charge of the NLE market.
Most serious FCP editors are Ae users already.  Give them a good taste
of expanded native file support along with Dynamic Linking  and throw in
some new capabilities and reliability to Pr, and they will wonder why they
were doing things the hard way for so long.
Fellow pros used to snicker and roll their eyes at me when I said I was
using PPro2.  But, when I mention CS5 they will always have a few
questions about how well things work... and the snicker is long gone.
However, I feel the lack of realtime uncompromised external monitoring
is an issue that must be natively resolved before Pr can take the lead.
Adobe and nVidia should find a way to work this out.
I think a rhetorical question can be found here somewhere.

function(){return A.apply(null,[this].concat($A(arguments)))}
SCAPsinger wrote:
I've posted this before, and at the risk of sounding like a clanging gong, I'll post it again JUST IN CASE it's as useful a solution for anyone else.
You can easily output the program monitor of PPro through a 2nd (or 3rd?) video port. In the Playback options, you can select an additional monitor as the output for previews (same place where you would select DV output for previews). There is no extending of the PPro interface or other modification required other than to select the monitor in the Playback options.
When you hit play in PPro, it activates full screen playback on the monitor. Pause playback and it pauses on the monitor. If/when you ALT+TAB out of PPro to another application, the fullscreen goes away (and - for me - reveals my beautiful company logo on the desktop) but it comes right back as soon as you hit play.
It works on all timelines, no codecs or special setups needed.
I previously connected via a DVI > HDMI adapter cable, but now I use the HDMI out of the video card straight to the HDMI port of the external HDTV.
I'm sure this solution won't be satisfactory for everybody, but for me, it gives a very good representation of what my projects look like on the end users HDTV set. AND it's very easy to setup. AND it works with all sequence settings. AND it works with hardware MPE active. AND....well...guess that's about it.
Thanks for your input...
That is pretty much what I am doing (except I am using two video cards) but it is not accurate when you are using DV.
I need to output to an NTSC monitor not a progressive computer monitor.  There is a big difference when viewing.

Similar Messages

  • Battling Hardware MPE, Episode 2: Chunky Blurs

    Round Two of my hardware acceleration MPE tests...
    When using direct export with hardware MPE, any effect that renders a blurred alpha channel (Fast Blur, Gaussian Blur, etc.) creates an extremely ugly/chunky/unusable result. The source footage and sequence does not matter, nor does the destination format. The following examples are of an animated Gaussian Blur (from 0 to something) on a title clip, wiped off with a Gradient Wipe transition (toggle the GradWipe makes no difference). As with my previous thread (Battling Hardware MPE, Episode 1: Cropping on Export), I tested four variations of exporting: with hardware acceleration on and off, and with direct export and sending to the AME queue:
    GPU Acceleration off, sent to AME queue:
    GPU Acceleration off, direct export:
    GPU Acceleration on, sent to AME queue:
    GPU Acceleration on, direct export:
    So we've got good, good, good, bad. As before, the direct export method using hardware MPE seems to throw a wrench in the works. Any effect that blurs like this (including soft shadows or glows) suffers this ugly banding and harsh falloff. What's curious is that the last example is how the Program Monitor appears while GPU acceleration is enabled; if I disable it, it looks like it does in the first three. What I can't figure out, then, is where hardware MPE is actually at work! Is it in the direct export (bad) or in the queue (same as non-GPU accelerated)? It's not making much sense to me.
    Now, I had a chance to have a brief email exchange with one of the engineers regarding a similar issue a few months ago. In response to similar observations and questions, here is his reply:
    You are correct that composting with alpha can give different results. This is caused by processing in linear color so that blending is more like natural light. With MPE GPU acceleration, all composting is always done in linear color. This is nothing to do with the hack, but an intentional design decision to never compromise in quality. In software, composting is only done in linear color when rendering at maximum render quality because on the CPU it takes a lot longer. This probably also explains why you occasionally saw this with software. In the monitors we never show anything at maximum quality with unrendered footage. With software you thus need to export with max render quality specified or set max render quality in the sequence settings and render previews. For consistent results when switching between software and GPU acceleration I suggest enabling both max render quality and max bit depth.
    Either I'm not understanding this, or it's confirming the bug. I get that hardware acceleration is supposed to enable "linear color processing;" that's fine, if that's better than how it's usually done (whatever that is--I'm not an engineer), but based on what I'm seeing with the hardware direct export, it's WORSE than any software render or encode. Ultimately, I don't care what is technically superior if it looks aesthetically inferior. With the GPU on, a direct export is not usable, and when rendering through the queue, it looks visually no different than when not using the GPU.
    So based on the response above, I just did some more tests, this time with the Maximum Render Quality and Maximum Bit Depth options. I did not change the MRQ and MBD settings for the sequence itself--only in the export window--as it is my understanding that those check boxes will enable or disable those features. Using the same example above, I found some interesting results:
    So, this would appear to largely bear out what the engineer explained. My observations now:
    Hardware acceleration, at least as it pertains to this linear color processing issue, is fundamentally equivalent to Maximum Render Quality in software rendering mode.
    Maximum Render Quality does nothing to soften the chunky blurs, shadows or glows. Instead, Maximum Bit Depth must be enabled.
    In my initial tests, GPU On + Queue resulted in the same visual effect as GPU Off; in this test, GPU On + Queue resulted in the same effect as GPU On + Export (???)
    Setting the Maximum Bit Depth option for your sequence in hardware mode will display smooth blurs with soft falloff in the Program Monitor.
    Setting the Maximum Bit Depth and/or the Maximum Render Quality option in software mode has no effect on the Program Monitor display.
    Regardless of sequence settings, failure to set either the MRQ or MBD option in the export window will result in those settings not being applied.
    Setting either the MRQ or MBD option in the export window will always result in those settings being applied, regardless of sequence settings.
    After going through all this, I may be willing to concede that everything is working correctly, more or less. However, my complaint is now, "WHY does this have to as complicated as this?" There are simply too many combinations that have to be set properly to get the desired quality of output, and I firmly believe that this needs to be simplified. When exporting or rendering in hardware/GPU mode, I believe that MRQ and MBD should be on by default; as it is, even with the promise of "linear color processing" with hardware acceleration, I still have to remember to tick another box to make sure that blurs, shadows, and glows don't look like stair steps. The jury is still out on how "good" linear color processing is; maybe I just got used to software rendering of these soft alpha channels, but I'm having difficulty seeing the benefit of more "realistic" light processing at the moment. With hardware acceleration on, you're basically stuck with how those soft elements look; with the hardware acceleration off, I can opt for the more subtle look if I like, even if it means I give up the other presumed benefits of linear color processing. When I design graphics in Photoshop, I expect them to look at least reasonably similar in Premiere; with hardware acceleration on, all bets are off.
    I realize this is a new technology and will, hopefully, continue to mature and improve, but I'm hoping that this at least sparks some conversation about this issue. Casual users may not care too much, but anyone using this product for broadcast or other commercial work should be aware of the complications associated with the technology, and should demand that it work consistently and at an expected level of quality. Maybe I'm expecting too much of this, but I certainly hope not.
    Your comments are requested and appreciated.

    According to your last picture, the one thing consistent with all the problem footage is MRQ.  It seems that feature is actually causing the problem.
    Correct; that was basically a test to see if what was described by the engineer (namely, enabling MRQ to produce better alpha channel compositing) held true. Well, it's sort of six of one, a half dozen of the other. In essence:
    Hardware MPE = Software MPE + Maximum Render Quality = Linear Color Processing
    Enabling MRQ in hardware mode does nothing; enabling MRQ in software mode makes software mode act like hardware mode. In either of those scenarios, the alpha channel is composited using linear color, which causes soft shadows, glows, etc. to balloon. Additionally, the soft shadows are banding, due to 8-bit processing. Only by enabling Maximum Bit Depth can the banding be eliminated, but the bulbous glow remains. Setting Maximum Bit Depth alone in software mode has no apparent effect; the alpha channel may not be composited "more realistically" thanks to linear color processing, but it doesn't grow grotesquely or reveal banding, either.
    The tests above were conducted with the Gaussian Blur effect within Premiere. I decided to try a test using a Photoshop document; the PSD is a simple text layer with an Outer Glow layer style applied. I tried importing the layer with the layer style as it is, I tried flattening the layer, and I tried merging the layered document on import into Premiere; all resulted in the same effect. The results are more troubling than the examples above, as I use Photoshop for the vast majority of my graphics work for Premiere. Here's the test:
    This is text composited against the background video in Photoshop, so that I can see how the glow should be rendered:
    Nothing fancy, but the glow has a nice, subtle fall-off. When I import the PSD into Premiere, edit the alpha text layer over the background clip, and render out in software mode, this is the result:
    Visually identical to what I created in Photoshop; so far, so good. Now, if I enable MRQ and MBD on export, still in software mode, this is the result:
    Um, yuck. Enabling MRQ has had the same ballooning effect as in the tests above, but since the graphic and background video are 8-bit, and I'm not using a 32-bit effect (like the Premiere Gaussian Blur effect), enabling Maximum Bit Depth has no effect. The glow shows banding, and is just downright ugly.
    So what happens in hardware accelerated mode? No prizes for guessing correctly:
    No combination of Maximum Render Quality or Maximum Bit Depth has any effect in this case; the glow always looks like this in hardware accelerated mode.
    This is a HUGE problem, as far as I am concerned. Not only can I not use hardware MPE to export if I want a decent-looking glow, but I can't even use it in the design and build phase because the composited result looks NOTHING like what I'm building in Photoshop. I have a keyboard shortcut set up now to launch the Project Settings panel so I can toggle back and forth between software and hardware mode, so I can at least enjoy some of the acceleration of hardware for general editing, but for detail work and for export, hardware MPE is proving to be an Achilles heel.
    This is proving to be really depressing. Until I did these tests, I didn't quite realize the depth of the problem. Granted, no one is forcing me to use hardware acceleration, but am I wrong in calling this a serious flaw?

  • FCP Problem with Firewire output to external monitor and speaker ???Help

    i have a g5 powermac. the problem is when using Final cut pro 4hd. when i output my work through firewire to my external monitor and speaker i have a problem with the audio signal. Theres feedback/noise/hiss from the speakers. The firewire connects to DSR-11 vtr deck which feeds my monitor and speakers. it only happens when in FCP is set to A/V firewire output. does not happen if Video output is not set to firewire.
    I Diagnosis is that it is not my dsr-11 deck or firewire i've ruled those out. The problem is either FCP software or Hardware problem with my G5
    Does anyone have a similar problem. please respone, i will try to answer any respones,
    Thanks
    powermac g5     powermac

    CaptM
    From the firewire that feeds the dsr-11. on the output, i use s-video cable to my monitor (sony pvm-14l) and High Quality rca cables thet feed the audio to the Roland Speakers.
    I've changed all wires and still have audio problem. I,ve changed my Dsr-11 deck to my camcorder and still have the problem.
    If any of u guys use FCP The problem happens When I select view> external Monitor > and select firewire for Audio/ and video. I have never changed my editing habits, something just went wrong with the signal, I think its a Hardware problem with the firewire connection. I'm Going to have to bring this to a Apple Service Center In my local area one day.

  • CS5: Bug when exporting directly from PPro with hardware MPE?

    For the record, I'm using:
    A GTX-480 (unsupported)
    The hardware MPE-enabling hack (unsupported)
    The latest version of the nVidia drivers (257.whatever)
    I discovered an issue, of sorts, when exporting directly from Premiere CS5, versus using the "Queue" option to send to AME. I was exporting from an NTSC DV Standard sequence to a 320x240 H.264, in which I had enable cropping and trimmed a bit off the sides and top and bottom of the source; the Output tab was summarily set to "Scale to Fit". With hardware MPE enabled in the Project Settings, the export would be the proper final dimensions (320x240), but any area that was cropped off was instead padded with black. The actual video content was then squeezed and malformed into the area not occupied by the black bars.
    I found that, if I disabled hardware MPE or sent the export through AME by use of the Queue button (instead of Export), then the export was performed properly--the video was cropped correctly and then the video stretched to the borders of the exported video, maintaining the desired aspect ratio.
    As I mentioned at the outset, I'm breaking a couple rules and perhaps tempting fate with others, but before I go about rolling back my drivers and the like, has anyone noticed a similar issue?
    ADDENDUM: By the way, the export doesn't need to come from a sequence. If I load up a source clip into the Source Monitor, and export from there using the process outlined above, I get the same issue. This would seem to indicate, to me, that this is due to some incompatibility with my card, its driver and hardware MPE...

    Did he demo renders or exports?
    About 11 minutes in, he [Dave] demos accelerated H.264 renders.
    Harm Millaard wrote:
    AFAIK MPE only works with renders, not with encoding.
    Well, he did both, actually--but the quote above is a typo on my part. I meant to say "exports" or "encodes." The last couple minutes of the aforementioned demo video are dedicated to exporting a sequence directly from Premiere, and having the benefit of hardware MPE. That's where I'm getting the issue I've outlined above; with hardware MPE enabled, and using the "Export" versus AME "Queue" button/function, I get the strange black outline. With software MPE or through AME, all is well.

  • ATI Primary and Nvidia Secondary for Hardware MPE Acceleration

    Hi everyone,
    I'm not sure if this has been discovered yet. I think it is very exciting, and very important for anyone with an AMD (ATI) GPU who wants hardware MPE acceleration.
    It is possible to use Hardware MPE acceleration while using an ATI video card as your primary adapter, and a lesser CUDA Nvidia GPU as a secondary adapter not connected to any monitor.
    My system:
    CPU: 1090T
    Mobo: 890GX
    RAM: 8 1333
    RAID: No
    GPU1: 5870
    GPU2: GTS 450
    As you can see, I have a Nvidia and AMD GPU in the same system. The 5870 is obviously by far the most powerful of the two, and it is what I use to record rendered footage using FRAPS.
    Recently, I became aware of the powers of hardware MPE. I concluded that the best way to obtain HMPE and maintain my FRAPS recording was to purchase a GTX 480. However, this was out of my wallets league as I could not sell the 5870.
    I was already aware that PhysX (A CUDA physics calculation library) could only be run on Nvidia CUDA GPUs (Like HMPE). Many Nvidia card users used secondary CUDA cards to accelerate physics calculation in games. ATI card users could not use a secondary Nvidia card for physics calculation as the Nvidia driver locked down PhysX in the presence of an active ATI GPU. Luckily a clever fellow called GenL managed to hack the Nvidia drivers to force PhysX to work in the presence of an ATI GPU.
    I hypothesised that if I performed that hack, HMPE would gain access to CUDA in a similar fashion to PhysX, thus allowing me to buy a far cheaper GTS 450 and pair it as an HMPE renderer with my 5870. After buying a GTS 450, I failed at implementing the hack and was about to give up.
    HMPE worked when my monitor was connected to the GTS 450, but if i tried to start PPro with the 5870 connected to any monitor HMPE was unavailable.
    I had two monitors connected to my GTS 450, and was playing around with adding stupid amounts of HMPE accelerated effects to an AVCHD clip. Realising that it was impractical to constantly switch the DVI cable from 5870 to GTS 450 I decided to leave my primary monitor connected to the 5870 and give up on HMPE. So, I reached around behind my computer and did it, but crucially did not quit PPro before I did so.
    When the screen flickered back to life, the yellow HMPE preview bar was still yellow. The timeline still scrubbed perfectly smoothly. HMPE was still working with a 5870 as the primary monitor: The PPro window was on the 5870 monitor, and the 5870 was rendering the window!
    I found that provided I did not close PPro, I could switch between HMPE and SMPE at will, all while using the 5870 as the primary adapter.
    I tested this using a 10 second composition of 3 AVCHD 1920x1080 Clips with CC, drop shadow, gaussian blur, edge feather, Basic 3D, transform, Ultra Key, drop shadow applied, rotatating amongst each other. I could still switch even if the 5870 was the only card connected to a monitor.
    Rendering this test clip via PPro direct export takes 30 seconds in HMPE mode with the 5870 and 1.43 in SMPE mode with the 5870.
    However: Rendering performance in AME stays the same whether I selected HMPE or SMPE. I believe this is because AME is a separate application that 're-detects' the ATI card and disables HMPE before beginning the encode, in the same manner that restarting PPro while using the 5870 removes the HMPE option. Rendering the clip in SMPE and HMPE modes using the GTS 450 gave the same 30 second vs 1.43 minute result.
    Therefore, as long as you are happy to encode via direct PPro export you will still see the benefit of HMPE while using an AMD card as the primary adapter.
    I hope this is as terribly excited to other users of ATI cards as it was for me. This has saved me several hundred dollars.
    Cheers,
    NS2HD

    Interesting results. I own a system manufactured by BOXX, a system developer out of Texas who really knows their stuff. I had asked them if it would be possible to purchase a CUDA enabled card and put it in my secondary slot and use it for MPE while maintaining my current (nvidia) card to run my monitors (also giving me the ability to run four screens). They said that no, according to the Adobe developers they were working with, Premiere could only use MPE off the CUDA card if the monitor previewing your work was plugged into that card. I guess they were wrong!
    Also, from my understanding, you don't see lesser results with AME because it's a separate program that starts separately, you see the lesser results because it has not yet been coded to take advantage of CUDA.

  • Alpha channel weirdness with hardware MPE

    To begin, I'm using a GTX 480 with the hack, so I'm not going to complain too loudly it this is a result of using as-yet unsupported hardware. However, I just want to verify with other hardware MPE users (both legit and unsupported) if this issue is happening on other systems.
    I've noticed some oddities with imported PSD files and the way that their alpha channels are rendered with hardware MPE, versus software MPE. I'm putting up a couple frame grabs with GPU acceleration turned on and off at couple different point where I'm using the PSDs. Forgive the PNG compression; you should be able to see the difference, nevertheless.
    First up, 100% opaque text over a background. The edges of the text are... fuzzy, maybe?
    Software:
    Hardware:
    Second, a couple layers Fast Blurring and fading in. The logo is 100% opaque, and there is a separate "glow" layer (rasterized in PS) behind it. Pretty obvious, here...
    Software:
    Hardware:
    Finally, a mostly-transparent logo bug. The hardware version is not as transparent.
    Software:
    Hardware:
    The only difference between each of these examples is that I turned on or off GPU acceleration in the Project Settings; it's the same PSD for each grab. I've also noticed that standard cross dissolves are a little chunky when dissolving to or from a graphic (even a flattened version); the opacity change is not as linear as it usually is. In software mode, this goes away.
    Anyone witnessed similar results? Again, I want to believe that this is just a result of using the GTX 480 and the hack, without official support. It could very well be the nVidia driver, too, I suppose, but I haven't tried rolling back to check that (I'm running the latest versions).
    Thoughts?

    I can confirm this.
    I do not think its the psd but the Alpha Channel in general.
    The colours are off when in MPE (Nvidia GTX 285)
    I filed a bug report.

  • Firewire Output for Video Preview Intermittent

    I'm experiencing a frustrating problem with After Effects these days.
    We're producing some video to be projected, so to see what the final output will really look like, I'm doing video previews using FireWire so output goes directly to the projector. 
    It's been working great up until yesterday.  Was working fine until I had to restart my Mac.  Upon reboot, my the projector no longer gets any video output.
    I've tried restarting numerous times, checked all connections, etc.  Got it working again after several restarts, but after switching over to Photoshop momentarily, the video output once again disappeared.
    Any suggestions on how to regain consistent Firewire output for Video Previews?
    My setup:
    After Effects CS6
    Mac Pro
    OSX Version 10.7.5
    Firewire Output of my Mac's monitor is going to the Firewire Input on my Sony Media Converter
    RCA Video out (Composite video) going to the projector's video input.
    After Effects Video Preview preferences:
    Output Device:  FireWire
    Output Mode: Apple FireWire NTSC

    Thanks for your reply, Rick.
    I finally figured it out... I had a background application running called iCam that monitors my security cameras.  I had forgotten that it uses Firewire and was intermittently hogging the resources.  Once I quit that application, everything was good once again.
    Thanks for taking the time to respond, much appreciated!
    Mike

  • I am buying an audio interface with Firewire output, would I feed this into Firewire,USB or Thunderbolt for Garageband?

    I am buying an audio interface with Firewire output, would I feed this into Firewire,USB or Thunderbolt for Garageband?

    I don't have a H4 but do have a H2. Did you set the H4 as a audio interface, after you plug it in choose interface in the H4 screen?
    Did you choose the H4 input channel in the track info?

  • Firewire Output.....

    I'm using Garage Band on a brand new iMac 21.5"... my first Mac actually.
    I'm using a Mackie 1640i to record church worship and not having any issues there, my question is this:
    The console allows me to feed it 16 channels of audio via Firewire to the individual channels on the console. Is there a way in Garageband to assign each channel an individual firewire output channel?

    Well, the idea would be to use the analog side of the console for the final mix, as well as having a pretty unique teaching tool for up and coming sound personnel.

  • Firewire output volume to Onyx board

    I can't find a way to reduce the Macbook firewire output to the input on my Mackie. Neither device seems to have an adjustment and the firewire output is ten times hotter than the analogue inputs on the board.
    Other than turning down the volume in each individual app, any ideas?
    Thanks!

    Welcome to the Apple discussions.
    Sometimes the volume setting gets jumbled, and resetting the PRAM will fix it. Follow these steps:
    1. Shut down the computer.
    2. Locate the following keys on the keyboard: Command, Option, P, and R. You will need to hold these keys down simultaneously in step 4.
    3. Turn on the computer.
    4. Press and hold the Command-Option-P-R keys. You must press this key combination before the gray screen appears.
    5. Hold the keys down until the computer restarts and you hear the startup sound for the second time.
    6. Release the keys.

  • Can I convert a camera Firewire output to a USB input on a laptop without buying a Canopus box?

    Can I convert a camera Firewire output connector to a USB input on a laptop without having to buy a Canopus box or other expensive piece of equipment?

    Unfortunately, no. Firewire and USB are two entirely different methods of transfering data. There's no simple/cheap converter out there. You will have to look into either purchasing a canopus device or get a computer which will support a firewire or video input.
    Thank you,
    Stephen Apple
    Independent Broadcast

  • My Powerbook boots up every few times and the hardware test still gives me -9972 error

    René O'Deay wrote:
    My Powerbook G4 15" aluminum 1.67Ghz 10.3.9 Panther won't start up.
    (I did a backup on an external drive not long before it failed)
    have gotten lost in my research on apple forums and knowledge base.
    From the original install discs:
    The Hardware test gives the error.
    "2STF/8/3 ATA-100 ata-6-Master (-9972)"
    The Disc utility does see my harddrive but fails to repair with the messge:
    1 volume cannot be repaired,
    'Invalid  node Structure'
    Disk 'no valid packets (-9997)'
    I do have a useless partition from TechTool 4 and had successfully run the programs just before Powerbook failed.
    aid everything was ok, with no warnings.
    found somewhere a link to a hardware test code list, that said 9972 could be the cable (ribbon?) to the drive needed to be reset, replaced, or the harddrive replaced.
    our local New Orleans 'official' Apple Tech guy calimed it was the harddrive and not worth replacing.  he whined that it would take hours, tho the guys on ifixit claimed only half an hour.
    i have since got a refurb MacBook (even older it turns out) with Tiger, but I miss my 15 incher Powerbook. (on very tight budget)
    the battery got zapped by lightning last year and have struggled with it ever since. it won't fully recharge.
    Right now have got it on the AC without the battery to try to charge the backup battery.
    I have managed to restore it several times after crashing, inspite of my tech guy claiming otherwise. but have never really opened it up besides just looking at the memory slots. just one filled with 512 card.
    so any advice, or suggestions.
    I've been messing with my Power book for like 10 hours and finally finished replacing the hard drive. (just installing the software and all the updates took almost 2 hours by itself) Now it boots up every few times and the hardware test still gives me -9972 error.
    <Re-Titled By Host>

    My friend. Do not despair.
    Firstly, you have a backup. Kudos.
    Secondly, i suspect the hard drive in the machine is more than just a few years old. Hard drives die. I suspect the hard drive is the issue, not the cable.
    Thirdly, it is worth changing the hard drive and take the ifixit advice. Simple to change. If it will be your first time changing the hard drive, just be organized and follow the steps carefully.
    Now, before we decided it is the hard drive we need to confirm this.
    I would check if SMART reports favorable conditions for the drive. Disk utility can tell you.
    If good then I would zero out the drive. This allows the drive to excercise every sector and will build confidence of a well prepared drive going forward.
    You can then restore from backup.
    The other option is to replace the internal HD with a new one, perhaps with more storage.
    As an FYI, I replaced the drive on my powerbook G3 and it's faster, quite , has more storage and gives me some peace of mind. Worth the money. The little guy runs beautifully. 
    Sent from my iPhone

  • HDV via FireWire output not available

    After editing an HDV50i project in a HDV50i timeline I would like to print it to video. Under "View -> Video Playback" all the HDV options are gray! I cannot select them. Consequently I cannot play the video through the FireWire output. In "Easy Setup" all possible codecs are there and I can choose them (DV, HDV, ProRes, DVCPro etc.etc.). When I startup FCP my Sony Z7 is already attached via FireWire. What's going wrong?

    You can't play back HDV through FireWire. The video stream has to be conformed because of the MPEG-2 format. You can print to video. To see your output on a monitor you'd need to get a Matrox MXO2 box.

  • Battling Hardware MPE, Episode 1: Cropping on Export

    This is likely going to be a series of posts about some of the--shall we say--quirks I've encounted when trying to work with hardware acceleration/MPE with CS5. I should preface this by saying that I am, at this time, using a GTX 480 which is obviously unsupported, so I'm willing to accept that any of what I've come across is due to this fact; however, I'm pretty sure that these issues are endemic to hardware accelerated MPE, in general.
    The first quirk I've found is that when exporting from Premiere with GPU acceleration activated, using the Export button, while cropping the source using the export crop function, the resulting encoded file is not properly rendered. Specifically, this set of variables results in black bars in the encoded video, seemingly the result of the "Scale to Fit" parameter being ignored. The source sequence type and material as well as the destination format do not seem to matter; originally, I thought this was an issue with the H.264 encoder, which I use for exporting small emailable spot reviews, but I've confirmed it with other formats like Flash and AVI as well.
    Since a picture is worth 1000 words, what follows are four screenshots illustrating the two variables I'm testing--namely, GPU acceleration and direct export vs. AME queue. For reference, the source sequence is a standard DV NTSC sequence, with a mish-mash of graphics and footage, and I'm exporting to a Lagarith AVI, 320x240, progressive, cropping 12L,4T,12R,4B, Scale to Fit. No, I wouldn't ordinarily export to such a file, but it's the same regardless of format, scaling, or cropping values.
    GPU Acceleration off, sent to AME queue:
    GPU Acceleration off, direct export:
    GPU Acceleration on, sent to AME queue:
    GPU Acceleration on, direct export:
    In the last one, you can clearly see the issue. Since the aspect ratio of the rendered file isn't changing, it would appear that the Scale to Fit option is not necessarily being overriden, but it's almost as if the crop values are being reapplied and creating the black bars.
    So, if this is due to hardware MPE, why isn't it appearing when sending the export to the AME queue? Well, here's my theory: hardware acceleration/rendering isn't being used when the export is sent to the queue! Check out the first three images: they are exactly the same. I would expect this of the two "GPU off" screenshots, but not of the "GPU on" screenshot.
    Now compare the two "GPU on" images; the one showing the cropping bug is noticeably sharper, and it shows the telltale signs of the linear light processing that hardware MPE is supposed to enable (which is another issue I'll cover later). You can see the blue light rays coming off the sparks much more clearly in the last image (again, not that I like this, or that it should be that way, but it's an indicator that MPE is working).
    So what the heck is going on here? Is this a bug, a quirk due to me using an unsupported card, or is this a "feature" in much the same way that linear light processing of GPU accelerated MPE is a feature? This would be a pretty simple thing for anyone to test: just create a DV sequence, throw anything in it (color bars would work), crop 8 pixels off the sides in the export window, and use the Export button to render to any particular format at 320x240 (I've confirmed this with other frame sizes, by the way).
    Hoping to get to the bottom of this... thanks for any discussion this may spark.

    Yep, Huston we have a problem.  I can reproduce your example. I have a GTX285.  Everything works great on my setup.  I have MPE enabled.
    I also tried a variation of your example.  I exported a 1280x720 image to a DV 720x480 Wide format.  I cropped 8pix from the TOP and Bottom so no black bars should be seen..
    If exported via Queue, fine.  If exported directly the resultant image is cropped to 4x3.
    Exported via Queue
    Exported directly

  • Firewire output Support

    Does anyone know when apple is going to add support for Firewire out To external monitor?
    Or we are stuck with having to buy a IO Card $$$$$
    Without External monitor support Color is Useless.
    Some info would be appreciated.
    Sigi

    There will never be any indication of what Apple ever intends to do on any subject.
    I thought this was a well understood principle by now.
    Consider this, though... Apple appears to be a hardware company that will loss-lead its software to attract revenue. As a profit-oriented company, what would their motivation be to re-tool the software to sell someone else's hardware? Discuss among yourselves.
    Consider also that FireWire operates at a given bitrate. Its DV. Consider that the application COLOR was designed, and is stated, to be a high-end correction/grade system. It does give the user the option of rendering back into the source codec, or into either Uncompressed or ProRes422/HQ. There are no options for lowering the output to a more compressed format. Some of this has to do with the fact that it is a GPU-based (not CPU) render engine, and FW(400? I'm assuming...) is probably not going to come out of there very easily... and consuming more cycles is not going to help the overall performance that so many complain about at the outset.
    Buying a Grand Prix racing chassis and then dropping in a Honda 4.0 HP lawn mower engine does not guarantee you a competitive ride, I'm afraid... well..., maybe down at the local gokart range, maybe, against the kids with the de-tuned bumpercars.
    JPO

Maybe you are looking for

  • Loading style sheets at run time

    I have created few fonts css and compiled them into swf to load them at run time. There is one custom component Card, is placed into a Module and this Module is loaded by main application. The Card component contains TextArea, MyTextArea(custom compo

  • Planned orders scheduled on Non working days

    Hi,        Planned orders scheduled on Non working days no Planning calnder assigned to the Material

  • Transferring songs from ipod to itunes on computer

    I recently loaded songs from a CD onto my portable computer. I then transferred these to my ipod. I am unable to simply transfer these from my ipod onto my main computer. Suggestions?

  • Sony NEX 5T ARW ICO Elements 11 and LR 4.4

    I have a Sony NEX 5T. Neither Elements 11 nor LR 4.4 will open the ARW files. What are my options?

  • Post Moved BT Broadband Desktop Help

    post moved http://community.bt.com/t5/The-Lounge/Why-BT-Broadband-Desktop-Help/m-p/462991/message-uid/462991#U4... If you want to say thanks for a helpful answer,please click on the Ratings star on the left-hand side If the reply answers your questio