Opened 18 months ago

Closed 18 months ago

Last modified 12 months ago

#13171 closed Patch - Feature (Invalid)

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

Reported by: Doug Larrick <doug@…> Owned by: Peter Bennett
Priority: minor Milestone: unknown
Component: Ports - rPi Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: no


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

Change History (17)

comment:1 Changed 18 months ago by Peter Bennett

Reporter: changed from doug@… to Doug Larrick <doug@…>

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.

comment:2 Changed 18 months ago by Peter Bennett

Status: newinfoneeded_new

comment:3 Changed 18 months ago by 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?

comment:4 Changed 18 months ago by 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.

comment:5 Changed 18 months ago by Doug Larrick <doug@…>

Sounds good to me. Thanks.

comment:6 Changed 18 months ago by 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.

comment:7 Changed 18 months ago by 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.

comment:8 Changed 18 months ago by 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.

comment:9 Changed 18 months ago by 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.

comment:10 Changed 18 months ago by 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.

comment:11 Changed 18 months ago by Peter Bennett

Status: infoneeded_newassigned

comment:12 Changed 18 months ago by 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.

comment:13 Changed 18 months ago by 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.

comment:14 Changed 18 months ago by 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.

comment:15 Changed 18 months ago by Peter Bennett

Resolution: Invalid
Status: assignedclosed

comment:16 Changed 17 months ago by Stuart Auchterlonie

Milestone: needs_triageunknown

comment:17 Changed 12 months ago by Peter Bennett

Owner: changed from Peter Bennett to Peter Bennett
Note: See TracTickets for help on using tickets.