Repository navigation
--simulate doesn't accurately simulate downloading under certain conditions #9843
Description
Activity
- changed the title
[-]`--simulate` does not accurately simulate downloading if FFmpeg is missing[/-][+]`--simulate` doesn't accurately simulate downloading under certain conditions[/+]on May 2, 2024 I'm a little hazy as to why one would want to use
--simulatebecause all it basically tells you is that the extractor didn't (with luck) crash. If you want to know, say, what format(s) will be selected there is--get-formator eqv. Since no video download is being run, it can't tell you anything about any external downloader.Looking at upstream confirms the diagnosis in this issue.
-
The API param
simulateis also forced to true when a "printing" option such as--get-formatis selected. This would give the wrong answer if the default format selection was changed bysimulate. -
The default format is changed to
best/bestvideo+bestaudioas below:
def prefer_best(): if self.params.get('simulate', False): return False if not download: return False if self.params.get('outtmpl', DEFAULT_OUTTMPL) == '-': return True if info_dict.get('is_live'): return True if not can_merge(): return True return False
So actually there are several cases where the default format should be changed, and isn't, when
simulateis set, or when no download is requested (normally not through the CLI). Arguably the first two tests should be moved after the tests that returnTrue.-
I'm a little hazy as to why one would want to use
--simulatebecause all it basically tells you is that the extractor didn't (with luck) crash. If you want to know, say, what format(s) will be selected there is--get-formator eqv.Yeah, the issue is really about the
simulateparam rather than just the--simulateCLI flagWell, I think the third result (without the simulate/download tests) is correct and the second not:
$ python -m youtube_dl --get-format 'BaW_jenozKc' 248 - 1920x1080 (1080p)+140 - audio only (audio_quality_medium) $ python -m youtube_dl --get-format -o - 'BaW_jenozKc' 248 - 1920x1080 (1080p)+140 - audio only (audio_quality_medium) $ python -m youtube_dl --get-format -o - 'BaW_jenozKc' 22 - 1280x720 (720p) $
- added a commit that references this issue
on May 4, 2024 In case users of the API rely on the historic behaviour when
downloadis falsy, that can be left in place, as it's always truthy in the CLI (at least it is upstream).Imo, since we are breaking compat anyway, it's more consistent to completely get rid of this behavior. Although not the recommended approach, I have often seen
extract_info(URL, download=False)to get metadata and thendownload(URL)in the wild.- added a commit that references this issue
on Jul 9, 2024
DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE
Checklist
Provide a description that is worded well enough to be understood
When running a yt-dlp command with
--simulate(and without an-farg), the default format selection differs from an unsimulated run under any of these conditions:---live-from-startwas not passed)A dry-run/simulate option should actually simulate the behaviour that will occur when downloading.
This behaviour is currently undocumented. Either the behaviour should be changed or at the very least be documented.
Copying initial discussion: #9805 (comment)
It looks like we can trace this logic back to ytdl-org/youtube-dl@0017d9a
Back then, upstream's default format spec was only
bestif ffmpeg was not available. So a simulated run would result in a "requested formats not available" error if ffmpeg was not available and there was no combined video+audio format available. Thissimulatecheck seems to be added so that you could print json without having to manually pass-f bv+baor-f bvetc in this scenario -- see the linked upstream PRProvide verbose output that clearly demonstrates the problem
yt-dlp -vU <your command line>)'verbose': TruetoYoutubeDLparams instead[debug] Command-line config) and insert it belowComplete Verbose Output