Created attachment 138202 [details] Example file, mentioned in the bug description. I think that the current handling of "AutoPlay" is wrong for Renditions. Currently, Okular obeys "/A" field from https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdfs/PDF32000_2008.pdf#G12.2318501. Although the difference is subtle, I think that this field shouldn't correspond to Okular's notion of autoplay: The activation itself is handled by Rendition actions, like with Movie annotations. "/A" field controls behaviour after annotation is activated and may be used to prevent playing (the only use is probably to display first frame of video instead of normal apperance, although even this seems weird). The following patch makes Okular not respect the /A field (which has no equivalent in Okular). --- a/generators/poppler/generator_pdf.cpp +++ b/generators/poppler/generator_pdf.cpp @@ -237,7 +237,7 @@ Okular::Movie *createMovieFromPopplerScreen(const Poppler::LinkRendition *popple movie->setPlayMode(Okular::Movie::PlayLimited); movie->setPlayRepetitions(rendition->repeatCount()); } - movie->setAutoPlay(rendition->autoPlay()); + movie->setAutoPlay(false); // will be triggered by external RenditionAction return movie; } However this means that there is now a problem of how to handle the autoplay. I would expect Screen annotations additional actions (/AA) to work, but it currently doesn't. I didn't yet discover the cause. To illustrate how autoplay with additional actions doesn't work after applying the above patch I attach an example. (It can also be used to confirm the wrong handling of autoplay, when `/A false` is removed.)
> I think that the current handling of "AutoPlay" is wrong for Renditions. Did you check what Acrobat does? Okular would usually strive to do the same.
(In reply to Oliver Sander from comment #1) > > I think that the current handling of "AutoPlay" is wrong for Renditions. > > Did you check what Acrobat does? Okular would usually strive to do the same. TL;DR: Yes it correctly handles `/A` and Rendition actions. In Acrobat `/A` works almost as expected. When the annotation is activated (e.g. using Rendition action on page open or "on click" action) and `/A` is true (default) everything starts playing normally. If `/A` is false however only black frame is displayed (here first frame of the video would be expected). In this activated, but not playing, state it is possible to play the video using controls (and maybe JavaScript, but I don't know the API available for Renditions well). I don't know whether it is possible to achieve the behaviour expected by `/A` in Okular, but I think it would be fine to just assume `/A` to be true. Because "true" essentially doesn't mean "starting playing automatically" but "don't pause instead of playing". "Start playing" should be left to the rendition actions, which may for example be used as "Additional Actions" on the Screen annotation to start the playback on "page open" or other event.
I can also confirm that Acrobat does treat the /A flag as “autoplay when activated” and not “activate automatically” as Okular does. The flag is poorly named, but the spec says (quote is from 1.7, table 9.15): > A boolean (Optional) If true, the media should automatically play when activated. If false, the media should be initially paused when activated (for example, the first frame is displayed). Relevant only for media that may be paused. Default value: true.
Git commit a33e499b4031a7a9f383017c92a77c1eb95ea782 by Albert Astals Cid, on behalf of Cimbali. Committed on 15/02/2023 at 23:32. Pushed by aacid into branch 'master'. Fix wrong interpretation of autoplay flag M +12 -0 core/movie.cpp M +10 -0 core/movie.h M +8 -1 generators/poppler/generator_pdf.cpp M +3 -0 part/videowidget.cpp https://invent.kde.org/graphics/okular/commit/a33e499b4031a7a9f383017c92a77c1eb95ea782