[FFmpeg-trac] #8343(avcodec:open): h261dec doesn't mark keyframes

[FFmpeg]

#8343: h261dec doesn't mark keyframes
-------------------------------------+-----------------------------------
             Reporter:  Lastique     |                    Owner:  (none)
                 Type:  enhancement  |                   Status:  open
             Priority:  wish         |                Component:  avcodec
              Version:  git-master   |               Resolution:
             Keywords:  h261         |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-----------------------------------
Comment (by Lastique):

 Replying to [comment:6 Balling]:
 > I have a concern here from the code
 02b7c630875c0bc63cee5ec597aa33baf9bf4e20
 >
 > They say that they mark all I frames as key frames, even those that
 start the GOP. Is it possible in ancient H261 for such a frame to not be a
 key frame?

 This is not a question about the spec but rather the encoder
 implementation (i.e. h261enc.c).

 The H.261 spec defines two modes of coding, INTER and INTRA. The latter
 ones do not use inter-frame prediction and frames entirely coded in this
 mode pretty much are what is understood as I-frames in the more modern
 MPEG codecs. The INTER mode uses motion compensation (MC) which references
 the previously coded picture. Pictures entirely coded in this mode are
 similar to the modern P-frames. I do not think the spec restricts the
 encoder to use only one mode for coding the entire picture, and in fact
 the spec doesn't specify pretty much anything about the encoder behavior.

 But it does specify that upon a Fast update request (4.3.2) the encoder
 uses INTRA mode to encode the next **picture** and then uses the Freeze
 picture release (4.3.3) to signal the decoder that it may exit the freeze
 mode and start displaying decoded pictures after this one.

 So, really, if the ffmpeg encoder always uses INTRA mode to encode entire
 pictures that were requested as AV_PICTURE_TYPE_I by the caller (or
 selected by the encoder as such), it has every reason to also mark these
 frames as Freeze picture release.

 Respectively, if a decoder is seeing a Freeze picture release-marked
 frame, per H.261 spec, it should trust the encoder and assume this is an
 INTRA-only-coded picture and, in case of libavcodec, mark it as
 AV_PICTURE_TYPE_I and a keyframe. Which is what this patch does.
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/8343#comment:7>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker