SplitStream 0.3 and other utils

[joe666boxer@y...]

> Since my source raw tystream is almost 4G, compiled splitstream by 
> default (use 'gcc -o splitstream splitstream.cpp') will crash on 2G 
> limit. So I enable LFS support by using 'gcc -D_FILE_OFFSET_BITS=64 -
> D_LARGEFILE_SOURCE -o splitstream splitstream.cpp' to compile. BTW: 
> to do this you require glibc 2.2 or later. This time finished 
> happily. My output is listed below.

Thanks for the info. I had no idea you had to force 64bit file
pointers using gcc.

> 
> > The time estimates that splitstream displays are it's best guess 
> as to
> > the time offset between the audio and video. It displays two 
> values;
> > typical output looks like:
> > 
> > estimated audio delay from first video -174.600000 ms
> > estimated audio delay from earliest video -107.855556 ms
> > 
> 
> Joe, would you mind to explain what these two output lines means, 
> and how they gonna be used in video editing? I couldn't figure it 
> out myself yet.
> 

the only annoyance I have with my streams is that there is a constant
offset between the audio and video. When I convert to divx+mp3, in the
last step, I adjust the sound (using nandub) to match the video. It's
not easy, so I wanted something to help. I looked closely at the PES
headers in tyStream, and found what looks like a timestamp. The clock
seems to tick 0x1950 for every 36 ms. I've converted a couple of
streams since I added that feature and it seems one of those values is
very close to the actual offset. I'm looking for feedback on this.

I just noticed something interesting. The difference between the two
values is exactly a multiple of 33.37 ms (which is the frame time of
an NTSC signal @ 29.97 fps). It seems I have the time conversion right.

How you use these values depends on what you want to do with the
video. Any decent setup should allow you to adjust the audio delay and
that's where you should use those. If the audio is late (negative
numbers displayed by splitstream), you could even try to delete 0x360
byte size packets from the begining of the audio stream; each packet
lasts 36 ms. So suppose I wanted to strip off 174.6 ms, I would then
delete 5 packets, which would cause the audio to be early by 5.4 ms
(hard to notice).

Thanks for the field test. I wish more people would try it out.

Joe