So I’m guessing you don’t know the differences between Direct Play and Transcode?
And do please tell me… If I have a 19 Mbps Upload pipe, and a 20 Mbps + BluRay rip, what do you think is going it happen?
Do you think it’s going to Direct Play?.. Sorry, not sure you’d be able to answer that as it appears you are not familiar with the differences between Direct Play and Transcode!
Um…
I appreciate this is now quite a large topic, and perhaps you may not have read every post, but my scenario was this…
A movie I have was as follows…
6.5 Mbps 10Bit x265 1080p Average Bitrate.
4.5 Mbps TrueHD Audio Track
640 Kbps AC3 Audio Track.
When played on Plex, it though it was 18+ Mbps. Why? Because it was “Average Bitrate” and some very fast moving scenes required far more bits. Or so Handbrake thought!
And so because Plex assumed 18+ Mbps was required to play it, it’s very near my Max upload bandwidth and would therefore likely force a transcode for remote users.
The solution? Set a MaxBitrate vaule when encoding, to try and reduce the peaks.
Did it work? Yes!
Does it still look good? Yes!
Did I originally believe 6.5 Mbps would be adequate to fit up my pipe? Yes!
Did it require some thought? Absolutely yes!
Right. As long as the buffer bucket doesn’t go empty, you can drink from it in gulps. The bigger the bucket, the more variable the input and output can be.
I fundamentally believe that to be true, and that even the worst modern devices have relatively big buffer buckets - swimming pools, really.
And I personally haven’t experienced issues because of this. I’ve been happy with CRF, because I’d rather use fewer bits most of the time, and as many bits as necessary when the scene demands it.
@axemanuk666’s experience was that the Plex analyzer noticed the high peak bitrate in a file. Plex is definitely conservative about file selection based on bandwidth estimates.
The x264 encoder can indeed be exceedingly bursty, even in ABR mode. I mostly think ABR is a waste of time for this combination of reasons.
So, I’m pretty curious to look at the variability of a few files. At this point it’s mostly about confirming my hunches for myself. I’ve got files that work for me, and so do others. 
Does anybody know what the Plex analyzer is doing - how it determines the bandwidth requirements of a file?
Lol… 
And so my goal, as much as possible, is to allow Direct Play for most of my remote users, especially those with Surround systems that support TrueHD and DTS-HD.
Because as we all know, once a transcode it initiated, the HD Audio track will be trashed!
Don’t really know exactly how it works no, but you can find the logs here…
%UserProfile%\AppData\Local\Plex Media Server\Logs \Plex Media Scanner Deep Analysis.log
Got this working, first impression is that it’s amazing. I want to work on it slightly to make sure I understand the Min/Max/Avg, to make the Bitrate and Average lines easier to read, and to make sure I understand how the “Average” line is calculated.
Found this too, haven’t tested yet.
Here, sharing a more interesting example, though it’s not an interesting movie for it. Then I’m going to make a new thread for anything else. I’ll link to it here when I do.
For the moment all I can say is that “graphs are fun” and “max is way above average” and “there are 10 minute periods that are twice the average”.
I fully well know the difference between the two. You apparently don’t understand the concept buffering. Direct Play is streaming the file as-is, without modification. The player on the other end does not play the bits at the exact moment they arrive on the players end, they buffer them, which is why you can have peaks above your 19Mbps pipe and still have no problems.
If the AVERAGE BITRATE of the file is 20Mbps and you only have 19Mbps, then it won’t direct play. If you have an AVERAGE rate of say, 15Mbps, with peaks as high as 25Mbps or 30 Mbps, this should still direct play. The only issue you might face is if those 25+Mbps peaks are of significant length, enough so to drain the buffer, then you might experience a temporary drop while the player re-buffers. But that is ONLY IF the peaks are sustained long enough to drain that buffer in the first place.
Plex probably won’t let that file Direct Play.
That is what is confusing a lot of users.
You are probably right in that Plex wouldn’t. I’m just trying to speak in terms of streaming in general, in order to try and help others understand the concept of buffering. Also the fact that even with peaks significantly higher than a persons available bandwidth, it is still possible to play the video without issue and without skimping on bits when they are needed the most.
Apart from the Netflix/YouTube private work on all of this, there’s some remarkable academic work on this topic.
https://puffer.stanford.edu/faq/
“When you say Puffer will learn better video-streaming “algorithms,” which algorithms do you mean?”
Puffer is focused on three types of algorithms: “congestion-control” algorithms that decide when to send each piece of data, also known as a packet, “throughput forecasters,” which predict how long it will take to send a certain amount of data over an Internet connection in the near future, and “adaptive-bitrate” (ABR) algorithms that decide what quality of video to send, in order to try to give the user the best picture quality that won’t lead to a stall or rebuffer. All three kinds of algorithms have a long history of work by academics and practitioners.
OK, so I appreciate that you are just trying to speak in terms of streaming in general, however we are talking in terms of Plex - specifically!
And therefore, if Plex thinks the file requires more bandwidth than you have available, or even sometimes just close to the bandwidth you have available, then of course it will FORCE a transcode for the remote user, who therefore will NOT get the HD Audio stream.
This scenario simply will not work! In your scenario, Plex will be aware of the peaks, and therefore will FORCE a transcode!
Try it for yourself… Look at the Dashboard or Tautulli to see what Bitrate is showing when you play some high Bitrate files, and you will see that there is probably NO way it will fit up your pipe, unless you are lucky enough to have a huge internet connection.
For the 10th or 11th time… I only have a 19 Mbps upload pipe!
Good god! I really don’t get why people are struggling with this!
Nice one! I could’t figure out how to use it, and in fact it looked strictly UNIX to me??
EDIT: Scratch that! I can now see the Windows instructions. Well found mate, I’m gonna take a good long look at that later
@FeMaster to your point, the stats from YouTube make it really clear. BIG chunks are downloaded and played from the buffer.
It started with a 30s buffer, downloaded to fill it, and started playing. When it got below 30s, it immediately filled it back up to 30s. Then it increased the size of the buffer and downloaded again to fill the new size. It kept doing that up to 120s.
Now it downloads a big chunk every little while and usually has 100+ seconds in the buffer.
That’s with tons of download bandwidth, and on a computer with a ton of ram.
On my TV (Roku), I see the YouTube buffer hang out at about 10s. Still a very large bucket. Of course, YouTube can switch to smaller chunks immediately if needed.
Just blew everything out. There’s a haze in the air. cough cough Got a 90 CFM blower and there’s not a spec of dust left in this thing.
Unfortunately, my prediction that I didn’t state was correct. The stock cooler can’t keep up with sustained CPU load of the higher TDP processor I put in. As transcoding on the fly only spikes the processor, I never get anywhere close to these temps on a normal basis. Feeding a reencode via HB, causes some crazy temps. I’ll need to look into an alternate cooler, or use a different system for reencoding.
I promised to take make another thread for bitrate predictability discussions. Instead, I found this.
https://forums.plex.tv/t/how-to-pre-encode-to-avoid-transcoding-using-vidcoder-presets/
@PlexyChip touches on almost all of the points here, and has excellent references and links to other relevant discussions. He’s done more homework than I was planning to do. I added some screenshots there.
I see your comments, but those numbers don’t immediately seem TOO HIGH For a modern CPU when it’s 100% busy.
Why do you think that’s too high?
Here, it’s a different CPU, but he’s cavalier about similar temps.
