This is a cache of https://discuss.96boards.org/t/dragonboard-410c-debian-283-error-using-gstreamer-v4l2h264enc-plugin/3583. It is a snapshot of the page at 2024-11-04T07:22:02.555+0000.
Dragonboard 410c Debian # 283 - Error using gstreamer v4l2h264enc plugin - DragonBoard410c - 96Boards Forum

Dragonboard 410c Debian # 283 - Error using gstreamer v4l2h264enc plugin

Products Support DragonBoard410c
#1

Hello,

I am trying to run a gstreamer program that I developed when I was using the Debian #252, which was successfully running with that Debian version.

This program uses the h264 hardware encoder, so the modifications of gstreamer-plugin-good were successfully made, and these are not changed from #260 to #283.

Now that I am trying to use it with Debian #283, I cannot attach the v4l2h264enc to the pipeline.
Compilation of the program is successful, but it fails in execution when I try to attach the v4l2h264enc to the pipeline.

Do you have any idea about what’s happening or what can be wrong in the packages installation, Debian configuration etc. ?

As an additional information, the kernel’s device-tree has been modified to do not use the console /dev/ttyMSM0, but I don’t think this influences the gstreamer setup…

Thank you in advance,
Regards,
Simon

#2

Hello again,

After running the program I can see the following kernel error

Error creating v4l2h264enc
[  619.548644] hwencTest[3155]: unhandled level 0 translation fault (11) at 0x92335000560, esr 0x92000004
[  619.560148] [92335000560] *pgd=0000000000000000
                                                  [  619.567854]
[  619.567873] CPU: 0 PID: 3155 Comm: hwencTest Tainted: G        W       4.9.56-linaro-lt-qcom #1
[  619.568498] Hardware name: qualcomm Technologies, Inc. APQ 8016 SBC (DT)
[  619.577264] task: ffff8000360e2700 task.stack: ffff8000348b0000
[  619.583983] PC is at 0xffffb09f7760
[  619.589585] LR is at 0xffffb09f7754
[  619.593055] pc : [<0000ffffb09f7760>] lr : [<0000ffffb09f7754>] pstate: 80000000
[  619.596531] sp : 0000fffff4276ab0
[  619.604165] x29: 0000fffff4276ab0 x28: 0000000000000000
[  619.612483] x27: 0000000000000000 x26: 0000000000000000
[  619.617790] x25: 0000000000000000 x24: 0000000000000000
[  619.623062] x23: 0000000000000000 x22: 0000000000000000
[  619.628368] x21: 0000aaaad60f1ec0 x20: 0000000000000001
[  619.633675] x19: 0000ffffb063232c x18: 0000000000000000
[  619.638948] x17: 0000aaaad61060e8 x16: 0000ffffb09f7738
[  619.644253] x15: 00000000000002e9 x14: 0000000000000000
[  619.649597] x13: 0a2e656e696c6570 x12: 6970206573696c61
[  619.654832] x11: 0000000000000001 x10: 0101010101010101
[  619.660140] x9 : 0000aaab129badb0 x8 : 0000aaab129d8e90
[  619.665446] x7 : 0000000000000000 x6 : 0000000000000000
[  619.670718] x5 : 0000ffffb07579a8 x4 : 00000000ffffffff
[  619.676013] x3 : 0000aaab129d8e90 x2 : 9000092335000560
[  619.681320] x1 : 0000000000000001 x0 : 0000aaab127ce020
[  619.686602]
Segmentation fault

The message Error creating v4l2h264enc is part of my program for debugging purposes.
The kernel installed for this test is the original from Debian #283.
As I repeat, this program was running successfully on Debian version #260.

Could you give some help about this ?
Thank you in advance.
Regards,
Simon

#3

Hi Simon

This thread is aging a little now (and IIRC I’ve seen other encoder related posts since). Is this issue still troubling you?

After running the program I can see the following kernel error

BTW I don’t think this is a kernel error. The DB410C is configured by default with 48-bit user address space (meaning the PC suggested we are running in userspace). I think the message in the kernel log is merely a debugging aid that is issued when a userspace program gets a SEGV (and can therefore be debugged further using gdb).

#4

Hello @danielt,
I did not tested anymore the program on the Debian #283, but I remember gst-launch was failing as well.

On Debian #260 I don’t have this problem, neither with the program neither with gst-launch.

Since the Debian #260 is not available anymore from your links, could you suggest me the git command line to retrieve the kernel branch for that release ?
If you have a PDF of the doc page printed would be even better (just to have full relese doc).

Regards,
Simon

#5

Debian #260 was not a release, it was a snapshot. We don’t tag snapshots and AFAIK once the snapshot is removed we do not retain any information on how to reconstruct it.

I think the best you could do look at the v4.9 maintainance branch and select one whose dates match the build date for snapshot #260:
https://git.linaro.org/landing-teams/working/qualcomm/kernel.git/log/?h=release/qcomlt-4.9

#6

OK but I am not so expert with git. Sorry for that.
In the #283 doc its stated the following one:

git checkout -b kernel-17.09 debian-qcom-dragonboard410c-17.09

How do I know which branch download from the git.linaro link you reported ?

Thank you.
Simon

#7

oh. #283 is an actual release, so of course actual releases don’t get deleted! “daily” builds are published on ‘snapshots’ area and when we make an actual release we copy them over into ‘release’ area. So #283 is 17.09, so it’s here http://builds.96boards.org/releases/dragonboard410c/linaro/debian/17.09/

For releases, we also create a git tag on the kernel tree so that we can easily get back to it. your git command will checkout the exact source code that was used for this release. It doesn’t matter which ‘branch’ you need to use, since you have a tag.

‘snapshots’ builds get deleted after 1 month, otherwise.

#8

Hi @simozz

You always download the main repository with the git clone command, then checkout the build you want.

time git clone -n http://git.linaro.org/landing-teams/working/qualcomm/kernel.git

I think this should get the 260 build for you:

cd kernel
git checkout -b kernel-17.06.1 debian-qcom-dragonboard410c-17.06.1

I have a ‘script’ that does various checkouts for me, it looks like this, just uncomment the one you want:

cd kernel
#time git checkout -b build-97 2e4646fcf227f8023e535ddb18d3f3185665d8dd
#time git checkout -b build-109 634ba131f4442045f1e38246a899615c219730ee
#time git checkout -b build-202 0ea6924010269ba065848b2e450673e96bceffd9
#time git checkout -b build-227 a6b64c721f5fed87d6f770ca2eb9ca622d1ce37c
#time git checkout -b kernel-17.04 debian-qcom-dragonboard410c-17.04
#time git checkout -b build-236 7a1690cbc7633f49cdb976687d32d5d2affbe14f
#time git checkout -b build-240 180b1b7c70a3c567b72421dd9ac1b465527bdf65
#time git checkout -b build-250 529c1db225629896d51b64a481b3760fd81a663a
time git checkout -b kernel-17.06.1 debian-qcom-dragonboard410c-17.06.1

As you can see, you can use a magic number for each build, or a symbolic tag for release builds. Unfortunately I don’t have a list of the magic numbers for every build. Daniel was suggesting a way you could find the magic numbers by looking at the dates.

Full Disclosure: I am an employee of qualcomm Canada, any opinions I may have expressed in this or any other post may not reflect the opinions of my employer.

1 Like
#9

Thank you. It seems the branch I was looking for.
Simon

PS: I will retry from scratch if #283 fails with the encoder. Last time I tried it was more than one month ago.