Wasabi - My attempt at an interactive CH Video 'Player'

[PuzzleheadedWasabi]

Hello,

I stumbled upon this thread a couple days ago and started arguing with people about what's the best way to go about building an interactive CH video player. This ended in me trying to build my own

I call it... (drumroll please....) Wasasbi! (!!)

It looks like this:



It's open-source. You can view and clone the source here: https://github.com/PuzzleheadedWasabi/wasabi

The big difference between what many other players might do and Wasabi does is that WASABI ISN'T ACTUALLY A PLAYER. The long term goal would be that you just run the .exe (possibly once if you're ok with having it startup with windows), and then you play video files as you normally would - whether that be through VLC (or other players) or streaming them through Plex.

I'll say this again because it's basically the entire point of the tech: from the user's perspective, to add interactivity to standard .mp4 videos you may download of this site, all you have to do is download and run an .exe file once. That's it. No loading things in the browser, no creating .bat files, no opening another player, no updates, no installation of config files, no readjusting to a new interface. Just download and run it, and play your videos as you normally would*.

*as long as you normally play your videos through a supported player, like VLC and hopefully like Plex and hopefully support can be added for what 99% of us use.

For now, it's just a proof of concept (so it doesn't actually make anything interactive yet) because it's not really a good idea to spend weeks coding stuff if nobody is actually going to use it. But it does integrate with VLC, so it's a kind of proof that this kind of tech is possible. To run the demo, download and run this file (or feel very free to clone and compile yourself, I'm using VS2017), then open any file in VLC that has 'wasabi' in its title (other videos won't trigger, as a demonstration that Wasabi can detect what video is playing). More details at that first GitHub link. The app will control the playback a little bit by seeking forward to 20 seconds, pausing, playing, printing the video's current time, and then exiting VLC.

How would videos become interactive? Creators could create (hopefully very simple) config files (say, .CHVP files) that can be loaded into Wasabi, or preferably uploaded to some database that Wasabi could automatically load (if you're comfortable allowing Wasabi to access the internet). Then you'd just watch your video as you normally would, and Wasabi would add interactivity as per the instructions in the CHVP file. This might mean assigning certain actions to certain keys at certain times in the video, triggering random events, displaying text or visual effects on screen, keeping some kind of score counter, etc.

Possibilities: 'Snakes v Ladders' games, Video maze games (as opposed to Milovana teases), jumping to timestamps (Inferno Canto), use of power-ups (Inferno Canto), randomness for denial / ruin / allow...

This is not intended to be a game engine. If you want to make a fully fledged GAME, Wasabi is a terrible idea. But if you're making a VIDEO and want to add interactivity, or perhaps you want to make something that blurs the lines between game and video and sits somewhere in the middle... then I think Wasabi could be perfect.

This was mostly just an experiment to see if the tech can work, and it's my first C# project, so excuse any noob-ness. But, I think it turned out well.

If people are actually interested in building on this I would be very happy, and if anyone wants to contribute feel very free. If there's interest I could probably tackle further integrations and actual features. If not, happy to let this die.

Feel free to ask any questions or voice any thoughts. Very interested to hear arguments or opinions on competing interactive CH approaches, on whether YOU (as a creator) would be interested in building stuff for this kind of tech, on as to whether YOU (as a viewer) would be interested in using this kind of tech, on how YOU watch videos (do you use Plex? Something else?), or anything else.

If you want to read some of my ramblings and argue with me about the theories of building these kind of apps: clicky

[fagustree]

I'm glad more people are looking into these things. Interactivity in CH vids is pretty cool...
I had shied away from executables due to platform support and code trustworthiness. I know you opened the source, but safe distribution and the possibility of someone, someday sneaking something like a bitcoin miner in the program made me opt for trying my luck with web technologies and using what the browser had available.

So far, so good.

[doremi]

I know you opened the source, but safe distribution and the possibility of someone, someday sneaking something like a bitcoin miner in the program made me opt for trying my luck with web technologies

That why it's very important to provide a way to test the integrity of the download to make sure the content has not been tampered with. And for myself, I review the sources I'm about to compile. About web technologies, fagustree, they can be under attack as well. With all the huge libraries and complex dependency relationships hosted on multiple servers, the possibilities of a bad actor are real. It's very important not to have a false sense of security.

[high_octane]

My project (viewtopic.php?f=25&t=22131) was meant to automate many of the aspects of interactive CH software, among other things, but the scope of it was absolutely gigantic, and I'm only one person who has very little time to devote to thinking about it. There are just so many other things I want to do that it is completely overwhelming.

[PuzzleheadedWasabi]

I had shied away from executables

Believe me, I get this. If I see an .exe on this forum, unless I'm hugely interested, I tend to close the thread. Unfortunately what I want this app to do can't be done using web tech. The dream here is that this is the final .exe you'd need to trust for all interactive CHs (as opposed to each release being a new .exe)

Like you pointed out, it's open source, so you can always compile it yourself to be sure there's nothing fishy going on. Not sure what else I can say to convince anyone it's safe, other than perhaps this: if I DID want to spread viruses (I don't), I think there's better ways of doing that posting .exe's on this forum.

