Emby Videos started glitching.

[Kyla666 0]

I switch to emby a long while back because plex was giving me sync issues but out of nowhere Emby has started messing up in a odd way.

At first i thought that maybe my files got corrupt but i have used every means possible to check and everything is showing the files are fine
So i loaded up Plex and tried playing the files and they all work correctly with no problem.

In the picture is what i am talking about where in the same spots in the video it will do this in multiple spots. playing it on my computer with VLC and it doesn't do this play it on plex it doesn't do this only on emby.
Here's some of the things i have tried to fix this.
1. Uninstall Emby using Revo Uninstaller to completely remove everything. Then reinstall.

2. DDU uninstall Graphic drivers and reinstall.

3. Use mkvtoolnix to re-encode  video.

 

I've spent a few hours now into trying to fix this i think i need help.

[Abobader 3464]

Hello Kyla666,

** This is an auto reply **

Please wait for someone from staff support or our members to reply to you.

It's recommended to provide more info, as it explain in this thread:

Thank you.

Emby Team

[Kyla666 0]

Never mind i figured it out. I guess my router is dying on me.

[Kyla666 0]

OK... Sorry i was wrong. The router is fine. tried playing it on my computer on Emby and same problem but if i set Quality lower to about 30mbps it plays fine. But for some reason it will not play at 60mbps like it has been doing for a very long time.

[seanbuff 1316]

1 hour ago, Kyla666 said:

I've spent a few hours now into trying to fix this i think i need help.

Provide an example for the team to look at. Please attach the information requested in how to report a media playback issue. Thanks!

 

[Kyla666 0]

ffmpeg-remux-0aa7ebc5-698e-4941-baa8-5c77df4dabbd_1.txt

[Luke 42078]

Hi, can you try Chrome and see how that compares? Thanks.

[Kyla666 0]

11 minutes ago, Luke said:

Hi, can you try Chrome and see how that compares? Thanks.

Chrome is the same as well as On my Roku Tv.

 

Setting the movie down to 1080p 30mbps does fix the issue but I'm trying to find out how or why it's now being a issue.  It's kind of a pain to have to set the biterate every time i wish to play the movie and not everyone in my house hold understands how to do it.

Edited May 23, 2025 by Kyla666

[visproduction 315]

Kyla,

I believe you mean 30 fps (Frames per second).

[Kyla666 0]

13 hours ago, visproduction said:

Kyla,

I believe you mean 30 fps (Frames per second).

lol No.

 

[Lessaj 467]

I could be mistaken but based on the information in the logs you provided there shouldn't really be a difference between 30 and 60 Mbps since the video bitrate is under 30 Mbps, so both cases should result in an ffmpeg remux - Firefox the transcode reason stated ContainerNotSupported, but I know Chrome supports mkv, except it doesn't support TrueHD so it would require a remux. However the overall bitrate for the container may exceed 30 Mbps, in that case it might be forcing a transcode to occur. Between these 2 situations the way the content is delivered is the same - using small TS files - but the work being done is very different. A remux just copies the video track and changes the audio format into TS segments, a transcode is essentially recreating the video track and also changing the audio format. It may be able to fix any errors on the fly in that situation, but would need a log example of that if transcoding is occurring.

Having said that, you mentioned it happens on your Roku as well. Is that also triggering a remux, or a transcode? Not sure if Roku supports TrueHD or not, so I'm asking because the processing would be the same in both cases if that's happening. If neither is capable of directly playing the MKV, you're playing back a slightly manipulated copy of the original MKV, which might be where the issue is being introduced.

If you playback the TS segment related to the affected timestamp in VLC does it show the same corruption? Each TS file should have 6 seconds of video (remux) or 3 seconds (transcode).

[Kyla666 0]

22 minutes ago, Lessaj said:

I could be mistaken but based on the information in the logs you provided there shouldn't really be a difference between 30 and 60 Mbps since the video bitrate is under 30 Mbps, so both cases should result in an ffmpeg remux - Firefox the transcode reason stated ContainerNotSupported, but I know Chrome supports mkv, except it doesn't support TrueHD so it would require a remux. However the overall bitrate for the container may exceed 30 Mbps, in that case it might be forcing a transcode to occur. Between these 2 situations the way the content is delivered is the same - using small TS files - but the work being done is very different. A remux just copies the video track and changes the audio format into TS segments, a transcode is essentially recreating the video track and also changing the audio format. It may be able to fix any errors on the fly in that situation, but would need a log example of that if transcoding is occurring.

Having said that, you mentioned it happens on your Roku as well. Is that also triggering a remux, or a transcode? Not sure if Roku supports TrueHD or not, so I'm asking because the processing would be the same in both cases if that's happening. If neither is capable of directly playing the MKV, you're playing back a slightly manipulated copy of the original MKV, which might be where the issue is being introduced.

If you playback the TS segment related to the affected timestamp in VLC does it show the same corruption? Each TS file should have 6 seconds of video (remux) or 3 seconds (transcode).

