[NUT-devel] Broadcast sufficiency - my assumptions/reasoning/design for it

[Rich Felker]

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