Another thought: don't many of us use and trust TeaseAI? I think if someone does end up making a killer new interactive CH that uses Wasabi, it would hopefully be enough of both an incentive (want to watch new thing) along with a reassurance that its safe (lots of people using it without issue, open source) to let people trust and use Wasabi.

[fagustree]

Which part can't be done by web tech? I'm afraid I still don't understand all of your plans for wasabi.

[PuzzleheadedWasabi]

Which part can't be done by web tech? I'm afraid I still don't understand all of your plans for wasabi.

Plans is a bit too grand of a word ;) I'm very not sure if this will pick up traction, and I'll only really tackle this if it does.

Super TLDR: Most similar apps are dedicated players. Wasabi isn't a player, it integrates into existing players. The only big difference (and when I put it this way, I realise it sounds like a tiny difference): instead of using this new second player, you use any player that you want. That's the only real difference.

Say some big name creator makes a new interactive video that uses Wasabi. It's an mp4. You download and play it as you would normally download and play mp4 videos - through e.g. VLC.

Here's the kicker (what I think is important): Wasabi detects you're using VLC and magically integrates with VLC (this is done and proven possible - see the demo). Now it adds interactivity - whatever, can be literally anything, think on screen overlays, like health bars, or way simpler stuff like jumping to timestamps. Mission accomplished, you now have interactive content.

You don't need to launch Wasabi, you don't need to play your file through Wasabi. The only thing you, as the user, do, is run Wasabi once. Interactivity is added because Wasabi detects you're playing media through VLC that supports interactivity.

What are the benefits of this approach? I think many, but the most immediately obvious is streaming content. Say you normally stream content to a second device through Plex. Ok, great. Run Wasabi once on that second device. Load your mp4 file as you normally would in Plex, and then play your media as you normally would through Plex. Wasabi detects you're using Plex and playing supported interactive content, and again automagically adds interactivity.

Now copy paste this to support every player. VLC took a day, with luck others are similar - this is definitely possible.

Does that help explain it?

As for why this can't be done using Web tech - web is sandboxed to hell and back, to hell, back, to hell again, and back again. There's no way to access lower level system stuff (such as editing a config file, using sockets, reading list of processes). Wasabi needs this.

[qDot]

So first off, interesting project! I’ve just got a couple of questions, which I’m hoping don’t come off as mean/complaints, just trying to figure out your general direction here. Always happy to see more people doing open source sex tech work, especially with an actual repository backing it. :)

I’m not quite sure how this differs from funscript playback outside of doing video overlays, and having slightly more flexibility in event output? Am I correct in that or is there more to it?

Also: why not integrate your own player? They usually come premade, and both liquid (scriptplayer dev) and I can attest that trying to support multiple video players is *hard*.

