When you are trying to one-box a youtube URL, Youtube automatically redirects to a page named consent.youtube.com. This page doesn’t have an oEmbed/OpenGraph tag, so oneboxing is unfortunately failing.
This is definitely not Discourse’s flaw, but has to do with a (as it seems) breaking change on Youtube’s end. I suspect this happens due to some new Europe regulation, because I can’t reproduce on meta.
Our server is in Europe (Germany) and you can see the redirecting URL here.
Somewhat eleviated with Onebox Assistant plugin, but not fully (it will render the embed but no longer return the Title).
I think there must be a specific implementation for Youtube through an API key or something…
I logged on here last night to report this exact issue as it’s been happening to us recently too, but when I pasted my example YouTube URL, it worked fine here on meta 
My discourse is v2.7.0.beta5 ( 61860098d9 )
Most probably because meta’s server is not in Europe 
Neither is the UK now 
The issue is related to the “Data Consent Form” and OneBox catches that instead of the actual content.
If instead of using the https://youtube.com/watch?v=XYZ you change it to https://youtu.be/XYZ it works because that’s the “Share URL” and that doesn’t pop the Consent Dialog. (However, this is not ideal).
Unless Discourse/OneBox “autochanges” the URL to the “Short Version” when oneboxing, maybe, as a quick fix? IDK, just giving more info/feedback.
As a media-heavy community we have thousands and thousands of YouTube videos shared by our members with several hundred being posted per month.
This change by YouTube is proving to be a real problem already but I don’t think it’s something that can be solved by Discourse if YouTube themselves are forcing a redirect to their consent page?
Just adding my +1 as this will be a big problem for our community too.
Update: Title is working again (as well as embed) with Onebox Assistant.
So if discourse were to rewrite the url as you describe when the post was cooked that would fix it?
If that’s the case a plugin could fix it (maybe even a theme component?) , and I would guess that it would be PR welcome and/or that they’ll fix it pretty quick.
Technically, yes. I did many tests and it’s constant, it works with the short URL, not with the “official” one.
I wouldn’t consider that a stable workaround; there’s a good chance Google will apply the same policy to those in the near future too.
Yeah, it isn’t.
Just find it very “funny” because both: https://youtu.be/VIDEO and deleting “www” on the normal url, so: https://youtube.com/watch?v=VIDEO work. So the criteria for “blocking” with the consent popup is not very “logical” from a user’s perspective.
I don’t disagree, but that leaves the only solution being not to use YouTube. 
You’d also need to catch the composer preview, to prevent showing this catastrophic failure message to the user:
Ouch, we should certainly investigate this! Thanks for reporting.
Is it possible for you to test those URLs again? This is what I’m currently seeing from a server in Frankfurt (wget output edited to just show the redirects):
wget 'https://youtu.be/KCyIfcevExE'
--2021-04-06 19:03:39-- https://youtu.be/KCyIfcevExE
Location: https://www.youtube.com/watch?v=KCyIfcevExE&feature=youtu.be [following]
--2021-04-06 19:03:39-- https://www.youtube.com/watch?v=KCyIfcevExE&feature=youtu.be
Location: https://consent.youtube.com/m?continue=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DKCyIfcevExE%26feature%3Dyoutu.be&gl=DE&m=0&pc=yt&uxe=23983172&hl=de&src=1 [following]
or
wget 'https://youtube.com/watch?v=KCyIfcevExE'
--2021-04-06 19:05:45-- https://youtube.com/watch?v=KCyIfcevExE
Location: https://consent.youtube.com/m?continue=https%3A%2F%2Fyoutube.com%2Fwatch%3Fv%3DKCyIfcevExE&gl=DE&m=0&pc=yt&uxe=23983172&hl=de&src=1 [following]
--2021-04-06 19:05:45-- https://consent.youtube.com/m?continue=https%3A%2F%2Fyoutube.com%2Fwatch%3Fv%3DKCyIfcevExE&gl=DE&m=0&pc=yt&uxe=23983172&hl=de&src=1
Location: https://consent.youtube.com/ml?continue=https://youtube.com/watch?v%3DKCyIfcevExE&gl=DE&hl=de&pc=yt&uxe=23983172&src=1 [following]
(i.e., those two URL formats are now also redirecting to the consent page)
