GOB

Group Of Blocks

Services
Introduced in Rel-8
GOB is a structural unit in video coding, specifically in the ITU-T H.263 and related codecs, representing a group of macroblocks within a video frame. In 3GPP, it's relevant for specifying multimedia telephony service interoperability and video codec requirements for conversational services.

Description

A Group Of Blocks (GOB) is a fundamental data structure in video compression standards, most notably defined in the ITU-T H.263 video codec, which has been widely adopted for low-bitrate video communication, including early 3GPP multimedia services. A video frame is divided into macroblocks, which are typically 16x16 pixel regions containing luminance and chrominance information. A GOB groups a set of consecutive macroblocks from a single row (or multiple rows in some configurations) of the frame into a single logical unit for encoding, transmission, and error resilience purposes.

In the encoding process, the video codec processes macroblocks sequentially, applying techniques like motion estimation, transformation (e.g., DCT), quantization, and entropy coding. The GOB structure provides a resynchronization point within the bitstream. Each GOB has a header containing a start code and information like the GOB number and quantization parameters. This header allows a decoder to regain synchronization if bit errors or packet loss corrupt the data stream, preventing the loss of an entire frame. The decoder can skip to the next GOB header and continue decoding, albeit with potential visual artifacts in the lost region.

Within 3GPP specifications, GOB is referenced primarily in the context of defining mandatory codec capabilities for multimedia services. Specifications like 26.110 (codec for circuit-switched multimedia telephony) and 26.114 (IP Multimedia Subsystem (IMS) multimedia telephony) mandate support for specific video codec profiles, including H.263, which inherently uses the GOB structure. The 3GPP work ensures interoperability between UEs and networks by specifying how these video codecs, with their GOB-based frame partitioning, should be used over 3GPP-defined transport protocols (e.g., RTP/UDP/IP) and handled in scenarios like handover or bandwidth adaptation. Its role is therefore not as an active 3GPP-invented protocol, but as a defined component of adopted video coding standards that the overall system must support.

Purpose & Motivation

The purpose of the GOB concept, as referenced in 3GPP, is to ensure reliable and interoperable video communication services over mobile networks. Video codecs like H.263 were selected in early 3GPP releases (e.g., Release 99, 4) for multimedia telephony because they offered reasonable quality at the low bitrates available on 2.5G and 3G networks. The GOB structure within these codecs solves a key problem for error-prone wireless channels: resilience to transmission errors.

Before widespread use of more advanced error concealment and flexible macroblock ordering (FMO) found in later codecs like H.264, H.263's primary method for error resilience was the GOB structure and its resynchronization headers. In circuit-switched or early packet-switched video calls, bit errors and packet loss were common. Without resynchronization points like GOB headers, a single error could cause a decoder to lose track of the bitstream syntax, leading to catastrophic failure and potentially freezing the video until the next independently coded frame (I-frame). GOB headers allow the decoder to localize errors, discard one group of blocks, and continue decoding, providing a graceful degradation in video quality.

3GPP's inclusion of specifications mandating H.263 with GOB support was motivated by the need for a standardized, baseline video capability for the 3GPP Multimedia Telephony Service. It addressed the limitation of having no common video format, which would have hindered interoperability between devices from different vendors and across different network operators. As video codec technology evolved, 3GPP specifications evolved to mandate more advanced codecs (like MPEG-4 Visual, H.264/AVC), but the foundational requirements for error-resilient video transport, for which GOB was an early solution, remained a core concern.

Key Features

  • Defines a resynchronization layer within a video frame for error resilience
  • Groups a consecutive set of macroblocks (e.g., one row) under a single header
  • GOB header contains a unique start code and spatial location (GOB number)
  • Enables localized error concealment; decoder can skip to next GOB after packet loss
  • Specified as part of mandatory H.263 profile support in 3GPP multimedia telephony
  • Provides a structural unit for bitstream parsing and processing in legacy video codecs

Evolution Across Releases

Rel-8 Initial

Formally referenced the H.263 video codec and its GOB structure within 3GPP multimedia service specifications like 26.110 and 26.114. Established GOB-based H.263 as a baseline mandatory video codec for IMS Multimedia Telephony (MMTel) to guarantee basic interoperability for video calls over PS networks.

Maintained support for H.263 with GOB as a legacy codec option while introducing more advanced mandatory codecs like H.264/AVC. Specifications ensured backward compatibility and defined codec negotiation procedures where GOB-based H.263 could be a fallback.

Further evolution of multimedia services with a focus on HD voice and video. While H.263/GOB remained in specs for legacy support, primary emphasis shifted to more efficient and resilient codecs like H.264 and H.265 (HEVC), which use different error resilience tools like slices and FMO.

Defining Specifications

SpecificationTitle
TS 26.110 3GPP TS 26.110
TS 26.114 3GPP TS 26.114
TS 26.937 3GPP TS 26.937