Still nothing ? I can’t watch 4k content on my LG OLED TV because I get buffering stops for a couple of seconds every 2 minutes. I guess that the movie has bitrates peaks that sometimes exceeds my interet downlink speed but the average bitrage is way below.
Having a few tens of seconds of buffer would definitely help.
@anon18523487, after reading some of this thread, it’s becoming clearer why my friend is having problems with LG TV, only when my server is transcoding.
They have a relatively poor connection (15Mbps down ADSL). So when Plex is direct playing, they have no problems, but it becomes completely unwatchable when it’s transcoding. They see changing frames. I’m guessing it’s because there’s no buffer on LG TV app when server is transcoding and the latency is too high (130ms) to sustain video playback. This is ridiculously bad decision by Plex not to implement buffering when streaming transcoded content. It’s a paradox. You’re transcoding so you can watch the video on slower connection, but in reality it’s possible that you’ll run into more problems because there’s no buffer! I can’t believe they haven’t fixed this/found a different way to approach it.
It is not that Plex chose not to implement a buffer. That is the way streaming works for transcoded media. It uses a protocol called HLS, which is a live streaming technology. So basically the client requests the data from the server just when it needs it. It’s not Plex didn’t implement a buffer, there is no buffer that can be used. Ok, there is a small buffer but only to start caching the next piece while the current one is playing. There is no mechanism to cache way ahead of what is playing. When direct playing, it does not use HLS, so the client requests the entire file and can build up a buffer.
Thanks for replying. Isn’t there any other protocol that can be used? It seems that you haven’t replied to these points:
@anthonws wrote on this thread (bolding mine):
My answer was clearly a rant, in case you didn’t noticed. My apologies, next time I will add a /i or /r.
@“MovieFan.Plex” , actually from what I researched it’s possible to have custom buffering for both HLS and DASH, although that takes the purpose of actually using an adaptive bitstream protocol. Right?
@KarlDag , ultimately, what you want can be achieved by download or sync. If you want to do a full read ahead buffer of the entire clip, then you would have to choose a fixed bitrate, have the free space to hold that data, etc. Furthermore, with so many different player engines, I’m sure this wouldn’t be something easy to achieve. Unless all of it would be under ffmpeg responsibility.
At least it seems that ExoPlayer can do it: How can I increase the buffersize ? The amount of stream that is fetched ahead of the current location ? · Issue #1010 · google/ExoPlayer · GitHub.
Hth,
anthonws.
And @plex-linux wrote:
@anon18523487: read your reason why youtube type buffering is currently not possible on anything but direct play. However is seems that all you would need to do is to store the last 10 or so segments as a buffer and then HLS streaming would work. This link below appear to me to be very similar even though it is only for music , (I am certainly not an expert on this however )
hls-buffer - Preload and buffer http live streams (aka do not lag on crappy networks)
I’m not an expert in this area so I don’t know. HLS and DASH are the 2 most popular. Also keep in mind that the player must also support the protocol, so we can’t just pick anything.
AFAIK, that buffer only allows for holding larger segments, not more. This could potentially help if there are also latency issues, but not for slow connection speeds.
That option is possible, but you then you’d have to wait for the entire file to be re-encoded before you could start playing.
There really aren’t many options if you have a bad/slow connection. Plex’s approach is the feature to automatically adjust the bitrate of the output to match the connection speed.
Unbelievable that no action has been taken in this space.
Plex’s key core functionality is streaming video content over IP - and it doesn’t do it well because it doesn’t implement a modern streaming protocol with buffer capability
Which is still unavailable on most clients, and on the ones it is available, is completely broken.
Ie. on Android - if a stream changes from 8mbps or above, to 4mbps or below, sound cuts out.
Not only that, but the speed it detects is wonky as all hell. I have a 100mbps ethernet connection and can stream 50+ mbps 4K HEVC content with no buffering; however when I turn on Auto Adjust, Plex thinks I can only stream 8mbps or so, sometimes dropping down to 4mbps. Crazy.
We use HLS streaming which is a modern protocol. But this really isn’t becasue of the protocol. It’s because you are streaming media that is being transcoded in real time. There isn’t a method to buffer this.
This is not something I’ve heard. if you can start a new thread and provide logs, I’d be happy to take a look. This is definitely not expected.
Again, provide me a log of this situation and I’ll take a look.
How do services like Sling TV, ESPN, FUBO etc auto adjust live content?
If I get time I’ll do it. Recreating issues and capturing logs takes time and I don’t work for Plex.
How do you buffer ahead live content? I’m confused. If you are referring to lowering the quality, yeah Plex does that too as you’ve mentioned. That’s still not buffering.
Sorry I was referring to those services being able to adjust quality on the fly - and mostly without issues - was off topic sorry.
I guess the question is, why is Plex streaming files sitting on a server, as live content? If you have auto-adjust on, I can understand you need to transcode each chunk at different bitrates as the stream continues, so that is live in a sense.
But if you have auto-adjust off, Plex knows what bitrate the entire file needs to be when the user presses play? Why does Plex only transcode 60 seconds ahead of the stream? Why not transcode the entire file once the user presses play and then place the entire file into buffer?
Something like this:
1, User presses play at 720p 4mbps
2. Plex now knows that the entire file needs to be transcoded to 720p 4mbps
3. Plex transcodes the entire file to 720p 4mbps, but breaks it into chunks so the stream can start before the entire file has transcoded.
4. Plex starts streaming the 1st chunk at 720p 4mpbs, whilst Plex continues to transcode the rest of the entire file into chunks
5. As each chunk is completed, it places it into buffer. Until the whole file is transcoded and buffered
6. Plex continues to play through all the transcoded and buffered files until playback completes.
I’m no expert, so no doubt i’m missing something - but the above seems like a much better method than only ever transcoding 60 seconds in advance - creating potential streaming weakpoints every 60 seconds?
What you describe is more or less what Plex does. Plex chooses not to transcode the entire file ahead of time so that it doesn’t waste time/energy in case you don’t need the entire file. Say you start watching a file that would be 5 GB in size if you add up all the chunks, but you stop watching after 10 minutes. By only trnscoding slightly ahead of time, there isn’t too much waste. You can change how far ahead the transcoder works. Settings \ Transcoder \ Transcoder default throttle buffer
However, that only impacts the server side. In order for the client to playback the chunks, these need to be stored in the player memory (aka the player stack). The amount of memory reserved for this is set by the app and is limited, typically in the MB range, so it can only hold a few chunks at a time. It physically cannot hold more data to be able to buffer ahead of time. That’s the way the protocol works. The protocol was designed for live playback, which doesn’t expect data ahead of time so it’s not possible to create a giant memory stack. Transcoding media on-the-fly is not a common thing to do and there isn’t a protocol I’m aware of designed for this. Plex uses HLS since it’s the best fit.
Why use a protocol designed for live playback if the entire file exists on the server?
Transcode the entire file (when play is pressed) on the server to the required bitrate - then stream via a protocol that allows for the client to buffer more of the file so it doesn’t have to download so many small chunks of data, creating multiple break points for the stream.
For example, I’m currently testing a server that streams over Cloudflare. Single thread download speeds from it to the client are more than sufficient (80mbps), but Plex keeps buffering. The only issue is high pings (no CPU load, disk io is low, plenty spare ram), But if the server and client were able to transcode/buffer more of the file in advance, high ping wouldn’t be such an issue.
You would have to wait for the entire file to finish re-encoding before it could start playback. Depending on your computer, this could take a long time. Some computers are barely able to keep up in real time so to watch a 2 hour movie, you’s have to wait 2 hours before the file was ready. Even if you have a fast computer that can convert the file at 10x the speed. You’d still be waiting 12 minutes before playback starts. Imagine seeing a message.
“Plex is converting your file, please wait 12 minutes for playback to begin.”
I meant still break it into chunks, but allow the chunks to be feed into the stream in advance - rather than waiting for Plex to request it when it needs it:
Something like this:
User presses play
Plex transcodes the first chunk and sends it to the client
Plex transcodes the second chunk even if the client hasn’t requested it yet - send it to the client as buffer
Plex transcodes the third chunk even if the client hasn’t request it yet, send it to the client as buffer
etc. etc. etc.
Soon enough, the entire file is transcoded and in the client buffer - despite the user only being a % way through the file.
This is the part that is the problem. There is no buffer. When using HLS, it can’t save these chunks ahead of time, that’s not the way the protocol works. There is not transmission protocol designed to handle this situation. Plex would need to write our own protocol to do what you describe. And that would only work on clients where Plex could implement this new protocol, which would be impossible on things like Smart TV’s where it’s controlled by the firmware.
To be clear, I understand what you want and it would be great if it was possible, but there are technical limitations outside of Plex’s control that just don’t allow this.
Thanks and I appreciate you taking the time to respond.
Whats the theoretical maximum buffer size for HLS? I can’t seem to find it, as it seems you can define it with:
config.maxMaxBufferLength
config.maxBufferSize
config.maxBufferLength
It can be set, but again, it’s only designed to hold 1 or 2 chunks at a time. Even if you defined it to be 1TB in size, it won’t use it.
+1 would really like this feature!
