skorous@y...

[skorous]

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

I'm not home at the moment but I'll try to get back to you either 
tonight or tomorrow morning with my results. Thanks again for your 
help.

> 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.

See I thought that was a problem. I'll try this patch and see if my 
numbers come out the same.


> >2) I don't recall getting source with my splitstream (memory is
> >faulty so I'll have to check of course) but do you have a pre-
> >compiled version? Also, does splitstream compile under Linux?
> 
> Its available. I will attach what I am using. Here are the caveats 
:
> 
> [1] I have only compiled it for Linux. It supposedly will compile 
for 
> Windows, but I haven't tried that. Actually I don't see why it 
couldn't 
> even work in DOS if the "ints" were declared as 'longs".

A linux version is actually better for me because I'm using NFS to 
send the files so any step I can automate on to the Linux box saves me 
several steps in the Windows end.

> [2] I will include the pre-compiled linux bin, but if you want to 
recompile 
> the source the command is :
> gcc -m486 -O2 splitstream.cpp -o splitstream
> The pre-compiled bin is in ELF static format which is why its so 
big. If 
> you know how do yourself a favor and recompile. I wasn't sure how 
much you 
> knew how to do.

I don't mind having a static linked version for the moment. It allows 
me to transfer it back and forth between several different machines 
without worrying about library issues (at least one of the machines I
may test this one has it's libraries mangled from a faulty upgrade 
that I never got around to fixing <grin>). 

> [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.

You can never have to much error logging. Thanks for the heads up 
though as it would have concerned me at first...

> [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.
> 
> [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.
> 
> Now compare the audio length. You'll quickly find out if this fixed 
> it. Let me know, I'm very curious to know if this bug could cause 
bad sync.

Not a problem.

> 3) I also have digital cable, how often have you come across a chunk
> >with > 255 records? I remembered reading your message about the
> >faulty computation but don't remember you ever having some across
> >them. I'm just curious how likely this is.
> 
> I recorded Jeremiah off Showtime. Its 1hr and 40min. Scanning the 
log, I 
> find there are 10 instances where there were more than 255 records 
in a 
> chunk. A record is basically a single unit of audio or video. Of 
those I 
> think the highest was 287 records. So, yes it does happen. How 
likely 
> depends on what you're recording. Since each record is a unit of 
video or 
> audio, the size of the unit depends on the audio or video. If 
neither are 
> changing very fast then what happens is the record size is small 
(little 
> data to store), so it can squeeze more records into a chunk (A chunk 
is 
> 128KBytes). A prime example for when this can happen is while the 
cable 
> box is changing channels. Mine either turns off or blanks the 
> display. Result is the TiVo is compressing 4 or 5 seconds of black 
> screen. Very few bytes per video frame, but a record for every 
video 
> frame, so in 4 seconds it will store 4 x 30fps = 120 video records 
> minimum. There are also alignment packets so the total is higher. 
Then 
> consider the audio packets and unknowns and it is obvious why it can 
go 
> above 255. 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.
> 
> 
> 
> 
> 
> 
> >Thanks for your help and thanks to everyone who's done all the pre-
> >cursor work for this project.
> >
> >Marty
> >
> >
> >Yahoo! Groups Sponsor
> >ADVERTISEMENT
> >
> >To unsubscribe from this group, send an email to:
> >ExtractStream-unsubscribe@y...
> >
> >
> >
> >Your use of Yahoo! Groups is subject to the 
> ><http://docs.yahoo.com/info/terms/>Yahoo! Terms of Service.