Add a --play option

deekerman commented

2026-02-20 21:14:50 -05:00

Owner

Originally created by @phihag on GitHub (Jan 11, 2013).

Originally assigned to: @phihag on GitHub.

A common case is just wanting to watch the downloaded video. For that, we should add an option to play the video.

For starters, it can be a simple post-processing action. However, I think the user experience would be better if we'd have an option to either autoplay once a certain buffer (say, 2MB) has been written to disk. We may also tee the output to a pipe and pass that to the video player in order for the video player not to stop playback once it reaches the current number of downloaded bytes.

Originally created by @phihag on GitHub (Jan 11, 2013). Originally assigned to: @phihag on GitHub. A common case is just wanting to watch the downloaded video. For that, we should add an option to play the video. For starters, it can be a simple post-processing action. However, I think the user experience would be better if we'd have an option to either autoplay once a certain buffer (say, 2MB) has been written to disk. We may also tee the output to a pipe and pass _that_ to the video player in order for the video player not to stop playback once it reaches the current number of downloaded bytes.

deekerman added the

postprocessors

label

2026-02-20 21:14:50 -05:00

deekerman commented

2026-02-20 21:14:52 -05:00

Author

Owner

@tbu- commented on GitHub (Oct 10, 2015):

That feature would be really useful! Perhaps it would be useful to preload the next video while the previous one is still playing, so you don't get a pause.

@tbu- commented on GitHub (Oct 10, 2015): That feature would be really useful! Perhaps it would be useful to preload the next video while the previous one is still playing, so you don't get a pause.

deekerman commented

2026-02-20 21:14:53 -05:00

Author

Owner

@johnhawkinson commented on GitHub (Oct 22, 2016):

@phihag, any updates on this? in 640 in 2013 you wrote:

See #628 for an API that would allow playing videos while downloading them. I'm currently working on that and expect it to be finished in a week or so.

Obviously it's been more than a week :)

Since then --exec has been added, which is perhaps a model for how this should work from a UI perspective.

At the moment it's annoying to achieve with the tools we have available since you have to run youtube-dl twice: once to get the filename and once to actually do the download, and that overhead can be significant where getting the metadata is slow. (I suppose we could popen youtube-dl's output or use the api to get the filename while it runs the download...but at that point it seems much better to just add this option.)

Thanks for the update.

We may also tee the output to a pipe and pass that to the video player in order for the video player not to stop playback once it reaches the current number of downloaded bytes.

I don't know that either of these are necessary. VLC, e.g., will continue playback on a regular file that is growing in realtime (at least when it grows faster than it plays), although it does get a little confused about the total time and present a pinned progress bar. But it's a better experience than playing from a pipe, since it cannot rewind or seek on a pipe.

@johnhawkinson commented on GitHub (Oct 22, 2016): @phihag, any updates on this? in 640 in 2013 you wrote: > See #628 for an API that would allow playing videos while downloading them. I'm currently working on that and expect it to be finished in a week or so. Obviously it's been more than a week :) Since then `--exec` has been added, which is perhaps a model for how this should work from a UI perspective. At the moment it's annoying to achieve with the tools we have available since you have to run youtube-dl twice: once to get the filename and once to actually do the download, and that overhead can be significant where getting the metadata is slow. (I suppose we could popen youtube-dl's output or use the api to get the filename while it runs the download...but at that point it seems much better to just add this option.) Thanks for the update. > We may also tee the output to a pipe and pass that to the video player in order for the video player not to stop playback once it reaches the current number of downloaded bytes. I don't know that either of these are necessary. VLC, e.g., will continue playback on a regular file that is growing in realtime (at least when it grows faster than it plays), although it does get a little confused about the total time and present a pinned progress bar. But it's a better experience than playing from a pipe, since it cannot rewind or seek on a pipe.

deekerman commented

2026-02-20 21:14:53 -05:00

Author

Owner

@yan12125 commented on GitHub (Oct 22, 2016):

since you have to run youtube-dl twice

Not sure why it's necessary for you. Here's an example with --exec:

youtube-dl test:youtube --exec "mpv {}"

@yan12125 commented on GitHub (Oct 22, 2016): > since you have to run youtube-dl twice Not sure why it's necessary for you. Here's an example with `--exec`: ``` youtube-dl test:youtube --exec "mpv {}" ```

deekerman commented

2026-02-20 21:14:53 -05:00

Author

Owner

@johnhawkinson commented on GitHub (Oct 22, 2016):

Not sure why it's necessary for you. Here's an example with --exec:

