Am Donnerstag, den 28.05.2015, 13:31 +0200 schrieb Enrico Weigelt, metux IT consult: > Am 28.05.2015 um 12:44 schrieb Philipp Zabel: > > Hi, > > >> Are these patches same as in your git branch tmp/imx-ipu-scaler ? > > > > No, that is an older version. > > Where can I get the recent ones ? > Could you push it to your public repo ? I've updated the tmp/imx-ipu-scaler branch. > >> when using it w/ gst for video playback, can be directly pass buffers > >> between VPU, IPU and FB (or let them directly write into shared > >> buffers), so CPU doesn't need to act on each frame for each step > >> in the decoding pipeline ? > > > > Check out the (capture/output-)io-mode parameters, that's what the > > dmabuf/dmabuf-import option pairs are for. > > Tried dmabuf, but load stays at the same (77..80% CPU, 1.2 loadavg). > dmabuf-import doesnt run at all: > > root@KoMo:/usr/share/videos/komo gst-launch-1.0 filesrc > location=montage.mp4 \! qtdemux \! h264parse \! v4l2video4dec > output-io-mode=5 \! v4l2video0convert capture-io-mode=5 output-io-mode=4 > \! fbdevsink That should be capture-io-mode=dmabuf for the decoder and output-io-mode=dmabuf-import for the converter element. h264parse doesn't provide and fbdevsink can't handle dmabufs, so the decoder's output-io-mode and the converter's capture-io-mode should be kept as mmio. [...] > By the way: do you have any idea whether the proprietary driver > (or the gpus itself) might talk to ipu and vpu ? Not that I am aware of. regards Philipp -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
