Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Oliver Endriss writes:
 > Gregor Lawatscheck wrote:
 > > 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?
 > 
 > According to the datasheet (table 16, p.39), a split buffer 
 > configuration SDRAM 160 KB / DRAM = 197 Kb should work. 
 > Obviously it doesn't.

It does, but not during playback. 
Playback in the way it has to be done on this card is not supported by
hardware and the overflow buffer mechanism is handled by hardware.


 > > 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?
 > 
 > You looked into the NTSC table (p.20), right? I wish we could use this 
 > setup! This would increase OSD memory size by approx. 260 KB and we 
 > wouldn't have any problems. Unfortunately, we have to use a PAL setup 
 > (p.21) which needs 2* 607,5 KB for reference frames plus 373 KB for B 	
 > frame.

Don't believe those numbers. They are bigger in the current RTSL.
They depend on the microcode.
 
 > 2 MB SDRAM are not enough for a PAL system with large OSD.
 > I guess it's not possible to move some or all OSD buffers into DRAM?

No, you can only use SDRAM.


Ralph


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



Home | Main Index | Thread Index