Changes to zss... & Fixes to splitstream

[Edmond E. Shwayri]

While you're working on ZSS, here are a couple of "bugs" I found in 
splitstream :

Find this :
num_recs = (int) buf[0] /* +(((int)buf[1]) << 8) */ ;

I do not know why the author commented out the +(((int)buf[1]) << 8) since 
that is the correct way to calculate it. The number of records in a chunk 
is an integer, not a byte. The first byte is the least-significant and the 
second byte is the most-significant. If this is not corrected, splitstream 
will only process the first 255 records and ignore the rest. This throws 
off the sequences and the result is half your file ends up being considered 
"bad". It is rare for a TyStream chunk to have more than 255 records, but 
it IS possible.

A person who records off of an analog channel may never see this. The 
amount of video and audio data streaming in is large since there is a 
constant signal with a lot of noise in it. Lots of video and lots of audio 
means a low number of records per-chunk. A person like me who is recording 
off of digital cable has a much cleaner signal that is much more 
compressible. During a quiet time where the screen may go black and the 
audio is muted there is very little data and if this continues for a few 
seconds you will see many records with little data and you may very well 
have more than 255 records per-chunk. On a 1hr 40 min stream it occurred 5 
seconds into the stream as the TiVo told the cable box to switch channels 
(cable box turns off video for about 4 seconds while switching) and a 
couple of times inside the stream, probably during scenes where there was 
no picture change.

The fix for this not to happen is to change the above line to (ie- 
uncomment the second part of the equation) :
num_recs = (int) buf[0]+(((int)buf[1]) << 8);

And :
struct TyStreamHeader TyStream[0xff];

To :
struct TyStreamHeader TyStream[2000];

The proper way to do this would be to dynamically re-size the TyStream 
variable as needed, but that's a lot of work and 2000 is good enough. If 
not then raise to the maximum number of records you think a chunk will have.

Second observation is in the calculation of the correct audio offset. I 
quickly noticed that neither number splitstream offered me were 
appropriate. Here is the first audio PES header and then the first 16 
video PESs.

PES Audio Header Found....Result = 1083.644444

[1] PES Video Header Found....Result = 1178.833333
[2] PES Video Header Found....Result = 1112.088889
[3] PES Video Header Found....Result = 1145.455556
[4] PES Video Header Found....Result = 1212.188889
[5] PES Video Header Found....Result = 1245.555556
[6] PES Video Header Found....Result = 1312.288889
[7] PES Video Header Found....Result = 1345.655556
[8] PES Video Header Found....Result = 1412.388889
[9] PES Video Header Found....Result = 1445.755556
[10] PES Video Header Found....Result = 1512.488889
[11] PES Video Header Found....Result = 1545.855556
[12] PES Video Header Found....Result = 1679.333333
[13] PES Video Header Found....Result = 1612.588889
[14] PES Video Header Found....Result = 1645.955556
[15] PES Video Header Found....Result = 1712.688889
[16] PES Video Header Found....Result = 1746.055556

The offsets splitstream calculates are :
begin_audio_time = 1083.644444 ms, first_video_time = 1178.833333 ms
begin_audio_time = 1083.644444 ms, begin_video_time = 1112.088889 ms
estimated audio delay from first video -95.188889 ms
estimated audio delay from earliest video -28.444444 ms

For me the correct calculation is obtained with the 13th video PES time-stamp :
1083.644444ms - 1612.588889ms ~ -529ms

We need to better understand at what point to calculate the sync. I would 
be very interested if people who use the other number could send me the 
first 20 - 30 video PES headers (If you're willing EMail me and I can send 
you a modified splitstream that does this). If I were to guess the proper 
way would be to seek say 30 PES records forward then start going backward 
until the next value is greater than the current value. The theory being 
that the video starts being in sync when its PES time-stamp increases 
linearly for the rest of the file. The reason mine may be different may 
again be the digital cable box and the fact that it takes the MPEG encoder 
longer to get a VSync which from my reading of the specs on the MPEG chip 
is when the sync is locked. This is a guess though which is why it would 
be interesting to compare the PES from various people to find the pattern 
and once and for all spit out one number.