Commen=
t # 13
on bug 71812<=
/a>
from Fabrice Bellet
About this specific bug this time :)
I see a deterministic corruption in your sample too, that seems related to =
the
presence of sprite frames in the stream, and the result looks like these S
frames are just ignored by the hardware decoder (they are correctly passed =
to
the mesa level).=20
For example, an effect of the corruption is the "C" of Captain, t=
hat is warped
into something that looks like the euro symbol (=E2=82=AC), around 22.5s. I=
s it similar
to what you observe ? I can provide screenshot if needed.
I tried with VDPAU on radeonsi/uvd, with nouveau, and also with the proprie=
tary
nvidia VDPAU implementation. _All_ implementations have this problem. The
radeon and the nvidia driver just silently drop S frames, and the following
non-S frames are corrupted. The nouveau driver replaces S frame by something
that looks like the rendering of an unintialized vmem buffer.
Also, I can reproduce the _same_ corruption with the ffmpeg software mpeg4
decoder, just by disabling the S-frames handling with this patch:
diff -uNrp ffmpeg-2.1.5.orig/libavcodec/mpeg4videodec.c
ffmpeg-2.1.5/libavcodec/mpeg4videodec.c
--- ffmpeg-2.1.5.orig/libavcodec/mpeg4videodec.c 2014-07-21
20:43:58.550548835 +0200
+++ ffmpeg-2.1.5/libavcodec/mpeg4videodec.c 2014-07-21 20:43:11.632103072
+0200
@@ -2105,6 +2105,8 @@ static int decode_vop_header(MpegEncC=
ont
}
if(s->pict_type =3D=3D AV_PICTURE_TYPE_S &&
(s->vol_sprite_usage=3D=3DSTATIC_SPRITE || s->vol_sprite_usage=3D=3DG=
MC_SPRITE)){
+ printf("S frame\n");
+ return AVERROR_INVALIDDATA;
if (mpeg4_decode_sprite_trajectory(s, gb) < 0)
return AVERROR_INVALIDDATA;
if(s->sprite_brightness_change) av_log(s->avctx, AV_LOG_ERR=
OR,
"sprite_brightness_change not supported\n");
Are sprite frames supposed to be decoded by the hardware ? The radeon driver
has a sprite-related section in its ruvd_mpeg4 struct definition in
mesa/src/gallium/drivers/radeon/radeon_uvd.h.