[mythtv] Ticket #5749: Internal player stutters on 720p content

Daniel and Mary-Beth Sherwood jackanddougal at yahoo.co.uk
Sun Oct 5 16:57:01 UTC 2008


Guys

I have been following this thread in the background and I was just wondering if it was related to the issue I idenetified in #5265.  Basically stutteriung can occur if the file has two audio streams with significantly differnt offset from the video. (in my case, one 700ms ahead and one 200ms behind).

Due to a bug in avformat decoder, the wrong audio track can sometimes be used to determine A/V sync status and confuse the player (only generally with XVMC).

Can you try the patch attached to #5265 to see if that fixes your problems (it did for me).

Cheers

Daniel


--- On Sun, 5/10/08, Daniel Kristjansson <danielk at cuymedia.net> wrote:

> 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