[linux-dvb] Video packets vs. picture headers

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Maybe I'm wrong, but it appears to me as if there is a difference
between CVS driver versions dated 2001-04-18 and 2001-04-28 regarding the
way the video packets are arranged.

In the CVS driver dated 2001-04-18 a new video packet (0xE0) was started
whenever a new picture header (0x00) or sequence header (0xB3) appeared
in the data stream, as in

       0 E0 video  8186 1F FA 80 80 05 23 3E B3 FE DF 9F 80 00 00 01 B3 2D 02 40 23
      16 B3 sequence_header
     156 B5 extension_start
     166 B8 group_of_pictures_header - time_code: 07:21:10.01
     174 00 picture_header - temporal_reference:    2  picture_coding_type: 1
     182 B5 extension_start
     191 01 slice 3B FC 3D AC BF 99 5A B6 B2 FE 65 60 E6 1B F5 40 16 00 36 FE
    1224 02 slice 33 7C 3D AD 01 CA B5 4D 68 04 EA C3 0D DD A5 68 D1 93 0D A3
    ...
   52404 E0 video  7840 1E A0 80 80 05 23 3E B3 C6 9F 80 00 00 01 00 00 1B 12 3B B8
   52419 00 picture_header - temporal_reference:    0  picture_coding_type: 3
   52428 B5 extension_start
   52437 01 slice 42 57 EF D7 6B E5 72 B9 5F 9E 9E D7 D2 E9 C4 9A FF 7D 3D 2B
   ...
   60250 E0 video  7264 1C 60 80 80 05 23 3E B3 E2 BF A9 60 C0 00 00 01 00 00 5B 50
   60267 00 picture_header - temporal_reference:    1  picture_coding_type: 3
   60276 B5 extension_start
   60285 01 slice 42 55 0E AC 7F 7D 3D EF D7 4E F5 52 BD 7E B2 6F 48 DB CF 34

With the latest CVS driver (dated 2001-04-28) this appears to be no longer the
case:

  107577 E0 video  8186 1F FA 80 80 05 23 60 87 7C DF 01 D3 96 28 0E C3 C8 D1 02 EE
  107867 16 slice 42 68 29 03 A3 ED 01 1F 69 AE E8 27 AE 15 50 28 B8 5C CB 0F
  108199 17 slice 42 68 3B 12 4C 38 7C AB 60 62 B8 3A F4 ED AA 20 F3 C2 21 F6
  108547 18 slice 42 68 E9 2A FD D0 04 8A 7B 1D 79 72 EA 9D 21 57 40 18 2A 13
  108878 19 slice 4A 69 3B 3D ED 80 C4 88 AB 55 0A 03 62 05 35 D4 5A BB 6A 93
  109215 1A slice 4A 7D 00 80 53 85 5D 2C 1C 28 02 0F 88 B7 1F 27 54 04 1D 10
  109524 1B slice 43 96 5A DA D0 07 68 01 F8 BB 36 5C 3F 46 DE 22 AB 98 74 E2
  109803 1C slice 43 99 DB 5C 88 76 3E EA D0 08 40 82 C7 3C F3 38 FA AB 63 BB
  110041 1D slice 42 C4 50 9B B4 04 AD 75 07 8C 69 CE 68 C8 FB 40 20 30 3C CB
  110277 1E slice 42 7A 2D DD DA 01 00 77 72 AD 82 C4 0A 60 B1 32 0E 4F C1 E2
  110467 1F slice 42 EB D6 06 CD 74 18 3E D0 14 BD B0 58 82 8E 69 75 6E AB 40
  110657 20 slice 42 68 29 41 15 51 AE 01 F5 54 DE 32 E8 08 18 1F 2B 54 41 ED
  110850 21 slice 4A 6C E8 30 5D DC 65 76 A1 40 5A 5E 35 EC D9 17 40 47 1D 2E
  111034 22 slice 43 A2 D1 F6 C0 63 0E DA D0 2C 49 75 6C 1A 11 2F A8 7C DA EA
  111238 23 slice 43 A1 BE A0 9D 4F 57 40 0F 5C AA FA D8 0C 1F 68 74 AB 40 20
  111447 24 slice 42 7A E5 4F 01 DA 9D B9 F1 96 80 DA 4F AB 5C 0E 68 3F D9 16
  111603 00 picture_header - temporal_reference:    9  picture_coding_type: 3
  111612 B5 extension_start
  111621 01 slice 52 5D 75 D7 3C D3 23 E8 69 CD EA FE 60 1D BB 22 42 A0 F6 AB
  111806 02 slice 5A 5E FA E5 D7 BE 12 B4 85 59 48 9F A6 07 39 1B B1 D8 D2 1D
  111935 03 slice 52 56 5D 80 89 81 C7 F7 B0 40 4D E3 E9 20 10 4B 9F A2 ED D0

Was this intended or is this just a bug?

Since VDR scans the data stream to find the picture frame borders, it depends
upon a new video packet starting whenever a new picture starts.

I assume that this new behaviour is perfectly within the DVB specs, but it
would make things a lot easier for VDR if this could be done the way it was
before.

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 listar@linuxtv.org with "unsubscribe linux-dvb" as subject.