August 2009 - Pro-apps-dev - lists.apple.com

Re: Testing with lossless codecs
by Darrin Cardani 11 Aug '09

11 Aug '09

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com <http://lists.apple.com/mailman/listinfo/quicktime-api> Darrin On Aug 11, 2009, at 10:34 AM, Dan DiPaola wrote: Team, What if we would like to try and stay in a 16 bit world? best, Dan DiPaola Co-Founder HD-encoding.com 818.859.7700 office 818.823.5500 cell dan(a)HD-encoding.com QualityNotQuantity On Aug 10, 2009, at 8:37 PM, Andreas Wittenstein wrote: Brian, http://www.bitjazz.com/sheervideo/ Andreas Wittenstein BitJazz Inc. http://www.bitjazz.com/ On 2009 Aug 10, at 12:44 , Brian Gardner wrote: Thanks, Darrin. There appears to be no way to test my plugins using a lossless QuickTime codec. _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/hd444%40mac.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/dcardani%40apple.com -- Darrin Cardani dcardani(a)apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… As mentioned, there's the None16 codec and the Microcosm codec. I know that the TIFF spec supports 16-bit per channel data, but I don't know if the QT TIFF codec supports it off the top of my head. You might have more luck with these codec questions on the QuickTime-API list. You can add yourself here: Animation and None are 8-bit RGB[A] codecs. If you need an RGB[A] QuickTime codec with 10 bits of precision per channel, try Sheer RGB[A] 10bf. It's only free for the first 20 days of use, but it's truly lossless, it's really fast, and it's cross-platform. I tried the Difference matte technique you suggested to test a number of QuickTime codecs, including the Animation codec. None of them were lossless. Actually, it's kind of scary that QuickTime does not have a single codec that is completely lossless... even the "uncompressed" were lossy. I used a 10 bit DPX 1920x1080p 24.0 fps sequence as source footage, which I've just received from a recent music video shoot, shot on a stage. The goal is to convert it into a single QuickTime ".mov" file, with lossless compression (or even no compression). I couldn't achieve that goal. Here are the codecs that I tested: Animation (at best setting) - truncates off the bottom 2 bits (10 bit - > 8 bit), which is lossy. None - Exact same results as Animation. 8-bit only. truncated bottom 2 bits. Lossy. (Differencing the Animation and None codecs to each other gives 0's-- exact match.) FCP Uncompressed 422 10 bit - differences at all edges (to be expected, 444->422 issue) DNxHD 10 bit 709 - Noisiest of these codecs. (Noisy into top 8 bits.) Blocking artifacts, especially in the vertically oriented direction. Lossy. Apple Pro Res HQ - slightly noisier than FCP Uncompressed 422, but similar 444->422 lossy results. Apple Pro Res 4444 codec - least lossy of the codecs I tested. Appears to have saved full 10 bits. (Did not just truncate down to 8. Possibly can do 16->16 bit?) Noisy in bottom bits, though. Lossy. NOTE: The Apple Pro Res 4444 codec has a bug, in that it does not appear to do the right thing if it is given an image that does not have an alpha channel. And there is no option in the codec UI to automatically add a fully opaque alpha channel. (It would be very nice to have that option.) When I layer two copies of the SAME resulting ProRes 4444 video on top of each other, and toggle visibility of the top layer On & Off -- they do not match! There is a brightness/contrast difference, which appears to be stemming from the alpha. For my 10 bit 444 source video, Pro Res 4444 was less lossy than "Uncompressed", "None", and "Animation". "Lossless" QT codecs appear to only be lossless for 8 bit video, not anything above 8 bits. Ditto for 444 video ... where even "Uncompressed" is quite lossy. Both were rather jarring surprises. -- Brian This email sent to hd444(a)mac.com This email sent to dcardani(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: Testing with lossless codecs
by Dan DiPaola 11 Aug '09

