Hi all. I've raised this issue on the LO users list; they suggested
transferring it here for better comment. So, I'm totally new here and to
LO's source code and its quirks (as well as very out of date with my C++
skills!). Apologies if I transgress any mail-list rules.
There has been (even IIRC since the OOo days) a glitch when playing an
embedded video clip into an Impress slide show. I believe the issue has
been reported by various people over the years, with at best
unsatisfactory work-arounds suggested.
Jumping straight in, when embedding a clip into a slide, a place-holder
frame is picked. This appears to be done by a method grabFrame() defined
in the file mediawindow.cxx. This file picks a frame as near as possible
to 3 seconds into the clip -- a position that is compiled in. As far as
the user is concerned, it's effectively a random frame.
Unfortunately, while that is adequate for a static placeholder at design
time, the exact same frame is displayed during the 'start slide'
transition before the video starts to play, and also left visible when
the video finishes. This typically gives rise to a flash at the start if
there's no slide transition or a wrong frame displaying if the slide
transition is slow (the video only starts when the transition is complete).
There is, however the simple and obvious workaround of setting the time
offset for that frame to zero. At the very least, a video will normally
fade in from and out to the same frame (or can be contrived to do so).
I've tried this out on the current HEAD sources (6.something), with the
expected effect on the start of the video - no inappropriate frame
displayed, and the video starts smoothly.
However, for reasons unknown, I've found that the /true/ last frame
remains displayed at the video end (I've been testing with a video each
of whose frames contains just the frame number). (A bonus, but the
reason really should be understood.)
A minor snag is that if a video starts with a black frame, that's what
will be seen when the slide is being laid out.
Is it reasonable to suggest for now a single-character alteration to the
source code? At line 37 in
#define AVMEDIA_FRAMEGRABBER_DEFAULTFRAME_MEDIATIME 3.0
#define AVMEDIA_FRAMEGRABBER_DEFAULTFRAME_MEDIATIME 0.0
(I'm using linux Mint, but I don't believe the LO issue is OS-specific.
The version I've edited locally shows as 6.0...alpha1+, but it looks as
though this code has been unchanged for a long time.)
Re: Impress video glitch - comments and a workaround
On Mon, 2017-11-13 at 15:16 +0000, Mike Scott wrote:
> A minor snag is that if a video starts with a black frame, that's
> what will be seen when the slide is being laid out.
> Is it reasonable to suggest for now a single-character alteration to
> the source code? At line 37 in
> #define AVMEDIA_FRAMEGRABBER_DEFAULTFRAME_MEDIATIME 3.0
> #define AVMEDIA_FRAMEGRABBER_DEFAULTFRAME_MEDIATIME 0.0
Yeah, it seems reasonable, I suggest going ahead and submit a patch for
that to our gerrit, you can add me on cc on that.
Maybe what we should additionally try to do is to pass an argument to
MediaWindow::grabFrame with the time to use and distinguish between the
case where we're previewing in impress edit mode in which case the
current 3.0 is a reasonable thing, vs the presentation mode where we
definitely want 0.0
LibreOffice mailing list
[hidden email] https://lists.freedesktop.org/mailman/listinfo/libreoffice