User Tools

Site Tools


hardwarerelated:raspberry_pi_4_tc358743

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
hardwarerelated:raspberry_pi_4_tc358743 [2020/05/24 03:20]
chris [Playground]
hardwarerelated:raspberry_pi_4_tc358743 [2020/05/28 12:04] (current)
chris
Line 8: Line 8:
   * I use the [[https://​geekworm.com/​collections/​raspberry-pi-4/​products/​raspberry-pi-4-ultra-thin-cnc-aluminum-alloy-metal-case-compatible-with-raspberry-pi-4-model-b-only|Geekworm Raspberry pi 4]] case, the board is mounted on top.   * I use the [[https://​geekworm.com/​collections/​raspberry-pi-4/​products/​raspberry-pi-4-ultra-thin-cnc-aluminum-alloy-metal-case-compatible-with-raspberry-pi-4-model-b-only|Geekworm Raspberry pi 4]] case, the board is mounted on top.
   * Basically, there are 2 modes to use the board. [[https://​www.raspberrypi.org/​forums/​viewtopic.php?​f=38&​t=120702|This thread]] has the details.   * Basically, there are 2 modes to use the board. [[https://​www.raspberrypi.org/​forums/​viewtopic.php?​f=38&​t=120702|This thread]] has the details.
-    * Via firmware, below steps first use that one+    * Via firmware
     * Via kernel driver mode, more modern/bugs will rather be fixed there     * Via kernel driver mode, more modern/bugs will rather be fixed there
  
Line 14: Line 14:
  
 What works for me as of now, what does not? What works for me as of now, what does not?
-  * grabbing HDMI of 720p@60Hz, and 1080p@25 Hz works +  * grabbing HDMI of 720p@60Hz, and 1080p@50 Hz works 
-  * no sound as of now +  * No sound as of now, seems like I need to solder 4 cables for this. Have no soldering iron etc. around. 
-  * I looked at several streaming software combinations,​ my goal is to stream low latency to a Linux desktop, over Gbit ethernet. mpegts stream, encoded by ffmpeg, looks most promising so far. +  * I looked at several streaming software combinations,​ my goal is to stream low latency to a Linux desktop, over Gbit ethernet. mpegts stream, encoded by ffmpeg, looks most promising so far. For low latency streaming, I had best results with the firmware based approach
-  * If not aiming at action games but for example videos, then caching and encoding with fewer artifacts ​can be used.+  * If not aiming at action games but for example videos, then caching and encoding with fewer artefacts ​can be used.
  
-===== First H2C-RPI-B01 ​testplain 720p ===== +===== Basic setup for the H2C-RPI-B01, ​first test ===== 
-These steps work for me on Raspbian-lite and Raspbianwith the H2C-RPI-B01 like a plain raspi camera. This works nice and easy for 1280x720@60pA similar project ​[[https://​mzyy94.com/​blog/​2020/​04/10/raspberrypi-hdmi-input/|is here]]. ​Limitations/​downsides:​ +From the 2 modesthis one uses the kernel code approach to control the TC358743. This approach is more modern ​and the one more likely to see bugfixing and development in the futureMore details are [[https://​www.raspberrypi.org/​forums/​viewtopic.php?​f=38&​t=120702&​start=400#​p1339178|here]],​ [[https://​www.raspberrypi.org/​forums/​viewtopic.php?​f=38&​t=120702|here]] (yes, 600+ posts..), and [[https://​mzyy94.com/​blog/​2020/​05/11/play-nintendo-switch-on-smartphone/#​hdmi%E5%85%A5%E5%8A%9B%E3%82%92%E6%89%B1%E3%81%86|here]]. 
-  * no sound is grabbed + 
-  * this uses firmware/​userland accessnot the kernel ​code which is the more modern way which also gets supported in the future +These use Raspbian or Raspbian-litewith latest updates. First we install some packages, then we prepare config.txt to use our hardware. These dtparam/​dtoverlay options lead to our Linux kernel ​detecting ​the hardware, and kernel modules getting loaded.
-  * For simplicitythis uses mplayer ​and X-forwarding via SSH: resource and bandwidth hungry, and with delay+
  
 <​code>​ <​code>​
-### Some software ​we will use later +### Software ​we will use 
-$ apt install mplayer xawtv vlc git-core+$ apt install mplayer xawtv vlc git-core ​ffmpeg
  
 +### Enabling the devices we will use
 +vi /​boot/​config.txt
 +# Ensure the following are active/not commented out:
 +--------------------------------
 +   ​dtparam=i2c_arm=on
 +   ​dtparam=i2s=on
 +   ​dtparam=spi=on
 +   ​dtparam=i2c_vc=on
 +   ​dtparam=audio=on
 +   ​dtoverlay=vc4-fkms-v3d
 +   ​dtoverlay=dwc2
 +   ​dtoverlay=tc358743
 +   ​dtoverlay=tc358743-audio
 +   ​start_x=1
 +   ​gpu_mem=128 ​
 +--------------------------------
 +
 +### Now we reboot the system
 +reboot
 +
 +### Verify if the module got loaded
 +root@pi4 31°C ~]$ dmesg | grep tc358743
 +[    4.183486] tc358743 0-000f: tc358743 found @ 0x1e (bcm2835 I2C adapter)
 +[root@pi4 31°C ~]$ lsmod|grep tc358743
 +tc358743 ​              ​40960 ​ 1
 +v4l2_dv_timings ​       36864  2 bcm2835_unicam,​tc358743
 +v4l2_fwnode ​           20480  2 bcm2835_unicam,​tc358743
 +v4l2_common ​           16384  3 bcm2835_unicam,​bcm2835_v4l2,​tc358743
 +videodev ​             200704 ​ 9 bcm2835_unicam,​v4l2_fwnode,​bcm2835_codec,​v4l2_common,​[..]
 +media                  36864  5 bcm2835_unicam,​bcm2835_codec,​videodev,​v4l2_mem2mem,​tc358743
 +[root@pi 31°C ~]$ 
 +</​code>​
 +
 +For reading the HDMI stream, the HDMI source and our grabber card have to agree on a video mode. [[https://​en.wikipedia.org/​wiki/​Extended_Display_Identification_Data|EDID]] is used for this: monitors or our grabber card can with this offer modes to the HDMI source, and agree on one mode. When using the firmware driven approach (more details in a later section), the application (i.e. raspivid) is setting the EDID. Here with the kernel approach, we have to use a file and explicitly use a command to offer the EDID data to the peer.
 +
 +<​code>​
 +# Further variant for an EDID file:
 +# wget https://​raw.githubusercontent.com/​6by9/​RPiTest/​master/​1080P50EDID.txt
 +git clone https://​github.com/​mzyy94/​ns-remote
 +v4l2-ctl --set-edid=file=ns-remote/​720P30EDID.txt
 +v4l2-ctl --set-dv-bt-timings query
 +</​code>​
 +You might have to execute the last comment twice or three times, to see "BT timings set". With an appropriate HDMI source, our card should now have agreed on a mode. Reminder: the H2C-RPI-B01 offers for example 1280x720@60Hz or 1920x1080@25Hz,​ but not 1920x1080@60Hz. So with a HDMI source only offering that, we will not come to an agreement (or we will simply then not be able to process the data).
 +<​code>​
 +# Now we can query which mode has been agreed on:
 +v4l2-ctl --query-dv-timings
 +
 +# Optionally, to sist all supported modes:
 +v4l2-ctl --list-dv-timings
 +
 +# Optionally, one can try to set one of the modes from "​list-dev-timings":​
 +v4l2-ctl --set-dv-bt-timings <​parameters>​
 +</​code>​
 +If these steps looked good, we can try to grab HDMI and record into a h264 file, which is playable via VLC. This records for 10 seconds, without sound. [[https://​www.raspberrypi.org/​forums/​viewtopic.php?​f=38&​t=120702&​start=425#​p1385724|Details.]]
 +<​code>​
 +git clone  https://​github.com/​6by9/​yavta
 +cd yavta/
 +make
 +./yavta --capture=1000 -n 3 --encode-to=file.h264 -f UYVY -m -T /dev/video0
 +</​code>​
 +
 +===== Kernel based streaming =====
 +At the moment, my goal is just to stream over the gbit NIC to a different linux system, with low latency and as few artefacts as possible. Over gbit, I have 0.3ms RTT between both systems. I was not able to get below 10 seconds latency with the kernel based approach. Try the firmware one, if you aim at low latency.
 +<​code>​
 +# Server: the process to be started on the Raspi
 +#   ​exchange the ip with your clients IP, who should receive the stream
 +
 +# reencoding x264
 +./yavta -f UYVY --capture=3000 -n 3 --encode-to=- -m -T /dev/video0 | \
 +  ffmpeg -i - -preset ultrafast -vcodec libx264 -tune zerolatency \
 +  -f mpegts udp://​192.168.0.2:​4242
 +# This is unfortunately reeoncoding in mpegts
 +./yavta -f UYVY --capture=3000 -n 3 --encode-to=- -m -T /dev/video0 | \
 +  ffmpeg -i - -r 60 -vcodec mpeg2video -f mpegts udp://​192.168.0.2:​4242
 +# I did not manage to plainly copy the x264 data from yavta
 +./yavta -f UYVY --capture=3000 -n 3 --encode-to=- -m -T /dev/video0 | \
 +  ffmpeg -i - -f h264 -c libx264 -preset ultrafast udp://​192.168.0.2:​4242
 +
 +# Client process, exchange with the IP of the Raspi who sends the stream:
 +ffplay -an -sn -i -fflags nobuffer udp://​192.168.0.3:​4242?​listen
 +ffplay -analyzeduration 1 -fflags -nobuffer -probesize 32 -sync ext \
 +  -i udp://​192.168.0.3:​4242?​listen
 +</​code>​
 +
 +===== Kernel based streaming, rtp protocol =====
 +This uses the TC358743 h264 encoding, so almost no load on the Raspberry. For me, still some seconds of delay.
 +<​code>​
 +# On Raspi/​server side
 +./yavta -f UYVY --capture -n 3 --encode-to=- -m -T /dev/video0 | \
 +  ffmpeg -i - -c:v copy -an -f rtp rtp://<​your-clients-IP>:​4242
 +
 +# A section similar like the following will be output, and
 +# needs to be copied into a file on the client, for example
 +# called stream.spd
 +SDP:
 +v=0
 +o=- 0 0 IN IP4 127.0.0.1
 +s=No Name
 +c=IN IP4 192.168.0.2
 +t=0 0
 +a=tool:​libavformat 58.20.100
 +m=video 4242 RTP/AVP 96
 +a=rtpmap:96 H264/90000
 +a=fmtp:96 packetization-mode=1;​ sprop-parameter-sets=J2QAKKwrQCgC3QDxImo=,​KO4CXLAA;​ profile-level-id=640028
 +
 +# On the client side:
 +ffplay -i -protocol_whitelist file,​udp,​rtp test.spd
 +</​code>​
 +===== Using the firmware approach =====
 +Besides the kernel code approach, there is the older firmware based approach. The kernel code which is more modern way which also gets supported in the future. For simplicity, this uses mplayer and X-forwarding via SSH: resource and bandwidth hungry, and with delay.
 +
 +<​code>​
 ### Let's have raspi-config set to options and reboot ### Let's have raspi-config set to options and reboot
 $ raspi-config nonint do_camera 0 $ raspi-config nonint do_camera 0
 +
 +### raspi-config has modified config.txt for us.  If the kernel
 +### approach was used on the system, the dtoverlay/​dtparam options
 +### for kernel mode need to be disabled.
 $ cat /​boot/​config.txt $ cat /​boot/​config.txt
 | [..] | [..]
Line 74: Line 189:
  
 ===== Firmware based streaming ===== ===== Firmware based streaming =====
-At the moment, my goal is just to stream over the gbit NIC to a different linux system, with low latency and as few artifacts ​as possible. ​ ffmpeg does this best for me currently. ​ Over gbit, I have 0.3ms RTT between both systems, the following uses 300kbyte/​sec bandwidth. This again just uses firmware for access, not the chips kernel drivers.+At the moment, my goal is just to stream over the gbit NIC to a different linux system, with low latency and as few artefacts ​as possible. ​ ffmpeg does this best for me currently. ​ Over gbit, I have 0.3ms RTT between both systems, the following uses 300kbyte/​sec bandwidth. This again just uses firmware for access, not the chips kernel drivers.
 <​code>​ <​code>​
 # Server: the process to be started on the Raspi # Server: the process to be started on the Raspi
 #   ​exchange the ip with your clients IP, who should receive the stream #   ​exchange the ip with your clients IP, who should receive the stream
-ffmpeg -f v4l2 -input_format yuyv422 -s 1280x720 -i /dev/video0 \+ffmpeg -f v4l2 -input_format yuyv422 -s 1280x720 ​-r 60 -i /dev/video0 \
   -vcodec mpeg2video -f mpegts udp://​192.168.0.2:​4242   -vcodec mpeg2video -f mpegts udp://​192.168.0.2:​4242
 # Client process, exchange with the IP of the Raspi who sends the stream: # Client process, exchange with the IP of the Raspi who sends the stream:
Line 85: Line 200:
  
 ===== Grabbing 1080p mode ===== ===== Grabbing 1080p mode =====
-At that point, I was debugging for very long, puzzled about no 1920x1080 modes grabbed by the board. ​Looking at the [[https://​world.taobao.com/​item/​602390051699.htm|specs]]we see that up to 1080p@25fps is offered. The chip can do more, but the 2 lane CSI2 bus to the Raspi is the bottleneck here.+At that point, I was debugging for very long, puzzled about no 1920x1080 modes getting ​grabbed by the board. ​Seems like no 60Hz can be grabbed, but 2530 or 50Hz. The chip can do more, but the 2 lane CSI2 bus to the Raspi is the bottleneck here.
  
-That mode is apparently not often offered by HDMI providing devices. My desktop with Xorg/Fedora can be configured to provide it, you need to explicitly create ​a mode for 1080p at 25Hz. I described a similar computation of the modeline for my [[snippets/​linux_4k_output|Samsung TV]], where my HDMI connection limits to only 4k@25Hz. You should not need to compile "​cvt12"​ as I did, you can directly add the mode with the values I used.+These modes are apparently not offered by all HDMI providing devices. My desktop with Xorg/Fedora can be configured to provide it, you need to explicitly create ​modes for 1080p at 25/30/50Hz. I described a similar computation of the modeline for my [[snippets/​linux_4k_output|Samsung TV]], where my HDMI connection limits to only 4k@25Hz. You should not need to compile "​cvt12"​ as I did, you can directly add the mode with the values I used.
 <​code>​ <​code>​
 [desktop]$ ./cvt12 1920 1080 25 [desktop]$ ./cvt12 1920 1080 25
Line 93: Line 208:
 Modeline "​1920x1080_25.00" ​ 65.75  1920 1968 2160 2400  1080 1083 1088 1099 -hsync +vsync Modeline "​1920x1080_25.00" ​ 65.75  1920 1968 2160 2400  1080 1083 1088 1099 -hsync +vsync
 [desktop]$ xrandr --newmode "​1920x1080_25.00" ​ 65.75  1920 1968 2160 2400  1080 1083 1088 1099 -hsync +vsync [desktop]$ xrandr --newmode "​1920x1080_25.00" ​ 65.75  1920 1968 2160 2400  1080 1083 1088 1099 -hsync +vsync
-[desktop]$ xrandr --output HDMI-1 --mode ​1920x1080_25.00+[desktop]$ xrandr --newmode "​1920x1080_30.00" ​ 79.75  1920 1976 2168 2416  1080 1083 1088 1102 -hsync +vsync 
 +[desktop]$ xrandr --newmode "​1920x1080_50.00" ​ 141.50 ​ 1920 2032 2232 2544  1080 1083 1088 1114 -hsync +vsync 
 +[desktop]$ xrandr --output HDMI-1 --mode ​1920x1080_50.00
  
-# Now at that point, we can grab 1920x1080@25Hz on the pi4: +# Now at that point, we can grab 1920x1080@25Hz on the pi4, firmware mode
-mplayer tv:// -tv driver=v4l2:​device=/​dev/​video0:​width=1920:​height=1080:​fps=25:​outfmt=yuy2+mplayer tv:// -tv driver=v4l2:​device=/​dev/​video0:​width=1920:​height=1080:​fps=50:​outfmt=yuy2 
 +# ..or with the kernel drivers: 
 +yavta --capture=1000 -n 3 --encode-to=file.h264 -f UYVY -m -T /​dev/​video0 
 +vlc file.h264
 </​code>​ </​code>​
  
Line 109: Line 229:
 # Works, but needs much bandwidth, of course. # Works, but needs much bandwidth, of course.
 mplayer tv:// -tv driver=v4l2:​device=/​dev/​video0:​width=1280:​height=720:​fps=30:​outfmt=yuy2 mplayer tv:// -tv driver=v4l2:​device=/​dev/​video0:​width=1280:​height=720:​fps=30:​outfmt=yuy2
 +
 +# get gstreamer
 +apt install -y gstreamer1.0-tools gstreamer1.0-nice gstreamer1.0-plugins-bad \
 +  gstreamer1.0-plugins-ugly gstreamer1.0-plugins-good gstreamer1.0-omx
 +  ​
 +# kernel based recording, with ffmpeg
 +./yavta -f UYVY --capture=3000 -n 3 --encode-to=- -m -T /dev/video0 | \
 +  ffmpeg -i - -r 30 -vcodec copy file.mp4
  
 # This uses ~300kbyte/​sec,​ has just some seconds latency over # This uses ~300kbyte/​sec,​ has just some seconds latency over
Line 134: Line 262:
   framerate=30/​1,​bitrate=500000 ! h264parse ! rtph264pay config-interval=-1 \   framerate=30/​1,​bitrate=500000 ! h264parse ! rtph264pay config-interval=-1 \
   pt=96 ! udpsink host=192.168.0.2 port=5000   pt=96 ! udpsink host=192.168.0.2 port=5000
 +gst-launch-1.0 v4l2h264enc ! video/​x-h264,​width=1280,​height=720,​\ 
 +  framerate=30/​1,​bitrate=500000 ! h264parse ! rtph264pay config-interval=-1 \ 
 +  pt=96 ! udpsink host=192.168.0.2 port=5000 
 +  ​
 # This works too, but huge delay # This works too, but huge delay
 # server # server
Line 166: Line 297:
 </​code>​ </​code>​
  
-===== Direct/​kernel mode ===== +===== Attempts to grab audio from the HDMI stream ​===== 
-This section ​is following ​[[https://github.com/mzyy94/​ns-remote/|this approach]], which is not using the firmware based configbut via kernel module. More details ​are [[https://​www.raspberrypi.org/​forums/​viewtopic.php?​f=38&​t=120702|here]] (yes600+ posts..), and [[https://​mzyy94.com/​blog/​2020/​05/​11/​play-nintendo-switch-on-smartphone/#​hdmi%E5%85%A5%E5%8A%9B%E3%82%92%E6%89%B1%E3%81%86|here]].+  * First: observing that no audio is captured from the HDMI stream. 
 +  * It seems like technically,​ audio could be sent via CSI2 (the interface cable H2C-RPI-B01 <-> Raspi4) on an alternate data type. [[https://www.raspberrypi.org/forums/viewtopic.php?​f=38&​t=120702&​p=1666020#​p1665584|source]] 
 +  * Based on the "I2S SYNC error!"​it seemed them most likely that additional wires are required, ​[[https://​www.raspberrypi.org/​forums/​viewtopic.php?​f=38&​t=120702&​p=1666020#​p1666015|source]]
 +    * "​You'​ll need to solder either wires or a header to those holesand then connect across to the relevant pins on the 40pin header of the PiDo exercise some caution when soldering to ensure you don't short anything to either 3.3V or GND. IRINT, RST, OSCL and 3.3V can all be ignored.
 +    * or: GPIO hammer header
 <​code>​ <​code>​
-vi /​boot/​config.txt +| Signal ​  ​| B101 header | Pi 40 pin header | 
-# Ensure the following are set/​active:​ +|----------|:​-----------:​|:​----------------:​| 
-  ​dtparam=i2c_arm=on +| LRCK/WFS |     ​7 ​      ​| ​     19          | 
-#   ​dtparam=i2s=on +| BCK/​SCK ​ |     ​6 ​      ​| ​     18          | 
-#   ​dtparam=spi=on +| DATA/​SD ​ |     ​5 ​      ​| ​     20          | 
-#   ​dtparam=i2c_vc=on +| GND      |     ​8 ​      ​| ​     39          | 
-#   ​dtparam=audio=on +</​code>​ 
-#   ​dtoverlay=vc4-fkms-v3d +  * [[https://​twitter.com/​mzyy94|mzyy94@]] has tried to solder the 4 cables, but [[https://​twitter.com/​mzyy94/​status/​1265179392965177344|still gets no sound]]. 
-#   ​dtoverlay=dwc2 +  * Only other idea would be to reach out to the maker of the  H2C-RPI-B01,​ will try that.
-#   ​dtoverlay=tc358743 +
-#   ​dtoverlay=tc358743-audio +
-#   ​start_x=1 +
-#   ​gpu_mem=128 ​ +
-reboot+
  
-# verify if the module got loaded +<code
-[root@pi4 31°C ~]$ dmesg | grep tc358743 +Does our HDMI stream ​offer audio at all?
-[    4.183486] tc358743 0-000f: tc358743 found @ 0x1e (bcm2835 I2C adapter) +
-[root@pi4 31°C ~]$ lsmod|grep tc358743 +
-tc358743 ​              ​40960 ​ 1 +
-v4l2_dv_timings ​       36864  2 bcm2835_unicam,​tc358743 +
-v4l2_fwnode ​           20480  2 bcm2835_unicam,​tc358743 +
-v4l2_common ​           16384  3 bcm2835_unicam,​bcm2835_v4l2,​tc358743 +
-videodev ​             200704 ​ 9 bcm2835_unicam,​v4l2_fwnode,​bcm2835_codec,​v4l2_common,​videobuf2_common,​bcm2835_v4l2,​v4l2_mem2mem,​videobuf2_v4l2,​tc358743 +
-media                  36864  5 bcm2835_unicam,​bcm2835_codec,​videodev,​v4l2_mem2mem,​tc358743 +
-[root@pi 31°C ~]$  +
- +
-# In userland mode, the application (i.e. raspivid) is from the +
-# tc358743 informing the HDMI peer about available HDMI modes, via EDID. +
-# Here for kernelmode driver, we need to do that ourself. +
-# wget https://​raw.githubusercontent.com/​6by9/​RPiTest/​master/​1080P50EDID.txt +
-git clone https://​github.com/​mzyy94/​ns-remote +
-v4l2-ctl --set-edid=file=ns-remote/​720P30EDID.txt +
-v4l2-ctl --set-dv-bt-timings query +
- +
-# Now we can query which mode has been agreed on: +
-v4l2-ctl --query-dv-timings +
- +
-# List all supported modes: +
-v4l2-ctl --list-dv-timings +
- +
-# Try to set one of the modes from "​list-dev-timings":​ +
-v4l2-ctl --set-dv-bt-timings ​<parameters> +
- +
-We can now record a h264 file, playable with VLC.  Records 10 seconds. +
-# https://​www.raspberrypi.org/​forums/​viewtopic.php?​f=38&​t=120702&​start=425#​p1385724 +
-git clone  https://​github.com/​6by9/​yavta +
-cd yavta/ +
-make +
-./yavta --capture=1000 -n 3 --encode-to=file.h264 -f UYVY -m -T /​dev/​video0 +
- +
-# Do we receive audio in the HDMI stream?+
 v4l2-ctl --list-ctrls v4l2-ctl --list-ctrls
 | audio_present (bool) ​  : default=0 value=0 flags=read-only | audio_present (bool) ​  : default=0 value=0 flags=read-only
Line 289: Line 384:
  
   * TODO   * TODO
-    * rework doc: write new way first 
     * sound. "​arecord -l" can not record.     * sound. "​arecord -l" can not record.
-      * https://www.raspberrypi.org/​forums/​viewtopic.php?​f=38&​t=120702&​sid=42e6acf1c8882cfadc40ed4ae3670fe0&​start=650#​p1665584 +      * confirm with vendor via website if the board is capable of doing thisIts not explicitly stated in the few lines of spec on the sitebut one could assume it is part of "HDMI grabbing"​
-    * ffmpegtry other codecs +      * I need extra wiring.. board<​->​pi4
-    * yavta: https://​github.com/​6by9/​yavta +    * kernel module debug parameters: https://​www.raspberrypi.org/​forums/​viewtopic.php?​f=38&​t=120702&​start=450#​p1389665 
-      * https://www.raspberrypi.org/​forums/​viewtopic.php?​f=38&​t=120702&​start=400#​p1339178 +    * uv4l approach. It's a separate application,​ no free source code, but might be usable.
-      * kernel module debug parameters: https://​www.raspberrypi.org/​forums/​viewtopic.php?​f=38&​t=120702&​start=450#​p1389665 +
-    * uv4l+
       * http://​blog.cudmore.io/​post/​2019/​12/​14/​Installing-uv4l-on-raspian-buster/​       * http://​blog.cudmore.io/​post/​2019/​12/​14/​Installing-uv4l-on-raspian-buster/​
       * https://​www.linux-projects.org/​uv4l/​installation/​       * https://​www.linux-projects.org/​uv4l/​installation/​
       * https://​www.raspberrypi.org/​forums/​viewtopic.php?​t=247305#​p1580751       * https://​www.raspberrypi.org/​forums/​viewtopic.php?​t=247305#​p1580751
  
hardwarerelated/raspberry_pi_4_tc358743.1590283203.txt · Last modified: 2020/05/24 03:20 by chris