[mythtv-users] Playback problem -- random short pauses

Paul Gardiner lists at glidos.net
Mon May 23 16:42:14 UTC 2011


On 23/05/2011 17:29, Michael T. Dean wrote:
> On 05/23/2011 12:07 PM, Paul Gardiner wrote:
>> On 23/05/2011 16:42, Michael T. Dean wrote:
>>> If you want to prevent all the "random short pauses" that occur during
>>> playback, simply change your Playback Profile group such that you never
>>> use VDPAU decoding.  Use ffmpeg decode with VDPAU rendering, and all
>>> works well.  The only pauses you'll see is the at-recording-start/stop
>>> pauses (which is a completely separate and unrelated problem).
>> Confused! I thought it was the at-recording-start/stop pauses we
>> were talking about. I don't believe I see any other type of
>> pause on my system, and I'm using VDPAU decode, so I guess
>> I must be lucky.
>
> There are 3 types of pauses that occur during playback with current
> MythTV on a properly-configured system.  These are distinct and
> unrelated issues.  This thread has various users talking about the 3
> different issues and providing information that seems contradictory, but
> that is well explained by the fact that they're discussing very
> different things.  The 3 issues are:
>
> 1) Short pauses that occur when the UI thread is blocked during
> qapp-processEvents() call.  This is the at-recording-start/stop pauses I
> mention.  These will occur regardless of which decoder/renderer you use.
>
> 2) Short pauses that occur due to video buffer starvation due to a
> combination of ffmpeg demux (reading data from the file to pass to the
> decoder) and vdpau decode.  These pauses occur at "random" intervals
> during playback--even when nothing is happening on the backend or the
> frontend.  These can be worked around by not using VDPAU decode--instead
> use ffmpeg decode.
>
> 3) Short pauses that occur at Live TV program boundaries.  These may or
> may not be related to #1, and I know nothing at all about them because I
> don't use Live TV.

Oh yes. I see 1 & 3. I forgot about 3 when posting before. I had assumed
they were closely related, imagining that the backend was more or less
stopping and restarting recording at program boundaries when in LiveTv mode.

On the subject of 3, some of the transmission can be lost. I had such
a pause right on the punch line of a joke at the end of QI. When I
replayed the recordings (out of LiveTv mode), I found that the punch
line was not at either the end of the program recording nor at the
beggining of the next.

> So, if you use ffmpeg decode (rather than VDPAU decode), you'll only see
> #1 and #3.  Issue #1 only occurs when the backend starts or stops a
> recording (so generally happens on the top of or half past the hour, and
> only while you're actually recording shows while watching other
> recordings).  Issue #3 only occurs in Live TV, as it's a Live TV
> specific thing, and only occurs on program boundary/when the backend
> stops and starts the Live TV recordings.
>
> Also, it's possible that specifying videobuffersize=32 in the filter
> section of the VDPAU-decode playback profile may work around the VDPAU
> video buffer starvation issue (#2), but that may "undo" all the changes
> that have allowed use of VDPAU on low-memory video cards (like 256MB
> cards)--you'll likely need a 512MB or greater card.  We're still testing
> this, and would appreciate users providing feedback about whether it
> helps or not.  This may be why you're not seeing the VDPAU issues, Paul
> (so please let us know if you have specified videobuffersize or other
> filters).

The only explicitly given filter I have is vdpaustudio. I'm using,
minimyth so there could possibly be settings made behind the scenes,
but I don't believe the profile filters are altered.

Paul.


More information about the mythtv-users mailing list