Email Newsletter
Like what you just read? Subscribe to receive the latest articles and resources from the Streaming Learning Center.


Everything You Ever Wanted to Know About IDR Frames but Were Afraid to Ask

Depending upon your encoding tool, you may have access to a checkbox or number box that controls something called IDR frames. What are these creatures and what is their significance? More imporantantly, what's the optimal setting? Well, let's just say that if you're seeing anything like the random blockiness in the picture below when you drag the playhead back and forth in the video window, you're probably using the wrong value.

IDR-ugly.jpg

Read on and I'll tell you why and identify the correct value.

What's An IDR Frame?

Here's the definition of IDR frame from Iain E. G. Richardson's excellent H.264 and MPEG-4 Video Compression book.

An encoder sends an IDR (Instantaneous Decoder Refresh) coded picture (made up of I- or SI-slices) to clear the contents of the reference picture buffer. On receiving an IDR coded picture, the decoder marks all pictures in the reference buffer as ‘unused for reference’. All subsequent transmitted slices can be decoded without reference to any frame decoded prior to the IDR picture. The first picture in a coded video sequence is always an IDR picture.

For less-technical audiences, here's another definition from a Harmonic White Paper entitled Advanced H.264 Encoding with Carbon Coder.

An IDR frame is a special type of I-frame in H.264. An IDR frame specifies that no frame after the IDR frame can reference any frame before it. This makes seeking the H.264 file easier and more responsive in the player.

There's some confusion in the marketplace about the difference between I-frames and IDR frames. The short answer is that every IDR frame is an I-frame, but not vice versa, so there can be I-frames that aren't IDR frames. When you're producing for streaming, that's when you can run into problems.

Simply stated, if all I-frames are not IDR frames, you can see the distortion shown in the figure above if you drag back and forth in the file. As an example, I produced the video file immediately below with no IDR frames. If you drag back and forth enough times, you'll see distortion like that shown in the frame grab above.

No-IDR

I'm not sure why this occurs, but I produced the next video with every I-frame an IDR frame, which is what I recommend in my book, Video Compression for Flash, Apple Devices and HTML5.

All-IDRYou can drag through this file from noon until night, and the frames won't ever get distorted.

What's the right setting?

Well, in case you missed the not-so-subtle pitch for my book above, when you're encoding for streaming, every I-frame should be an IDR-Frame.

Here's what the relevant control looks like in Promedia Carbon (formerly Carbon Coder).

carbon setting.jpg

Here's the recommendation from the aforementioned Rhozet white paper. "Unless the target playback device requires a different value, this setting should also be set to 1 (every I-frame is an IDR frame)." Using the settings shown in the screen shot, you would get a minimum IDR interval of 1 (so the first I-frame in the video is an IDR frame) and every I-frame thereafter would also be an IDR frame.

And here's the I-frame related control in Telestream Episode.

episode-idr-setting.png

Here's the recommendation from the Telestream Episode help file:

More distant IDR frames may allow more efficient compression but limits the ability of a player to move to arbitrary points in the video. In particular, QuickTime Player may show image artifacts when you scrub the timeline unless every I-frame is an IDR frame.

And here's what the IDR control looks like in Sorenson Squeeze 8.

squeeze-idr-setting.png

Use the value shown and you'll avoid the problems seen in the figure above and the first video.


Comments (12)

Said this on 12-28-2011 At 11:19 am

Great stuff Jan, thanks for sharing. I had no idea what IDR stood for.

Said this on 12-28-2011 At 12:27 pm
Great, glad you found it helpful, thanks for taking the time to comment.

Have a great new years.

Jan
KARTIK PODUGU
Said this on 6-13-2012 At 01:55 am

Very good explanation. Now, i will never get confused between and IDR frame and I frame. Thanks

Said this on 6-13-2012 At 07:03 am
Glad you found it useful. Thanks for taking the time to leave a note.

Jan
Tom Cook
Said this on 2-22-2013 At 06:35 am

I just found this thread via a search.  Now I'm really confused.  What the article say is an IDR, I thought that's what an I-frame is; independent of all prior and future frames.  If some I's are not IDR's, then what the heck is an I-frame?  I'm coming to this from the world of Mpeg2 where an I-frame is totally independent from surrounding frames.  And if an I-frame is NOT independent, then what differs that from a P or B??

Said this on 2-25-2013 At 12:29 am
Tom:

There are two kinds of I-frames; IDR and non-IDR. Neither refers to any other frames, BUT, P and B frames can use frames before Non-IDR frames for reference. They can't use frames before IDR frames for reference. Sorry I didn't make it clearer; does this help?

LMK.

Jan
Tom Cook
Said this on 2-25-2013 At 12:40 am

Thanks Jan.  Between your comments and my own further thinking, I think it is clearer.  I had been thinking in terms of I-frames being self-contained, that is they don't need to reference other frames to be rendered.  But even in Mpeg2 (once I thought about it), self-contained doesn't mean OTHER frames don't reference it.  An I-frame followed by a P is complete (self-contained).  BUT the P does reference it, so it's not IDR.  And likewise if an I is *preceded* by a B, the I is not an IDR.  I remember the option to CLOSE the GOPs by not ending with a B.  I never did it, but I understood it.  (And I'm now remembering it, after years of no contact w/the subject.)

Said this on 2-25-2013 At 12:43 am
Glad we got that cleared up for you. It is confusing.

Thanks for asking the question; if it was on your mind, I'm sure it was on lots of others.

Jan
JT
Said this on 1-24-2013 At 11:22 am

Thanks for explaining it so nicely. I have a question though, what are the other adverse results we can expect other than distortion (when scrubbing the timeline) when each iFrame is not an IDR frame? If video Advertisements are inserted in content both the videos have to be IDR frames?

Thanks in advance

Jt

Said this on 1-24-2013 At 01:13 pm
JT:

Not sure what you're saying. Do you need non-IDR frames for video advertising to work? The distortion was the only problem I encountered, but that was enough for me.

Jan
Said this on 1-24-2013 At 05:21 pm

Jan

I am wondering what happens if non-IDR frame video AD is inserted in IDR frame content and it streamed through.

Thanks

Jt

Said this on 1-25-2013 At 10:15 am
I'm still not getting it. These things happen on completely different levels; advertising is applied long after the encoding.

Are you experiencing an actual problem or just concerned that you may experience one down the road. Most encoders make every I-frame an IDR frame, so I can't imagine you'll have one. I wrote this post because some encoders do give you the option, and that it's essential to make every I-frame an IDR frame for the reasons stated. Since this is what most other sites also advise, I can't imagine it would cause a problem with advertising insertion.

I could be wrong, but it sounds unlikely.

Jan
Post a Comment
* Your Name:
* Your Email:
(not publicly displayed)
Reply Notification:
Approval Notification:
Website:
* Security Image:
Security Image Generate new
Copy the numbers and letters from the security image:
* Message: