[FEATURE] ARM64v8 support.

[Xeddius]

I would like to host this on my Raspberry PI4 4gb board.
It'll need to be arm64 since armhf performs extremely poorly on the PI4.
I would set it up manually by myself if I had the time.

The PI4 performs extremely well with arm64 (aarch64) and should be able to work within the requirements.

[GigaFyde]

This shouldn't be impossible I think.

[nurdism]

should be doable but I dont have a PI4 to mess with so I wont be able to do this myself

[Xeddius]

I have one that I can provide remote access to in the next few days.

[GigaFyde]

Hey there @Xeddius

I recently got myself a rpi4 4gb, and with the help of @m1k1o managed to package an ARM64 docker image of neko.
Whilst it technically works, performance is still awful.
There was only a very small performance increase going from ARMv7 to ARM64v8

Feel free to give it a test yourself, but don't get your hopes up too much.
gigafyde/neko:firefox-arm64

[mbattista]

Hi @GigaFyde and @Xeddius

I also made a working ARMv7 container.
Since I use HW acceleration parameter in the pipeline it runs smooth on my rpi3 for normal websites.
YouTube kind of works/plays, but its not that smooth. But I think the rpi3 is here the limiting factor?
Perhaps one of you can give me feedback if it runs better on a rpi4.

Important the video played only on a windows system. I could not get any video on linux. (perhaps a missing codec, but I thought chrome has all important codecs preinstalled)

docker-compose.yml:

version: "3.4"
services:
  neko:
    image: "mbattista/neko:arm_firefox"
    restart: "unless-stopped"
    # increase on rpi's with more then 1gb ram
    shm_size: "740mb"
    ports:
      - "8084:8080"
      - "52000-52100:52000-52100/udp"
        #    volumes:
        #      - "./certs:/certs"
    # this is important since we need a GPU for hardware acceleration alternatively mount the devices into the docker
    privileged: true
    environment:
      NEKO_SCREEN: '1280x720@30'
      NEKO_PASSWORD: 'neko'
      NEKO_PASSWORD_ADMIN: 'admin'
      NEKO_EPR: 52000-52100
      NEKO_VP8: 'false'
      NEKO_VP9: 'false'
      NEKO_H264: 'true'
      # Change target bitrate and framerate on this parameter
      NEKO_VIDEO: ' ximagesrc display-name=%s use-damage=0 show-pointer=true use-damage=false ! video/x-raw,framerate=30/1 ! videoconvert ! queue ! omxh264enc target-bitrate=1500000 control-rate=4 ! h264parse config-interval=3  ! video/x-h264,profile=baseline,stream-format=byte-stream '
      NEKO_MAX_FPS: 0
      NEKO_OPUS: 'true'
      #      NEKO_CERT: '/certs/cert.pem'
      #      NEKO_KEY: '/certs/key.pem'

@m1k1o should I make another pull request for the arm containers? They need to be cross-build in the pipeline

[m1k1o]

@mbattista this looks very good! It would be interesting to have arm Dockerfile. Is that affecting only base build or also browsers needs to be changed? We could habe base and arm_base, then use that as base image for browsers.

[mbattista]

https://github.com/mbattista/neko/tree/arm-container

I forgot to post the branch which has the changes in them.
I will make some changes to the README and make a pull request. =)

[m1k1o]

At the first sight, I do not see any differences in browser's Dockerfile, just the base image.

That could be generalized in all Docerfiles like this so we can avoid repetition:

ARG BASE_IMAGE=m1k1o/neko:base
FROM $BASE_IMAGE

And then when building, it could be replaced:

docker build -t m1k1o/neko:firefox_arm --build-arg BASE_IMAGE=m1k1o/neko:base_arm .

What do you say?

[mbattista]

good idea.

[m1k1o]

I tried it with my Raspberry Pi 3 Model B+.

• With Firefox I am not even able to connect to WebRTC. What makes sense, because it does not support H264.
• On Edge (or any chromium) I am able to connect, but not getting any video, even when switching screen size (what sometimes helps).

When switching to old pipelines on Rpi3 it works, so sadly, GPU doesn't seem to be working properly for me.

Are there any prerequisites for the host?

[mbattista]

