[FFmpeg-devel] [PATCH]Fix MPlayer VC1 vdpau decoding
Thu Feb 26 12:34:12 CET 2009
On Thu, Feb 26, 2009 at 09:28:30AM +0100, Gwenole Beauchesne wrote:
> On Wed, 25 Feb 2009, Michael Niedermayer wrote:
> >> Index: libmpcodecs/vd_ffmpeg.c
> >> ===================================================================
> >> --- libmpcodecs/vd_ffmpeg.c (revision 28734)
> >> +++ libmpcodecs/vd_ffmpeg.c (working copy)
> >> @@ -916,7 +916,7 @@
> >> avctx->draw_horiz_band = draw_slice;
> >> mp_msg(MSGT_DECVIDEO, MSGL_INFO, MSGTR_MPCODECS_XVMCAcceleratedMPEG2);
> >> assert(ctx->do_dr1);//these are must to!
> >> - assert(ctx->do_slices); //it is (vo_)ffmpeg bug if this fails
> >> +// assert(ctx->do_slices); //it is (vo_)ffmpeg bug if this fails
> >> avctx->slice_flags=SLICE_FLAG_CODED_ORDER|SLICE_FLAG_ALLOW_FIELD;
> >> }
> >> return selected_format;
> > why is this change needed but wasnt before?
> Most likely VC-1 decoding was not tested since it was not widely available
> at that time. IIRC, do_slices is set if CODEC_CAP_DRAW_HORIZ_BAND is set
> in the codec, which VC-1 doesn't.
> Would any of the following be correct?
> - Set the flag for VC-1 et al.
> - Set do_slices if hwaccel, as it would/were the case for do_dr1?
> The latter sounds more practical.
i was just asking "why?" i didnt reject it. If it never worked with that
assert() then its removial is likely fine.
I just thought "hey why is this commented out now? how could a recent
change have made that needed?"
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel