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

["Dr. Werner Fink" <werner@suse.de>]

On Thu, May 15, 2003 at 06:12:45PM +0200, Klaus Schmidinger wrote:
> Gregor Lawatscheck wrote:
> > 
> > At 07:41 14/05/2003, I wrote:
> > >Just to say - it cristallized that this "blank screen" bug is down to
> > >statistical multiplexing and corresponding headers in the PES stream.
> > >I've posted about this over on the linux-dvb list:
> > >http://www.linuxtv.org/mailinglists/linux-dvb/2003/05-2003/msg00191.html
> > 
> > After a lot of talking and speculation and testing out I've come up with an
> > experimental, dirty patch for vdr-1.1.31 to work around problems with
> > either the firmware, the drivers or the way some mux encoders send the
> > headers for variable bitrate streams.
> > ...
> > Here's the patch
> > http://www.mpex.net/riovolt/vdr-statmux-vbr_vbv_delay.patch
> > comments from testers appreciated.
> 
> To avoid an additional place where the data is scanned I'd like to suggest
> putting this into cRemux::ScanVideoPacket(), since there we are already
> sync'ed on an I-frame:
> 
> --- remux.c     2003/04/26 15:07:41     1.15
> +++ remux.c     2003/05/15 16:00:00
> @@ -501,6 +501,13 @@
>           if (Data[i] == 0 && Data[i + 1] == 0 && Data[i + 2] == 1) {
>              switch (Data[i + 3]) {
>                case SC_PICTURE: PictureType = (Data[i + 5] >> 3) & 0x07;
> +                               if (PictureType == I_FRAME) {
> +                                  uchar *p = (uchar *)Data;
> +                                  //printf("VBV: %02X %02X %02X\n", p[i + 5], p[i + 6], p[i + 7]);//XXX
> +                                  p[i + 5] = 0x8F;     // 10001111 http://members.aol.com/mpucoder/DVD/mpeghdrs.html#picture 
                                                             ^
For what this bit is good for? ------------------------------|
IMHO this is part of the `temporal sequence number', isn't it?
Btw:  http://members.aol.com/mpucoder has moved to
      http://www.mpucoder.com/


> +                                  p[i + 6] = 0xFF;     // 11111111 tag vbv for variable bitrate
> +                                  p[i + 7] = 0xF8;     // 11111000 ditto
> +                                  }
>                                 return Length;
>                }
>              }
> 
> With the printf() line active I can see that for RTL and Sat.1 these three
> bytes are always 8F FF F8, while for ARD, for instance, there are sequences
> like this:
> 
> VBV: 4C 26 E0
> VBV: 4C 65 00
> VBV: 4B FC 38
> VBV: 4C 64 C0
> VBV: 4C 35 10
> VBV: 4C 3D D0
> VBV: 4C 29 68
> VBV: 4C 23 A8
> VBV: 4B E8 B8
> VBV: 4C 17 E0
> VBV: 4C 26 70
> VBV: 4A E9 08
> 
> Recording and Transfer Mode works here both with and without the patch,
> so AFAICS I wouldn't mind adopting this. However, I'm not quite sure
> whether simply poking the three constant byte values into the data stream
> is correct, or whether we should rather set/clear specific bits...


        Werner


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