[ExtractStream] [HTML inside] MPEG Stream questions...

[Edmond E. Shwayri]

---------------------- multipart/alternative attachment
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.

>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
><http://taxes.yahoo.com/>http://taxes.yahoo.com/
>
>Yahoo! Groups Sponsor
>ADVERTISEMENT
>
>To unsubscribe from this group, send an email to:
>ExtractStream-unsubscribe@yahoogroups.com
>
>
>
>Your use of Yahoo! Groups is subject to the 
><http://docs.yahoo.com/info/terms/>Yahoo! Terms of Service.


---------------------- multipart/alternative attachment
An HTML attachment was scrubbed...
URL: http://lists.merlins.org/archives/extractstream/attachments/a9b5cfc9/attachment.html

---------------------- multipart/alternative attachment--