Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2 instances of omxplayer using mpeg2 causes gpu lockup #386

Closed
jmeiners opened this issue Oct 29, 2015 · 21 comments
Closed

2 instances of omxplayer using mpeg2 causes gpu lockup #386

jmeiners opened this issue Oct 29, 2015 · 21 comments

Comments

@jmeiners
Copy link

If you play 2 instances of omxplayer (windowed display) and both are using mpeg2 sources the gpu both videos will freeze and the gpu will stop responding to any vc commands till rebooted. (mpeg2 is licensed)

Is there a hardware/software limitation to only a single mpeg2 stream?

@VittGam
Copy link

VittGam commented Oct 29, 2015

Have you tried increasing the RAM allocated to the GPU to more than 128 MB? You can do it with gpu_mem in /boot/config.txt, or via raspi-config.

@jmeiners
Copy link
Author

Yes, using 196M gpu on a pi2.
It can run 6+ instances if it is h.264, but only 1 if mpeg2

@carlonluca
Copy link

Probably not the same issue, but it seems similar to raspberrypi/firmware#449. Although the problem is related also to h264 there.

@jmeiners
Copy link
Author

Not really. This lockup happens immediately every time.

@carlonluca
Copy link

If you read all the messages you'll see that I can reproduce the same (or very similar) freeze in a few seconds when I run multiple players concurrently. The backtrace in every case is very similar (you'll have to read the messages after the first report).

@carlonluca
Copy link

Also maybe related to #379?

@jmeiners
Copy link
Author

I think I have also seen the lockup you are referring to. Very rare but can happen.

This issue is I can run lots of h.264 instances but only 1 mpeg2.

@carlonluca
Copy link

If I run multiple players I get a complete lock of the GPU in a few seconds. If I run a single player I have a very rare lock, maybe related to frequent seek or however not sure. But I typically see both on h264. If you can run on gdb your omxplayer you may compare your backtraces with the ones I reported.

@gkreidl
Copy link

gkreidl commented Nov 1, 2015

I suppose it's a firmware issue. I could play up to four SD MPEG TS channels a short while ago (before upgrading to Jessie) with the same omxplayer version, Now it doesn't work any more.

@jmeiners
Copy link
Author

jmeiners commented Nov 1, 2015

Do you recall what firmware version you were running (that worked)?

@popcornmix
Copy link
Owner

Try with --nodeinterlace - I suspect that will work.

It's the change to the QPU deinterlacer which causes this. It grabs a lock on the QPUs which prevents a second stream from also using QPU deinterlace.
I'll see if we can either fall back to VPU deinterlace if QPU is not available, or whether we can share for SD resolutions.
1080i deinterlace is never going to support multiple streams (it's very expensive for GPU).

@gkreidl
Copy link

gkreidl commented Nov 2, 2015

it does work and now I know why it always worked for me until a short while ago: for some reason I had --deinterlace in my live-tv options (a special settings field in omxplayerGUI).

@jmeiners
Copy link
Author

jmeiners commented Nov 2, 2015

You, my friend, are a genius :)
Is that locking done in the open source interface lib or the gpu?

@popcornmix
Copy link
Owner

It's in the firmware. I'm looking into it.

@popcornmix
Copy link
Owner

@jmeiners
Copy link
Author

jmeiners commented Nov 4, 2015

That firmware actually crashes my pi2. I am running a custom kernel though, so probably not the best test subject. Maybe someone of a recent kernel can try it?

@popcornmix
Copy link
Owner

How does it crash? Do you get rainbow splash screen? Do you get any kernel console log? Can you log in?

@jmeiners
Copy link
Author

jmeiners commented Nov 4, 2015

Very strange. The device will lock up (custom screen saver freezes, ssh freezes, etc). Sometimes it will recover for awhile and then lock up again. This is just after boot, not running omxplayer. Seems unlikely to have anything to do with your specific change.
My systems are firmware/kernel locked down so I can't actually use a firmware update anyway. I'm perfectly happy with using --nodeinterlace for the windowed display case (thanks again). The quality difference isn't a big deal in the smaller window.

