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

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.=20
Basically what happens is that the codec takes a 3D block of pixels=20
(I think it's currently 32 frames or so), performs a 3D wavelet=20
transform on it, quantises the resulting coefficients, entropy=20
encodes them, and writes them to the stream.

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

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

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

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

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

Lourens
--=20
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.