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

Re: aux time code
by Rainer Standke 14 Aug '08

14 Aug '08

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Hi Helena, My 2 cents, Rainer for full control, on both existing and non-existing TC tracks, there should be a flag that you can turn on and off and that decides if file or XML wins. This could work like the updatebehaviour flag for QT metadata. In the latter case the actual Quicktime files should be changed/overwritten. I don't see the use or benefit of a situation where you have one TC assigned to a clip in the QT file, and another one in FCP. That is bound to become a problem later on in people's workflows. In other words, I would like to see an optional behaviour where the TC in the Quicktime does get overwritten. That flag should off course default to off, or file wins, and maybe there should be a warning in the user interface upon import. P.S. What should I expect to see when I import clips with all 3 timecodes and have them batch capatured? Will the aux TCs from the XML migrate into the Quicktime file? _______________________________________________ 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

Re: FCP preferred video time scales changed?
by mike woodworth 14 Aug '08

14 Aug '08

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com The following media files are not optimized for FCP. It is highly recommended that you either recapture the media .... mike -- Mike Woodworth mike(a)divergentmedia.com On Aug 13, 2008, at 8:33 PM, Paul Schneider wrote: Hi Mike, Thanks, Paul mike -- Mike Woodworth mike(a)divergentmedia.com On Aug 11, 2008, at 1:59 PM, Mike Woodworth wrote: Hello, mike -- Mike Woodworth mike(a)divergentmedia.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/pschneider%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… sorry, I'm speaking of the "media performance warning" ... the dialog text is: and then there is a list of all the media I just drag and dropped on the browser. I had worked around this once before, and was under the impression http://developer.apple.com/qa/qa2005/qa1447.html covered all the requirements to not see this warning, but my media is all different timescales - all from this list. Can you be more specific about the warning you're seeing? What exactly does the dialog say? On Aug 13, 2008, at 12:37 PM, mike woodworth <mikelists(a)divergentmedia.com > wrote: So I've looked more, and it seems that the timescale wasn't the cause of this problem. I was confused because it appears the same clip will only sometimes be flagged with this warning. I can't see anything different between my media and that directly captured in FCP. Is it documented anywhere what all FCP is checking when it qualifies imported media? I'm still looking into this report form our users, but at first glance it seems Final Cut Pro has begun to show a warning when importing media with a video timescale/sample duration of 30000/1001. Has something changed since http://developer.apple.com/qa/qa2005/qa1447.html was first released? Was this changed on purpose, and do I need to change our app to output media with the less accurate 2997/100 values? It's possible something else is going on here, but a quick test with 30000/1001 media shows the warning, and changing the file to 2997/100 in dumpster fixes it. This email sent to pschneider(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: FCP preferred video time scales changed?
by Paul Schneider 14 Aug '08

