[vdr] Re: [PATCH] (DVB-T) statmux fix vbr tagging for pic header

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

Gregor Lawatscheck wrote:
> At 23:41 18/05/2003, you wrote:
>
> Bad signal with ff cards meaning if the sat isn't hooked up or tuned
> to a channel it could crash in transfer / replay mode?

Yes, some people reported this kind of problem.

> > > My first thought then was it could be the PCR that is going out
> > > of sync after a while and eventually crashes things (then again
> > > it should only be non-lipsync) so I made sure every channel had
> > > the correct PCR PID set. Same result.
> >
> >PCR is never used in transfer mode, only during *live* view.
> >Therefore, PCR is not included in recordings.
>
> Ah ok. Good point. Then again wouldn't it make sense to feed the full
> featured card with PCR infos in transfermode. I kind of thought this
> would be happening anyway.

I don't know whether the full featured card will accept PCR data during
replay. IIRC R. Metzler wrote that the firmware does not deliver PCR.

> I've analyzed the deadlock further. It happens when the around 224 k
> of data is sent as lots of 2048 sized packets within the same picture
> header.
>
> When the lock up occurs around 105 of these ~2048 byte packets are
> sent without any new frame being detected. The stream itself
> indicates 224 k as vbv buffer size, so really any single picture
> wouldn't be larger than that.
>
> With a vbv delay at 0xfff this seems to be avoided most of the time.
> With a smaller vbv delay it doesn't seem to go to the next pictue
> header / group of picture, thinks it's still on the same picture
> (which it assumes is longer than 105 x 2048 byte packets) and locks
> up. Odd. It's usually right at the end of a group of pictues (GOP)
> only few bytes before the next sequence header.

Sounds interesting.

> I've then debugged this further before I sent this message off. Let
> us forget about vbv delay and look at the bitrate setting in the
> squence header (00 00 01 b3 see
> http://www.mpucoder.com/DVD/mpeghdrs.html#seq ). You won't believe
> this: The recordings that lock the av7110 have a bitrate of around
> 6480000 set in the sequence header. Changing this to 3675200 as
> pvastrumento does by calculating the real rate suddenly makes it
> play. Nothing else changed but bytes 8 to 10 in the squence header.

The bit rate is a 30 bit integer. The sequence header holds the lower 
18 bits, while the extension header holds the upper 12 bits.

> Equally setting it to 0 (!) or the maximum makes it play. How weird?!
>  I believe the vbv delay stuff had effects in a similar direction but
> doen't always work to counteract the strange behaviour of the
> firmware - so let's forget about vbv delay for now :).

You are right. I modified my patch to set the bit rate. 
If I set byte 8/9 to 0x0000 or 0xffff, my RTL recording plays flawless.
Weird, because only bits 2..17 of the bit rate are modified,
while bits 0-1 and 18-29 are not changed. 

> Unfortunately I've been struggling to test by putting it in the
> av7110 driver. I've tried putting it in get_video_format, as this
> seems to be called before play_pes but somehow I can't seem to change
> the bitrate that is actually sent to the decoder. Again, probably
> best fixed in the firmware rather than in the driver or vdr - but how
> bizarre.

Your code will patch only the *first* sequence header 
because of [1], [2].


> get_video_format(av7110_t *av7110, u8 *buf, int count)
> {
>          int i;
>          int hsize,vsize;
>          int sw;
>          u8 *p;
>
>          if (av7110->sinfo)
>  [1] -->         return;
>          for (i=7; i<count-10; i++) {
>                  p=buf+i;
>                  if (p[0] || p[1] || p[2]!=0x01 || p[3]!=0xb3)
>                          continue;
>
> +                printk ("Seq. head at %d/%d - br: %d, %d\n", i,
> count, p[8], p[9]);
> +               p[8] = 0x00;
> +                p[9] = 0x00;
> +               printk ("New seq. head at %d/%d - br: %d, %d\n", i,
> count, p[8], p[9]);
>
>                  p+=4;
>                  hsize = ((p[1] &0xF0) >> 4) | (p[0] << 4);
>                  vsize = ((p[1] &0x0F) << 8) | (p[2]);
>                  sw = (p[3]&0x0F);
>                  SetMode(av7110, sw2mode[sw]);
>                  dprintk("dvb: playback %dx%d fr=%d\n", hsize, vsize, sw); 
>   [2] -->        av7110->sinfo=1;
>                  break;
>          }
> }
>
> I'm aware the 10th byte isn't manipulated but I tried playing back a
> file which didn't need it changed to get the bitrate. Maybe someone
> can work out where I'm going wrong in testing this.

It appears that only some values will cause the firmware to lock.
I think we should pass this info to the firmware guys. Maybe the error 
occurres when the bitrate is calculated from the sequence/extension header
(wrong bit masks, shifts or something like that).

Oliver


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