IDR

Instantaneous Decoding Refresh

Services →
Introduced in Rel-8

IDR is a video coding feature that defines a frame type which resets the decoder state, enabling random access and error recovery by making all subsequent frames independent of prior data.

Category
Services
Introduced
Rel-8
Where
Services › Codecs
Specifications
13 specs
IDR Description Purpose Related Classification Detected Changes Specifications

Description

Instantaneous Decoding Refresh (IDR) is a critical concept in modern video compression standards, notably H.264/AVC (Advanced Video Coding) and H.265/HEVC (High Efficiency Video Coding), as adopted and profiled by 3GPP for multimedia services like MBMS and streaming. An IDR picture is a special type of Intra-coded (I) picture that acts as a strong synchronization and random access point within a video bitstream. From a decoding perspective, the arrival of an IDR picture resets the decoder's reference picture buffer. This means that no frame decoded after an IDR picture is allowed to use any frame that was decoded *before* that IDR picture as a reference for predictive coding.

Technically, this is enforced through the NAL (Network Abstraction Layer) unit type and syntax elements in the slice header. When a decoder encounters an IDR picture, it marks all existing reference pictures in its decoded picture buffer (DPB) as "unused for reference," effectively clearing them. All subsequent P (Predicted) and B (Bi-predictive) pictures can then only refer to pictures that follow this IDR picture in decoding order. This creates a clean break in the prediction chain. The IDR picture itself is coded using only spatial redundancy within the frame (intra-prediction), making it independently decodable but also relatively large in size compared to inter-coded frames.

In the context of 3GPP services, such as Packet-Switched Streaming Service (PSS), Multimedia Broadcast/Multicast Service (MBMS), or Dynamic Adaptive Streaming over HTTP (DASH), IDR pictures are strategically inserted into the video stream. Their role is multifaceted: they enable random access for users joining a broadcast or seeking within a stream, provide a recovery point after data loss or corruption (as decoding can restart cleanly from an IDR), and facilitate channel switching in mobile TV services by providing frequent entry points. The placement interval of IDR pictures is a key trade-off between random access performance/error resilience and coding efficiency, as more frequent IDR pictures increase bitrate but improve accessibility.

Purpose & Motivation

The purpose of the Instantaneous Decoding Refresh (IDR) picture is to provide guaranteed, clean points for decoder (re-)initialization within a predictively coded video sequence. Video compression relies heavily on temporal prediction, where frames (P and B frames) are encoded relative to previously decoded reference frames. This creates long chains of dependency. Without a mechanism like IDR, a decoder that starts in the middle of a stream, experiences a packet loss, or encounters a corrupted frame would be unable to reconstruct subsequent frames correctly, as they might depend on missing or erroneous reference data.

IDR solves this problem by periodically inserting a frame that breaks all prediction dependencies from the past. It was motivated by the requirements of interactive and broadcast services over error-prone and dynamic channels like mobile networks. For services like video telephony, streaming, and mobile TV, users need to be able to switch channels or seek within a video instantly. The IDR picture provides the technical foundation for this by ensuring that from that point onward, decoding is self-contained. It addresses the limitations of a pure I-frame approach by formally defining the reset of the decoder state in the standard, ensuring interoperability. Its creation and standardization within video codecs were essential for enabling reliable, random-access video services in 3GPP ecosystems, balancing the high compression efficiency of long-term prediction with the practical needs of delivery and playback.

Classification

Part ofHEVC
Related approachesDASH

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (6 CRs across 4 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Studied in Rel-8, normative work from Rel-15.

Rel-15 1 change

In Release 15, the specification for the IDR (Instantaneous Decoding Refresh) function clarified decoder behavior for streams not starting with an IDR or IRAP access unit. It mandated that a video decoder shall either begin decoding immediately upon receiving data or, alternatively, no later than receiving the next IDR/IRAP access unit or recovery point SEI message. The decoding process for such a stream was defined to be the same as for a valid video bitstream.

Rel-16 1 change

In Release 16, updates were made concerning the Instantaneous Decoding Refresh (IDR) function, specifically clarifying decoder behavior for streams that do not begin with an IDR or IRAP access unit. The specification now mandates that a video decoder shall either start decoding immediately upon receiving data or, alternatively, no later than the next IDR/IRAP access unit or recovery point SEI message. Furthermore, it was specified that the decoding process for such a stream not starting with an IDR/IRAP must be identical to that of a valid video bitstream.

  • Missing XML Data Type for Attributes in MBMS USD TS 26.346CR0658
Rel-17 1 change

In Release 17, the specification clarified the decoding start behavior for streams not beginning with an IDR/IRAP access unit, explicitly stating the decoder shall start immediately or no later than the next such unit or recovery point SEI message. It also reinforced the rule that only one active picture parameter set is permitted between consecutive IDRs/IRAPs for H.265 (HEVC). Furthermore, it detailed sender requirements to transmit a recovery picture or Gradual Decoder Refresh (GDR) upon receiving a NACK for a lost reference picture.

  • Corrections to DASH quality metric and QoE configuration and reporting TS 26.247CR0178
Rel-19 3 changes

In Release 19, the enhancements for the Instantaneous Decoding Refresh (IDR) function focused on improving error recovery mechanisms within MBMS. Specifically, this was achieved through the introduction of **In-session Unicast Repair for MBMS Object Distribution**, providing a targeted method to recover lost data. This allows for the delivery of recovery pictures or Gradual Decoder Refresh (GDR) upon receiving a NACK message, ensuring faster decoder recovery after packet loss.

  • [AMD_PRO-MED] In-session Unicast Repair for MBMS Object Distribution TS 26.346CR0677
  • [5G_RTP_Ph2] PSI Guidelines for HEVC tiles TS 26.522CR0007
  • Improved Time Synchronization for MBMS TS 26.346CR0672

Explore further

Broader topics and technologies where IDR plays a role.

Defining Specifications

3GPP specifications that define or reference IDR, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TS 26.114 vj10 IMS Multimedia Telephony Media Handling Rel-19
TS 26.223 vj00 IMS Telepresence Client Specification Rel-19
TS 26.234 vj00 3GPP PSS Protocols and Codecs Specification Rel-19
TS 26.247 vj00 3GPP Progressive Download & DASH over HTTP Rel-19
TS 26.346 vj20 MBMS User Services Media Codecs & Protocols Rel-19
TS 26.522 vj30 RTP for XR in 5G Systems Rel-19
TS 26.851 vb20 Enhancements to Multimedia (EMM) for PSS, MMS, MBMS Rel-11
TR 26.906 vj00 HEVC Evaluation for 3GPP Services Rel-19
TR 26.926 vj00 Traffic Models & Quality Evaluation for Media/XR in 5G Rel-19
TR 26.946 vj00 MBMS User Services Overview Rel-19
TR 26.948 vj00 Video enhancements for 3GPP Multimedia Services Rel-19
TR 26.955 vj00 Video Codec Analysis for 5G Services Rel-19
TS 29.163 vj00 Interworking between 3GPP IM CN and CS networks Rel-19