At 21:20 20/05/2003, you wrote:
> Don't "analyze" and "streamtype" look at the sequence header of the MPEGSorry to have caused a misunderstanding. I wasn't trying to imply this. It's more like the bitrates in there seem to give it problems. Probably completely unrelated and a minor point. I just though had this bug been in the firmware in the part that isn't precompiled there might have been the possiblity that the same bug occurs there too... Now that you say the non-RTSL part of the firmware doesn't actually look at the firmware that's rather unlikely.
> 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.
> 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.
OK thx for the info.
> I know this might be a bit too much of a favour to ask from you, but couldWould there be anyone in particular who does or do you mean the old RTSL won't wouldn't work with newer firmwares?
> 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.
> What was the old size and what's the new size? I think playing around withI see. Mhh maybe the bug has been in the RTSL there longer than Apr 15 2002 but was exposed by making the buffer size smaller. When I see the lockup here it's at around 210 kb of data passed in a single frame (the frame in reality is shorter than that!).
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 inThat could be it. Would be interesting if you can play those files through the 210 kb buffer size in the firmware by simply changing the bitrate in the sequence header.
> 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?!?
That would also be interesting. Seeing what data the microcode thinks it's getting for these files.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.