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

[Michael Niedermayer]

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

[...]
-- 
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
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070401/d6fe71a8/attachment.pgp>