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



Gregor Lawatscheck writes:
 > At 19:41 20/05/2003, you wrote:
 > >Gregor Lawatscheck writes:
 > >  > well which might have been reproduced by employing the same routines 
 > > in the
 > >  > firmware which could also need fixing.
 > >
 > >
 > >Where would that be?
 > >The ES is not touched in mpegtools or in the firmware.
 > 
 > Don't "analyze" and "streamtype" look at the sequence header of the MPEG 
 > stream to output the bitrate? Doesn't analyze also look at the size of the 
 > P(E)S packets to calculate and output the bitrate per GOP?


Yes, but they do not change it or use it for demuxing.


 > >Again, there is no kind of ES level processing in the firmware. This is all
 > >done by the video DSP microcode which did not change for quite a while
 > >(since the last RTSL release I got sometime back in 2001).
 > 
 > Uh oh, I hope the bug is not in there. The last firmware which worked fine 
 > was from 15 Apr 2001? Are you sure the firmware doesn't look at the bitrate 
 > in the seqeuence header -- well I guess why would it? Maybe it's a bug in 
 > the driver after all as I suspected way back in time - but then why would 
 > the driver tell the firmware something about the bitrate?

It doesn't.


 > I know this might be a bit too much of a favour to ask from you, but could 
 > you please build a firmware with the RTSL that was used in 0.9.4 just so we 
 > can either eliminate or pin-point this as the cause?

Sorry, I do not have firmware sources which would be compatible with
the current linuxtv drivers.


 > >The real fix is to throw out OSD memory and give it back to the video
 > >decoder which seems to need it for some streams.
 > 
 > The good thing is, I've yet to encounter a stream that doesn't play once we 
 > manipulate the bitrate in the sequence header. That's how odd it is.
 > 
 > >I have files which play fine when I increase the video buffer back to
 > >its old size.
 > 
 > What was the old size and what's the new size? I think playing around with 

I am not completely certain about the size in 0.9.4 but it should be
over 260 kB. Now it is 210 kB.


 > vbv_delay did the same thing as increasing the size of the video buffer in 
 > the firmware. IMHO I don't actually think a bigger buffer size is needed in 
 > the firmware. Leave the video buffer as it is and try changing the bitrate 
 > in the sequenece header instead and then play those streams which 
 > previously only played when you increased the video buffer. I wouldn't be 
 > surprised if they played then. If this is a bug that sits in the RTSL then 

I guess the microcode does some calculations based on the bitrate and
decides it cannot handle it?!?
The code on the ARM core can read back the birate as parsed by the
microcode but, AFAIK, it does not do anything with it.


Ralph 


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



Home | Main Index | Thread Index