Add a --play option

[phihag]

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.

[tbu-]

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.

[johnhawkinson]

@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.

[yan12125]

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 {}"

[johnhawkinson]

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.

[yan12125]

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.

[johnhawkinson]

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...)

[yan12125]

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.

[johnhawkinson]

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.

[yan12125]

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).

[johnhawkinson]

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

[yan12125]

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.

[johnhawkinson]

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?

[yan12125]

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 mpv-player/mpv@78caf6a, 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.