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



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

Klaus
-- 
_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10
CadSoft Computer GmbH                   Fax:   +49-8635-6989-40
Hofmark 2                               Email:   kls@cadsoft.de
D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de
_______________________________________________________________


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



Home | Main Index | Thread Index