[ExtractStream] Re: Status of Windows tools ==> Linux Solutions

[Dale Reed]

willieb9000@y... wrote:

> >
> > dir and a stopwatch? :) 
> 
> Ok, I am laughing at myself here -- I guess I just thought there
> would be a more techno way to do it(which I am sure there is, but for
> my own info, a watch should work fine :))


Sorry, I couldn't resist a little humor. I usually just do a dir
60 seconds into it and divide by 60 to get the rate. My home
system is running WindowsXP and its new task manager includes a
networking graph similar to the processor graph that you can use
to determine throughput on differnt interfaces and such. It
works pretty decent as well.


> Now, you said you use Tivoweb -- have you looked at the resource
> manager in there? I think it tells you the bitrates tivo uses to
> record stuff -- my tympeg is crapping out a lot on ty streams. It


The encoded bitrate is a byte in the recorded db entry. The display
just translates that, not the actually tystream.

> says "can't find first frame" a lot and just stops. pretty annoying
> becasue I don't know when it will happen. You mentioned that you were
> still working on making the app more tolerant. It this what it does
> when it is being intolerant? When it works, though, it seems to get
> sync.


I haven't ran into that a lot, except when my tystreams where corrupt.
The more tolerant is where tympeg will just stop half way through
encoding something with an error. If you use convertstream on the
tystream file, convertstream just keeps going after the error.


> And I guess I told you some of my mpgs were being played at a really
> slow pace -- I was wondering if the wrong bitrate info could cause
> that. Check out the tivoweb resource manager and let us know what you
> think.


I've seen this before as well. My guess is that the mpeg isn't being
put together right. My understanding of mpeg is that you get a full
frame of data, then several "updates" to the original frame. If you
use DisplayStream, you'll see something like Video and Vid-P, which
I believe are the full frames and updates, respectively.

The error you are seeing above (can't find first frame) is because
if can't find the first "full" frame in the first packet. I would
guess just going to the next packet until you found a full frame
would work.

The display where it looks like a slide slow could be caused by it
only finding the full frames. However, they usually are not synced
with the audio. I'm still digging through all this and time is
tight right now. :(


> Oh, and A few of us have been using regular ES lately using the -p
> option and are getting sync in tmpgenc. The docs say -p is no longer
> necessary, but it seems to be working. Any idea or comment on this --
> try it if you have time -- could it be that these PES header give
> the "muxer" a cue as to how to match them -- I don't know what they
> do -- we are just speculating. THought you might like to know and
> comment though.


I'll look at the ES code and see what it does. I think the PES
header does give an offset of some kind, which could be used to
keep the audio/video in sync.



Dale