Added function start-paused

[bholmes451]

This function allows a user to start omxplayer in a paused state instead
of immediately starting playback of the video. The user can then use
standard keyboard or dbus commands to begin playback manually.

To use this function add the command-line parameter: --start-paused to
the omxplayer command.

Example:

omxplayer -p -o hdmi --start-paused test.mkv

This will start the omxplayer, load the buffer to begin playback and
then pause. To resume playback, press the key on the keyboard for
resume (by default this is the p or space keys), or send a dbus command.

[bholmes451]

This pull request solves these issues:
#527 #534

[xk]

Does an "omxplayer --start-paused test.mkv" show the first frame on the screen or a black screen? And if it does, always or just sometimes?

[bholmes451]

During our testing it has always shown a black screen. My belief based on the source code is that it actually pauses a few frames before the actual first frame of the movie buffer. But I'm considering retracting this pull request for now. Our extended testing found a problem with controlling multiple instances of omxplayer through dbus to be problematic. In addition, long term we are going to need more insight into startup times which this interface currently can't handle.

[bk138]

@bholmes451 Not taking the the DBUS issues into account, I reckon this PR nonetheless does what it says, i.e. pause the video upon start (so one can start later via DBUS/key cmd)?

If so, I kindly request a merge @popcornmix . We need this functionality and I considered implementing it myself, but bholmes451 was faster ;-)

[merlink01]

@bholmes451 after compiling your fork, it seems not to work correct.
If I use this parameter it doesn't show the first frame.
Also no blank screen is shown.
The optimal solution should be showing first frame as this is standard on Broadcast Media Players.
Any Idea how to fix this?

[bk138]

@merlink01 so what is actually shown then?

[merlink01]

It seems the Framebuffer stays as before, so I see the shell instead.

[merlink01]

For testing I used this File:
https://www.edius.de/test/foo.mp4
(h264/1080p50)

[bk138]

@merlink01 me thinks adding -b should blank the screen. will try it out and report here

[merlink01]

Thanks, ill try it.

[KenT2]

It would be great if there were two options, one to pause before the first frame and one after the first frame.

Pausing before for the first frame is useful for low end theatre video playout where the Pi is connected direct to the projector. Pausing after first frame meets your broadcast requirement and is also useful for 'magic pictures' where a static first frame suddenly starts moving when the viewer approaches (using movement sensor).
I have implemented both of these in Pi Presents by using the dbus Position command to detect when to pause but it would be much better done in omxplayer, less jittery time delays.

[merlink01]

OK, the -b option does the job.
But I agree with @KenT2, for my player solution the first Frame would be a much better solution.

[jehutting]

@merlink01 When omxplayer is in the initial paused state, does it show the first frame when you execute the STEP command (available by pressing the 'v' (keyboard) key))?

[merlink01]

@jehutting Thanks for the tip, I'll try tomorow.

[merlink01]

@jehutting
Yes that is working!

But there is no dbus command for step.
(I'll try to simulate a key press.)

[jehutting]

Thanks @merlink01 for trying it out.

The idea is to give the --start-paused an extra argument where the value

• 0 = pause before the first frame (blank screen, as is the case of current implementation), and
• 1 = pause after the first frame (meaning showing the first frame).

With value 1 all you need to do is an extra statement m_av_clock->OMXStep();.
Note: OMXStep() has an argument steps for the number of steps to make; I never tried that.

[merlink01]

If you are Working on this, would it also be possible to implementiert an --end-paused Option?
So the player could stop on last frame.

[dronus]

I've merged this and also added --end-paused by #669 .

[willwrong]

Is there any hope of this being merged? It strikes me as essential for any higher-level video control. Thanks.