I'm assuming we want to start playing immediately, not to wait for the download to finish. This is more important for much longer videos where the download might take a long time.

@johnhawkinson commented on GitHub (Oct 22, 2016): > Not sure why it's necessary for you. Here's an example with --exec: I'm assuming we want to start playing immediately, not to wait for the download to finish. This is more important for much longer videos where the download might take a long time.

deekerman commented

2026-02-20 21:14:53 -05:00

Author

Owner

@yan12125 commented on GitHub (Oct 22, 2016):

Ah, I see your point.

will continue playback on a regular file that is growing in realtime (at least when it grows faster than it plays)

Assume downloading is slower than playing. When mpv hits end of file, it quits normally.

@yan12125 commented on GitHub (Oct 22, 2016): Ah, I see your point. > will continue playback on a regular file that is growing in realtime (at least when it grows faster than it plays) Assume downloading is slower than playing. When mpv hits end of file, it quits normally.

deekerman commented

2026-02-20 21:14:53 -05:00

Author

Owner

@johnhawkinson commented on GitHub (Oct 22, 2016):

If downloading is slower than playing, then this is a lot harder to think about, since the right time to start depends on speed and duration, and speed is not perfectly predictable, so there is no perfect solution. There's no universal correct answer for that case.

But when the download is faster than playing, you want to start playing nearly instantaneously after the download starts. That's the case I'm interested in support for (and it's easier).

It starts to sound like the slower-than-realtime download calls for a pipe (maybe --play 'sleep $DELAY; tail +1f {} | mpv'), and the faster-than-realtime download calls for a filename (--play 'vlc {}'), but either way it does not change how this is implemented, it just changes what args the user calls --play with.

Do you know what Philipp was intending? It doesn't seem very complicated...
The quick-and-dirty solution is to have FileDownloader.download() or FileDownloader.report_destination() fork, sleep for a second(?), and launch the player. (I guess a snazzier subprocess solution is required for Windows...)

@johnhawkinson commented on GitHub (Oct 22, 2016): If downloading is slower than playing, then this is a lot harder to think about, since the right time to start depends on speed and duration, and speed is not perfectly predictable, so there is no perfect solution. There's no universal correct answer for that case. But when the download is faster than playing, you want to start playing nearly instantaneously after the download starts. That's the case I'm interested in support for (and it's easier). It starts to sound like the slower-than-realtime download calls for a pipe (maybe `--play 'sleep $DELAY; tail +1f {} | mpv'`), and the faster-than-realtime download calls for a filename (`--play 'vlc {}'`), but either way it does not change how this is implemented, it just changes what args the user calls `--play` with. Do you know what Philipp was intending? It doesn't seem very complicated... The quick-and-dirty solution is to have FileDownloader.download() or FileDownloader.report_destination() fork, sleep for a second(?), and launch the player. (I guess a snazzier subprocess solution is required for Windows...)

deekerman commented

2026-02-20 21:14:53 -05:00

Author

Owner

@yan12125 commented on GitHub (Oct 22, 2016):

The "sleep before start" does not fit all scenarios. Downloading speed may drop significantly in the middle, even if at first the speed looks quite fine.
I guess the best solution to this is asking players to add an option/feature, so that it waits in reaching the end of a file but not quits immediately.

@yan12125 commented on GitHub (Oct 22, 2016): The "sleep before start" does not fit all scenarios. Downloading speed may drop significantly in the middle, even if at first the speed looks quite fine. I guess the best solution to this is asking players to add an option/feature, so that it waits in reaching the end of a file but not quits immediately.

deekerman commented

2026-02-20 21:14:53 -05:00

Author

Owner

@johnhawkinson commented on GitHub (Oct 22, 2016):

I agree, solving slower-than-realtime download completely requires player support, and is beyond the scope of youtube-dl. But there is value in making this work where the download is faster than realtime, and we can do that today.

I guess the best solution to this is asking players to add an option/feature, so that it waits in reaching the end of a file but not quits immediately.

Does mpv not do this? VLC does this when reading from a pipe.

@johnhawkinson commented on GitHub (Oct 22, 2016): I agree, solving slower-than-realtime download completely requires player support, and is beyond the scope of youtube-dl. But there is value in making this work where the download is faster than realtime, and we can do that today. > I guess the best solution to this is asking players to add an option/feature, so that it waits in reaching the end of a file but not quits immediately. Does mpv not do this? VLC does this when reading from a pipe.

deekerman commented

2026-02-20 21:14:53 -05:00

Author

Owner

