ffmpeg does NOT understand "-maxrate 999000k"

[Heiler]

Disabling "Remux videos with tsmuxer" made some progress, the video played but slow AF (100% CPU USAGE) but still no audio

[mik_s]

Try this conf instead. I removed the truehd from supported as it was remuxing this instead of transcoding.
I also set the transcoding profile to MPEGTS-H265-AC3

LG-OLED-2016.conf

(2.87 KiB) Downloaded 134 times

Download the subrip subtitles from here then rename them to the same as the video so this should be used instead of PGS which will let UMS remux the video stream. The conf is set to stream the subtitles so you should be able to enable them on the TV.

If this does not work then you could use a program to remove the PGS subtitle stream and replace it with a subrip one. I think MKVtools does this.

I suggest when getting your videos you should avoid the BluRay rips and instead use the WEBrip ones instead which will not have these PGS subtitles as only BluRay players use them.

Another thing you can do if you are not bothered about subtitles is to just disable them and this will stop the video transcoding and just does the audio.


Your measured speed for the TV is 15Mb/s so using max value would not have worked.

Code: Select all

Renderer [LG] webOS TV OLED55B7P has an estimated network speed of 15.660118049117953 Mb/s

Your network may be capable of 780Mb/s but the network connection on the TV will be limited.
15-20 is usually good enough for most videos in h264. Not sure with h265 in 4K. If only the audio is being transcoded then this should not be a problem.
Once it starts playing you will be able to see if it stutters or buffers.

[mik_s]

I did a bit of testing with the Maximum bandwidth setting and looks like setting it to 0 for max adds an extra 0 to the end so the calculated -bufsize and -maxrate are out of range.

With it set to 0

Code: Select all

ffmpeg.exe -y -loglevel info -i "video.mkv" -filter_complex "subtitles=video.mkv:si=1" -bufsize 500000k -maxrate 499000k -crf 19 -ab 448k -c:a copy -c:v h264_nvenc -preset llhp -pix_fmt yuv420p -f mpegts \\.\pipe\...

and at 90

Code: Select all

ffmpeg.exe -y -loglevel info -i "video.mkv" -filter_complex "subtitles=video.mkv:si=1" -bufsize 45000k -maxrate 44000k -crf 19 -ab 448k -c:a copy -c:v h264_nvenc -preset llhp -pix_fmt yuv420p -f mpegts \\.\pipe\...

For my PS4 the conf is set to halve the bitrate so it is 499000k instead of 999000k.
I'll report this as it is out by a factor of 10.

[mik_s]

I was wrong, 0 means 1Gb/s not 100Mb/s so this is correct.

The actual limit for FFmpeg is "-bufsize 965000k -maxrate 964000k" any higher causes an error in the logs.
1Gb/s is just slightly larger so it fails.

These are not actually playable on my PS4 as that stops working over "-bufsize 60000k -maxrate 59000k"

That is for h264_nvenc though, if I use libx264 for CPU encoding I can get it working up to "-bufsize 2000000k -maxrate 1999000k"

[Heiler]

With "Remux videos with tsmuxer", the TV says "This file type cannot be played on this TV" and won't play it.

Without the remux, it will transcode with ffmpeg with HORRIBLE quality. The difference is brutal. And every other file I've streamed before it says it needs to transcode because the TV connection wouldn't handle the bitrate, which is not true because I've watched it all

ps.: I still don't want it to really transcode the video, but it seems this tsmuxer way is kinda broken TOO

[Heiler]

From ChatGPT:
Issues That Affect Quality:
-crf 23 + -maxrate 59000k
These two options together are clashing. CRF mode is designed for constant quality, not bitrate limiting. When you also set -maxrate, you're effectively forcing a hybrid mode that often degrades quality.

-preset llhp (low latency high performance)
That preset prioritizes speed over quality. Use this only if real-time latency is required (e.g., live streaming). Otherwise, it sacrifices quality significantly.

it suggests, for 60mbit/s wi-fi:
-c:v hevc_nvenc -rc vbr_hq -b:v 59000k -maxrate 59000k -bufsize 118000k -preset p5

[mik_s]

Did you try playing from the #--TRANSCODE--# folder and select the "The Last of Us S01E02 - Infected [FFmpeg Video] {Stream Ext. Sub:SubRip/Portuguese}" option?
This should not need the video to be transcoded as the subtitles are streamed. I can't really see how you started to play without digging in and decoding the the communications from the TV.

I think using tsmuxer ignores external subtitles so it thinks it needs to burn in the subs.

Code: Select all

Not muxing the video stream with FFmpeg because we need to burn subtitles.

Try turning off "Remux videos with tsMuxeR when possible instead of transcoding" so it is not used. I think this is an old option for when FFmpeg could not do this.

