Skip to main content
Brian_Raila
Brian_Raila
Inspiring
February 26, 2020
Question

ActionScript rm.callAS("multimedia_seek") Seeks to scene-change, rather than timepoint - BUG?

  • February 26, 2020
  • 1 reply
  • 5040 views

 

Here's a real head-scratcher.

 

In the attached files, one notes ActionScript calls to seek a timepoint in an RMA, then Play.

 

A Seek does, indeed, occur.  But in many trials, with many different video recordings, the buggy behavior is [to its credit] entirely, uniformly, consistent.  Follows my 'Findings of Fact':

 

  • With certain compliant video files, Acrobat's 'Seek' command operates in this manner:  The Seek lands on the first frame of a scene-cut [in the original source footage] immediately preceding the Seek timepoint, rather than the timepoint stipulated by the <rm.callAS("multimedia_seek")> command.

 

The first attachment utilizes encoded/compiled-in/enclosed video files [as well as two, secondary, networked examples], for their precise operation is most fully insured, being free of network entanglement and uncertainties.  The two compiled-in, Flash-dependent clips are identified by the default Flash Play icon being seen in lower-left of each.  A Seek is executed as follows:

 

/*  A variant of Joel_Geraci1 at Forum, 2-2-18 - and also from D. P. Story  */
var aRM = this.getAnnotsRichMedia(0); // var used to ID any Clip on first page (PDF document page# minus 1)
var rm = aRM[3]; // get rich media annot for The Clip [RM List Position# minus 1]
if ( !rm.activated ) rm.activated=true; // activate the Clip-annot 
rm.callAS("multimedia_seek", (12));
rm.callAS("multimedia_play"); // play The Clip
//

 

 

 

I don't aim to rattle the community, with rancor and hubbub concerning Adobe's upcoming End of Support for Flash Player.  I am a stalwart, 27-year company shareholder, customer, and developer, more interested in finding solutions to abundant, progressive, combined, forms of expression.  I am, with positive anticipation, initiating expertise with InDesign, and with Animate.  With regards to the company attending to my posted (presumable) bug, at this moment, Adobe "remain[s] fully committed to working with partners, including  Apple, Facebook, Google, Microsoft and Mozilla to maintain the security and compatibility of Flash content."

 

That first attachment speaks to 'Flash content', for which support remains committed.

 

 

But, furthermore, the company explicitly states that moving beyond the year 2020, in re Acrobat, and Reader:

  • Playback of non-Flash media (excluding *.flv and *.swf) content in PDFs will continue to be supported.
  • Converting Office or HTML to PDF with embedded rich media (non-Flash content) will continue to be supported.
  • Inserting or embedding rich media (non-Flash content) in PDFs will continue to be supported.

 

My second attachment speaks to 'non-Flash media', and 'non-Flash content'.

 

The second attachment utilizes network-referenced video files, subject to network entanglement and uncertainties, which usually compromise performance and, invariably, compromise temporal precision –– my audiences include playwrights, comedians, musicians, dancers, and singers, not to mention film and video actors, directors, camera operators, editors, reviewers, and producers –– in short, media choreography.  "Cue" is the word; timing is everything.  A Seek is executed as follows:

 

/*  A variant of Joel_Geraci1 at Forum, 2-2-18 - and also from D. P. Story  */
var aRM = this.getAnnotsRichMedia(0); // var used to ID any Clip on first page (PDF document page# minus 1)
var rm = aRM[3]; // get rich media annot for The Clip [RM List Position# minus 1]
if ( !rm.activated ) rm.activated=true; // activate the Clip-annot 
rm.callAS("multimedia_seek", (12));
rm.callAS("multimedia_play"); // play The Clip
//

 

 

 

In either of the attached files, it is the case that Seek appears to function as an inaccurate operator.

 

I am not wedded to Acrobat, nor the PDF format.  But I am steadfastly devoted to universal, low-cost, platform-independent and, above all, network-independent, dissemination of human expressive forms.

 

Next follows an engineering hint:  I shall presently post an example that differentiates [consistently] irregular behavior by Acrobat, re ActionScript calls, using two different sources of H.264, .mp4 files.  From one of those H.264 encoders, the result is as expected, per Adobe documentation.  It can be found by a search on ActionScript rm.callAS("multimedia_seek").

 

Stay in touch.

 

 

This topic has been closed for replies.

1 reply

D
Dave Merchant
Legend
February 26, 2020

As posted to your other thread, seek is only able to move the playhead to the nearest keyframe. How close that is to the time value you pass as a parameter depends entirely on how the video file is created. It is possible to create video files with keyframes at exact user-defined points, but it's not easy and if you plan to seek to "random" positions it won't help.

Brian_Raila
Brian_RailaAuthor
Inspiring
February 26, 2020

 

Thank you, Dave.  I have been trying to discern what might be the case, vis-a-vis 'keyframe dependence'.  And you are certainly qualified in the 'videoplayer skins' department.  But, as I've pursued documentation, I've not come up with any explanation from Adobe, that offers meaningful guidance.  That is to say –– whose idea was it to stipulate the argument as "seconds", rather than as "timepoint beyond nearest desired keyframe/scene-change/coin-flip".  Heck, app.setTimeOut is in milliseconds.  The ActionScript multimedia_nextCuePoint is unambiguous [though as you point out, getting them there might be a pain, but I've seen plenty claims of doing it with Adobe Media Encoder], as are the remainder of RM calls [one's first guess might be that multimedia_volume would be 0-100 (or 99), but it's not too hard to find documentation that it's actually 0-1; which is fine, since I use it in increments of .01].

 

As to "it's not easy and if you plan to seek to "random" positions it won't help," have a look at my most-recent post, found here.  It turns out that [so far], on anything I run through iMovie, I can then search random frames, acrosss the duration of the clip.  I am presuming the temporal resolution is to 33 milliseconds [a reference point addressable for each frame].  "We don't no steenking user-defined points."

 

Now, that doesn't explain the Handbrake encoding.  It was my sense that h.264 has to require keyframes at some frequency.  Configurable and variable, yes, and I would assume can be allowed to 'float', dependent on image processing analysis [e.g. 30-sec. black 'leader' at head of film xfer], but would hardly work with ongoing 1 keyframe/min., right?  I am certain the Handbrake encodes are 'clicking' at every [conventional Hollywood] scene-change, and not intra-scene.  At least, far as the footage I've tested.

 

Thanks for tuning in.  I shall keep the forum updated on my investigation.  Right now I need to solve why I stopped getting auto-email-notifications.

 

 

D
Dave Merchant
Legend
February 26, 2020

Documentation for anything rich-media or 3D in Acrobat has always been terrible; some things in the docs have never been implemented, some things in the code have never been documented. It was never much more than a proof of concept, and Adobe decided back in the Acrobat X cycle that the concept wasn't something they wanted to push forward. PDFs were just going to be boring documents, anything "interactive" was to be done in HTML or ePUB. Rich media and 3D made it into the Adobe extension to the ISO PDF spec so they couldn't just delete the code from Acrobat, but it got zero developer attention. They offloaded the 3D bits to Tetra, and left the Flash stuff to wither. It was never going to appear on mobile, none of the third-party PDF viewers could deal with it because they couldn't bundle the runtime, and these days the vast majority of people view PDFs on a phone or in a native browser window. It's not worth the effort to develop documents anymore, unless you're targeting a closed audience who can be forced to use Adobe Reader on a desktop computer.

 

The two embeddable SWFs "videoPlayer" and "audioPlayer" used by Acrobat and InDesign were pretty much out-of-the-box examples of the playback widget from Flash 8, hence the strange names of the function calls, and the Acrobat managers probably assumed people would go to the Flash Pro docs for help. Then Flash was 86ed and .. yeah.

 

The idea of video "cue points" in the Acrobat API is strictly a FLV idea, they are detected by the (closed source) FLV decoder in the Flash runtime and so the player gets to see them "for free". They are not the same as markers or XMP data in other video codecs, and since you can't make FLVs anymore that entire concept is dead on arrival.

 

As to keyframes, there are some third party apps that will analyze a video file and show the frame types (I and B) but by default an H.264 encoder creates them as it sees fit, based on how much a frame differs from the previous. That's why scene changes will create one. You can usually define the average interval between keyframes to aim for, and it's possible in some encoders to create H.264 files in "all-I" format where every frame is a keyframe, but at the cost of a much larger filesize.

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices