Get sequence start from Transmit API

Hi Jon,

Such a call isn't available yet, but we've had a request for this and are tracking it as bug #3218723.

Cheers,

Zac

For automation purposes you may want to also implement reading any XMP sidecar file that exists. That has the timecode of the capture in it.

- a good example is to export H.264 in AME/PPro. the resulting xmp/xmpses file has the xmp fields of interest. Open it with WordPad (coz that understands Unicode) and you'll see a XMP:RDP packet like this:

    <stCap:CaptureTimecode>

        <rdf:Seq>

            <rdf:li rdf:parseType="Resource">

                <rdf:value rdf:resource="Capture"/>

                    <stCap:index>0</stCap:index>

                    <stCap:time>00:07:01:13</stCap:time>

                </rdf:li>

            </rdf:Seq>

    </stCap:CaptureTimecode>

    <stCap:NCapture>1</stCap:NCapture>

</rdf:Description>

You can read/write/modify XMP embedded in source files or in sidecar xmp files for sources that can't embed XMP using the Adobe XMP Toolkit.

http://www.adobe.com/devnet/xmp.html

regards

Rallymax.

it would be whatever the timestamp is in the src footage, so no; it's not the sequence nor clip timecodes.

at a higher level - is it even possible for the sequence object to start at non-zero?

if you're making an exporter the sequence start time will be the source start and end times that you can read during exExport.

Hey Jon - New in 6.0.2, just released, the sequence start time and timecode droppedness are available through the sequence info suite.

Here's a link to the updated header file:

https://acrobat.com/#d=j60W3ttl3zTNIYusKY2cSA

hi all,

Always great to see new information in the selectors. great work.

But, this does then assume that your plugin will check to see what version it's running on. For current and future this is great but for backward compatibility to CS5, CS5.5, CS6.0.0, CS6.0.1 - which you have to assume is the majority of the market - it won't work. So if your plugin in non-commerical it's fine but if it is commercial you need to check. Will you get back an error when you try to use this new mechanism on < 6.0.2?

thx

thx. my post was more of a cautionary tale for those who have not needed to think about backward compatibility.

For example, betwen CS4 and CS5 the Source frameRate went from float64 fps to int64 ticks.

nothing wrong with the change - in fact it was a good thing - but it does come back to haunt you when you develop against the newest CS and then hope that it'll work on CS n-1 and n-2 etc.

The sames goes the for the Suites. If you blindly use the non-versioned label it'll always point to the current version in the SDK. eg memory suite 2,3,4. If you don't explicitly open them with the version number after detecting the app version in PrSDKAppInfoSuite then you'll fail to get those suites too.

as I said, the only reason I posted was as a cautionary note for those who have not dealt with multiple versions of the App.

Acrobat.com has been updated, so here's the updated link to the header file:

https://workspaces.acrobat.com/?d=j60W3ttl3zTNIYusKY2cSA

That's it.  A developer in a different thread mentioned the link was broken so I just posted the updated link.