[M4IF Technotes] Re: VBV comments

[Max Griessl]

Hi Arcangelo,
Arcangelo Bruna wrote:
> 
> Hi.
> I'm implementing a real time Simple Profile encoder. I have a problem in 
> the VBV implementation.
> The standard says to use the stuffing bits (bytes) to avoid underflow, 
> but, in this profile, only the stuffing MB are allowable, because the 
> stuffing_start_code can not be used.
> 
>  
> 
> Unfortunately, for a real time implementation, it is not really a simple 
> thing: in fact, they can not introduced in the next frame because it 
> will be inserted in the VB surely when it is already empty. So we must 
> insert them only in the already encoded frame, so the frame size become 
> bigger.
> But what happen if the frame size become too bigger so that when the 
> decoder requires it the frame it is not transmitted at all?

I am not a hardware expert. Only for a hard coded MPEG-4 decoder with limited 
memory the buffersize is really relevant. But in reallity I would say a hardware 
decoder does not process a whole frame at one time. It will take some time to 
decode Macroblock after Macroblock and later on the stuffing macroblocks. During 
  that decoding new input bits are put into the buffer. The simultanous putting 
to and getting bits from the VBV buffer must be balanced to avoid overflow and 
underflow. I have no experience how this can be modelled in a realistic way. 
Maybe other (hardware) people can clarify this.
> 
>  
> 
> Another problem: we can not re-encode the frame (due to the real time 
> encoding constraints), so we will insert the stuffing MB at the end of 
> the frame. But what happen if, using the Video Packet, the last video 
> packet become bigger than the profile's constraints (2048 bits for the 
> SP   L1 <mailto:SP   L1>)?

> 
>  
> 
> All these problems could be avoided allowing the stuffing_start_code in 
> each profiles & levels. Is there a reason why it is not so? Is possible 
> to suggest it to the standardization committee?

For simple profile it will never be changed, because it is already standarized.
The stuffing_start code has been added after the simple profile was already fixed.
> 
>  
> 
> Thanks,
> Arcangelo.
> 

Hope this helps,
Max
-- 
Max Griessl                                 DynaPel Laboratories GmbH
Software Design                             Fraunhoferstr. 9/2
Tel: +49 (0) 89 96242812                    D-85737 Ismaning, Germany
Fax: +49 (0) 89 96242890                    http://www.dynapel.de