At 17:33 22/05/2003, you wrote:
Thanks for the round up. What's the earliest firmware to support this? The one post April 15 2002 or ealier than that? I run into problems with firmware newer than January 2002 (i.e. immediately post 0.9.3). For example Feb 2002 which was the first to be included with the then new newstruct branch already has problems with blank screens. "oldstruct" I believe shipped the Jan 2002 firmware of 0.9.4 right till the end to Oct 2002 when it was abandoned.AFAIK when Ralph implemented simultaneous recording and replay (which didn't work in earlier versions) he needed some extra SDRAM, which he had to take off the OSD memory.
> I simply don't get why the memory allocation needed to be changed muchI see what you mean now. We should try and find some kind of compromise but in the end it's the firmware wizards who have to decide what functions can be done in how much memory. As 230k seems to be some kind if MPEG standard for a control rate buffer (for playback?) it'd probably a good idea for current and future compatibility to have the buffer at that.
> after 0.9.4 - especially in terms of essential video memory for playback.
> Is there an established value of how much OSD memory vdr needs to work?
Back in August 2002 he once asked me what the absolute minimum
OSD memory would be that VDR required, and I told him VDR needs around 83KB OSD
bitmap memory (plus some additional memory for color table and window management,
but I guess that negligable) - and that's only possible because it uses a 2bpp
window for the central list area, which means we can't have a full screen 16 color
window :-(.
So my guess would be that even though VDR's OSD size hasn't changed, the totalYes I guess we have to wait and see. Obviously as suggested on here before, some kind allocation model which can be set at driver start up would be optimal, but I guess that's kind of hard to do.
available OSD memory is now pretty much at the limit, and giving more memory
to the video buffer will actually reduce the available OSD size. If I've calculated
this correctly, taking 20KB off the current OSD memory (and assuming that we
already are at the limit) would mean you would have 6 or 7 fewer lines
in the OSD.
But that's all just guessing...