Export Movie Sequence vs JSFL

[MRocchio]

Hi There,

Interesting one when it comes to exporting PNG sequences out of Animate:

Animated Test FLA - 128fr

1. Export Movie Seq(manual export) - Completed rendering test scene in 3mins - all 128fr

2. Publish via JSFL using dom.exportPNG - 3 FRAMES RENDERED in 3 Min - just under 2 hours to render

3. Grabbed another publish program i found online and outcome was the same. Confirms our code is not the issue. Or both pieces of code have the same issue

What we are seeing is that Exporting a Movie Sequence is 1000 times more efficient when Rendering out then what we can do with JSFL.

Can anyone tell me why? Also..can we write to the export function via JSFL ?

Any comments are appreciated.

Mark

[arao2k6]

Hi Mark

Can you share the script you are using to export the movie. A sample fla and script would be great to repro it at our end.

Regards

Avinash

[MRocchio]

Thnxs for reply.

I provided the material requested to Adobe support. I can provide again, but the material is for broadcast and I would need to ensure all material stays within the intended parties.

Let me know how you would let me to proceed..

Thnxs,

Mark

[Mohanaraj]

Thanks Mark, will check with the Support team on this.

Thanks!

Mohan

[MRocchio]

Here is the specs of one of the systems rendering out Flash: win 7, XEON, 12 core with 28GB...

We should be flying thru these FLAs.

M

[MRocchio]

Here is an image of the folder structure showing how long this beast of a system takes to render the FLA.. 1 frame every 2 min

[arao2k6]

Hi Mark

Got the files from support team. Publish profile profileflash10as3.xml is missing in the zip.

Can you share the same as well.

Thanks!

Avinash

[MRocchio]

here it is..we do not use it as this is what you would call if you used Publish via the file menu...we call publish via jsfl..

may be a red herring for you, but here it is..

Adobe Issues - Test FLA - Google Drive

Let me know if you have any issues..

Personally, i would review your render engine(s) in Flash instead of this. I've tested the test FLA with multiple JSFL export PNG sequ scripts and the speed is the same when calling via JSFL. no matter the script. What I would do if i were you is confirm the speed issue calling export via jsfl. Write a small script and see for yourself how slow it is. Then do the Export->Movie->PNG Sequence and you will see how much faster exporting via the menu is compared to the JSFL call. And it is FLASH that hangs when exporting via JSFL. It just sits there not responding, then kicks back in. Does not use all RAM (28GB!) and the PROC is not pinned. this points to how FLASH exports via the jsfl calls...

Thnxs for staying on this...

M

[arao2k6 · Accepted solution]

Thanks Mike for the file. We are able to see a drop in performance while exporting through JSFL compared to export from UI. We will investigate it further and keep you updated.

Thanks for your time.

Regards

Avinash

[MRocchio]

Thnxs Avinash...

Please keep me posted.

Mark

[MRocchio]

Hi Avinash,

I know its only been a few days, but this is starting to come to where I need a render box for every scene in the render q. some shots are taking 6-7 hours...

Its getting to be a production killer and there is a line where i will need to either decide to add many many many many more boxes due to the bug, or just move to Harmony.

Just want you to understand the wrench this bug/issue is causing.

Mark

[MRocchio]

This has been noted as a BUG..i suspect based on the last bug I found fl.quit(false) this will take a year or so to fix...

Doh! production killing bug..

[MRocchio]

Hi There,

any update on this bug?

Mark

[Mohanaraj]

Hi Mark,

We are working on it and will update you as soon as we have a fix in place.

Thanks!

Mohan

[Mohanaraj]

Hi Mark,

While we are looking into this, we found a possible workaround that may help you in the interim:

Instead of calling exportPNG in loop, call exportPNG for entire sequence at once. This is controlled by the last argument to exportPNG.

i.e. doc.exportPNG( pngFile, true, false);   // last argument false means export entire timeline as a png sequence

In a nutshell the following code needs to be replaced (there is a loop & last argument to exportPNG is true):

for (var i=0;i<timeline.frameCount;i++) {

     timeline.currentFrame = i;

      pngFile = strTarget+pad(i + 1)+'.png';

      //debug(pngFile);

      doc.exportPNG(pngFile,true,true);

      iFrameLength++;

}

Modified jsfl script is posted at Adobe Creative Cloud  for your reference. Please watch out for png naming convention while trying this workaround.

Thanks!

Mohan

[MRocchio]

Hi Mohanaraj,

I tested on the system that i used to detail this issue, so i had that result to compare render times and this is what I found:

All same FLA

1. 129 fr FLA Tested Jan 3rd - 44 Min - 2fr/min(with the odd 3 fr/min)

2. 129 fr FLA Tested Feb 6 - WITH ADOBE FIX - 4Min to Render - Yee friggin hawww!

3. Retested 129fr FLA from Jan 3rd test - Original code - 44 min - Same outcome as Jan 3rd test

Knocking 40 mins off render time! I'm going to test on multiple FLAs and systems tomorrow.

Nice work..

Yippie!

Mark

[Mohanaraj]

Thanks for the update Mark and I'm glad that it helped.

[MRocchio]

One thing I will track down tomorrow is with the fix,  the export is no longer exporting as per stage size..not sure where the dimensions are coming from at the moment.

[MRocchio]

Hey Guys,

It is a fix and it is not. It does render faster but this new render does not render as per stage size. So we are getting different PNGs sizes depending on scene..its inconsistent.

What is this export using to decide on what the size of the PNGs are? In the UI side we get another window asking export size....

We tried calling a profile to dictate 1920x1080, that did not work either. ExportPNG seems to ignore the format in the profile and we cannot find anywhere else to have the export well, export the stage...

So its a fix that opened a new issue. We cannot use this until we can control the output...

Let us know if there is anything else we can do to have your new export function with the ability to read the stage size as per the UI..

Quick edit: Our stage size is 1920x1080 for HD broadcast.

I'm taking a guess here but export may be dictated in this process by the biggest asset in the library.  We have different size BGs depending on camera/fielding..and it could be coincidence, but each output of PNGs match the size of the BG..

M

[Mohanaraj]

Hi Mark,

Seems like the second argument doesn't function as intended. The second argument is to specify whether the current settings should be used for export(true) or UI should be populated to enter the settings(false). I'll check where it is going wrong.

Thanks!

Mohan

[MRocchio]

Hi Mohan,

Just checking in!

Any progress? Ready for me to test!!?

M

[MRocchio]

Hi There,

There is a rumor that the fix will be included in the March update. Can you confirm this? March is tomorrow!! Hoping the release is Mar 1st and not Mar. 29!

Let me know what's the latest please.

M

[Mohanaraj]

Hi Mark,

I can tell you that the fix is identified and validated internally and will be included in the upcoming release. Please PM me for more details.

Thanks!

Mohan

[MRocchio]

Hey Gang,

Update from the user side on the prerelease.

Renders are much faster..Adobe seems to have fixed the Publish issue via JSFL - BUT - another issue was introduced. If you use fl.quit() the prerelease will crash. We ran the script on 2015 and 2014 with no issues. We in turn rewrote how we close Flash after render. So, if you are using fl.quit() in your script please let us know if you are experiencing the same issue with fl.quit() crashing Flash. We REM out fl.quit() for the prerelease and the system does not crash..

At least I have renders working at an acceptable speed.

Thnxs,

M

[MRocchio]

Another issue we found is when Animate displays a dialog window with say a font issue, but you hit the checkbox to not display again...it displays again and stops the script