Finally: this is doable in web tech, if, once again, you build your own video player into it. You could do a canvas overlay on a video element to get your overlays fairly easily, and the other apis exist for doing config file storage and other parts you’d need. I wrote syncydink (https://GitHub.com/metafetish/syncydink) as a pure client side web app that pulls off at least some of that, including device access.

[PuzzleheadedWasabi]

Thanks for the comment and the questions! Absolutely not coming across as mean, and even if you were I wouldn't mind, really, I promise. Tell me I sound like a shitty salesman, go on. Feel very free to question and critique away.

I’m not quite sure how this differs from funscript playback outside of doing video overlays, and having slightly more flexibility in event output? Am I correct in that or is there more to it?

The goal of Wasabi is to be a general interactivity-enabler. Looking at funscript, it adds haptics, but it does not actually appear to support interactivity (user does this, random chance, do that). I'm guessing a bit here as I'm not 100% sure what funscript is, sorry. Hopefully that makes sense?

Also: why not integrate your own player?

Then it'd just be like any other player. Then it wouldn't be interesting ;)

For real though, I think there's serious benefits to this approach. From the end user's perspective, compare these options...

• You run Wasabi.exe once... that's it (!!)
• You download a player, create a folder, Windows prompts you need admin access to create a directory in program files, extract the player, delete the zip, download the script file, open the player, wait for it to open, load the script file, load the media with the player.

Let's take funscript as an example. I'm seeing these instructions for installing and using a player for funscript... and it scares me! Look at these!! You need to download and install a certain version of Java, to select VLC directories, to download and load script files. Alternatively you can encode the files yourselves?!? WHAT? Who wants to do that? I also assume that the actual experience of using the player (without having done so myself) is not as good as using VLC. And, finally, there is no way to stream the video from a NAS or other PC and still get interactivity.

This isn't me trying to bash on this program - I'm sure it works fine, and, well, it works... Wasabi does nothing right now. But I feel there's some serious room for improvement from a UX perspective. This is my stab at what I think is the solution. Perhaps for us on Milovana forums, who are a bit, uhh, interested in this stuff, we can spend those 5 minutes and wade through those hurdles. But if the goal is world domination - to get 80%+ of people who watch CH to use interactivity - I feel like this level of ease of access is important.

Yes, it's more difficult to program. But that's okay. If for the end user everything just magically works... it's so, so worth it. Again, just imagine: you run Wasabi, you get interactivity. Big bada boom. Don't tell me that doesn't make you salivate. There'd be NO barrier to entry. You'd be insane to NOT use Wasabi.

This is doable in web tech

Like you point out, it'd be something entirely different, and not in the spirit of this project.

[PuzzleheadedWasabi]

Another quick thought: the real difficulty here is interfacing with supported players (which, while difficult, still appears to be very doable). Once that is done, interfacing with other stuff (like with the very impressive list of hardware integrations on your GitHub, damn!) is just as easy, from a dev perspective, as that interfacing would be if Wasabi was a dedicated player app. Say there's an interface called PlayerInterface that's implemented by VLCInterface, PlexMediaPlayerInterface, WindowsMediaPlayerInterface... whatever. From a dev perspective, interfacing with all of these is abstracted through the parent interface, and you can call your getTime() and seekTo() on a PlayerInterface as you would if it was an integrated player application and you had a class Player with getTime and seekTo methods (or whatever).

So I think the dev hurdle here may not be as big as it seems.

[qDot]

The goal of Wasabi is to be a general interactivity-enabler. Looking at funscript, it adds haptics, but it does not actually appear to support interactivity (user does this, random chance, do that). I'm guessing a bit here as I'm not 100% sure what funscript is, sorry. Hopefully that makes sense?

Funscript was made to track motion in videos and translate it to sex hardware. Specifically, the Fleshlight Launch, but we have methods of converting those actions to other hardware. It's pretty simple.

Also: why not integrate your own player?

Then it'd just be like any other player. Then it wouldn't be interesting ;)

For real though, I think there's serious benefits to this approach. From the end user's perspective, compare these options...

• You run Wasabi.exe once... that's it (!!)
• You download a player, create a folder, Windows prompts you need admin access to create a directory in program files, extract the player, delete the zip, download the script file, open the player, wait for it to open, load the script file, load the media with the player.

