[matroska-devel] Re: b-frames
steve.lhomme at free.fr
Sat Jun 28 12:37:28 CEST 2003
Moritz Bunkus wrote:
> Although I'm at home I'm still pondering the B frame handling. So here
> are some of my questions.
> 1. Let's assume you have the typical sequence of IBP (display order?),
> timestamps 0, 40 and 80ms. In order to store that in Matroska WITH
> libmatroska I have to first AddFrame(I), then AddFrame(P, I) and then
> AddFrame(B, I, P). Otherwise I don't have the BlockGroup for the P
> frame that the AddFrame(B...) needs. Correct? So in a Matroska file
> the frames would be stored as IPB.
Yes, in coding order. That's also probably the preferred way for the codec.
> 2. Reading those frames and refpriorities. For a file containing B
> frames I have a MinCache of 2. I frames have a prio of 0, P have 1
> and B have a prio of 2. Correct? So let's take the example above. I
Yes and no. You can also have P frames with prio of 0 because they are
used the same as I frames in MPEG (for references).
> get the I frame and keep it. I get the P frame and keep it. Then I
> get the B frame. Now I'm happy and can deliver the frames in the
> order I want (either coding or display).
> Next example: display order IPBP which are stored as IPPB in the file
> according to my thoughts in 1. So I get the I frame, the first P
> frame which I both store. Now I get the second P frame. But which
> frame from the two stored frames can I discard? And how do I decide
It should be actually 0 for P frames because it's supposed to replace an
I frame in the reference cache. With a value of 1 it can't replace in
cache an element with prio 0.
> 3. Multiple B frames. Is this possible? If yes, how do I handle that?
> Display order: IB1B2P. How will this be stored, what does the
> refprio/cache handling look like in this case?
> I guess that Steve will answer all this ;) Thanks in advance.
display order : I1 B2 B3 P4
coding order : I1 P4 B2 B3 (== matroska order)
I1 : prio 0
P4 : prio 0
B2 : prio 2
B3 : prio 2
You have 2 elements in the cache, an element is rendered when it leaves
I1 arrives : (I1, .)
P4 arrives : (I1, P4)
B2 arrives : it can't replace an element in the cache, so all previous
frames in the cache has to be rendered, ie I1
(I1*, P4) and B2* (displayed)
B3 arrives : it can't replace....
(I1*, P4) and B3*
P5 or I5 arrives : It has to replace an element in the cache
etc until there is no more data and so you have to flush the cache in
display order. (I use an ordered list in the DSF, using std::map).
I still haven't implemented the full system... (I have to fix my
lockings first), ie I keep everything in memory ;)
More information about the Matroska-devel