[linux-dvb] Re: vbv delay/buffer overflows on VBR statmux

[Gregor Lawatscheck <gpel@mpex.net>]

At 18:08 21/05/2003, we wrote:
> Table 14: Video Input Buffer (theoretical + decoder delay +
>  > display synchronization = 229,376 + 52,000 + 75,000)
>  > which is surprisingly close to 230 k as "theoretical" input. Maybe this
>  > also explained why higher vbv_delay (i.e. no delay by setting 0xffff) had
>  > an effect freeing some memory?
>
> Maybe.
> Some numbers in the RTSL include files also are different to the ones
> in the TI datasheet. Without more knowledge about the microcode one
> can only speculate.
Section 7.7.2 says something about the MPEG standard:
The video input buffer, which is located in the SDRAM, is made up of three 
components: a theoretical rate control buffer whose size is specified in 
the MPEG-2 video standard (229,376 bytes); a buffer space to compensate for 
the decoder delay (52,000 bytes); and additional storage space to synchronize
the video decoder timing with that of the NTSC/PAL encoder Vsync timing 
(75,000 bytes).

Could that be why 230 k works fine or is this not the video memory?
Moreover there seems to be seperate memory  for I-/P-/B-FRAME of up to 500 
k each, I'm not quite sure what the vid memory does beyond holding the 
frames - things like timing info -- but then so much?



--
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.