[mythtv-users] Playback problem -- random short pauses
adeffs.mythtv at gmail.com
Wed Jun 1 23:06:43 UTC 2011
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.
> 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.
> 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
not in my experience either with a E5200 Pentium Dual Core (C2D with
less cache and some other small changes iirc)
>> 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.
Before you ask, read the FAQ!
then search the Wiki, and this list,
Mailinglist etiquette -
More information about the mythtv-users