Hi,
is this something that could be fixed with this preview?
Dolby TrueHD is not transcoded for LG TVs, even though most (if not all?) don’t support TrueHD passthrough from internal apps like Plex.
I don’t know if the server or the client decides, if it’s necessary to transcode?
@Red-Naxela I replied in your original thread
I cannot get Live TV to work at all, all clients just report “Playback error”.
I am in the UK.
I use tvheadend to drive my tuner, and use antennas docker to simulate a HDHomeRun that Plex then connects to.
Reverting back to the official build and Live TV works again.
Logs attached.
@e10kstarfire I cannot reproduce this via any of my live tv channels. I sent you a PM asking you to capture a sample which I can hopefully use to reproduce.
Thanks I replied via PM
I was going to give you feedback but I noticed that I can no longer log into my (forums) account. It just says
No login methods
No login methods are configured.
Administrators can visit /u/admin-login to reconfigure the site.
and afterwards
The change you wanted was rejected.
Maybe you tried to change something you didn’t have access to.
I googled the error message and the only other mention of this issue says that it happend to them after changing their email address. I think that that’s also happening here? I’ve changed my email many months ago but maybe I didn’t log into my account for that long. If a mod wants to help me with this please PM me and I’ll tell you my info.
With that out of the way I got the new Transcoder and haven’t found any functional regressions. I did some performance tests though and the old Transcoder is considerably faster:
| Scale | Scale + Burn-in | |
|---|---|---|
| 1.42.1.10060 | 4.04x | 3.64x |
| Preview | 2.66x | 2.23x |
Meaning with this new Transcoder I can only serve up to 2 clients at once whereas in the past I could do 3-4.
Interestingly enough these are h264_vaapi numbers but hevc_vaapi hasn’t resulted in a significant performance pentalty. Which is weird because if I do the transcoding with ffmpeg directly I get way higher performance with H.264:
| Scale | |
|---|---|
hevc_vaapi |
4.09x |
h264_vaapi |
11.4x |
(Note that this is not an apples to apples comparsion. It’s just to demonstrate the performance difference between codecs)
@bur115 when you say call ffmpeg directly do you mean you are calling the transcoder directly or a different build of ffmpeg. also are you preforming sw or hw burn in?
Directly (v7.1.1).
HW. But also there’s a performance penalty increase (from 10% to 16%).
I updated the builds to address the instability on windows, the error caused by certain livetv audio streams, and to pull in the critical security patch.
This thread is strictly for Forum Preview issues.
It is not for existing problems with the transcoder.
Please create new threads with the appropriate tags.
Wow,
4x to 11.4x is a huge jump in H.264 transcode speed. Is that speed increase from using FFMPEG 7.1.1 vs 6.1 or is something else going on?
Nah it’s all ffmpeg v7.1.1, just using different outputs. You’ll just have to pay the price for that ~40% bitrate reduction (at the same quality). FWIW the Plex Transcoder is doing something pretty inefficiently anyway because both are equally slow.
@chris_decker08 Well scratch that because I just did. I can no longer play videos with an audio delay bigger than the -window_size(5 sec). This is what you’ll need:
Like I said this can be fixed by increasing the -window_size. This is indeed a regression because the old Transcoder also uses 5 and works just fine. There might have been some code in place that dealt with this situation but this is no longer the case.
I also don’t understand why it’s even set in the first place; the default is 0, meaning all segments are kept (which AFAICT is happening anway?). Because there might be a good reason for it I’m currently setting the -window_sizemyself to
max(5,ceil([0:a].delay/1000))
Note that an abs() was not necessary as “negative delays” (positive video delay) work as intended.
@bur115 do you have a sample video with such a delay?
mkvmerge -o test.mkv --sync 1:6000 anyfilewithdts.mkv
Out of curiosity, when do you encounter files with such large timestamp offsets?
If this is something you are doing as part of your own workflow, does adding --timestamps 0:0 address the symptoms?
I would expect a large offset to make a variety of tasks more difficult, and wouldn’t be surprised if it confused the streaming buffer-cache of various players or required a bunch more memory. I’m certainly not saying it isn’t a regression! Just curious.
Oh hi @Volts, long time no see (I’m using a burner account).
One example I can give you is the UHD Blu-ray of “The Others (2001)”. If you rip that one yourself (from your legally owned disc) you’ll get a file where the English TrueHD audio track has a delay of 8.091s. That won’t play on various players that lack DTS/TrueHD support (if you’re using this preview that is).
Ahh, weird, interesting, thanks.
UPDATE: I guess this post was premature. He tried playing the file directly on his Apple TV, and it didn’t play – so the issue is not Plex-related.
UPDATE 2: The files having issues playing back had a nearly 2-second (Delay relative to video: -1 s 997 ms) audio delay introduced to the mkv via my MCEBuddy use.
It’s not 5 seconds like the above, but it is enough to delay video with VLC and to break playback to Apple TV via Plex - plays fine on Roku.
……………………
Is it possible to run an older FFmpeg 3.x-based version of Plex Media Server (PMS) on Windows alongside the Transcoder Preview?
I’ve been using the Preview and it’s working well overall, but I’m running into a playback issue with a friend’s Apple TV. Some of my x265 1080p files—encoded in Handbrake with Level 5.1—fail to play on his Apple TV Plex client. These same files play fine on his LG TV, Mac/Safari, and my Roku TV via Plex.
I’ve used Level 5.1 for years to distinguish older transcodes from newer ones (my library dates back to the Windows Media Center era). The affected files have bitrates well below threshold and are confirmed as Direct Play compatible, yet playback intermittently stalls on his Apple TV. Lowering the Remote Quality setting restores playback, suggesting a client-side issue with stream profile parsing or buffer allocation.
After testing, he found that re-wrapping the file—without re-encoding—into a new container with Level 4.2 resolves the issue. I’m wondering if this behavior is tied to changes in FFmpeg handling between versions.
is it an AppleTV HD or 4K? HEVC content struggles on the HD
It is 4K model 2022, it is actually my ATV dklien. Thanks for the post John
