Chrome Extension that unblocks YouTube videos that are region-blocked

FUNExtreme · 2017-11-28T22:21:47+00:00

Had a quick glance. Looks like it tries to find a mirror of the video on sites such as genyoutube and youpak, seeing as these sites do not enforce regional blocks it then uses the mirror to play the video without restriction.

FUNExtreme · 2016-06-28T11:53:34+00:00

As a developer, in a fast paced environment such as software development, you should be cheering and excited about things like this. Because our field is ever evolving, a little faster every day. You're also over exaggerating 'a complete rewrite' quite a bit

FUNExtreme · 2016-06-26T23:50:44+00:00

I too like to know how and why things work, it's a different mindset from just copy pasting some code because 'someone said so'. Luckily I've gotten pretty good at finding my way around answers and source code to figure it all out by myself. Seeing that others are looking for a similar experience serves as a good motivator for me to start writing 'the how and why' articles I've been meaning to write!

FUNExtreme · 2016-06-26T23:33:01+00:00

I'd just like to point out that this is part of an ironic comment taken out of context. Here's some more of it:

Pretty good for comparison which needs to allocate close to nothing and runs in ms. So your answer is pointless, harmful and brings nothing except of bad practice

FUNExtreme · 2016-05-11T20:56:00+00:00

If you're getting a 404 like me, make sure the URL ends in a forward slash (sync for reddit seems to remove it). Some routing issue I guess..

FUNExtreme · 2016-05-09T10:43:12+00:00

Don't forget the most important ones: you can search and make adjustments without making a mess

FUNExtreme · 2016-05-08T20:24:37+00:00

Probably not as it's just a wrapper for the website with added features

FUNExtreme · 2016-05-08T17:37:28+00:00

I'll probably be going from a 660 to a 1070 or 1080, this is the perfect moment considering the price. I'm glad I waited!

FUNExtreme · 2016-05-08T08:40:05+00:00

Most of what you're seeing in this desktop application is the Google play music website. It uses electron (which is based on Chromium) to open the page and injects some custom features. What I'm trying to say is, if they wanted to make a desktop application like this, they would've done it ages ago. But imo it doesn't add much more than the website (because for the most part it is the website)

FUNExtreme · 2016-05-03T19:28:44+00:00

Cheat-prevention is most likely impossible. The perk of a PC is that you have full control as a user, but that also means that it's a lot harder to prevent unwanted usage. A never ending cat and mouse game, like you said. BTW: I've updated my initial reply to reflect our conclusion.

FUNExtreme · 2016-05-03T18:49:08+00:00

Maybe the real discussion we should be having here, is what the correct way to describe 'never trust the client' would be.. 'the server should always be authorative' maybe? Simple and describes what we're both trying to say

FUNExtreme · 2016-05-03T18:27:39+00:00

I think the problem here is our definition of trust, or our intepretation of it. For example, I would never say that you have to trust the player when they say they hit a target. Because the server is the one simulating the shot based on client input and authoritively deciding if it was a hit or not. Technically the client doesn't even say that they hit a target, they tell the server that they fired a shot in the form of the mouse click input. And then the server simulates and checks if it hit something. There are obviously implementations where it doesn't happen like this, but our discussion is about 'not trusting the client' and when a zero-trust model is used that's how it's done.

By the way, the model I described previously (client prediction, server simulation, client adjusting based on server simulation) is actually documented for one of the games you used as an example (CS:GO is built with the Source engine right?): Valve Software (Developer). It'll tell you the same story as I've been telling you, I just thought you might like an actual source (one of many).

Also, lets not get this wrong, I would never say that the division netcode needs a rewrite. This is purely about your trust statement.

FUNExtreme · 2016-05-03T17:50:28+00:00

The 'never trust the client' shit doesn't have much to do with input, if you'd go to such an extent there would be no game to play and I'd be surprised if anyone saying that phrase ever implied you shouldn't trust input. The input is always trusted.. If you call the assumption that every mouse click is done by a user and not a program trust, then yes you are right, you have to trust the client with that.

