Let's make money


#1

Let’s make money.
There’s a demand for video sharing.
So multiple users can watch the same video at the same time.
This is a perfect opportunity to make money.
High fidelity is leaving it open to us.
It can also be free to the user.
youtube and other video sharing sites are doing it.
Use programs like node.js to do the syncing and collection of data.
Sell their information. High fidelity has left it open to us to take advantage of.
Let’s not let this go to waste.


#2

Just a question…
How do you see the input for this?
Would you like to paste or type the url ? or navigate on the web directly on youtube in vr? or have a place where you can prefill a list of url in order chose what you want to play from that list in-world ?


#3

The best way to do it would be to use A program like node.js.
This server will just synchronize people watching the same video using an apps.
As long as the URL is the same while using the apps.
All personal data would be stored in the log.


#4

Might be easier if the videos were queued on domain-stack and when a user enters into the domain, they can use built-in search (that the domain-owners provide) that will teleport them to the correct ‘zone’ inside the domain that has video results of their search.

In this manner, placement of zones and content within can be managed outside of Interface, and outside of Stack-Manager. High Fidelity has provided excellent means of relaying data back and forth. Leave the client and the server lightweight. Put the heavy lifting on the AWS or Droplets.

That is how I would do it.


#5

HiFi has a messages API for sending signals for synchronization so using node.js isn’t necessary. Node.js is an entire server framework which is a lot of bloat for solving such a small problem.

@Alezia.Kurdis and @AlphaVersionD ask some good questions. Is the entire browser synchronized, is just the video synchronized, is your desktop synchronized. Do you modify the url on the entity in interface or do something in stack manager? I think the easiest way to get something up and running is to past a YouTube url in the entity/script and have the messages API synch the current time of the video across clients.

Making money on this would be difficult and require a lot of investment as bigscreenVR already is the big player in the space.


#6

The main problem with modifying the url of a WebEntity is the fact that as soon as a web entity is modified (forexample, updating the timestamp on the url, due to cache busting), the entity refreshes, breaking playback every time it is updated, which is not a very “seamless” experience.

I think we need an dedicated MediaEntity or a Flag for Web Entities that disables reloading of the WebEntity, after this has been loaded. When this flag is toggled back off, the web entity should work as it currently does, and on change update the page. You could then write rules via scripts to toggle this property on update, by checking if the url has changed enough to update the page. This way anyone loading the entity should be synced within a few seconds, depending on their connectivity, and if the have the video already in cache or not.

The only down side to this is that the video will still not, reliably, be always in sync thanks to media provider advertisements. Many video providers now tend to have preroll, midrolls, postroll ads, which tend to cause everything to out of sync after loading, while we can always rely on the ads being of various lengths.


#7