@popcornmix
Copy link
Owner

@gkreidl are you able to test the dropbox firmware?

@gkreidl
Copy link

gkreidl commented Nov 4, 2015

Sorry, not at the moment.

Am 04.11.2015, 17:48 Uhr, schrieb popcornmix [email protected]:

@gkreidl are you able to test the dropbox firmware?


Reply to this email directly or view it on GitHub:
#386 (comment)

popcornmix added a commit to raspberrypi/firmware that referenced this issue Nov 6, 2015
…m edges

See: #463

firmware: di_adv: Add config setting to add nop delays to shader
See: http://forum.kodi.tv/showthread.php?tid=231092&pid=2150605#pid2150605

firmware: vcilcs: Avoid a potential deadlock when very threaded
See: #449

firmware: vrf: Add spinlock around vrf acquire/release calls to avoid restoring an invalid p10 from ISR context

firmware: rpi_display: only ratelimit if the backlight is actually changed
See: raspberrypi/linux#1179

firmware: di_adv: Support multiple instances of qpu deinterlace at SD resolution
See: popcornmix/omxplayer#386

linux: rpi-ft5406: Use interruptible sleep to avoid high load reported
See: https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=125034

linux: dts: Added overlay for Adafruit PiTFT 2.8 capacitive touch screen
See: raspberrypi/linux#1192

linux: config: Add MCP320X
See: raspberrypi/linux#1189

linux: Build i2c_gpio module and add a device tree overlay to configure it
See: raspberrypi/linux#1183
popcornmix added a commit to Hexxeh/rpi-firmware that referenced this issue Nov 6, 2015
…m edges

See: raspberrypi/firmware#463

firmware: di_adv: Add config setting to add nop delays to shader
See: http://forum.kodi.tv/showthread.php?tid=231092&pid=2150605#pid2150605

firmware: vcilcs: Avoid a potential deadlock when very threaded
See: raspberrypi/firmware#449

firmware: vrf: Add spinlock around vrf acquire/release calls to avoid restoring an invalid p10 from ISR context

firmware: rpi_display: only ratelimit if the backlight is actually changed
See: raspberrypi/linux#1179

firmware: di_adv: Support multiple instances of qpu deinterlace at SD resolution
See: popcornmix/omxplayer#386

linux: rpi-ft5406: Use interruptible sleep to avoid high load reported
See: https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=125034

linux: dts: Added overlay for Adafruit PiTFT 2.8 capacitive touch screen
See: raspberrypi/linux#1192

linux: config: Add MCP320X
See: raspberrypi/linux#1189

linux: Build i2c_gpio module and add a device tree overlay to configure it
See: raspberrypi/linux#1183
@popcornmix
Copy link
Owner

The fix is in latest rpi-update firmware. I can now play 4 SD videos with deinterlace.

neuschaefer pushed a commit to neuschaefer/raspi-binary-firmware that referenced this issue Feb 27, 2017
…m edges

See: raspberrypi#463

firmware: di_adv: Add config setting to add nop delays to shader
See: http://forum.kodi.tv/showthread.php?tid=231092&pid=2150605#pid2150605

firmware: vcilcs: Avoid a potential deadlock when very threaded
See: raspberrypi#449

firmware: vrf: Add spinlock around vrf acquire/release calls to avoid restoring an invalid p10 from ISR context

firmware: rpi_display: only ratelimit if the backlight is actually changed
See: raspberrypi/linux#1179

firmware: di_adv: Support multiple instances of qpu deinterlace at SD resolution
See: popcornmix/omxplayer#386

linux: rpi-ft5406: Use interruptible sleep to avoid high load reported
See: https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=125034

linux: dts: Added overlay for Adafruit PiTFT 2.8 capacitive touch screen
See: raspberrypi/linux#1192

linux: config: Add MCP320X
See: raspberrypi/linux#1189

linux: Build i2c_gpio module and add a device tree overlay to configure it
See: raspberrypi/linux#1183
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants