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

[Gregor Lawatscheck <gpel@mpex.net>]

At 13:43 21/05/2003, you wrote:
> Marcus Metzler wrote:
> It's a shame because doubling memory size would not make the card much
> more expensive. Has someone ever tried to add more memory to the card?
> Of course this would require a modified firmware. ;-)
Sounds like a good idea. There's space for an extra 2 MB right? Is it 
special SDRAM or box standard one - I haven't really noticed a memory bank 
on there that could be expanded.

I ran vdr with the 15 mbit patch for a 4 hour period on a single channel 
without a hickup. Previously with just the vbv delay stuff it would crash 
around one hour but OK could just have been unlucky. After 4 hours all was 
fine until the next command to vdr. Trying to change the channel then took 
ages - the closing of the transfer thread timed out with "outcom error" 
followed by "OutCommand: timeout waiting for COMMAND idle" but eventually 
the channel changed, then the after a while in that state the ARM crashed. 
So something seems to become unstable after a while. What seems to work is 
to play a recording before the ARM crashes - that somehow seems to reset 
stuff and makes it live a bit longer. Equally vdr seems to rest the av7110 
on startup which could also be usful on channel changes. If I use mplayer 
and the ARM crashes and I reload the firmware mplayer locks up straight 
away again as it doesn't seem to reset things. Running vdr for some seconds 
after reloading drivers/firmware usually helps...

Oliver wrote
>I do not understand why the firmware has problems with *low-bitrate*
>streams. If buffer space is limited I would rather expect problems with
>high-bitrate streams.

Maybe we're setting a too high bitrate for low-bitrate streams? I'm 
currently testing various bitrates and vbv buffer sizes. After some heavy 
channel changes I now have it in a state where the ARM hasn't yet crashed 
but every new command times out in the message log but is then processed. 
I'm now looping a recording through it to see if the same data over and 
over eventually crashes it or whether there's still specially crafted data 
that could cause this.

I get the feeling on channel changes when detecting a different aspect 
ratio some data about it is sent to the av7110 - which might also include 
the "wrong" bitrate. I'll have to take a closer look.

>> 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.

>The two bits in byte 10 are the *low* significant bits! If they are set,
>the bitrate would be increased by 1200 bits/s max. These bits are 0 in
>all streams I have seen.

Yes, that's what I tried to say. I haven't seen a stream using those last 
two bits either.

>If this patch will ever find its way into CVS, I'll add a module
>parameter to disable it completely.

Good idea. If it goes in there it should be off by default I guess.

- Gregor 


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