HackerTrans
トップ新着トレンドコメント過去質問紹介求人

iod

no profile record

コメント

iod
·11 か月前·議論
You of course can, assuming that your hardware configuration supports eMMC with dedicated hardware boot partition(s). Some devices, like the one I used in my example, in its default configuration the hardware is actually booted from a MicroSD card as a regular mmc block device; which is quite common in hobbyist targeted SBCs. In those cases you have to be cognizant of boot loader firmware locations if you want a GPT partition table, as most user guides and sample disk images for these systems assume MBR style partition table reserving only the first block. Followed by system-specific boot blob(s) at the required offset location and then a fat32 partition somewhere thereafter with the OS. If the boot firmware blob starts before the 34th¹ block with 512-byte sectors blocks, then for setting up GPT, you move the main GPT table to after the firmware; otherwise you can just allocate the first partition space as reserved protected area in GPT for the firmware so that it doesn't get written to as a reference for future repartioning.

¹ https://en.wikipedia.org/wiki/GUID_Partition_Table#Features
iod
·11 か月前·議論
U-Boot does actually have some support for GOP Video¹. It's rather new, so it might be worth revisiting with your specific devices.

¹ https://u-boot.org/blog/seeing-is-believing-video-support-la...
iod
·11 か月前·議論
U-Boot does basic enough UEFI emulation for most use cases. I find that I don't need native UEFI firmware and I can just build U-Boot with UEFI support for most ARM devices.

For example, right now I have an old armhf i.MX6 Wandboard Quad that runs:

  U-Boot -> UEFI (with Secure Boot if desired) -> Systemd Boot (or Linux EFI Boot Stub) -> Debian (or other distro)
That same layout should be doable on any U-Boot¹ supported device.

Some arm devices such as the i.MX6, are strict on the placement of their boot firmware where it would interfere with a normal GPT table. One solution to this is to use a special "--move-main-table" option in gdisk² so that the GPT doesn't clobber U-Boot. While technically GPT is optional as long as U-Boot can read your main partition, I still always setup GPT anyway or Systemd Boot complains.

¹ https://docs.u-boot.org/en/latest/develop/uefi/uefi.html

² https://www.rodsbooks.com/gdisk/sgdisk.html
iod
·2 年前·議論
People interested in FUSE might also be interested in the CUSE companion (sub)project.

CUSE is userspace character device driver emulation. It allows you to emulate hardware without compiling a new kernel module. I just used it recently to write a hardware device supporting IOCTLs using Python. However I didn't find any good Python libraries that worked easily and documentation was lacking, but I found it easy enough that I ended up writing it using just the ctypes ffi library. The only part that wasn't immediately intuitive for me, as someone who has never written kernel drivers, is how IOCTL's require the buffers to be resized for each read and write which means the calls come in pairs, but luckily CUSE has a debug mode which shows all bytes in and out. CUSE was originally implemented to create userspace sound devices¹ but has also been use for things like custom TTYs. I used it for creating a virtual SPI device. Hopefully someone finds this useful and this project can get more attention.

¹ https://lwn.net/Articles/308445/
iod
·2 年前·議論
As per the direct quote in my parent comment, by "unlimited concurrent viewers", I can only assume that they mean what it says as taken by the text from the links of both ¹⁺²
iod
·2 年前·議論
People interested in this project might also be interested in Cloudflare's webrtc streaming service¹ as a cloud hosted solution to this same problem. "Sub-second latency live streaming (using WHIP) and playback (using WHEP) to unlimited concurrent viewers." Using the same OBS WHIP plugin, you can just point to Cloudflare instead. Their target pricing model is $1 per 1000 minutes.² Which equates to $0.06 per hour streamed.

¹ https://developers.cloudflare.com/stream/webrtc-beta

² https://blog.cloudflare.com/webrtc-whip-whep-cloudflare-stre...
iod
·2 年前·議論
I used the demo streaming.html code linked above as-is and host it statically on Nginx alongside Janus on a cloud VPS. As far as config, there is just the one file: /etc/janus/janus.plugin.streaming.jcfg , but you can leave it blank and just use the html api¹ if you don't want to mess with that file as the API has an option:

  "permanent":true
that automatically generates/updates the config for you. You can substitute srtp (secure) for regular rtp for testing, but I prefer to use the secure variant since it goes out to a public VPS and doesn't really incur any overhead for my source devices.

¹ https://janus.conf.meetecho.com/docs/streaming#streamapi

