ddp 1 Posted August 13, 2025 Posted August 13, 2025 Hi, I have been chasing down the fact that some of my videos that are from free-to-air digital TV (MPEG-2 .ts files containing h264 video and mp2 audio), and are a little 'jittery' on my new TV. I have chased this to the point where I believe while my TV supports mpeg-2 audio, but Emby does not recognise this and forces it to be transcoded unnecessarily. I can see from the playback plugin (but also Stats for Nerds) that the audio stream is being transcoded: Original Video Codec: h264 Size: 1920x1080 Framerate: 50 Aspect Ratio: 16:9 Bitrate: 3726003 Interlaced: true Original Audio Codec: mp2 Language: English Channels: 2 Original Audio Codec: aac_latm Language: English Channels: 2 Transcoded Video Direct: true Codec: h264 Size: 1920x1080 Transcoded Audio Direct: false Codec: aac Channels: 8 Transcode Info Container: ts Bitrate: 3918003 Position: 6% (00:04:52 / 01:17:19) Transcode Reasons ContainerNotSupported A relevant log line showing the negotiated supported codecs: 2025-08-13 00:19:12.982 Info DynamicHlsService-0HNEPL9LMM02J:00000001: http/1.1 GET http://192.168.2.2:8096/emby/videos/244805/master.m3u8?DeviceId=703b95e1ff3e8ab8&MediaSourceId=mediasource_244805&PlaySessionId=00b56064a7474ad691c1f18491fdc5b3&api_key=<removed>&VideoCodec=h264,mpeg2video,hevc,h265,av1&AudioCodec=aac_latm,mp4a_latm,ac3,eac3,ac4,trueHD,dts,dca,dtshd,aac,mp3&VideoBitrate=79744000&AudioBitrate=256000&MaxHeight=2304&AudioStreamIndex=2&CopyTimestamps=true&SegmentContainer=ts&MinSegments=2&AllowInterlacedVideoStreamCopy=True&BreakOnNonKeyFrames=True&SubtitleStreamIndexes=-1&ManifestSubtitles=vtt&h264-profile=high,main,baseline,constrainedbaseline&h264-level=51&hevc-profile=Main,Main10&hevc-level=153&aac_latm-audiochannels=8&mp4a_latm-audiochannels=8&ac3-audiochannels=8&eac3-audiochannels=8&ac4-audiochannels=8&trueHD-audiochannels=8&dts-audiochannels=8&dca-audiochannels=8&dtshd-audiochannels=8&aac-audiochannels=8&mp3-audiochannels=8&TranscodeReasons=ContainerNotSupported. Source Ip: 192.168.2.10, Connection=keep-alive, Host=192.168.2.2:8096, User-Agent=Emby/2.1.23g (Linux;Android 12) ExoPlayerLib/2.18.7, Accept-Encoding=gzip However, I can play this exact stream in other clients on my TV (MythTV leanback app), and specifically when I installed the app: Codec Info, I can see my supported codecs includes: "audio/mpeg", "audio/mpeg-L1" and "audio/mpeg-L2" which I believe shows it does support MP2 audio. If all the above is correct, can you provide a quick fix by forcing an override for the support for my client (seems that may have been possible via XML once?) or of course fixing it would be even better Thanks
brothom 177 Posted August 13, 2025 Posted August 13, 2025 3 hours ago, ddp said: 2025-08-13 00:19:12.982 Info DynamicHlsService-0HNEPL9LMM02J:00000001: http/1.1 GET http://192.168.2.2:8096/emby/videos/244805/master.m3u8?DeviceId=703b95e1ff3e8ab8&MediaSourceId=mediasource_244805&PlaySessionId=00b56064a7474ad691c1f18491fdc5b3&api_key=<removed>&VideoCodec=h264,mpeg2video,hevc,h265,av1&AudioCodec=aac_latm,mp4a_latm,ac3,eac3,ac4,trueHD,dts,dca,dtshd,aac,mp3&VideoBitrate=79744000&AudioBitrate=256000&MaxHeight=2304&AudioStreamIndex=2&CopyTimestamps=true&SegmentContainer=ts&MinSegments=2&AllowInterlacedVideoStreamCopy=True&BreakOnNonKeyFrames=True&SubtitleStreamIndexes=-1&ManifestSubtitles=vtt&h264-profile=high,main,baseline,constrainedbaseline&h264-level=51&hevc-profile=Main,Main10&hevc-level=153&aac_latm-audiochannels=8&mp4a_latm-audiochannels=8&ac3-audiochannels=8&eac3-audiochannels=8&ac4-audiochannels=8&trueHD-audiochannels=8&dts-audiochannels=8&dca-audiochannels=8&dtshd-audiochannels=8&aac-audiochannels=8&mp3-audiochannels=8&TranscodeReasons=ContainerNotSupported. Source Ip: 192.168.2.10, Connection=keep-alive, Host=192.168.2.2:8096, User-Agent=Emby/2.1.23g (Linux;Android 12) ExoPlayerLib/2.18.7, Accept-Encoding=gzip However, I can play this exact stream in other clients on my TV (MythTV leanback app), and specifically when I installed the app: Codec Info, I can see my supported codecs includes: "audio/mpeg", "audio/mpeg-L1" and "audio/mpeg-L2" which I believe shows it does support MP2 audio. Sounds like the video is jittering due to the server transcoding the file and your logs seem to confirm this. I also noticed Emby sometimes not picking the highest/original quality available for whatever reason, so it will raise or lower the quality unintentionally selecting something outside of the original parameters causing transcoding. Do you have quality settings enabled in your app? If you have, does the file become less laggy when you choose the maximum quality? Looks something like this:
ddp 1 Posted August 13, 2025 Author Posted August 13, 2025 (edited) Thanks for the thought - I'm not 100% sure the jittering is the audio transcode. What I can see is that it is definitely transcoding, the quality is 76 (or sometimes 80) MBps and I can see in the stats for nerds its transcoding at 500+ frames per second, so its should not be the cause, but when I play this video in another app its buttery smooth and in emby its jittering through a very slow pan. Other videos that are mpeg2 .ts files with h264 and mp3, are also smooth in emby. Ultimately, if the tv supports mp2, emby should recognise this and direct play the audio whether it really fixes my jittering video or not Edited August 13, 2025 by ddp
brothom 177 Posted August 13, 2025 Posted August 13, 2025 23 minutes ago, ddp said: Thanks for the thought - I'm not 100% sure the jittering is the audio transcode. What I can see is that it is definitely transcoding, the quality is 76 (or sometimes 80) MBps and I can see in the stats for nerds its transcoding at 500+ frames per second, so its should not be the cause, but when I play this video in another app its buttery smooth and in emby its jittering through a very slow pan. Other videos that are mpeg2 .ts files with h264 and mp3, are also smooth in emby. Files can be different from one another, regardless of their extension. It almost sounds like something is wrong with some of your files and when FFMPEG tries to process them, it can't fill the holes, causing some frames to be missed / skipped which in turn causes jitter. Also the "other player" could be performing on-the-fly fixes. For example VLC is known for being (very) idiot-proof. Giving VLC files that are even only partially intact can sometimes be rendered without any major issues. 23 minutes ago, ddp said: Ultimately, if the tv supports mp2, emby should recognise this and direct play the audio whether it really fixes my jittering video or not If you TV supports the provided video codec/container and the same goes for the audio track, Emby shouldn't transcode AT ALL. Your Emby CLIENT however can be set so a specific quality, causing it to transcode anyway. --- Have you checked to see if another quality than the highest is selected in your Emby client?
ebr 16169 Posted August 13, 2025 Posted August 13, 2025 6 hours ago, ddp said: I can see from the playback plugin (but also Stats for Nerds) that the audio stream is being transcoded In that example it is the container that is not supported, not the audio. However, once we change the container (to HLS) that then further restricts the available audio formats. That is why your audio ends up being converted as well.
Luke 42077 Posted August 14, 2025 Posted August 14, 2025 In this app we might be able to stream copy the mp2. If you temporarily (just for testing) restrict user audio transcoding permissions for the user, does it play?
ddp 1 Posted August 15, 2025 Author Posted August 15, 2025 Thanks Luke, this allowed me to validate that the TV can play these streams. If I disable audio transcoding for this User, the stream continues to play with Direct Video (HLS) and Direct Audio (MP2). If I disable converting the container, the video will not play. Something does not feel right here as presumably transcoding just the container does not need to transcode the audio, but the speed of my transcode is so much faster than the play back (whether Emby transcodes just the container, or the container and the audio), that i don't understand why this video (and not others from similar mpeg.ts files) is causing the jittery playback. I have checked several other mpeg.ts files (some with hls/ac3 for example) and they do not jitter during slow pans. So summarising: mpeg.ts (HLS/MP2) - transcode container and MP2 -> jitters mpeg.ts (HLS/MP2) - transcode container only -> jitters mpeg.ts (HLs/AC3) - transcode container only -> no jitter at all FWIW: I am on 4.9.18 and am happy to provide more (logs, or small snippets of the videos, etc.). Thanks,
ddp 1 Posted August 16, 2025 Author Posted August 16, 2025 (edited) Hi, one other brief thought. It might be worth noting the TV is an Australian model, it includes a physical aerial input to handle free to air broadcast DTV. I would expect it has to handle the mepg TS files that are broadcast here. I can't be sure as it does seem odd the TV would not support this container, but when I don't transcode the container it fails to play. Edited August 16, 2025 by ddp decided to add/clarify my post
ddp 1 Posted August 17, 2025 Author Posted August 17, 2025 Yes - all of them have mpeg ts as container & variable video, with the first audio channel having constant audio and one having a variable audio - switching to that audio did not change the situation fwiw. Here are the full details of one of the jittering videos (and below one that does not): General ID : 784 (0x310) Complete name : 1030_20250810123800.ts Format : MPEG-TS File size : 2.01 GiB Duration : 1 h 17 min Overall bit rate mode : Variable Overall bit rate : 3 727 kb/s Frame rate : 25.000 FPS Video ID : 102 (0x66) Menu ID : 1 (0x1) Format : AVC Format/Info : Advanced Video Codec Format profile : High@L4 Format settings : CABAC / 4 Ref Frames Format settings, CABAC : Yes Format settings, Reference frames : 4 frames Codec ID : 27 Duration : 1 h 17 min Width : 1 920 pixels Height : 1 080 pixels Display aspect ratio : 16:9 Active Format Description : Full frame 16:9 image Frame rate : 25.000 FPS Standard : Component Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Interlaced Scan type, store method : Separated fields Scan order : Top Field First Color range : Limited Color primaries : BT.709 Transfer characteristics : BT.709 Matrix coefficients : BT.709 Audio #1 ID : 103 (0x67) Menu ID : 1 (0x1) Format : MPEG Audio Format version : Version 1 Format profile : Layer 2 Codec ID : 3 Duration : 1 h 17 min Bit rate mode : Constant Bit rate : 256 kb/s Channel(s) : 2 channels Sampling rate : 48.0 kHz Frame rate : 41.667 FPS (1152 SPF) Compression mode : Lossy Delay relative to video : -388 ms Stream size : 142 MiB (7%) Language : English Audio #2 ID : 104 (0x68) Menu ID : 1 (0x1) Format : AAC LC SBR Format/Info : Advanced Audio Codec Low Complexity with Spectral Band Replication Commercial name : HE-AAC Format settings : NBC Muxing mode : LATM Codec ID : 17-2 Duration : 1 h 17 min Bit rate mode : Variable Channel(s) : 2 channels Channel layout : L R Sampling rate : 48.0 kHz Frame rate : 23.438 FPS (2048 SPF) Compression mode : Lossy Delay relative to video : -142 ms Language : English Language, more info : Visual impaired commentary Editorial classification : Visual impaired commentary Mix type : Independent Text ID : 43 (0x2B)-801 Menu ID : 1 (0x1) Format : Teletext Subtitle Language : English Menu ID : 1024 (0x400) Menu ID : 1 (0x1) Format : Teletext Subtitle / AVC / MPEG Audio / AAC / / Duration : 1 h 17 min List : 43 (0x2B)-801 (Teletext Subtitle, en) / 102 (0x66) (AVC) / 103 (0x67) (MPEG Audio, English) / 104 (0x68) (AAC, English) / 7000 (0x1B58) () / 7789 (0x1E6D) () Language : English / / English / English and one that is not jittering: General ID : 1283 (0x503) Complete name : 1070_20250803045000.ts Format : MPEG-TS File size : 8.79 GiB Duration : 4 h 10 min Overall bit rate mode : Variable Overall bit rate : 5 025 kb/s Frame rate : 25.000 FPS Video ID : 833 (0x341) Menu ID : 1 (0x1) Format : AVC Format/Info : Advanced Video Codec Format profile : High@L4 Format settings : CABAC / 4 Ref Frames Format settings, CABAC : Yes Format settings, Reference frames : 4 frames Codec ID : 27 Duration : 4 h 10 min Bit rate : 4 389 kb/s Maximum bit rate : 10 000 kb/s Width : 1 920 pixels Height : 1 080 pixels Display aspect ratio : 16:9 Frame rate : 25.000 FPS Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : MBAFF Scan type, store method : Interleaved fields Scan order : Top Field First Bits/(Pixel*Frame) : 0.085 Stream size : 7.67 GiB (87%) Color range : Limited Audio ID : 835 (0x343) Menu ID : 1 (0x1) Format : AC-3 Format/Info : Audio Coding 3 Commercial name : Dolby Digital Codec ID : 129 Duration : 4 h 10 min Bit rate mode : Constant Bit rate : 384 kb/s Maximum bit rate : 444 kb/s Channel(s) : 2 channels Channel layout : L R Sampling rate : 48.0 kHz Frame rate : 31.250 FPS (1536 SPF) Compression mode : Lossy Delay relative to video : -1 s 29 ms Stream size : 688 MiB (8%) Language : English Service kind : Complete Main Text ID : 836 (0x344)-801 Menu ID : 1 (0x1) Format : Teletext Subtitle Language : English Menu ID : 832 (0x340) Menu ID : 1 (0x1) Format : AVC / AC-3 / Teletext Subtitle / Duration : 4 h 10 min List : 833 (0x341) (AVC) / 835 (0x343) (AC-3, English) / 836 (0x344)-801 (Teletext Subtitle, en) / 774 (0x306) () Language : / English / English
Luke 42077 Posted September 8, 2025 Posted September 8, 2025 @ddpmpegts is pretty widely supported, so most likely it does support it. When you force the direct play I am guessing it just has trouble with these particular files.
ddp 1 Posted September 13, 2025 Author Posted September 13, 2025 Thanks Luke, I used ffmpeg -i 1030_20250909005300.ts -c copy 1030_20250909005300.mp4 to convert the file to an mp4 container. Interestingly, this is still not smooth at all, in fact similar if not worse. Now the container is not coming up as unsupported, but oddly it is still converting the audio (mp3) in software. I don't really understand why that would be. 2 thoughts, when I used that ffmpeg line above, there was 1 or 2 logs indicating errors in frames that ffmpeg corrected. Maybe something is not quite right with the files as you suspect, but usually a once over with ffmpeg fixes that. The other thought I have right now, is regardless of why, when the audio is not playing via hardware it somehow causes the video/audio syncing to be modified enough that the jittering video is quite noticeable. I'm not sure there is anything specific we can further do with this, for now, I am playing the myth recordings in a myth client so it is not a major problem for me, and it only occurs on my new TV. My hope to replace myth as a client with emby is not going to happen at the moment, but unless you want to chase this further, suggest we close this ticket. 1
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now