--simulate doesn't accurately simulate downloading under certain conditions

[seproDev]

DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE

• I understand that I will be blocked if I intentionally remove or skip any mandatory* field

Checklist

• I'm reporting a bug unrelated to a specific site
• I've verified that I have updated yt-dlp to nightly or master (update instructions)
• I've checked that all provided URLs are playable in a browser with the same IP and same login details
• I've checked that all URLs and arguments with special characters are properly quoted or escaped
• I've searched known issues and the bugtracker for similar issues including closed ones. DO NOT post duplicates
• I've read the guidelines for opening an issue

Provide a description that is worded well enough to be understood

When running a yt-dlp command with --simulate (and without an -f arg), the default format selection differs from an unsimulated run under any of these conditions:

• ffmpeg is not available
• the outtmpl is -
• the URL is for a livestream (and --live-from-start was 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 best if 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. This simulate check seems to be added so that you could print json without having to manually pass -f bv+ba or -f bv etc in this scenario -- see the linked upstream PR

Provide verbose output that clearly demonstrates the problem

• Run your yt-dlp command with -vU flag added (yt-dlp -vU <your command line>)
• If using API, add 'verbose': True to YoutubeDL params instead
• Copy the WHOLE output (starting with [debug] Command-line config) and insert it below

Complete Verbose Output

[debug] Command-line config: ['-vU', '--simulate', 'https://www.youtube.com/watch?v=2yJgwwDcgV8']
[debug] Encodings: locale cp1252, fs utf-8, pref cp1252, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version master@2024.04.28.221944 from yt-dlp/yt-dlp-master-builds [ac817bc83] (win_exe)
[debug] Python 3.8.10 (CPython AMD64 64bit) - Windows-10-10.0.22631-SP0 (OpenSSL 1.1.1k  25 Mar 2021)
[debug] exe versions: none
[debug] Optional libraries: Cryptodome-3.20.0, brotli-1.1.0, certifi-2024.02.02, curl_cffi-0.5.10, mutagen-1.47.0, requests-2.31.0, sqlite3-3.35.5, urllib3-2.2.1, websockets-12.0
[debug] Proxy map: {}
[debug] Request Handlers: urllib, requests, websockets, curl_cffi
[debug] Loaded 1810 extractors
[debug] Fetching release info: https://api.github.com/repos/yt-dlp/yt-dlp-master-builds/releases/latest
Latest version: master@2024.04.28.221944 from yt-dlp/yt-dlp-master-builds
yt-dlp is up to date (master@2024.04.28.221944 from yt-dlp/yt-dlp-master-builds)
[youtube] Extracting URL: https://www.youtube.com/watch?v=2yJgwwDcgV8
[youtube] 2yJgwwDcgV8: Downloading webpage
[youtube] 2yJgwwDcgV8: Downloading ios player API JSON
[youtube] 2yJgwwDcgV8: Downloading android player API JSON
WARNING: [youtube] Skipping player responses from android clients (got player responses for video "aQvGIIdgFDM" instead of "2yJgwwDcgV8")
[debug] Loading youtube-nsig.7d1f7724 from cache
[debug] [youtube] Decrypted nsig ZyUwo2vdMccktm7tN0 => ZvGvrjLHlKzcbw
[debug] Loading youtube-nsig.7d1f7724 from cache
[debug] [youtube] Decrypted nsig vYdxycJ0vBBgWEBA_9 => Etq9qDUH370hPg
[youtube] 2yJgwwDcgV8: Downloading m3u8 information
[debug] Sort order given by extractor: quality, res, fps, hdr:12, source, vcodec:vp9.2, channels, acodec, lang, proto
[debug] Formats sorted by: hasvid, ie_pref, quality, res, fps, hdr:12(7), source, vcodec:vp9.2(10), channels, acodec, lang, proto, size, br, asr, vext, aext, hasaud, id
[debug] Default format spec: bestvideo*+bestaudio/best
[info] 2yJgwwDcgV8: Downloading 1 format(s): 244+251

[pukkandan]

cc @dirkf

[dirkf]

I'm a little hazy as to why one would want to use --simulate because 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-format or 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.

1. The API param simulate is also forced to true when a "printing" option such as --get-format is selected. This would give the wrong answer if the default format selection was changed by simulate.

2. The default format is changed to best/bestvideo+bestaudio as 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 simulate is set, or when no download is requested (normally not through the CLI). Arguably the first two tests should be moved after the tests that return True.

[bashonly]

I'm a little hazy as to why one would want to use --simulate because 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-format or eqv.

Yeah, the issue is really about the simulate param rather than just the --simulate CLI flag

[dirkf]

Well, 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)
$ 

[pukkandan]

Re: 96da952#r141681868

In case users of the API rely on the historic behaviour when download is 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 then download(URL) in the wild.