Re: [mythtv] sound + xvmc + livetv = problem, why?
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 of > 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@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev ___ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv] sound + xvmc + livetv = problem, why?
On Sun, 2006-01-29 at 19:27 -0500, Isaac Richards wrote: > > 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.. > > I believe it was set there because we don't want it for the null videoout > method. I would've sworn it was always forced on for both types of xvmc, too, > but I don't see that anywhere. > > There's a place in avformatdecoder that seems like it'd be disabling the > forced on extra buffering as well, in InitVideoCodec. Might want to check > that that's not causing problems either. Hmm, I wasn't aware of the null decoder wrinkle. We could just check the using_null_videoout boolean instead right? I'll also check InitVideoCodec.. -- Daniel ___ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv] sound + xvmc + livetv = problem, why?
On Sunday 29 January 2006 18:55, Daniel Kristjansson wrote: > 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 of 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.. I believe it was set there because we don't want it for the null videoout method. I would've sworn it was always forced on for both types of xvmc, too, but I don't see that anywhere. There's a place in avformatdecoder that seems like it'd be disabling the forced on extra buffering as well, in InitVideoCodec. Might want to check that that's not causing problems either. Isaac ___ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
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 of > 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@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv] sound + xvmc + livetv = problem, why?
> Anyone have an idea what might be happening here?
Dunno guv? :)
I've been trying to pin this down for a couple of weeks because it's been
stopping me migrating to SVN for 'live' and I so want the current svn +
the radio patch.
At the moment I've only a subjective view - fwiw my 2c:-
What seems to be happening is that the audio/video is thrashing in trying
to get sync - logs showing audio in front/video in front etc. You can get
lucky in changing back and forth between channels (possibly quiet
audio/video patch) when the thing will start in sync and stay in sync
- in my case combined front/backend on an epia 10k running at 20%cpu
(720x576 no HD signal on UK freeview)
More often it starts out of sync and stays out- when its out of sync and
thrashing cpu is maxed out. (pausing sometimes fixes it) So its sort of
self perpetuating, catchup seems to need cpu cycles which are not there -
and the catchup goes too far anyway.
With this viewpoint I'd bumped the ringbuffer cache and added the EIT
caching patches - these freed up some cpu and made it more likely that a
channel change would solve the problem - but not reliably. Of course
compiling with debug makes the problem more visible! (Actually 8675 with
the EIT cache patch was usable - but current (8765) isn't)
I'vd been trying to understand the sync algorithm - but haven't got there
yet :( - I thought I'd solved it with the change below when I realised
avsync_adjustment could be +ve/-ve
{{{
Index: mythtv/libs/libmythtv/NuppelVideoPlayer.cpp
===
--- mythtv/libs/libmythtv/NuppelVideoPlayer.cpp (revision 8766)
+++ mythtv/libs/libmythtv/NuppelVideoPlayer.cpp (working copy)
@@ -1625,7 +1625,9 @@
if (buffer)
videoOutput->PrepareFrame(buffer, ps);
-videosync->WaitForFrame(avsync_adjustment);
+if ( avsync_adjustment >= 0 )
+videosync->WaitForFrame(avsync_adjustment);
+
if (!resetvideo)
videoOutput->Show(m_scan);
}}}
However whilst this gives me relatively reliable startup the stuttering
starts after 30-40s or so.
(All this on 2.6.14, UK-PAL, EPIA 10k,bttv & ttusb_dec drivers)
cheers & good luck
jim
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv] sound + xvmc + livetv = problem, why?
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 of how much extra audio to decode is around line 2210 of avformatdecoder.cpp (the 'storevideoframes' bit). It just compares timestamps, fairly simple stuff.. Isaac ___ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv] sound + xvmc + livetv = problem, why?
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. -- Daniel ___ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv] sound + xvmc + livetv = problem, why?
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. > > I'm not very familiar with how the audio decoding works in MythTV. > But it seems that the audio buffers aren't getting filled quickly > enough when you are in LiveTV and using XvMC. This causes the A/V > sync routines then kick in to slow down the video to match the audio > speed, which in the meantime plays a sample, mutes, plays a sample, > mutes, etc. > > This does not happen when you playback a recording, and the CPU > utilization is lower when you play the same stream in LiveTV vs. > playing back the recording. What I did notice is that with XvMC, > when you pause a playing recording the audio '-v audio' debug > keeps going, but it stops when you pause in LiveTV. With XVideo > output, it keeps going in either case. > > I've tried upping the ringbuffering and I'm using ChromaKey OSD > so I don't think the problem is with video (and the CPU is at 40% > in LiveTV on a 1080i stream, and 70% playing a 1080i recording). > > AFAICT Everything points to audio, but I don't understand how that > would interact with LiveTV mode. (I even tried removing the avlock > locking, to see if there was some lock contention, it had no effect.) > > Anyone have an idea what might be happening here? Does pausing for a few seconds, then unpausing help at all? Isaac ___ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
