Please allow invoked ffmpeg to read from stdin

[Vrihub]

Please open a new issue so that we don't forget it.

Since you asked for it... you can find all the details in #8139

[jaimeMF]

I've proposed #8256 to pass q when using Ctrl+C. I think that's enough for your use case, or do you really want to be able to use the stdin for ffmpeg? (if so, I'd like to hear why you need it)

[jaimeMF]

Since I think 9d90e7d solves the problem you have, I'm closing the issue.

If you really need to pass something to ffmpeg through stdin, we can reopen the issue.

Thanks for report!

[Vrihub]

I think that's enough for your use case, or do you really want to be able to use the stdin for ffmpeg? (if so, I'd like to hear why you need it)

Well 9d90e7d is an ad hoc fix, that is surely enough for this particular use case (sending "q" to stop ffmpeg gracefully, but why trapping Ctrl-C? and not "q"?), but there are certainly other uses for ffmpeg interactive mode: if you press "?" while ffmpeg is running, you'll get a menu explaining other interactive commands; most have to do with logging-debugging (and maybe they can be useful to debug problems in youtube-dl itself, so I wouldn't disable them).

More generally, this doesn't seem a good approach: to allow for a very very specific use case ("gradually feeding youtube-dl with urls through a pipe", see #8139 (comment)) you break the default expected behaviour of ffmpeg (reading from stdin), then make an exception (9d90e7d) to fix the use case that I pointed out. What if someone else in the future will complain about some of the other ffmpeg interactive commands not working anymore? You'd have to add yet another ad hoc workaround?

I proposed a more conservative solution (see #8139 (comment)): let ffmpeg behave as it's supposed to (so that you don't break "q" and other interactive commands), and if you really think the "gradually feeding youtube-dl with urls through a pipe" use case is really worth considering, add a new option to youtube-dl to pass "-nostdin" (that is a ffmpeg option) to the invoked ffmpeg, so that ffmpeg's stdin can be disabled on demand by the user if he needs to.

[jaimeMF]

(First of all: thanks for your detailed response and explanation)

sending "q" to stop ffmpeg gracefully, but why trapping Ctrl-C? and not "q"?

To be consistent with the rest of youtube-dl, 'Ctrl-C' cancels the download in the rest of downloaders. Additionally, while supporting 'Ctrl-C' is simple, 'q' may require some rework of the downloader.

if you press "?" while ffmpeg is running, you'll get a menu explaining other interactive commands; most have to do with logging-debugging (and maybe they can be useful to debug problems in youtube-dl itself, so I wouldn't disable them).

I know, but if someone needs to debug a problem they can just run the command that it's printed when you run youtube-dl with the --verbose option.

let ffmpeg behave as it's supposed to (so that you don't break "q" and other interactive commands)

I think that being able to directly control ffmpeg is your expectation, I see ffmpeg just as an internal tool for youtube-dl and I don't think users should be able to control it fully. And in the case of passing input to ffmpeg, it wouldn't allow us to wrap ffmpeg like we do for rtmpdump to provide the same download progress messages (the user wouldn't see the output from ffmpeg)

to allow for a very very specific use case ("gradually feeding youtube-dl with urls through a pipe"

I see youtube-dl not as program you interact with (that's the only place where youtube-dl ever consumes from stdin and it's not even documented), instead you just run it until it finishes and you can exit it if you want to cancel the download The example I shared was too specific, but I still think that being able to use youtube-dl in a script without having to care about it consuming stdin is nice.

Since I don't share your view, I'll let other maintainers decide what approach should follow youtube-dl.

[yan12125]

Agree with @jaimeMF - if you want to interact with ffmpeg, run ffmpeg directly.

[ealgase]

[q] interactive input should still work for livestreams, otherwise finishing a download is difficult.