#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
_______________________________________________
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-trac
To unsubscribe, visit link above, or email
ffmpeg-trac-requ...@ffmpeg.org with subject "unsubscribe".
