[MPlayer-dev-eng] video filter layer

[Michael Niedermayer]

Hi

On Sat, Apr 21, 2007 at 09:41:33PM +0900, Bobby Bingham wrote:
> Michael Niedermayer wrote:
> > * many parts are undocumented and noone really understands the whole
> >   libmpcodecs, RTFS also doesnt help as the authors of various filters
> >   might have had a different idea on how things work ...
> 
> fun
> 
> > direct rendering with slices is "fun"
> > 
> > the problem is that while frames are output in display order from codecs
> > (at least all current codecs behave that way, ...) slices are output
> > for the currently coded frame which is generally a future frame
> > 
> > so for example a filter (independant of the filter API) would get with 
> > a common mpeg2 (IBBPBBP) video
> > 
> [snip coded frame order]
> 
> I've thought a little about this.  Here's the idea I have at the moment:
> 
> Obviously, some filters need frames in display order (temporal blur,
> probably ivtc, though I admit to not understanding much about it, etc).
>  Certainly the final video output or video encoder does.  But there are
> plenty of simpler filters which can operate in any order (crop, scale,
> spatial blur, etc).  Let the filters specify if they require display
> order or not.  All filters before the first display-order-only
> filter/video output can be processed in the order they come out of the
> decoder.
> 
> After that, the frames would need buffered until we can output them to
> the remaining filters in display order (I assume the API provides a way
> to know when you've gotten the next frame in display order?  I haven't
> looked at that part of the code yet).  This would be handled
> automatically by the filter system.

libmpcodecs assumes that if reordering is done then its always mpeg1/2/4
IP(B) style, this of course fails fatally with h.264


> 
> Of course, by buffering the frames like that, we probably push the data
> out of the cache and lose some of the benefit of slices.  On the other
> hand, there's no reason I see that the reordered frames can't be split
> up and processed as slices for the rest of the filters.
> 
> But then, maybe it's faster to do the reordering at the beginning, and
> run all the frames through the filters as slices in display order?

> Might be worth benchmarking.

yes, it should also be easy to simply have a generic "slicify" filter
which just turns the input frames into slices for the next filters

also current libavcodec does
*request buffers in coded order (it of course has to)
*output slices in coded order (it could fairly easily also output
 them in display order but its not supported currently IIRC, and it
 might be slower ...)
*output buffers in display order (even if slices are used though adding
 support for coded order output shouldnt be hard if theres some advantage
 for it)
*dont gurantee that the output buffer contains proper data if slices where
 enabled (it reusees a single slice for all slices if possible)


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20070421/e94b56b6/attachment.pgp>