31–40 of 54 posts
Drones. EDIT: Big-boy drones.
MPEG-TS is incorporated in many digital TV standards. They will continue to be around for a long time simply because of that, regardless of technical points.
So this is why I can never watch a whole movie and not have a single dropped frame!
Back in the old TV days, the TV camera set the 60 fps frequency, and if it was slightly slow at just 59.9 fps, then your TV would also run slightly slow. The whole system was synced perfectly.
Whereas now every device seems to think it can set it's own version of "60 Hz". Your GPU's 60Hz is inevitably a bit different from your displays idea of "60Hz", which in turn is a bit different from your web browsers idea of "60Hz", which is again a bit different from the livestream you're watchings version of "60 Hz". At every stage, when one clock is slightly faster, frames are dropped, and at other stages duplicate frames are inserted. End result: You can't watch a film without random occasional jitters.
Please, everyone in the AV industry: Design your shit better. We should take away your quartz crystals and force you to have only inaccurate timing devices just so you are forced to properly sync everything!
Earlier quoted context omitted.
What about bridging broadcast media to IP or vice versa? One of the advantages of MPEG-TS is that it’s dead simple to map it to RTP or even plain UDP and back even with packet loss and data errors.
Extract the PS from the TS and send that over the network.
There's RTP, but I would definitely not call translating MPEG-TS to RTP and back "dead simple" (unless you're just encapsulating MPEG-TS via RFC 2250, but then you're still using MPEG-TS).
> able to recover the clock of the source in order to know when to drop or duplicate video frames So this is why I can never watch a whole movie and not have a single dropped frame! Back in the old TV days, the TV camera set the 60 fps frequency, and if it was slightly slow at just 59.9 fps, then your TV would also run slightly slow. The whole system was synced perfectly. Whereas now every device seems to think it ca…
For VOD, your playback system's clock running slightly fast or slow should not be an issue, since all buffers are under its control (it can just send disk loads, HTTP requests etc. at the pace it needs them), and for livestreaming, the most common solutions (HLS and MPEG-DASH, ultimately using MPEG-TS or fragmented MPEG-4 container files) also explicitly specify clock synchronization.
> We should take away your quartz crystals and force you to have only inaccurate timing devices just so you are forced to properly sync everything!
For livestreams, that would ultimately require synchronizing your entire video pipeline to a remote source (i.e. running your video output slightly slow/fast as required) – I'm not sure if devices like set-top boxes or streaming receivers support that, but it seems entirely impossible for anything capable of displaying two video streams (synchronized to different source clocks) at once.
Don't RTMP and probably WebRTC both handle this in ~1-4 second chunks with video segments and a playlist?
For non-live content a buffer can be attempted multiple times.
Live content, yes that's an issue, but often if it's missed it's too late.
The simple answer: MPEG-TS still exists because it’s still the best media container/transport system in existence. It was designed and has evolved over a long time based on solid foundations by very smart people in the industry, across multiple institutions and professions. As opposed to the “format du jour” that was quickly thrown together by some eastern block script kiddie who saw the basic outline of an AVI file…
(FWIW, DVDs use MPEG-2 program streams, not transport streams. Both MPEG-2 part 1 systems streams, just different kinds.)
I don't know what this property is called so I don't really know how to search how well a format can start mid stream. any hints?
I started using mpeg_ts when I discovered that it streams well, that is, it can start randomly in the middle without much trouble. A few other formats I tried choked under this use case. I don't know what this property is called so I don't really know how to search how well a format can start mid stream. any hints?
This property is more a function of the encoding parameters of the video stream. It just happens that MPEG-TS is typically encoded so as to minimize the reasonable time between RAPs.
Also, MPEG-TS streams have sync bytes every 188 bytes, making it trivial to align the bitstream and then find the RAPs. Basically the use case you are describing is just the normal operation of a broadcast decode; get a stream at some arbitrary point of broadcast and decode it.