Any way to increase the buffer for playing videos? (very long distance between server and television)

[Kennyw888 5]

Looked through the posts in the forum, but not really answering my question other than it doesn't seem to be a topic that has been specifically covered and while others have requested such a feature, perhaps it's not possible on the limited amount of RAM a consumer television would have or what that TV would allow Emby to reserve.  My  situation is as follows:  New Zealand home w/emby server on ubuntu w/zfs local U.2 media  ---> tailscale (pfsense) ---> 1gbps internet ---> Japan with 300mbps internet ---> minipc w/tailscale playing through a browser to home TV via HDMI output. 

Problem #1 is that the latency is ~250ms to ~350ms between NZ & Japan with some spikes likely due to "reasons."  I occasionally see pauses that generally last less than 3 seconds that I feel could be smoothed out if there were a way to increase the amount of the stream buffering.  In general, speedtesting from Japan to openspeedtest server running on Ubuntu is  ~45mbps down, ~125mbps up but I'm not done any extensive testing at different times.  Issue happens on 1080p media which is all less than 3mbps as I transcoded all 1080p this way. 

I realize that this is very niche and there aren't many who are doing things this way, but an increase in buffer size could also solve the niche issues of others when a PC is involved on the receiving side.

Thanks

Edited March 16, 2025 by Kennyw888
More accurate speedtest

[visproduction 315]

Overall, encoding hardware / software that runs live is limited in quality by the processing speed.  Non-live encoding that may often take 4 to 10 times longer to encode, can use more detailed levels and higher quality to produce your end video media.  I think a lot of these extra settings to improve quality and make a built in buffering in the file (Video Buffer Verifier) is probably not available with real time encoding.  I don't use hardware or any real time transcoding, so other people in the forum will know those details.  I didn't even realize there was a Video Buffer Verifier until just now, looking everything up.  I have no idea how good it is, or if it will help.  So a lot of this info here is aimed at off-line higher quality settings for transcoding.  I don't have the exact ffmpeg commands needed, but AVIDemux is what I like to 3rd party encode, because it doesn't automatically force settings like Handbreak.
 

Things that should help smoother video streaming online.

Don't use VBR and use CBR instead for video streaming.

Maximum Consecutive B-Frames 3 or 6 for 1080P

GOP size Min 16, Max 120

B-frames as References - Non-strict (Not Blu-ray compatable)

I frame Threshold 40  (some suggest 48)

Limited GOP size and making the I Frame Threshold < 48 keeps the video streaming packets to not have I frames beyond 2 seconds which can help stop stuttering on transfer rate challenged networks.  If a packet is missed, so it starts the out of order sequence, then video streaming would have to wait until the lost packet is resent and would probably drop the follow up packets, because they don't have an I frame for video processing, which means the video player would stop to wait for the I Frame before playing further.  If an I Frame is in every TCP/IP packet or at most the next packet, then this stuttering can be better.

Partition Search:
8X8 DCT Spatial Transform
4x4, 4x8 and 8x4 P-frame Intra-predicted Blocks
8x8 Instra predicted Blocks
4x4 Intra predicted Blocks.

Partition search at this level takes longer, but the end result is nicer and I think that might help streaming just because there are less artifacts. 

There are Akamai white papers that cover this as well as many online sources.  I can't find the link to this White Paper.  I will quote part of it below.   It's the best one I've seen that goes over some of these encoding options.  Sorry, but I don't know the exact ffmpeg settings to make some of the changes above.  These options are inside the x264 Configuration settings in AVIDemux, a 3rd party encoder.

Fabio Sonnati in Italy really likes to break down encoding options:  https://sonnati.wordpress.com/best-of-blog/

He has a lot of ffmpeg advanced tweak examples.

Other Akamai related info on video streaming delivery: https://www.akamai.com/resources/white-paper?ind=i6&sol=s1