11 Aug '09

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Team, What if we would like to try and stay in a 16 bit world? best, Dan DiPaola Co-Founder HD-encoding.com 818.859.7700 office 818.823.5500 cell dan(a)HD-encoding.com QualityNotQuantity On Aug 10, 2009, at 8:37 PM, Andreas Wittenstein wrote: Brian, http://www.bitjazz.com/sheervideo/ Andreas Wittenstein BitJazz Inc. http://www.bitjazz.com/ On 2009 Aug 10, at 12:44 , Brian Gardner wrote: Thanks, Darrin. There appears to be no way to test my plugins using a lossless QuickTime codec. _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/hd444%40mac.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… Animation and None are 8-bit RGB[A] codecs. If you need an RGB[A] QuickTime codec with 10 bits of precision per channel, try Sheer RGB[A] 10bf. It's only free for the first 20 days of use, but it's truly lossless, it's really fast, and it's cross-platform. I tried the Difference matte technique you suggested to test a number of QuickTime codecs, including the Animation codec. None of them were lossless. Actually, it's kind of scary that QuickTime does not have a single codec that is completely lossless... even the "uncompressed" were lossy. I used a 10 bit DPX 1920x1080p 24.0 fps sequence as source footage, which I've just received from a recent music video shoot, shot on a stage. The goal is to convert it into a single QuickTime ".mov" file, with lossless compression (or even no compression). I couldn't achieve that goal. Here are the codecs that I tested: Animation (at best setting) - truncates off the bottom 2 bits (10 bit - > 8 bit), which is lossy. None - Exact same results as Animation. 8-bit only. truncated bottom 2 bits. Lossy. (Differencing the Animation and None codecs to each other gives 0's-- exact match.) FCP Uncompressed 422 10 bit - differences at all edges (to be expected, 444->422 issue) DNxHD 10 bit 709 - Noisiest of these codecs. (Noisy into top 8 bits.) Blocking artifacts, especially in the vertically oriented direction. Lossy. Apple Pro Res HQ - slightly noisier than FCP Uncompressed 422, but similar 444->422 lossy results. Apple Pro Res 4444 codec - least lossy of the codecs I tested. Appears to have saved full 10 bits. (Did not just truncate down to 8. Possibly can do 16->16 bit?) Noisy in bottom bits, though. Lossy. NOTE: The Apple Pro Res 4444 codec has a bug, in that it does not appear to do the right thing if it is given an image that does not have an alpha channel. And there is no option in the codec UI to automatically add a fully opaque alpha channel. (It would be very nice to have that option.) When I layer two copies of the SAME resulting ProRes 4444 video on top of each other, and toggle visibility of the top layer On & Off -- they do not match! There is a brightness/contrast difference, which appears to be stemming from the alpha. For my 10 bit 444 source video, Pro Res 4444 was less lossy than "Uncompressed", "None", and "Animation". "Lossless" QT codecs appear to only be lossless for 8 bit video, not anything above 8 bits. Ditto for 444 video ... where even "Uncompressed" is quite lossy. Both were rather jarring surprises. -- Brian This email sent to hd444(a)mac.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: how trims & cuts effect reference image wells
by Darrin Cardani 11 Aug '09

11 Aug '09

