So yesterday I did another test with a 2160p@25Mb/s file and could narrow the limit down to 1080p@7.5Mb/s. Today I tried to investigate why the limit was so low by increasing the log verbosity on my server and on my client and also adding -loglevel verbose to the Transcoder but I (unfortunately) can no longer trigger it. I must’ve hit some kind of bug which triggers for bitrates over 7.5Mb/s (regardless of resolution) with the results being semi-consistent (every bitrate above would eventually get stuck but the timings were sometimes different), I remember it being mostly linear e.g. crashing after 21 minutes at 9Mb/s and 23 minutes at 8Mb/s but then e.g. 7.9Mb/s would crash after seconds and 7.8Mb/s would crash after an hour (those aren’t actual numbers). Anyway hitting the bug and hitting my GPU limit would initially look the same (spinning circle, client overlay would say something like "buffering: 10% and the dashboard would say buffering) but in the bug scenario the stream would never recover.
Now that the bug is no longer happening I watched a movie at 2160p@70Mb/s without any buffering but I’ll continue watching movies that way (fixing the bitrate even when it’s larger than the source) until I encounter another buffering or am confident in that number.
So my key takeaways from this beta so far are:
- Burning-in will make 4K transcoding impossible for me (regardless of codec)
- There’s a bug which makes transcoding fail when the target bitrate is bigger than 7.5Mb/s (at any resolution) but the problem might be unique to me (your
ffmpegfork seems to be 2 years old and a rebase could help) - My (4K) limit seems to be high enough to not be hit under regular circumstances but I’d still appreciate a server-side limit
