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

[Andre]

On 2 Jun 2011, at 00:06, Steven Adeff wrote:

> On Wed, Jun 1, 2011 at 12:28 PM, Andre <mythtv-list at dinkum.org.uk> wrote:
>> 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.
> 
> interesting benchmark. I wonder if the i7 is "fast enough" to not be
> slowed up by the ffmpeg/vdpau issue? If I understand what Mr Dean said
> that wouldn't be out of the question. Obviously the solution is still
> for the issue to be fixed, but interesting benchmark.

So i7 @ 2.8Ghz is this the new 0.24 frontend minimum spec ;-) no wonder Mike doesn't think Atoms are up to the job...

I also tried upping the vdpaubuffersize= to 48 & then 64 in case that was helpful as it's a 1GB card but no improvement there.

> 
> <snip>
> 
>> 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.
> 
> from my understanding from another email thread on this list, the 430
> isn't any faster than the 220 but it *can* pass the high def audio
> codecs. So I don't think that will change anything.

I wasn't expecting miracles, I know the benchmarks for the 430 which I why I bought a higher clock 430, it looked like it was a little borderline with the slower ones. 

I just wondered if driver maturity was a factor, 64 bit nvidia drivers were disastrous on the GT430 but work fine on the GT220. Of course there is a motherboard & CPU difference too, the usual frontend MB has irq bugs as the kernel disables MSI maybe that's a factor too, I've had trouble with Nvidia & irq sharing in the past.

Would be interesting to know if GT240's or massively over specified cards see the same effects? Anyone running Myth on a gaming or workstation card?

> 
>> 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.
> 
> not in my experience either with a E5200 Pentium Dual Core (C2D with
> less cache and some other small changes iirc)

All a bit reminiscent of the early BBC HD trials where very few had CPU's with enough grunt to decode the video.


> 
>>> 
>>> 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.
> 
> my parents system with a GT220 and also with an E5200 (though also
> acting as a backend) has to use optical for my parents receiver and
> they still gets the stutter, so unlikely to affect things.

Thanks, was grasping at straws anyway.

Hopefully when the problem is fixed as I'm sure it will be, it will be backported or considered justification for a 0.24.X release.

Andre