[matroska-devel] [Fwd: Re: Re: b-frames]

Christian HJ Wiesner chris at matroska.org
Sat Jun 28 15:49:17 CEST 2003


Message from Dave ....

-------- Original Message --------
Subject: 	Re: [matroska-devel] Re: b-frames
Date: 	Sat, 28 Jun 2003 14:29:54 +0100 (BST)
From: 	Dave Latherdal <dave at leatherdale.net>
To: 	chris at matroska.org
References: 	<20030628075847.GG1544 at bunkus.org> 
<3EFD6FE8.6050409 at free.fr> <3EFD7413.2040302 at matroska.org>



Im not on the mailing list but take a look every now and then via the NNTP
service. Reading through this i believe avs2matroska is doing everything
the way it should, except according to the specs the referece priority
should be the other way round with the b-frames have priority 0 and I/P
having priority 2.("A value of 0 means the frame is not referenced.") So
my code does it that way (i think, i don't have my code handy atm).

Could you mention this to the right people please as either the specs need
changing or the examples in this thread are wrong.

DaveEL

> Dave,
>
> are you subscribed to matroska-devel meanwhile ? did you respect this in
> avs2matroska already ?
>
> Steve Lhomme wrote:
>
>>Moritz Bunkus wrote:
>>
>>
>>>Heya.
>>>
>>>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
>>>   that?
>>>
>>>
>>
>>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
>>the cache...
>>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
>>(P4, I5)
>>
>>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 ;)
>>
>>
>>http://www.matroska.org
>>
>>
>>
>
>



http://www.matroska.org



More information about the Matroska-devel mailing list