I'm definitely NOT attending an interview where this kind of tech is used. My heart rate is irrelevant to whether someone should hire me - and I say that as someone who doesn't even get anxious or nervous during interviews.
Not for interviews, video-applications, is used to sense stress and give extra points (not deducting them) if a person is indeed just too shy of being on video vs talking about something ; )
Started uni recently. My friends have those. They don’t have or use a mouse. All they use is touchpad and the touchscreen. Well, to be honest, a lot of them don’t have a touchscreen yet still don’t use a mouse.
I think it describes a somewhat common scenario, where it's on by default but there's an effort made to make it seem like you went out of your way to agree to it.
Like a pre-checked box on a form about your desire to receive marketing mails.
which is very similar to what you do, but runs into an issue of throttling to ~70Kbps. Is the difference just the "key" parameter? Do you get no throttling?
There is no throttling when using the JSON returned by the HTTP request in the shell script or generated by the utilities I wrote.
it's not the key the author is using, it's the post-data.
Moreover, to get throttled videoplayback URLs with the "WEB" key and client info like the author is using, one does not need to make POST requests to /youtubei/v1/player. There are throttled videoplayback URLs in the HTML of the /watch?v= page. For example,
curl -A "" -40s https://www.youtube.com/watch?v=aqz-KE-bpKQ|grep -o https://rr[^\"]*|sed -n 's/\\u0026/\&/g;/itag=22/p'
It's ironic how the author is claiming this is complicated. That's his own doing.
Interesting. I ran the script to extract the json - that part was almost instant, then i used the first `url` field of `streamingData.adaptiveFormats`. I then ran
for me the download is throttled to "768k", i assume thats in bits per second and not bytes which is very low: the random video i tried would take 8 minutes.
on the other hand,
yt-dlp videoIdHere
does its processing then downloads the whole thing in about 5 seconds.
Does that curl command run much faster for you? Or do you do something else?
Is 768k too slow to watch the video from the URL. If not, then I would not call that "throttled". Don't need 500 MB/s to watch a video. From what I've seen, when people discuss YouTube throttling online they are referring to max speeds of 60-70k. That's too slow to watch the video from the URL. Not too slow to download, though. And that's why this idea that YouTube is "preventing" downloads doesn't make any sense. There are download URLs in every /watch?v= YouTube page. Those are throttled. Max speed 60-70k.
Use this post-data and should get same speed as yt-dlp.
I should add that with respect to the download URLs in the HTML of every /watch?v= page some will not work at all, namely, in the case of heavily commercialised videos, videos using DASH and some other uncommon cases. But I always found this is minority of linked YouTube videos one encounters on the web.
iOS and Android clients do not yet have URLs with the "n" parameter. This is why specifying the clientName as "IOS," along with the specific YouTube key, currently yields URLs that remain unthrottled.
However, acquiring this key requires decompiling the mobile application, monitoring requests through a proxy, or relying on values discovered by others. It's not necessarily straightforward.
I do agree that the code is simpler this way.
I also find it interesting that, by default, yt-dlp calls the YouTube API three times, initially as an Android client, then as an iOS client, and finally as a Web client. Depending on the video and certain other parameters, YouTube provides different formats to different clients.
"However, acquiring this key decompiling the mobile application, monitoring requests through a proxy or relying on values discovered by others."
This is again not true. The key is in the HTML of every /watch?v= YouTube page. It's a public key; it's not hidden in any way.
Further, it's possible, up until today at least, to use the "WEB" key with clientName "ANDROID" of "IOS" and receive unthrottled URLs. The key in the shell script is in fact the WEB key. The key for IOS is different.
default ctrl-f will only search through the current page while the site-provided one can search through all content... this is not really an argument against it existing
But it's about inpage search, it's just a lazy loading page.
The dedicated search field is for searching my websites and the result would be a list of my pages that contain the search term. Ctrl-F jumps to the location of the search term on the page I'm already at.
@pessimizer, @SuperCuber - So educate me. Let's base it on something I've actually done, a code analyser. For this you parse the code into an AST, and to deal with lexical scopes of declarations of procedures/variables etc. you have a stack of symbol tables.
So we've got a tree (the AST), we've got a symbol table for the current scope (a hash table of <id, info> pairs), and we have a stack of symbol tables (a stack).
A tree, a hash table and a stack. Those are data structures. What more needs to be added to this definition to turn it from "data structures" into a "data model"?
Firstly this is a serious question, secondly I have a great deal of experience of defining data structures to solve problems, so I can't see what adding an abstract term is doing.
You could say that the extra something is the specification/maintenance of the correct interrelationship between those data structures (and I'd agree), and there's a word for that: it's called 'code'. I genuinely don't understand what you're getting at and I'd genuinely like to know.
And no answer :-( It does rather defeat the point of discussion here if people say things they won't back up. I don't know if I've changed your mind, you certainly haven't given me any reason to change mine, so why post?
Hopefully the Rust syntax is not too much of a distraction here, but enough to focus on the `struct` and `enum` parts (an enum in rust can be "one of" the variants, like tagged union or sum type in other languages, or | operator in typescript). The project is a live wallpaper/screensaver that is a simulation of something like a combination of the games Factorio and Mini Metro.
I had in mind what I wanted to happen - a grid containing a rail network with trains running between different nodes.
What I call the model is the representation of the things in the code: I could store the train's position in terms of [float,float] and a facing Direction, but instead I choose to store it in terms of List<[int, int]> of grid tiles that it plans to go through, then an int for its current position in the list, and then a single float between 0 and 1 representing how far into the tile it's moving.
The two possible solutions have pros and cons, and there are other solutions as well that are equally valid I'm sure. In my mind, the process of "modeling your domain/problem space" is about deliberately thinking about these things and choosing what you think is the best.
I completely, fully get what you're saying and I've done this trade off between various data structures for a very long time, but my question wasn't about that, but the difference between data structures and data models. Put simply, it was a question of terminology used rather than technique applied.
I guess in the way I use it, choosing a data structure is about the complexity/performance of operations you're going to do with a collection of objects, and choosing a data model is more about the meaning of fields, and what entities and relations between them you have in the first place, sort of like `CREATE INDEX` vs `CREATE TABLE`
Are you complaining about the lack of dark patterns that push you to accept all cookies? When that cookie banner opened for me, I thought "finally, one of the moral ones" because all the non essential cookies are turned off by default, and you have two options with the same visual weight to either accept or reject the others.
Moved to them from gmail, set up *@firstnamelastname.com and the ability to send and receive emails from my old gmail, then moved all my accounts over (pretty easy if you have a password manager)
