[ExtractStream] Re: OK I've almost got it working

Edmond E. Shwayri eshwayri at n...
Thu, 04 Apr 2002 20:06:38 -0500


---------------------- multipart/alternative attachment
After dinner I had a closer look at that file. There is only 1 problem 
with it that I can see. The header chunk (the first chunk) is exactly 1 
byte too small. I added 1 byte at 0x20000 and then loaded the file into 
DisplayStream and got (if you can't see html then this will look weird) :

80 78 0E 05 00 00 00 00 00 00 00 00 00 00 00 
00 (0x05) | 

80 78 0E 05 00 00 00 00 00 00 00 00 00 00 00 
00 (0x05) | 

00 01 03 C0 30 00 DC 60 00 00 00 00 00 00 00 00 size=00010 (aud-P) | 00 
00 00 00 00 01 C0 03 6A 8C 80 07 21 00 05 F9 F1 FF FF
00 36 04 C0 30 2D 12 40 00 00 00 00 00 00 00 00 size=00360 (audio) | F1 
FF FF FF FD A8 00 77 56 33 55 66 55 33 33 33 12 22 29
00 01 03 C0 30 00 DC 70 00 00 00 00 00 00 00 00 size=00010 (aud-P) | 00 
00 00 00 01 C0 03 6A 8C 80 07 21 00 07 13 41 FF FF FF
00 36 04 C0 30 2D 15 A0 00 00 00 00 00 00 00 00 size=00360 (audio) | FF 
FF FF FD A8 00 88 77 44 77 77 55 34 33 44 44 32 49 24
00 01 03 C0 30 00 DC 80 00 00 00 00 00 00 00 00 size=00010 (aud-P) | 00 
00 00 00 01 C0 03 6A 8C 80 07 21 00 07 2C 91 FF FF FF
00 36 04 C0 30 2D 19 00 00 00 00 00 00 00 00 00 size=00360 (audio) | FF 
FF FF FD A8 00 77 66 44 77 77 55 43 43 44 33 11 29 B4
00 01 03 C0 30 00 DC 90 00 00 00 00 00 00 00 00 size=00010 (aud-P) | 00 
00 00 00 01 C0 03 6A 8C 80 07 21 00 07 45 E1 FF FF FF
00 36 04 C0 30 2D 1C 60 00 00 00 00 00 00 00 00 size=00360 (audio) | FF 
FF FF FD A8 00 77 66 55 76 66 66 55 33 55 44 55 6D B6
00 05 47 E0 30 20 56 40 00 00 00 00 00 00 00 00 size=00054 (vid-H) | 00 
00 00 00 01 B3 22 02 40 23 0E 29 23 81 10 11 11 12 12
00 00 42 E0 30 00 CC 58 00 00 00 00 00 00 00 00 size=00004 (video) | 00 
01 00 00 00 00 00 00 01 B8 00 00 00 00 00 00 01 E0 00
00 00 8C E0 30 00 CC 5C 00 00 00 00 00 00 00 00 size=00008 (video) | 00 
00 00 00 01 B8 00 00 00 00 00 00 01 E0 00 00 8C 80 07
80 78 0E 05 00 00 00 00 00 00 00 00 00 00 00 
00 (0x05) | 

00 01 06 E0 30 00 CC 64 00 00 00 00 00 00 00 00 size=00010 (vid-P) | 00 
00 00 00 01 E0 00 00 8C 80 07 21 00 07 4B 3B FF FF 00
00 00 48 E0 30 00 CC 74 00 00 00 00 00 00 00 00 size=00004 (video) | FF 
FF 00 00 00 00 01 00 00 8A 6E 80 00 00 01 B5 8F FF F3
14 A7 42 E0 30 20 56 A0 00 00 00 00 00 00 00 00 size=14A74 (video) | 00 
00 01 00 00 8A 6E 80 00 00 01 B5 8F FF F3 9C 00 00 00
00 00 42 E0 30 00 CC 78 00 00 00 00 00 00 00 00 size=00004 (video) | 1E 
82 68 02 30 00 00 00 01 E0 00 00 8C 80 07 21 00 07 12
00 01 06 E0 30 00 CC 7C 00 00 00 00 00 00 00 00 size=00010 (vid-P) | 30 
00 00 00 01 E0 00 00 8C 80 07 21 00 07 12 F9 FF FF 00
00 00 4B E0 30 00 CC 8C 00 00 00 00 00 00 00 00 size=00004 (video) | FF 
FF 00 00 00 00 00 01 00 00 19 96 D3 B8 00 00 01 B5 83
01 D1 02 E0 30 21 A1 18 00 00 00 00 00 00 00 00 size=01D10 (video) | 00 
00 00 01 00 00 19 96 D3 B8 00 00 01 B5 83 23 23 9C 00
00 00 42 E0 30 00 CC 90 00 00 00 00 00 00 00 00 size=00004 (video) | 3E 
A9 10 00 00 00 00 00 01 E0 00 00 8C 80 07 21 00 07 2F
00 01 06 E0 30 00 CC 94 00 00 00 00 00 00 00 00 size=00010 (vid-P) | 00 
00 00 00 01 E0 00 00 8C 80 07 21 00 07 2F 1B FF FF 00
00 00 4B E0 30 00 CC A4 00 00 00 00 00 00 00 00 size=00004 (video) | FF 
FF 00 00 00 01 00 00 59 EA 73 B8 00 00 01 B5 83 23 23
01 F7 42 E0 30 21 BE 2C 00 00 00 00 00 00 00 00 size=01F74 (video) | 00 
01 00 00 59 EA 73 B8 00 00 01 B5 83 23 23 9C 00 00 00
80 78 0E 05 00 00 00 00 00 00 00 00 00 00 00 
00 (0x05) | 

06 8F 0A E0 30 21 DD A0 00 00 00 00 00 00 00 00 size=068F0 (video) | EA 
B0 00 00 01 00 01 52 3B B3 80 00 00 01 B5 84 4F F3 9C

This looks correct. The 0x05 I am going to guess is CC3 (Close Captioning 
- Channel 3). I know 0x01 is CC1 and 0x02 is CC2 here in the US. People 
say 0x03 is a packet with data so I will guess it may be TEXT1 and maybe 
0x04 would be TEXT2. 0x05 is definitely stored in the same manner as 0x01 
and 0x02. If you are using a program to do anything to this file it must 
know to ignore 0x05 packets (deal with them like 0x01 and 0x02 packets).

The <vid-h> is the video header.
Second video (size=00004) is a continuation of the header.
Third video (size=00008) is the GOP (Group of pictures).
<vid-p> is the PES with the PTS time-stamp for start of video.
Fourth video (size=00004) starts the I-Frame.
Fifth video (size=14A74) continues the I-Frame.
Sixth video (size=00004) continues I-Frame.
<vid-p> is PES (I contend with DTS information).
Seventh video (size=00004) starts a B-Frame.
Eightth video (size=01D10) continues the first B-Frame.
Nineth video (size=00004) continues the first B-Frame
<vid-p> is PES
Tenth video (size=00004) starts second B-Frame.
Eleventh video (size=1F74) continues second B-Frame.
Twelvth video (size=068F0) is a P-Frame.

This structure looks normal. The question is why does that first chunk 
have 1 less byte than it should. It could be the TiVo, BUT I think it 
sounds MUCH MUCH more likely to be an issue with the extraction 
program. Being 1 byte only it sounds like a memmove or a write command has 
an edge problem with 1 byte. What program did you use to get this bad.ty?


At 02:21 PM 4/4/02, you wrote:
>--- In ExtractStream@y..., "Edmond E. Shwayri" <eshwayri@n...> wrote:
> > Nothing there.
>Bother: try this
><http://freespace.virgin.net/y.llain/tivo/>http://freespace.virgin.net/y.llain/tivo/
>
>Sorry
>
>
>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/eb813654/attachment.html

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