[MPlayer-dev-eng] Nut and B frames (and much more) NODAEMON

[Ville Saari]

On Mon, Apr 26, 2004 at 06:51:05PM +0200, Roberto Ragusa wrote:

> I'd like to raise a possible issue with future advanced video codecs.
> Is the nut container able (in a not hacked and ugly way, I mean) to handle
> codecs that don't operate on single frames?
> We're assuming that the codecs belong to one of these types.
> 1) independent frames (that is IIIIIIII-type, i.e. MJPEG)
> 2) backward dependent frames (that is IPPPIPPP-type, i.e. MPEG without B)
> 3) backward and forward dependent frames (that is IBBBPBBBPBBBI, i.e full MPEG)
> 
> what about another possibility?
> 
> 4) group of frames (that is GGG, where every G encodes, for example, 25 frames).

The cases 3 and 4 can be unified if the consecutive B-frames and the
following P or I are considered to form a G.

This would avoid the out-of-order timestamps. The buffering needs of the
composite packet would be similar to the approach of storing the BBP in
display order except that there would not be packets belonging to the
other streams between the frames. This is good, because those interspersed
packets would have to be buffered too in the display order solution if we
want to avoid seeking back and forth when decoding the different streams.

And the storage order of the frames (BBP or PBB) would then be irrelevant
as the timestamps are concerned, so the decode order could be used to
make the codecs happy.

-- 
 Ville