oh, you are right :(
I did not look into it beforehand

codecId | RTCCodec_0_Inbound_102
[codec] | H264 (102, level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f)
decoderImplementation | ExternalDecoder

It seems that on my windows system there is an external codec which can encode the video.
That is probably the reason why it worked on my windows but not on my linux chrome.

Will try to change the pipeline and will post again when I know more

[mbattista]

Ok, it seems to be related to the SPS bug in pion.

I updated the compose file. now it should work

[m1k1o]

After your latest change, I was able to get it working. This weird colored bar showed on top of my browser.

After redeploaying it vanished.

Pipeline is working good, pretty fast. But browser itself is really slow, but that is not a surprise.

Good job!

[mbattista]

https://github.com/m1k1o/neko now has an Raspberry Docker image. via m1k1o/neko#36

[nrgapple]

m1k1o/neko:arm-chromium is no longer on docker hub https://hub.docker.com/r/m1k1o/neko/tags?page=1&ordering=last_updated

[mbattista]

I made a pull request that fixes some problems and will hopefully restore the build pipeline of the project.

in the meantime you can test mbattista/neko:arm-chromium

[GigaFyde]

For those interested,

gigafyde/neko:pi4-base
gigafyde/neko:pi4-firefox

[mbattista]

For those interested,

gigafyde/neko:pi4-base
gigafyde/neko:pi4-firefox

How is the performance on an pi4? Is it acceptable?
Would the m1k1o/neko:arm-chromium (mbattista/neko:arm-chromium) run on the pi4?

[GigaFyde]

Performance on the pi4, when using pi4 optimized images, was surprisingly good.
Only thing currently wrong with it is heavy video artifacting.

But I'd call it useable once those are eliminated

[mbattista]

Could you try the following parameter on your pi4:

 NEKO_VIDEO: ' ximagesrc display-name=%s use-damage=0 show-pointer=true use-damage=false ! video/x-raw,framerate=30/1 ! videoconvert ! queue ! video/x-raw,framerate=30/1,format=NV12 ! v4l2h264enc extra-controls="controls,video_bitrate_mode=1,h264_profile=0,video_bitrate=2500000;" ! h264parse config-interval=3 ! video/x-h264,profile=baseline,stream-format=byte-stream '

I left the bitrate mode on the default VBR thinking it would be better. But perhaps CBR is better suited for this.
This also bumps the bitrate up a notch. I feared that the the amount of dropped frames will increase with further increases of the bitrate, but it seems that the fps on my rpi3 stays between 18 and 23 frames no matter which (sane) bitrate.

btw, these are the (documented) 'extra-controls' parameter on my rpi3. There are not many options to change the quality of the encoding. But perhaps you can find a good configuration.

pi@raspberrypi:~/neko $ v4l2-ctl -d /dev/video11 -L

Codec Controls

             video_bitrate_mode 0x009909ce (menu)   : min=0 max=1 default=0 value=0 flags=update
                                0: Variable Bitrate
                                1: Constant Bitrate
                  video_bitrate 0x009909cf (int)    : min=25000 max=25000000 step=25000 default=10000000 value=10000000
           sequence_header_mode 0x009909d8 (menu)   : min=0 max=1 default=1 value=1
                                0: Separate Buffer
                                1: Joined With 1st Frame
         repeat_sequence_header 0x009909e2 (bool)   : default=0 value=0
                force_key_frame 0x009909e5 (button) : flags=write-only, execute-on-write
            h264_i_frame_period 0x00990a66 (int)    : min=0 max=2147483647 step=1 default=60 value=60
                     h264_level 0x00990a67 (menu)   : min=0 max=13 default=11 value=11
                                0: 1
                                1: 1b
                                2: 1.1
                                3: 1.2
                                4: 1.3
                                5: 2
                                6: 2.1
                                7: 2.2
                                8: 3
                                9: 3.1
                                10: 3.2
                                11: 4
                                12: 4.1
                                13: 4.2
                   h264_profile 0x00990a6b (menu)   : min=0 max=4 default=4 value=4
                                0: Baseline
                                1: Constrained Baseline
                                2: Main
                                4: High

[GigaFyde]

Gave that one a try, and its a major regression in performance.
With that one audio is no longer in sync, tho video didn't seem to have artifacts.

[mbattista]

I will try to keep mbattista/neko:arm-chromium, mbattista/neko:arm-firefox and mbattista/neko:arm-base via github actions up-to-date with m1kio/neko dev branch.

[GigaFyde]

@mbattista please change those formats to reflect what arm / pi version they're build for

[mbattista]

true.
I will tag them with armv7-xxxx later.