Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



At 04:42 17/05/2003, you wrote:
Gregor Lawatscheck wrote:
> >From my limited point of view, I think it would be better to set
> >only the vbv delay without touching the rest:
> >
> > p[i + 5] |= 0x07;
> > p[i + 6] |= 0xFF;
> > p[i + 7] |= 0xF8;
>
> >IMO we should not modify the data during recording.
> >We should fix it during replay. It's a firmware bug and it should be
> >fixed in the firmware. If this is not possible it should be fixed in
> >the driver.
>
> I completely agree. I've submitted it as a patch but wouldn't like to
> see it applied to the sourcetree just yet. It was intended for
> testing. As you say it should be fixed in the firmware, if not there
> then in the driver. Only as a last resort by some sort of special
> setting in channels.conf should vdr have to deal with it.

Ok, this is an experimental driver patch to fix the problem:

--- av7110.c.org Sat May 17 05:12:30 2003
+++ av7110.c Sat May 17 05:19:39 2003
@@ -1116,6 +1116,8 @@ pes_play(void *dest, ring_buffer_t *buf,
int len, split=0;
u32 sync;
u16 blen;
+ int i, ftype;
+ char *p;

dprintk ("function : %s\n", __FUNCTION__);
if (!dlen) {
@@ -1165,6 +1167,20 @@ pes_play(void *dest, ring_buffer_t *buf,

dprintk ("function: %s pread=%08x pwrite=%08x\n", __FUNCTION__,
buf->pread, buf->pwrite);
+
+ p = dest;
+ for (i = 0; i < blen-8; i++) {
+ if (p[i] == 0 && p[i+1] == 0 && p[i+2] == 1 && p[i+3] == 0) {
+ ftype = (p[i+5] >> 3) & 0x07;
+ if (ftype) {
+ //printk ("pic %d at %d/%d\n", ftype, i, blen);
+ p[i+5] |= 0x07;
+ p[i+6] |= 0xff;
+ p[i+7] |= 0xf8;
+ }
+ }
+ }
+
wake_up(&buf->queue);
return blen;
}


Replay and transfer mode should work now. Please test!

If it works I'll ask the firmware people to check whether it can be
fixed in the firmware.

> >This might also help with old RTL recordings that cannot be played
> > with the current firmware. I haven't had the time yet to look into
> > this issue but I'll try to do this next weekend.

Indeed, it also fixes the RTL bug. Great job, Gregor!
Thx, and good job for adapting it to the driver! We're definitely on the right road here but not quite there. After I though the patch at driver level would improve stability over having it in vdr (then again that isn't logical) I got an ARM crash after about 3 hours, 100 channel changes and then just letting it sit on a channel that previously didn't have demux problems:

May 17 17:16:46 lagwagon vdr[3606]: switching to channel 4
May 17 17:16:46 lagwagon vdr[4288]: transfer thread ended (pid=4288)
May 17 17:16:47 lagwagon vdr[4289]: receiver thread ended on device 2 (pid=4289
May 17 17:16:47 lagwagon vdr[3606]: buffer stats: 52264 (4%) used
May 17 17:16:47 lagwagon vdr[4290]: transfer thread started (pid=4290)
May 17 17:16:47 lagwagon vdr[4291]: receiver thread started on device 2 (pid=42
1)
May 17 18:07:21 lagwagon vdr[4291]: buffer usage: 80% (pid=4290)
May 17 18:07:21 lagwagon vdr[4291]: buffer usage: 85% (pid=4290)
May 17 18:07:21 lagwagon vdr[4291]: buffer usage: 90% (pid=4290)
May 17 18:07:21 lagwagon vdr[4291]: buffer usage: 95% (pid=4290)
May 17 18:07:21 lagwagon vdr[4291]: buffer usage: 100% (pid=4290)
May 17 18:07:26 lagwagon av71100: ARM crashed!
May 17 18:07:26 lagwagon av71100: ARM crashed!
May 17 18:07:38 lagwagon av71100: ARM crashed!
May 17 18:07:38 lagwagon av71100: ARM crashed!
May 17 18:07:50 lagwagon av71100: ARM crashed!
May 17 18:07:50 lagwagon av71100: ARM crashed!
May 17 18:07:54 lagwagon vdr[4290]: ERROR: skipped 99 byte to sync on TS packet
May 17 18:07:54 lagwagon vdr[4290]: ERROR: skipped 99 byte to sync on TS packet
May 17 18:08:03 lagwagon av71100: ARM crashed!
May 17 18:08:03 lagwagon av71100: ARM crashed!
May 17 18:08:15 lagwagon av71100: ARM crashed!
May 17 18:08:15 lagwagon av71100: ARM crashed!
May 17 18:08:27 lagwagon av71100: ARM crashed!
May 17 18:08:27 lagwagon av71100: ARM crashed!
May 17 18:08:39 lagwagon av71100: ARM crashed!
May 17 18:08:39 lagwagon av71100: ARM crashed!
May 17 18:08:51 lagwagon av71100: ARM crashed!
May 17 18:08:51 lagwagon av71100: ARM crashed!
May 17 18:08:53 lagwagon vdr[4290]: ERROR: skipped 99 byte to sync on TS packet
May 17 18:08:53 lagwagon vdr[4290]: ERROR: skipped 99 byte to sync on TS packet
May 17 18:09:03 lagwagon av71100: ARM crashed!
May 17 18:09:03 lagwagon av71100: ARM crashed!


The buffer fill up is the typical indicator that the av7110 has locked up and refuses to process / decode any more data. This used to happen when changing channels. Setting vbv delay higher seems to be a temporary fix - eventually the av7110 still crashes :(.

Maybe we should also look into what can be done with the PTS and what could be different about those RTL recordings and the BBC channels here in terms of PTS.

http://www.bretl.com/mpeghtml/timebuf.HTM is a *very* useful reference of what can be done.
As is http://www.bretl.com/mpeghtml/bufsync.HTM more to the point http://www.bretl.com/mpeghtml/startbuf.HTM which specifically talks about what happens on starting to decode a stream and how constant and variable bitrate differ.


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



Home | Main Index | Thread Index