starred/youtube-dl-ytdl-org

Fork 0

mirror of https://github.com/ytdl-org/youtube-dl.git synced 2026-03-02 19:17:00 -05:00

youtube-dl sends spurious input to invoked ffmpeg #6589

New issue

Closed

opened 2026-02-21 03:19:57 -05:00 by deekerman · 7 comments

deekerman commented

2026-02-21 03:19:57 -05:00

Owner

Originally created by @ghost on GitHub (Jan 4, 2016).

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.

Originally created by @ghost on GitHub (Jan 4, 2016). 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.

deekerman closed this issue

2026-02-21 03:19:59 -05:00

deekerman commented

2026-02-21 03:20:01 -05:00

Author

Owner

@dstftw commented on GitHub (Jan 4, 2016):

Post the exact snippet you pasting.

@dstftw commented on GitHub (Jan 4, 2016): Post the exact snippet you pasting.

deekerman commented

2026-02-21 03:20:02 -05:00

Author

Owner

@jaimeMF commented on GitHub (Jan 4, 2016):

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

@jaimeMF commented on GitHub (Jan 4, 2016): Without more info I think that 3f17c357d9958bfae18f06676c89ffdb63553509 should fix your issue.

deekerman commented

2026-02-21 03:20:02 -05:00

Author

Owner

@Vrihub commented on GitHub (Jan 13, 2016):

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

@Vrihub commented on GitHub (Jan 13, 2016): 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

deekerman commented

2026-02-21 03:20:02 -05:00

Author

Owner

@jaimeMF commented on GitHub (Jan 13, 2016):

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

@jaimeMF commented on GitHub (Jan 13, 2016): @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.

deekerman commented

2026-02-21 03:20:02 -05:00

Author

Owner

@Vrihub commented on GitHub (Jan 13, 2016):

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

@Vrihub commented on GitHub (Jan 13, 2016): `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`

deekerman commented

2026-02-21 03:20:03 -05:00

Author

Owner

@jaimeMF commented on GitHub (Jan 13, 2016):

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

@jaimeMF commented on GitHub (Jan 13, 2016): 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).

deekerman commented

2026-02-21 03:20:03 -05:00

Author

Owner

@Vrihub commented on GitHub (Jan 13, 2016):

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

@Vrihub commented on GitHub (Jan 13, 2016): > 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).

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/youtube-dl-ytdl-org#6589

No description provided.

Rows
Columns