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

[Gregor Lawatscheck <gpel@mpex.net>]

At 22:11 20/05/2003, you wrote:
> > If it helps I can cut out a minute or so around the glitch and make
> > it available for download.
>
> Yes, please. I'll check whether I can improve it.
Sorry for taking this back over to the vdr list by accident. I guess when I 
read Klaus commenting I subconsciously typed the vdr list as recipient :).

Some things I wanted to say:

1) Could it be a problem under certain conditions that the vbv buffer size 
is bigger than the actualy buffer set aside in the firmware? Of all the 
streams I've seen so far the vbv buffer size is 224 kbyte, as Ralph says 
the video memory in the firmware is at 210 k now. I suppose if settitng the 
bitrate alone doesn't save us from ARM crashes and if nothing can be done 
about freeing another 20k (to be safe) from the firmware I suppose we could 
try patching that value too. But let's see how far we get.

2) Once in a while I get glitches on BBC-1 the 15 Mbit channel with the new 
firmware when I'm pretty sure the reception is so good that with the old 
firmware this wouldn't have happened. Maybe this is related, maybe it's 
not. If the TI micorcode handles the 6,4 MBit wrong, I wouldn't be 
surprised if it handled the 15 Mbit wrong too, just that it has slightly 
different effects (such as minor glitches).

3) The remaining two bits of the 10th byte aren't patched yet so on certain 
bitrates higher than 26.2 Mbit it wouldn't actually patch it to 15 MBit - 
but it's fairly unlikely to have such a high bitrate even on VBR.

Great job devising and optimizing these patches Oliver, I don't notice much 
(or any) CPU impact as long as there is no logging. Let's just hope setting 
the bitrate avoids lockups and ARM crashes over here. I'll report once I 
have some more data.



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