[ExtractStream] More Re: its in the 3s.....

[Dale Reed]

willieb9000@y... wrote:

> OK, I have looked at the code for tyconvert again and I just cannot
> find where he skips the 01 and 02 blocks. My guess is that he does it
> by omission since all valid audio and video records contain 0C and
> 0E, but don't anybody quote me becasue I have no idea.


Thats what it looks like to me. I'm working with the tyc source code
(assuming its the same) that runs w/out a gui.

> I have noticed though that in the valid video records, the first
> five bytes follow a pattern:
> 
> 00 01 06 E0 30
> 01 B2 42 E0 30
> 00 00 4A E0 30
> 03 CD C2 E0 30
> 00 00 42 E0 30
> 00 01 06 E0 30
> 00 00 4B E0 30
> 01 AD 42 E0 30
> 00 00 42 E0 30
> 
> We know the first 3 bytes contain the size of the data the record
> refers to. the 4th one, E0, says the packet is video. The 5th seems
> to always be 30 though.


>From Tyconvert:

unsigned long size = (((p[0]<<8) | p[1])<<4) | (p[2]>>4);

>From SplitStream:

TyStream[i].size =
(((unsigned int) buf[header_pos]) << 12) |
(((unsigned int) buf[header_pos + 1]) << 4) |
(((unsigned int) buf[header_pos + 2]) >> 4);

Anyone notice the subtle difference between the two? It would only
matter if the first byte was non-zero. Wonder which is correct? :)

> In those unknown 03 packets, the first 4 bytes are always the same:
> 
> 00 01 8E 03 
> 00 01 8E 03 
> 00 01 8E 03 
> 00 01 8E 03 
> 00 01 8E 03 
> 00 01 8E 03 
> 
> I can't tell how tyconvert parses the chunkk, but is it possible it
> reads the "E 03" in the unknown chunks as the "E0 3" in the valid
> video chunks and therefore includes them in the stream? These unknown
> records are in the record portion of the chunk, but apparently they
> do not correspond to actual packets in the rest of the chunk. Once
> tyconvert recognizes the record as valid, though, the data packet
> that tyconvert is expecting to correspond with that "record" is
> missing and then the next *valid* record gets mismatched with the
> packet after the one it really corresponds to, and therefore it
> doesn't match, etc. And tyconvert never recovers.


tyconvert always users the fourth byte to determine the type (third
line of the for() loop:"

type = p[3];

It will always skip any non video/audio records. The key is the
"ofs += size;" after the switch. It skips the unrecognized chunk
in the data section. However, this is assuming "size" is correct".
Playstream and the original extractstream use 8/4/4. Splitstream
and the latext CVS ES use 12/4/4. When I configure tyc to use 12/4/4
it gives a GPF. :( So how does splitstream get away with it? :)


I also added this at the bottom of the switch:


default:
if (type == NON_EMPTY_ID)
fprintf(stderr, "Skipping NON_EMPTY_ID size %d\r", size);
break;

So it will print out the skipped segments.