[mythtv-users] Intel i965 video buffers errors on frontend

Wed Jul 12 13:36:36 UTC 2017

On 12/07/17 11:34, evade. wrote:
> On 11/07/17 02:04, Stuart Auchterlonie wrote:
>> On 10/07/17 10:58, evade. wrote:
>>> On 06/07/17 23:35, Stuart Auchterlonie wrote:
>>>> On 06/07/17 12:35, evade at internode.on.net wrote:
>>>>> Hello,
>>>>> I'm having difficult problems with playback in the frontend version
>>>>> 0.28.1-3 and would love some help please!
>>>>>
>>>>> Intel H170M chipset, Intel i5-6500 CPU with HD Graphics 530
>>>>>
>>>>> <snip>
>>>>> So I switched to VAAPI, despite it lacking deinterlacing.  I'm still
>>>>> having playback problems with stuttering, especially with live TV.  My
>>>>> PC also has Intel HD audio (Realtek ALC892).
>>>>>
>>>>> Although playback works, when I enable debug logging I see multiple
>>>>> occurrences of both:
>>>>>
>>>>> <date> <time> I  Player(0): Waiting for video buffers...
>>>>>
>>>>> and:
>>>>>
>>>>> <date> <time> I  Player(0): Video is 3.54437 frames ahead of audio,
>>>>>                           doubling video frame interval to slow down.
>>>>>
>>>>> <snip>
>>>>
>>>> When playing back the recording pull up the playback data screen
>>>> (m > playback > playback data)
>>>>
>>>> and have a look at the data there. It's a little complex, but
>>>> you need to check a few things.
>>>>
>>>> - cpus usage, check it's not maxed out
>>>> - storage to buffer and buffer to decoder figures.
>>>>     You want storage to buffer figures to be significantly higher than
>>>>     the buffer to decoder figures (not just a little bit higher)
>>>> - available buffer. this figure is upside down, should really say "used
>>>>     buffer", the closer to 100% this is the better.
>>>> - frames decoded / free, frames decoded really should be greater
>>>> than 10
>>>>     for consistent viewing.
>>>>
>>>> Regards
>>>> Stuart
>>>
>>> Thanks for the fast response Stuart!
>>>
>>>
>>> My CPU has 4 cores and no hyperthreading.  I'm testing with 1080i H.264
>>> broadcast TV, because that's the worst-case scenario where I am.
>>>
>>> When the problem occurs the first core sits at about 75% and there's 0%
>>> of 4 Mb buffer available!  Sometimes after 10 to 20 seconds playback
>>> freezes momentarily.  Then the buffer jumps up to 20% and the first core
>>> averages around the same as the other cores at under 15% utilisation.
>>> (I imagine that the 75% utilisation involves a lot of I/O wait due to
>>> the buffer being empty.)
>>
>> This cpu usage indicates that the cpu is doing the decoding,
>> in the status screen it probably also said "ffmpeg" rather than "vaapi"
>>
>>>
>>> The other figures are:
>>>> 1 Gbps (!)  Storage To Buffer
>>
>> Good
>>
>>> up to 5 Mbps  Buffer to Decoder
>>> and
>>> Frames decoded / free
>>> ~3/~18
>>>
>>
>> Okay, it's not decoding enough frames, i'd expect because it's using
>> the cpu and not the gpu to do the decode.
>>
>> So check your profiles, to ensure it's selecting vaapi for this content.
>>
>>>
>>> If I start playback, then immediately pause and wait 10 seconds, I can
>>> get the buffer up to 60%, but the problem is this means jumping TV
>>> channels isn't an option!  (I imagine my spouse will not tolerate it)
>>>
>>>
>>> For the record, I bought the i5-6500 CPU hoping it's GPU would not have
>>> any problems as I intend to run two small KVM VMs on the system also.
>>> (They use SSD storage, totally separate from the HDDs where mythtv is
>>> writing and reading from)
>>> For this reason I'm not content going back to software rendering, even
>>> if it works.
>>> I may be wrong, but I thought the 'OpenGL' playback profile was software
>>> based, which is why I've tried VDPAU and now VAAPI.
>>
>> This cpu with it's embedded gpu should be able to handle this content
>>
>>
>> Regards
>> Stuart
> 
> Thanks again Stuart.
> 
> Can you please clarify the "Frames decoded / free" measure?
> 
> When watching live TV it's usually around 3/18 but when watching a
> bluray rip it can be 20/2.  I'm still sure what it means though.
> 
> 

20/2 is good, that means there are plenty of frames ready to be
displayed.

If it only occurs in livetv, then try rewinding a bit, so that you
are watching "live tv" with a slightly larger delay than before.

Some people seem to hit this issue only on livetv since it's trying
to playback too close to the end of the recording.

Regards
Stuart

> 
> I've significantly increased the RAM allocated for video memory in the
> BIOS (128MiB -> 512MiB) and can see a significant reduction in
> "stuttering" or audio gaps yet the buffer on live TV remains at 0%.
> 
> I can confirm that despite an early CPU spike on one core, I am
> definitely using a VAAPI profile.  Most of my testing has been with
> 1080i H.264 VAAPI TV.
> 
> As Helen pointed out in another reply I am probably making diagnosis
> harder by trying to address a few things together.  In my testing
> tonight I might have see only one "glitch" when playing back multiple
> different random shows from pre-recorded 1080i TV.  I also didn't
> observe the 'A/V sync' measure going above 0.03  If this is the case
> then just adding video memory fixed that issue!
> 
> (I'll test further but suspect that only about 256 MiB video memory is
> actually required)
> 
> 
> So the problem affecting live TV still has the same symptoms I first
> wrote about.  The  buffer remains at 0% and A/V sync gets up to 0.13,
> with the "Frames decoded / Free" ratio mentioned previously.
> 
> Is there any way to diagnose this further, please?
> 
> 
> 
> Thank again!
> evade.
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org