The Nearglass command

nearglass publish sends one stream to the relays without the ingest in between. It has three jobs: replay an H.264 file as a live source, take one SRT or RTMP encoder on your own machine, or capture a camera and encode it on a Rockchip board's hardware encoder. Video is not re-encoded on the way through (the camera case encodes once, on the chip).

The command is in the nearglass package, with nearglass ingest and nearglass token. Unpack it and run nearglass publish --help for every option.

Where it publishesCopy Anchor Link

One of three, chosen by the options you give.

Through the control API (the usual one). The API names the relays and the namespace, and mints a publisher token for every connection, so there is no token to keep.

echo "$SK" > sk.txt && chmod 600 sk.txt
nearglass publish --api https://api.nearglass.com --secret-key-file sk.txt --stream st_... \
  --file film.ts --loop

The stream can be any of yours; it does not need sdk in its ingest. A relay ends a publishing session when its token expires, and nearglass publish reconnects with a fresh one, so a stream stays up past --token-ttl. The log line publishing through the control API shows the relays it was told to use.

From a descriptor file. Save the answer of POST /v1/streams/{id}/publisher-tokens and give it with --descriptor pub.json. The token inside is fixed: when it expires (ttl, up to 7 days), the publish stops and the file has to be replaced. For an unattended device use --api.

By hand, for your own relay. --relay https://relay.nearglass.com/ (repeat for a failover list), --namespace live/cam and --token-file pub.tok, a token from Nearglass token mint --role publisher. See Self-hosting.

A relay with a self-signed certificate: a descriptor from the API pins it by its hash; by hand, give --tls-root with the certificate. --tls-disable-verify skips the check and is for local testing only.

What it publishesCopy Anchor Link

Exactly one of these.

A file: --fileCopy Anchor Link

nearglass publish --api $API --secret-key-file sk.txt --stream $ID --file film.ts --loop

The file is H.264 in MPEG-TS, or a raw Annex B stream (.h264, .264). It is replayed in real time, at its own timestamps; --loop repeats it until you press Ctrl-C. A raw stream is paced by the frame rate in its headers, or by --fps if it has none. Keyframes and B-frames are whatever the file has, so give it a keyframe every second and no B-frames. The command stops with an error if the file has no H.264 or no keyframe. The log line event=Session(Connected means a relay took the stream.

A file replay sends the picture only. For sound, publish from an encoder. The stream's ingest_token_at (in GET /v1/streams/{id}/stats) is set by the ingest, so it does not change for a nearglass publish; watch the log line instead.

Make a suitable file with ffmpeg:

ffmpeg -f lavfi -i testsrc2=size=1280x720:rate=30 -t 20 -c:v libx264 -preset veryfast \
  -tune zerolatency -bf 0 -pix_fmt yuv420p -force_key_frames "expr:gte(t,n_forced*1)" \
  -an -f mpegts film.ts

One encoder: --srt-listen or --rtmp-listenCopy Anchor Link

The command listens for a single encoder on your machine and forwards it to the relays. It is for a site where the encoder and this machine share a network, with no ingest host in between.

nearglass publish --api $API --secret-key-file sk.txt --stream $ID --srt-listen 0.0.0.0:9000

It prints the address to send to, with a key it makes up:

send SRT (MPEG-TS, H.264) to srt://0.0.0.0:9000?streamid=<key>

Replace 0.0.0.0 with this machine's address. --stream-key sets the key instead. --srt-latency-ms (default 120) is the SRT latency on this side. With --rtmp-listen 0.0.0.0:1935 it prints send RTMP to rtmp://0.0.0.0:1935/live with the stream key <key>. One encoder at a time, one stream, and this key is only for this run. The picture and sound rules are the same as for the ingest: see OBS and SRT. Sound is carried here too, on the same terms: AAC-LC or Opus, see Audio. The log line publishing ends with audio=Some("opus/1ch") (or similar) when the sound was taken.

A camera: --encoder mppCopy Anchor Link

On a Rockchip board (RK3588 or RK3576), --encoder mpp captures a V4L2 camera and encodes it on the chip's hardware encoder. It exists only in the Linux arm64 build with Rockchip MPP; any other build stops with --encoder mpp: this build has no hardware encoder.

nearglass publish --api $API --secret-key-file sk.txt --stream $ID \
  --encoder mpp --device /dev/video11 --size 1920x1080 --fps 60 --bitrate 8000000

The viewers' side can ask the encoder for a keyframe (a viewer joining) or a lower bitrate, and it does both. The camera path sends the picture only.

StoppingCopy Anchor Link

Ctrl-C, or SIGTERM (a systemd stop), ends the stream cleanly, so the relay frees the stream's name at once. --seconds stops after a set time.

When it does not workCopy Anchor Link