[Ffmpeg-devel] one slice at the time rendering w/o callback
Sat Nov 19 16:53:44 CET 2005
On Sat, Nov 19, 2005 at 02:00:56AM +0200, Ivo wrote:
> On Sunday 13 November 2005 18:44, Ivo wrote:
> > I was looking into a way to have avcodec render one slice at the time
> > without making use of the draw_horiz_band callback. AFAICS, that's
> > currently not possible. I would like to have a uniform api, i.e. request a
> > slice, process it, request next slice, etc... similar to requesting a full
> > frame in non-sliced mode.
> > Now my question is, which way should I go? I see several options:
> > 1) add a new function to AVCodec and have an implementation for all
> > codecs that do slices, plus add an avcodec_decode_video like wrapper in
> > utils.c (avdecode_decode_video_slice or something)
> > 2) add a 'one-slice-at-the-time' flag to AVCodec, and have the caller
> > call avcodec_decode_video multiple times
> Does anybody have something to say about this?
> I gave it a litlle more thought, and I think option 1 is the cleanest way.
> For that, I need to split up avcodec_decode_video into three parts, namely,
> pre-decode-slices loop, decode-slices loop and post-decode-slices loop. The
> new avcodec_decode_video will call the "pre" function, do the decode slices
> loop (or return prematurely if it would have done so now) and call the
> "post" function.
> The new avcodec_decode_slice will call the pre-function, decode one slice
> and only call the post-function if all slices are done. Its API will be
> similar to decode_video, but with an extra argument called got_slice (like
> got_picture). got_slice will be set if a slice was succesfully decoded and
> got_picture will only be set if all slices are decoded. The caller can
> check that to see if all slices are done. At the last call for a particular
> frame, it will return the bytes consumed like decode_video does.
> Any comments? Like, go ahead. Or, you're dumb, that will never work? :)
one problem is one of terminology, there are 2 things which are
1. a "chunk" of the bitstream which when decoded could cover anything
from a single 16x16 macroblock to the whole frame in raster scan order
normaly (h264 allows arbitrary order, and field pictures in mpeg2/h264
would be made of slices which contain only even or odd lines) but then
again these rare cases can be dealt with by simply decoding all slices
and pretending that the image is made of a single slice, still i wanted
to mention them ...
2. a rectangle of pixels from the left to the right border of a picture
More information about the ffmpeg-devel