<html> We can hypothesize about the why, but my guess is it is hardware related.  The why isn't really all that relevant.  All we need to know for zss and splitstream is that the MPEG packet may be fragmented across multiple TY records.   Here are some examples : Here the sequence header (MPEG packer type B3) is fragmented accross the first two records.  Total size is 88 Bytes.  The GOP which is record 3 is all contained in that record. As to what is in this MPEG packet, the fixed size of a sequence header is 12 Bytes.  Byte 11 though includes a "(load non-intra quantiser matrix)" flag which in this case is set.  The matrix occupies 64 bytes and they are appended to the fixed portion for a total size of 12 + 64 = 76.  The remaining 12 bytes look to be pad. 00 05 47 E0  30 20 56 40  00 00 00 00  00 00 00 00  size=00054 (vid-H) | 00 00 00  00 00 01 B3  1E 01 E0 24  08 8B A3 81  10 11 11 12 00 00 42 E0  30 00 B9 94  00 00 00 00  00 00 00 00  size=00004 (video) | 82 00 01  00 00 00 00 00 00 01 B8  00 00 00 00  00 00 01 E0 00 00 8C E0  30 00 B9 98  00 00 00 00  00 00 00 00  size=00008 (video) | 00 00 00  00 00 01 B8  00 00 00 00 00 00 01 E0  00 00 8C 80 Here the I-Frame spans two records.  Total size is $4 + $AA6C = 43632 Bytes 00 00 48 E0  30 00 B9 B0  00 00 00 00  00 00 00 00  size=00004 (video) | 93 FF FF  00 00 00 00 01 00 00 8F  FF F8 00 00  01 B5 8F FF 0A A6 C2 E0  30 20 56 A0  00 00 00 00  00 00 00 00  size=0AA6C (video) | 00 00 00  01 00 00 8F  FF F8 00 00  01 B5 8F FF  F3 9C 00 00 00 01 06 E0  30 00 B9 B4  00 00 00 00  00 00 00 00  size=00010 (vid-P) | ED 27 30  00 00 01 E0  00 00 8C 80  07 21 00 07  18 A5 FF FF In this case the MPEG record starts in the short 4 byte packet which carries the I-Frame sub-type and then continues in the 0x2 sub-type.  There looks to be no padding at the end of this packet. In this case the B-Frame starts out in a 4 byte packet types 0xB which is what marks the start of the B - Frame, then two 0x2 packets which need to be appended.  In the last 4 byte packet note that only the last byte is 00, so if there is padding it may only be 1 byte worth of it. 00 00 4B E0  30 00 B9 F0  00 00 00 00  00 00 00 00  size=00004 (video) | 07 FF FF  00 00 00 00 00 01 00 00  DF FF FB B8  00 00 01 B5 01 F0 82 E0  30 21 82 E4  00 00 00 00  00 00 00 00  size=01F08 (video) | 00 00 00  00 01 00 00  DF FF FB B8  00 00 01 B5  83 23 23 9C 00 00 42 E0  30 00 B9 F4  00 00 00 00  00 00 00 00  size=00004 (video) | 19 0B 27  C0 33 80 00 00 00 01 C0  03 6A 8C 80  07 21 00 05 I am no expert in MPEG, but forced alignment seems very unlikely.  This sounds to me to be either TiVo hardware related or TiVo software related.  I don't see why these extra pads couldn't be stripped for MPEG export. MPEG allows for multiple video and audio streams.  Each stream is identified by Ex with x 0 to F (I guess a total of 16 different video streams).  Same goes for audio (with a total of 32 different audio streams).  The TiVo is recording a single composite video signal no matter what input it uses.  That means the source media has a maximum of 1 video channel and up to 2 audio channels.  To support both audio channels the TiVo would need hardware to be able to encode both audio channels simultaneously.  Assuming it has it (I don't think it does), then it also needs a software upgrade that would allow it to record MAIN and SAP.  If all those conditions were met then theoretically we could see MAIN on C0 and SAP on C1. <blockquote type=cite cite><tt>Interesting... so the 4-byte packets [for the most part] Tivo's way of saying to the decoder -- "Hold up - there's a little bit more MPEG info on it's way, but we had to wrap it in something..." So do you know if the padding is optional, or is it necessary for a) timing purposes or b) "error control" to ensure enough '00' data to let the decoder know definitively that the next header won't get 'lost' in the data? Also - I noticed that in the MPEG spec that audio blocks use not just C0, but C0 - DF as Stream ID's, and video blocks can actually use E0 thru EF as Stream ID's. In the splitstream (and of course zss) code it checks the Tivo headers for C0 & E0 for audio & video respectively... any chance that the Tivo code might use more than one Stream ID as well? Conspiring minds want to know... ;-) Laterz, Roger "Merch" Merchberger __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax <a href="http://taxes.yahoo.com/">http://taxes.yahoo.com/</a> </tt> Yahoo! Groups Sponsor ADVERTISEMENT <tt>To unsubscribe from this group, send an email to: ExtractStream-unsubscribe@yahoogroups.com </tt> <tt>Your use of Yahoo! Groups is subject to the <a href="http://docs.yahoo.com/info/terms/">Yahoo! Terms of Service</a>.</tt> </blockquote> </html>