Read the systems layer
ITU-T identifies H.222.0 as a systems standard for moving pictures and associated audio information. MPEG transport streams organise carried media and related signalling; they are not simply another spelling of the MPEG-2 video codec. A file or response labelled TS therefore still needs its actual video and audio identities established before compatibility can be judged.
Keep packetization separate from delivery
The IETF’s MPEG RTP payload reference discusses transport-stream packets carried through RTP. That is one context for understanding packetization, not proof that every .ts resource uses RTP or UDP. HLS can also refer to transport-stream media resources delivered through HTTP. Inspect the real presentation and connection rather than inferring the complete network protocol from the container’s name or filename extension.
Check the media tracks
A player needs to interpret the container and decode the relevant tracks. It may show a picture while failing on an audio format, or reject the container before either decoder starts. Preserve those observations separately. Renaming a .ts file as .mp4 does not rebuild the container or convert its compressed tracks. A proper conversion decision begins with the destination’s supported combinations and your right to modify the source.
Use a precise compatibility question
Report the container, video codec/profile, audio codec and application together. If only a stream URL is known, ask the responsible publisher for a redacted technical summary rather than sharing credentials publicly. Avoid claiming one transport-stream test establishes every channel’s format. This reference does not inspect a UK IPTV feed, certify a receiver or establish that media carried in a familiar container is licensed for redistribution.
Questions, answered
Does .ts mean the picture must be MPEG-2 video?
No. A transport-stream container and a video coding format are separate layers. Inspect the actual tracks rather than deriving them from the extension.