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

[Andre]

On 31 May 2011, at 14:37, Christopher Kerr wrote:

> On Tue, May 31, 2011 at 10:40 PM, Andre <mythtv-list at dinkum.org.uk> wrote:
>> 
>> On 23 May 2011, at 20:51, Michael T. Dean wrote:
>> 
>>> On 05/23/2011 03:20 PM, Steven Adeff wrote:
>>>> On Mon, May 23, 2011 at 3:06 PM, Daniel Kristjansson wrote:
>>>>> Removing the fsync() call can lead to pauses, in the unlikely event that
>>>>> it is being called on a Linux system. The fdatasync() and range syncs
>>>>> are mostly no-ops since we're appending to a file, so removing those
>>>>> will have no effect. The main reason the fsync() was added was to
>>>>> prevent pauses on when the disk I/O scheduler decided to finally write
>>>>> hundreds of megabytes of data to disk in one long write and consequently
>>>>> starve all readers and so stop video playback. This was accidentally
>>>>> subverted when the fdatasync() code was added. But that change happened
>>>>> over five years ago so if you are seeing a regression with 0.24, fsync()
>>>>> changes are not to blame.
>>>> That's what I figured.
>>>> 
>>>> It sounds like, from what Mike says, the issue has to do with VDPAU
>>>> decoding and the interaction with ffmpeg (Mike, am I understanding
>>>> that correctly?).
>>> 
>>> Yes.  (That's right for issue #2.)
>>> 
>>>>  So I don't think chasing i/o is the way to attack
>>>> this. It sounds like Mike and the other dev's looking at the issue
>>>> have an understanding of what's causing VDPAU to do this. Hopefully a
>>>> solution can be found that still lets users take advantage of using
>>>> VDPAU with ATOM-like systems.
>>> 
>>> Though this not so much--the other devs are looking into this, not me.
>>> I'm only relaying what info I've learned from them (and from my own
>>> testing that I've done, in part, for them).  :)
>> 
>> Any tests that we can do to expand the data set? I'm assuming that not every hardware configuration exhibits these problems.
>> 
>> I'm primarily concerned with problem #2, the others I can tolerate more easily and they can be mostly avoided (I don't watch live TV), for me #2 is the nasty one. I'm almost at the stage of burning BD-RE's to be able to watch important stuff properly. :-(
> 
> Issue #2 is exhibited on every machine I have using VDPAU decoding  -
> 2 Ion's and an 8500GT. I understand from Michael T. Dean's post that
> it affects most (all?) machines using VDPAU decoding.

I dragged the i7 860 GT220 machine from the office and gave that a try, so far completely glitch free playback with vdpau, glitch free (but a little noisy and soft) with normal soft decoding and vdpau render & de-interlace. 

Soft decode with opengl render was very lumpy, totally unwatchable, yadif 2x de-int, soft decode with xv-blit and yadif 2x was smooth, no glitches but soft, noisy and nasty aliasing artefacts.

This was Ubuntu 11.04, Nvidia 270 current, 64 bit, 4GB ram raid 0 2x 7200 disks, JYA 0.24 latest from yesterday.

I may try swapping the GT220 back with the GT430, although I bought the GT430 hoping it would fix the glitching I had on the GT220. Drivers & Myth have moved along significantly in the time since then.

Tried the 1.8Ghz C2D (4300 I think) with soft decode (2cores) and vdpau render & de-int but soft decode is totally unable to keep up, pauses for a second every two or three! I though that received wisdom was that C2D's were generally good enough for 1080i h264? The C2D Quad 2.4Ghz I tried some time ago wasn't up to it either. I guess broadcasters are using more complex coding profiles these days.

> 
> In my case, the pauses are very brief, but my TV loses it's grasp on
> the HDMI audio stream and takes a further 5 seconds to pick it up
> again, resulting in annoying missed punchlines - sure, two button taps
> and I'm back 10 seconds and it's all fine, but it's starting to bug me
> a bit.

It's tempting to try optical and forego the HD audio, can always drag the blurays back from the box in the garage.

Andre