Re: platform: coda: how to use firmware-imx binary releases? / how to use VDOA on imx6?
Am 05.10.2017 16:10 schrieb Nicolas Dufresne: Le jeudi 05 octobre 2017 à 13:54 +0200, Martin Kepplinger a écrit : > This message is most likely just a result of the VDOA not supporting > the > selected capture format. In vdoa_context_configure, you can see that > the > VDOA only writes YUYV or NV12. ok. I'll have to look into it, and just in case you see a problem on first sight: this is what coda says with debug level 1, when doing gst-launch-1.0 playbin uri=file:///data/test2_hd480.h264 video-sink=fbdevsink A bit unrelated, but kmssink remains a better choice here. True, but I'm currently not yet interested in the other end of the pipe :) Decoding works in principal. VDOA is still disabled however :( I don't see what I can do about this right now, which is a bit odd. It is definitely probed (and not removed). I see at least a few frames of the video, so I guess the video file is fine? Or could it be a file (or pixel) format that isn't supported? Again, ffprobe says Stream #0:0: Video: h264 (High), yuv420p(progressive), 852x480, 24 fps, 24 tbr, 1200k tbn, 48 tbc thanks After this, I want to have video conversion (color space) via a v4l2 interface that in turn uses the imx6 IPU. I guess gst-inspect-1.0 should see a V4L2 Converter, which it currently doesn't here: # gst-inspect-1.0 | grep v4l2 video4linux2: v4l2video1dec: V4L2 Video Decoder video4linux2: v4l2deviceprovider (GstDeviceProviderFactory) video4linux2: v4l2radio: Radio (video4linux2) Tuner video4linux2: v4l2sink: Video (video4linux2) Sink video4linux2: v4l2src: Video (video4linux2) Source # dmesg | grep ipu [1.394717] imx-drm display-subsystem: bound imx-ipuv3-crtc.2 (ops 0xc07d4b60) [1.402258] imx-drm display-subsystem: bound imx-ipuv3-crtc.3 (ops 0xc07d4b60) [1.514984] imx-ipuv3 240.ipu: IPUv3H probed should imx-ipuv3 provide a video4linux2 interface for video conversion? At least I don't see it yet. (or other V4L2 Linux config options than I already have enabled)
Re: platform: coda: how to use firmware-imx binary releases? / how to use VDOA on imx6?
Le jeudi 05 octobre 2017 à 13:54 +0200, Martin Kepplinger a écrit : > > This message is most likely just a result of the VDOA not supporting > > the > > selected capture format. In vdoa_context_configure, you can see that > > the > > VDOA only writes YUYV or NV12. > > ok. I'll have to look into it, and just in case you see a problem on > first sight: > this is what coda says with debug level 1, when doing > > gst-launch-1.0 playbin uri=file:///data/test2_hd480.h264 > video-sink=fbdevsink A bit unrelated, but kmssink remains a better choice here. Nicolas
Re: platform: coda: how to use firmware-imx binary releases? / how to use VDOA on imx6?
Am 05.10.2017 10:19 schrieb Philipp Zabel: Hi Martin, On Thu, 2017-10-05 at 09:43 +0200, Martin Kepplinger wrote: I'm running a little off-topic here, but with the newest firmware too, my coda driver says "Video Data Order Adapter: Disabled" when started by video playback via v4l2. This message is most likely just a result of the VDOA not supporting the selected capture format. In vdoa_context_configure, you can see that the VDOA only writes YUYV or NV12. ok. I'll have to look into it, and just in case you see a problem on first sight: this is what coda says with debug level 1, when doing gst-launch-1.0 playbin uri=file:///data/test2_hd480.h264 video-sink=fbdevsink with the video file being (ffprobe) Input #0, h264, from 'test2_hd480.h264': Duration: N/A, bitrate: N/A Stream #0:0: Video: h264 (High), yuv420p(progressive), 852x480, 24 fps, 24 tbr, 1200k tbn, 48 tbc after some s_ctrl: id/val printings: [ 98.833023] coda 204.vpu: Created instance 0 (cefc5000) [ 98.837550] coda 204.vpu: Releasing instance cefc5000 [ 98.839080] coda 204.vpu: s_ctrl: id = 9963796, val = 0 [ 98.839091] coda 204.vpu: s_ctrl: id = 9963797, val = 0 [ 98.839100] coda 204.vpu: Created instance 0 (ceeb2000) [ 98.842867] coda 204.vpu: Releasing instance ceeb2000 [ 98.845435] coda 204.vpu: s_ctrl: id = 9963796, val = 0 [ 98.845447] coda 204.vpu: s_ctrl: id = 9963797, val = 0 [ 98.845458] coda 204.vpu: Created instance 0 (cefc5000) [ 98.851652] coda 204.vpu: Setting format for type 2, wxh: 852x480, fmt: H264 L [ 98.851670] coda 204.vpu: Setting format for type 1, wxh: 852x480, fmt: NV12 T [ 98.854800] coda 204.vpu: get 2 buffer(s) of size 819200 each. [ 99.022191] coda 204.vpu: get 2 buffer(s) of size 622080 each. [ 99.025904] coda 204.vpu: Video Data Order Adapter: Disabled [ 99.025922] coda 204.vpu: H264 Profile/Level: High L3 [ 99.026214] coda 204.vpu: __coda_start_decoding instance 0 now: 864x480 [ 99.036277] coda 204.vpu: 0: not ready: need 2 buffers available (1, 0) [ 99.063157] coda 204.vpu: job ready so while the video is shown, the VDOA is "disabled". thanks a lot for your help (it's shown far from fluent yet, almost frame by frame, but that's ok for now... I'll still need to took into the v4l2 interface for the imx6 IPU) (imx6, running linux 4.14-rc3, imx-vdoa is probed and never removed, a dev_info "probed" would maybe be useful for others too?) It supsequently fails with cma: cma_alloc: alloc failed, req-size: 178 pages, ret: -12 That is -ENOMEM. Is CMA enabled and sufficiently large? For example, CONFIG_CMA=y CONFIG_CMA_DEBUGFS=y CONFIG_DMA_CMA=y CONFIG_CMA_SIZE_MBYTES=256 CONFIG_CMA_SIZE_SEL_MBYTES=y My cma buffer size was indeed just too small.
