skorous@y...

[skorous]

--- In ExtractStream@y..., "Edmond E. Shwayri" <eshwayri@n...> wrote:

> Thats a problem. Mine are exactly the same. On the Jeremiah
> program the audio reports 100:01 (WinAmp doesn't report msec) and
> the video reports 100:01.552. Obviously the same to the second.
> Sounds to me like you're losing audio frames.

Ok. I think I should expand on this. Splitstream claims that both of 
my streams should be the same length. In my most recent case I ripped 
a Formula1 race. Splitstreams says:

last audio time 02:45:6488.820 last video time 02:45:6489.74

Now I'm a bit confused on how to interpret that. 2:45 I understand 
and 2 hours 45 minutes. That's easy. 6488.820 seconds confuses me a 
bit. But anyway, if I pull the two streams up in Windows Media Player 
the video is 2:45:14 whereas the audio is only 2:45:08. Using my 
ultra-accurate timing method (one mississippi, two mississippi, 
<grin>) the audio at the end appears to be off by about 6 seconds. 
I'm assuming that TMPEnc is trying to sync them up by time index 
rather than PES codes though I dont' entirely understand what a PES 
code is...

> [3] Mine is dumping out A LOT of messages (namely the PES header
> stamps) onto stderr. This amounts to about 14 megs of data, so be
> sure to re-direct to a file so your video card doesn't have to
> display all of it. splistream myfile.ty myfile.m2a mfile.m2v +
> 2>debug.log If you don't want to see that info, remove the offending
> fprintf statements in the source.
> [4] Have a look at debug.log and look for
> Warning: second byte in chunk 14345 is non-zero 24:1
> Every time you see a message like that it means there were more
> than 255 records in the chunk its reporting. Since this is a
> patched splitstream this won't be a problem. I left this in there
> just to see how often this happens.

I didn't have any errors like that throughout the program. However I 
did have several "Warning: large sequence mismatch" messages and a 
couple of "Warning Video Sequence number out of wack by a little" 
messages. 

> [5] If you could send me the first oh say 50 lines of the debug.log
> and the audio offset value you used. I am trying to figure out
> what pattern there is for determining the audio offset. Some
> people need the low number, some need the high number, and others
> like me can't use either.

My two choices were:
estimated audio delay from first video -113.233333 ms
estimated audio delay from earliest video -46.488889 ms
and the -46 number worked out pretty well. Well, at the beginning it
did. As stated, farther in to the file it gets progressively farther
out of whack.

> Problem is if it does, splitstream just ignores the ones above 
> 255 and gives you an unexpected sequence error, but continues on.
> Result is you lose whatever was in those packets. A more difficult
> thing to jusdge is how that loss affects the streams. 
> Theoretically, in a perfect world, the streams should be placed
> back into sync by their PES time-stamps, but I wouldn't bet on it.

My experience thus far would seem to prove that the PES headers don't
seem to do much at least thus far... Perhaps I've got a setting wrong
somewhere.

Marty