Playing youtube


I was watching some youtube videos on a web entity playlist kinda thing
Smokey arrives and hears and sees youtube but shes seeing 3 songs earlier
Can it be made so we both see the same thing?


Hmm, would be nice. but the trick is here that youtube is seeing smokey as a new user. and start playing from the begin. Something like that.

I think that can only work if it used some proxy where everybody conect to and the proxy get it from youtube.


is no point playing a video if everyone cant see it at the same time


There’s no easy way to do that at the moment, something we’ll definitely be looking at.
In the mean time you can use already existing services to synchronize youtube like


Ah i use that will that work in hifi?


Never actually tried, but I see no reason why it wouldn’t.
Available to test it if you want.


You can, but it take a bit of scripting to do that. What I did in legacy grid is to monitor when people arrive in the scene and then send them the vid URL with a time index.

Basically, everyone runs with a a separate session, so synchronizing it requires an additional tweak.

[edit] oops, changed lagacy to legacy - unintended typo pun.


no dosent start playing with sync vid grr

re scripting, i need to be less dumb to do that lol


Oh yeah, just tried, my bad. does work though.
The only thing is that you have to confirm your username when the page load and you can’t put it full screen AFAICT.
But I’m sure you can find better alternatives out there.
Maybe even some that synchronize the entire webpage, not just youtube.


Right now the web entity is a locally rendered browser control attached to the URL. Navigating in the browser will move you around, but it won’t affect any other user looking at the same screen. Once thing we could do is allow access to the HTML/JS context in the web entity. In that case you could attach an entity script to the browser that would see when it had changed URL and update the entity itself so that other people who saw it would also see it update. However this invites all sorts of problems, since there are lots of sites like youtube where the state of the page is more complex than just the URL, or lots of pages that show different things depending on whether you’re logged in or not, and who you’re logged in as.

Ultimately, the web entity is designed to allow you to render web content, not to act as a hub for shared browsing. Granted, that doesn’t really make a lot of sense in the context of High Fidelity, where the idea is that you’re in a shared space and everyone is seeing the same thing. But my original goal in adding it was to allow much easier creation of static content, like game instructions and event calendars and the like. Making it possible to interact with the browser with a regular mouse and keyboard was actually a bit of feature creep that I allowed myself to be talked into.

Eventually I think it would be nice to have a completely different kind of entity that is specifically designed for shared interaction with a common ‘computing surface’. If you’ve ever used remote desktop tools like VNC or Windows Remote Desktop, then that’s you get what I’m talking about. You could use something like that to connect to a MAME emulator running somewhere and then have javascript running that allows people to come up and play the game, even two player.

Alternatively you could have something like a Twitch entity that connects to a specific twitch video stream, which either you or someone else could broadcasting on. Unfortunately most systems like twitch tend to have a very long delay between when you send and when a connected viewer receives it.


Let us not forget the question versus the huge generalization that has ensued. @Judas is asking for a point solution.


For youtube specifically, you could write an entity script that would check for the number of avatars at a regular interval, and if a new avatar appears then it would grab the current current local video URL and update the entity so that everyone was on the same video. This would have the unfortunate side effect of restarting the current video every time someone new came in range of the entity.

Right now I don’t think there’s any way to access the web entity internal JS context, so you can’t do something clever like get the exact time of the video and sync the URL to that timecode, but maybe in the future.


As I wrote a few posts earlier you use &t=nnn which is how I handled that point problem elsewhere. You can have the script be the initiator of the video, then it can know how long it has been playing. Then when others enter, it autoplays the video in their respective sessions with a tie index. Like this:



Why not just use the VNC @jamespollack wrote about on the blog? If you have enough bandwidth you could simply run Youtube on the desktop, and pump it into HF that way.

I’ve got a few things I’m going to try in June that might count as “shared real time videos” Such as local performances, where the RL person is mapped via PrioVR to the HF avatar IK.

2016 is going to be an interesting year. Let’s hope I don’t mess it up. :smiley:


ill have a try with, ‘watch together’.
I was more thinking about the teaching learning experience offered by vr, or if i was giving a presentation and using it I would expect synchronization .
I really like the idea of streaming from the web and would prefer a occam’s razor approach rather than having to have a complex bolted together solution.
Do you remember the teacher trying to make the vhs player work?
Teachers don’t have time during class to fight the technology.


Poor teachers today. It’s not some easy vhs that’s used anymore. The disaster is much bigger, interactive schoolboards. computers, tablets. Do the still have the foe lessons ?


That should actually be possible right now.

  • In a classroom environment, create a ‘teacher’ object like a button or something and put it in the world.
  • Attach a script, so that when the button is pressed, clicked, whatever, it pops up an overlay web window locally (similar to the browser window you get from hitting Ctrl-B). This is the teacher view.
  • Any time the URL on the teacher view changes, the script could push the new URL to an in-world web entity which is visible to the students.

This would suffice for some simple stuff, but it doesn’t solve all the problems. If the teacher wants to highlight a piece of text or scroll through a long document, the students don’t see this reflected in the web entity.

Alternatively, you could get at least as much, if not more functionality if instead of relying on a web view, the script opened up overlay windows for everyone. The teacher’s instance of the script can communicate with the instances running for students over the messaging API, and you have access on each end to the JS context in the overlay window QML.