[vdr] Re: Problems Recording some FTA.

[Gregor Lawatscheck <gpel@mpex.net>]

At 18:14 18/05/2003, you wrote:

> > If the available space in the ring buffer
> > (len) is smaller than the packet size derived from the PES header
> > (blen) then "buffer empty" is indicated.
> > Shouldn't this be more like "buffer overflow"?
>
> 'len<blen' means underflow. This ringbuffer holds data until it can be
> transferred to the AV7110. ring_buffer_avail() returns the number of
> bytes *waiting* in the buffer. Whenever the firmware is ready to accept
> a new chunk, it issues an interrupt and pes_play is called with
> dlen=2048 bytes.
So the av7110 wants things in chunks of 2048 and not larger? Is this the 
ring buffer of the av7110 or the ring buffer in userspace on the machine 
because when the av7110 locks up len is always 0?!

> > Moreover if blen is larger than 2048 (see case DATA_MPEG_PLAY) the
> > buffer is supposed to be empty?
>
> I've never seen 'blen>dlen'. The message 'buffer empty' would be
> misleading in this case. It should read 'packet too large'.
Yes, I too think it ought to be like this - in fact there is already code 
in there:

        if (len<blen) {
        // if (len<blen || blen > dlen) {  <--- blen > dlen misleading here
                printk("buffer empty: len: %d, blen: %d\n", len, blen);
                wake_up(&buf->queue);
                return -1;
        }
        // This code was commented out
        // if (blen>2048) {  <-- original code
         if (blen > dlen)
                buf->pread=(buf->pread+blen)%buf->size;
                printk("packet too large: %d\n", blen);
                return -1;
        }


> During my tests I only got 'len<blen' which means that there is an
> incomplete pes packet in the ringbuffer. This is harmless as the
> firmware will try again later.
Yes, this is almost like a reception error. Make sense as these come in 
short bursts too.


> > I guess I must misunderstand this but
> > it bemuses me. How does this make sense? Again it's more like "buffer
> > overflow"? It seems some channels send oversized PES packets from
> > time to time (and when they do mostly in succession of three or so).
>
> Are you sure that 'blen>dlen' really occurres?
> I think this would be a problem.
Yes, sporadically I see PES packets with up to 60 kb (!) in size - most of 
them are 2048 or a few bytes shorter (no header extension i guess). Would 
it be the player software (i.e vdr) to break these down into smaller chunks?

0.9.4 didn't seem to mind packets larger 2048 - I guess this might have to 
do with the firmware changes and trying to make space for new features?

Is this then the root cause of all our demux problems -- oversized PES 
packets? Weird... and why would the 0xffff vbv delay help counter this for 
a while. Maybe it allocates a larger buffer that accomodates most large PES 
packets but once there is one that is even larger than 0xffff it crashes?



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