First off: I'm not sure why you don't expect a player to come with an installer. That's not really an argument. ScriptPlayer has a full InnoSetup installer (I helped write it).

And if Wasabi is then bound to keep up with every movie player it supports, and if development ever stops it may just not work period with newer players...

Let's take funscript as an example. I'm seeing these instructions for installing and using a player for funscript... and it scares me! Look at these!! You need to download and install a certain version of Java, to select VLC directories, to download and load script files. Alternatively you can encode the files yourselves?!? WHAT? Who wants to do that? I also assume that the actual experience of using the player (without having done so myself) is not as good as using VLC. And, finally, there is no way to stream the video from a NAS or other PC and still get interactivity.

That's not a funscript player. Look at the date on that post. 2013. That's for the old RealTouch player.

Scriptplayer has a whole FAQ worth of instructions to make it work in many situations: https://github.com/FredTungsten/ScriptPlayer

Syncydink is literally a client-side webpage. Open it in Chrome and it just works. https://buttplug.world/syncydink

So your comparison doesn't really match up with modern capabilities.

As for who wants to encode video themselves, there's a whole community of people who very much enjoy doing that, with a surprisingly mature set of tools. http://realtouchscripts.com, or watch https://www.youtube.com/watch?v=qgdk77C5SFc for an overview of the current community situation.

This isn't me trying to bash on this program - I'm sure it works fine, and, well, it works... Wasabi does nothing right now. But I feel there's some serious room for improvement from a UX perspective. This is my stab at what I think is the solution. Perhaps for us on Milovana forums, who are a bit, uhh, interested in this stuff, we can spend those 5 minutes and wade through those hurdles. But if the goal is world domination - to get 80%+ of people who watch CH to use interactivity - I feel like this level of ease of access is important.

I agree with you on the UX front. I run a startup specifically *for* consulting on and building new platforms to research UX for sex tech. The research I've done there are where a lot of my critique is coming from now.