Akamai Media Services on Demand Encoder Best Practices msod-encoder-best-practices.pdf  March 2022
I have not experimented with the Video Buffer Verifier settings.  They can be adjusted. AVIDemux encoder has an Advanced 1 tab that allows Max VBV Bitrate, VBV Buffer Size, Initial VBV Buffer occupancy and three Slicing settings. This may help with your buffering question.  I have quoted info below from the white paper.

 

Quote

Reference frames
A reference frame can be used by a P-frame, also known as a predictive or partial frame, to help define a future frame in a compressed video. While H.264 can support any number of reference frames, we recommend using between three and five (three to five reference frames can be used by a P-frame) for optimal performance across devices.H.264 levels limit the decoded picture buffer. For example, if level 4.1 is being used, then the maximum reference frames allowed for 720p and 1080p videos are nine and four, respectively.

...

Rate Control
... it is recommended to use CBR as it maintains a steady stream of data regardless of the complexity of the video in any given frame.
VBR might cause playback problems if the data rate suddenly jumps to a rate with which the client can not keep up.
 

Encoder buffer model

When using the x264 system output, bitrate can be controlled using VBV (Video Buffer Verifier). VBV is a theoretical MPEG video buffer model used to ensure that an encoded video stream can be correctly buffered and played back at the decoder device. By definition, the VBV should not overflow or underflow when its input is a compliant stream. When encoding such a stream, it is important that it complies with the VBV requirements. There are two parameters that need to be set for VBV controls — VBV buffer size and VBV maximum bitrate. Consider a small time period T over that desired to restrict the data throughput. We recommend a VBV buffer size of 1-5x video bitrate, and all renditions use the same VBV buffer size multiplier:• VBV buffer duration = VBV buffer size / VBV maximum bitrate• VBV data throughput = (T + VBV buffer duration) * VBV maximum bitrateIt is important to keep VBV data throughput well below the video maximum bitrate specification of the highest H.264 profile the device can support and the average net- work bandwidth available for video of end user.
 

Audio encoding

To ensure renditions in the multiple-bitrate set can be played back appropriately, you must encode each rendition’s audio track using the same sample rate and bitrate. Using the same sample rate avoids issues such as audio/video sync, as most devices rely on the audio track’s time clock to control playback. Using the same bitrate avoids issues such as audible “pops” when the device changes from one rendition to another.The audio codec used with H.264 is generally AAC.

Finally there are browser settings for Firefox that increase buffering.  I have not yet found any recent post for Chrome, Safari or Edge.  As far as TV apps, there are probably no settings to adjust.
 https://superuser.com/questions/1702978/bring-back-buffering-for-html5-video

In Firefox:

• Enter about:config in the URL bar and accept the warning.
• Type media.cache in the configuration Search edit to list a few settings.
• Increase media.cache_readhead_limit from the default 60, up to 9999.
• Increase media.cache_resume_treshold from the default 30, up to 9999.

===

Very old post about Chrome video buffering: 

 https://beebom.com/how-force-youtube-fully-buffer-video-chrome-firefox/

===
Yes, pretty complex at times.  There is no "Make it better" button, even though everyone thinks that there should be an easy fix.  Ha!

Edited March 16, 2025 by visproduction

[Kennyw888 5]

Thanks Mr. Vis production,

Lots of good information in there for those that are either streaming larger files, transcoding on the fly or transcoding their collections for Emby/Plex.  In my case, my 1080 streams are all direct play and it took me lots and lots of testing to find the perfect (general) settings in ffmpeg that maintain good quality (for me) of my collection while maintaining a small size mostly in h.265.  None of my 1080p material needs to pass thru the GPU in the server before being sent out.  I'll caveat that with the oddball device deciding it cannot play it as is, but generally not.  I use vbr by default and I'm not sure how to make Emby transcode to cbr on the fly but that may be worth a try.

That said, I will install Firefox and give those settings a try.  I'm not hopeful that it will affect Emby, but maybe I'm wrong.