[vdr] Re: Problems Recording some FTA.

[Oliver Endriss <o.endriss@gmx.de>]

Gregor Lawatscheck wrote:
> 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

Yes, pes_play cannot not transfer pes packets larger than 2048 bytes.
This is the size of the transfer buffer in DPRAM.

> the ring buffer of the av7110 or the ring buffer in userspace on the

The size of the kernel ringbuffer is 128 KB (AVOUTLEN).
I don't know how things are handled on the arm side.

> machine because when the av7110 locks up len is always 0?!

len==0 means that the ringbuffer is empty. Just an idea:
Did you see blen==6 (pes packet length == 0) before the arm crash?

ISO 138181-1 says:
'A value of 0 indicates that the PES packet length is neither specified 
nor bounded and is allowed only in PES packets whose payload is a video 
elementary stream contained in Transport Stream packets.'

I think that this is not handled correctly in the code!

> > > 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;
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Note that this line clears the ringbuffer.

>                  printk("packet too large: %d\n", blen);
>                  return -1;
>          }

Yes, would be better. Do you get 'packet too large' messages?

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

Sometimes this also occurres when you replay a recording. It means that 
the pes packet hasn't been transferred completely into the ring buffer 
yet. This is no problem.

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

Which is the maximum pes packet size allowed for DVB?
As you can see, pes_play() will never transfer packets larger than 2048 
bytes, so oversized packets cannot be passed to the av7110.

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

I enabled the 'packet too large' printk and checked with an old RTL 
recording. There are no oversized packets. Maybe this is a different 
issue in your environment.

Oliver


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