site_archiver(a)lists.apple.com Delivered-To: Pro-apps-dev(a)lists.apple.com Let me know if you have any questions. Here's the plugin I used: Darrin On Aug 7, 2009, at 10:55 AM, Brian Gardner wrote: I'm tryng to get my head around what happens to a FxPlugin (especially a generator) when it is trimmed or cut inhalf then it's parts are moved around on timeline. And what a plugin which has reference image parameter(s) should/could do to appropriately update itself. I would assume the FCP 7 will make a copy of the generator (or clip+filter), then make two API method calls, to which our plugins can optionally respond: My plugin should respond to these two methods, and update it's internal state for accessing the appropriate frame ranges of it's reference image parameters to meet the new post-cut state of the edit. Is my assumption anywhere near correct? If so, what are those FxGenerator 2 methods to which my FxPlug should respond? If not, how does it really work? And how should/can my generator respond to a cut edit, so that it can appropriately access it's reference image parameters? -- Brian _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/dcardani%40apple.com -- Darrin Cardani dcardani(a)apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com Brian, The way you suggest it should work would be a good design. However, that's not how it works currently. :( Paul's out on vacation, and he'd have a better idea of how it works in FCP, but I'll go over what Motion does. I believe that FCP does basically the same thing, but am not positive. An image well is a parameter like any other. When you change the clip duration or the start point, you change the value of the parameter, so the host app will ask your plugin to re-render, just as if the user changed the value of a slider or checkbox. It should first call your plugin's -parameterChanged: method with the ID of the image parameter, but upon testing, I've discovered that it does not (at least in Motion - you should try in FCP). This is a bug you should write up. So all your plugin knows is that something changed and it should rerender. One way you can track what's changed is by caching the image in the image well's start time and duration. In your -renderOutput: method, you can use the FxTimingAPI to see if the image parameter's start time or duration is different from your cached value and do the appropriate thing if it's changed. It's not as convenient as getting a -parameterChanged: message, or a notification directly, but it should be workable. ImageWellChangeTester.zip 1.) a method invoked to the original generator passing it the old and new duration. (to the 1st half of cut object) 2.) another method invoked to signal the new copy of the generator, passing it the old and new relative start frame offset. (to the 2nd half of the cut generator) This email sent to dcardani(a)apple.com

1 0

Re: markers on nested sequences in XML import
by Rainer Standke 11 Aug '09

11 Aug '09

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Hello all, Rainer On Aug 10, 2009, at 15:53 , Helena Ju wrote: Hi Rainer, Hope that helps! Regards, Helena On 2009-08-09, at 11:33 AM, Rainer Standke wrote: Hello, To reproduce: Can't try this myself on FCP 7 - yet. Thanks, Rainer _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/hju%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… thanks for everyone's help. I found the culprit, and to a certain degree it my foot inside my mouth. What I was doing was adding the marker xml as a child of the clipitem that represents the nested sequence. It turns out that markers get ignored there - which I find slightly surprising, to say the least. That place works for regular cliptitems that are not nested sequences, I fully expected the nested sequences to behave the same way. Turns out the place to put the markers that go on clipitems that are nested sequences is at the top level of the nested sequence. Which also means they would show up as sequences markers if that sequence weren't nested into another sequence. >From my simple test in FCP 7.0 (regardless of whether I export just the mother sequence or the whole project) a marker on the mother sequence, another on the nested sequence, and another on the clip within the nested sequence exported and imported with all 3 markers coming back into the correct locations. can anyone confirm that markers on nested sequences get ignored when importing an XML file? This is what I am seeing in FCP 6.0.6. - nest a sequence in a sequence. - put a marker on that sequence (on the nested clip, not the mother sequence) - export mother sequence as XML - reimport XML This email sent to hju(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: Testing with lossless codecs
by Andreas Wittenstein 11 Aug '09

11 Aug '09

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Brian, http://www.bitjazz.com/sheervideo/ Andreas Wittenstein BitJazz Inc. http://www.bitjazz.com/ On 2009 Aug 10, at 12:44 , Brian Gardner wrote: Thanks, Darrin. There appears to be no way to test my plugins using a lossless QuickTime codec. _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… Animation and None are 8-bit RGB[A] codecs. If you need an RGB[A] QuickTime codec with 10 bits of precision per channel, try Sheer RGB[A] 10bf. It's only free for the first 20 days of use, but it's truly lossless, it's really fast, and it's cross-platform. I tried the Difference matte technique you suggested to test a number of QuickTime codecs, including the Animation codec. None of them were lossless. Actually, it's kind of scary that QuickTime does not have a single codec that is completely lossless... even the "uncompressed" were lossy. I used a 10 bit DPX 1920x1080p 24.0 fps sequence as source footage, which I've just received from a recent music video shoot, shot on a stage. The goal is to convert it into a single QuickTime ".mov" file, with lossless compression (or even no compression). I couldn't achieve that goal. Here are the codecs that I tested: Animation (at best setting) - truncates off the bottom 2 bits (10 bit - > 8 bit), which is lossy. None - Exact same results as Animation. 8-bit only. truncated bottom 2 bits. Lossy. (Differencing the Animation and None codecs to each other gives 0's-- exact match.) FCP Uncompressed 422 10 bit - differences at all edges (to be expected, 444->422 issue) DNxHD 10 bit 709 - Noisiest of these codecs. (Noisy into top 8 bits.) Blocking artifacts, especially in the vertically oriented direction. Lossy. Apple Pro Res HQ - slightly noisier than FCP Uncompressed 422, but similar 444->422 lossy results. Apple Pro Res 4444 codec - least lossy of the codecs I tested. Appears to have saved full 10 bits. (Did not just truncate down to 8. Possibly can do 16->16 bit?) Noisy in bottom bits, though. Lossy. NOTE: The Apple Pro Res 4444 codec has a bug, in that it does not appear to do the right thing if it is given an image that does not have an alpha channel. And there is no option in the codec UI to automatically add a fully opaque alpha channel. (It would be very nice to have that option.) When I layer two copies of the SAME resulting ProRes 4444 video on top of each other, and toggle visibility of the top layer On & Off -- they do not match! There is a brightness/contrast difference, which appears to be stemming from the alpha. For my 10 bit 444 source video, Pro Res 4444 was less lossy than "Uncompressed", "None", and "Animation". "Lossless" QT codecs appear to only be lossless for 8 bit video, not anything above 8 bits. Ditto for 444 video ... where even "Uncompressed" is quite lossy. Both were rather jarring surprises. -- Brian This email sent to site_archiver(a)lists.apple.com

1 0

Re: markers on nested sequences in XML import
by Helena Ju 10 Aug '09

10 Aug '09

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Hi Rainer, Hope that helps! Regards, Helena On 2009-08-09, at 11:33 AM, Rainer Standke wrote: Hello, To reproduce: Can't try this myself on FCP 7 - yet. Thanks, Rainer _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/hju%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… >From my simple test in FCP 7.0 (regardless of whether I export just the mother sequence or the whole project) a marker on the mother sequence, another on the nested sequence, and another on the clip within the nested sequence exported and imported with all 3 markers coming back into the correct locations. can anyone confirm that markers on nested sequences get ignored when importing an XML file? This is what I am seeing in FCP 6.0.6. - nest a sequence in a sequence. - put a marker on that sequence (on the nested clip, not the mother sequence) - export mother sequence as XML - reimport XML This email sent to hju(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: FYI iTunes/FCP bug
by Helena Ju 10 Aug '09

