GoFuckYourself.com - Adult Webmaster Forum

GoFuckYourself.com - Adult Webmaster Forum (https://gfy.com/index.php)
-   Business Discussion (https://gfy.com/forumdisplay.php?f=48)
-   -   Live Video Banner & Hosting (https://gfy.com/showthread.php?t=1385989)

jim101 09-05-2025 03:33 PM

Live Video Banner & Hosting
 
Most of the main cam sites have the affiliate feature to embed a live video banner. ie a live video model feed. Clicking on this takes the user to the model room - a good feature for sure.

What kind of hosting for the affiliate website is typically needed to ensure the live video banner stream appears on the affiliate website reasonably quickly? Are there any other techniques needed to optimize the speed or particular known problems/conflicts causing unnecessary delay on this type of feature?

Just taking LJ as an example, on a trial I notice their video banner (prerecorded not live) appears within a second or two and is linked to the main "headshot page" ie works fine. On the other hand, the live video banner typically takes 25-40 seconds to appear on the same webpage, like waiting for water to boil. Is it down to hosting/server power and if so what typically works well?

cerulean 09-06-2025 11:00 AM

Without knowing the specific coding environment at play here, I don't think this is a server issue. I think we're just talking about different implementations of technology.

A pre-recorded video, or a split HLS stream, with the proper moov atom will tell the browser to download the chunk necessary to start the video now. Nothing is being processed on the server side, so we're down to just how fast the connection is between user and server. The browser does all the heavy lifting interpreting the video, showing it, and asking for the next chunk.

Depending on a livestream, you might need to connect to a socket and perform a handshake before the video loads. There could be checks that need to be performed based on session data. All of that takes more time, because you could be interacting with more than just the server. They might need to check a database, or poll for live status, etc. 25-40 seconds seems like an excessive amount of time, so there might be a server issue in conjunction with this, but ultimately the difference stems from the differences in technology.

I think if you hosted with either of the top two adult hosts, you would be fine hardware wise. Both Vacares and MojoHost are perfectly capable of serving assets quickly.

I built a library that I now sell as a SaaS for a client that integrated Streamate/Cambuilder, NATS, and payment processors. For the cam part of this equation, I used their API to grab a list of live performers. The only assets that were served were static images, but the round-trip time to the API took longer than simply loading a predefined asset. Speaking of, I also needed to connect to the APIs of NATS and the payment processor, and those took time too. You might be seeing something similar here. Nevertheless, it was way faster than 25 seconds (we're talking differences between milliseconds here).

Ultimately I think the answer to your question depends on the tech stack, and whether it has been optimized. If there is no limitation on their end, then a properly configured and optimized server and coding stack on your end should not present any noticeable delay.

jim101 09-07-2025 04:43 PM

Quote:

Originally Posted by cerulean (Post 23396610)
Without knowing the specific coding environment at play here, I don't think this is a server issue. I think we're just talking about different implementations of technology.

A pre-recorded video, or a split HLS stream, with the proper moov atom will tell the browser to download the chunk necessary to start the video now. Nothing is being processed on the server side, so we're down to just how fast the connection is between user and server. The browser does all the heavy lifting interpreting the video, showing it, and asking for the next chunk.

Depending on a livestream, you might need to connect to a socket and perform a handshake before the video loads. There could be checks that need to be performed based on session data. All of that takes more time, because you could be interacting with more than just the server. They might need to check a database, or poll for live status, etc. 25-40 seconds seems like an excessive amount of time, so there might be a server issue in conjunction with this, but ultimately the difference stems from the differences in technology.

I think if you hosted with either of the top two adult hosts, you would be fine hardware wise. Both Vacares and MojoHost are perfectly capable of serving assets quickly.

I built a library that I now sell as a SaaS for a client that integrated Streamate/Cambuilder, NATS, and payment processors. For the cam part of this equation, I used their API to grab a list of live performers. The only assets that were served were static images, but the round-trip time to the API took longer than simply loading a predefined asset. Speaking of, I also needed to connect to the APIs of NATS and the payment processor, and those took time too. You might be seeing something similar here. Nevertheless, it was way faster than 25 seconds (we're talking differences between milliseconds here).

Ultimately I think the answer to your question depends on the tech stack, and whether it has been optimized. If there is no limitation on their end, then a properly configured and optimized server and coding stack on your end should not present any noticeable delay.

Thanks for the info on this. If I've understand you correctly, as far as the user browser is concerned it makes no difference whether the video stream is live or pre-recorded, the stream is just treated as chunks of data to be converted to video in the user browser. For the livestream there is extra communication/logic to perform on the server, but nothing that should normally take approx 25 seconds.

At the moment I am just experimenting with landing pages using Wordpress on a shared hosting service. Without traffic to the landing page the response of the LJ recorded video banner and live video banner are actually very similar, the live video just slightly slowly to start. When traffic is introduced to the landing page domain the pre-recorded video still starts quickly but the live video is significantly delayed.

I will take a look at the hosts you mentioned. I expect to use a VPS with any amount of traffic.

cerulean 09-07-2025 07:58 PM

Quote:

Originally Posted by jim101 (Post 23396806)
Thanks for the info on this. If I've understand you correctly, as far as the user browser is concerned it makes no difference whether the video stream is live or pre-recorded, the stream is just treated as chunks of data to be converted to video in the user browser. For the livestream there is extra communication/logic to perform on the server, but nothing that should normally take approx 25 seconds.

At the moment I am just experimenting with landing pages using Wordpress on a shared hosting service. Without traffic to the landing page the response of the LJ recorded video banner and live video banner are actually very similar, the live video just slightly slowly to start. When traffic is introduced to the landing page domain the pre-recorded video still starts quickly but the live video is significantly delayed.

I will take a look at the hosts you mentioned. I expect to use a VPS with any amount of traffic.

I think if the live video is taking that long to load, then I would start by opening up the network graph in the browser's web inspector and see exactly where the delay is. Even though the browser can't do anything about it, you should be able to see if it's a TTFB issue, or something else. If it's a TTFB issue, then it's definitely the server crunching and trying some kind of behind-the-scenes logic which is slowing things down. You have to figure out which server is taking so long. If it's something you can control, then you can put breakpoints in the code and monitor that.

If it's a delay with a remote server, then you might need to talk to their tech team to figure it out. You can see the handshake in the browser in real time, and it should be clear what's happening when (from the browser's perspective). After that, you need to do some performance testing on the actual software.

If you're primarily using WordPress, I'll DM you some info that might be useful.

jim101 09-08-2025 05:22 PM

Quote:

Originally Posted by cerulean (Post 23396830)
I think if the live video is taking that long to load, then I would start by opening up the network graph in the browser's web inspector and see exactly where the delay is. Even though the browser can't do anything about it, you should be able to see if it's a TTFB issue, or something else. If it's a TTFB issue, then it's definitely the server crunching and trying some kind of behind-the-scenes logic which is slowing things down. You have to figure out which server is taking so long. If it's something you can control, then you can put breakpoints in the code and monitor that.

If it's a delay with a remote server, then you might need to talk to their tech team to figure it out. You can see the handshake in the browser in real time, and it should be clear what's happening when (from the browser's perspective). After that, you need to do some performance testing on the actual software.

If you're primarily using WordPress, I'll DM you some info that might be useful.

Thank you again for the info above. I hadn't paid too much attention to the network tab in chrome dev tools but it looks like a useful aid. I have used pingplotter to see the network route sometimes. Perhaps pingdom might be a useful tool to monitor also.

I started to take a look at the stated specs for a few VPS providers (Vice Temple, M3Server, MojoHost, Vacares and a non-adult for comparison Namecheap). Some interesting overlaps and differences.


All times are GMT -7. The time now is 02:07 PM.

Powered by vBulletin® Version 3.8.8
Copyright ©2000 - 2025, vBulletin Solutions, Inc.
©2000-, AI Media Network Inc123