Ideally you want to avoid transcoding whenever possible as it does lower quality.
One main factor is the measured network speed in these logs for your TV is measuring 11mb/s which will result a lower quality to keep the bitrate under that.

Code: Select all

Renderer LG OLED 2016 has an estimated network speed of 11.16587559840114 Mb/s

When transcoding it does increase the bandwidth needed as it has to do this very fast so is not efficient with the size of the output.
This is the reason it is using the settings is to keep it under 11mb/s which will have to lower quality to meet that.

It could be this measurement is inaccurate, but then again the other device is measuring 50mb/s (I assume this is the 2023 LG as its conf is in the logs but might not have been identified at this point) so this just may be what that TV is capable of. There are other factors that can affect the accuracy of the speed test too if the TV was doing something else so was slow to respond or some interference if on Wifi or if the signal quality is low.

You could try turning off automatic bitrate as long as the max bitrate is set to 90. This will allow the best quality but if the speed test is accurate then the TV may struggle to play and buffer a lot. This will also stop UMS from transcoding those other videos that were previously streamed if they use a higher bitrate than the speed measured.

If you never want to transcode then it would be better to replace your videos with ones better suited for your TV. Avoid BluRay and use WEB-DL instead so it won't use PGS subtitles and probably won't use trueHD either as I think this is mainly used in home theatre setups.

[Heiler]

it's inaccurate because the oled-2016 is wi-fi, the lg-2023 is wired, but the 2016 successfully played a lot of 30-40mbit videos before.

btw I've put 90mbit there but it's not sticking. if I quit and open it again it's blank! is this because 90 is the default?

anyway this whole thing seems broken.
1. the bandwidth measurement is not accurate, there should at least have a warning there
2. 0 network bandwidth means 1gbit but 1gbit is not valid at least for hevc_nvenc
3. there is no option to select between h264 or h265 transcoding
4. there is no option to set h265 as lossless (as there are for mpeg-2 and h264)
5. "use lpcm for audio" is being ignored as it's transcoding truehd to ac3
6. "remux videos with tsmuxer" generates an invalid content to the tv
7. "-preset llhp" should not be used as this isn't a LIVE stream with 0-latency CHAT. we would have decent quality with "p5" instead

[mik_s]

The bandwidth seems fairly accurate if the 2016 TV is on Wifi as the 2023 TV was reading 50mb/s on wired so this this will be a lot faster.
The speed can be affected by various things but should be around the right range. The first speed I saw was 15mb/s and the newest one was 11mb/s.
The bitrate of a video is probably a lot less than it report as this is the max used and for scenes where there is a lot happening, most of the rest will be lower and the device can read ahead to get a good buffer for when the bitrate peaks.

The 1GB option is broken for transcoding so I have reported this to make sure there is a limit on the value used in the transcoding command.
There is no need to use this though and the default of 90 is more than enough for any video.
The max bitrate will have saved but if automatic bitrate is turned on this will be overridden. Try turning this off.

The choice between h264 and h265 is chosen in the conf file. If transcoding to 4k you need to use h265 as h264 does not have the bitrate to encode 4k.

There will be losses when transcoding especially if there is not enough bandwith for it.

LPCM is for Mencoder and not suitable for Wifi. There should be a tooltip message for this but might be missing.

Code: Select all

# Use LPCM for audio
# ------------------
# Choose whether or not the Pulse Code Modulation (PCM) audio format should be
# used instead of AC-3 with the MEncoder transcoding engine. Offers lossless
# transcoding quality but higher bitrate. Bandwidth requirements are around 1.5
# Mbit/s for 2.0 and 4.6 Mbit/s for 5.1 audio. Not suitable for Wi-Fi
# streaming.
# Default: false
audio_use_pcm =

I'm not sure about Tsmuxer as I don't know if this can handle 4k. this still requires FFmpeg to transcode the audio then it is fed into Tsmuxer along with the original video and this chain may not be able to handle 4k content. Just using FFmpeg it can copy the video stream instead of transcoding if it is supported doing the same thing as Tsmuxer.

Those setting are all correct as UMS has to transcode as fast as possible in realtime for it to be able to be played, it is effectively a livestream.
If there is any more delay then the device will timeout before it can start to play.
This happened a lot when I have to transcode videos on my spinning rust HDD to my PS4 when there are a lot of subtitles as it will not play the first time but retrying it works as it has cached the sub data.

Transcoding has its downsides to is best avoided whenever possible. 4K content takes a lot of processing power to do well and I don't know the best setup as I don't have anything that plays 4K so I can't test these myself


Like I said it is better to get your videos that are more suited for your TV so they do not need to be transcoded. The ones you have are fairly recent so should be easily found.