@yan12125 commented on GitHub (Oct 22, 2016):

But there is value in making this work where the download is faster than realtime, and we can do that today.

Yes. If players have proper supports, there's no need to handle slower-than-realtime cases specially in youtube-dl.

Does mpv not do this? VLC does this when reading from a pipe.

mpv waits for pipes, too, while it quits for normal files. As you've mentioned, using pipe disables seeking, so I'd like to prevent it.

Other issues I can imagine as of now:

The default format. As on-the-fly merging is not implemented yet, bestvideo+bestaudio is not applicable with --play. Unfortunately, best has lower resolution on most YouTube videos and maybe more sites.
When combining --play with other post processing options like --embed-thumbnail, handling of temporary files is an issue, especially on Windows, in which it's disallowed to delete a file in use (e.g., opened by a player).

@yan12125 commented on GitHub (Oct 22, 2016): > But there is value in making this work where the download is faster than realtime, and we can do that today. Yes. If players have proper supports, there's no need to handle slower-than-realtime cases specially in youtube-dl. > Does mpv not do this? VLC does this when reading from a pipe. mpv waits for pipes, too, while it quits for normal files. As you've mentioned, using pipe disables seeking, so I'd like to prevent it. Other issues I can imagine as of now: - The default format. As on-the-fly merging is not implemented yet, `bestvideo+bestaudio` is not applicable with `--play`. Unfortunately, `best` has lower resolution on most YouTube videos and maybe more sites. - When combining `--play` with other post processing options like `--embed-thumbnail`, handling of temporary files is an issue, especially on Windows, in which it's disallowed to delete a file in use (e.g., opened by a player).

deekerman commented

2026-02-20 21:14:54 -05:00

Author

Owner

@johnhawkinson commented on GitHub (Oct 22, 2016):

None of these seem like showstoppers.
(Also, --play should probably imply both --no-part and --hls-use-mpegts)

@johnhawkinson commented on GitHub (Oct 22, 2016): None of these seem like showstoppers. (Also, `--play` should probably imply both `--no-part` and `--hls-use-mpegts`)

deekerman commented

2026-02-20 21:14:54 -05:00

Author

Owner

@yan12125 commented on GitHub (Oct 22, 2016):

Even if --no-part is specified, files are still re-generated with ffmpeg during thumbnail or subtitle embedding.

None of these seem like showstoppers.

Can't agree. I bet there will be lots of complaints if --play does not give highest resolutions for YouTube videos.

@yan12125 commented on GitHub (Oct 22, 2016): Even if `--no-part` is specified, files are still re-generated with ffmpeg during thumbnail or subtitle embedding. > None of these seem like showstoppers. Can't agree. I bet there will be lots of complaints if `--play` does not give highest resolutions for YouTube videos.

deekerman commented

2026-02-20 21:14:54 -05:00

Author

Owner

@johnhawkinson commented on GitHub (Oct 22, 2016):

So this should block until on-the-fly merging is implemented? (Is there an Issue #?)

It seems poor for "best" to be the enemy of "good." (Or, in this case "bestvideo+bestaudio" the enemy of --play.)

Have any of the players tried to solve the on-the-fly merging problem?

@johnhawkinson commented on GitHub (Oct 22, 2016): So this should block until on-the-fly merging is implemented? (Is there an Issue #?) It seems poor for "best" to be the enemy of "good." (Or, in this case "bestvideo+bestaudio" the enemy of `--play`.) Have any of the players tried to solve the on-the-fly merging problem?

deekerman commented

2026-02-20 21:14:54 -05:00

Author

Owner

@yan12125 commented on GitHub (Oct 22, 2016):

Is there an Issue #

Sorry I can't remember it.

Have any of the players tried to solve the on-the-fly merging problem?

From github.com/mpv-player/mpv@78caf6ae86, I guess someone added a feature in ffmpeg so that the ffmpeg-based mpv can handle bestvideo+bestaudio properly. I'm not sure what ffmpeg does is on-the-fly merging or not, though.

@yan12125 commented on GitHub (Oct 22, 2016): > Is there an Issue # Sorry I can't remember it. > Have any of the players tried to solve the on-the-fly merging problem? From https://github.com/mpv-player/mpv/commit/78caf6ae8634b9fe9589187d8febb927dce2ddeb, I guess someone added a feature in ffmpeg so that the ffmpeg-based mpv can handle bestvideo+bestaudio properly. I'm not sure what ffmpeg does is on-the-fly merging or not, though.

Rows
Columns

Add a --play option #492