14 Aug '08

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Hi Mike, Thanks, Paul mike -- Mike Woodworth mike(a)divergentmedia.com On Aug 11, 2008, at 1:59 PM, Mike Woodworth wrote: Hello, mike -- Mike Woodworth mike(a)divergentmedia.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/pschneider%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… Can you be more specific about the warning you're seeing? What exactly does the dialog say? On Aug 13, 2008, at 12:37 PM, mike woodworth <mikelists(a)divergentmedia.com > wrote: So I've looked more, and it seems that the timescale wasn't the cause of this problem. I was confused because it appears the same clip will only sometimes be flagged with this warning. I can't see anything different between my media and that directly captured in FCP. Is it documented anywhere what all FCP is checking when it qualifies imported media? I'm still looking into this report form our users, but at first glance it seems Final Cut Pro has begun to show a warning when importing media with a video timescale/sample duration of 30000/1001. Has something changed since http://developer.apple.com/qa/qa2005/qa1447.html was first released? Was this changed on purpose, and do I need to change our app to output media with the less accurate 2997/100 values? It's possible something else is going on here, but a quick test with 30000/1001 media shows the warning, and changing the file to 2997/100 in dumpster fixes it. This email sent to pschneider(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: aux time code
by Helena Ju 13 Aug '08

13 Aug '08

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

aux time code
by Rainer Standke 13 Aug '08

13 Aug '08

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Hello, 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/site_archiver%40lists.a… I am wondering about assigning an aux timecode to media, i.e. Quicktime files. Ideally I'd like to import an XML, and I know how to encode the timecodes ad aux TCs. When I then proceed to connect the media, the media's existing timecodes overwrite the TCs I was trying to assign in the XML file. Can that be avoided somehow? I have not tried batch capturing the clips yet, so I don't know if that would preserve any aux TCs from the imported XML. Obviously, the timecodes would survive. This email sent to site_archiver(a)lists.apple.com

1 0

Re: FCP preferred video time scales changed?
by mike woodworth 13 Aug '08

13 Aug '08

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com mike -- Mike Woodworth mike(a)divergentmedia.com On Aug 11, 2008, at 1:59 PM, Mike Woodworth wrote: Hello, mike -- Mike Woodworth mike(a)divergentmedia.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… So I've looked more, and it seems that the timescale wasn't the cause of this problem. I was confused because it appears the same clip will only sometimes be flagged with this warning. I can't see anything different between my media and that directly captured in FCP. Is it documented anywhere what all FCP is checking when it qualifies imported media? I'm still looking into this report form our users, but at first glance it seems Final Cut Pro has begun to show a warning when importing media with a video timescale/sample duration of 30000/1001. Has something changed since http://developer.apple.com/qa/qa2005/qa1447.html was first released? Was this changed on purpose, and do I need to change our app to output media with the less accurate 2997/100 values? It's possible something else is going on here, but a quick test with 30000/1001 media shows the warning, and changing the file to 2997/100 in dumpster fixes it. This email sent to site_archiver(a)lists.apple.com

1 0

Re: FxScript known limitation in MeasureString?
by Darrin Cardani 11 Aug '08

11 Aug '08

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com On Aug 4, 2008, at 4:31 PM, Andy Mees 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/site_archiver%40lists.a… Can you confirm that the maximum width that can be reported by FxScript's MeasureString function is 32767, regardless of the actual string length? Andy, I'm no expert on FxScript, but it appears that the text processing functions like MeasureString are just exposing the underlying Carbon functions of the same name. Those functions do indeed have a 32K limitation on their size. This email sent to site_archiver(a)lists.apple.com

1 0

FCP preferred video time scales changed?
by mike woodworth 11 Aug '08

11 Aug '08

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Hello, mike -- Mike Woodworth mike(a)divergentmedia.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… I'm still looking into this report form our users, but at first glance it seems Final Cut Pro has begun to show a warning when importing media with a video timescale/sample duration of 30000/1001. Has something changed since http://developer.apple.com/qa/qa2005/ qa1447.html was first released? Was this changed on purpose, and do I need to change our app to output media with the less accurate 2997/100 values? It's possible something else is going on here, but a quick test with 30000/1001 media shows the warning, and changing the file to 2997/100 in dumpster fixes it. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Width, Height, and Rowbytes in FxImage returning possible wrong values.
by Brad Wright 11 Aug '08

11 Aug '08

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Hi Darrin: Brad On Aug 10, 2008, at 9:46 PM, Darrin Cardani wrote: Darrin On Aug 10, 2008, at 9:41 PM, Brad Wright wrote: Thanksi Steve: Brad Wright On Aug 10, 2008, at 9:15 PM, Steve Christensen wrote: |<- 16 x width ->||<- 16 x width ->| |<----------- rowBytes ----------->| row 0 |<---- upper --->||<--- lower ---->| row 1 |<---- upper --->||<--- lower ---->| ... row 719 |<---- upper --->||<--- lower ---->| or this: |<- 16 x width ->||<- 16 x width ->| |<----------- rowBytes ----------->| |<--- upper ---->| row 0 |<---- lower --->||<--- upper ---->| row 1 |<---- lower --->||<--- upper ---->| ... row 719 |<---- lower --->||<--- upper ---->| On Aug 10, 2008, at 8:20 PM, Brad Wright wrote: Thanks Steve: Brad On Aug 9, 2008, at 11:45 PM, Steve Christensen wrote: On Aug 9, 2008, at 6:29 PM, Brad Wright wrote: [myBitmapImage width] == 720 [myBitmapImage height] == 240 [myBitmapImage rowBytes] = 23040 The image format is Float and 32 bit wide. -- 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… If it was two rows stacked in a single rowBytes, I'd see a different pattern in the image. In this case the image suppose to be 720 wide, but the actual pattern in the bytes shows that it 1440 wide. The width and height are inconsistent with what is actually contained in the image. It's reporting 720x240 in the FxImage for width and height, but actual contents the memory is consistent with 1440 wide. To test this, I ran a color bar test pattern across the image and the memory pattern is consistent with 1440 wide. If it were double stacked in a rowBytes you'd see a duplication of color bar information. In this case, I'm only seeing a 1/2 of the color bar pattern in the first 720 pixels. If it were row 1 and row 2, the entire color bar pattern would be contained in the first 720 pixels and it would repeat in the next 720 pixels for the next row. This isn't the case as far as I can tell. Brad, What is the field order of the images you are receiving? What are the width and height? Steve's analysis is correct. FCP will often point you to a bitmap which is as many bytes wide as 2 scan lines, one of which is an even field and one of which is an odd field. Actually, I did some analysis on the image being returned. I actually walk the image a for loop and the values are consistent with a 1440x1080 image. I did this by running creating test patterns for the image, so I can see where the values should line up in memory. In this particular case, the values are consistent with 1440 pixels wide and not 720. I'm testing with Final Cut 5.14 and the latest FxPlug API's. It certainly could be broken in this combination. No, you're assuming that 16 x width == rowBytes. That's not always true. What I was getting at was this: 23040 bytes works out to 1440 16- byte float pixels between the start of each succeeding row. Given that you're seeing an image size of 720 x 240 (half of 720 x 480), it looks like you have imageInfo.fieldOrder set to either kFxFieldOrder_UPPER_FIRST or kFxFieldOrder_LOWER_FIRST. (This is also likely the type of input and output images your plugin is being provided.) Thus the bitmap is laid out like this: The rowBytes value is set so that you're using every other line (or one field) of the overall image. You should only be working with the first 720 pixels (or 11520 bytes) on each line since the other half of the rowBytes -may- contain the other field's pixels or it may be uninitialized -- the implementation details are unspecified. That's why you have to respect both the image dimensions as well as the rowBytes: there may be bytes at the end of each row in the image you're processing that are supposed to be left alone. >From what I'm seeing math doesn't quite add up. The row bytes reports 23040 while the image format is 32 bit float. 32 bit float is 16 bytes wide. Therefore, 23040/16 is 1440 which is the width of the sequence settings. So, it looks like something is inconsistent. What value did you supply in imageInfo.fieldOrder? If it contains something other than kFxFieldOrder_PROGRESSIVE, the bitmap may actually contain the entire image, but rowBytes is set up so you only see the pixels in every other row. If that's the case, it's not an application bug since it's doing exactly what you told it to do. I'm seeing possibly wrong values for width and height in an FxImage. The problem happens when I export to a DVC Pro 25 NTSC movie from an HD timeline. My sequence is 1440x1080, and the exported image is 720x480. In the rederOutput function I retrieve the actual image using the temporal image API. if ([tempororalImageApi getInputBitmap:(FxBitmap **) &myBitmapImage withInfo:(FxRenderInfo) imageInfo atTime: (double) renderInfo.frame]==NO) { NSLog(@"Failed to retrieve the original Bitmap image\n"); return NO; } Here's the values I get: 23040 is the correct row bytes value for the image if it's at 1440 pixels wide. When I try to process the image using these values in my loop, I get only the first part of the actual image. So it appears that the image is actually 1440 wide instead of being 720 wide. Is this a know bug? Is there a workaround? _______________________________________________ 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 This email sent to dcardani(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: Width, Height, and Rowbytes in FxImage returning possible wrong values.
by Darrin Cardani 11 Aug '08

11 Aug '08

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Darrin On Aug 10, 2008, at 9:41 PM, Brad Wright wrote: Thanksi Steve: Brad Wright On Aug 10, 2008, at 9:15 PM, Steve Christensen wrote: |<- 16 x width ->||<- 16 x width ->| |<----------- rowBytes ----------->| row 0 |<---- upper --->||<--- lower ---->| row 1 |<---- upper --->||<--- lower ---->| ... row 719 |<---- upper --->||<--- lower ---->| or this: |<- 16 x width ->||<- 16 x width ->| |<----------- rowBytes ----------->| |<--- upper ---->| row 0 |<---- lower --->||<--- upper ---->| row 1 |<---- lower --->||<--- upper ---->| ... row 719 |<---- lower --->||<--- upper ---->| On Aug 10, 2008, at 8:20 PM, Brad Wright wrote: Thanks Steve: Brad On Aug 9, 2008, at 11:45 PM, Steve Christensen wrote: On Aug 9, 2008, at 6:29 PM, Brad Wright wrote: [myBitmapImage width] == 720 [myBitmapImage height] == 240 [myBitmapImage rowBytes] = 23040 The image format is Float and 32 bit wide. _______________________________________________ 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… Brad, What is the field order of the images you are receiving? What are the width and height? Steve's analysis is correct. FCP will often point you to a bitmap which is as many bytes wide as 2 scan lines, one of which is an even field and one of which is an odd field. Actually, I did some analysis on the image being returned. I actually walk the image a for loop and the values are consistent with a 1440x1080 image. I did this by running creating test patterns for the image, so I can see where the values should line up in memory. In this particular case, the values are consistent with 1440 pixels wide and not 720. I'm testing with Final Cut 5.14 and the latest FxPlug API's. It certainly could be broken in this combination. No, you're assuming that 16 x width == rowBytes. That's not always true. What I was getting at was this: 23040 bytes works out to 1440 16- byte float pixels between the start of each succeeding row. Given that you're seeing an image size of 720 x 240 (half of 720 x 480), it looks like you have imageInfo.fieldOrder set to either kFxFieldOrder_UPPER_FIRST or kFxFieldOrder_LOWER_FIRST. (This is also likely the type of input and output images your plugin is being provided.) Thus the bitmap is laid out like this: The rowBytes value is set so that you're using every other line (or one field) of the overall image. You should only be working with the first 720 pixels (or 11520 bytes) on each line since the other half of the rowBytes -may- contain the other field's pixels or it may be uninitialized -- the implementation details are unspecified. That's why you have to respect both the image dimensions as well as the rowBytes: there may be bytes at the end of each row in the image you're processing that are supposed to be left alone. >From what I'm seeing math doesn't quite add up. The row bytes reports 23040 while the image format is 32 bit float. 32 bit float is 16 bytes wide. Therefore, 23040/16 is 1440 which is the width of the sequence settings. So, it looks like something is inconsistent. What value did you supply in imageInfo.fieldOrder? If it contains something other than kFxFieldOrder_PROGRESSIVE, the bitmap may actually contain the entire image, but rowBytes is set up so you only see the pixels in every other row. If that's the case, it's not an application bug since it's doing exactly what you told it to do. I'm seeing possibly wrong values for width and height in an FxImage. The problem happens when I export to a DVC Pro 25 NTSC movie from an HD timeline. My sequence is 1440x1080, and the exported image is 720x480. In the rederOutput function I retrieve the actual image using the temporal image API. if ([tempororalImageApi getInputBitmap:(FxBitmap **) &myBitmapImage withInfo:(FxRenderInfo) imageInfo atTime:(double) renderInfo.frame]==NO) { NSLog(@"Failed to retrieve the original Bitmap image\n"); return NO; } Here's the values I get: 23040 is the correct row bytes value for the image if it's at 1440 pixels wide. When I try to process the image using these values in my loop, I get only the first part of the actual image. So it appears that the image is actually 1440 wide instead of being 720 wide. Is this a know bug? Is there a workaround? This email sent to dcardani(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0