Re: Re: Re: Encoder-decoder interface question.

Forwarded to uci-devel at lists sourceforge dot net for comments from Alex
Stewart

"Lourens Veen" <[email protected]> schrieb im Newsbeitrag
news:[email protected]...
On Friday 18 October 2002 12:26, Kondoros Attila wrote:
> --- ChristianHJW <[email protected]>
> wrote:
> > "Kondoros Attila" <[email protected]>
>
>   As I see it if it allows more than 1 frame at a time
> it will be ok. But I cannot comment more deeply about
> the 3D wavelet (not enough backdround on them), maybe
> others can step in to "enlighten" us...

Well, I didn't write the 3D wavelet code, but I can comment on it.
Basically what happens is that the codec takes a 3D block of pixels
(I think it's currently 32 frames or so), performs a 3D wavelet
transform on it, quantises the resulting coefficients, entropy
encodes them, and writes them to the stream.

For the interface, this means that there has to be a way for the
codec to buffer up and have access to 32 frames of data at a time.
I skimmed through the UCI docs, and it seems that the codec will
have to do it itself (although I'm not sure why max_raw_buffer_size
would have to be set to 1 frame for video codecs):
"min_raw_buffer_size/max_raw_buffer_size - This indicates the
minimum and maximum amount of raw data that can be handled by one
call to encode_data. For video codecs, these should both be set to
the size of one frame."

That makes sense, since having UCI do it would give unnecessary
latencies if the codec can do frame-by-frame encoding, and besides
it would require that UCI know how many frames the codec wants to
buffer, which might change dynamically, etc. Leaving it up to the
codec is the right decision here IMHO. On the other hand, we don't
want to copy data around all the time, as that would be very
inefficient.

Ideally, (this may already be the case, I haven't read everything in
detail) the codec would get called with a pointer to a buffer each
time new data is available in that buffer. It would check whether
there was enough to do an encode cycle, and if so, would perform
one. The output data this yields is returned, and the parts of the
buffer that are represented in the generated output are tagged as
no longer necessary, so that they can be freed. Instead of a single
buffer it would ofcourse be possible to have a buffer per frame or
something, for ease of memory management.

Anyway, I'm far from understanding all the issues involved, so this
may all be a bad idea. However, I do think it would be necessary
for the codec to be able to access the last n frames, for which it
should be able to tell UCI when a frame of raw data can be
discarded. Since this is also necessary for performing motion
compensation and not just for 3D wavelets, I presume this has
already been taken care of.

In the end (yeah, I really am about to shut up now), a video codec
is a piece of software that converts video frames into an encoded
stream, and converts that decoded stream back into raw video
frames. As long as you don't assume anything more, it should be
possible to accomodate everything (not necessarily efficiently, but
at least it would be possible).

Lourens
--
GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'[email protected]'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.





--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to '[email protected]'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.