nvhost-msenc v4l2-ioctl's not being set

Hi,

I have a TX2 running L4T 28.1 on an nvidia Jetson TX2 development board.

I’m trying to get video encoding working, but none of the calls to the MM API result in the expected ioctl calls. I think these are being blocked in v4l2_ioctl after this failure (strace) while calling NvVideoEncoder::createVideoEncoder(“enc0”):

16162 openat(AT_FDCWD, "/dev/nvhost-msenc", O_RDWR) = 24
16162 openat(AT_FDCWD, "/usr/lib/aarch64-linux-gnu/libv4l/plugins", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 25
16162 fstat(25, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
16162 getdents64(25, /* 5 entries */, 32768) = 176
16162 getdents64(25, /* 0 entries */, 32768) = 0
16162 close(25)                         = 0
16162 openat(AT_FDCWD, "/usr/lib/aarch64-linux-gnu/libv4l/plugins/libv4l-mplane.so", O_RDONLY|O_CLOEXEC) = 25
16162 read(25, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\260\t\0\0\0\0\0\0@\0\0\0\0\0\0\0x!\0\0\0\0\0\0\0\0\0\0@\0008\0\6\0@\0\32\0\31\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\24\26\0\0\0\0\0\0\24\26\0\0\0\0\0\0\0\0\1\0\0\0\0\0\1\0\0\0\6\0\0\0H\35\0\0\0\0\0\0H\35\1\0\0\0\0\0H\35\1\0\0\0\0\0\20\3\0\0\0\0\0\0\30\3\0\0\0\0\0\0\0\0\1\0\0\0\0\0\2\0\0\0\6\0\0\0\300\35\0\0\0\0\0\0\300\35\1\0\0\0\0\0\300\35\1\0\0\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\220\1\0\0\0\0\0\0\220\1\0\0\0\0\0\0"..., 832) = 832
16162 fstat(25, {st_mode=S_IFREG|0644, st_size=10232, ...}) = 0
16162 mmap(NULL, 73824, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 25, 0) = 0x7f9c375000
16162 mprotect(0x7f9c377000, 61440, PROT_NONE) = 0
16162 mmap(0x7f9c386000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 25, 0x1000) = 0x7f9c386000
16162 close(25)                         = 0
16162 mprotect(0x7f9c386000, 4096, PROT_READ) = 0
16162 ioctl(24, VIDIOC_QUERYCAP, 0x7fd1f155a0) = -1 ENOTTY (Inappropriate ioctl for device)
16162 write(2, "Failed to query video capabilities: Inappropriate ioctl for device\n", 67) = 67
16162 munmap(0x7f9c375000, 73824)       = 0
16162 openat(AT_FDCWD, "/usr/lib/aarch64-linux-gnu/libv4l/plugins/libv4l2_nvvidconv.so", O_RDONLY|O_CLOEXEC) = 25
16162 read(25, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\300\35\0\0\0\0\0\0@\0\0\0\0\0\0\0\350i\0\0\0\0\0\0\0\0\0\0@\0008\0\4\0@\0\27\0\26\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4_\0\0\0\0\0\0\4_\0\0\0\0\0\0\0\0\1\0\0\0\0\0\1\0\0\0\6\0\0\0\0`\0\0\0\0\0\0\0`\1\0\0\0\0\0\0`\1\0\0\0\0\0\0\t\0\0\0\0\0\0(\t\0\0\0\0\0\0\0\0\1\0\0\0\0\0\2\0\0\0\6\0\0\0\210`\0\0\0\0\0\0\210`\1\0\0\0\0\0\210`\1\0\0\0\0\0@\2\0\0\0\0\0\0@\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) = 832

The encoder is opened on the first line with fd=24. The the ioctl(24, VIDIOC_QUERYCAP, 0x7fd1f155a0) call fails. After this there are no further calls to ioctl with fd=24.

There is no error returned by my calls to the MM API, until I call setStreamStatus(true) on the capture and output planes. That call fails with -1. errno is not set.

For completeness I see:

nvidia@tegra-ubuntu:~/Projects/snc$ ls -l /dev/nvhost-msenc
crw-rw---- 1 root video 241, 0 Feb 11  2016 /dev/nvhost-msenc
nvidia@tegra-ubuntu:~/Projects/snc$ id -a
uid=1001(nvidia) gid=1001(nvidia) groups=1001(nvidia),4(adm),20(dialout),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev)
nvidia@tegra-ubuntu:~/Projects/snc$ ls -l /usr/lib/aarch64-linux-gnu/libv4l/plugins
total 52
-rwxrwxr-x 1 root root 28584 Sep 28  2017 libv4l2_nvvidconv.so
-rwxrwxr-x 1 root root  8480 Sep 28  2017 libv4l2_nvvideocodec.so
-rw-r--r-- 1 root root 10232 Jan 24  2016 libv4l-mplane.so

Any ideas what might be wrong?

Thanks!

Hi Ratbert,
Can you successfully run 01_video_encode sample? We have verified all samples before each release. It should work fine.

I took most of my setup code from that sample. I did not actually ever run it though. So I actually did run the sample this morning and it seems to work, though I have no good input data for it. I can see that the ioctl and the number of devices involved are more complex than I first thought, but at least now I have a model to work from.

Anyway, that lead me to look a bit more closely at the only setup API calls that “failed” setStreamStatus (I have two, as I need two encoders) and it turns out I was simply not checking the return value correctly. Once I fixed that, we’re off to the races :)

There is another problem now, but I’m sure that it just part of the normal coding cycle - I’m happy everything , bar my code, is working correctly at this point.

Thanks and sorry for the noise.