4 ms·

At a guess I'd say yes. The Pi 3 model could run Chromium and play YouTube at a reasonable-ish speed in a full desktop environment. The Pi 4 is faster with mor

At a guess I'd say yes. The Pi 3 model could run Chromium and play YouTube at a reasonable-ish speed in a full desktop environment. The Pi 4 is faster with more RAM (if you get the larger RAM models which go up to 8GB). This one is faster again than the Pi4B.

morsch 6y ago
Thanks, however playing YouTube only requires decoding video which is less difficult than encoding it. You need both for Jitsi, and at a non-trivial resolution (>=720p) to boot.
- alias_neo 6y ago
  I understand. I develop secure (video) communications solutions for a living. I don't have a feel for the encode capability of the Pi as I've never used it for that purpose but I still think you should be OK at ~1080p. Like I said originally it is a guess, but if it's of help to have some experimental evidence, I'm happy to rip a Pi4B out of my rack at some point and run some tests if I can spin up a Jitsi server quickly with Docker.
  - morsch 6y ago
    Well, that would be above and beyond. ;) No need to spin up a server, though? Public rooms are available at http://meet.jit.si/ http://meet.jit.si/. (This is an entirely different thing, but apropos: the RPi 4 is too slow to run the Jitsi Meet server, at least according to the devs: Arm and 4GB of ram are not enough to run it https://community.jitsi.org/t/jitsi-meet-on-raspberry-pi-4-feasible-or-not/24457 https://community.jitsi.org/t/jitsi-meet-on-raspberry-pi-4-f...)
    - alias_neo 6y ago
      Understood. I was planning to spin up the server on a "proper" server machine and just use the Pi as a client (which is the metric I believe you're interested in). If public servers are available, I can just spin up two clients on Pis and give it a test calling between the two. I don't have many options for USB cameras but I can figure something out. I do have a CSI camera I can test on one Pi though. I've made a note to test this. I'll need some time as they're mounted in a server rack case I built and will need to be removed and re-installed with a DE to test at my desk.
    - alias_neo 6y ago
      Ok, I've run the test on a Pi4B 4GB and my Laptop. The Pi4B is hard wired to a gigabit network, the laptop on WiFi AC. The Pi is using a Microsoft LiveCam USB webcam, the laptop is using the built in (1080p?) camera. The Pi is running the Raspberry Pi OS desktop which I've just downloaded/installed and fully updated and is using the Chromium Browser. Laptop running Ubuntu 20.04 and Firefox. The Pi decodes HD reasonably well with some occasional glitching but only encodes SD, Jitsi complains about the network being non-optimal but that appears to be a red-herring, all 4 cores are at 100%. If I lower the "call quality" slider to SD the network issue goes away. The video received on the laptop from the Microsoft HD webcam on the Pi is 420x270. it's smooth and the frame rate and latency is "good" but it's pretty "soft" at full screen due to the low resolution. In conclusion, I don't believe you're reasonably going to be able to get 720p or 1080p encoding out of it with Jitsi Meet in Chromium. Anything else you'd like to know?
      - NanoCoaster 6y ago
        Hey, I'm not morsch, just wanted to thank you for testing and posting the results :) Too bad, but probably to be expected. The RasPi wasn't really meant for tasks like this. Still, actually interesting that it would suffice in a pinch if you just needed to just stream some video, even if the quality isn't really good.
        alias_neo 6y ago
        No problem, hopefully it helps answer some peoples questions about the kind of performance to expect. I imagine Jitsi isn't taking advantage of hardware encoding capability (It's using VP8/Opus in my testing) but it gives an idea of what's currently possible. That said, as I mostly work on native code for the communications work I do, I imagine the Pi would do a much better job with a native client and the right codecs.
        morsch 6y ago
        You can use native code to stream to Jitsi using UV4L[1]. At least I think you could, at some point. It's a bit odd, certainly not as plug and play as using the browser. [1] http://www.linux-projects.org/uv4l/ http://www.linux-projects.org/uv4l/

morsch 6y ago

Thanks, however playing YouTube only requires decoding video which is less difficult than encoding it. You need both for Jitsi, and at a non-trivial resolution (>=720p) to boot.

alias_neo 6y ago
I understand. I develop secure (video) communications solutions for a living. I don't have a feel for the encode capability of the Pi as I've never used it for that purpose but I still think you should be OK at ~1080p. Like I said originally it is a guess, but if it's of help to have some experimental evidence, I'm happy to rip a Pi4B out of my rack at some point and run some tests if I can spin up a Jitsi server quickly with Docker.
- morsch 6y ago
  Well, that would be above and beyond. ;) No need to spin up a server, though? Public rooms are available at http://meet.jit.si/ http://meet.jit.si/. (This is an entirely different thing, but apropos: the RPi 4 is too slow to run the Jitsi Meet server, at least according to the devs: Arm and 4GB of ram are not enough to run it https://community.jitsi.org/t/jitsi-meet-on-raspberry-pi-4-feasible-or-not/24457 https://community.jitsi.org/t/jitsi-meet-on-raspberry-pi-4-f...)
  - alias_neo 6y ago
    Understood. I was planning to spin up the server on a "proper" server machine and just use the Pi as a client (which is the metric I believe you're interested in). If public servers are available, I can just spin up two clients on Pis and give it a test calling between the two. I don't have many options for USB cameras but I can figure something out. I do have a CSI camera I can test on one Pi though. I've made a note to test this. I'll need some time as they're mounted in a server rack case I built and will need to be removed and re-installed with a DE to test at my desk.
  - alias_neo 6y ago
    Ok, I've run the test on a Pi4B 4GB and my Laptop. The Pi4B is hard wired to a gigabit network, the laptop on WiFi AC. The Pi is using a Microsoft LiveCam USB webcam, the laptop is using the built in (1080p?) camera. The Pi is running the Raspberry Pi OS desktop which I've just downloaded/installed and fully updated and is using the Chromium Browser. Laptop running Ubuntu 20.04 and Firefox. The Pi decodes HD reasonably well with some occasional glitching but only encodes SD, Jitsi complains about the network being non-optimal but that appears to be a red-herring, all 4 cores are at 100%. If I lower the "call quality" slider to SD the network issue goes away. The video received on the laptop from the Microsoft HD webcam on the Pi is 420x270. it's smooth and the frame rate and latency is "good" but it's pretty "soft" at full screen due to the low resolution. In conclusion, I don't believe you're reasonably going to be able to get 720p or 1080p encoding out of it with Jitsi Meet in Chromium. Anything else you'd like to know?
    - NanoCoaster 6y ago
      Hey, I'm not morsch, just wanted to thank you for testing and posting the results :) Too bad, but probably to be expected. The RasPi wasn't really meant for tasks like this. Still, actually interesting that it would suffice in a pinch if you just needed to just stream some video, even if the quality isn't really good.
      - alias_neo 6y ago
        No problem, hopefully it helps answer some peoples questions about the kind of performance to expect. I imagine Jitsi isn't taking advantage of hardware encoding capability (It's using VP8/Opus in my testing) but it gives an idea of what's currently possible. That said, as I mostly work on native code for the communications work I do, I imagine the Pi would do a much better job with a native client and the right codecs.
        morsch 6y ago
        You can use native code to stream to Jitsi using UV4L[1]. At least I think you could, at some point. It's a bit odd, certainly not as plug and play as using the browser. [1] http://www.linux-projects.org/uv4l/ http://www.linux-projects.org/uv4l/