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

evade. evade at internode.on.net
Wed Jul 12 10:34:40 UTC 2017


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.



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.


More information about the mythtv-users mailing list