ok who has extractstream working 100%?

by Gateway August 1, 2001 07:01 PM

Posted in: Upgrading

ok after 3 weeks of messing around now I have yet to rip a complete show without any audio or video errors in it. Im not sure whats going on but I get alot of these..

bash-2.02# ExtractStream 1166768 1166769 1166770
Attempting to locate tyStream with fsid 0x11cdb0...
...tyStream located, sector map follows:
Start Length
05608c00 00100000
Block: 5608c00 Count: 1048576 Total blocks 1
Playing block 05608c00/dev/hda10 has 0x00100000 sectors
/dev/hda11 has 0x03606c00 sectors
/dev/hda12 has 0x00002000 sectors
/dev/hda13 has 0x03a9d400 sectors
Bad chunk, skipping
Playing block 05708c00Bad chunk, skipping
Attempting to locate tyStream with fsid 0x11cdb1...
...tyStream located, sector map follows:
Start Length
01c00000 00100000
Block: 1c00000 Count: 1048576 Total blocks 1
Playing block 01c00000Bad chunk, skipping
Playing block 01ce8700Sequence number bogus 2a6d2c!=2a6d84 at record 17 of 33
Playing block 01ce8800Sequence number bogus 2a6d2c!=2b56c8 at record 0 of 46
Playing block 01ce8900Sequence number bogus 2a6d2c!=2067ac at record 0 of 38
Playing block 01ce8a00Sequence number bogus 2a6d2c!=224ba4 at record 0 of 23
Playing block 01ce8b00Sequence number bogus 2a6d2c!=243f30 at record 0 of 21
Playing block 01ce8c00Sequence number bogus 2a6d2c!=26364c at record 0 of 21
Playing block 01ce8d00Sequence number bogus 2a6d2c!=282a0c at record 0 of 18
Playing block 01ce8e00Sequence number bogus 2a6d2c!=2a1a90 at record 0 of 39
Playing block 01ce8f00Sequence number bogus 2a6d2c!=2bf7f8 at record 0 of 30

..
sometimes its only 1 or 2.. but it cant be good.. my audio burps every so often video seems fine for most part..

i have the latest extract stream for the cvs tree dated july 8th, are there any newer versions?

all my recordings are on the highest quality setting, and I extract to my pc box with nfs using warnfs client on the pc side of things..

ideas ??

Gate

Discussion:

Marc on August 2, 2001 4:04 AM

I had the same problem, to such an extent that I removed the sequence bogus checking entirely. The output is much cleaner, but not perfect. It's basically the same as the output I get from ConvertStream - kinda works, kinda doesn't.

Source for my changes are here and the TiVo compiled binary is
here

robin on August 2, 2001 9:37 AM

Originally posted by Marc:
I had the same problem, to such an extent that I removed the sequence bogus checking entirely. The output is much cleaner, but not perfect. It's basically the same as the output I get from ConvertStream - kinda works, kinda doesn't.

Source for my changes are here and the TiVo compiled binary is
here


Whatever works, go with it BUT...

As has been repeated many times before, the "bogus" messages are not errors, just informational. There should be a few every once in awhile, and a lot at the end.

In TiVo v1.3 captured video, checksumming was used. In v2.0.1, sequences are used. ExtractStream assumes the latter. If you don't follow the sequencing, then you'll get small (less than 1 second) audio/video clips from unrelated programs, and that will drive most multiplexers nuts.

Remember you're dealing with encoding hardware that writes directly to the disk given chunks of disk allocated by some driver. Why the encoder quits writing to a chunk and then continues writing to another chunk is unknown... but that's what it's doing, and the sequence numbers allow you to keep it straight.

The majority of the bugs we've seen have to do with the sequence number restarter: after loosing sequence, how do we know where to start again. The code that believes it knows the restarting pattern is:

Code:


The obvious problem is: if the sequence restarter code is incorrect, we could loose major chunks of valid data (if we don't see the restarter, then everything after that will be bad, until we see a restarter we like).

Since you seem to know how to program, monitor what's being thrown away and see if it's a variation of the above pattern.

Hypothetically, this code could also be the source of the sync problems (I don't know -- I don't have sync problems). The sequencing tracks video data only. When we loose sequence, the rest of the chunk is thrown away, including all audio. We've worked with a few variations of this, and the "discard the rest of the chunk" approach has worked best. Maybe there's a way to determine if a few of the upcoming audio packets should be saved. Worse, maybe some of the audio that has already been processed should have been thrown away.

Nick has a better grasp on the sequencing code, he might have a different opinion.

Gateway on August 2, 2001 2:05 PM

I have been doing encoding for several years now and have never run into such problems with extract stream.. my set up is tivo philips, tivonet, nfs (warnfs).

The video seems fine for most part some times i get some pretty bad errors and video doesnt play at all just the first frame.

my main problem is with audio burps.. when playing back the .m2a track before muxing i notice that at some points it would hic-up or speed up really quick for like .05 of a second, this is deff noticable when played together with the video.

-Gateway