On Tue, 30 Nov 2004 21:03:56 -0600, David Engel <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 30, 2004 at 10:55:07AM -0500, Doug Larrick wrote:
> Well, pthread_mutex_t seems to have the same problem as QMutex in that
> a precess already waiting doesn't get priority over a process that
> releases, yield
On Mon, Dec 06, 2004 at 07:10:52PM -0600, [EMAIL PROTECTED] wrote:
> BTW, is speed3.patch.gz quality enough for mere mortals to test at this point?
Yes. I want to double check a few things and will probably commit it
tomorrow.
David
--
David Engel
[EMAIL PROTECTED]
_
BTW, is speed3.patch.gz quality enough for mere mortals to test at this point?
On Sun, 5 Dec 2004 20:51:31 -0600, David Engel <[EMAIL PROTECTED]> wrote:
> On Sun, Dec 05, 2004 at 06:00:26PM -0500, Isaac Richards wrote:
> > forwards a few times quickly. I'm just grumbling because CVS has been
> >
On Mon, 2004-12-06 at 17:44, David Engel wrote:
> On Mon, Dec 06, 2004 at 02:32:25PM -0500, Shane Shrybman wrote:
> > I compiled a fresh version from CVS and did some tests. Hopefully this
> > output will be useful.
>
> It was most helpful. Please try this patch.
>
This does seem to fix the pre
On Monday 06 December 2004 06:08 pm, David Engel wrote:
> On Mon, Dec 06, 2004 at 04:44:23PM -0600, David Engel wrote:
> > On Mon, Dec 06, 2004 at 02:32:25PM -0500, Shane Shrybman wrote:
> > > I compiled a fresh version from CVS and did some tests. Hopefully this
> > > output will be useful.
> >
>
On Mon, Dec 06, 2004 at 04:44:23PM -0600, David Engel wrote:
> On Mon, Dec 06, 2004 at 02:32:25PM -0500, Shane Shrybman wrote:
> > I compiled a fresh version from CVS and did some tests. Hopefully this
> > output will be useful.
>
> It was most helpful. Please try this patch.
I'm pretty sure thi
On Mon, Dec 06, 2004 at 02:32:25PM -0500, Shane Shrybman wrote:
> I compiled a fresh version from CVS and did some tests. Hopefully this
> output will be useful.
It was most helpful. Please try this patch.
David
--
David Engel
[EMAIL PROTECTED]
Index: libs/libmythtv/NuppelVideoPlayer.cpp
==
Hi,
On Mon, 2004-12-06 at 11:43, David Engel wrote:
> On Sun, Dec 05, 2004 at 11:11:07PM -0500, Isaac Richards wrote:
> > Cool. Happen to know if thumbnail generation's fixed, btw?
>
> The attached patch might help, but I doubt it. I can't test this very
> well remotely.
>
> The problem appear
On Sun, Dec 05, 2004 at 11:11:07PM -0500, Isaac Richards wrote:
> Cool. Happen to know if thumbnail generation's fixed, btw?
The attached patch might help, but I doubt it. I can't test this very
well remotely.
The problem appears to be in the position map handling, which I didn't
think I'd touc
On Sunday 05 December 2004 09:51 pm, David Engel wrote:
> I relooked at this. All I really care about is syncronizing the speed
> changes. I only moved the other stuff because it seemed logical to
> due so. Since the video/audio/ringbuffer stuff shouldn't have any
> effect on the speed changes,
On Sun, Dec 05, 2004 at 06:00:26PM -0500, Isaac Richards wrote:
> forwards a few times quickly. I'm just grumbling because CVS has been
> slightly broken for a bit now, so really, please don't mind me. =)
I figured you were just having a bad day.
> > > How about reverting Pause() to the state i
On Sunday 05 December 2004 03:29 am, David Engel wrote:
> On Sun, Dec 05, 2004 at 01:23:55AM -0500, Isaac Richards wrote:
> > I'm also not really liking how complicated this whole thing is becoming.
> > =(
>
> I'm sorry you feel that way. If anything, I think the logic is
> getting simpler, and mo
On Sunday 05 December 2004 03:53 am, David Engel wrote:
> On Sun, Dec 05, 2004 at 02:29:21AM -0600, David Engel wrote:
> > Furthermore, I feel the feature changes which lead to the, hopefully
> > temporary, and near ending, chaos have been worth the pain. The new
> > ff/rew is much better, IMO, fo
look at all
the places tv_play.cpp is calling Pause(true), which used to block until
playback was fully paused. It still doesn't block until that with this new
Why do we need to block until the audio output loop is paused at all?
The rest of the audio loop looks fairly thread safe?
On my
On Sun, Dec 05, 2004 at 02:29:21AM -0600, David Engel wrote:
> Furthermore, I feel the feature changes which lead to the, hopefully
> temporary, and near ending, chaos have been worth the pain. The new
> ff/rew is much better, IMO, for the software decoders and is finally
> somewhat useful for the
On Sun, Dec 05, 2004 at 01:23:55AM -0500, Isaac Richards wrote:
> I'm also not really liking how complicated this whole thing is becoming. =(
I'm sorry you feel that way. If anything, I think the logic is
getting simpler, and more importantly, works in a more controlled
manner.
Furthermore, I fe
On Sunday 05 December 2004 01:23 am, Isaac Richards wrote:
> I'm fairly sure that this new Pase() still isn't going to work - look at
> all the places tv_play.cpp is calling Pause(true), which used to block
> until playback was fully paused. It still doesn't block until that with
> this new versio
On Saturday 04 December 2004 11:26 pm, David Engel wrote:
> On Sat, Dec 04, 2004 at 01:54:30PM -0500, Isaac Richards wrote:
> > > > The bigger issue, though, is that there's a _lot_ of code that assume
> > > > that NVP::Pause blocks until certain threads are paused, which isn't
> > > > true with th
On Sat, Dec 04, 2004 at 01:54:30PM -0500, Isaac Richards wrote:
> > > The bigger issue, though, is that there's a _lot_ of code that assume
> > > that NVP::Pause blocks until certain threads are paused, which isn't true
> > > with this patch anymore.
> >
> > OK, that can be handled rather easily.
On Sat, Dec 04, 2004 at 02:44:16PM -0800, Bruce Markey wrote:
> Pressing "E" to enter edit mode always settles at a keyframe
> (MM:SS:01) one to three seconds previous to the playback
> position when the key is pressed. It also moves back when
> switching from pause to edit. Positioning on a keyfra
David Engel wrote:
...
Here's my first cut.
Only found one serious bug. Press ">" or "<" one or more times
then press Pause. Video goes to normal forward speed with no
audio while the OSD reports "Paused" with the progress bar
advancing. Pausing in slo/fast-mo or stretch don't seem to
have this pro
On Saturday 04 December 2004 01:25 pm, David Engel wrote:
> On Sat, Dec 04, 2004 at 02:29:57AM -0500, Isaac Richards wrote:
> > I thought the entire point of breaking everything for this was to protect
> > against those changes being made async?
>
> Not exactly. The point was to make sure certain
On Sat, Dec 04, 2004 at 11:19:52AM -0500, Chris Pinkham wrote:
> > As long as it sleeps in GetFrame for a bit.
>
> I assume in this case that GetFrame would be changed to a bool or int
> type so the return value would indicate whether a frame was "got" or
> not :) so places that expect a new frame
On Sat, Dec 04, 2004 at 02:29:57AM -0500, Isaac Richards wrote:
> I thought the entire point of breaking everything for this was to protect
> against those changes being made async?
Not exactly. The point was to make sure certain things didn't change
in unexpected places.
> The bigger issue, th
> > Whether we add a lock or not, I still think we should strongly
> > consider the change to return early from NVP::GetFrame. Try changing
> > between 1/16 speed and paused to see why.
>
> As long as it sleeps in GetFrame for a bit.
I assume in this case that GetFrame would be changed to a bool
On Saturday 04 December 2004 02:03 am, David Engel wrote:
> On Sat, Dec 04, 2004 at 12:48:50AM -0500, Isaac Richards wrote:
> > > but it should be close enough for others to provide feedback. There
> > > might be a very tiny race condition, but I think it should be
> > > inconsequential, and if it
On Sat, Dec 04, 2004 at 12:48:50AM -0500, Isaac Richards wrote:
> > but it should be close enough for others to provide feedback. There
> > might be a very tiny race condition, but I think it should be
> > inconsequential, and if it turns out not to be, it will hopefully be
> > much easier to fix
On Friday 03 December 2004 11:25 pm, David Engel wrote:
> On Wed, Dec 01, 2004 at 10:29:38PM -0600, David Engel wrote:
> > On Wed, Dec 01, 2004 at 09:50:56AM -0600, David Engel wrote:
> > > I'm going to look at the speed change needs again and see if I can do
> > > something without a mutex that wo
On Wed, Dec 01, 2004 at 10:29:38PM -0600, David Engel wrote:
> On Wed, Dec 01, 2004 at 09:50:56AM -0600, David Engel wrote:
> > I'm going to look at the speed change needs again and see if I can do
> > something without a mutex that won't have race conditions.
>
> Just a quick update. I've made s
David Engel wrote:
On Wed, Dec 01, 2004 at 09:50:56AM -0600, David Engel wrote:
I'm going to look at the speed change needs again and see if I can do
something without a mutex that won't have race conditions.
Just a quick update. I've made some progress, but it will probably be
another day
On Wed, Dec 01, 2004 at 09:50:56AM -0600, David Engel wrote:
> I'm going to look at the speed change needs again and see if I can do
> something without a mutex that won't have race conditions.
Just a quick update. I've made some progress, but it will probably be
another day or two before I'm fin
On Wednesday 01 December 2004 10:50 am, David Engel wrote:
> On Tue, Nov 30, 2004 at 10:21:08PM -0500, Doug Larrick wrote:
> > I am concerned though that this loop is spending way too much time just
> > spinning during normal playback, especially with your getframe.patch.
> > Maybe I'm being dense,
On Tue, Nov 30, 2004 at 10:21:08PM -0500, Doug Larrick wrote:
> I am concerned though that this loop is spending way too much time just
> spinning during normal playback, especially with your getframe.patch.
> Maybe I'm being dense, but where exactly is it that it sleeps (rather
> than busy-wait
David Engel wrote:
On Tue, Nov 30, 2004 at 10:55:07AM -0500, Doug Larrick wrote:
David Engel wrote:
That's the problem! Try changing the decoder_lock from a QMutext to a
pthread_mutex_t and see if that helps. I suspect it will, and will
also get rid of the sched_yield which I didn't like anyway.
Take two, with patches attached!
David
On Tue, Nov 30, 2004 at 09:03:56PM -0600, David Engel wrote:
> On Tue, Nov 30, 2004 at 10:55:07AM -0500, Doug Larrick wrote:
> > David Engel wrote:
> > >That's the problem! Try changing the decoder_lock from a QMutext to a
> > >pthread_mutex_t and see if th
On Tue, Nov 30, 2004 at 10:55:07AM -0500, Doug Larrick wrote:
> David Engel wrote:
> >That's the problem! Try changing the decoder_lock from a QMutext to a
> >pthread_mutex_t and see if that helps. I suspect it will, and will
> >also get rid of the sched_yield which I didn't like anyway. If you
36 matches
Mail list logo
