[mythtv] How would one speed up the channel changing in mythtv ?

John van Timmeren vantimmeren at gmail.com
Sun Oct 19 15:23:16 UTC 2008


Tweaking the configuration didn't get my channel switching below 2
seconds (possible even a little more). And I think i've tried it
all...

FYI a link to a general discussion about the channel switch speed,
explaining some of the previous anwers.

http://www.gossamer-threads.com/lists/mythtv/users/346910


And below a recent discussion about a problem that with some extra
effort could speed up channel switching:


> From: Daniel Kristjansson <danielk at cuymedia.net>
> Subject: Re: [mythtv] Ticket #5749: Internal player stutters on 720p content
> To: "Development of mythtv" <mythtv-dev at mythtv.org>
> Date: Sunday, 5 October, 2008, 12:49 AM
> On Sat, 2008-10-04 at 14:12 -0500, David Engel wrote:
> > On Sat, Oct 04, 2008 at 12:20:17PM -0400, Michael T.
> Dean wrote:
> > > On 10/03/2008 11:54 AM, zgeggy2k wrote:
> > > >  One thing I haven't tried is running it
> as root _with_real_time_priority_
> > > >  settings (which hopefully even CFS would
> honor). I'll give it a try.
> > >
> > > Do they enable GROUP_SCHED?  If so, are they
> using USER_SCHED as the
> > > "Basis for grouping tasks?"  If so,
> that's almost definitely the issue
> > > and your system configuration should be fixed.
> >
> > I have GROUP_SCHED and USER_SCHED enable in my
> self-compiled kernel
> > but haven't done anything to explicitly enable it
> at run-time on
> > Debian Sid.  For grins, I rebuilt and tested a kernel
> with GROUP_SCHED
> > and USER_SCHED disabled.  It made no difference -- the
> stuttering is
> > still there.
> > David
>
> The problem Michael identified is very interesting and it
> explains why
> I was having performance problems with recent kernels, but
> I think
> Janne just found the root of your problem, the audio in
> your files is
> 500 ms behind the video, but in AVFormatDecoder we only
> read audio
> packets as far ahead as we read video packets. Fixing that
> problem
> is not a trivial undertaking, but on the positive side with
> a just
> a little extra work it will probably also speed up channel
> flipping
> and may make XvMC decoding work much more effectively.
>
> Note: To work well, XvMC currently requires a faster CPU
> than software
> decoding, which makes it pretty darn useless. This is
> probably in large
> part because it requires the audio to be decoded in much
> less time since
> we only have 5 usable XvMC frames instead of the 31 we
> currently have
> for software decoding. We may also be able to greatly
> reduce that 31
> frame number with the AVFD refactor in place.
>
> -- Daniel
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


More information about the mythtv-dev mailing list