[facebook] Cannot parse data

Checklist

[X] I'm reporting a broken site
[X] I've verified that I'm running yt-dlp version 2022.06.29 (update instructions) or later (specify commit)
[X] I've checked that all provided URLs are playable in a browser with the same IP and same login details
[X] I've checked that all URLs and arguments with special characters are properly quoted or escaped
[X] I've searched the bugtracker for similar issues including closed ones. DO NOT post duplicates
[X] I've read the guidelines for opening an issue
[X] I've read about sharing account credentials and I'm willing to share it if required

Region
Bangladesh
Provide a description that is worded well enough to be understood
Downloading worked perfectly fine a just few days ago but now any facebook video link in "facebook.com/. . ./ videos/ . . ." format throws this error.
I have checked a similar type of issue #4289 , but it works fine on my side. The aforementioned link format, however, shows this error
Provide verbose output that clearly demonstrates the problem

[X] Run your yt-dlp command with -vU flag added (yt-dlp -vU <your command line>)
[X] Copy the WHOLE output (starting with [debug] Command-line config) and insert it below

Complete Verbose Output
❯ yt-dlp.exe -vU "https://www.facebook.com/100015388953240/videos/424804832900683/"
[debug] Command-line config: ['-vU', 'https://www.facebook.com/100015388953240/videos/424804832900683/']
[debug] Encodings: locale cp1252, fs utf-8, pref cp1252, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version 2022.06.29 [9d339c4] (win32_exe)
[debug] Python 3.8.10 (CPython 64bit) - Windows-10-10.0.19044-SP0
[debug] Checking exe version: ffmpeg -bsfs
[debug] Checking exe version: ffprobe -bsfs
[debug] exe versions: ffmpeg 5.0-full_build-www.gyan.dev (setts), ffprobe 5.0-full_build-www.gyan.dev
[debug] Optional libraries: Cryptodome-3.15.0, brotli-1.0.9, certifi-2022.06.15, mutagen-1.45.1, sqlite3-2.6.0, websockets-10.3
[debug] Proxy map: {}
[debug] Fetching release info: https://api.github.com/repos/yt-dlp/yt-dlp/releases/latest
[debug] Downloading _update_spec from https://github.com/yt-dlp/yt-dlp/releases/download/2022.06.29/_update_spec
Latest version: 2022.06.29, Current version: 2022.06.29
yt-dlp is up to date (2022.06.29)
[debug] [facebook] Extracting URL: https://www.facebook.com/100015388953240/videos/424804832900683/
[facebook]<PHONE_NUMBER>00683: Downloading webpage
[facebook]<PHONE_NUMBER>00683: Downloading webpage
ERROR: [facebook]<PHONE_NUMBER>00683: Cannot parse data; please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= , filling out the appropriate issue template. Confirm you are on the latest version using  yt-dlp -U
  File "yt_dlp\extractor\common.py", line 640, in extract
  File "yt_dlp\extractor\facebook.py", line 713, in _real_extract
  File "yt_dlp\extractor\facebook.py", line 659, in _extract_from_url

