* For v4l2video8dec to appear at all in gstreamer's list (output of 'gst-inspect-1.0'), I had to clear the gstreamer's registry 'rm ~/.cache/gstreamer-1.0/registry.armv7l.bin'. Probably has to do with particular order of installation that happened.
* To use s5p_mfc and s5p_fimc as modules, a workaround is needed for a null dereference upon inserting the modules. The issue is a race condition in the driver: v4l_id udev utility runs immediately after /dev/video* node is created, which is in the middle of the probe routine, so v4l_id calls open before the probe finishes (the driver should take the lock before creating the device node). A workaround is to disable the udev rule 60-persistent-v4l.rules (by adding a blank file of same name to /etc/udev/rules.d).
Yep. I was comparing cpu usage two pipeline sections 'v4l2video8dec ! v4l2video10convert ! fakesink' and 'avdec_h264 ! videoconvert ! fakesink'. The rough cpu load is for first 5 to 10 secs of big_buck_bunny_1080p_h264.mov. Yeah, a real sink will add to this.at 3) you mean CPU reduction from software decoding to mfc decoding?; clutter or egl unfortunately will use some CPU too...
Unfortunately, end-to-end HW decoding does not work for me. With glimagesink the framerate I get is about 5-10frames/sec. Some evidence suggests that the root cause is in the gstreamer/v4l2videodec, but other suggests that its in glimagesink.
TL;DR: Did anybody actually get a smooth playback of the above-mentioned Big Buck Bunny 1080p with glimagesink and the mfc pipeline?
Code: Select all
gst-launch-1.0 \ filesrc location=/mnt/ext/samples/big_buck_bunny_1080p_h264.mov \ typefind=true ! \ qtdemux name=m m.video_0 ! \ h264parse ! video/x-h264, stream-format=byte-stream, alignment=au ! \ v4l2video8dec ! videoconvert ! \ fpsdisplaysink video-sink=glimagesink
1. pure software decoding 'avdec_h264 ! videoconvert ! glimagesink ' shows a much higher frame rate than mfc 'avdec_h264 ! videoconvert ! glimagesink'. MFC is unwatchable ~5-10 fps, software is watchable (but fpsdisplaysink does report that all frames are still oficially late). This suggests that glimagesink is not the bottleneck.
2. If I comment out all the code in 'show_frame', effectively turning glimagesink into a fakesink (but with a log entry when show_frame is called), then compare the show_frame call timestamps in software vs MFC pipeline. The software pipeline calls it roughly every 20-40ms (on-time) consistenly. The MFC pipeline calls it roughly every 200ms and very erratically. This suggests that the issue is in gstreamer/v4l2videodec.
3. 'videotestsrc ! fpsdisplaysink video-sink=glimagesink' shows stable 30fps. This is a weak test though, since it's not a 1920x1080 stream.
4. The hardware converter is not the issue, since in all experiments there is no noticeable effect when 'videoconverter' is exchanged with 'v4l2video10converter'.
5. In v4l2videodec log, there are strange gaps in timestamps, when looking at 'Handling frame' events. Usually these exact events are spaced at around 30-40ms, but once in a while (every 10 or so frames), there is a gap on the order of 100ms:
Code: Select all
0:00:01.376665265 27542 0xb5504380 DEBUG videodecoder gstvideodecoder.c:2797:gst_video_decoder_clip_and_push_buf:<v4l2video8dec0> pushing buffer 0xb5567658 of size 3137536, PTS 0:00 :00.208333333, dur 0:00:00.041666666 0:00:01.377676847 27542 0x196660 LOG videodecoder gstvideodecoder.c:2147:gst_video_decoder_chain:<v4l2video8dec0> chain PTS 0:00:00.500000000, DTS 0:00:00.458333333 duration 0:0 0:00.041666666 size 51180 0:00:01.474289401 27542 0xb5504380 DEBUG v4l2 gstv4l2bufferpool.c:1285:gst_v4l2_buffer_pool_release_buffer:<v4l2video8dec0:pool:src> release buffer 0xb5567658
5. The actual hw decoding operation seems to correspond to these events, which always show a fast ~15-20ms decode time. So, the low level decode operation seems to not be the root cause of the problem.
Code: Select all
0:00:01.361191915 27542 0x196660 LOG v4l2 gstv4l2bufferpool.c:988:gst_v4l2_buffer_pool_poll:<v4l2video8dec0:pool:sink> polling device 0:00:01.375507350 27542 0xb5504380 LOG v4l2 gstv4l2bufferpool.c:1091:gst_v4l2_buffer_pool_dqbuf:<v4l2video8dec0:pool:src> dequeueing a buffe