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

[Gregor Lawatscheck <gpel@mpex.net>]

At 23:41 18/05/2003, you wrote:
> Please post your system setup. Are you watching in transfer mode?
Yes indeed - I'm using transfermode or mplayer to reproduce the problems.
I have a Siemens DVB-s full featured rev 1.3
and a TT Budget DVB-T feeding it.

> Arm crashes might have some other reasons:
> - hw failure
> - bad signal with full-featured cards
> - interrupt sharing/not enough cpu power (???)
I rule all these out because it's pretty stable with 0.9.4 / vdr 1.1.13. 
I'd stay with it but then on that  version I can't record from sat properly 
or 1.1.13 locks up sometimes switchting between transfermode and sat.

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?

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

> debitype has nothing to do with card/system types. It is used in debi
> and gpio interrupt/tasklet processing. IIRC I could produce a debi/gpio
> irq oops if I overloaded the system (not enough cpu power).
ok thanks, that's not it then I think...

> > What was changed in the firmware to include timshifting on one card?
> > Are the buffers smaller or in another part of the RAM or something?
>
> I don't know. Only the driver developers can answer this question.
> As these changes trigger the RTL bug, it might be possible to locate the
> bug in the firmware.
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.

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

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.

get_video_format(av7110_t *av7110, u8 *buf, int count)
{
        int i;
        int hsize,vsize;
        int sw;
        u8 *p;

        if (av7110->sinfo)
                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);
                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. 


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