Has the video been deleted, or does it require an account? (Please don't share your login details)

Uhh no the video is up there, public
Specifically I found that, it isn't able to download when the link is like  facebook.com/ [some number] /video/ . . .
but when I try to download the same video with the same link on an online  video downloader site (savefrom.net  as an example) ,  it does the job just fine.

Verify from incognito. If the content is private, pass cookies to yt-dlp

Well, the content is not private, its shared to a public group. Online downloader sites works just fine.
However, I attempted with --cookies  and also --cookies-from-browser flags to pass cookies, but its the same error.

Both me and gamer191 are getting this though

Maybe geo-restricted?

Okay, so this time I logged out of my account and then tried to access it and got the same "content isn't available" prompt.
Although the group is public, i guess these contents can be accessed when you're logged into an account.
And not specifically this group, I've tried with other content links as well. Some contents can be downloaded and some others show parsing error.
If those were private content, passing cookies should have solved it.
It worked just fine a few weeks ago, even without passing cookies. Now I don't know where exactly the problem lies.
Thanks for your valuable time.

@SillyCatto Try with --username USERNAME (it will automatically ask for your password). Also use --twofactor TWOFACTOR if you have 2 factor authentication set up

Here ,

Okay, so this time I logged out of my account and then tried to access it and got the same "content isn't available" prompt.

 I specifically asked you to check in incognito!

Check with cookies. If it works, duplicate of https://github.com/yt-dlp/yt-dlp/issues/4101

Tried in incognito

I got that. I was just ranting about how you didn't do that the first time

I'm having the same issue.  This worked for me two weeks ago.  For the past two weeks I get this error.  I've tried a few different Facebook videos (all private videos) and they get the same error.
yt-dlp.exe -vU --cookies facebook.com_cookies.txt https://m.facebook.com/groups/1431367000434525/permalink/3184874755083732/?_rdr
[debug] Command-line config: ['-vU', '--cookies', 'facebook.com_cookies.txt', 'https://m.facebook.com/groups/1431367000434525/permalink/3184874755083732/?_rdr']
[debug] Encodings: locale cp1252, fs utf-8, pref cp1252, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version 2022.06.29 [9d339c4] (win32_exe)
[debug] Python 3.8.10 (CPython 64bit) - Windows-10-10.0.19044-SP0
[debug] Checking exe version: ffmpeg -bsfs
[debug] Checking exe version: avconv -bsfs
[debug] Checking exe version: ffprobe -bsfs
[debug] Checking exe version: avprobe -bsfs
[debug] exe versions: none
[debug] Optional libraries: Cryptodome-3.15.0, brotli-1.0.9, certifi-2022.06.15, mutagen-1.45.1, sqlite3-2.6.0, websockets-10.3
[debug] Proxy map: {}
[debug] Fetching release info: https://api.github.com/repos/yt-dlp/yt-dlp/releases/latest
[debug] Downloading _update_spec from https://github.com/yt-dlp/yt-dlp/releases/download/2022.06.29/_update_spec
Latest version: 2022.06.29, Current version: 2022.06.29
yt-dlp is up to date (2022.06.29)
[debug] [facebook] Extracting URL: https://m.facebook.com/groups/1431367000434525/permalink/3184874755083732/?_rdr
[facebook]<PHONE_NUMBER>083732: Downloading webpage
[facebook]<PHONE_NUMBER>083732: Downloading webpage
ERROR: [facebook]<PHONE_NUMBER>083732: Cannot parse data; please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= , filling out the appropriate issue template. Confirm you are on the latest version using  yt-dlp -U
  File "yt_dlp\extractor\common.py", line 640, in extract
  File "yt_dlp\extractor\facebook.py", line 713, in _real_extract
  File "yt_dlp\extractor\facebook.py", line 659, in _extract_from_url

Same here, but i got a different error:
ERROR: [facebook]<PHONE_NUMBER>55090: Unable to extract lsd; please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= , filling out the appropriate issue template. Confirm you are on the latest version using  yt-dlp -U
  File "/usr/lib/python3.10/site-packages/yt_dlp/extractor/common.py", line 642, in extract
    self.initialize()
  File "/usr/lib/python3.10/site-packages/yt_dlp/extractor/common.py", line 548, in initialize
    self._perform_login(username, password)
  File "/usr/lib/python3.10/site-packages/yt_dlp/extractor/facebook.py", line 335, in _perform_login
    lsd = self._search_regex(
  File "/usr/lib/python3.10/site-packages/yt_dlp/extractor/common.py", line 1194, in _search_regex
    raise RegexNotFoundError('Unable to extract %s' % _name)

os: arch linux with 5.18.14-arch1-1 kernel
yt-dlp version: 2022.07.18

I have same and this link works (video is playing) in Firefox private tab.
In yt-dlp it is forwarded to https://www.facebook.com/100056421282594/videos/784057722750292/ - which doesn't play in incognito tab in Firefox.
$ yt-dlp -Uv https://www.facebook.com/groups/199346028164827/posts/837033841062706/
[debug] Command-line config: ['-Uv', 'https://www.facebook.com/groups/199346028164827/posts/837033841062706/']
[debug] Encodings: locale UTF-8, fs utf-8, pref UTF-8, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version 2022.07.18 [135f05e] (zip)
[debug] Python 3.10.5 (CPython 64bit) - Linux-5.18.13-200.fc36.x86_64+debug-x86_64-with-glibc2.35 (glibc 2.35)
[debug] Checking exe version: ffmpeg -bsfs
[debug] Checking exe version: ffprobe -bsfs
[debug] exe versions: ffmpeg 5.0.1 (setts), ffprobe 5.0.1
[debug] Optional libraries: Cryptodome-3.15.0, brotli-1.0.9, certifi-2021.10.08, mutagen-1.45.1, sqlite3-2.6.0, websockets-10.1
[debug] Proxy map: {}
[debug] Fetching release info: https://api.github.com/repos/yt-dlp/yt-dlp/releases/latest
Latest version: 2022.07.18, Current version: 2022.07.18
yt-dlp is up to date (2022.07.18)
[debug] [generic] Extracting URL: https://www.facebook.com/groups/199346028164827/posts/837033841062706/
[generic]<PHONE_NUMBER>62706: Downloading webpage
WARNING: [generic] Falling back on generic information extractor.
[generic]<PHONE_NUMBER>62706: Extracting information
[debug] Looking for video embeds
[debug] Identified a twitter:player iframe
[debug] [FacebookPluginsVideo] Extracting URL: https://www.facebook.com/plugins/video.php?height=426&width=238&href=https://www.facebook.com/100056421282594/videos/784057722750292/
[debug] [facebook] Extracting URL: https://www.facebook.com/100056421282594/videos/784057722750292/
[facebook]<PHONE_NUMBER>50292: Downloading webpage
[facebook]<PHONE_NUMBER>50292: Downloading webpage
ERROR: [facebook]<PHONE_NUMBER>50292: Cannot parse data; please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= , filling out the appropriate issue template. Confirm you are on the latest version using  yt-dlp -U
  File "/usr/local/bin/yt-dlp/yt_dlp/extractor/common.py", line 644, in extract
    ie_result = self._real_extract(url)
  File "/usr/local/bin/yt-dlp/yt_dlp/extractor/facebook.py", line 713, in _real_extract
    return self._extract_from_url(real_url, video_id)
  File "/usr/local/bin/yt-dlp/yt_dlp/extractor/facebook.py", line 659, in _extract_from_url
    raise ExtractorError('Cannot parse data')

I am pretty sure it's an account-related problem, excessive use of yt-dlp can cause some kind of "invisible ban".
Attempting to use the cookies of an account with this kind of "ban" (even with public videos that are downloaded normally with no cookies on the same machine) will result in the error mentioned in this issue, another attempt within 0 - 10 minutes will lock the account and "someone may have tried to access your account".
In the past (until about a few months ago) you could easily know you currently have this kind of "ban" as almost every non-public video you normally have access to would give "content isn't available at the moment", and you could easily know when it ends.
Currently, everything works as expected on browser but using yt-dlp with cookies causes the aforementioned error, and there is no way to know if the "ban" has ended other than trial and error.
I am 95% sure about this, but the only way to prove this theory is to use a clean account on a clean IP.

As mentioned in https://github.com/yt-dlp/yt-dlp/issues/4477#issuecomment-1200612649, youtube-dl works, but yt-dlp doesn't. So it's caused by a regression, not Facebook "banning" you.

youtube-dl (https://yt-dl.org/downloads/2021.12.17/youtube-dl) doesn't work for my link above. Have same error.

I see mentions of generic extractor and twitter:player in the log - is it correct?

I use yt-dlp without cookies and video is available without FB account, so my account can't (?) be related.
IP address can be related: checked it with proxy. The error is different in this case, seems like FB requires login for some reason:

$ yt-dlp --proxy socks5://<IP_ADDRESS>:43322 -v https://www.facebook.com/groups/199346028164827/posts/837033841062706/
[debug] Command-line config: ['--proxy', 'socks5://<IP_ADDRESS>:43322', '-v', 'https://www.facebook.com/groups/199346028164827/posts/837033841062706/']
[debug] Encodings: locale UTF-8, fs utf-8, pref UTF-8, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version 2022.07.18 [135f05e] (zip)
[debug] Python 3.10.5 (CPython 64bit) - Linux-5.18.13-200.fc36.x86_64+debug-x86_64-with-glibc2.35 (glibc 2.35)
[debug] Checking exe version: ffmpeg -bsfs
[debug] Checking exe version: ffprobe -bsfs
[debug] exe versions: ffmpeg 5.0.1 (setts), ffprobe 5.0.1
[debug] Optional libraries: Cryptodome-3.15.0, brotli-1.0.9, certifi-2021.10.08, mutagen-1.45.1, sqlite3-2.6.0, websockets-10.1
[debug] Proxy map: {'http': 'socks5://<IP_ADDRESS>:43322', 'https': 'socks5://<IP_ADDRESS>:43322'}
[debug] [generic] Extracting URL: https://www.facebook.com/groups/199346028164827/posts/837033841062706/
[generic]<PHONE_NUMBER>62706: Downloading webpage
[redirect] Following redirect to https://www.facebook.com/login/?next=https%3A%2F%2Fwww.facebook.com%2Fgroups%2F199346028164827%2Fposts%2F837033841062706%2F
[debug] [generic] Extracting URL: https://www.facebook.com/login/?next=https%3A%2F%2Fwww.facebook.com%2Fgroups%2F199346028164827%2Fposts%2F837033841062706%2F
[generic] ?next=https://www.facebook: Downloading webpage
WARNING: [generic] Falling back on generic information extractor.
[generic] ?next=https://www.facebook: Extracting information
[debug] Looking for video embeds
[redirect] Following redirect to https://www.facebook.com/login/?next=https%3A%2F%2Fwww.facebook.com%2Fgroups%2F199346028164827%2Fposts%2F837033841062706%2F&_fb_noscript=1
[debug] [generic] Extracting URL: https://www.facebook.com/login/?next=https%3A%2F%2Fwww.facebook.com%2Fgroups%2F199346028164827%2Fposts%2F837033841062706%2F&_fb_noscript=1
[generic] ?next=https://www.facebook: Downloading webpage
WARNING: [generic] Falling back on generic information extractor.
[generic] ?next=https://www.facebook: Extracting information
[debug] Looking for video embeds
ERROR: Unsupported URL: https://www.facebook.com/login/?next=https%3A%2F%2Fwww.facebook.com%2Fgroups%2F199346028164827%2Fposts%2F837033841062706%2F&_fb_noscript=1
Traceback (most recent call last):
  File "/usr/local/bin/yt-dlp/yt_dlp/YoutubeDL.py", line 1431, in wrapper
    return func(self, *args, **kwargs)
  File "/usr/local/bin/yt-dlp/yt_dlp/YoutubeDL.py", line 1506, in __extract_info
    ie_result = ie.extract(url)
  File "/usr/local/bin/yt-dlp/yt_dlp/extractor/common.py", line 644, in extract
    ie_result = self._real_extract(url)
  File "/usr/local/bin/yt-dlp/yt_dlp/extractor/generic.py", line 4108, in _real_extract
    raise UnsupportedError(url)
yt_dlp.utils.UnsupportedError: Unsupported URL: https://www.facebook.com/login/?next=https%3A%2F%2Fwww.facebook.com%2Fgroups%2F199346028164827%2Fposts%2F837033841062706%2F&_fb_noscript=1

@ohhai Bruh! So what you are saying is your issue is off topic for this thread? The conditions to reproduce are not the same, the error message is not the same... What made you think it's the same issue?

and video is available without FB account,

test with the same proxy you are using

@pukkandan  conditions are same - just downloading FB video. Error messages are same as well - "Cannot parse data".
Tested this video in browser with same proxy and it does not play and requires login. Incredible.
OK, it still is not clear for me:

browser w/o proxy, no cookies: video plays
yt-dlp w/o proxy, no cookies: doesn't play

I am pretty sure it's an account-related problem, excessive use of yt-dlp can cause some kind of "invisible ban".
Attempting to use the cookies of an account with this kind of "ban" (even with public videos that are downloaded normally with no cookies on the same machine) will result in the error mentioned in this issue, another attempt within 0 - 10 minutes will lock the account and "someone may have tried to access your account".
In the past (until about a few months ago) you could easily know you currently have this kind of "ban" as almost every non-public video you normally have access to would give "content isn't available at the moment", and you could easily know when it ends. Currently, everything works as expected on browser but using yt-dlp with cookies causes the aforementioned error, and there is no way to know if the "ban" has ended other than trial and error.
I am 95% sure about this, but the only way to prove this theory is to use a clean account on a clean IP.

Tried using a proxy server, but that did not make any difference.  Going to try with a clean account if I can.... need to get the account added to the private Facebook group.

Going to add here that using yt-dlp to try to download a reel has locked me out of my Facebook account. I am jumping through the hoops to get it back but be cautious as it's very much not worth getting a few min video to jump through Facebook security hoops.
I also do not understand why it is doing this when I have 2fa enabled... smh

Going to add here that using yt-dlp to try to download a reel has locked me out of my Facebook account. I am jumping through the hoops to get it back but be cautious as it's very much not worth getting a few min video to jump through Facebook security hoops.
I also do not understand why it is doing this when I have 2fa enabled... smh

Noticed the same thing trying to download the same video multiple times

I am pretty sure it's an account-related problem, excessive use of yt-dlp can cause some kind of "invisible ban".
Attempting to use the cookies of an account with this kind of "ban" (even with public videos that are downloaded normally with no cookies on the same machine) will result in the error mentioned in this issue, another attempt within 0 - 10 minutes will lock the account and "someone may have tried to access your account".
In the past (until about a few months ago) you could easily know you currently have this kind of "ban" as almost every non-public video you normally have access to would give "content isn't available at the moment", and you could easily know when it ends. Currently, everything works as expected on browser but using yt-dlp with cookies causes the aforementioned error, and there is no way to know if the "ban" has ended other than trial and error.
I am 95% sure about this, but the only way to prove this theory is to use a clean account on a clean IP.

This theory is only partially correct in my case. I tried with this public video in the following scenarios:

yt-dlp 2021.12.01 + with cookies -> success
yt-dlp 2021.12.01 + no cookies -> success
yt-dlp 2021.12.25 (or above) + with cookies -> failed
yt-dlp 2021.12.25 (or above) + no cookies -> success
youtube-dl 2021.12.17 + with cookies -> success
youtube-dl 2021.12.17 + no cookies -> success

I'm pretty sure this is a regression in yt-dlp 2021.12.25

...

The hypothesis (the correct word) is correct.  Facebook blocks according to how many you have watched (using non-Facebook apps) or downloaded the videos.

...

The hypothesis (the correct word) is correct. Facebook blocks according to how many you have watched (using non-Facebook apps) or downloaded the videos.

 I know my terminology and your pedantry is irrelevant since we are not writing a scientific paper.
The problem is a combination of regression (like many said) and something Facebook actively did/does since versions that used to work aren't working any longer and previous versions do.

...

The hypothesis (the correct word) is correct. Facebook blocks according to how many you have watched (using non-Facebook apps) or downloaded the videos.

 I know my terminology and your pedantry is irrelevant since we are not writing a scientific paper.
The problem is a combination of regression (like many said) and something Facebook actively did/does since versions that used to work aren't working any longer and previous versions do.

No, you are wrong. For example youtube-dl 2021.12.17 doesn't work (with cookies or without cookies). It can work the first time, or even the second time, but not more, Facebook blocks !

Actually, true. Something has changed in Facebook (again) and now not even youtube-dl is able to download it. Moreover, Facebook has been actively locking accounts if you use --cookies. Better to be safe than sorry. 🙂

So no solution?

So no solution?

No, you can change your IP or using a proxy but again, it only works one or two times, no more that.

I can confirm youtube-dl works while yt-dlp does not.  I have downloaded a few random videos with youtube-dl without any issue, while yt-dlp keep saying Cannot parse data.

I have two very similar addresses/sources. The first one works properly, the second (is a character shorter 😲) doesn't:
- works:
  $ yt-dlp -F https://www.facebook.com/reel/3134999970123716
	or    https://www.facebook.com/haniksport/videos/3134999970123716 (redirection to the previous)
- doesn't:
  $ yt-dlp -F https://www.facebook.com/reel/685477723183696
	or    https://www.facebook.com/haniksport/videos/685477723183696 (redirection to the previous)

output from the failed command:
$ yt-dlp -vU -F https://www.facebook.com/reel/685477723183696
[debug] Command-line config: ['-vU', '-F', 'https://www.facebook.com/reel/685477723183696']
[debug] Encodings: locale UTF-8, fs utf-8, pref UTF-8, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version 2022.11.11 [8b64402] (pip)
[debug] Python 3.10.9 (CPython x86_64 64bit) - Linux-5.18.0-x86_64-with-glibc2.35 (OpenSSL 3.0.7 1 Nov 2022, glibc 2.35)
[debug] exe versions: ffmpeg 4.4.2 (setts), ffprobe 4.4.2, rtmpdump 2.4
[debug] Optional libraries: Cryptodome-3.15.0, brotli-1.0.9, certifi-2022.12.07, mutagen-1.46.0, sqlite3-2.6.0, websockets-10.3
[debug] Proxy map: {}
[debug] Loaded 1723 extractors
[debug] Fetching release info: https://api.github.com/repos/yt-dlp/yt-dlp/releases/latest
Latest version: 2023.01.02, Current version: 2022.11.11
[debug] Downloading _update_spec from https://github.com/yt-dlp/yt-dlp/releases/download/2023.01.02/_update_spec
ERROR: You installed yt-dlp with pip or using the wheel from PyPi; Use that to update
[debug] [facebook:reel] Extracting URL: https://www.facebook.com/reel/685477723183696
[debug] [facebook] Extracting URL: https://m.facebook.com/watch/?v=685477723183696&_rdr
[facebook]<PHONE_NUMBER>83696: Downloading webpage
[facebook]<PHONE_NUMBER>83696: Downloading webpage
ERROR: [facebook]<PHONE_NUMBER>83696: Cannot parse data; please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= , filling out the appropriate issue template. Confirm you are on the latest version using  yt-dlp -U
  File "/nix/store/lndn110lyfzz5rqn2lv4rp1m2ppkiify-python3.10-yt-dlp-2022.11.11/lib/python3.10/site-packages/yt_dlp/extractor/common.py", line 674, in extract
    ie_result = self._real_extract(url)
  File "/nix/store/lndn110lyfzz5rqn2lv4rp1m2ppkiify-python3.10-yt-dlp-2022.11.11/lib/python3.10/site-packages/yt_dlp/extractor/facebook.py", line 705, in _real_extract
    return self._extract_from_url(real_url, video_id)
  File "/nix/store/lndn110lyfzz5rqn2lv4rp1m2ppkiify-python3.10-yt-dlp-2022.11.11/lib/python3.10/site-packages/yt_dlp/extractor/facebook.py", line 651, in _extract_from_url
    raise ExtractorError('Cannot parse data')

- doesn't:
  $ yt-dlp -F https://www.facebook.com/reel/685477723183696
	or    https://www.facebook.com/haniksport/videos/685477723183696 (redirection to the previous)

Can you play this video in browser without being logged in?
In my browser I get this:

This Video Isn't Available Anymore
The link may be broken or the video may have been removed. You can explore more videos or try logging into facebook.com and then visiting the link again.

You could try passing cookies. and/or verify that the URL is correct and the video still exists

@bashonly: You're right. The second address requires a login. Sorry 🙈

Seal was working pretty good with facebook and youtube but now it just stopped downloading from facebook
Any link gets an error
But YouTube works fine
I get this error
App version: 1.7.3 (10730)
Device information: Android 13 (API 33)
Supported ABIs: [arm64-v8a, armeabi-v7a, armeabi]
Yt-dlp version: 2023.01.06
URL: https://www.facebook.com/mohammed.abdelhalim.794/videos/3053042581661283/
ERROR: [facebook]<PHONE_NUMBER>661283: Cannot parse data; please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= , filling out the appropriate issue template. Confirm you are on the latest version using  yt-dlp -U
/I have tried all Seal versions and having same issue/

@omarmohamedmoustafa facebook does enforce a rate-limit on how many posts are able to view when not logged in. I can download that link without issue. Does that video load for you in your browser when not logged in? (use private/incognito tab)

@omarmohamedmoustafa facebook does enforce a rate-limit on how many posts you are able to view when not logged in. I can download that link without issue. Does that video load for you in your browser when not logged in? (use private/incognito tab)

Yes it does load in an incognito tab easily

FYI, I'm using the latest yt-dlp pip package and it has the same Cannot parse data error. And this is a public video:
λ yt-dlp --verbose https://www.facebook.com/OhMyGoal.KeliNetwork/videos/1365011847657288

[debug] Command-line config: ['--verbose', 'https://www.facebook.com/OhMyGoal.KeliNetwork/videos/1365011847657288']
[debug] Encodings: locale UTF-8, fs utf-8, pref UTF-8, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version 2023.01.06 [6becd25] (pip)
[debug] Python 3.11.0 (CPython x86_64 64bit) - macOS-12.5-x86_64-i386-64bit (OpenSSL 3.0.7 1 Nov 2022)
[debug] exe versions: ffmpeg 5.1.2 (setts), ffprobe 5.1.2
[debug] Optional libraries: Cryptodome-3.17, brotli-1.0.9, certifi-2022.09.24, mutagen-1.46.0, sqlite3-2.6.0, websockets-10.4
[debug] Proxy map: {}
[debug] Loaded 1760 extractors
[facebook] Extracting URL: https://www.facebook.com/OhMyGoal.KeliNetwork/videos/1365011847657288
[facebook]<PHONE_NUMBER>657288: Downloading webpage
[facebook]<PHONE_NUMBER>657288: Downloading webpage
ERROR: [facebook]<PHONE_NUMBER>657288: Cannot parse data; please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= , filling out the appropriate issue template. Confirm you are on the latest version using  yt-dlp -U
  File "/opt/homebrew/Caskroom/miniforge/base/envs/py311/lib/python3.11/site-packages/yt_dlp/extractor/common.py", line 680, in extract
    ie_result = self._real_extract(url)
                ^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Caskroom/miniforge/base/envs/py311/lib/python3.11/site-packages/yt_dlp/extractor/facebook.py", line 703, in _real_extract
    return self._extract_from_url(real_url, video_id)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Caskroom/miniforge/base/envs/py311/lib/python3.11/site-packages/yt_dlp/extractor/facebook.py", line 650, in _extract_from_url
    raise ExtractorError('Cannot parse data')

Looks like this is what happened to me, and I'm not even using cookies, just anonymous download:

I am pretty sure it's an account-related problem, excessive use of yt-dlp can cause some kind of "invisible ban".

And I think this could be the root cause?

Noticed the same thing trying to download the same video multiple times

This seems correct since I tried switching my internet connection from wifi to mobile data (via hotspot), and the issue is gone!

No, you can change your IP or using a proxy but again it only works one or two times, no more that 🙁

So, in my case, it's because I'm downloading the same video multiple times because I created a Python package and testing the codes against the same set of test URLs, which includes a Facebook video URL. This probably triggered the rate limits.
I have proven this IP thing also since I used the scraping ideas from fb-video-downloader in my package as the custom downloader for FB URLs since yt-dlp currently has issue with FB. It was working yesterday, then suddenly it's not working today without any code change! So, it's the same scenario with FB blocking my IP when I used yt-dlp before: it was working one day, then suddenly there's issue in the next day, and no code change.
I inspected also the HTML response when the IP is "blocked". Turned out that some critical page sections are missing, like the FBQualityLabel and "id": <VIDEO ID> which are the basis of  [fb-video-downloader](https://github.com/renanrgs/fb-video-downloader, and most likely also used by yt-dlp. These fragments are not there which triggers the Cannot parse data.
Likewise, I tried downloading different videos with my mobile data, but only once each time and it seems to be fine. Maybe the issue only happens if it's the same video being re-downloaded?
At least in my case, it means there's no bug in yt-dlp. Maybe an improvement for this is to include a WARNING in the README or in the program's output if the user is downloading an FB video? Something like:
Facebook may ban your IP, so don't use "yt-dlp" excessively or don't try to download the same video multiple times.

As mentioned, I tried with youtube-dl, and the Facebook videos downloaded fine without throwing the "Cannot parse data" error. I tried with over 20 videos, and it worked fine whereas yt-dlp continues to show that error.

Which is why it's marked as a regression...

This does not work with yt-dlp, but as a test, I downloaded the same private (group) video manually running youtube-dl -v --cookies "$HOME\Documents\ytdl-cookies\facebook_cookies.txt" somePrivateVideoUrl) over ten times in less than 5 minutes with no "shadow ban" so this is definitely a bug with youtube-dlp.

Though as a test, I downloaded the same private (group) video with youtube-dl manually running youtube-dl -v --cookies "$HOME\Documents\ytdl-cookies\facebook_cookies.txt" somePrivateVideoUrl) over ten times in less than 5 minutes with no "shadow ban" so this is definitely a bug with youtube-dlp.

Just adding another data point:
I had the same experience using your method. When I first tried yt-dlp with a cookie file, Facebook locked the entire account and I had to reactivate it from a different device. I then successfully downloaded 3 videos from a private group using youtube-dl and the command you gave above.
yt-dlp version 2023.03.04
youtube-dl version 2021.12.17

I'm having the same issue with public videos. Even without --cookies.
λ yt-dlp -vU "https://m.facebook.com/100047237161886/videos/827373744915230"
[debug] Command-line config: ['-vU', 'https://m.facebook.com/100047237161886/videos/827373744915230']
[debug] Encodings: locale cp1252, fs utf-8, pref cp1252, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version<EMAIL_ADDRESS>[392389b7d] (win_exe)
[debug] Python 3.8.10 (CPython AMD64 64bit) - Windows-10-10.0.19045-SP0 (OpenSSL 1.1.1k  25 Mar 2021)
[debug] exe versions: ffmpeg 6.0-essentials_build-www.gyan.dev (setts), ffprobe 6.0-essentials_build-www.gyan.dev
[debug] Optional libraries: Cryptodome-3.17, brotli-1.0.9, certifi-2022.12.07, mutagen-1.46.0, sqlite3-2.6.0, websockets-10.4
[debug] Proxy map: {}
[debug] Loaded 1786 extractors
[debug] Fetching release info: https://api.github.com/repos/yt-dlp/yt-dlp/releases/latest
Available version<EMAIL_ADDRESS>Current version<EMAIL_ADDRESS>Current Build Hash: 5590c57bd0433ed239a2deaaf92e2ad6f37fe50f53664c821575cafe106a9421
yt-dlp is up to date<EMAIL_ADDRESS>
[facebook] Extracting URL: https://m.facebook.com/100047237161886/videos/827373744915230
[facebook]<PHONE_NUMBER>15230: Downloading webpage
[facebook]<PHONE_NUMBER>15230: Downloading webpage
ERROR: [facebook]<PHONE_NUMBER>15230: Cannot parse data; please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= , filling out the appropriate issue template. Confirm you are on the latest version using  yt-dlp -U
  File "yt_dlp\extractor\common.py", line 694, in extract
  File "yt_dlp\extractor\facebook.py", line 703, in _real_extract
  File "yt_dlp\extractor\facebook.py", line 650, in _extract_from_url

After an IP change it seems to be working fine again. However, as I said, I haven't tried downloading anything before it failed. So it doesn't seem to be a block due to "many downloads".
I've logged both requests and files. Maybe this helps in some way @pukkandan.
notworking.log
notworking_359649331226507_https_-www.facebook.com_WatchESLOne_videos_359649331226507 .dump.log
notworking_359649331226507_https_-_www.facebook.com_video_tahoe_async_359649331226507_chain=true_isvideo=true_payloadtype=primary.dump.log
working.log
working_359649331226507_https_-www.facebook.com_WatchESLOne_videos_359649331226507.dump.log
working_359649331226507_https_-_www.facebook.com_video_playback_dash_mpd_debug.mpdv=359649331226507_dummy=.mpd.dump.log

The issue is known to happen only on some IPs

I can confirm that youtube-dl can download facebook public videos using the generic extractor, while current yt-dlp cannot, with the "cannot parse" infamous message.
Just checked on:
https://www.facebook.com/reel/1433316224146708/?s=ifu

The issue suddenly emerged when trying to download the video at https://fb.watch/lvnR3xSUPP/
ERROR: [facebook]<PHONE_NUMBER>284372: Cannot parse data
yt-dlp version 2023.06.22
debug info
[debug] Command-line config: ['--proxy', 'localhost:3128', '--no-check-certificates', '--geo-bypass', '--simulate', '-v', 'https://fb.watch/lvnR3xSUPP/'] [debug] Encodings: locale UTF-8, fs utf-8, pref UTF-8, out utf-8, error utf-8, screen utf-8 [debug] yt-dlp version<EMAIL_ADDRESS>[812cdfa06] (darwin_legacy_exe) [debug] Python 3.10.5 (CPython x86_64 64bit) - macOS-10.9.5-x86_64-i386-64bit (OpenSSL 1.1.1n  15 Mar 2022) [debug] exe versions: ffmpeg N-101508-ge93403b (setts), ffprobe N-101508-ge93403b [debug] Optional libraries: Cryptodome-3.18.0, brotli-1.0.9, certifi-2023.05.07, mutagen-1.46.0, sqlite3-2.6.0, websockets-11.0.3 [debug] Proxy map: {'http': 'localhost:3128', 'https': 'localhost:3128'} [debug] Loaded 1851 extractors [generic] Extracting URL: https://fb.watch/lvnR3xSUPP/ [generic] lvnR3xSUPP: Downloading webpage [redirect] Following redirect to https://www.facebook.com/ImpactWrestling/videos/1217480652284372/ [facebook] Extracting URL: https://www.facebook.com/ImpactWrestling/videos/1217480652284372/ [facebook]<PHONE_NUMBER>284372: Downloading webpage [facebook]<PHONE_NUMBER>284372: Downloading webpage ERROR: [facebook]<PHONE_NUMBER>284372: Cannot parse data; please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= , filling out the appropriate issue template. Confirm you are on the latest version using  yt-dlp -U   File "yt_dlp/extractor/common.py", line 708, in extract   File "yt_dlp/extractor/facebook.py", line 707, in _real_extract   File "yt_dlp/extractor/facebook.py", line 654, in _extract_from_url

Can confirm - it's working with youtube-dl
Get this chrome extension
https://chrome.google.com/webstore/detail/get-cookiestxt-locally/cclelndahbckbenkjhflpdbgdldlbecc
sign into facebook
run plugin
save file to txt
➜  bin git:(main) ✗ ./youtube-dl  https://www.facebook.com/video.php\?v\=771488304847683 --cookies=/home/ubuntu/sync/tiktok-signature/tiktok_signature/www.facebook.com_cookies.txt
[facebook]<PHONE_NUMBER>47683: Downloading webpage
[facebook]<PHONE_NUMBER>47683: Downloading webpage
WARNING: unable to extract OpenGraph title; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see  https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
WARNING: unable to extract og:image; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see  https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
[download] Destination: Facebook video #771488304847683-771488304847683.mp4
[download] 100% of 16.04MiB in 00:02

➜  bin git:(main) ✗ ./yt-dlp  https://www.facebook.com/video.php\?v\=771488304847683 --cookies=/home/ubuntu/sync/tiktok-signature/tiktok_signature/www.facebook.com_cookies.txt
[facebook] Extracting URL: https://www.facebook.com/video.php?v=771488304847683
[facebook]<PHONE_NUMBER>47683: Downloading webpage
[facebook]<PHONE_NUMBER>47683: Downloading webpage
ERROR: [facebook]<PHONE_NUMBER>47683: Cannot parse data; please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= , filling out the appropriate issue template. Confirm you are on the latest version using  yt-dlp -U

actually I'm using this with python and the youtube_dl fails too.

this makes me think the difference could be in the python version / SSL ciphers used rather than the extractor code

I think I may be running into this same issue (came to the Github to report it, then found my error already seemed to be listed in another issue that pointed to this one.
Here's my -vU output:
C:\Extra Programs>yt-dlp.exe -vU --no-check-certificate -F https://www.facebook.com/watch/?v=272028332136574 --cookies-from-browser firefox [debug] Command-line config: ['-vU', '--no-check-certificate', '-F', 'https://www.facebook.com/watch/?v=272028332136574', '--cookies-from-browser', 'firefox'] [debug] Encodings: locale cp932, fs utf-8, pref cp932, out utf-8, error utf-8, screen utf-8 [debug] yt-dlp version<EMAIL_ADDRESS>[b532a3481] (win_exe) [debug] Python 3.8.10 (CPython AMD64 64bit) - Windows-10-10.0.19045-SP0 (OpenSSL 1.1.1k  25 Mar 2021) [debug] exe versions: ffmpeg git-2019-12-26-b0d0d7e [debug] Optional libraries: Cryptodome-3.18.0, brotli-1.0.9, certifi-2023.05.07, mutagen-1.46.0, sqlite3-2.6.0, websockets-11.0.3 [Cookies] Extracting cookies from firefox [debug] Extracting cookies from: "C:\Users\---REDACTED---\AppData\Roaming\Mozilla\Firefox\Profiles\PVeqKIvp.default\cookies.sqlite" [Cookies] Extracted 2591 cookies from firefox [debug] Proxy map: {} [debug] Loaded 1855 extractors [debug] Fetching release info: https://api.github.com/repos/yt-dlp/yt-dlp/releases/latest Available version<EMAIL_ADDRESS>Current version<EMAIL_ADDRESS>Current Build Hash: 5ff3e702171a50175c34397494e2d18ce35d771c2110b1e59bd173ec2fb352aa yt-dlp is up to date<EMAIL_ADDRESS>[facebook] Extracting URL: https://www.facebook.com/watch/?v=272028332136574 [facebook]<PHONE_NUMBER>36574: Downloading webpage [facebook]<PHONE_NUMBER>36574: Downloading webpage ERROR: [facebook]<PHONE_NUMBER>36574: Cannot parse data; please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= , filling out the appropriate issue template. Confirm you are on the latest version using  yt-dlp -U   File "yt_dlp\extractor\common.py", line 710, in extract   File "yt_dlp\extractor\facebook.py", line 707, in _real_extract   File "yt_dlp\extractor\facebook.py", line 654, in _extract_from_url
The video is a stream of a news broadcast; I think it's behind a content warning due to either scenes of conflict in the program or a feature on a film art producer who killed himself, which is the last item in the show. It was on TV so I don't think there's anything that graphic, but in any case if you just look at the first few minutes you won't see anything problematic. I'm trying to download it for news reasons.
It doesn't play in an incognito window but it does when I'm logged in (so obviously skipping the cookies parameter doesn't help). --force-generic makes no difference. Neither does removing --no-check-certificate or -F from the start. I can't test it in youtube-dl as there seems to be a bug in my old version and I can't update it. I tried running it from a different IP address using a VPN and that also made no difference.

Per #7839, this error now occurs with nearly every FB URL

Thought this would be useful for this. This is me trying to download a a livestream.
`PS C:\Users\Admin\Desktop> ./yt-dlp.exe -vU -f bestvideo[height<=1080]+bestaudio https://www.facebook.com/Ramee/videos/671880558194304 -o "Ramee Aug 15 2023 Part 1.%(ext)s"
[debug] Command-line config: ['-vU', '-f', 'bestvideo[height<=1080]+bestaudio', 'https://www.facebook.com/Ramee/videos/671880558194304', '-o', 'Ramee Aug 15 2023 Part 1.%(ext)s']
[debug] Encodings: locale cp1252, fs utf-8, pref cp1252, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version<EMAIL_ADDRESS>[876b70c8e] (win_exe)
[debug] Python 3.8.10 (CPython AMD64 64bit) - Windows-10-10.0.19045-SP0 (OpenSSL 1.1.1k  25 Mar 2021)
[debug] exe versions: ffmpeg 2023-04-17-git-65e537b833-full_build-www.gyan.dev (setts), ffprobe 2023-04-17-git-65e537b833-full_build-www.gyan.dev
[debug] Optional libraries: Cryptodome-3.18.0, brotli-1.0.9, certifi-2023.07.22, mutagen-1.46.0, sqlite3-2.6.0, websockets-11.0.3
[debug] Proxy map: {}
[debug] Loaded 1863 extractors
[debug] Fetching release info: https://api.github.com/repos/yt-dlp/yt-dlp-nightly-builds/releases/latest
Available version<EMAIL_ADDRESS>Current version<EMAIL_ADDRESS>Current Build Hash: 7f7cdae9ae8c2706352e1ca2314642026bf5afeb6c20fb76ec3e79cbb5fc6256
yt-dlp is up to date<EMAIL_ADDRESS>[facebook] Extracting URL: https://www.facebook.com/Ramee/videos/671880558194304
[facebook]<PHONE_NUMBER>94304: Downloading webpage
[facebook]<PHONE_NUMBER>94304: Downloading webpage
ERROR: [facebook]<PHONE_NUMBER>94304: Cannot parse data; please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= , filling out the appropriate issue template. Confirm you are on the latest version using  yt-dlp -U
File "yt_dlp\extractor\common.py", line 715, in extract
File "yt_dlp\extractor\facebook.py", line 733, in _real_extract
File "yt_dlp\extractor\facebook.py", line 680, in _extract_from_url
PS C:\Users\Admin\Desktop>`

Per #7839, this error now occurs with nearly every FB URL

On second thought, I think I want to decouple the newly manifested issue that affects all FB URLs from this original issue, since PR #7890 will definitely resolve the new issue, but may not resolve the issue being discussed in here.

I have the same problem

Hii guys i'm facing the same issue "cannot parse data" is there any solution , because we are stucked in our product development.

Experiencing the same issue. Surprisingly, the latest version of youtube-dl can download Facebook videos, but yt-dlp cannot.

@UtopianElectronics can you share an example? I can't find any URLs that work with youtube-dl

Experiencing the same issue. Surprisingly, the latest version of youtube-dl can download Facebook videos, but yt-dlp cannot.

I tried youtube-dl 2021.12.17 and it does not work for me. (And youtube-dl -U reports "ERROR: can't find the current version. Please try again later.", so I don't know if I have the latest... not that we are here to debug youtube-dl.)
yt-dlp<EMAIL_ADDRESS>does not work for me.

The FB extractor in yt-dl hasn't been updated since release (2021.12.17) and should be expected to be broken. A yt-dl version using a version of the extractor from a PR might work. Also, it might depend on which Python version is used since one failure mode (IIRC, and why the extractor wasn't updated) is blockage by FB's bouncers based on client fingerprinting.
yt-dlp has made some networking improvements that might help to fix such blockage.

The FB extractor in yt-dl hasn't been updated since release (2021.12.17) and should be expected to be broken. A yt-dl version using a version of the extractor from a PR might work. Also, it might depend on which Python version is used since one failure mode (IIRC, and why no PR was merged) is blockage by FB's bouncers based on client fingerprinting.
Above, a video that can be downloaded with yt-dl doesn't match the FB extractor directly but with the generic extractor its embedded videos (that do match the FB extractor) can be downloaded.

Looks like when the extractor is trying to parse the url, the url redirects to a new url that begins with "fb://" and the android webview can not read correctly the new url on the contrary of chrime which is basically the same as webview..
I'm not a developer but this is my contribution in this subject

Above, a video that can be downloaded with yt-dl doesn't match the FB extractor directly but with the generic extractor its embedded videos (that do match the FB extractor) can be downloaded.

Above where? 😄  In any case:
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['--ffmpeg-location', '.\\FFmpeg', '--external-downloader-args', '-v 8 -stats', '-vF', 'https://www.facebook.com/gazzetta.gr/videos/1282182232423557/']
[debug] Encodings: locale cp1253, fs mbcs, out cp737, pref cp1253
[debug] youtube-dl version 2<IP_ADDRESS>6
[debug] Lazy loading extractors enabled
[debug] Single file build
[debug] Python 3.4.10 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 - OpenSSL 1.0.2k  26 Jan 2017
[debug] exe versions: ffmpeg n6.1-dev-1930-N-111814-g9f66286, ffprobe n6.1-dev-1930-N-111814-g9f66286, phantomjs 2.1.1, rtmpdump 2.4
[debug] Proxy map: {}
[facebook]<PHONE_NUMBER>423557: Downloading webpage
[facebook]<PHONE_NUMBER>423557: Downloading webpage
WARNING: Unknown codec vp<IP_ADDRESS>.<IP_ADDRESS>.00
WARNING: Unknown codec vp<IP_ADDRESS>.<IP_ADDRESS>.00
WARNING: Unknown codec vp<IP_ADDRESS>.<IP_ADDRESS>.00
WARNING: Unknown codec vp<IP_ADDRESS>.<IP_ADDRESS>.00
WARNING: Unknown codec vp<IP_ADDRESS>.<IP_ADDRESS>.00
WARNING: Unknown codec vp<IP_ADDRESS>.<IP_ADDRESS>.00
WARNING: Unknown codec vp<IP_ADDRESS>.<IP_ADDRESS>.00
[info] Available formats for<PHONE_NUMBER>423557:
format code               extension  resolution note
309810111544885a          m4a        audio only DASH audio   65k , m4a_dash container, mp4a.40.5 (44100Hz)
1285943572038730v         mp4        360x640    DASH video  181k , mp4_dash container, av01.0.01M.<IP_ADDRESS>.01.01.0, video only
2905904322879782v         mp4        360x640    DASH video  217k , mp4_dash container, av01.0.01M.<IP_ADDRESS>.01.01.0, video only
1357980768469980v         mp4        540x960    DASH video  332k , mp4_dash container, av01.0.04M.<IP_ADDRESS>.01.01.0, video only
264187603137569v          mp4        720x1280   DASH video  575k , mp4_dash container, av01.0.05M.<IP_ADDRESS>.01.01.0, video only
701716058436450v          mp4        900x1600   DASH video  922k , mp4_dash container, av01.0.08M.<IP_ADDRESS>.01.01.0, video only
279905904762370v          mp4        1080x1920  DASH video 1555k , mp4_dash container, av01.0.08M.<IP_ADDRESS>.01.01.0, video only
dash_sd_src               mp4        unknown
dash_sd_src_no_ratelimit  mp4        unknown
1345607079376096v         mp4        216x384    DASH video  104k , mp4_dash container
332073845822799v          mp4        360x640    DASH video  161k , mp4_dash container
276657805118621v          mp4        360x640    DASH video  227k , mp4_dash container
300477575999225v          mp4        540x960    DASH video  366k , mp4_dash container
828632058729309v          mp4        720x1280   DASH video  552k , mp4_dash container
834065534700307v          mp4        720x1280   DASH video  955k , mp4_dash container
1529796337425201v         mp4        1080x1920  DASH video 1629k , mp4_dash container
dash_hd_src               mp4        unknown    (best)

FWIW, is the genericIE still involved here, as suggested?
OT: Are these WARNING: Unknown codec vp09.00.* related to my specific build of ffprobe or just to the fbIE? Because they persevere even when no (ffmpeg/)ffprobe is being installed:
youtube-dl -vF "https://www.facebook.com/gazzetta.gr/videos/1282182232423557/" =>

[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: [u'-vF', u'https://www.facebook.com/gazzetta.gr/videos/1282182232423557/']
[debug] Encodings: locale cp1253, fs mbcs, out cp737, pref cp1253
[debug] youtube-dl version 2<IP_ADDRESS>6
[debug] Lazy loading extractors enabled
[debug] Single file build
[debug] Python 2.7.18 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 - OpenSSL 1.0.2t  10 Sep 2019
[debug] exe versions: none
[debug] Proxy map: {}
[facebook]<PHONE_NUMBER>423557: Downloading webpage
[facebook]<PHONE_NUMBER>423557: Downloading webpage
WARNING: Unknown codec vp<IP_ADDRESS>.<IP_ADDRESS>.00
WARNING: Unknown codec vp<IP_ADDRESS>.<IP_ADDRESS>.00
WARNING: Unknown codec vp<IP_ADDRESS>.<IP_ADDRESS>.00
WARNING: Unknown codec vp<IP_ADDRESS>.<IP_ADDRESS>.00
WARNING: Unknown codec vp<IP_ADDRESS>.<IP_ADDRESS>.00
WARNING: Unknown codec vp<IP_ADDRESS>.<IP_ADDRESS>.00
WARNING: Unknown codec vp<IP_ADDRESS>.<IP_ADDRESS>.00
[info] Available formats for<PHONE_NUMBER>423557:
format code               extension  resolution note
309810111544885a          m4a        audio only DASH audio   65k , m4a_dash container, mp4a.40.5 (44100Hz)
1285943572038730v         mp4        360x640    DASH video  181k , mp4_dash container, av01.0.01M.<IP_ADDRESS>.01.01.0, video only
2905904322879782v         mp4        360x640    DASH video  217k , mp4_dash container, av01.0.01M.<IP_ADDRESS>.01.01.0, video only
1357980768469980v         mp4        540x960    DASH video  332k , mp4_dash container, av01.0.04M.<IP_ADDRESS>.01.01.0, video only
264187603137569v          mp4        720x1280   DASH video  575k , mp4_dash container, av01.0.05M.<IP_ADDRESS>.01.01.0, video only
701716058436450v          mp4        900x1600   DASH video  922k , mp4_dash container, av01.0.08M.<IP_ADDRESS>.01.01.0, video only
279905904762370v          mp4        1080x1920  DASH video 1555k , mp4_dash container, av01.0.08M.<IP_ADDRESS>.01.01.0, video only
dash_sd_src               mp4        unknown
dash_sd_src_no_ratelimit  mp4        unknown
1345607079376096v         mp4        216x384    DASH video  104k , mp4_dash container
332073845822799v          mp4        360x640    DASH video  161k , mp4_dash container
276657805118621v          mp4        360x640    DASH video  227k , mp4_dash container
300477575999225v          mp4        540x960    DASH video  366k , mp4_dash container
828632058729309v          mp4        720x1280   DASH video  552k , mp4_dash container
834065534700307v          mp4        720x1280   DASH video  955k , mp4_dash container
1529796337425201v         mp4        1080x1920  DASH video 1629k , mp4_dash container
dash_hd_src               mp4        unknown    (best)

[facebook]<PHONE_NUMBER>423557: Downloading webpage
[facebook]<PHONE_NUMBER>423557: Downloading webpage

There was very little difference between the yt-dlp FB extractor code and the youtube-dl FB extractor code prior to the reels patch (which also does not have a meaningful impact on this issue).
As you see in the log, there are 2 requests being made -- the first is for the actual FB webpage, and extraction silently fails. The 2nd request is to FB's "Tahoe" video API endpoint, unhelpfully also labeled as Downloading webpage -- yt-dlp does this as well. But the difference is in the response, since this API endpoint seems to employ some sort of TLS fingerprinting protection that blocks yt-dlp's Py>=3.10 fingerprint and allows youtube-dl's Py<=3.9 fingerprint. This is what yt-dlp gets back:
{
  "__ar": 1,
  "error": 1357005,
  "errorSummary": "Your Request Couldn't be Processed",
  "errorDescription": "There was a problem with this request. We're working on geting it fixed as soon as we can.",
  "payload": null,
  "hsrp": {
    "hblp": {
      "consistency": {
        "rev":<PHONE_NUMBER>
      }
    }
  },
  "lid": "7274291556808579435"
}

The facebook extractor is designed rather poorly IMO, and everything fails silently until there are no more fallbacks, at which point an identical Cannot parse data extractor error is raised. So this longstanding issue (#4311) should actually be tracking the Tahoe API request failure, while the #7901 should be tracking the newly manifested failure to extract from all webpages.

FWIW, is the genericIE still involved here, as suggested?

no

Indeed, some report_extraction()-type feedback ought to be provided when an extractor uses multiple tactics, as in the somewhat randomly constructed FB extractor.

@bashonly
Many thanks for your erudite reply; highly appreciated 😄 👍 ... BTW:

prior to the reels patch

... the link has to be changed to bb5d84c9d2f1e978c3eddfb5ccbe138036682a36 😉 ...
I had to do a "refresh" on TLS fingerprinting, still I kindly ask for a further clarification on:

since this API endpoint seems to employ some sort of TLS fingerprinting protection that blocks yt-dlp's Py>=3.10 fingerprint and allows youtube-dl's Py<=3.9 fingerprint.

From the article I read it comes that both apps' TLS fingerprints depend on the combination of CPython+OpenSSL lib in use when the scripts are being invoked; or is there something additional involved in the case of yt-dlp?
I find that even yt-dlp_x86.exe, currently built on CPython 3.7, stills fails on FB 😿 , so it isn't only on Py>=3.10 that the Tahoe API endpoint blocks yt-dlp (unless I misunderstood what you wrote previously) ...
The successful yt-dl logs I posted previously were on CPython 3.4+OpenSSL-1.0.2k and CPython 2.7+OpenSSL-1.0.2t, so both using the 1.0.2 OpenSSL branch; AFAIAA, 1.0.2 doesn't even support TLSv1.3, so why older (less secure) CPython and older (less secure) OpenSSL are being whitelisted by that API is beyond me...
Finally, I dug up my archives and found out that the last yt-dlp version that emulates the current yt-dl behaviour in regards to FB is v2021.12.01 (!):
yt-dlp_x86 -vF "https://www.facebook.com/gazzetta.gr/videos/1282182232423557/" =>

[debug] Command-line config: ['-vF', 'https://www.facebook.com/gazzetta.gr/videos/1282182232423557/']
[debug] Encodings: locale cp1253, fs utf-8, out utf-8 (No ANSI), err utf-8 (No ANSI), pref cp1253
[debug] yt-dlp version 2021.12.01 [91f071a] (win_exe)
[debug] Python version 3.7.9 (CPython 32bit) - Windows-Vista-6.0.6003-SP2
[debug] exe versions: none
[debug] Optional libraries: Cryptodome, mutagen, sqlite, websockets
[debug] Proxy map: {}
[debug] [facebook] Extracting URL: https://www.facebook.com/gazzetta.gr/videos/1282182232423557/
[facebook]<PHONE_NUMBER>423557: Downloading webpage
[facebook]<PHONE_NUMBER>423557: Downloading webpage
[debug] Sort order given by extractor: res, quality
[debug] Formats sorted by: hasvid, ie_pref, res, quality, lang, fps, hdr:12(7), vcodec:vp9.2(10), acodec, filesize, fs_approx, tbr, vbr, abr, asr, proto, vext, aext, hasaud, source, id
[info] Available formats for<PHONE_NUMBER>423557:
ID                       EXT RESOLUTION |   TBR PROTO | VCODEC          VBR ACODEC     ABR     ASR MORE INFO
-----------------------------------------------------------------------------------------------------------------------
309810111544885a         m4a            |   65k https | audio only          mp4a.40.5  65k 44100Hz DASH audio, m4a_dash
dash_sd_src              mp4 unknown    |       https | unknown             unknown
dash_sd_src_no_ratelimit mp4 unknown    |       https | unknown             unknown
1345607079376096v        mp4 216x384    |  104k https | vp<IP_ADDRESS>  104k video only             DASH video, mp4_dash
1285943572038730v        mp4 360x640    |  181k https | av01.0.01M.08  181k video only             DASH video, mp4_dash
2905904322879782v        mp4 360x640    |  217k https | av01.0.01M.08  217k video only             DASH video, mp4_dash
332073845822799v         mp4 360x640    |  161k https | vp<IP_ADDRESS>  161k video only             DASH video, mp4_dash
276657805118621v         mp4 360x640    |  227k https | vp<IP_ADDRESS>  227k video only             DASH video, mp4_dash
1357980768469980v        mp4 540x960    |  332k https | av01.0.04M.08  332k video only             DASH video, mp4_dash
300477575999225v         mp4 540x960    |  366k https | vp<IP_ADDRESS>  366k video only             DASH video, mp4_dash
264187603137569v         mp4 720x1280   |  575k https | av01.0.05M.08  575k video only             DASH video, mp4_dash
828632058729309v         mp4 720x1280   |  552k https | vp<IP_ADDRESS>  552k video only             DASH video, mp4_dash
834065534700307v         mp4 720x1280   |  955k https | vp<IP_ADDRESS>  955k video only             DASH video, mp4_dash
dash_hd_src              mp4 720p       |       https | unknown             unknown
701716058436450v         mp4 900x1600   |  922k https | av01.0.08M.08  922k video only             DASH video, mp4_dash
279905904762370v         mp4 1080x1920  | 1555k https | av01.0.08M.08 1555k video only             DASH video, mp4_dash
1529796337425201v        mp4 1080x1920  | 1629k https | vp<IP_ADDRESS> 1629k video only             DASH video, mp4_dash

As the more observant among you might have noticed, avc1 streams are missing, but I guess this is due to this ...
Kind regards 😄

Python 3.10's SSL ciphers were backported to all builds of yt-dlp regardless of the actual Python version used

Python 3.10's SSL ciphers were universally backported regardless of the actual Python version used

Thanks for that 👍 😄 ; that "change" was committed on 2022.11.06 and first "made" it on yt-dlp v2022.11.11; but, as I posted earlier, FB is being broken now on every yt-dlp version after v2021.12.01; so, 11 months already prior to 5b9f253, something inside 2021.12.01...2021.12.25 (5f549d4 ?) now breaks FB in yt-dlp 😢 ...

And we don't know exactly what aspect of the fingerprint is triggering a block from FB. It could be any number of things

I have been conducting some tests with latest "upstream", i.e. youtube-dl, and in my efforts to download avc1 (aka h264) video streams from FB, posing as Firefox, I discovered that Fx versions < 90 do work as intended, however every newer Fx version >=90 will now generate the same error as when using yt-dlp:
yt-dl -vF --user-agent "Mozilla/5.0 (Windows NT 6.0; rv:89.0) Gecko/20100101 Firefox/89.0" "https://www.facebook.com/gazzetta.gr/videos/1282182232423557/" =>

[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['--ffmpeg-location', '.\\FFmpeg', '--external-downloader-args', '-v 8 -stats', '-vF', '--user-agent', 'Mozilla/5.0 (Windows NT 6.0; rv:89.0) Gecko/20100101 Firefox/89.0', 'https://www.facebook.com/gazzetta.gr/videos/1282182232423557/']
[debug] Encodings: locale cp1253, fs mbcs, out cp737, pref cp1253
[debug] youtube-dl version 2<IP_ADDRESS>5
[debug] Lazy loading extractors enabled
[debug] Single file build
[debug] Python 3.4.10 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 - OpenSSL 1.0.2k  26 Jan 2017
[debug] exe versions: ffmpeg n6.1-dev-1945-N-111829-g3c9dc0, ffprobe n6.1-dev-1945-N-111829-g3c9dc0, phantomjs 2.1.1, rtmpdump 2.4
[debug] Proxy map: {}
[facebook]<PHONE_NUMBER>423557: Downloading webpage
[facebook]<PHONE_NUMBER>423557: Downloading webpage
[info] Available formats for<PHONE_NUMBER>423557:
format code               extension  resolution note
309810111544885a          m4a        audio only DASH audio   65k , m4a_dash container, mp4a.40.5 (44100Hz)
135152312980525v          mp4        360x640    DASH video   90k , mp4_dash container, avc1.4d401e, video only
1159988861624345v         mp4        360x640    DASH video  179k , mp4_dash container, avc1.4d401e, video only
288169693854753v          mp4        540x960    DASH video  366k , mp4_dash container, avc1.4d401f, video only
1703613763384686v         mp4        720x1280   DASH video  770k , mp4_dash container, avc1.4d401f, video only
1760573717746257v         mp4        720x1280   DASH video 1575k , mp4_dash container, avc1.4d401f, video only
312425081166210v          mp4        1080x1920  DASH video 3465k , mp4_dash container, avc1.640028, video only
dash_sd_src               mp4        unknown
dash_sd_src_no_ratelimit  mp4        unknown
dash_hd_src               mp4        unknown    (best)

OTOH,
yt-dl -vF --user-agent "Mozilla/5.0 (Windows NT 6.1; rv:90.0) Gecko/20100101 Firefox/90.0" "https://www.facebook.com/gazzetta.gr/videos/1282182232423557/" =>

[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['--ffmpeg-location', '.\\FFmpeg', '--external-downloader-args', '-v 8 -stats', '-vF', '--user-agent', 'Mozilla/5.0 (Windows NT 6.1; rv:90.0) Gecko/20100101 Firefox/90.0', 'https://www.facebook.com/gazzetta.gr/videos/1282182232423557/']
[debug] Encodings: locale cp1253, fs mbcs, out cp737, pref cp1253
[debug] youtube-dl version 2<IP_ADDRESS>5
[debug] Lazy loading extractors enabled
[debug] Single file build
[debug] Python 3.4.10 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 - OpenSSL 1.0.2k  26 Jan 2017
[debug] exe versions: ffmpeg n6.1-dev-1945-N-111829-g3c9dc0, ffprobe n6.1-dev-1945-N-111829-g3c9dc0, phantomjs 2.1.1, rtmpdump 2.4
[debug] Proxy map: {}
[facebook]<PHONE_NUMBER>423557: Downloading webpage
[facebook]<PHONE_NUMBER>423557: Downloading webpage
ERROR: Cannot parse data; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; type  youtube-dl -U  to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
Traceback (most recent call last):
  File "C:\Python3410-32\yt-dl_pycompile\youtube_dl\YoutubeDL.py", line 859, in wrapper
    return func(self, *args, **kwargs)
  File "C:\Python3410-32\yt-dl_pycompile\youtube_dl\YoutubeDL.py", line 955, in __extract_info
    ie_result = ie.extract(url)
  File "C:\Python3410-32\yt-dl_pycompile\youtube_dl\extractor\common.py", line 565, in extract
    ie_result = self._real_extract(url)
  File "C:\Python3410-32\yt-dl_pycompile\youtube_dl\extractor\facebook.py", line 680, in _real_extract
    return self._extract_from_url(real_url, video_id)
  File "C:\Python3410-32\yt-dl_pycompile\youtube_dl\extractor\facebook.py", line 594, in _extract_from_url
    raise ExtractorError('Cannot parse data')
youtube_dl.utils.ExtractorError: Cannot parse data; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; type  youtube-dl -U  to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.

Food for thought, perhaps? 😉
Regards.

How do I get "youtube-dl version 2<IP_ADDRESS>5" used in the last post???

FB is being broken now on every yt-dlp version after v2021.12.01; so, 11 months already prior to https://github.com/yt-dlp/yt-dlp/commit/5b9f253fa0aee996cf1ed30185d4b502e00609c4, something inside 2021.12.01...2021.12.25 (https://github.com/yt-dlp/yt-dlp/commit/5f549d4959025eef8bb49c870be5a8c35866e301 ?) now breaks FB in yt-dlp

@Vangelis66 I think it's more likely that b1156c1e59646d450836ce8e61c34641070e8ccb / d14cbdd92d8bbb9deedc77da80085b0280ae52bb was the culprit, since FB's fingerprinting seems to be very http header-focused

The results above are repeatable with yt-dl master and Python 3.9 and also with the nightly release. Note that yt-dl currently sends UA versions < FF 90 by default.
However:

yt-dl --add-header 'Sec-Fetch-Mode: same-origin' ... breaks
ditto 'Sec-Fetch-Mode: navigate'
yt-dlp<EMAIL_ADDRESS>fails with UA set to FF 89 and FF 90
yt-dlp --add-header 'Sec-Fetch-Mode:' ... succeeds, without setting UA.

yt-dlp  --add-header 'Sec-Fetch-Mode:'   --extract-audio --audio-format mp3  https://web.facebook.com/watch/?v=2139244499701931
[facebook] Extracting URL: https://web.facebook.com/watch/?v=2139244499701931
[facebook]<PHONE_NUMBER>701931: Downloading webpage
[facebook]<PHONE_NUMBER>701931: Downloading webpage
ERROR: [facebook]<PHONE_NUMBER>701931: Cannot parse data; please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= , filling out the appropriate issue template. Confirm you are on the latest version using  yt-dlp -U

yt-dlp is up to date<EMAIL_ADDRESS>

You do need to add the FF UA, as updated above.

yt-dlp  --user-agent "Mozilla/5.0 (Windows NT 6.0; rv:89.0) Gecko/20100101 Firefox/89.0"  --add-header 'Sec-Fetch-Mode:'   --extract-audio --audio-format mp3  https://web.facebook.com/watch/?v=2139244499701931
[facebook] Extracting URL: https://web.facebook.com/watch/?v=2139244499701931
[facebook]<PHONE_NUMBER>701931: Downloading webpage
[facebook]<PHONE_NUMBER>701931: Downloading webpage
ERROR: [facebook]<PHONE_NUMBER>701931: Cannot parse data; please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= , filling out the appropriate issue template. Confirm you are on the latest version using  yt-dlp -U

Yet:
$ yt-dlp -v -F 'https://web.facebook.com/watch/?v=2139244499701931' --user-agent 'Mozilla/5.0 (Windows NT 6.0; rv:89.0) Gecko/20100101 Firefox/89.0' --add-header 'Sec-Fetch-Mode:'
[debug] Command-line config: ['-v', '-F', 'https://web.facebook.com/watch/?v=2139244499701931', '--user-agent', 'Mozilla/5.0 (Windows NT 6.0; rv:89.0) Gecko/20100101 Firefox/89.0', '--add-header', 'Sec-Fetch-Mode:']
[debug] Encodings: locale UTF-8, fs utf-8, pref UTF-8, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version<EMAIL_ADDRESS>[812cdfa06] (source)
[debug] Lazy loading extractors is disabled
[debug] Git HEAD: de4cf77ec
[debug] Python 3.9.16 (CPython i686 32bit) - Linux-4.4.0-210-generic-i686-with-glibc2.23 (OpenSSL 1.1.1v  1 Aug 2023, glibc 2.23)
[debug] exe versions: ffmpeg 4.3, ffprobe 4.3
[debug] Optional libraries: Cryptodome-3.11.0, certifi-2019.11.28, secretstorage-3.2.0, sqlite3-2.6.0
[debug] Proxy map: {}
[debug] Loaded 1851 extractors
[facebook] Extracting URL: https://web.facebook.com/watch/?v=2139244499701931
[facebook]<PHONE_NUMBER>701931: Downloading webpage
[facebook]<PHONE_NUMBER>701931: Downloading webpage
[debug] Sort order given by extractor: res, quality
[debug] Formats sorted by: hasvid, ie_pref, res, quality, lang, fps, hdr:12(7), vcodec:vp9.2(10), channels, acodec, size, br, asr, proto, vext, aext, hasaud, source, id
[info] Available formats for<PHONE_NUMBER>701931:
ID                              EXT RESOLUTION │ PROTO │ VCODEC  ACODEC
────────────────────────────────────────────────────────────────────────
progressive_sd_src              mp4 unknown    │ https │ unknown unknown
progressive_sd_src_no_ratelimit mp4 unknown    │ https │ unknown unknown
$

Apparently FB is looking at the final version number, not the rv.
With this page yt-dl gets:
[facebook]<PHONE_NUMBER>701931: Downloading webpage
ERROR: Unable to download webpage: HTTP Error 302: The HTTP server returned a redirect error that would lead to an infinite loop.
The last 30x error message was:
Found (caused by HTTPError()) ....

But that's another problem.

yt-dlp -v -F 'https://web.facebook.com/watch/?v=2139244499701931' --user-agent 'Mozilla/5.0 (Windows NT 6.0; rv:89.0) Gecko/20100101 Firefox/89.0' --add-header 'Sec-Fetch-Mode:'
[debug] Command-line config: ['-v', '-F', 'https://web.facebook.com/watch/?v=2139244499701931', '--user-agent', 'Mozilla/5.0 (Windows NT 6.0; rv:89.0) Gecko/20100101 Firefox/89.0', '--add-header', 'Sec-Fetch-Mode:']
[debug] Encodings: locale UTF-8, fs utf-8, pref UTF-8, out UTF-8, error UTF-8, screen UTF-8
[debug] yt-dlp version<EMAIL_ADDRESS>[b532a3481] (zip)
[debug] Python 3.7.3 (CPython x86_64 64bit) - Linux-5.0.0-38-generic-x86_64-with-Ubuntu-19.04-disco (OpenSSL 1.1.1b  26 Feb 2019, glibc 2.29)
[debug] exe versions: ffmpeg 4.1.3, ffprobe 4.1.3, phantomjs 2.1.1
[debug] Optional libraries: Crypto-broken 2.6.1, certifi-2018.08.24, secretstorage-2.3.1, sqlite3-2.6.0
[debug] Proxy map: {}
[debug] Loaded 1855 extractors
[facebook] Extracting URL: https://web.facebook.com/watch/?v=2139244499701931
[facebook]<PHONE_NUMBER>701931: Downloading webpage
[facebook]<PHONE_NUMBER>701931: Downloading webpage
ERROR: [facebook]<PHONE_NUMBER>701931: Cannot parse data; please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= , filling out the appropriate issue template. Confirm you are on the latest version using  yt-dlp -U
File "/home/joseph/bin/yt-dlp/yt_dlp/extractor/common.py", line 710, in extract
ie_result = self._real_extract(url)
File "/home/joseph/bin/yt-dlp/yt_dlp/extractor/facebook.py", line 707, in _real_extract
return self._extract_from_url(real_url, video_id)
File "/home/joseph/bin/yt-dlp/yt_dlp/extractor/facebook.py", line 654, in _extract_from_url
raise ExtractorError('Cannot parse data')

OpenSSL 1.1.1b
Or Crypto-broken vs Cryptodome
Or Python 3.7 vs 3.9 (but I get the same result with Py 3.11 and no Crypto*).
Or location/IP.
Or maybe something related to cookie changes between the two yt-dlp versions.

How do I get "youtube-dl version 2<IP_ADDRESS>5" used in the last post???

This is a self-compiled Windows 32-bit build, using CPython 3.4.10, from source code snapshot "master-git-20230903-g66ab081"; since you're a Linux user, it shouldn't be difficult for you to compile it yourself or, even, run it directly from source 😉 ; of course, this is OT for this tracker...

I think it's more likely that https://github.com/yt-dlp/yt-dlp/commit/b1156c1e59646d450836ce8e61c34641070e8ccb / https://github.com/yt-dlp/yt-dlp/commit/d14cbdd92d8bbb9deedc77da80085b0280ae52bb was the culprit, since FB's fingerprinting seems to be very http header-focused

... I'm not a coder, I've stated that multiple times 😉 , but both these commits (in Jan 2022) were authored after v2021.12.25, which is now also broken in FB yielding the error in this issue's title:
[debug] Command-line config: ['-vF', 'https://www.facebook.com/RoeiFreilich/videos/2139244499701931/']
[debug] Encodings: locale cp1253, fs utf-8, out utf-8 (No ANSI), err utf-8 (No ANSI), pref cp1253
[debug] yt-dlp version 2021.12.25 [87e0499] (win_exe)
[debug] Python version 3.7.9 (CPython 32bit) - Windows-Vista-6.0.6003-SP2
[debug] exe versions: none
[debug] Optional libraries: Cryptodome, mutagen, sqlite, websockets
[debug] Proxy map: {}
[debug] [facebook] Extracting URL: https://www.facebook.com/RoeiFreilich/videos/2139244499701931/
[facebook]<PHONE_NUMBER>701931: Downloading webpage
[facebook]<PHONE_NUMBER>701931: Downloading webpage
ERROR: [facebook]<PHONE_NUMBER>701931: Cannot parse data; please report this issue on  https://github.com/yt-dlp/yt-dlp . Make sure you are using the latest version; type  yt-dlp -U  to update. Be sure to call yt-dlp with the --verbose flag and include its complete output.; please report this issue on  https://github.com/yt-dlp/yt-dlp . Make sure you are using the latest version; type  yt-dlp -U  to update. Be sure to call yt-dlp with the --verbose flag and include its complete output.
  File "yt_dlp\extractor\common.py", line 599, in extract
  File "yt_dlp\extractor\facebook.py", line 721, in _real_extract
  File "yt_dlp\extractor\facebook.py", line 667, in _extract_from_url

... whereas:
yt-dlp_x86 -vF "https://www.facebook.com/RoeiFreilich/videos/2139244499701931/" =>

[debug] Command-line config: ['-vF', 'https://www.facebook.com/RoeiFreilich/videos/2139244499701931/']
[debug] Encodings: locale cp1253, fs utf-8, out utf-8 (No ANSI), err utf-8 (No ANSI), pref cp1253
[debug] yt-dlp version 2021.12.01 [91f071a] (win_exe)
[debug] Python version 3.7.9 (CPython 32bit) - Windows-Vista-6.0.6003-SP2
[debug] exe versions: none
[debug] Optional libraries: Cryptodome, mutagen, sqlite, websockets
[debug] Proxy map: {}
[debug] [facebook] Extracting URL: https://www.facebook.com/RoeiFreilich/videos/2139244499701931/
[facebook]<PHONE_NUMBER>701931: Downloading webpage
[facebook]<PHONE_NUMBER>701931: Downloading webpage
[debug] Sort order given by extractor: res, quality
[debug] Formats sorted by: hasvid, ie_pref, res, quality, lang, fps, hdr:12(7), vcodec:vp9.2(10), acodec, filesize, fs_approx, tbr, vbr, abr, asr, proto, vext, aext, hasaud, source, id
[info] Available formats for<PHONE_NUMBER>701931:
ID                              EXT RESOLUTION | PROTO | VCODEC  ACODEC
------------------------------------------------------------------------
progressive_sd_src              mp4 unknown    | https | unknown unknown
progressive_sd_src_no_ratelimit mp4 unknown    | https | unknown unknown

yt-dlp --add-header 'Sec-Fetch-Mode:' ... succeeds, with UA set to FF 89,

I can confirm here with latest yt-dlp-nightly, using as a test the link cited by @jheled :
yt-dlp -vF --user-agent "Mozilla/5.0 (Windows NT 6.1; rv:89.0) Gecko/20100101 Firefox/89.0" --add-header "Sec-Fetch-Mode:" "https://web.facebook.com/watch/?v=2139244499701931" =>

[debug] Command-line config: ['--ffmpeg-location', '..\\FFmpeg', '--downloader-args', 'ffmpeg:-v 8 -stats', '-vF', '--user-agent', 'Mozilla/5.0 (Windows NT 6.1; rv:89.0) Gecko/20100101 Firefox/89.0', '--add-header', 'Sec-Fetch-Mode:', 'https://web.facebook.com/watch/?v=2139244499701931']
[debug] Encodings: locale cp1253, fs utf-8, pref cp1253, out utf-8 (No VT), error utf-8 (No VT), screen utf-8 (No VT)
[debug] yt-dlp version<EMAIL_ADDRESS>[2301b5c1b] (win_x86_exe)
[debug] Python 3.7.9 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 (OpenSSL 1.1.1g  21 Apr 2020)
[debug] exe versions: ffmpeg n6.1-dev-1945-N-111829-g3c9dc0 (setts), ffprobe n6.1-dev-1945-N-111829-g3c9dc0, phantomjs 2.1.1, rtmpdump 2.4
[debug] Optional libraries: Cryptodome-3.18.0, brotli-1.0.9, certifi-2023.07.22, mutagen-1.46.0, sqlite3-2.6.0, websockets-11.0.3
[debug] Proxy map: {}
[debug] Loaded 1864 extractors
[facebook] Extracting URL: https://web.facebook.com/watch/?v=2139244499701931
[facebook]<PHONE_NUMBER>701931: Downloading webpage
[facebook]<PHONE_NUMBER>701931: Downloading webpage
[debug] Sort order given by extractor: res, quality
[debug] Formats sorted by: hasvid, ie_pref, res, quality, lang, fps, hdr:12(7), vcodec:vp9.2(10), channels, acodec, size, br, asr, proto, vext, aext, hasaud, source, id
[info] Available formats for<PHONE_NUMBER>701931:
ID                              EXT RESOLUTION | PROTO | VCODEC  ACODEC
------------------------------------------------------------------------
progressive_sd_src              mp4 unknown    | https | unknown unknown
progressive_sd_src_no_ratelimit mp4 unknown    | https | unknown unknown

With this page yt-dl nightly gets:
[facebook]<PHONE_NUMBER>701931: Downloading webpage
ERROR: Unable to download webpage: HTTP Error 302: The HTTP server returned a redirect error that would lead to an infinite loop.
The last 30x error message was:
Found (caused by HTTPError()) ....

But that's another problem.

Indeed, but as a workaround one can use a browser for the redirection:
https://web.facebook.com/watch/?v=2139244499701931
=>
https://www.facebook.com/RoeiFreilich/videos/2139244499701931/

and then feed yt-dl that second FB URL:
yt-dl -vF "https://www.facebook.com/RoeiFreilich/videos/2139244499701931/" =>

[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['--ffmpeg-location', '.\\FFmpeg', '--external-downloader-args', '-v 8 -stats', '-vF', 'https://www.facebook.com/RoeiFreilich/videos/2139244499701931/']
[debug] Encodings: locale cp1253, fs mbcs, out cp737, pref cp1253
[debug] youtube-dl version 2023.08.07 [86e3cf5e5] (single file build)
[debug] ** This version was built from the latest master code at https://github.com/ytdl-org/youtube-dl.
[debug] ** For support, visit the main site.
[debug] Python 3.4.4 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 - OpenSSL 1.0.2d 9 Jul 2015
[debug] exe versions: ffmpeg n6.1-dev-1945-N-111829-g3c9dc0, ffprobe n6.1-dev-1945-N-111829-g3c9dc0, phantomjs 2.1.1, rtmpdump 2.4
[debug] Proxy map: {}
[facebook]<PHONE_NUMBER>701931: Downloading webpage
[facebook]<PHONE_NUMBER>701931: Downloading webpage
[info] Available formats for<PHONE_NUMBER>701931:
format code                      extension  resolution note
progressive_sd_src               mp4        unknown
progressive_sd_src_no_ratelimit  mp4        unknown    (best)

but both these commits (in Jan 2022) were authored after v2021.12.25, which is now also broken in FB,

Then it was almost certainly d76d15a6699dc41eea26a96d054a1b7bcb12c69b that broke the FB "Tahoe" fallback

Then it was almost certainly https://github.com/yt-dlp/yt-dlp/commit/d76d15a6699dc41eea26a96d054a1b7bcb12c69b that broke the FB "Tahoe" fallback

Indeed it was! 👍 ; to sum it up:
The Tahoe API endpoint "fallback" in recent yt-dlp versions is broken because of:

Update our chrome versions used for User-Agents; the cut-off Chrome version in this case is 77 (>=78 gets the door shut on its face 😞 ); "us" engaged in retrocomputing have a saying: "Newer isn't always better", which, I think, fits perfectly here 😜 ...
[utils] Add Sec-Fetch-Mode to std_headers; this is worked-around by --add-header "Sec-Fetch-Mode:" (thanks @dirkf 😄 ).

Putting 1+2 into practice 😉, with latest yt-dlp-nightly:
yt-dlp -vF --user-agent "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36" --add-header "Sec-Fetch-Mode:" "https://www.facebook.com/gazzetta.gr/videos/1282182232423557/" =>

[debug] Command-line config: ['--ffmpeg-location', '..\\FFmpeg', '--downloader-args', 'ffmpeg:-v 8 -stats', '-vF', '--user-agent', 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36', '--add-header', 'Sec-Fetch-Mode:', 'https://www.facebook.com/gazzetta.gr/videos/1282182232423557/']
[debug] Encodings: locale cp1253, fs utf-8, pref cp1253, out utf-8 (No VT), error utf-8 (No VT), screen utf-8 (No VT)
[debug] yt-dlp version<EMAIL_ADDRESS>[69dbfe01c] (win_x86_exe)
[debug] Python 3.7.9 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 (OpenSSL 1.1.1g  21 Apr 2020)
[debug] exe versions: ffmpeg n6.1-dev-1945-N-111829-g3c9dc0 (setts), ffprobe n6.1-dev-1945-N-111829-g3c9dc0, phantomjs 2.1.1, rtmpdump 2.4
[debug] Optional libraries: Cryptodome-3.18.0, brotli-1.0.9, certifi-2023.07.22, mutagen-1.47.0, sqlite3-2.6.0, websockets-11.0.3
[debug] Proxy map: {}
[debug] Loaded 1864 extractors
[facebook] Extracting URL: https://www.facebook.com/gazzetta.gr/videos/1282182232423557/
[facebook]<PHONE_NUMBER>423557: Downloading webpage
[facebook]<PHONE_NUMBER>423557: Downloading webpage
[debug] Sort order given by extractor: res, quality
[debug] Formats sorted by: hasvid, ie_pref, res, quality, lang, fps, hdr:12(7), vcodec:vp9.2(10), channels, acodec, size, br, asr, proto, vext, aext, hasaud, source, id
[info] Available formats for<PHONE_NUMBER>423557:
ID                       EXT RESOLUTION |   TBR PROTO | VCODEC          VBR ACODEC     ABR ASR MORE INFO
-------------------------------------------------------------------------------------------------------------------
309810111544885a         m4a audio only |   65k https | audio only          mp4a.40.5  65k 44k DASH audio, m4a_dash
dash_sd_src              mp4 unknown    |       https | unknown             unknown
dash_sd_src_no_ratelimit mp4 unknown    |       https | unknown             unknown
1345607079376096v        mp4 216x384    |  105k https | vp<IP_ADDRESS>  105k video only         DASH video, mp4_dash
1285943572038730v        mp4 360x640    |  182k https | av01.0.01M.08  182k video only         DASH video, mp4_dash
2905904322879782v        mp4 360x640    |  217k https | av01.0.01M.08  217k video only         DASH video, mp4_dash
332073845822799v         mp4 360x640    |  161k https | vp<IP_ADDRESS>  161k video only         DASH video, mp4_dash
276657805118621v         mp4 360x640    |  228k https | vp<IP_ADDRESS>  228k video only         DASH video, mp4_dash
1357980768469980v        mp4 540x960    |  333k https | av01.0.04M.08  333k video only         DASH video, mp4_dash
300477575999225v         mp4 540x960    |  367k https | vp<IP_ADDRESS>  367k video only         DASH video, mp4_dash
264187603137569v         mp4 720x1280   |  575k https | av01.0.05M.08  575k video only         DASH video, mp4_dash
828632058729309v         mp4 720x1280   |  553k https | vp<IP_ADDRESS>  553k video only         DASH video, mp4_dash
834065534700307v         mp4 720x1280   |  955k https | vp<IP_ADDRESS>  955k video only         DASH video, mp4_dash
dash_hd_src              mp4 720p       |       https | unknown             unknown
701716058436450v         mp4 900x1600   |  922k https | av01.0.08M.08  922k video only         DASH video, mp4_dash
279905904762370v         mp4 1080x1920  | 1556k https | av01.0.08M.08 1556k video only         DASH video, mp4_dash
1529796337425201v        mp4 1080x1920  | 1630k https | vp<IP_ADDRESS> 1630k video only         DASH video, mp4_dash

😃

I think there is more to the fingerprinting than just the headers, since I still get the error with the same command line on yt-dlp master

Have you tried (/are you able to try) with the yt-dlp_x86.exe binary? I can't try py>3.7 here at the moment 😉 ...

it could be a regional thing

I don't know whether that specific FB video is locked for non-Greek IPs; I tried several non-GR nodes in my VPN service: all fail; but then I realised every such node (server) has its own fingerprint when it faces the Tahoe API...
I let a Google search find a random Facebook video, e.g.
https://www.facebook.com/OfficialRandomVideos/videos/gas-station-fails-compilation-preview/536547506527068
and that one works, too, with yt-dlp_x86.exe and the Ch77 UA:
yt-dlp -vF --user-agent "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36" --add-header "Sec-Fetch-Mode:" "https://www.facebook.com/OfficialRandomVideos/videos/gas-station-fails-compilation-preview/536547506527068" =>

[debug] Command-line config: ['--ffmpeg-location', '..\\FFmpeg', '--downloader-args', 'ffmpeg:-v 8 -stats', '-vF', '--user-agent', 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36', '--add-header', 'Sec-Fetch-Mode:', 'https://www.facebook.com/OfficialRandomVideos/videos/gas-station-fails-compilation-preview/536547506527068']
[debug] Encodings: locale cp1253, fs utf-8, pref cp1253, out utf-8 (No VT), error utf-8 (No VT), screen utf-8 (No VT)
[debug] yt-dlp version<EMAIL_ADDRESS>[69dbfe01c] (win_x86_exe)
[debug] Python 3.7.9 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 (OpenSSL 1.1.1g  21 Apr 2020)
[debug] exe versions: ffmpeg n6.1-dev-1945-N-111829-g3c9dc0 (setts), ffprobe n6.1-dev-1945-N-111829-g3c9dc0, phantomjs 2.1.1, rtmpdump 2.4
[debug] Optional libraries: Cryptodome-3.18.0, brotli-1.0.9, certifi-2023.07.22, mutagen-1.47.0, sqlite3-2.6.0, websockets-11.0.3
[debug] Proxy map: {}
[debug] Loaded 1864 extractors
[facebook] Extracting URL: https://www.facebook.com/OfficialRandomVideos/videos/gas-station-fails-compilation-preview/536547506527068
[facebook]<PHONE_NUMBER>27068: Downloading webpage
[facebook]<PHONE_NUMBER>27068: Downloading webpage
[debug] Sort order given by extractor: res, quality
[debug] Formats sorted by: hasvid, ie_pref, res, quality, lang, fps, hdr:12(7), vcodec:vp9.2(10), channels, acodec, size, br, asr, proto, vext, aext, hasaud, source, id
[info] Available formats for<PHONE_NUMBER>27068:
ID                       EXT RESOLUTION |  TBR PROTO | VCODEC       VBR ACODEC   ABR ASR MORE INFO
---------------------------------------------------------------------------------------------------------------------
1698545660382577a        m4a audio only |  49k https | audio only       mp4a.40.29 49k 48k [eng] DASH audio, m4a_dash
dash_sd_src              mp4 unknown    |      https | unknown          unknown
dash_sd_src_no_ratelimit mp4 unknown    |      https | unknown          unknown
684531790355612v         mp4 426x240    |  49k https | avc1.4D401E  49k video only         DASH video, mp4_dash
232167923066388v         mp4 480x270    | 103k https | avc1.4D401E 103k video only         DASH video, mp4_dash
794172132156124v         mp4 640x360    | 232k https | avc1.4D401E 232k video only         DASH video, mp4_dash
6381808691895407v        mp4 1280x720   | 847k https | avc1.4D401F 847k video only         DASH video, mp4_dash
dash_hd_src              mp4 720p       |      https | unknown          unknown

Have you tried (/are you able to try) with the yt-dlp_x86.exe binary?

I don't have a windows machine that I can test with

I don't know whether that specific FB video is locked for non-Greek IPs;

The video wasn't geo-restricted; what I meant is that maybe FB serves different html to different regions. There are a few values needed for the Tahoe request that are sourced from the initial webpage response:
            tahoe_data = self._download_webpage(
                self._VIDEO_PAGE_TAHOE_TEMPLATE % video_id, video_id,
                data=urlencode_postdata({
                    '__a': 1,
                    '__pc': self._search_regex(
                        r'pkg_cohort["\']\s*:\s*["\'](.+?)["\']', webpage,
                        'pkg cohort', default='PHASED:DEFAULT'),
                    '__rev': self._search_regex(
                        r'client_revision["\']\s*:\s*(\d+),', webpage,
                        'client revision', default='3944515'),
                    'fb_dtsg': self._search_regex(
                        r'"DTSGInitialData"\s*,\s*\[\]\s*,\s*{\s*"token"\s*:\s*"([^"]+)"',
                        webpage, 'dtsg token', default=''),
                }),
                headers={
                    'Content-Type': 'application/x-www-form-urlencoded',
                })

Anyways, I will be merging the FB PR to close the other issue shortly. I was hoping to figure this out as well, but I've tried everything and can't reproduce the successful response on my end. So I'm just giving a heads up that this Tahoe issue is about to become impossible to debug with master/nightly (you'll need to use an old nightly build, or modify the source to force the fallback to the Tahoe request).

Nightly build suddenly works again!
$ ~/yt-dlp_linux --version
2<IP_ADDRESS>540
~/yt-dlp_linux   --extract-audio --audio-format mp3 -o xx1.mp3 https://web.facebook.com/watch/?v=2139244499701931
[facebook] Extracting URL: https://web.facebook.com/watch/?v=2139244499701931
[facebook]<PHONE_NUMBER>701931: Downloading webpage
[info]<PHONE_NUMBER>701931: Downloading 1 format(s): sd
[download] Destination: xx1.mp4
[download] 100% of    4.59MiB in 00:00:00 at 8.64MiB/s
[ExtractAudio] Destination: xx1.mp3
Deleting original file xx1.mp4 (pass -k to keep)

Nightly build suddenly works again!

Seems #7890 fixed it

this Tahoe issue is about to become impossible to debug with master/nightly (you'll need to use an old nightly build

... For anyone still interested 😉 , the very last yt-dlp-nightly release without #7890 merged is 2<IP_ADDRESS>110 ...

I was hoping to figure this out as well, but I've tried everything
and can't reproduce the successful response on my end

Last night I did continue my tests, this time using some experimental yt-dlp_x86.exe builds, compiled with modded CPython 3.8/3.9 (so as to launch even on NT 5.1 😉 ) and modded OpenSSL-3.1.0 lib, and I still found that adding:
 --user-agent "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36" --add-header "Sec-Fetch-Mode:"
to my commands did make the Tahoe API "happy" 😜 ; as a test, I used the TEST 'url' inside #7890,
https://www.facebook.com/radiokicksfm/videos/3676516585958356/

CPython 3.8.13+OpenSSL-3.1.0-dev
yt-dlp_x86 -vF "https://www.facebook.com/radiokicksfm/videos/3676516585958356/" =>

[debug] Command-line config: ['-vF', 'https://www.facebook.com/radiokicksfm/videos/3676516585958356/']
[debug] Encodings: locale cp1253, fs utf-8, pref cp1253, out utf-8 (No VT), error utf-8 (No VT), screen utf-8 (No VT)
[debug] yt-dlp version<EMAIL_ADDRESS>[7237c8dca] (win_x86_exe)
[debug] Python 3.8.13+ (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 (OpenSSL 3.1.0-dev )
[debug] exe versions: none
[debug] Optional libraries: Cryptodome-3.18.0, brotli-1.0.9, certifi-2023.07.22, mutagen-1.46.0, sqlite3-2.6.0, websockets-11.0.3
[debug] Proxy map: {}
[debug] Loaded 1864 extractors
[facebook] Extracting URL: https://www.facebook.com/radiokicksfm/videos/3676516585958356/
[facebook]<PHONE_NUMBER>958356: Downloading webpage
[facebook]<PHONE_NUMBER>958356: Downloading webpage
ERROR: [facebook]<PHONE_NUMBER>958356: Cannot parse data; please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= , filling out the appropriate issue template. Confirm you are on the latest version using  yt-dlp -U
  File "yt_dlp\extractor\common.py", line 715, in extract
  File "yt_dlp\extractor\facebook.py", line 733, in _real_extract
  File "yt_dlp\extractor\facebook.py", line 680, in _extract_from_url

but
yt-dlp_x86 -vF --user-agent "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36" --add-header "Sec-Fetch-Mode:" "https://www.facebook.com/radiokicksfm/videos/3676516585958356/ =>

[debug] Command-line config: ['-vF', '--user-agent', 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36', '--add-header', 'Sec-Fetch-Mode:', 'https://www.facebook.com/radiokicksfm/videos/3676516585958356/']
[debug] Encodings: locale cp1253, fs utf-8, pref cp1253, out utf-8 (No VT), error utf-8 (No VT), screen utf-8 (No VT)
[debug] yt-dlp version<EMAIL_ADDRESS>[7237c8dca] (win_x86_exe)
[debug] Python 3.8.13+ (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 (OpenSSL 3.1.0-dev )
[debug] exe versions: none
[debug] Optional libraries: Cryptodome-3.18.0, brotli-1.0.9, certifi-2023.07.22, mutagen-1.46.0, sqlite3-2.6.0, websockets-11.0.3
[debug] Proxy map: {}
[debug] Loaded 1864 extractors
[facebook] Extracting URL: https://www.facebook.com/radiokicksfm/videos/3676516585958356/
[facebook]<PHONE_NUMBER>958356: Downloading webpage
[facebook]<PHONE_NUMBER>958356: Downloading webpage
[debug] Sort order given by extractor: res, quality
[debug] Formats sorted by: hasvid, ie_pref, res, quality, lang, fps, hdr:12(7), vcodec:vp9.2(10), channels, acodec, size, br, asr, proto, vext, aext, hasaud, source, id
[info] Available formats for<PHONE_NUMBER>958356:
ID                EXT RESOLUTION |  TBR PROTO | VCODEC       VBR ACODEC     ABR ASR MORE INFO
--------------------------------------------------------------------------------------------------------
998172518084032a  m4a audio only |  65k https | audio only       mp4a.40.5  65k 48k DASH audio, m4a_dash
dash_sd_src       mp4 unknown    |      https | unknown          unknown
673954957623594v  mp4 276x144    |  45k https | avc1.4D400C  45k video only    DASH video, mp4_dash
329723412734958v  mp4 460x240    |  96k https | avc1.4D4015  96k video only    DASH video, mp4_dash
1334094473848775v mp4 690x360    | 200k https | avc1.4D401E 200k video only    DASH video, mp4_dash
266105879550722v  mp4 920x480    | 333k https | avc1.4D401F 333k video only    DASH video, mp4_dash
682373210155474v  mp4 1380x720   | 606k https | avc1.4D4020 606k video only    DASH video, mp4_dash

CPython 3.9.13+OpenSSL-3.1.0-dev
yt-dlp_x86 -vF "https://www.facebook.com/radiokicksfm/videos/3676516585958356/" =>

[debug] Command-line config: ['-vF', 'https://www.facebook.com/radiokicksfm/videos/3676516585958356/']
[debug] Encodings: locale cp1253, fs utf-8, pref cp1253, out utf-8 (No VT), error utf-8 (No VT), screen utf-8 (No VT)
[debug] yt-dlp version<EMAIL_ADDRESS>[7237c8dca] (win_x86_exe)
[debug] Python 3.9.13 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 (OpenSSL 3.1.0-dev )
[debug] exe versions: none
[debug] Optional libraries: Cryptodome-3.18.0, brotli-1.0.9, certifi-2023.07.22, mutagen-1.46.0, sqlite3-2.6.0, websockets-11.0.3
[debug] Proxy map: {}
[debug] Loaded 1864 extractors
[facebook] Extracting URL: https://www.facebook.com/radiokicksfm/videos/3676516585958356/
[facebook]<PHONE_NUMBER>958356: Downloading webpage
[facebook]<PHONE_NUMBER>958356: Downloading webpage
ERROR: [facebook]<PHONE_NUMBER>958356: Cannot parse data; please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= , filling out the appropriate issue template. Confirm you are on the latest version using  yt-dlp -U
  File "yt_dlp\extractor\common.py", line 715, in extract
  File "yt_dlp\extractor\facebook.py", line 733, in _real_extract
  File "yt_dlp\extractor\facebook.py", line 680, in _extract_from_url

but
yt-dlp_x86 -vF --user-agent "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36" --add-header "Sec-Fetch-Mode:" "https://www.facebook.com/radiokicksfm/videos/3676516585958356/ =>

[debug] Command-line config: ['-vF', '--user-agent', 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36', '--add-header', 'Sec-Fetch-Mode:', 'https://www.facebook.com/radiokicksfm/videos/3676516585958356/']
[debug] Encodings: locale cp1253, fs utf-8, pref cp1253, out utf-8 (No VT), error utf-8 (No VT), screen utf-8 (No VT)
[debug] yt-dlp version<EMAIL_ADDRESS>[7237c8dca] (win_x86_exe)
[debug] Python 3.9.13 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 (OpenSSL 3.1.0-dev )
[debug] exe versions: none
[debug] Optional libraries: Cryptodome-3.18.0, brotli-1.0.9, certifi-2023.07.22, mutagen-1.46.0, sqlite3-2.6.0, websockets-11.0.3
[debug] Proxy map: {}
[debug] Loaded 1864 extractors
[facebook] Extracting URL: https://www.facebook.com/radiokicksfm/videos/3676516585958356/
[facebook]<PHONE_NUMBER>958356: Downloading webpage
[facebook]<PHONE_NUMBER>958356: Downloading webpage
[debug] Sort order given by extractor: res, quality
[debug] Formats sorted by: hasvid, ie_pref, res, quality, lang, fps, hdr:12(7), vcodec:vp9.2(10), channels, acodec, size, br, asr, proto, vext, aext, hasaud, source, id
[info] Available formats for<PHONE_NUMBER>958356:
ID                EXT RESOLUTION |  TBR PROTO | VCODEC       VBR ACODEC     ABR ASR MORE INFO
--------------------------------------------------------------------------------------------------------
998172518084032a  m4a audio only |  65k https | audio only       mp4a.40.5  65k 48k DASH audio, m4a_dash
dash_sd_src       mp4 unknown    |      https | unknown          unknown
673954957623594v  mp4 276x144    |  45k https | avc1.4D400C  45k video only    DASH video, mp4_dash
329723412734958v  mp4 460x240    |  96k https | avc1.4D4015  96k video only    DASH video, mp4_dash
1334094473848775v mp4 690x360    | 200k https | avc1.4D401E 200k video only    DASH video, mp4_dash
266105879550722v  mp4 920x480    | 333k https | avc1.4D401F 333k video only    DASH video, mp4_dash
682373210155474v  mp4 1380x720   | 606k https | avc1.4D4020 606k video only    DASH video, mp4_dash

that maybe FB serves different html to different regions.

Sadly 😢 , I can't test your theory about FB serving different page sources in different parts of the globe, as any attempt to use a VPN node/HTTPS Proxy (to "move out" of my region 😜 ) has resulted in a Tahoe API block 😠 ...

No solution yet?

Hi!
I have been looking into this, and Facebook would consistently return "RelayPrefetchedStreamCache\u00406fa52080e4dc537033301a17dbec99b5" instead of "RelayPrefetchedStreamCache". I fixed it by modifying the facebook function a little:
def extract_relay_prefetched_data(_filter):
return traverse_obj(extract_relay_data(_filter), (
'require', (None, (..., ..., ..., '__bbox', 'require')),
lambda _, v: any(key.startswith('RelayPrefetchedStreamCache') for key in v if isinstance(key, str)), ..., ...,
'__bbox', 'result', 'data', {dict}), get_all=False) or {}

Greetings, how does a person download Facebook videos that are only available for registered users? (such as those shared directly on a private group.)
C:\Users\+++++++\Downloads>yt-dlp.exe https://fb.watch/ps73RVDKQy/ [generic] Extracting URL: https://fb.watch/ps73RVDKQy/ [generic] ps73RVDKQy: Downloading webpage [redirect] Following redirect to https://www.facebook.com/watch/?v=285133124181047&ref=sharing [facebook] Extracting URL: https://www.facebook.com/watch/?v=285133124181047&ref=sharing [facebook]<PHONE_NUMBER>81047: Downloading webpage ERROR: [facebook]<PHONE_NUMBER>81047: This video is only available for registered users. Use --cookies, --cookies-from-browser, --username and --password, --netrc-cmd, or --netrc (facebook) to provide account credentials
 --username and --password doesn't work when I have the 2FA on, and the cookies from browser is denied.
`C:\Users+++++++\Downloads>yt-dlp.exe --cookies-from-browser brave https://fb.watch/ps73RVDKQy/
Extracting cookies from brave
Traceback (most recent call last):
File "yt_dlp_main_.py", line 17, in
File "yt_dlp_init_.py", line 1009, in main
File "yt_dlp_init_.py", line 963, in _real_main
File "yt_dlp\YoutubeDL.py", line 687, in init
File "yt_dlp\YoutubeDL.py", line 4128, in build_request_director
File "functools.py", line 967, in get
File "yt_dlp\YoutubeDL.py", line 4049, in cookiejar
File "yt_dlp\cookies.py", line 91, in load_cookies
File "yt_dlp\cookies.py", line 112, in extract_cookies_from_browser
File "yt_dlp\cookies.py", line 281, in _extract_chrome_cookies
File "yt_dlp\cookies.py", line 1042, in _open_database_copy
File "shutil.py", line 418, in copy
File "shutil.py", line 264, in copyfile
PermissionError: [Errno 13] Permission denied: 'C:\Users\+++++++\AppData\Local\BraveSoftware\Brave-Browser\User Data\Default\Network\Cookies'
[13972] Failed to execute script 'main' due to unhandled exception!
C:\Users+++++++\Downloads>`
Thank you.

Hi!
I have been looking into this, and Facebook would consistently return "RelayPrefetchedStreamCache\u00406fa52080e4dc537033301a17dbec99b5" instead of "RelayPrefetchedStreamCache". I fixed it by modifying the facebook function a little:
def extract_relay_prefetched_data(_filter): return traverse_obj(extract_relay_data(_filter), ( 'require', (None, (..., ..., ..., '__bbox', 'require')), lambda _, v: any(key.startswith('RelayPrefetchedStreamCache') for key in v if isinstance(key, str)), ..., ..., '__bbox', 'result', 'data', {dict}), get_all=False) or {}

That indeed seem to solve some of the cases if not all. :)

some additional info about the tahoe endpoint: https://github.com/yt-dlp/yt-dlp/issues/542#issuecomment-886241207

Facebook download is broken for me just recently [debug] Command-line config: ['--config-locations', '/data/user/0/com.deniscerri.ytdl/cache/config-TERMINAL[1724055006871].txt', '--cookies', '/data/user/0/com.deniscerri.ytdl/cache/cookies.txt', '--add-header', 'User-Agent:Mozilla/5.0 (Linux; Android 10; CPH2179 Build/QP1A.190711.020; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/126.0.6478.186 Mobile Safari/537.36', '-P', '/storage/emulated/0/Android/data/com.deniscerri.ytdl/files/downloads/TERMINAL/33', '--no-cache-dir', '--ffmpeg-location', '/data/app/com.deniscerri.ytdl-Z-mB9Bd2kzOoSfmyPlxQfg==/lib/arm64/libffmpeg.so']
[debug] | Config "/data/user/0/com.deniscerri.ytdl/cache/config-TERMINAL[1724055006871].txt": ['--buffer-size', '4096', '--no-hls-use-mpegts', '--write-info-json', '--write-playlist-metafiles', '--write-comments', '--merge-output-format', 'mkv', '--fixup', 'never', '--add-metadata', '--remux-video', 'mkv', '-vU', 'https://www.facebook.com/reel/1012634026633835/?mibextid=rS40aB7S9Ucbxw6v']
[debug] Encodings: locale UTF-8, fs utf-8, pref UTF-8, out utf-8 (No ANSI), error utf-8 (No ANSI), screen utf-8 (No ANSI)
[debug] yt-dlp version<EMAIL_ADDRESS>from yt-dlp/yt-dlp-master-builds [a7d3235c8] (zip)
[debug] Python 3.8.0 (CPython aarch64 64bit) - Linux-4.9.190+-aarch64-with-libc (OpenSSL 1.1.1t  7 Feb 2023, libc)
[debug] exe versions: ffmpeg 5.1 (setts), ffprobe 5.1
[debug] Optional libraries: Cryptodome-3.17, mutagen-1.46.0, sqlite3-3.30.1
[debug] Proxy map: {}
[debug] Request Handlers: urllib
[debug] Loaded 1830 extractors
[debug] Fetching release info: https://api.github.com/repos/yt-dlp/yt-dlp-master-builds/releases/latest
ERROR: [facebook]<PHONE_NUMBER>633835: Cannot parse data; please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= , filling out the appropriate issue template. Confirm you are on the latest version using  yt-dlp -U
File "/data/user/0/com.deniscerri.ytdl/no_backup/youtubedl-android/yt-dlp/yt-dlp/yt_dlp/extractor/common.py", line 740, in extract
ie_result = self._real_extract(url)
File "/data/user/0/com.deniscerri.ytdl/no_backup/youtubedl-android/yt-dlp/yt-dlp/yt_dlp/extractor/facebook.py", line 857, in _real_extract
return self._extract_from_url(real_url, video_id)
File "/data/user/0/com.deniscerri.ytdl/no_backup/youtubedl-android/yt-dlp/yt-dlp/yt_dlp/extractor/facebook.py", line 802, in _extract_from_url
raise ExtractorError('Cannot parse data')

@error-reporting don't pass the user-agent header

I was not passing any user agent header any user agent that you see is from using yt-dlp vebose log

[debug] Command-line config: ['--config-locations', '/data/user/0/com.deniscerri.ytdl/cache/config-TERMINAL[1724055006871].txt', '--cookies', '/data/user/0/com.deniscerri.ytdl/cache/cookies.txt', '--add-header', 'User-Agent:Mozilla/5.0 (Linux; Android 10; CPH2179 Build/QP1A.190711.020; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/126.0.6478.186 Mobile Safari/537.36'

How adding user agent header broken facebook download

Websites will serve you different content depending on the user-agent header sent with your request. The user-agent header in your command-line config returns webpage data that is useless to yt-dlp's extractor

ERROR: [facebook]<PHONE_NUMBER>48453: Cannot parse data; please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= , filling out the appropriate issue template. Confirm you are on the latest version using  yt-dlp -U
Latest version<EMAIL_ADDRESS>from yt-dlp/yt-dlp-nightly-builds
yt-dlp is up to date<EMAIL_ADDRESS>from yt-dlp/yt-dlp-nightly-builds)