According abstream owner, first 10 users to get 10k views will be paid double of their payment. Let say you get 10k views (tier 1) = $35k, you will paid $70. It will end on the day they make official launch (soon).
Although, it is almost a faithful copy of lulustream (which, in part, seems positive to me), I love that here, if the ads are configured correctly, then the videos can be played and viewed, without that hyper abuse of pop-ups , which has lulustream. Another thing I liked is that it supposedly has a higher IP count.
I have not reviewed the veracity of the counting system, its rates, much less whether they are reliable, so here I give the benefit of the doubt, for now.
What I think should be improved is:
There is a bug when trying to change the subtitle track of the video, since when trying to do so, what is changed is the audio track.
Clarify why they put "Video must be longer than 3 mins." Yes, they have differentiated rates, for videos of 1-5, 5-10, 10-30 and more than 30 minutes. They are also including the same duration in adjacent ranges, for example: 1-5, 5-10, in both of which they include 5-minute long videos.
Increase storage size.
Option disable/do not allow cloning of files, in my account.
Option to disable the anti-ad blocker and hopefully count the view, even if it is at a very reduced rate, like lulustream does.
Option to disable encoding in videos with H264 and AAC codecs.
Option choose video encoding resolution.
Increase the file loading speed a little more.
So if someone from the AbStream team sees this, it would be good for them to take these recommendations into account.
Post automatically merged:
9. Add other payment methods, such as Paypal, USDT (with BEP-20 and TRC-20), and Bitcoin (with Lightning Network).
You clicked audio icon ( and you did not close it) before clicking subtitle(cc) icon at the same time. When you do so, choose subtitle from the first list. The first list is subtitle and the second list is audio.
I see they have added USDT payments with the TRC-20 network. However (as I mentioned before), it would be great if they added support for much cheaper networks like BEP-20 (for BTC AND USDT) and hopefully Lightning Network (for BTC), since for some cryptocurrencies, the fees on their main networks are too high, and then all the work of those who climb them would be wasted. Also, if support for Paypal were also added it would be great.
10. There is a bug in some values of the API responses for the encoding and remote loading queues, the percentage of progress (reflected in the JSON key, called "progress"), always remains at "0" ( 0%) this despite the fact that the percentage of progress is actually different, according to the web interface (which is real data).
11. There is a bug on the "Deleted files" page. The files do not allow them to be marked in order to restore them, since the check box does not exist for any of them.
12. It would be nice to add features like: "Protected file code". How does this work according to "VEEV"? "Protected file codes can be used to share a temporarily link without exposing your original video. Each time a user visits the original protected link they are redirected to a secondary link that is only valid for 12 hours. If you want to avoid ever sharing your protected link you can setup a task in the background to run every few hours to update the secondary link by sending a request to https://yourhost.to/d/[file_code_protected] and capturing the redirect destination which will be valid for the next 12 hours."
13. The average remote upload bandwidth is 3 Mb/s (not the worst, but not good either), and sometimes it's terrible, like here:
At least 10 Mb/s bandwidth is ideal, for each upload. Keep in mind that many hosts have bandwidth above this value.
14. I see that the "Iframe" that contains the player is wrapped in a "Div", and inline CSS styles are also added to these HTML elements. It would be better if the code was cleaner (only the iframe).
Thank you very much for paying attention to the recommendations made in a constructive manner.
According Abstream settings, you don't need it. 360p, 480p, 720p, and 1080p(low bitrate) will not be encoded. Only 1080p(high bitrate), 2k, 4k and 8k will be encoded to 1080p.
Which means 360p will be 360p, 480p will be 480p, 720p will be 720p when uploaded to abstream.
Please note that I have made sure that the problem does not come from my side.
The remote links come from cloud servers from a well-known company, with enough bandwidth to upload at more than 60 Mb/s, as long as the download client has that capacity.
Additionally, of all the video hosting services I've tried so far, only one intermittently presented a similar problem. When they reported it, they solved it by implementing more high-bandwidth upload servers.
Remember that if you have a server that must handle multiple uploads (which from the server side would be a download) at the same time, the width will be reduced depending on the number of users adding more tasks. For example, if the servers have a bandwidth connection of only 1 Gbps, this could be insufficient and uploads will progressively slow down as the servers will have to handle many downloads at the same time.
Here's another case I tested recently, and as you can see, it's now gotten worse, no longer even hitting the 3 Mb/s I had gotten in previous tests.
According Abstream settings, you don't need it. 360p, 480p, 720p, and 1080p(low bitrate) will not be encoded. Only 1080p(high bitrate), 2k, 4k and 8k will be encoded to 1080p.
Which means 360p will be 360p, 480p will be 480p, 720p will be 720p when uploaded to abstream.
On the other hand, I would like to add to the list this other problem that I found, which I think could be solved, along with the other pending ones:
15. There seems to be a small bug, in which most of the time (approximately 90% of them), when finishing loading any video (which by the way are files with an mp4 container, at no more than 720p), The player keeps showing this error, without the possibility of playing until the user reloads the page or the user waits about 30 minutes (without reloading the page). Only then will the iframe automatically refresh and the player appear, allowing the video to play.
How to reproduce this bug?
15.1 Request the remote upload of a hopefully full-length video, using the API, in order to obtain the file_code before the video has finished processing.
15.2. Quickly replace the file_code obtained above into an ABStream iframe and visit the page containing said iframe before the video has finished loading and processing.
15.3. View the messages, which notify the progress of the video that is being processed.
15.4. In the final message you will get the status message "Internal Problem", but if we refresh the page at this moment, we realize that in reality, the video is already ready to play, only that the iframe notifies as if an error had occurred. error instead of showing the player.
15. There seems to be a small bug, in which most of the time (approximately 90% of them), when finishing loading any video (which by the way are files with an mp4 container, at no more than 720p), The player keeps showing this error, without the possibility of playing until the user reloads the page or the user waits about 30 minutes (without reloading the page). Only then will the iframe automatically refresh and the player appear, allowing the video to play.
Hello again, it seems that the peak hours have passed (at which time I apparently carried out the test) for this hosting, and then the loading speed improved a little more, however it still does not reach at least half of what other sites achieve. host with the exact same link. Keep in mind that this is not a comparison to criticize, but rather one more way to verify that the problem does not come from my side (server from which the file is downloaded).
There seems to be a small bug, in which most of the time (approximately 90% of them), when finishing loading any video (which by the way are files with an mp4 container, at no more than 720p), The player keeps showing this error, without the possibility of playing until the user reloads the page or the user waits about 30 minutes (without reloading the page). Only then will the iframe automatically refresh and the player appear, allowing the video to play.
Trying again with another video file. If it continues, contact abstream support https://abstream.to/contact or Go to your account and create support ticket (My Tickets).
As I have verified, they are links to servers in the cloud, with high bandwidth availability and zero load. On the other hand, the location of the source servers does not have much to do here, because the servers that host the file are centrally located, and also the bandwidth they have guarantees that this is practically negligible, but this does not This is what we are seeing reflected in the ones I have made.
While all the other hosts download at much higher than 16 Mb/s, Abstream maintains an average of about 4 Mb/s and with a lot of luck, for a (very brief) moment it achieved a peak of 12 Mb/s. This means that AbStream's servers are experiencing high load, which is exhausting their bandwidth. If this were not the case, the other hosting (I assume with different locations) would not achieve high speeds with the same link, at any time of the day.
This is the last one I did and it came back at a poor speed.
Well, I'll leave this bandwidth issue here, because I'm tired of spending my time doing checks for nothing.
I continue my list, I think I found more problems:
16. I have carried out a test for the visit counter, with a 2-minute video, I made several views, viewing it in its total duration, with the same IP and none were counted, while for a long-duration file, 2 were made visits from the same IP and it only counted 1 time. Here I have 2 big questions: are 5 views in a row counted, for the same IP? If a user accumulates a single view for a video, how long must they wait for a second view to be counted? What is the percentage of the video duration that must be viewed for the view to be counted?
17. Although this is not relevant to me, the real-time counter called "Users watching:" in the user panel apparently does not work, it always stays at "0".
10. There is a bug in some values of the API responses for the encoding and remote loading queues, the percentage of progress (reflected in the JSON key, called "progress"), always remains at "0" ( 0%) this despite the fact that the percentage of progress is actually different, according to the web interface (which is real data).
This means that AbStream's servers are experiencing high load, which is exhausting their bandwidth. If this were not the case, the other hosting (I assume with different locations) would not achieve high speeds with the same link, at any time of the day.
This is the last one I did and it came back at a poor speed.
Well, I'll leave this bandwidth issue here, because I'm tired of spending my time doing checks for nothing.
I am 100% certain that the problem is from the link you submitted. Check image below for proof. If you are going to post image again, post the full length of the image (showing the source url for investigation) like I did below.
Two different links with different speed. Now you know where the problem is from. Try to upload another video file from another website.
16. I have carried out a test for the visit counter, with a 2-minute video, I made several views, viewing it in its total duration, with the same IP and none were counted, while for a long-duration file, 2 were made visits from the same IP and it only counted 1 time. Here I have 2 big questions: are 5 views in a row counted, for the same IP? If a user accumulates a single view for a video, how long must they wait for a second view to be counted? What is the percentage of the video duration that must be viewed for the view to be counted?
I happend to me last month, I contacted abstream support and they said "same owner ip address" which is not counted. I will advised you to upload 5 different videos, send the 5 video links to one of your friends and tell him to watch all the 5 videos then check again.
Although this is not relevant to me, the real-time counter called "Users watching:" in the user panel apparently does not work, it always stays at "0".
There is a bug in some values of the API responses for the encoding and remote loading queues, the percentage of progress (reflected in the JSON key, called "progress"), always remains at "0" ( 0%) this despite the fact that the percentage of progress is actually different, according to the web interface (which is real data).
It would be nice to add features like: "Protected file code". How does this work according to "VEEV"? "Protected file codes can be used to share a temporarily link without exposing your original video. Each time a user visits the original protected link they are redirected to a secondary link that is only valid for 12 hours. If you want to avoid ever sharing your protected link you can setup a task in the background to run every few hours to update the secondary link by sending a request to and capturing the redirect destination which will be valid for the next 12 hours."
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.