OK since there seems to be a disagreement (to put it lightly :) as to what the current NUT framework can do for synchronizing timing between a transmitter and receiver, I'd like to lay down the hypotheses and reasoning I'm working from. Maybe others disagree on the basic assumptions or haven't though of them. So, here it goes: Transmitter side: Key assumption is that frames are actually transmitted according to dts. In a VBR transmission with immensely excessive bandwidth, or a pure CBR (e.g. uncompressed, single-stream) transmission, this can be done almost exactly. In CBR with buffer restraints, obviously it will not be exact. It is sufficient that the mean difference between dts and actual transmission time be constant over intervals of time whose length is on the order of the maximal length of time in which transmitter and receiver clocks can be expected to remain within an acceptable error relative to one another. Ensuring that this mean difference requirement can be met is a matter of bitrate constraints on the codecs in use. Unless my casual estimates are horribly mistaken, it is much easier to meet these requirements than to meet most buffering requirements, i.e. any broadcast setup already meeting moderate to strict buffer size constraints will automatically meets the requirements for the transmitter to be able to ensure the mean difference requirement. Note that if content is created live and transmitted with minimal delay, the constraint will automatically be met. Only non-live transmissions need to make particular efforts to synchronize transmit times with dts, and even then if bitrate/buffer constraints are strict it may be trivial. Many years ago I wrote a non-live streaming server based on ogg container (eew!) which synchronized transmission of ogg pages to the system clock and it involved very little effort. Receiver side: Upon receiving each frame, the receiver stamps it with the actual time the frame was received, according to the local clock. Drift in the mean difference between receive-timestamps and dts is tracked and used to adjust the local clock as it diverges from the transmitter's clock. Note that there's nothing NUT-specific about this design. It will work with any existing container, and it can be used in place of the redundant timestamps in MPEG if one desires. In the interests of improving the media software/hardware landscape in general, it's much more worthwhile to have designs that work with any container, and to push developers to move towards supporting those rather than highly container-specific or application-specific ("application" in the sense of "broadcast tv" or "video on demand", not "firefox" or "ms word") implementations of synchronization. I'd be very happy to see (maybe even help write) an RFC on synchronization of unidirectional broadcast streams for arbitrary streamable containers. Is anyone willing to consider that as a constructive alternative to arguing about putting MPEG-type stuff in NUT? Rich