p2p-webtransport
ffplayout
p2p-webtransport | ffplayout | |
---|---|---|
1 | 6 | |
156 | 432 | |
1.9% | 4.4% | |
7.0 | 9.5 | |
7 months ago | 7 days ago | |
HTML | Rust | |
GNU General Public License v3.0 or later | GNU General Public License v3.0 only |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
p2p-webtransport
-
Video Live Streaming: Notes on RTMP, HLS, and WebRTC
> I just wish WebRTC wasn't so prescriptive of DTLS/SRTP.
There was a webrtc-webtransport spec, but it got renamed to p2p-webtransport[1]. I'm not sure when the rename happened. Feels like a pretty strong indicator of webrtc being deconstructed, but whose to say this goes anywhere. We'd also need webcodecs.
It's somewhat scary & also somewhat exciting thinking of the one good, working, browser supported standard being ripped into pieces (p2p-webtransport, webcodecs, more) & being user-implemented. Having the browser & servers have a well-known target is both great but also perhaps confining. If we leave it up to each site/library to DIY their solution, figure out how to balance the p2p feeds, it'll be a long long time before the Rest of the World (other than the very big few) have reasonable tech again. WebRTC is quite capable & a nice even playing field, with lots of well-known rules to enable creative interopation. We'd be throwing away a lot. I'd hoped for webrtc-webtransport, to at least keep some order & regularity, but that seems out, at the moment. But Webrtc-nv is still ultra-formative; anything could happen.
The rest of the transport stack is also undergoing massive seismic shifts. I feel like we're in for a lot of years of running QUIC or HTTP3 over WebRTC Data-Channels and over WebTransport, so we can explore solutions the new capabilities while not having to ram each & every change through with the browser implementers. It feels like a less visible but far more massive Web Extensibility Manifesto moment, only at sub-HTML levels[2]. The browsers refused to let us play with HTTP Push, never let appdevs know realtime resources had been pushed at the browser, so we're still debating terrible WebSocket vs SSE choices; terrible. I think of gRPC-web & what an abomination that is, how sad & pointless that effort is; all because the browser is a mere glimmer of the underlying transport. I feel like a lot of experimentation & exploration is going to happen if we start exploring QUIC or HTTP3 over WebTransport. Attempts to reimagine alternatives to WebRTC are also possible if we had specs like p2p-webtransport, or just did QUIC over DataChannels. Running modern protocols in the client, not the browser, seems like a semi-cursed future, but necessary, at least for a while, while we don't yet know what we could do. The browsers are super laggy, slow to expose capabilities.
[1] https://github.com/w3c/p2p-webtransport
[2] https://github.com/extensibleweb/manifesto
ffplayout
-
Self-hosting a simple virtual TV station
What a cool project idea! Owncast would be a great solution for you from the broadcasting end, and I'd be happy to answer any questions you have about it. From the programming/scheduling side you could do something super simple like this project https://github.com/owncast/playout-example that plays from a directory, or build something more custom with ffplayout https://github.com/ffplayout/ffplayout
-
Beginner issues… My session with my VPS keeps ending after 6-12 hours with "client_loop: send disconnect: Broken pipe", also ending the script that it's running at the same time. Not sure which piece of things I should be troubleshooting
I have a VPS running Ubuntu. Things generally run fine with it—I connect to it through Terminal on my Mac to run the Python script it's set up for, and I use Filezilla to manage its files. I am running the Python version of ffplayout on it, and it works as intended until a certain point, typically somewhere between 6-12 hours, at which point I get the "client_loop: send disconnect: Broken pipe" message in Terminal, and ffplayout stops running and Terminal's connection to the server is broken.
-
Self Hosted Video Stream Question
Hi, you wan try ffplayout. Work well with owncast for exemple.
-
PC based video playback
Try https://github.com/ffplayout/ffplayout
-
Video Live Streaming: Notes on RTMP, HLS, and WebRTC
I do something like this by using https://github.com/ffplayout/ffplayout-engine
-
Video Playout schedule software?
ffplayout maybe?
What are some alternatives?
webrtc-nuts-and-bolts - A holistic way of understanding how WebRTC and its protocols run in practice, with code and detailed documentation.
FFmpeg - Mirror of https://git.ffmpeg.org/ffmpeg.git
rtp-over-quic-draft
IPTV-Channels - A collection of IPTV channels that can be accessed across the world!
docker-wyze-bridge - WebRTC/RTSP/RTMP/LL-HLS bridge for Wyze cams in a docker container
folderplayout - CasparCG client for scheduled recurring playback of a playlist.
Ant-Media-Server - Ant Media Server is a live streaming engine software that provides adaptive, ultra low latency streaming by using WebRTC technology with ~0.5 seconds latency. Ant Media Server is auto-scalable and it can run on-premise or on-cloud.
FirebaseRTC - Codelab for building a WebRTC Video chat application using Firebase Cloudstore.
video-to-ascii - It is a simple python package to play videos in the terminal using characters as pixels
overpass - A self-hosted live video streaming platform with Discord authentication, auto-recording and more!
owncast - Take control over your live stream video by running it yourself. Streaming + chat out of the box.