Qml has a YouTube view example (http://doc.qt.io/archives/qt-5.5/qtwebkitexamples-webkitqml-youtubeview-example.html) which you can use to update the time with the YouTube API instead of going through the browser and adding the time stamp to the url. You probably still don’t want the entity to refresh.

I’m not sure how to fix advertisements. I’ve forgotten about them since I’ve gotten YouTube red.


#8

Another issue I can forsee, unless something like the dedicated MediaEntity having a workaround for this, is that unless otherwise specified or my information is incorrect, WebEngine doesn’t have access to H.264. To gain access, an additional parameter needs to be passed (-proprietary-codecs). This has pretty much made watching streams on Youtube not doable. Source: https://doc.qt.io/qt-5/qtwebengine-features.html

Hmm… I think there is a way to load qml stuff on an entity, or at the very least, a trick that could be done. With some clever JSON stuff, you could keep the ‘timestamp’ on the hosting zone’s information. The only issue I see is who does the updating for it?


#9

Hmm.

The specfic trick would be load up an overlay infront of the entity, and scale that overlay with it. This is doable, and that way its always only client side.

Actually you could also just use WebOverlays, so… technically this could be entirely doable via just regular entities with a script that loads up an WebOverlay (not sure if there is a QMLOverlay) that is parented to the entity, which loads up the video. The script then just monitors any changes to userdata, and monitoring if there are any major changes to the userdata.

I think this would require absolutely no changes from Hifi client and could be done via client loaded scripts instead. although the Codec issue will still be present though.

We should experiment with this.


#10

Someone looked into the codec issue for a worklist job. I can’t find the job though. The HiFi team is at least aware of the issue.


#11

You miss the point entirely.
These features that were left out of High Fidelity are wanted. We might as well take care of it. Using external servers will allow us to gather more information. Of course using the built in messenger server will be more efficient. but it will not allow us to get the data.


#12

Didnt see one of worklist, but they do have on fogbugz, 4306 point to Worklist https://worklist.net/21490.

According to the ticket they got stumped until after the Qt Update to 5.9 which finished only a few weeks back, it is however on the docket.


#13

But shouldn’t this issue be taken care of by a app in the app store. I’m sure this can be beneficial for both sides.


#14

If anyone wants some example code for synchronizing the video using the youtube API, check out YouTube-Sync on github. It uses peer.js to send messages between clients but it should be easy to replace that with the signals in Hifi’s messages API.

When someone pauses, plays, or syncs the video, it sends out a signal so everyone’s video pauses, plays or syncs.


#15

That’s the one. I wish worklist search worked better. I wonder if HiFi decided to update the webengine config


#16

I saw this one. A little old don’t you think.


#17

You can log the signals going through the messages API if you want. You run the HiFi server serving the messages. The High Fidelity company doesn’t run it.

That code is just an example, the YouTube API might have changed a bit but the general flow of the code should still be useful.


#18

How to set up your own private RTMP server using nginx.

https://obsproject.com/forum/resources/how-to-set-up-your-own-private-rtmp-server-using-nginx.50/


#19

From what I can see, the way it works is it sends out a timestamp to everyone, and everyone sends a timestamp back, checking to see how far apart everyone is. If a threshold is hit, it syncs everyone up, unless manually done.

The only issue I can see is how do we determine the host, or do we use a zone party system much like how the demo worked? Would one person go into a zone, ‘claim’ it, then give it updates on what the timestamp should be in the JSON of the zone/entity?

Basically, here is how I see it:

  1. Server does everything - Server handles the audio through the audio mixer and takes in the stream itself to broadcast to other users (video mixer?). This means the server is the only entity that needs any plugins, not the users themselves. Only issue is that most people’s servers bandwidth will most likely cry, especially since this scales badly.

  2. The zone has a host - When someone enters a zone, they are deemed the ‘host’ until they either leave or give the host properties to someone else. They’re client’s job is only to keep the time stamps updated on the JSON for everyone else to read. The problem comes from what happens to host management (host DCes, leaves, etc).

  3. Passing of the baton - As people come into the zone, they will be informed where everyone is as they update each other. Users just need to know the URL of the video (from JSON) and the timestamp is not recorded at all in an object. This basically means everyone is peer to peer, all only moving forward when the user who was unsynced is now synced. Of course, this also means it only takes ONE person to slow everything down, unless we have a different catch up rule, where the person is moved say 2 seconds ahead to hopefully start when their time stamp is announced.

However, in the end, this doesn’t solve streaming issues, but would allow syncing of videos (at least for YouTube).


#20

Another option is to combine 1, 2 and 3 in your list. You could have a server entity script/assignment client script (host) that watches the peer to peer timestamps from client entity scripts. The host would have control over when to sync.

That script could have a manual override where a server owner or other chosen user could go in and press sync. Eventually you could add in different ways to sync or even add a visualization where the server owners can see statistics on how far people watching are behind and what individuals are lagging so they can decide on the best way to sync.

If the server owner disconnects, the script would still play the video and might have some default functionality for keeping things in sync.

So the default is a combination of your 1 and 3 and someone can step in to make it more like 2 and 3 with a little 1 as well. I think this is the type of thing which is solvable but will require iteration to figure out what works best.