I wrote a little helper shell code using wget, openssl, dd, jq, and jo to make it easy to talk JSON to the API, for the one-off configs I do. Here is an example of what I use which demonstrates simulcast and srtp ingestion for both h264 and vp8 video streams as well as opus audio. Just fill in the [ ]'s with your specifics. I then use ffmpeg to generate all the streams and pipe to the appropriate ports for each simulcast level and target. If you use gstreamer beware srtp key format is different.

  #!/bin/sh
  server="https://[YOUR_JANUS_SERVER_HOST]/janus"
  token(){ dd if=/dev/urandom bs=6 count=1 status=none|openssl base64;}
  post_jo(){ first="$1";shift;wget --quiet --output-document - --post-data "$(jo -- "$@")" "$server$first";}
  tx(){ post_jo "$@" transaction="$(token)";}
  data_id(){ jq ".data.id//(null|halt_error(1))";}
  message()( set -e
    id="$(tx / janus=create|data_id)" # create janus session and store id
    hn="$(tx "/$id" janus=attach plugin=janus.plugin.streaming|data_id)" # create plugin session and store id
    tx "/$id/$hn" janus=message body="$(jo -- "$@")"
    tx "/$id" janus=destroy >/dev/null
  )

  # example usage:

  # list all streams
  message request=list|jq .plugindata.data.list

  # remove stream with id 666
  message request=destroy id=666 secret=adminpwd permanent=true|jq 

  # create new stream
  message request=create id=666 secret=adminpwd permanent=true name=[YOUR_STREAM_NAME] type=rtp media=["$(
    jo type=video mid=v1 codec=h264 pt=96 simulcast=true svc=false port=5010 port2=5020 port3=5030 \
      fmtp=level-asymmetry-allowed=1\;packetization-mode=1\;profile-level-id=42c01f
    )","$(
    jo type=video mid=v2 codec=vp8 pt=96 simulcast=true svc=false port=5012 port2=5022 port3=5032
    )","$(
    jo type=audio mid=a codec=opus pt=97 port=5000
    )"] srtpsuite=80 srtpcrypto=zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz|jq # your srtp token needs to match your source

  # show new stream info to verify configuration
  message request=info id=666 secret=adminpwd|jq

  # on streaming source device
  ffmpeg [YOUR_INPUT_CONFIG HERE] -f rtp -srtp_out_suite SRTP_AES128_CM_HMAC_SHA1_80 -srtp_out_params zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz srtp://[YOUR_JANUS_SERVER_HOST]/:[PORT]

  # for gstreamer, showing alternative key format
  gst-launch-1.0 [YOUR_INPUT_CONFIG HERE] ! rtpav1pay ! srtpenc key=cf3cf3cf3cf3cf3cf3cf3cf3cf3cf3cf3cf3cf3cf3cf3cf3cf3cf3cf3cf3 ! udpsink host=[YOUR_JANUS_SERVER_HOST] port=[PORT]
iod
·2 年前·議論
I went to your discourse link. As Lorenzo was trying to say, you will want to get a better idea what is going on with ICE candidate gathering. In firefox there is an about:config setting that might help with this:

  media.peerconnection.ice.obfuscate_host_addresses = false
which will show the actual deobfuscated candidates host addresses. Here is a tool you can run on your client to see the stun candidates received.

https://webrtc.github.io/samples/src/content/peerconnection/...

If you do not get any valid candidates, then it is most likely a misconfiguration of your browser, vpn, firewall or network. Unfortunately this is most likely not a Janus thing, but I would need more information to know for sure.
iod
·2 年前·議論
Another library that I would recommend people look into for live streaming to WebRTC, as an alternative to Pion used in this project, is Janus WebRTC Server. I use it for ingesting RTP streams I generate from usb webcams and then playing it with very low latency in the browser. It even has a feature where you can stream multiple streams simultaneously. It also has a simple http api for adding, updating, and removing streams on demand.

Here is the library's streaming demo:

https://janus.conf.meetecho.com/demos/streaming.html
iod
·2 年前·議論
Webtorrent

Use a free signalling server from the webtorrent community. You can skip the torrent part of the implementation and just use the signalling, it's awesome. You can use a libraries like:

https://github.com/webtorrent/bittorrent-tracker

https://github.com/subins2000/p2pt

to get started. For me, I found the protocol is simple enough where I just use small vanilla javascipt implementation to talk to the websocket servers to generate the signalling messages. I wish more people knew about this and realize how easy it can be to bring WebRTC to their applications.

List of some free webtorrent trackers:

  wss://tracker.openwebtorrent.com
  wss://tracker.files.fm:7073
  wss://tracker.webtorrent.dev
---> Usage stats for the last one: https://tracker.webtorrent.dev

Some free stun servers for NAT traversal:

  stun:stun.cloudflare.com
  stun:stun.l.google.com:19302
iod
·2 年前·議論
I am sorry if this comes off to be negative, but with every example provided on the site, when compiled and then fed into ShellCheck¹, generates warnings about non-portable and ambiguous problems with the script. What exactly are we supposed to trust?

¹ https://www.shellcheck.net
iod
·4 年前·議論
For single player you have to select "Uplink", "Hazard Course", or "Day One" for your game data. "HLDM" is for multiplayer.