On Tue, May 14, 2013 at 12:21:31PM +0300, Martin Storsjö wrote: > From: Michael Niedermayer <[email protected]> > > Fixes read of uninitialized memory. > > --- > In a comment on github, Mashiat wrote: > --- > In-loop filtering process is same for both progressive pictures > and interlaced field pictures, if the difference in stride is > accounted for. Interlaced frame picture has it's own process > defined and needs to be implemented. If I remember correctly, > SA10143 consists of interlaced field pictures, so in-loop > filtering mechanism should be the same. > > Unless someone steps forward to fix the existing code to account > for stride so that it works on both progressive and interlaced > field pictures, this patch is an acceptable compromise. I just > wanted the above fact to be noted. > --- > --- > libavcodec/vc1dec.c | 2 +- > tests/ref/fate/vc1_sa10143 | 58 > ++++++++++++++++++++++---------------------- > 2 files changed, 30 insertions(+), 30 deletions(-) > > diff --git a/libavcodec/vc1dec.c b/libavcodec/vc1dec.c > index 994f5df..7714113 100644 > --- a/libavcodec/vc1dec.c > +++ b/libavcodec/vc1dec.c > @@ -4650,7 +4650,7 @@ static void vc1_decode_p_blocks(VC1Context *v) > if (s->mb_y != s->start_mb_y) ff_mpeg_draw_horiz_band(s, (s->mb_y - > 1) * 16, 16); > s->first_slice_line = 0; > } > - if (apply_loop_filter) { > + if (apply_loop_filter && v->fcm == PROGRESSIVE) { > s->mb_x = 0; > ff_init_block_index(s); > for (; s->mb_x < s->mb_width; s->mb_x++) {
There's a similar condition twenty lines above. Why not simply modify apply_loop_filter at the beginning to account for v->fcm as well and drop && v->fcm == PROGRESSIVE from there instead? The approach looks good though (and the spec defines special loop filtering for interlaced frames only indeed). _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