10 Aug '09

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Hi Martin! Thanks, Helena On 2009-08-10, at 1:44 PM, Martin Baker wrote: Martin Baker www.digital-heaven.co.uk www.twitter.com/digitalheaven www.videospaceonline.com www.finalcutters.com www.funkycloud.com/lifeshaker ------------------------------------------------------ Digital Heaven Ltd is registered in England and Wales Company registration number: 3628396 Registered address: 55 Lynwood Drive, Worcester Park, Surrey KT4 7AE VAT registration number: GB 736 0989 03 _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/hju%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… Thanks for the heads up. Yes, anything you drag over any of the FCP UI, we'll look at and try to import. Why wait for the drag-drop? I agree it is gross. If you can send me the bug number I'll gladly comment it so the ITunes guys don't have to puzzle over it. I've just filed a report on this and while I guess there probably aren't too many other developers using iTunes and FCP together it might be useful to have on record. For a while, we've had an issue with our Loader product where dragging a track from iTunes onto Loader results in FCP misbehaving during playback. The playhead doesn't move and the timecode display and audio meters don't update. This only happens from iTunes - dragging a file from the Finder onto Loader is perfectly fine. Interestingly, dragging a source clip from Browser to Viewer always seems to reset FCP and cures the issue. Double-clicking a source clip to load it into the Viewer does not reset FCP in the same way and the issue remains. So after much head scratching and going around in circles, in desperation I just wondered what would happen if I moved the Loader window to my right monitor. Success. This time dragging a track from iTunes didn't cause these playback issues. What's different? I don't have FCP windows on my right monitor... So it turns out that dragging an track from iTunes anywhere over the FCP UI causes this issue and by its design, Loader is designed to sit over the Browser window. So every single time users were dragging from iTunes to Loader, they were crossing the FCP UI and firing the problem. Cue huge forehead slap! This email sent to hju(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: Testing with lossless codecs
by Darrin Cardani 10 Aug '09

10 Aug '09

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Darrin On Aug 10, 2009, at 12:44 PM, Brian Gardner wrote: Thanks, Darrin. There appears to be no way to test my plugins using a lossless QuickTime codec. -- Brian On Aug 10, 2009, at 10:08 AM, Darrin Cardani wrote: On Aug 3, 2009, at 9:38 AM, Dan DiPaola wrote: Darrin -- Darrin Cardani dcardani(a)apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/brianrg%40earthlink.net _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/dcardani%40apple.com -- Darrin Cardani dcardani(a)apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… Brian, You might look for the 3rd party Microcosm video codec (I think from Red Giant these days). It is intended for compressing 16-bit per channel video losslessly. I see that BitJazz's Sheer Video is also lossless, but I don't know if it works with 16-bit per channel video. A little Googling would have revealed these solutions to you. I tried the Difference matte technique you suggested to test a number of QuickTime codecs, including the Animation codec. None of them were lossless. Actually, it's kind of scary that QuickTime does not have a single codec that is completely lossless... even the "uncompressed" were lossy. I used a 10 bit DPX 1920x1080p 24.0 fps sequence as source footage, which I've just received from a recent music video shoot, shot on a stage. The goal is to convert it into a single QuickTime ".mov" file, with lossless compression (or even no compression). I couldn't achieve that goal. Here are the codecs that I tested: Animation (at best setting) - truncates off the bottom 2 bits (10 bit - > 8 bit), which is lossy. None - Exact same results as Animation. 8-bit only. truncated bottom 2 bits. Lossy. (Differencing the Animation and None codecs to each other gives 0's-- exact match.) FCP Uncompressed 422 10 bit - differences at all edges (to be expected, 444->422 issue) DNxHD 10 bit 709 - Noisiest of these codecs. (Noisy into top 8 bits.) Blocking artifacts, especially in the vertically oriented direction. Lossy. Apple Pro Res HQ - slightly noisier than FCP Uncompressed 422, but similar 444->422 lossy results. Apple Pro Res 4444 codec - least lossy of the codecs I tested. Appears to have saved full 10 bits. (Did not just truncate down to 8. Possibly can do 16->16 bit?) Noisy in bottom bits, though. Lossy. NOTE: The Apple Pro Res 4444 codec has a bug, in that it does not appear to do the right thing if it is given an image that does not have an alpha channel. And there is no option in the codec UI to automatically add a fully opaque alpha channel. (It would be very nice to have that option.) When I layer two copies of the SAME resulting ProRes 4444 video on top of each other, and toggle visibility of the top layer On & Off -- they do not match! There is a brightness/contrast difference, which appears to be stemming from the alpha. For my 10 bit 444 source video, Pro Res 4444 was less lossy than "Uncompressed", "None", and "Animation". "Lossless" QT codecs appear to only be lossless for 8 bit video, not anything above 8 bits. Ditto for 444 video ... where even "Uncompressed" is quite lossy. Both were rather jarring surprises. II have found that "NONE" does a fairly good job of holding a color space. ... most of all no artifacts. If and when my gamma or saturation shifts I do a compensation pass on the front end. I need all the color gamut I can possibly get with ABSOLUTELY no artifacts. We encode for Blu-ray, any artifacting will make itself known on a 60' screen after we compress the HD down to 18Mbs. If there is even so much as a hint of color banding or posterization I will amplify it by a factor of two or more depending on the motion and colors used in the shot. I do not believe Animation is a truly and completely lossless codec. The Animation codec absolutely is a truly and completely lossless codec when set to Best temporal and spatial quality. If you find that not to be the case, it's a bug. You can do a simple test by compressing some footage with it, opening up the compressed footage and placing it over the original footage and setting the blend mode to Difference. If there are any pixels which are not 0, then it's not lossless. (And if that's the case and you're sure you've set it to Best quality, then it's a bug.) This email sent to brianrg(a)earthlink.net This email sent to dcardani(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

