#8343: h261dec doesn't mark keyframes -------------------------------------+----------------------------------- Reporter: Lastique | Owner: Type: enhancement | Status: new Priority: wish | Component: avcodec Version: git-master | Resolution: Keywords: | Blocked By: h261 Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+----------------------------------- Changes (by cehoyos): * priority: normal => wish * version: 4.2 => git-master * type: defect => enhancement * blockedby: => h261 Comment: The patch is ignored here and will not be backported. -- Ticket URL: <https://trac.ffmpeg.org/ticket/8343#comment:1> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

#8343: h261dec doesn't mark keyframes ------------------------------------+----------------------------------- Reporter: Lastique | Owner: Type: defect | Status: new Priority: wish | Component: avcodec Version: git-master | Resolution: Keywords: h261 | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ------------------------------------+----------------------------------- Changes (by Lastique): * type: enhancement => defect Comment: I disagree with "enhancement" qualification, this is a bug. -- Ticket URL: <https://trac.ffmpeg.org/ticket/8343#comment:3> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

#8343: h261dec doesn't mark keyframes -------------------------------------+----------------------------------- Reporter: Lastique | Owner: 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 | -------------------------------------+----------------------------------- Changes (by cehoyos): * type: defect => enhancement -- Ticket URL: <https://trac.ffmpeg.org/ticket/8343#comment:5> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

#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

I frames are not the same as key frames. Only IDR frames are key frames in AVC/HEVC, e.g.

Key frame is not about decoding the frame. It is about decoding all

#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:8 Balling]: frames after the key frame. An I-frame is an IDR-frame if there is no prediction across the I-frame. Which there isn't in the H.261 spec. And in any case, the spec explicitly says the decoder should start displaying pictures starting with the one marked as Freeze picture release. Meaning that it guarantees that further pictures are decodable.

Marking all I frames as key frames is a bug in encoder.

It is not, if the encoder knows/guarantees that I-frames are actual keyframes. -- Ticket URL: <https://trac.ffmpeg.org/ticket/8343#comment:9> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

#8343: h261dec doesn't mark keyframes -------------------------------------+----------------------------------- Reporter: Lastique | Owner: (none) Type: enhancement | Status: closed Priority: wish | Component: avcodec Version: git-master | Resolution: fixed Keywords: h261 | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+----------------------------------- Comment (by Balling): Fixed in cf1c52c5c6cc82a27080fdaee53354f026401c7f Yay -- Ticket URL: <https://trac.ffmpeg.org/ticket/8343#comment:11> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker