This is a followup to another post of mine, on the same subject.
That one documents imprecision in the ActionScript 'Seek' operator. In it, I promised, "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." Now follows the particulars, as demonstrated in the attached file.
A single scene is called, with a JavaScript, to be Played beginning at the timepoint of 3 seconds:
/* 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[1]; // 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", (3));
rm.callAS("multimedia_play"); // play The Clip
//
In the upper instance on the attached page, this works as expected. In the lower instance, it does not work. Rather, the clip Plays, beginning at the timepoint of 0 seconds [its default Start point, upon activation].
There is a difference in the encoding of these two samples, though each is compliant with Acrobat's supported H.264, .mp4 file types.
The upper instance is the 12.9 MB output of iMovie, Version 10.1.14. Next, the clip was cropped via Handbrake, to remove the irrelevant, unwanted 'side pillars'.
The lower instance is the 2.7 MB output of Handbrake, Version 1.3.1 (2020010400). The encoding parameters include '1rf20.00'. If I understand correctly, this indicates one full Reference Frame captured every 20th frame[?].
Hypothesis: We know that data get get discarded, in the Handbrake re-encoding of the iMovie output. Does this somehow render the Timeline of the clip to be unreadable by Acrobat? I tried Handbrake at '1rf00.00'. The result was the same –– Seek point not honored; clip plays from timepoint 0 seconds.
Then there's this –– the Import to iMovie (golf swing clip) was, itself, a trim executed via Handbrake, in the first place. Which suggests that iMovie brings the Acrobat-readable timepoints back to life?
Finally, let's return to the above-referenced another post of mine. Those clips that failed to seek accurately were, without exception, Handbrake re-encodes. But remember, the Seek at least went some place other than 0 sec. And, the result was, without fail, related directly [next-previous scene-change] to the Seek timepoint argument. So if Handbrake is somehow stripping off timing data, the question for Adobe engineers becomes, "How is it that Acrobat conflates designated timepoints, with next-previous scene-cuts?" And, "Why does Acrobat treat iMovie clips differently?"
I do accept workarounds, if not clumsy beyond practicable. Someone's bound to chime in with, "Well, what about 'Multimedia_nextCuePoint?" Well, what about it? Which begs the questions:
- What might be a reasonable mechanism for marking, and managing, CuePoints/Chapter-marks, and such?
- Adobe Media Encoder?
- Is Media Encoder processing lossy? This is becoming a pricey workaround, for what presumably oughta' be working 'as is'.
- How about a fudged way to batch process a CuePoint mark every, say, 10 times/sec.? That's a reasonable 'reference rate' in the realm of animation, for instance. I could live with that, for the moment. But in the larger picture, Acrobat's commenting frequency [temporal resolution] on temporal media is already 30 times/sec., so 10/sec. remains coarse.
I invite community comment, and especially look to Adobe to address this. And of course, perhaps there's simply a deficiency in my understanding of ActionScript, or of H.264 video.
Cheers,
BR
AdChoices