[Ffmpeg-devel] Embedded preview vhook/voutfb.so /dev/fb
Sun Apr 1 11:56:43 CEST 2007
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. :)
> 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
> 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
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the ffmpeg-devel