Talk:Video compression picture types

Merging with video compression section
A merge tag has just been added to this article suggesting it be merged with video_compression, I'm just noting that I feel that the topics of this page are distinct enough that the warrant being separate. AlyM 21:04, 22 August 2006 (UTC)

If they are distinctly different things, then yes, they need different articles. But I fail to see the difference between "intraframe and interframe compression" and "I pictures, P pictures, and B pictures".

The merge tag is ambiguous. It could suggest either
 * move the B pictures article into the video_compression article, and make B pictures a redirect into the video_compression article
 * move the video_compression section of the video_compression article into the B pictures article, leaving behind a short summary and a Template:Main link to the B pictures article.

Which option would you prefer? --70.189.73.224 14:39, 2 September 2006 (UTC)

I also simply oppose the merge suggestion (agreeing with AlyM above). They are different topics. It is possible, for example, to do interframe compression without using I, P or B pictures. Many wavelet-based or 3-D transform video compression designs do that. Maybe one article or another (or both) could use some improvement, and perhaps the video compression article should contain some reference to this article and vice versa, but merging those articles doesn't sound like the right way to accomplish the improvement. -Mulligatawny 22:21, 5 October 2006 (UTC)

I have tried to sort of link this into the video codecs article, and this article, honestly, should probably make its way at least in summary form onto that page as well. Since I don't entirely understand this article, I feel severely under qualified to be the one that does this. -Evan (06/04/07)

Possibly incorrect article title
The title and first paragraph appear to be at odds with the rest of this article. The article gives information about all three frame types, yet the title only relates to B-Frames. Also, confusingly, I-frame and P-frame redirect here. I propose the article be renamed to Video compression picture types, Video picture types or Video frame types --Ozhiker 15:45, 29 November 2006 (UTC)

I agree. This article is about more than B pictures. I had been thinking of changing the name to "I pictures, P pictures, and B pictures." A new first paragraph might be:


 * "The three major picture types found in typical video compression designs are I(ntra) pictures, P(redicted) pictures and B(i-predictive) pictures (or B(i-directional) pictures). They are also commonly referred to as I frames, P frames, and B frames.  In older material, the term "bi-directional" rather than "bi-predictive" is dominant."

Ivar Y 17:44, 29 November 2006 (UTC)

Why? Example?
To me it is not clear why one or some B frames before the next I-frame improve compression, generally. I can image special situations like transition effects in a NLE or something woshing across the screen possibly blurred and too close the camera. Then after the woosh or the transition effect an I frame would be inserted and the frames would be predicted into the woosh or the transition effect from both sides. --Arnero (talk) 12:49, 10 May 2010 (UTC)


 * I think it is because I-frames often occur at set intervals, so you cannot just add an I-frame where a transition occurs. Depends on the format of course. --Petteri Aimonen (talk) 21:32, 10 May 2010 (UTC)


 * I-frames need to be placed at regular intervals only on some transports (e.g. optical media, live streams) and only to aid seeking/trick-modes and/or stream switching (and there are techniques other than using regular I-frames to deal with that). However, that's not the real benefit.
 * The main problem is that with most video compression formats, the compression techniques used for I-frames usually differ from those used by other frames such as P-frames, such that below a certain quality threshold, the artifacts introduced by the two frame types can differ by quite a lot. Therefore, when a relatively static sequence is encoded as consecutive P/B-frames followed immediately by an I-frame, there will be a noticeable quality "pop" as certain artifacts appear or disappear abruptly. However, using B-frames before this next I-frame smooths out these pops, since B-frames essentially interpolate between two frames, making the transition much smoother and less noticeable. C xong (talk) 05:28, 27 July 2010 (UTC)


 * Regular intervals (or at least max intervals) are needed in most practical applications. Tuning to a new channel on the TV. Seeking on the DVD or youtube. Preview images on the timeline of the video editor. GOP for cutting. Also, if the GOP consists of over 20 pictures, they do not hurt compression that much. How do we change the article? Like this?:
 * Typically every 30th frame is an so I-frame saved without any reference to other frames. From every I-frame the frames are predicted forward and backwards. The forward and backward prediction from two consecutive I-frames meet each other at some point. The encoder chooses a point across which motion compensation does not work well. The frames around this point are encoded at lower quality level since they are not referenced by other frames. To hide the forward to backward transition and to account for spatial differences in the success of motion compensation, each macro block has its own transition point in time. --Arnero (talk) 12:33, 10 August 2010 (UTC)

History
I'd love to see some more history, such as when P/B-frames were first developed, by whom, and early notable implementations and their impact on industry. C xong (talk) 05:32, 27 July 2010 (UTC)

Regarding merge
I do not understand merging with an article bigger then the article being merge into. I am declining this, if you want you can put that back. -- Hinata  talk  16:57, 8 January 2011 (UTC)

Datamoshing
Should datamoshing be mentioned? It is accomplished by removing I-frames to achieve the effects in Kanye West's "Welcome to Heartbreak" and Chailift's "Evident Utensil". -38.99.161.194 14:23, 8 February 2011 (UTC) —Preceding unsigned comment added by 38.99.161.194 (talk)

Merging with Intra-frame
The suggestion to merge Intra-frame into this article from 2011-06 is unrelated to the discussion in 2006. Anyway, it spooked me when ffmpeg "failed" to extract proper WebP pictures from WebM, until I figured out that I need option  to get the key frames. If the suggested merge helps to grok this, please do. Otherwise 2011 is stale. –89.204.138.164 (talk) 23:48, 21 January 2014 (UTC)

Possible incoherence in B slice specification in H264 video
Reading the following book "H.264 and MPEG-4 Video Compression" (ISBN: 0-470-84837-5) i noticed that the meaning of B frame in the H264 specification is a bit different from what is explained in this article. In the book is specified that B-Slices "Contains B macroblocks (each macroblock or macroblock partition is predicted from a list 0 and/or a list 1 reference picture) and/or I macroblocks." , looking up in the same book the definition for List 0 and 1 we can read

– List 0: The closest past picture (based on picture order count) is assigned index 0, followed by any other past pictures (increasing in picture order count), followed by any future pictures (in increasing picture order count from the current picture).

– List 1: The closest future picture is assigned index 0, followed by any other future picture (in increasing picture order count), followed by any past picture (in increasing picture order count).

The reason why is specified that B slice are the only one able to predict future frame is due to the encoding scheme used to encode the index inside this lists, in particular: "The selected buffer index is sent as an Exp-Golomb codeword (see Section 6.4.13.1) and so the most efficient choice of reference index (with the smallest codeword) is index 0 (i.e. the previous coded picture in list 0 and the next coded picture in list 1)."

Why are they called I frames?
B frames is short for "bi-directional predictive" and the P frames is short for "predictive". So what the heck is I frames short for? Nobody has mentioned this in the article or in the talk here. I would expect it to mean "Index frames" but I'm not adding that until someone confirms it. --Rj.amdphreak (talk) 08:54, 11 March 2023 (UTC)2600:1700:B281:3830:7969:4DEF:ABA6:58B5 (talk) 08:51, 11 March 2023 (UTC)


 * mmm idk 186.12.32.134 (talk) 05:31, 29 April 2023 (UTC)