Roku Developer Program

[tifroz]

I found out that when the video player ("roVideoPlayer" in my code) starts streaming an mp4 file, it doesn't just generate one, but a dozen requests (each with a different byte range, e.g. bytes=1131256-, bytes=1717552-, bytes=3060889-, etc ..) I imagine that the video player is trying to generate snapshots at different intervals(?)

However in my case, this is something I need to avoid as the servers aren't under my direct control, and some of them will throw HTTP 429 codes (Too many requests)

Is there a way to disable this behavior, and get the player to only send the requests needed to stream the video?

[joetesta]

Yes this is the behavior of the player buffering chunks. I ran into this when trying to count the number of views by counting http requests. Unfortunately I think your only option would be to find hosting that will tolerate this behavior.

[tifroz]

Thanks this is helpful!...though not what I wanted to hear obviously 😉

[RokuMarkn]

MP4 is not a streaming format, and it's rather difficult (and wasteful) to read the whole file sequentially in order to play it. In any case, counting the number of http requests is not a good way to count views, since there will be unavoidable repeat requests -- for example if the users pauses for a while, the connection will probably time out and a new connection will need to be made when playback resumes.

--Mark

[tifroz]

Thanks for chiming in Mark

I am not a video expert, so I won't argue the right or wrong of the behavior on an academic basis. But on a practical basis, hopefully we could agree on these 2 points

1. mp4 is a commonly used to stream videos - we as developers can't simply dismiss this reality
2. sending a dozen simultaneous requests to a server isn't particularly friendly to the server - and it's not unreasonable for the server to protest when this happens

It would be helpful if that behavior would either be configurable, or if the behavior was closer to that of html5 video players in common browser since most video streaming servers are configured & tested against these browsers.

[RokuMarkn]

The requests are not sent simultaneously; they are sequential. I don't see what's unfriendly about making multiple requests; in fact, it seems quite the opposite. The choice is between making several requests to download the necessary data which is scattered around the file, or reading the data sequentially and discarding the data that is not needed. Generally server costs are related to bandwidth, not to the number of http requests, so if I were running a server, I'd prefer that the client request only the data it needs rather than downloaded unnecessary data only to discard it. I'm sure that most Roku customers would also prefer that the player download the minimum data necessary, since home internet costs are also based on total bandwidth, not on a count of http requests. If this feature were configurable, your channel's users would probably not be happy to learn that you're using more of their bandwidth than necessary because of some server peculiarity.

--Mark

[tifroz]

Thanks for taking the time to explain Mark, this does make sense. I was under the impression that these requests are made in parallel because there is a large number of requests send very quickly when an mp4 starts streaming - but it could very well be sequential (just a really fast sequence).

Still makes sense to behave more like mainstream browsers for compatibility purposes IMHO - but I won't beat this very dead horse again...