How to fetch frame rate of a project item?

[meett9325076]

Hello All,

Can anyone tell me how would I get frame rate of a project item? I couldn't find it in the Premiere Pro API: Samples/api_doc.html at master · Adobe-CEP/Samples · GitHub

Premiere Pro Version: 9.0.0
Extension Type: Panel

Thanks & Regards,
Meet Tank

[e_d_]

Hi Meet,

you can find technical metadata like frame rate in a projectItem's projectMetadata and/or XMPMetadata.

[meett9325076]

Thanks e.d. I can see the frame rate in below field of project metadata:

<premierePrivateProjectMetaData:Column.Intrinsic.MediaTimebase>25.00 fps</premierePrivateProjectMetaData:Column.Intrinsic.MediaTimebase>

Could you please confirm the field to be used?

Thanks,
Meet

[e_d_]

Hi Meet,

this is what you're looking for.

Unfortunately Premiere's metadata doesn't seem to contain any information what the timecode base is, which is not critical when worming with straight frame rates only, but when working with 29.97 or 30-drop (or 23.978, or 59.94, yada yada...) and you need to perform timecode-related operations, your results might be off point.

[Bruce Bullis]

Let's say we were nice and gave you the frame rate of the projectItem; how/where would you use that information?

Would you want the source frame rate, or the frame rate after PPro's footage interpretation had been applied?

[meett9325076]

I couldn't understand "the frame rate after PPro's footage interpretation". I want the frame rate of a project item which I imported in premiere pro.

[Bruce Bullis]

Footage has a frame rate, before it's brought into PPro.

PPro can apply a footage interpretation, which changes the frame rate for that projectItem, when used within PPro.

So, even if we gave you the original frame rate, you still wouldn't be able to match PPro's interpretation.

Again: If you had the frame rate info you wanted, how would you use it?

[sberic]

Bruce Bullis wrote

Footage has a frame rate, before it's brought into PPro.

PPro can apply a footage interpretation, which changes the frame rate for that projectItem, when used within PPro.

So, even if we gave you the original frame rate, you still wouldn't be able to match PPro's interpretation.

Again: If you had the frame rate info you wanted, how would you use it?

Going out on a limb here, but my guess would be that meett9325076​ would like to use the framerate to create a function that would help him calculate Marker positions in the timeline.

Per-ProjectItem versions may also be of interest as Clips can have their own internal markers, correct?

[meett9325076]

sbericsbericsberic's assumption is correct. I want to use the frame rate to find out deviation and use this to compare marker's start and end time.

Thanks,

Meet

[Sven Akelian]

I see many use of framerate in the SDK, the one that come to mind right ahead:

     - The API returns in and out points in seconds, having the frameRate (footage one not interpreted) allows for frame calculations for instance.

     - If one is trying to build a bridge script between premiere and another software having both the interpreted and original framerate easily accessible is trivial

     - to check and report mixed framerate timelines

and many many more...

I personally use a quite long XMP Property check to retrieve the framerate from that as it seems each camera handles it differently

I think something along those lines could be really useful:

clip.projectItem.getFrameRate()

or

clip.frameRate

[Bruce Bullis]

I think what you'd want in those cases is PPro's current _interpretation_ of the file, not the file's intrinsic frame rate, right?

[Sven Akelian]

I think both are valuable and might need separate property names.

I see so much potential in the scripting environment of premiere can't wait for more accessibility

[Bruce Bullis]

When might you need the source frame rate, and not PPro's interpretation of it?

Sven Akelian

I see so much potential in the scripting environment of premiere can't wait for more accessibility

No need to wait! There are literally hundreds of panel-driven workflows publishing video, every day.

[Sven Akelian]

I have to recheck then, my last attempt was a big frustration because it was lacking editing an api.

The doc is still as sparse it seems ? Some guides on github, some blog post etc etc... But no official JS API doc right ?

I just discovered the object model viewer of extendscript pretty neet!!

[Sven Akelian]

Many... for instance to know if the file was or not interpreted by premiere.

https://forums.adobe.com/people/Bruce+Bullis  wrote

When might you need the source frame rate, and not PPro's interpretation of it?

[Bruce Bullis]

Ok, but...what specific behavior on your part, would having BOTH pieces of info, enable?

"Hey, The file says , but PPro's interpretation says !"

Presumably, the user has applied that interpretation for a reason; if your panel is acting based on the file's intrinsics, rather than on characteristics the user has gone to the trouble of applying to the media, what (desirable) use cases require that you also know the intrinsics?

[Sven Akelian]

I just think the api should have such basic properties, whatever the reason it's valuable information.

One example: some cameras (Arri for instance) can record 50fps shot as 25fps "pre" interpreted files. Knowing if the file was or not altered inside premiere is useful.

I've succesfuly built a Premiere to Nuke bridge that sends selected shots to nuke if the shot was altered.

I want to add a Retime node in nuke for instance, allowing me to keep timecodes in sync between apps in a controllable manner.

Do you know also if there is a plan to add AE like clipboard functions to premiere (behing able to copy anything (keys,footages...) to readable clipboard ?

As for the original question of the post (where i is your project​Item):

var pxmp = new XMPMeta(i.getProjectMetadata())
            if (pxmp.doesPropertyExist(kPProPrivateProjectMetadataURI, 'Column.Intrinsic.MediaTimebase') == true) {
              frameRate = pxmp.getProperty(kPProPrivateProjectMetadataURI, 'Column.Intrinsic.MediaTimebase')
              frameRate = parseFloat(frameRate)
            }

[Bruce Bullis]

> ...the API should have such basic properties...

As a logic professor once told me (loudly, in front of the whole class),"Should" only makes sense in the realm of moral philosophy.

We understand why you'd want to get PPro's interpretation of project media; I have yet to hear a compelling use case for getting both PPro's interpretation of media, as well as some sort of "unmodified" interpretation of that media, through the PPro API, although your "check whether an interpretation has been implied" makes some sense. If your panel understands a given format, you're welcome to get the path from PPro and sniff the original media yourself.

We have no plans to make PPro's clipboard handling emulate AE's.

I'd agree that hiding the media time base in a projectItem's XMP is annoying, and that getting it, along with all other available footage interpretation, would enable much better awareness, by panels.

[Sven Akelian]

Ahaha when I said should it was more like:

     - your making a great media editor and provide functions to devs, why limit the direct access (thought object properties) to metadata ? (real question not rhetorical)

I have done just that: I use mediainfo to gather all the necessary media infos which I compare to the project item metas.

As for the reason I think I've just explained in the previous post one of the use case.

If you want to step out of the adobe ecosystem for finishing for instance it's important to have the proper datas.

XML, EDL and such are great but having messed around the API for a week I was able to find better ways to transfer edit back and forth, send it to scratch for conformation (EDL based but again using the API I can customise how it is generated (One EDL per tracks, with detailed notes about the effects used)...)

meett9325076​: I think post #16 "should" (ahaha) be the accepted answer (for others to find it when googling)

Thanks for the follow up Bruce Bullis​