matiaspl

SUDO_UID=1000 ./telepi | export SUDO_UID=1000 cvlc -vvv stream:///dev/stdin --sout '#standard{access=http,mux=ts,dst=:8090}' :demux=h264

matiaspl

Derived from screen's EDID (which seems to be wrong - bad checksum) using wxEDID, cvt_modeline_calculator. It's a pitty the embedded controller doesn't have hardware rotation because the screens orientation (portrait) seems to be the source of all evil.

On Windows machines the screen does run in FHD, HD and QHD modes. The resolutions below are only full HD, the "b" mode worked best for me.

export DISPLAY=:0

xrandr --newmode "a" 116.148  1080 1112 1144 1184  1920 1928 1932 1936  -HSync +VSync
xrandr --newmode "b" 137.533440  1080 1112 1144 1184  1920 1928 1932 1936  -HSync +VSync
xrandr --newmode "c" 114.611200  1080 1112 1144 1184  1920 1928 1932 1936  -HSync +VSync

matiaspl

All Tronxy stuff goes here

cprsImage.py - algorithm for creating previews displayed on the Tronxy LCD using M4010 GCODE commands (as seen in the Tronxy Slicer) - base for a Cura postprocessing script/plugin. The function is executed from Tronxys' CuraEngineBackend like this:

if self._screenshotImages and Preferences.getInstance().getValue('cura/enablePreview'):
            startX, startY, endX, endY = cprsImage.detectImageValidRange(self._screenshotImages[1])
            self._scene.gcode_list.insert(0, cprsImage.genImageGcode(self._screenshotImages[0], startX, startY, endX, endY))

matiaspl

mpv --hwdec="no" --lavfi-complex="[aid1]asplit=3[sv][eb][av];[sv]showvolume=b=4:w=720:h=68[sv-v];[eb]ebur128=video=1:size=720x540:meter=18[eb-v][ao];[av]avectorscope=s=720x540:zoom=1.3:rc=2:gc=200:bc=10:rf=1:gf=8:bf=7[av-v];[sv-v][eb-v][av-v]vstack=3[1c];[vid1]split=4[v][wf][wfc][vs];[wf]waveform=m=1:d=0:r=0:c=7[wf-vus];[wf-vus][v]scale2ref=iw:1220-ih[wf-va][sig];[wf-va]setsar=1[wf-v];[wfc]waveform=m=0:d=0:r=0:c=7,scale=610x610,setsar=1[wfc-v];[vs]vectorscope=m=color3:g=color,scale=610x610,setsar=1[vs-v];[sig][wf-v]vstack[2c];[wfc-v][vs-v]vstack[3c];[1c][2c][3c]hstack=3,scale=1280:-1[vo]" rtmp://server/app/key

matiaspl

Why would you even want to do that?

Well, there are some vendor locked dongles out there (I'm looking at you Panasonic!) that use regular off-the-shelf chips but cost a lot of money and not $5 that they're really worth. E.g. there's the AJ-WM50E dual band AC dongle (sold for 160 USD) that you should use with AG-UX180 camera to get wifi CCU running.

I happen to have one such dongle, couple of summer holiday nights and family far, far away. Why not do some hacking then?

The camera is - as far as I can tell - running Linux or a similar system. If so, it has a limited set of tools to get to know what's getting connected to it.

Ultimate goal

Make the not-so-Panasonic dongle resemble the Panasonic one as much as possible, so that the camera just enables it thinking it's legit.

matiaspl

You might ask why would anyone do it in the first place? Well, OBS is the only reasonable free tool for OSX for streaming but it has a flaw which makes it impossible to stream 1080p50/p60 on my i5 MacBook Pro. It works if you disable preview, but then if you can't see the video there's no reason for using OBS ;)

You need ffmpeg-dl from ffmpegdecklink brew package by AMIA Open Source (brew install ffmpegdecklink). It's worth noting that unlike brew's regular ffmpeg this one allows building ffmpeg with additional libraries (e.g. brew install ffmpegdecklink -with-srt in case you need SRT).

/usr/local/opt/ffmpegdecklink/bin/ffmpeg-dl -f decklink -i 'UltraStudio Mini Recorder' -video_input hdmi -format_code Hi50 -audio_input embedded -channels 2 -vf yadif=1 -c:v h264_videotoolbox -profile:v main -b:v 6M -pix_fmt yuv420p -color_range 1 -coder cabac -c:a aac_at -b:a 192k -f flv rtmp://your_server/app/key

What this does is capture 1080i50 signal from HDMI input (use *-vi

matiaspl

This device has a design flaw which - if you're not careful enough - might lead to ethertnet socket popping out of the board and taking solder pads along on a bad day. And on a good day you might end up with partially working socket because only a smaller part of the socket will lose contact with the board - power but no link, link but no power, etc.

The bad thing is that the PCB is a multi layered one and you can't really see where the traces go. The good thing however is everyone uses a more or less reference design for ethernet sockets with isolation transformers. And it's easy to figure out what goes where if you know where to look (so I did).

The board utilizes an isolation transfermer U15 (Yuan Dean Scientific 15FB-10BNL) which includes four differential line isolation in a single package (IN and OUT sockets). The IN socket goes to pins 19, 21 (tx) and 22, 24 (rx). OUT socket uses 16, 18 (tx) and 13, 15 (rx). PoE for the input socket goes to the lower bridge rectifier BR2 (Vishay DF01S).

The fix: 1

matiaspl

U-Boot 2010.06 (Aug 11 2018 - 18:47:37)

Check Flash Memory Controller v100 ... Found
SPI Nor(cs 0) ID: 0xc2 0x20 0x17
Block:64KB Chip:8MB Name:"MX25L6436F"
SPI Nor total size: 8MB
Cannot found a valid SPI Nand Device
In:    serial
Out:   serial
Err:   serial

matiaspl

#!/bin/bash

: ${1?"Usage: $0 FPS (i.e. 25, 29.97, 60000/1001)"}

fps=$1
samplerate=48000
size=1920x1080
debug="-hide_banner"
#debug="-loglevel debug" # verbose
fontfile="UbuntuMono-R.ttf"

matiaspl

TS: VAAPI H264 to H265 transcode with deinterlacing

gst-launch-1.0 --gst-debug=2 -ev mpegtsmux name="mux"
souphttpsrc location=http://stream/url ! parsebin ! queue ! vaapih264dec ! vaapipostproc deinterlace-mode=1 deinterlace-method=4 width=1280 height=720 ! vaapih265enc rate-control=vbr bitrate=2000 keyframe-period=50 max-bframes=0 quality-level=4 ! video/x-h265,stream-format=hvc1 ! queue ! h265parse config-interval=1 ! video/x-h265,alignment=au,stream-format=byte-stream ! mux. tcpserversink host=0.0.0.0 port=1234

TS: audio transcode

gst-launch-1.0 --gst-debug=2 -ev souphttpsrc location=http://stream/url ! tsparse ! tsdemux ! queue ! flump3dec ! audioconvert ! avenc_aac ! aacparse ! mpegtsmux ! tcpserversink host=0.0.0.0 port=1234

TS: audio remux