VLC plays it just fine with no corruption. Chrome has the same problem.  

Whats odd is nothing changed on my computer or in the settings. This just started happening out of the blue.
(I was thinking maybe it's do to with Nvidia driver update because that's the only thing that changed)
 

[Lessaj 467]

Thank you for adding the stats for nerds during playback, that shows that both 30 Mbps and 60 Mbps are exactly the same result, it's only transcoding the audio and not the video. Your VLC screenshot is for the original MKV. I'm referring to the TS segments that are generated, if you find the same TS file that was generated that correlates to 10:33 (or whatever the example happens to be, if you find a different occurence) does it show the same corruption if played back in VLC? You will only be able to find them while the stream is playing, they are deleted when it's stopped.

[Kyla666 0]

6 minutes ago, Lessaj said:

Thank you for adding the stats for nerds during playback, that shows that both 30 Mbps and 60 Mbps are exactly the same result, it's only transcoding the audio and not the video. Your VLC screenshot is for the original MKV. I'm referring to the TS segments that are generated, if you find the same TS file that was generated that correlates to 10:33 (or whatever the example happens to be, if you find a different occurence) does it show the same corruption if played back in VLC? You will only be able to find them while the stream is playing, they are deleted when it's stopped.

Yes. the TS files are having the same corruption when played in VLC  which i am guessing means there's a problem with transcoding at 60mbps. but why now? I've not changed anything.

[Lessaj 467]

But it's not transcoding at 60 Mbps, nor is it doing it at 30. The video bitrate is already less than both of those values, it doesn't add more data to target that rate, it is only copying the video track into the TS container. Overall this is a very lightweight operation, it is doing nothing with the video. If it happens at the same time stamps this might be a keyframe issue? I might be able to find the same file and do some testing.

[Lessaj 467]

I am able to reproduce issues with the same file. Not exactly the same as you but I get corruption too, I saw some basically right away during the universal logo but I see it at the same spot you've shown too. I tried to convert the file from AVC to HEVC as part of my usual ingestion pipeline and ffmpeg did not report any errors, I will try again with more logging just in case. I then tried to play the now converted file and there is no issue. Indeed MPV and VLC do not show the corruption, but I saw it in the TS file playback. In this case I am not sure why a remux would do this since it's not doing anything with the video, maybe @softworkzhas some ideas.

EDIT: To clarify, when playing back the TS file MPV is basically straight up skipping frames, VLC shows the corruption.

4B4A37_105.ts

Edited May 23, 2025 by Lessaj

[speechles 2055]

Quote

21:43:04.695   Stream #0:0 -> #0:0 (copy)
21:43:04.695   Stream #0:1 -> #0:1 (truehd (native) -> aac (native))
21:43:04.695   Stream #0:6 -> #1:0 (subrip (srt) -> webvtt (native))
21:43:04.695   Stream #0:7 -> #2:0 (subrip (srt) -> webvtt (native))
21:43:04.695   Stream #0:8 -> #3:0 (subrip (srt) -> webvtt (native))
21:43:04.695   Stream #0:9 -> #4:0 (subrip (srt) -> webvtt (native))
21:43:04.695   Stream #0:10 -> #5:0 (subrip (srt) -> webvtt (native))
21:43:04.695   Stream #0:13 -> #6:0 (subrip (srt) -> webvtt (native))

Might have to do with all these subrip embedded into the media. Because you may want to change track to those they get embedded into the m3u8 playlist. Which is completely fine. The issue is those other tracks which cannot be parsed are arranged around the container.

Quote

Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
21:43:04.674 [matroska,webm @ 000001f9cc352200] Could not find codec parameters for stream 18 (Subtitle: hdmv_pgs_subtitle (pgssub)): unspecified size

There are many that cannot be parsed correctly all of those are PGSSUB and cannot be displayed since they cannot be parsed.

If you try to get this to Direct Play it would resolve the issue. You might want to mark this AC3 track shown below as default in MKVToolNix GUI and maybe abandon all those PGSSUB that are in it too. Then Remux the file removing those PGSSUB and changing the audio track default to the below. Also remove any "tags" you might find in the media. Those are not standard and might cause parsers to choke.

Quote

21:43:04.693   Stream #0:2(eng): Audio: ac3, 48000 Hz, 5.1(side), fltp, 448 kb/s

The second audio stream is compatible. If on the details view pre-play screen you select this audio track instead of the TrueHD track it should play back correctly with no issues since it removes ffmpeg packaging from the equation.

Edited May 24, 2025 by speechles

[Lessaj 467]

18 minutes ago, speechles said:

Might have to do with all these subrip embedded into the media. Because you may want to change track to those they get embedded into the m3u8 playlist. Which is completely fine. The issue is those other tracks which cannot be parsed are arranged around the container.

I tested removing all the subtitles from the file and just had a single element SRT instead but it still does it, so it's something with the video track still but not clear what.

And yes, direct playing does not show any issues.

Edited May 24, 2025 by Lessaj

[Luke 42078]

OK we're looking into it. Thanks.