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

[Brian_Raila]

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.

[Dave Merchant]

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]

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.

[Dave Merchant]

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.

[Brian_Raila]

I hear you, Dave.  For now, consider that I've solved the video encoding obstacle; that I've Seek working as advertised.  I'll next, elsewhere, turn attention to temporal triggers of media.  Summary:  I need a Timer/Interval/Stall/Idle capability such that –– three [f''rinstance] clips play, from a single Button Event, with start times following that event, by x interval, y interval, and z interval, respectively.  I've tried various approaches, but am still tripping over my own scripting naiveté.

To emphasize, I do not require Flash.  I do require precision.  Both operational, and cognitive, because the two are inextricable.

As for the big picture, here is a generalized description [edited] that I recently sent to Bob Levine:

– – – – –

Subject: Seeking Best Practices for documents self-contained, stand-alone, and portable, with unrestricted content

I am aware of your many-fold contributions to the Adobe community.  You will understand why my work has led me, more than once, to your remark in this post, "PDF is an awful format for multimedia," which led me to reviewing with interest your referenced article.  You will see that I am hardly a Luddite in network operations, and precisely for that reason I offer my good-natured comeback that "network dependence is an awful compromise for multimedia."  But that article of yours has pointed me in promising directions.  In short, I require portable, compiled documents, with all components contained [or predictably connected and operated upon via a 'carry-along satchel' of some sort], independent of network reliance.  It's looks like I should look at InDesign.

Context:  I am an artist, also engaged in Arts and Humanities education.  In this 11-min. screen recording of a PDF in action, you'll observe that the document supports millisecond-sync of 22-track audio, not to mention animation, video, etc.  I find that though engineers and scientists routinely utilize, say, attachments traveling within a document, dancers, painters, and playwrights are taken by surprise.

Why I look to you:  That document I composed last year, on a Late 2007 MacBook, OS X 10.7.5, with Acrobat Pro XI, and Flash-25.0.0.127 (I am now, in every respect, substantially upgraded).  Everything you see was created via the built-in Properties Action dialog/editor/GUI-thingy.  Would that I'd known of ActionScript methods to manipulate media in background/hidden fashion [e.g. rm.activated = !rm.activated], manipulating Booleans, managing an array of media, etc., which would allow a more refined/polished/graceful result.  Now I better understand that potential, and have initiated evaluation of InDesign, and of Animate.

Summary objective:  Above all, I require portability, and independence from network dependencies beyond the user's control.  F'rinstance, the instructor distributes  a document.  The students turn in, each one of them potentially different, a marked-up/modified/enhanced/edited variant, e.g. "Look, Teach –– at the final eighth-note of 'bar 24', instead of that percussion, consider instead that I play this trill, on my flute."  The student needn't edit the video/audio.  The trill recording is simply an audio comment, pegged to one of the 30 comments/sec. [or cue-point, or other marker] supported in Acrobat.

  Representative set of required document traits:

• precise synchronization of temporal media
• selective layering
• variable opacity

• scalable pages: Paragraph 2 - Line 7 is Line 7 is Line 7 [your blog violates this.  Instructors are as dependent on an equivalent of Bates numbering ('bar 24'), as are lawyers and doctors]

• platform independence
• compliance with a communications display standard [e.g. ISO 32000]

   Representative set of unacceptable constraints (Current Practice for decades) to be avoided:

• Here is a recording of –
• one single choir, alone
• on a single stage
• at one time, only
• on one single Youtube channel
• oh, wait! - did that essential component of my presentation, somewhere, sometime, somehow, suddenly disappear?
• O, brother, Four O Four, where art thou?

   What I do not require of the recipient/user/reader

• network-connection dependence/shackles
• mobile-device dependence
• compliance with merely a data transfer standard [e.g. ISO 15445], which specifies five traits for browsers of Web so-called 'pages' –– namely Back, Forward, Pause, Reload, Print.  Absent are specifications for Dimensions, Top, Bottom, Left, Right, Header, Footer, Find, Magnification, Comments, Markups, Attachments, Copy/Duplicate/Forward, and an abundance more.  Hence, this behavior is ever-changing, ever-unpredictable, varying from manufacturer to manufacturer, on device to device.  This is why reading same is analogous to using books in the library, during an earthquake.
• social-media-platform dependence [you can imagine my morose dismay that the University of Maryland 'Student Course Registration' page trumpets, "See what courses your Facebook Friends are signing up for!"]

– – – – –

Finally, with respect to "PDF is an awful format for multimedia," somebody better get the word out quick, to the United States Federal Courts, wherein:

• "All documents are required to be filed in the PDF format. Other file types may be encapsulated inside PDF files, e.g. audio files in MP3 format, or video files. CM/ECF plans to require PDF/A compliant files to meet the requirements of the National Archives and Records Administration. Each court will set its own deadline for requiring documents to be filed in the PDF/A format. No warning period is planned."

Let me not be misunderstood.  If any manufacturer, presently, is in a position to "do it right," it is Adobe.  And if there is any set of persons I turn to for guidance in meeting my above objectives, it is this community forum.  I am not sowing rancor, or sour grapes, in the least.

I am not at all wedded to Flash.  For all I care, my documents can be dependent upon a carry-along satchel [consider that Boeing manages a library of more than 10 million PDFs], that includes the likes of VLC Media Player [consider that the max. file size of a PDF = the storage capacity of the device].  For all I care, they can take as long to locally load as it takes to find Act II of Henry V in a compendium of dramatic works.  But once the user starts using the document it, without fail, goes gangbusters, as reliably as a machine gun on a target, which re-aimed [cognitively speaking], continues firing clips in precisely the way its maker intended.

– BR