In my experience thus far, people using sex tech software really want a one-stop-shop. Some of the software I produce currently is similar to what you plan on having with Wasabi, except for hardware access (ours is called Intiface Desktop: https://intiface.com/desktop). It's been a nightmare to support (released 5 months ago, we probably have a ~1000 users right now), and that's a problem I'm slowly but surely remedying, but it's super difficult. Don't overestimate your potential user's expertise, unless you wanna be constant tech support to get anyone up and running.

Yes, it's more difficult to program. But that's okay. If for the end user everything just magically works... it's so, so worth it. Again, just imagine: you run Wasabi, you get interactivity. Big bada boom. Don't tell me that doesn't make you salivate. There'd be NO barrier to entry. You'd be insane to NOT use Wasabi.

Like you point out, it'd be something entirely different, and not in the spirit of this project.

I'm afraid I still don't understand your interactivity ideas with Wasabi. If you want random movies, branching, etc, you probably want control of your movie player so you can orchestrate playlists, batch/buffer video loads, and what not. I'm not sure how hooking to outside players fixes that or helps the end user.

That said, my perspective there comes from seeing movie players as a mostly solved problem via libraries. Syncydink just uses video.js which handle 99% of that for us. You could possible reuse/fork ScriptPlayer for its video player. For the web side, keeping this off the web platform would make your mobile story suck, and a lot of people use their phones for stuff like this now.

In the end, I'm not sure how this differs from something like TeaseAI, or the multiple JOI/CH sites out there already? Do you have some like, short term goals for applications built on top of this platform, just so I can get a better idea of your direction?

[PuzzleheadedWasabi]

Thank-you thank-you so much for your input, seriously, it's incredibly appreciated.

First, I have to be clear, this is a pet project, I'm not a startup, what I've made is just a POC written in <2 days because I went 'huh trying C# sounds fun'. I do not plan or expect to profit from this. I think that's important to keep in mind, as you definitely seem to be far more progressed, and (perhaps?) going into your projects with a different mindset from what I'm doing (a bit of hacking to learn something new, and for fun) (and not that there's anything wrong with either mindset).

Funscript was made to track motion in videos and translate it to sex hardware. Specifically, the Fleshlight Launch, but we have methods of converting those actions to other hardware. It's pretty simple.

In this case, I think the distinction I drew originally is correct, no? Funscript does not support interactivity. Further, the core aim of funscript is hardware integration, and that is not the key aim of Wasabi.

But, in the world where Wasabi becomes a thing, it would always be possible to copy paste Funscript into Wasabi to add support for hardware interactivity, so it's possible that one day Wasabi could be a super set of what Funscript is (again, AFAIK)

First off: I'm not sure why you don't expect a player to come with an installer. That's not really an argument. ScriptPlayer has a full InnoSetup installer (I helped write it).

Fair. But even installing something (and selecting a directory and clicking next and waiting) is a bit of (granted, tiny) effort. The goal of Wasabi is to be magical. You run Wasabi.exe once and that's it, you're done.

And if Wasabi is then bound to keep up with every movie player it supports, and if development ever stops it may just not work period with newer players...

Realistically, I think it's very unlikely that breaking changes to player APIs are made often.

(snip)... so your comparison doesn't really match up with modern capabilities.

I don't think you get my point. My comparison was just an example. I'm sure that a lot of those steps I mentioned can be condensed or removed, but with the technology you're using, it's impossible to get it down to ONE step - run a file once. In my view, anything else is too much effort. It's not as magical as Wasabi could be. It's getting people to jump through hoops, to browse to a url, to use that site and that player, to click some buttons that they otherwise wouldn't need to click.

I agree that this level of (and I'm sorry to use this world, really, but for lack of a better term) 'magic' is not required to make a good product. But your version of this product will never be the best version of this product, and that, I think, is close to indisputable. Funscript (and etc.) WOULD be better if a user could run one file, play their videos as they normally would, and have everything just work. That extra step to use a different player is not adding to the user experience.

I'm very happy to agree to disagree on the importance of this 'magic', and again, I'm sure you could make a great solution without this 'magic'. But that's not the dream behind Wasabi. And I think you have to concede, that that's a good dream.

As for who wants to encode video themselves, there's a whole community of people who very much enjoy doing that, with a surprisingly mature set of tools. http://realtouchscripts.com, or watch https://www.youtube.com/watch?v=qgdk77C5SFc for an overview of the current community situation.

I think again I have to highlight the distinction between the projects. Especially the following: you're target audience appears to be people quite heavily invested in these kind of products. They're not your average porn watchers. They're the top 1%. They're kinky men buying sex hardware, damn it. Of course this more hardcore demographic will be completely fine to spend some extra time setting up the software and getting everything to work together... especially if it's the only option ;). It's the exact reason why I'm completely fine to work around the (sorry, god awful) UX of Tease AI.

Wasabi is not targeting that demographic. It's targeting your average cock hero watcher. It's trying to usher in a new generation of simple interactive CH, targeting someone who probably doesn't post on these forums, and hopefully many more people who don't even browse this site. I think that audience exists, and is much larger. And for that audience, this 'magical' level of ease of access is IMO critical.

I myself probably couldn't be bothered using some interactive CH player unless the video really was so good I had to try it. Wasabi is meant to break down that barrier to entry to something basically non-existent. The goal of Wasabi isn't to be a 'well I suppose this is fine'. It's to be a 'wait that was too easy omigod interactivity is here wtf'.

I agree with you on the UX front. I run a startup specifically *for* consulting on and building new platforms to research UX for sex tech. The research I've done there are where a lot of my critique is coming from now.

Have you critiqued the proposed UX of Wasabi? Your point seem to suggest that the UX of other applications is fine, not that the UX of Wasabi is bad.

In my experience thus far, people using sex tech software really want a one-stop-shop.

Wasabi could be that one stop shop. The fact it runs outside of a web sandbox means that it's possible for it to do more than what a web based solution could, so there's nothing there to suggest it can't be a one stop shop - it might be even more one-stop-shoppier than web. What it has over other solution is that it's a one stop shop that also has ease of access.

Really, again, it's just a matter of using your own player vs integration into other players. That's the key here, and the importance of that (and technical difficulty of that) is what we're arguing about. That one distinction doesn't stop Wasabi from being that one stop shop.

Also, as above, the percentage of men who use sex toys is much less than those who don't. In the world where Wasabi becomes a thing, it would only make sense to first not have support for hardware. I don't think that's a feature most people want.

Some of the software I produce currently is similar to what you plan on having with Wasabi, except for hardware access (ours is called Intiface Desktop: https://intiface.com/desktop). It's been a nightmare to support (released 5 months ago, we probably have a ~1000 users right now), and that's a problem I'm slowly but surely remedying, but it's super difficult.

I'm assuming much of the challenge is hardware integration? That does sound like it could be tricky. As above, not really the (primary) goal of Wasabi (although it's possible Wasabi could support it).

Don't overestimate your potential user's expertise, unless you wanna be constant tech support to get anyone up and running.

See comments above on target audience. They are very different. Also, I'm not estimating expertise. I'm estimating laziness.

I'm afraid I still don't understand your interactivity ideas with Wasabi. If you want random movies, branching, etc, you probably want control of your movie player so you can orchestrate playlists, batch/buffer video loads, and what not.

Every interaction with a video starts with you opening that video file (through e.g. Plex or VLC or some other player), which is the one thing Wasabi needs to initiate control. The things you mentioned are possible to do after control is initated.

I'm not sure how hooking to outside players fixes that or helps the end user.

Again, it's just less effort to double click a file in explorer, to not change the way you currently open videos. I can understand if you disagree how important that is, even though I think it really is very important.

That said, my perspective there comes from seeing movie players as a mostly solved problem via libraries. Syncydink just uses video.js which handle 99% of that for us. You could possible reuse/fork ScriptPlayer for its video player.

I understand that embedding a player is easy. But again, that's not the goal of Wasabi, as I believe that's not the best solution.

For the web side, keeping this off the web platform would make your mobile story suck, and a lot of people use their phones for stuff like this now.

This is a good point. Some quick thoughts: first, web apps suck on mobile. Second, by definition Wasabi can't suck on mobile if it doesn't exist on mobile xDD. Third, and this may be contentious, and I might be very wrong on this, but I THINK (big emphasis) that mobile shouldn't be the primary focus for this kind of project. It appears to me that it'd be a bit hard to have interactive content done well on a phone with a relatively small screen and no keyboard for shortcuts. Possible, sure, but for an emerging genre, better to start on a more sensible platform. Of course, I can very well be wrong on this. If I am, and people do want to use Wasabi on mobile, that's in my view a separate problem that needs a separate solution. I don't know what that solution is. It could very well be a web app. But it would lose the magic of Wasabi, and so at least right now, mobile is just not a space I'm interested in exploring. It's boring, the solution would be boring, and there currently doesn't exist anything that uses Wasabi. IMO mobile can be very safely postponed.

In the end, I'm not sure how this differs from something like TeaseAI, or the multiple JOI/CH sites out there already?

Respectfully, I think we might possibly have a bit of a disconnect if you're suggesting that Wasabi is the same thing as TeaseAI. Perhaps that is my fault for not properly explaining what Wasabi could be.

TeaseAI is a tease and denial virtual domme with text chat. Wasabi aims to be a general interactivity enabler for videos, (think super simple jump-to-timestamp logic) possibly with support for limited game elements (think power up stuff like in Canto 1). Anything that can be achieved by drawing on top of a video frame dynamically, by controlling the video playback, is fair game. The scope should be very broad - teases, like some kind of psuedo milovana lottery tease in video format, or snakes and ladders teases, can work too. It's a general interactivity enabler for video, an interactive video format if you will, so very very broad scope for what it could be and what it can be used for. Creators could enable this interactivity through YAML config files.

Also, I have to again stress that the proposed UX of wasabi is the antithesis of TeaseAI's UX, and I believe that is very important.

As for JOI/CH site vs Wasabi, I'd need to compare a specific site, but again the boon of 'magic' integration rears its head.

Do you have some like, short term goals for applications built on top of this platform, just so I can get a better idea of your direction?

I have no goals and I have no plans. I don't personally have the desire or skill to create a CH, let alone interactive porn content. But, if a creator wants to build something that uses Wasabi, I would be very happy to work with that creator to make sure that Wasabi supports the features that creator needs to build out whatever that project may be. From there the sky's the limit.

I hope this answers your questions. Let me know if you have any further thoughts. Again, thank-you for showing interest in this and taking the time to write your post. It's really appreciated.

[figroll]

Some thoughts:

1) You should be solving problems for creators not viewers as the content is what drives the adoption of any platform. If you made a system for creating content that was substantially better than the alternatives people would use it. The natural questions that arise about an interactive player is things like "What does the scripting language look like?", "What sort of things can I do in my content?".

2) Very few, if any, people care about what video player they use to watch porn. If there was something really compelling that required, say, VLC people would install VLC. Cross platform and security concerns are orders of magnitude more significant.

Overall if the USP of your platform is "It doesn't matter what video player you use!" I think you mostly jut solved a problem people don't have and didn't provide anything compelling that is going to attract content creators.

I also agree with qDot and think you should probably just use something like video.js which a) solves the player problem for you and b) is cross platform and can be run in a sandbox. And possibly use Electron if you want something more like a desktop app. Or If you are really wedded to C# then you could use Blazor but even then you are going to (probably) be best integrating video.js into that rather than trying to write your own player API/tech.

