[mythtv] sound + xvmc + livetv = problem, why?

Rob R rob.r at plutohome.com
Mon Jan 30 17:38:27 UTC 2006

That would make sense.  The "slow motion" I see with xvmc now is exactly the
same behavior I saw when "extra audio buffering" was disabled in the
previously working versions.

-----Original Message-----
From: mythtv-dev-bounces at mythtv.org [mailto:mythtv-dev-bounces at mythtv.org]
On Behalf Of Daniel Kristjansson
Sent: Sunday, January 29, 2006 3:56 PM
To: Development of mythtv
Subject: Re: [mythtv] sound + xvmc + livetv = problem, why?

On Sun, 2006-01-29 at 17:17 -0500, Isaac Richards wrote:
> On Sunday 29 January 2006 16:58, Daniel Kristjansson wrote:
> > On Sun, 2006-01-29 at 16:40 -0500, Isaac Richards wrote:
> > > On Sunday 29 January 2006 14:38, Daniel Kristjansson wrote:
> > > > I've been looking at ticket #774 a little more closely since it
> > > > seems to be effecting more users and it makes the EPIA pretty
> > > > useless as a frontend in LiveTV mode.
> > >
> > > Does pausing for a few seconds, then unpausing help at all?
> >
> > It has been reported to help, but it hasn't made any difference in
> > my testing.
> Well, I'd play with the extra audio buffering code - you should be able to

> force it to decode more audio and defer video decoding with that.  Logic
> how much extra audio to decode is around line 2210 of avformatdecoder.cpp 
> (the 'storevideoframes' bit).  It just compares timestamps, fairly simple 
> stuff..

Hey, it looks like the problem may be right there, extra audio buffering
is not set if the decoder is recreated but not the video output method.
For some reason this decoder setting is being set in NVP::InitVideo
instead of NVP::OpenFile where all the other decoder options are set..

It isn't the whole problem, but combined with the fix for #774
that bob.r AT plutohome.com posted this appears to fix the problem.

-- Daniel

mythtv-dev mailing list
mythtv-dev at mythtv.org

More information about the mythtv-dev mailing list