On 2019-10-26 15:49, Carl Eugen Hoyos wrote:
Am Sa., 26. Okt. 2019 um 13:12 Uhr schrieb Andrey Semashev
<andrey.semas...@gmail.com>:
The decoder never marks pictures as I-frames, which results in no
keyframe indication and incorrect frame skipping, in cases when
keyframes should be decoded.
This commit works around this decoder limitation and marks I-frames
and keyframes based on "freeze picture release" bit in h261 picture
header. This reflects h261enc behavior.
diff --git a/libavcodec/h261dec.c b/libavcodec/h261dec.c
index 14a874c45d..3b1711a21d 100644
--- a/libavcodec/h261dec.c
+++ b/libavcodec/h261dec.c
@@ -502,9 +502,9 @@ static int h261_decode_picture_header(H261Context *h)
s->avctx->framerate = (AVRational) { 30000, 1001 };
/* PTYPE starts here */
- skip_bits1(&s->gb); /* split screen off */
- skip_bits1(&s->gb); /* camera off */
- skip_bits1(&s->gb); /* freeze picture release off */
+ skip_bits1(&s->gb); /* split screen indicator */
+ skip_bits1(&s->gb); /* document camera indicator */
+ h->freeze_picture_release = get_bits1(&s->gb); /* freeze picture release */
format = get_bits1(&s->gb);
@@ -532,7 +532,8 @@ static int h261_decode_picture_header(H261Context *h)
/* H.261 has no I-frames, but if we pass AV_PICTURE_TYPE_I for the first
* frame, the codec crashes if it does not contain all I-blocks
- * (e.g. when a packet is lost). */
+ * (e.g. when a packet is lost). We will fix the picture type in the
+ * output frame based on h->freeze_picture_release later. */
s->pict_type = AV_PICTURE_TYPE_P;
Why can't you use freeze_picture_release here?
The comment says the decoder may crash on some input. I don't know if
this is true and I don't have any test files not produced by ffmpeg
itself to test.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
