On Tue, Nov 08, 2011 at 03:47:31PM +0600, Mashiat Sarker Shakkhar wrote: > The current code is a generalization of the earlier progressive MV > prediction code. This was supposed to predict MVs for both interlaced > and progressive pictures. But the interlaced MV prediction is buggy > and works mostly by luck.
Nobody likes interlaced modes, eh? > This partially fixes interlaced MV prediction. > --- > libavcodec/vc1dec.c | 189 > ++++++++++++++++++++++----------------------------- > 1 files changed, 80 insertions(+), 109 deletions(-) > > diff --git a/libavcodec/vc1dec.c b/libavcodec/vc1dec.c > index e389040..3253292 100644 > --- a/libavcodec/vc1dec.c > +++ b/libavcodec/vc1dec.c > @@ -1475,12 +1475,10 @@ static inline void vc1_pred_mv(VC1Context *v, int n, > int dmv_x, int dmv_y, > int px, py; > int sum; > int mixedmv_pic, num_samefield = 0, num_oppfield = 0; > - int opposit, f; > - int16_t samefield_pred[2], oppfield_pred[2]; > - int16_t samefield_predA[2], oppfield_predA[2]; > - int16_t samefield_predB[2], oppfield_predB[2]; > - int16_t samefield_predC[2], oppfield_predC[2]; > - int16_t *predA, *predC; > + int opposit, a_f, b_f, c_f; nit: oppositE and while the patch looks reasonably good I wonder if it's not better to split MV prediction for progressive and interlaced cases _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