[PuzzleheadedWasabi]

You should be solving problems for creators not viewers as the content is what drives the adoption of any platform. If you made a system for creating content that was substantially better than the alternatives people would use it. The natural questions that arise about an interactive player is things like "What does the scripting language look like?", "What sort of things can I do in my content?".

I think this is a great point. I suppose Wasabi tries to tackle both? The focus on all my blabbering above has been on fixing (what I see as) the problem for viewers, and not for creators, because I think I know what the problem is for viewers, but I don't know what the problem is for creators (as I'm not a creator). If someone wants to collaborate and use Wasabi I could build it out to make using it for creators a very easy / powerful / straightforward experience etc. Hesitant to jump in and start doing stuff for creators immediately because (a) not sure if anyone would care and (b) I might be way off the mark on what creators actually want.

I definitely do agree that content would drive adoption. Wasabi needs a 'killer app' (erm, killer video) to see any actual use. I'm just not the guy who's able to make that 'killer app'.

2) Very few, if any, people care about what video player they use to watch porn. If there was something really compelling that required, say, VLC people would install VLC. Cross platform and security concerns are orders of magnitude more significant.

Overall if the USP of your platform is "It doesn't matter what video player you use!" I think you mostly jut solved a problem people don't have and didn't provide anything compelling that is going to attract content creators.

Clearly you (along with others) disagree with my take on this. I've argued extensively on as to why I think it's important, so I don't think it's worth restating my view. Happy to agree to disagree.

Regarding attracting content creators: I don't think it'll happen, but if it does, I think it'd be because it's an opportunity for a creator to directly influence the development of a new tool, hopefully one they agree has potential, almost from the ground up. I think that would interest me if I was a creator.

I also agree with qDot and think you should probably just use something like video.js which a) solves the player problem for you and b) is cross platform and can be run in a sandbox. And possibly use Electron if you want something more like a desktop app. Or If you are really wedded to C# then you could use Blazor but even then you are going to (probably) be best integrating video.js into that rather than trying to write your own player API/tech.

Thanks for the advice on alternate solutions, and I agree they seem completely viable. But, this is something I'm really just not interested in tackling. To me this project exists because it's fun, and it's fun because it pushes technical boundaries and does something a bit different. I'm sure you'd agree that what you're describing is (from a technical perspective) a bit boring, so there's not much motivation to do it. And again, in my view, it's the worse solution, so I just don't have a reason to go that route.