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

[Michael Militzer]

Hi Stephan,

Quoting Stephan Assmus <superstippi at gmx.de>:

[...]

> 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 :-).

Yes, you are right with this. The feature is called B-frames where
bidirectional prediction can be used which linearly combines samples from
a past and future frame.

> 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
> _______________________________________________
> XviD-devel mailing list
> XviD-devel at xvid.org
> http://list.xvid.org/mailman/listinfo/xvid-devel
>
>