[XviD-devel] API transparency with regards to requiring future frames

[Stephan Assmus]

Hi again,

I would like to confirm an assumption I have with regards to the decoder 
requiring "future" frames for a particular frame. I hope I am right in 
thinking this is a feature of MPEG4/XViD that a frame can reference a 
future frame, otherwise just ignore this mail :-).

Suppose the following situation: I keep fetching chunk data and stuffing it 
into the decoder, and whenever xvidDecoderStats.type > XVID_TYPE_NOTHING I 
am happy to have decoded a frame and display it. As an example, assume I 
decoded 3 frames in this way, but what really happened, without me being 
aware of it, is that I fed the decoder data so that it could decode until 
frame 4, because frame 3 needed frame 4. The library kept quite about 
having already parsed frame 3, because it wanted me to keep feeding it data 
until it could parse frame 4 as well so that it could reconstruct frame 3 
fully. After having displayed frame 3, progressing to "decode" frame 4 - 
what I would expect from the library, is that it handles this 
transparently, and just gives me frame 4, because it buffered this 
internally. My question is... is this assumption correct, or does this work 
more involved?

How common are streams that use this feature? My xvid based decoder works 
fine so far, but I don't know if I tested it with such streams.

Best regards,
-Stephan