Default to more RPi video buffs, falling back on alloc failure

[Doug Larrick <doug@…>]

Experiments on my system show that 11 buffers is insufficient to avoid buffering on some US OTA HDTV content.

​https://github.com/MythTV/mythtv/pull/159

[Peter Bennett]

Hi Doug

Please tell me what are the symptoms you see and please supply a sample file that shows the problem. You can extract a minute or so of video and use Dropbox or another method to share it, and paste the URL here.

[Doug Larrick <doug@…>]

I added a comment here yesterday, evidently unsuccessfully. Trying again... The symptom is that we hit the "Waiting for video buffers..." log point in mythplayer.cpp . When this happens playback hiccups, as if you hit pause. Unfortunately it's not consistent -- rewinding and playing past the same point usually results in fine playback. So I suspect what happens is that other activities are consuming CPU. Increasing this parameter caused the problem to disappear totally for me.

I will attempt to find a sample that demonstrates the problem consistently.

Question: would it be a more acceptable change to expose this existing setting in the UI?

[Peter Bennett]

I have two Raspberry Pi's that I use regularly for watching HD recordings. I have seen some pauses when watching a recording in progress but nothing on prerecorded programs.

I am currently working on a couple of other fixes for the Waiting for video buffers... problem.

See #13172 and #12318.

If I get fixes for those I would like to try those plus the realtime fix you have supplied to see if they help, before committing this buffer change.

[Doug Larrick <doug@…>]

Sounds good to me. Thanks.

[Peter Bennett]

Have you seen this log message when you get the error?

DOMX:2 ProcessPacket - no input buffers

I saw that error while testing out changes for #13172 that may be using too much memory. It was accompanied by a stream of Waiting for video buffers messages.

[Peter Bennett]

Please look at #13173 and confirm whether the issue addressed there is the same or different from the issue addressed by this ticket.

[Doug Larrick <doug@…>]

I think perhaps #13173 is a more severe version of what I'm seeing. I would not say it ever pauses for 10 seconds -- rather, the dropouts I see are more like 0.5 to 1 second, and mostly affect audio: my system streams un-decoded audio to my AV receiver, which does the decoding; a hiccup in the audio bitstream causes silence for 3-5 seconds while it re-acquires.

I will not have more time to try again until this weekend.

[Peter Bennett]

If you are willing to try something out, there are patches you can try that fix 3 varieties of the Waiting for buffers and stuttering problems.

• #13173 - I see this once or twice during 1 hour of 1080i TV from Comcast, Boston WHDH channel 707 and WBTS channel 710.

• #12318 - Some people report "stuttering" which only happens with LiveTV and goes away if you pause and resume

• #13172 - Stuttering and jerking when adjusting audio sync in negative direction.

[Doug Larrick <doug@…>]

I'll pull those and try Saturday, thanks! I'll revert my video buffers at the default setting but include my realtime patch.

[Peter Bennett]

I have some problems with this patch #13171.

• It is already possible to change the number of output buffers with the setting OmxVideoBuffers (e.g. -O OmxVideoBuffers=15 on the command line). We could if needed add it to the setup GUI or change the default value to 15.
• The criteria for failure and fallback. The only time the CreateBuffers fails is if the malloc fails, and that will likely never happen. If it causes low memory, the system will instead begin swapping, and then performance will slow to a crawl. I do not think that fallback logic is useful.

I have tried with -O OmxVideoBuffers=15 and have not been able to see any difference in performance.

[Doug Larrick <doug@…>]

It's not allocating the actual video buffers in the GPU here? Darn, then I agree, the fallback loop is useless.

One more round of errands today, then I will have time to do my experiments and report back on the other ticket.

[Doug Larrick <doug@…>]

Aha! I've figured this out. It's memory related. If the Pi is memory starved and does light swapping, 4 more video buffers can make the difference between a glitch and floating through the event. I agree, then, that this change is just treating a symptom. Please close this ticket; I will close the GitHub? PR.