[FFmpeg-devel] [PATCH] set flags and stuff required for XvMC instead of just checking them
Sun Feb 15 19:32:08 CET 2009
On Sun, Feb 15, 2009 at 07:21:38PM +0100, Reimar D?ffinger wrote:
> On Sun, Feb 15, 2009 at 07:16:24PM +0100, Michael Niedermayer wrote:
> > On Sun, Feb 15, 2009 at 07:08:22PM +0100, Reimar D?ffinger wrote:
> > > On Sun, Feb 15, 2009 at 06:24:59PM +0100, Michael Niedermayer wrote:
> > [...]
> > > > > > 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)
> > i dont see how the function prototype would have prevent slices in coded order
> It provides no information whether they are in coded order or not, nor
> does it indicate a place where to write the data.
> If you mean it could have been hard-coded to assume coded order, I guess
> that's possible, but would only work for MPEG2 without additional
that was prior to h264 :)
and yes iam pretty sure it was hardcoded
> hacks, and would (AFAICT) not work for libmpeg2.
this brings up an interresting thought, are you sure vd_libmpeg2
does not use coded order slices?
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel