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

Steven Adeff 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.

<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.

> 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)

>>
>> 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.


-- 
Steve
http://www.mythtv.org/wiki/User:Steveadeff
Before you ask, read the FAQ!
http://www.mythtv.org/wiki/index.php/Frequently_Asked_Questions
then search the Wiki, and this list,
http://www.gossamer-threads.com/lists/mythtv/
Mailinglist etiquette -
http://www.mythtv.org/wiki/index.php/Mailing_List_etiquette


More information about the mythtv-users mailing list