Three stage docker and armv7/v6

[QuantumEntangledAndy]

This creates the three stage docker you suggested in #104 and and also builds a multi arch docker image with amd64/armv7 and armv6.

The issue with getting armv6 previously is mitigated by dropping armv8. It seems that the github hosted machines only have 2cpus and limited ram so building 4 archs at once is too much but three is possible. I have chosen armv6 and armv7 over armv7 and armv8 as these are the ones on rpis.

closes #104 #76 #84 #73

[mr-onion-2]

Hi, great work - thanks. I'm watching this with interest :)

Unfortunately I only have Pi4's (ARMv8) and I am running 64bit OS.

Is it possible to reconsider which architectures to build? According to this, the only Pi running ARMv7 is the 2b. So supporting ARMv6 and ARMv8 might give more coverage. Just my opinion, and of course it may be biased.

Thanks!

[QuantumEntangledAndy]

Although not many pi's have a v7 only processor most rpis run v7 os for increased compatibility. for example I run the official rasbian image on my pi4 which means that although it's armv8 capable it's OS is armv7. I think most people would run it like this.

I'd rather drop V6 then v7.

Ideally I'd like all the archs to be supported on one image but that's not a easy right now. I do have a method for getting more archs to work but I'd rather wait on implementing it until we finalise one of the three docker PRs first so that I know what we are working with.

[QuantumEntangledAndy]

Also is there any reason you want to use docker for neolink? There is a know segmentation fault when using docker with high resolution streams. I actually recommend you use the binaries directly.

[mr-onion-2]

Thanks for the quick response - makes sense.

As for why I want to use Docker, literally everything else I run is containerized and running on my K3S cluster. I'd rather not have any extra bare-metal machines that need managing separately if I can help it.

I'll only be monitoring the substream so hopefully it will be OK.

[QuantumEntangledAndy]

You could try this to pull the armv7 since I think it compatible with v8:

docker pull quantumentangledandy/neolink:three-stage-docker --platform=linux/arm/v7

[mr-onion-2]

Thanks for the idea - I spent some time trying to see how to do this from within Kubernetes but had no success.

I've forked your branch however and I'm building a v8, just to see.

[Lanwalker]

A FYI for anybody considering Reolink cameras... their 2 year warranty with a bonus 1/2 year for registering those communist chinese pieces of junk is worthless. 1st one I purchased from the Reolink page cost me $44 and screwed up a 64GB memory card and would not eject it... I had to send it back. The idiots sent me 4 16 GB memory cards and another camera that dropped network connections 15 feet from my router, they said it needed a firmware update and I did that and a little time later it dropped off again and was very warm. I told them about it and they wanted to know if I would remove everything else from my home network and see if it did it again ( Sure, 3 or 4 days with just a $44 dollar camera on my home network while I twiddle my thumbs waiting for it to crash again<G> ) and while having this back and forth conversation in the middle of the night ( when they are in their offices ), the darn thing dropped off again... and these are supposed to be home security devices<G>. I told them I wanted it replaced and they could send me a box to return it in since I had already thrown the trash out and they want me to PREPAY MAIL ( about $16 for tracking a package ) to SEND IT BACK FOR A REFUND of my $44... they are not going to replace it again since they already replaced it once ( the memory card issue ). That 2 1/2 year warranty on that chinese trash is worth more in toilet paper. I told them I WILL KEEP IT AND LET EVERYBODY KNOW HOW THEIR SUPPORT GROUP TREATS PEOPLE. Merry Christmas and have a Happy New Year... AND BUY AMERICAN MADE<G> Robert Gamble On Monday, December 28, 2020, 3:46:53 PM EST, Mike K <[email protected]> wrote: Thanks for the idea - I spent some time trying to see how to do this from within Kubernetes but had no success. I've forked your branch however and I'm building a v8, just to see. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe .

[m1k1o]

I tried this new setup, it is working but i get these errors. And my ffmpeg is failing. Not sure, if new Dockerfile is causing this problem or anything else.

Neolink error log:

(neolink:6): GStreamer-WARNING **: 18:15:55.831: ../gst/gstpad.c:4616:gst_pad_push_data:<funnel282405:src> Got data flow before stream-start event
(neolink:6): GStreamer-WARNING **: 18:15:55.831: ../gst/gstpad.c:4621:gst_pad_push_data:<funnel282405:src> Got data flow before segment event
(neolink:6): GStreamer-WARNING **: 18:15:55.831: ../gst/gstpad.c:4363:gst_pad_chain_data_unchecked:<rtpbin150229:recv_rtcp_sink_1> Got data flow before stream-start event
(neolink:6): GStreamer-WARNING **: 18:15:55.831: ../gst/gstpad.c:4368:gst_pad_chain_data_unchecked:<rtpbin150229:recv_rtcp_sink_1> Got data flow before segment event

FFMPEG command, that is working with previous version:

Input #0, rtsp, from 'rtsp://neolink:8554/cam/mainStream':
  Metadata:
    title           : Session streamed with GStreamer
    comment         : rtsp-server
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: hevc (Main), yuvj420p(pc, bt709), 3840x2160, 20 fps, 20 tbr, 90k tbn, 20 tbc
    Stream #0:1: Audio: pcm_s16be, 16000 Hz, stereo, s16, 512 kb/s
[segment @ 0x558e2be77800] Opening 'recording.mp4' for writing
[mp4 @ 0x558e2be846c0] Could not find tag for codec pcm_s16be in stream #1, codec not currently supported in container
Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument

[QuantumEntangledAndy]

@m1k1o When was the last time you pulled an updated docker image? Your error seems to suggest that ffmpeg is failing because it dosent support pcm_s16be in mp4. I suspect your ffmpeg command needs to convert the audio and that it only worked before because you were using a docker image prior to the introduction of audio. Please consider transcoding the audio pcm_s16le should work without any loss or significant time. But you may want to transcode to aac for improved compression.

[m1k1o]

@QuantumEntangledAndy thank you, that might be the case. It was a long time ago, indeed. But what about that warnings? That should not have anything to do with the way, how I am processing video/audio output. Or?

[QuantumEntangledAndy]

I think those warnings are harmless it is just saying that we received data before any clients have asked for it to start playing.

We push the camera data to gstreamer as soon as a client connects without waiting for the start signal. We could improve this but I think it should be a separate issue and not part of this PR perhaps you can try to see if you get the warning with current version of the master docker image.

[brgavino]

FYI - Will be broken on armv7 until this is fix is released in docker: docker/buildx#508

Workaround is to use alpine:3.13 as the base, still pull from edge/testing. You can run privileged: true to fix any permissions with time in the runtime. Refer to: brgavino@6e6878f

[QuantumEntangledAndy]

With no progress on my PRs in years I am closing them in favour of working on my own fork. If your interested in these features please see there