Is this still true? From looking at the files created when transcoding, it seems like this should really say ‘equal to the size of the source file once transcoded’?
For example, if I have an 70 GB 4k movie with a video bitrate of 80 Mbps and am transcoding it to 40 Mbps, it seems like the transcoded file would be 35 GB (oversimplification, audio and subtitles probably wouldn’t compress the same).
I ask because my original Plex server uses a 32 GB RAMdisk for the transcode directory. When I built it I did not have 4k content but added some over time, and have not had any issues transcoding 80 GB 4k movies down to 20 Mbps.
I just built a new virtual Plex server for home use, and followed the above rule, giving it an 80 GB RAMdisk. I then moved the old server with the 32 GB RAMdisk to another location that has way more upload bandwidth, and am using that for any remote usage when on the road.
Since the remote site has almost 1 Gb up I increased the max remote stream bandwidth to 40 Mbps and in my testing I have not seen any issues watching 4K movies at that bitrate, so I am just wondering how the transcode directory size limitations actually work, and if that documentation is still right?
I would think it’s still true. If the transcode was just a re-mux for direct stream, then you would need to have basically the same amount of space available. Even more if you had two or more transcode sessions happening at the same time.
I’m almost sure it does. The files are converted to a different container format, and would need to be stored someplace. I’m sure someone with a little more knowledge of the matter will replay if I’m wrong.
Direct Stream = yes (because it still is going through the transcoder and is chopped into chunks, even if it’s only remuxed into a different container)
Direct Play = no (because the whole file is transferred as-is – including the original container)
Ok this is making a bit more sense. I only direct play at home, haven’t direct streamed anything remote because I always put a cap in place (previously due to upload limits at home, and now because I am streaming a lot of live TV from Channel DVR on the same remote server and want Plex to still have SOME limits).
So if - ruling out multiple streams at once and source files with low bitrate sand file sizes that fall under my enforced bandwidth limits:
I never direct stream 4k due to limits I have in place
I am always streaming at a lower bitrate than the source file
Will the temp transcode files in the transcode directory ever actually be the size of the original file, or will they be the size of the file once transcoded (and in either case only after the whole movie is transcoded)?
Nobody can tell with absolute certainty. There are simply too many variables at play.
Just generally: Putting the transcoder temp folder in RAM disc is usually a bad idea. If you are concerned with SSD wear, assign a folder on a traditional HD (“spinning rust”) to be the transcoder temp.
Doing so will free you from any concerns about available space and
will also enable you to jump back and forth even in very long movies, without the need to re-transcode.
The freed up RAM is better put to use as drive cache.
Well it’s been working fine so I’ll just leave it as is. Was just curious why what I was seeing looking at the file sizes when transcoding was contrary to the documentation.
Still have 32GB left for ZFS caching on both servers.
I’ve been using RAM (/dev/shm)as the transcode directory with no problems. My old server was an i3-7100 with 8 GB RAM, and it had something like 4-5 GB free RAM while Plex was running. If I had it transcode a 4k HDR file to 1080p SDR, this took up about 700-800 MB of space in the RAM drive. I ran out of QuickSync horsepower before I ran out of space in the RAM drive.
My current server is an i5-10400 with 16 GB RAM. It also has no problem transcoding files which are much, much too large to fit into the RAM drive.
If I have a transcoder meltdown I will be sure to switch it back to the default path on the SSD, but… So far, so good. I see no reason not to experiment with it.
