Re: [Mvpmc-devel] Fix for seeks

[<ge...@ac...>]

OK, I changed the patch around last night to use the STC timestamp if it
is within 10 seconds of the GOP timestamp.  Otherwise, use the GOP timestamp
as the starting point for the jump.  This works great on my system, since
it always uses STC.  On yours, I assume it will always use GOP.

I also added a default of 4mb/s if the bitrate is 0.  I don't know what the
best choice here is, but 4 seemed like a reasonable middle-of-the-road value.
Perhaps 5 is better, I don't know.

I'll check this in tonight, and package up a development release for the rest
of you to play with.

As for the number keys, I probably messed something up when I moved to the
current threading model.  I don't use them much, but when I do, they seem to
work.  I'll look into that as well.

Jon

> Ok,
> 
> This is similar to the fix I looked at way back when, where I hacked up the
> same thing. The problem is that the GOP value and the av_current_stc() is
> way out, (at least 30 secs) and therefore it jumps a few times and then
> either finds a random position or more often goes off the end of the
> recording.
> 
> For me this fix is much better. What is missing in this patch is a default
> value for the avg_bps value. Some of the UK DVB-T recordings show up as 0
> Mb/s and therefore they dont seek at all.
> I have added a local fudge of forcing the initial guess to allways be 5
> Mb/sec, which the patch then tries modifies if it is way off, which seems a
> neat way of doing it. Having a method that defaults to stc but uses gop when
> needed sounds elegant to me.
> 
> I am still having problems with the seek 0-9 function. On the old 1.4 code
> this works like a dream. On the latest versions it takes several pushes on
> the button to get it to move to the x*10% point.
> 
best regards,
> 
> John
> ----- Original Message ----- 
> From: <ge...@ac...>
> To: "C Western" <mf...@ds...>
> Cc: <>
> Sent: Monday, October 25, 2004 5:17 AM
> Subject: Re: [Mvpmc-devel] Fix for seeks
> 
> 
> > > I have added a patch to the "patches" section on sourceforge that fixes
> > > severe problems I was having with skip forard and reverse.
> >
> > OK, I do have one issue with this patch that I overlooked before.  The
> > method of seeking based of the GOP timestamp in the demuxer could mean
> that
> > your seek is off by up to 5 seconds or so, since the GOP timestamp is
> really
> > the timestamp for the last GOP header in the demux buffer.
> >
> > So, is the problem that you're having that is returning
> > a timestamp that is totally unrelated to the GOP value?  If so, we could
> > compare the two, and if they are way off (ie, more than 10 seconds), then
> > use the GOP timestamp, otherwise use the STC timestamp.
> >
> > Basically, this patch makes the 30 second skip worse for me.  If it gives
> > you a 30-40 second skip versus a random skip, then we should move to some
> > solution like this.  But I think we should use the STC timestamp whenever
> > we know we can trust it.
> >
> > Jon
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> > Use IT products in your business? Tell us what you think of them. Give us
> > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
> more
> > http://productguide.itmanagersjournal.com/guidepromo.tmpl
> > _______________________________________________
> > Mvpmc-devel mailing list
> > Mvp...@li...
> > https://lists.sourceforge.net/lists/listinfo/mvpmc-devel
> >
> >
> > _____________________________________________________________
> > This email was filtered by Frontgate MX - the free spam and content
> filter.
> > url: www.frontgatemx.com
> >
> >
>