[Ffmpeg-devel] Embedded preview vhook/voutfb.so /dev/fb

[Marc Hoffman]

Michael Niedermayer writes:
 > Hi
 > 
 > On Sun, Apr 01, 2007 at 11:31:06AM +0900, Bobby Bingham wrote:
 > > Rich Felker wrote:
 > > >On Fri, Mar 30, 2007 at 02:07:12PM +0800, Bobby Bingham wrote:
 > > >>>Now, on to picture sequence filters....
 > > >>>
 > > >>>These would be similar to picture filters, but also have an amount of
 > > >>>necessary 'context' along the time axis, i.e. a number of past and
 > > >>>future frames that need to be available in order for the filter to
 > > >>>operate. Again, what to do when the in/out correspondence isn't
 > > >>>one-to-one is a little tricky. Perhaps mimic the way scaling ends up
 > > >>>working along the spatial axes...
 > > >>>
 > > >>Is there any reason the picture filters can't just be a picture
 > > >>sequence filter with temporal context = 0?
 > > >
 > > >They could, but the idea was to have a simpler filter-writing API for
 > > >pure picture filters where it doesn't have to know anything about the
 > > >idea of "frames" or "sequence".
 > > >
 > > >Also it's possible that a filter operating on sequences of frames
 > > >could need to see them in-order, even if it doesn't explicitly need
 > > >context to be able to look back at old frames. For example it might
 > > >remember the brightness of the previous frame internally, or remember
 > > >a phase (in inverse telecine or phase shifting), etc..
 > > >
 > > >Or if it's a temporal blur, it might remember the sum/average of the
 > > >past few frames in an internally-kept buffer (or a permanent output
 > > >buffer), rather than having to re-sum them from context each time.
 > > >This is the time-dimension analogue of what Michael was talking about
 > > >with boxblur and slices. :)
 > > 
 > > Okay.
 > > 
 > > I've started looking at the source for some of the simple libmpcodecs 
 > > filters, as well as reading DOCS/tech/libmpcodecs.txt (does someone know 
 > > off-hand if this is up to date?). I haven't looked at much of the actual 
 > > libmpcodecs code itself yet though, so many of these questions could 
 > > probably be answered by looking there first. But while we're on the 
 > > topic, it might be faster to ask here.
 > > 
 > > How does libmpcodecs handle slice order?  Does it guarantee any specific 
 > > order?  Actually, backing up a step, I know slice size is codec defined 
 > > - I assume order is too?  What orders are common, if any?  And sizes - 
 > > do slices generally correspond to the entire image width?  Or are 
 > > smaller widths common too?
 > 
 > ok, these things arent documented/specified anywhere IIRC, slice height
 > can be anything and also is in practice, slice width is always picture
 > width (some (most/all?)) filters would break if they would be feeded
 > with smaller slices, hell i dont even remember if the API completely
 > supports smaller slices ...
 > 
 > i thought slice order is always top to bottom that is 
 > (buf + y*linesize with y=0...height even for negative linesize) but it
 > seems vf_scale contains code to handle bottom->top too so iam not sure
 > if that used or not, other orders though will not work with scale and
 > i am pretty sure nothing output slices in a different order from
 > top<->bottom
 > 
 > 
 > [...]
 > > I also want to ask about the motivation for treating full frames and 
 > > slices differently in libmpcodecs.  Obviously slices have the benefit of 
 > > being small and fitting in cache - but is there any reason for having 
 > > separate APIs for both of them (put_image() vs draw_slice())?  At first 
 > > glance, it seems to me that if a filter requires full frames, it could 
 > > still be passed in the form of a single, frame-sized slice.  That would 
 > > have the benefit that filters that support both frames and slices could 
 > > implement just draw_slice() instead of implementing the same operations 
 > > again in put_image().
 > 
 > well i dont know, maybe theres no reason or need for draw_slice + put_image
 > 
 > [...]
 > -- 

I gave a poke at the configuration for this and attempt to build this
lots of stuff is undefined maybe I can atleast get this library
compiled and linked into ffmpeg.  Has anyone started this (am I
wasting my time please hold back on the sarcasm)?

Marc