[FFmpeg-trac] #11048(ffplay:new): Feature Request: Start ffplay in paused mode

[FFmpeg]

#11048: Feature Request: Start ffplay in paused mode
-------------------------------------+----------------------------------
             Reporter:  geegee       |                    Owner:  (none)
                 Type:  enhancement  |                   Status:  new
             Priority:  normal       |                Component:  ffplay
              Version:  git-master   |               Resolution:
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+----------------------------------
Description changed by geegee:

Old description:

> I would like to request the addition of a global option for ffplay,
> called something like `-start_paused`, which will normally open the input
> but pause on the first frame until the pause key (space in ffplay) is
> pressed again, or the `s` key is pressed to advance and pause on the next
> frame.
>
> This would be very useful for viewing CBZ and CBR files, which are
> nothing but ZIP and RAR files, respectively, with different extension
> names and which contain a collection of picture files such as .jpg, .bmp,
> gif, and png.
>
> The current problem is that opening such zip/rar files directly with
> ffmpeg/ffplay, to the best of my knowledge, isn't supported. Thus,
> something like the following command can be used to circumvent this
> limitation and to allow viewing all compressed pictures in ffplay, which
> pipes extracted files to ffplay:
> {{{
> 7z e -so input.zip | ffplay -hide_banner -infbuf -fs -i pipe:
> }}}
> The problem with the approach above is that ffplay will display the
> contents at 25 fps, with each frame being one picture file from the
> compressed archive. Thus, manual pausing (or the `s` key) needs to be
> used to control how fast ffplay displays each frame. Using manual pause
> is also imperfect because, typically, human reaction will be too slow to
> pause right on the first frame, and thus a few initial frames will have
> been displayed too fast. On top of that, the ability to rewind or seek to
> previous frames is not possible with this command.
>
> Therefore, once again, my proposed solution would be to add a global
> option for ffplay, called something like `-start_paused`, which will
> normally open the input but pause on the first frame until the pause key
> (space in ffplay) is pressed again or the `s` key is pressed to advance
> and pause on the next frame.
>
> The problem of not being able to go to the previous frame or rewind to
> the very first frame would still remain, but this seems to be a problem
> with how piping works. A further solution to that would be to also
> introduce a way to buffer input frames, I tried to achieve this using
> `-infbuf` but that did not seem to change anything regarding seeking past
> frames.
>
> While I was experimenting with possible solutions, I noticed that ffplay
> will sometimes be able to read directly from zip files to my very own
> surprise, but with some limitations it seems. For example, `ffplay -i
> file.zip` surprisingly works as long as the contents are .jpg files, but
> will fail if the contents are .png (`-loglevel trace` seems to indicate
> that ffplay tries to open .png's in the .zip file as mp3's instead of
> `png_pipe`). Thus, I worked around this by using the piping command I
> mentioned previously, but that came at the cost of losing the ability of
> seeking previous frames with the arrow keys.
>
> Thank you very much for considering my suggestion and for the amazing
> work you do!

New description:

 I would like to request the addition of a global option for ffplay, called
 something like `-start_paused`, which will normally open the input but
 pause on the first frame until the pause key (space in ffplay) is pressed
 again, or the 's' key is pressed to advance and pause on the next frame.

 This would be very useful for viewing CBZ and CBR files, which are nothing
 but ZIP and RAR files, respectively, with different extension names and
 which contain a collection of picture files such as .jpg, .bmp, gif, and
 png.

 The current problem is that opening such zip/rar files directly with
 ffmpeg/ffplay, to the best of my knowledge, isn't supported. Thus,
 something like the following command can be used to circumvent this
 limitation and to allow viewing all compressed pictures in ffplay, which
 pipes extracted files to ffplay:
 {{{
 7z e -so input.zip | ffplay -hide_banner -infbuf -fs -i pipe:
 }}}
 The problem with the approach above is that ffplay will display the
 contents at 25 fps, with each frame being one picture file from the
 compressed archive. Thus, manual pausing (or the 's' key) needs to be used
 to control how fast ffplay displays each frame. Using manual pause is also
 imperfect because, typically, human reaction will be too slow to pause
 right on the first frame, and thus a few initial frames will have been
 displayed too fast. On top of that, the ability to rewind or seek to
 previous frames is not possible with this command.

 Therefore, once again, my proposed solution would be to add a global
 option for ffplay, called something like `-start_paused`, which will
 normally open the input but pause on the first frame until the pause key
 (space in ffplay) is pressed again or the 's' key is pressed to advance
 and pause on the next frame.

 The problem of not being able to go to the previous frame or rewind to the
 very first frame would still remain, but this seems to be a problem with
 how piping works. A further solution to that would be to also introduce a
 way to buffer input frames, I tried to achieve this using `-infbuf` but
 that did not seem to change anything regarding seeking past frames.

 While I was experimenting with possible solutions, I noticed that ffplay
 will sometimes be able to read directly from zip files to my very own
 surprise, but with some limitations it seems. For example, `ffplay -i
 file.zip` surprisingly works as long as the contents are .jpg files, but
 will fail if the contents are .png (`-loglevel trace` seems to indicate
 that ffplay tries to open .png's in the .zip file as mp3's instead of
 `png_pipe`). Thus, I worked around this by using the piping command I
 mentioned previously, but that came at the cost of losing the ability of
 seeking previous frames with the arrow keys.

 Thank you very much for considering my suggestion and the amazing work you
 do!

--
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/11048#comment:1>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker