Video play on arm-Preemption disabled at <>

0

I am currently using an ARM Freescale processor board to perform video playback:

When I use the Qt Multimedia libraries over the application I get a Preemption before the video playback freezes:

root@sanuser:~#  /home/app.sh start
====== AIUR: 4.1.4 build on Mar  2 2018 10:49:12. ======
        Core: MPEG4PARSER_06.09.36  build on Aug 23 2016 05:18:47
 file: /usr/lib/imx-mm/parser/lib_mp4_parser_arm11_elinux.so.3.2
------------------------
    Track 00 [video_0] Enabled
        Duration: 0:02:07.280000000
        Language: und
    Mime:
        video/x-h264, parsed=(boolean)true, alignment=(string)au, stream-format=(string)avc, width=(int)640, height=(int)480, framerate=(fraction)25/1, codec_data=(buffer)014d401effe10018674d401eda0280f6c044000003000400000300c83c58ba8001000468ef3c80
------------------------
------------------------
    Track 01 [audio_0] Enabled
        Duration: 0:02:07.317000000
        Language: und
    Mime:
        audio/mpeg, mpegversion=(int)4, channels=(int)6, rate=(int)48000, bitrate=(int)384039, stream-format=(string)raw, codec_data=(buffer)11b0
------------------------
====== BEEP: 4.1.4 build on Mar  2 2018 10:49:24. ======
        Core: AAC decoder Wrapper  build on May 30 2016 12:33:44
 file: /usr/lib/imx-mm/audio-codec/wrap/lib_aacd_wrap_arm12_elinux.so.3
CODEC: BLN_MAD-MMCODECS_AACD_ARM_03.09.00_CORTEX-A8  build on Jul 13 2016 18:15:25.
[INFO]  bitstreamMode 1, chromaInterleave 0, mapType 0, tiled2LinearEnable 0
BUG: scheduling while atomic: vqueue:src/642/0x00000101
Preemption disabled at:[<80101544>] __do_softirq+0x5c/0x3b4

However the video play back is smooth while using gstreamer pipeline without any issues:

gst-launch-1.0 -v filesrc location=/home/SampleVideo_720x480.mp4 typefind=true ! qtdemux !queue max-size-time=0 !vpudec ! videoconvert ! imxipuvideosink framebuffer=/dev/fb0
qt
arm
gstreamer
qtmultimedia
asked on Stack Overflow May 16, 2018 by Sangram Jadhav • edited May 16, 2018 by eyllanesc

1 Answer

0

Qt multimedia system happens to trigger a kernel bug. It may be bug in Qt too, but no userspace application should be triggering a kernel panic. And that's what BUG: scheduling while atomic is. It's a driver bug somewhere in the kernel code, possibly the video driver for the board. Probably gstreamer has a workaround for that kernel bug, or does something differently and the kernel bug isn't hit. But it's definitely a kernel bug, no doubt about it.

answered on Stack Overflow May 18, 2018 by Unslander Monica • edited May 18, 2018 by Unslander Monica

User contributions licensed under CC BY-SA 3.0