[vdr] Re: Problems Recording some FTA.

[Gregor Lawatscheck <gpel@mpex.net>]

At 01:49 19/05/2003, you wrote:
> Yes, pes_play cannot not transfer pes packets larger than 2048 bytes.
> This is the size of the transfer buffer in DPRAM.
Thx. Good to know.

> > 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.
Should just about be enough...

> > 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?
No unfortunately not.

> 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!
Interesting. I'm now thinking more along the lines of the bitrate set in 
the sequence header as can be  seen in my other posting.

> >          // 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.
Oh ok :) I guess that's not the worst of things when something like this 
happens.

> >                  printk("packet too large: %d\n", blen);
> >                  return -1;
> >          }
>
> Yes, would be better. Do you get 'packet too large' messages?
No I don't actually. The large packets I thought I saw were because I had 
moved the patch up a couple of lines, that way it showed me all sorts of 
"sizes" I guess heh. Before changing this to "packet too large" it would 
have been dropped as "buffer empty" anyway - so it couldn't have been that. 
I didn't think it through the first time around :(


> 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.
OK. I guess I was a bit paranoid, trying to find this bug.

> > >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?
I take this back. The PES packets are at or under 2048. vdr already breaks 
them down into these chunks. It was a clear oversight on my part.

> 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.
They can be fairly large, especially for DVB-T. This caused problems with 
channel 5 in the UK and most channels in Finland but was since fixed in vdr 
by Teemu Rantanen.

>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.
Yes, I guess there wouldn't be. I believe vdr and mplayer make sure there 
aren't when outputting... so old RTL and the UK channels could still be 
related. Next target: What's up with the bitrate in the sequence header and 
what could the firmware do with it? Calculate a buffer size or something 
(but then why does setting to 0 or maximum work heh). Sounds almost trivial 
and certainly fixable in the firmware if it was that. Let's hope...

- Gregor 


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