[FFmpeg-devel] [PATCH] set flags and stuff required for XvMC instead of just checking them
Reimar Döffinger
Reimar.Doeffinger
Sun Feb 15 19:08:22 CET 2009
On Sun, Feb 15, 2009 at 06:24:59PM +0100, Michael Niedermayer wrote:
> On Sun, Feb 15, 2009 at 05:47:42PM +0100, Reimar D?ffinger wrote:
> > On Sun, Feb 15, 2009 at 05:20:41PM +0100, Michael Niedermayer wrote:
> > > well the slice flags specify the limitations of the user app,
> > > if mplayers limitations between xvmc and normal vo differ this is
> > > mplayers problem.
> >
> > Well, as long as that check (which fails hard) is there in FFmpeg it
> > is not just a limitation of the user app, and it wouldn't help a bit if
> > MPlayer's XvMC supported the format that not setting SLICE_FLAG_CODED_ORDER
> > would produce.
>
> remove the check from xvmc if you like, but keep in mind that hw decoding
> cannot be done without SLICE_FLAG_CODED_ORDER.
I will think about it some more, I'll see about it once the code is
ready to do acceleration selection on get_format (I hope the MPlayer
part is close, not so sure about FFmpeg, maybe mis-/reusing
xvmc_acceleration to replace CODEC_CAP_HWACCEL etc. is the best approach).
> > > you can just always set the slice flags if it works, it should be
> > > faster
> >
> > SLICE_FLAG_CODED_ORDER doesn't work.
>
> i faintly remember that this was possible in the distant past when arpi
> was still leading mplayer ...
> you are sure you dont draw the slices in the wrong pic?
Certainly it draws them in the wrong pic (that's easily visible), and I do
not know how it should ever have worked since in libvo the function prototype is:
> static int draw_slice(uint8_t *src[], int stride[], int w,int h,int x,int y)
More information about the ffmpeg-devel
mailing list