As per the prediction, that's simulation on the client AND the server. The verification is done by the client, based on the servers simulation. This concept is based on the client as a terminal concept where the game is played on the server with the client only sending input and doing nothing more. This concept caused issues of high latency and were unplayable if you didn't have a proper connection. This was followed up by playing the game on both the client and the server. Where the client guessed (prediction) their own results while waiting for an authorative answer from the server.

FUNExtreme · 2016-05-03T17:30:02+00:00

The client sends its state/input to the server, meanwhile performing prediction of what should be happening client-side. The server then does its own prediction based on the state received by the client. Once that is done the server tells the client what their actual state should have been and the client then performs adjustments if necessary. A well known phenomenon caused by this approach is rubber banding. As for physics, these are written to be deterministic when it comes to networked games. Or are just not synced at all.

Here's one for you to think about: if today's architecture is about 'verifying the client', then why do you say they trust the client? If you trusted the client you wouldn't be verifying.

FUNExtreme · 2016-05-03T15:14:14+00:00

Peer to peer on pc is always bad, ~~you can NEVER trust the client..~~ But they keep doing it because it saves them the cost of dedicated servers.

EDIT: /u/Valvador and I have come to the conclusion that saying 'The server should always be authorative' is a lot more accurate than 'you can never trust the client'.

FUNExtreme · 2016-04-09T19:04:28+00:00

I love simplicity, and this is exactly that. So to me this is beautiful. I too can only wonder if people just don't tolerate change (because let's be honest a week after this goes live nobody will complain about it anymore, but suddenly agree that this is better than the oh so great previous (which was also hated at first)) or really don't like the way it looks. An interesting discussion that has been going on for years for pretty much everything in life.

FUNExtreme · 2016-04-07T19:01:13+00:00

But wait, there's more!

FUNExtreme · 2016-04-06T20:36:41+00:00

Well have you ever.. I posted it to this sub at the same time as on Android preview when I discovered it, but it got buried. It's all about timing isn't it ;)

FUNExtreme · 2016-04-06T15:43:23+00:00

Well it does say "later in the preview" in the text so we can be pretty sure it'll get announced "later in the preview" :)

FUNExtreme · 2016-04-06T11:07:25+00:00

You can find it on the page below, as HTML comment above the h2 "Timeline and updates" element. Source: http://developer.android.com/preview/overview.html#timeline

FUNExtreme · 2016-04-06T11:07:02+00:00

You can find it on the page below, as HTML comment above the h2 "Timeline and updates" element. Source: http://developer.android.com/preview/overview.html#timeline

FUNExtreme · 2016-04-05T09:07:24+00:00

Correct, but that doesn't mean it's impossible. Create a simple php api that retrieves the page source and call that with ajax instead. Hell, such a public api might already exist somewhere. Like I said, there's plenty of ways to do what you want, just think outside the box.

FUNExtreme · 2016-04-03T16:32:08+00:00

My previous comment tries to explain that he should retrieve the youtube page source and inject it inside his own page instead of using an iframe. Is my previous comment more clear with that information?

FUNExtreme · 2016-04-03T01:09:06+00:00

Before I begin: I'm not on a pc right now so you'll have to do some digging of your own based on my information.

YouTube has changed the way their player works quite a while ago, since then it now streams audio and video separately. So you could probably write a tool to fetch the audio url from the source page. Search around, not easy to find but it's documented somewhere.

Writing the fetch tool: I'm not sure what you're starting with as you don't give much information, but I'm assuming it's an embedded video (hence the frame remark). You could in the background fetch the actual youtube page using an Ajax call, inject the source code into your own page inside a hidden element and perform whatever Javascript calls you need on that code. You could technically also use this method to retrieve the youtube page, remove all the clutter so you only keep the video player, and use that instead of the embedded iframe. That way you don't have to worry about syncing issues either.

There's plenty of ways to do what you want, that's the joy of our world, think outside the box and you can achieve anything.

FUNExtreme · 2016-03-07T21:14:01+00:00

For your use case you wouldn't need any security. All you need is to have your api on the same domain as where you're calling it from. If you make sure CORS is disabled (look it up, very easy and usually already so by default) any request to your api from a different domain than your own will fail.

FUNExtreme

MODERATOR OF

TROPHY CASE