Understanding IEEE's deterministic AV bridging standards
Packets within packets (within packets...)
A complete AVBTP Ethernet packet is shown in Figure 2. The AVBTP Ethernet frame is uniquely identified by the AVBTP Ethertype.
Within a P1722 packet, the content type is described by the Payload Info field.
The initial implementation of AVBTP supports IEC 61883 content however AVBTP has been designed to allow future expansion to support other yet-to-be-defined media standards.
Figure 2 illustrates how IEC 61883-6 AM824 uncompressed audio samples are encapsulated in an Ethernet frame.
Supported media types
Continuing the theme of leveraging existing standards, AVBTP takes advantage of the media formats and synchronization mechanisms specified by IEC 61883 for use in IEEE 1394 FireWire devices.
Formats based on IEC 618837 parts 1–8 are:
• 61883-2 SD-DVCR
• 61883-4 MPEG2-TS Compressed Video
• 61883-6 Uncompressed Audio
• 61883-7 Satellite TV MPEG
• 61883-8 Bt.601/656 Video
• IIDC Uncompressed Industrial Cameras
A notable side benefit of basing AVBTP on IEC 61883 is the relative ease with which a FireWire gateway8 to an AVB network could be implemented.
Synchronization
Synchronization in an AVB network starts with the Precision Time Protocol but ends with synchronized media clocks. PTP is responsible for synchronizing all nodes in an AVB network to identical wall clock time; not for synchronizing media clocks. In other words, PTP does not actually transport synchronized media clocks but instead provides a low-level building block crucial for managing a distributed media synchronization system.
A crucial benefit of this approach is coexistence of multiple, independent media clock domains on an AVB network. Unrelated audio and video streams can simultaneously exist in the same LAN.
Cross-timestamping and Presentation Timestamps
AVBTP assumes that AVB node media clocks are clocked by free-running oscillators. It is also assumed that the node's internal concept of wall clock time has been synchronized to the PTP Grandmaster. AVBTP media clock sources embed "AVBTP Presentation Timestamps" in AVBTP streaming packets. Figure 3 illustrates the relationship between PTP network time and AVBTP Presentation Timestamps.
Not all AVBTP streaming packets include an AVBTP Presentation Timestamps. The DBC (data block count) in the AVBTP header defines how often AVBTP Presentation Timestamps are generated. A commonly used value for DBC is 810. This means every eighth media sample, the value of the local PTP RTC is sampled, converted to a 32-bit value (in nanoseconds), and added to desired (if any) latency normalization value. More on latency normalization later.
Media Clock Recovery
Recreating synchronized media clocks follows a similar but reverse process.
The value of the DBC field in the P1722 header triggers how often the AVB media clock slave should recreate a media clock edge.
Figure 4 illustrates the AVBTP media clock recovery mechanism. Figure 5 illustrates one possible method of implementing what is essentially a distributed PLL. With only minimal additional filtering, sub-nanosecond jitter is easily obtainable.
Loading comments... Write a comment