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

[Oliver Endriss <o.endriss@gmx.de>]

Klaus Schmidinger wrote:
> Oliver Endriss wrote:
> > Klaus Schmidinger wrote:
> > > Oliver Endriss wrote:
> > > > Klaus Schmidinger wrote:
> > > > > Marcus Metzler wrote:
> > > > > > It is no problem to free 20k, you just have to reduce the
> > > > > > OSD memory. Of course, Klaus will kill you if you do that
> > > > > > :-). They should have put more memory on the board.
> > > > >
> > > > > Well, there is one other way, if you can do without teletext
> > > > > re-insertion. The memory used for this just happens to be
> > > > > 20KB, too, and it also is taken from the SDRAM. Disabling
> > > > > teletext re-insertion can give these 20KB right to the video
> > > > > buffer, without decreasing the OSD.
> > > >
> > > > Argh. ;-)
> > > > On most stations teletext is much better than EPG.
> > > > I don't want to loose this feature right now.
> > > >
> > > > Could the memory setup be made customizable?
> > > > - mpeg buffer size
> > > > - osd memory size
> > > > - teletext reinsertion on/off
> > > > etc.
> > >
> > > Thinking about it: since TT re-insertion is only feasible during
> > > live tv, that memory is unused during replay. Maybe we could
> > > dynamically assign the video buffer size so that it has 230KB
> > > during replay (without TT re-insertion) and 210KB during live TV
> > > (with TT).
> > >
> > > @Ralph: would this be technically possible, or is there a reason
> > > that forbids this?
> >
> > Sounds good. According to the datasheet it should be possible to
> > change buffer setup when the decoder is idle. Don't know whether
> > this still applies.
>
> There would even be another possibility: since I assume that nobody
> will be using teletext and the OSD at the same time, we could give
> the OSD higher priority, so that when the OSD is displayed there will
> be no TT re-insertion. That way we wouldn't have to dynamically
> assign the video buffer size (which may be somewhat tricky...).

In this scenario the contents of the OSD memory would be lost as soon as 
teletext re-insertion starts. So everything has to be initialized each 
time the OSD gets activated (color palette etc.)
But this should be a minor problem...

> > > > Has anyone ever tried to upgrade a DVB-S to 4MB SDRAM?
> > > > This would solve all memory problems.
> > > > I'm dreaming of a full-screen true-color osd. ;-)
> > > > Well, this would be an option for some hardware hackers only.
> > >
> > > I'd be willing to try this if I knew where to get the necessary
> > > chip, and whether the hardware (i.e. the board layout) is able to
> > > do this.
> >
> > The problem is the SCS2 (SDRAM chip select 2) signal. Until now I
> > could not find the pinout of the AV7110 BGA package. It's missing
> > in the datasheet. So I don't know whether it is possible to grab
> > the signal at all.
>
> Maybe it would be enough to know where that siganl would go in the
> SDRAM chip? Since it isn't possible (I guess) to look "under" the
> AV7110 it might be easier to check the pinout of the SDRAM chip...

Finally I found the datasheet of the SDRAM chip HY57V161610D.
You can download it from www.hynix.com. The chip select is on pin 18,
which is (probably) connected to the SCS1 output of the AV7110.

But this doesn't help because we need the *second* SDRAM chip select 
(SCS2) for a second SDRAM (addresses >= cc200000). Unless this signal 
is available somewhere on the board we are out of luck.
Maybe we could tap it if it is located on the outer pin row of the 
AV7110. Does anyone have a pinout of the AV7110?

Maybe there is a board layout which can easily be upgraded with a second 
RAM chip? Until now I haven't seen such a board.

Oliver


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