youtube-dl sends spurious input to invoked ffmpeg

[ghost]

This was noticed when I pasted in a Debian console a series of:

youtube-dl htp://myserver.com/onelink
youtube-dl htp://myserver.com/anotherlink
youtube-dl htp://myserver.com/thirdlink

While the first command was executed, the others were sent as input for ffmpeg, which spammed the console with countless:

Enter command: <target>|all <time>|-1 <command>[ <argument>]
error parsing debug value
debug=0

These errors can be prevented if ffmpeg's invocation includes a </dev/null.

A workaround is to add </dev/null to each youtube-dl call.

[dstftw]

Post the exact snippet you pasting.

[jaimeMF]

Without more info I think that 3f17c35 should fix your issue.

[Vrihub]

I think commit 3f17c35 actually caused a regression: ffmpeg should be allowed to receive input from the user!

For example, when recording a live stream in mp4 format, if the user wants to gracefully stop the recording, ffmpeg supports this by pressing "q" in the terminal window, and the mp4 file will be regularly closed and saved. After 3f17c35 this is no longer possible, and the only way the user can stop the recording is pressing Ctrl-C (or closing the terminal), which results in a corrupted mp4 file!
This is just a use case, but I'm sure there are others.

Indeed the original poster's way of "pasting a series of commands" seems wrong to me; shell commands should be separated by a ";" character, in order to be executed serially. Separating them with spaces actually causes the problem he reported, but this is a shell syntax error, not a bug in youtube-dl.

So please revert commit 3f17c35

[jaimeMF]

@Vrihub you have a valid point, but the problem is that in commands like while read aurl ; do youtube-dl "${aurl}"; done < path_to_batch_file ffmpeg consumes part of the batch file contents and youtube-dl gets incomplete urls (see #4945). Maybe youtube-dl should pass q to ffmpeg when pressing Ctrl-C.

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

[Vrihub]

while read aurl ; do youtube-dl "${aurl}"; done < path_to_batch_file
There is no reason to use a loop like that; for this kind of stuff there is:
youtube -a path_to_batch_file

[jaimeMF]

For that simple case yes, but if you want to gradually feed youtube-dl with urls through a pipe you can't use it (-a - tries to consume all the input).

[Vrihub]

For that simple case yes, but if you want to gradually feed youtube-dl with urls through a pipe you can't use it (-a - tries to consume all the input).

Then I'd suggest that you add a new option to youtube-dl for disabling ffmpeg's stdin, to be used in this particular scenario (which I find rather uncommon, BTW, but this is just an opinion). Maybe --hls-prefer-native and/or --external-downloader are already suitable for this?

For the most common scenario, in which youtube-dl is invoked interactively to download from one source, I think youtube-dl's default behaviour should be to allow ffmpeg's behave as it is supposed to (=be able to read from stdin).