FYI iTunes/FCP bug
by Martin Baker 10 Aug '09

10 Aug '09

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date :x-mailer; bh=DqEs0pJQWHAc0WNd0GbtNVsbbAHHkgLEPzf7AxsiHbo=; b=XWmYr7Qwe2rGFK5UNe+pfYVk3jQaj6oCfu8iy7lD4XUFXG0z6Lv0IW33FOSiRmXNd3 DZ0D+VL3jULKfyyQzfPOUbxGqLHTSkY8A2gfJij+sNfrxH2h2CdLQPlsWXRmKi9T7iYC k590EkdRnXmHmocfyMulj+jynS8AUKFSdNnp8= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:x-mailer; b=EfIFMtZNB6GX6Ptd7OAsLLJtxulRYblBJJd1biXl2oLb6Id5R/2Tv3DeoUCxNx07x9 PnEHBO6nkRaPLNDDTFlD0700OK5E4RaEX2rat7LdM98MHnMtpf+p4C8XOcWtpVBNKWO7 95gnxhZCA+zyg8NRS/FDpioDn1EDt6hvaGLpE= Martin Baker www.digital-heaven.co.uk www.twitter.com/digitalheaven www.videospaceonline.com www.finalcutters.com www.funkycloud.com/lifeshaker ------------------------------------------------------ Digital Heaven Ltd is registered in England and Wales Company registration number: 3628396 Registered address: 55 Lynwood Drive, Worcester Park, Surrey KT4 7AE VAT registration number: GB 736 0989 03 _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… I've just filed a report on this and while I guess there probably aren't too many other developers using iTunes and FCP together it might be useful to have on record. For a while, we've had an issue with our Loader product where dragging a track from iTunes onto Loader results in FCP misbehaving during playback. The playhead doesn't move and the timecode display and audio meters don't update. This only happens from iTunes - dragging a file from the Finder onto Loader is perfectly fine. Interestingly, dragging a source clip from Browser to Viewer always seems to reset FCP and cures the issue. Double-clicking a source clip to load it into the Viewer does not reset FCP in the same way and the issue remains. So after much head scratching and going around in circles, in desperation I just wondered what would happen if I moved the Loader window to my right monitor. Success. This time dragging a track from iTunes didn't cause these playback issues. What's different? I don't have FCP windows on my right monitor... So it turns out that dragging an track from iTunes anywhere over the FCP UI causes this issue and by its design, Loader is designed to sit over the Browser window. So every single time users were dragging from iTunes to Loader, they were crossing the FCP UI and firing the problem. Cue huge forehead slap! This email sent to site_archiver(a)lists.apple.com

1 0

Re: Testing with lossless codecs
by Marijn Eken 10 Aug '09

10 Aug '09

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0