Ingest: The Gateway to Live Streaming​

The Ingest component is the first line of engagement for streamers. It adopts a protocol-agnostic stance, currently supporting RTMP, with plans to expand to WebRTC, SRT, and WARP/MOQ. The process encompasses:

The go-live process involves:

1. Authentication: Verifying the streamer's identity via their unique stream key when a new stream is initiated.
2. Validation & Transcoding: Ensuring the room's readiness, triggering a new transcoder job, and queuing it in our message broker.
3. Transcoding Handoff: The transcoder, upon receiving the queued job, interfaces with Ingest to fetch and transcode the incoming stream.
4. Broadcasting: Once the stream is transcoded, the room is flagged as live, inviting viewers to join in.

Ingest also serves as a safeguard against denial-of-service (DOS) attacks by managing data flow and ensuring packet integrity. Stream distribution to transcoders is based on system capacity, maintaining optimal load balancing. This setup also allows for dynamic scaling of transcoder resources in response to fluctuating live request volumes.

The separation of Ingest and Transcoder processes is intentional:

• Ingest's Lightweight Operation: As a transmuxer (changing stream containers, e.g., FLV to MP4), it's resource-efficient, capable of handling hundreds of streams on a single core.
• Transcoder's Resource-Intensive Task: As a transcoder (codec conversion or re-encoding), it's computationally demanding, with a single HD-quality stream requiring several CPU cores.

This division ensures scalability and cost-efficiency, enabling the use of preemptable cloud instances for transcoders to reduce expenses without risking stream continuity.

Transcoder: The Powerhouse of Video Quality​

Once authenticated, the incoming video is assigned to a transcoder job. Here's what happens:

• Configuration Check: It assesses room settings to determine necessary video qualities (HD, SD, LD) and whether to archive recordings to S3.
• FFmpeg Integration: Utilizing FFmpeg, it outputs fragmented mp4 files, which are then processed for optimal structure, essential for our player.

Currently, we transcode into H264 & AAC, with future plans to adopt AV1 & Opus. AV1's compression excellence and bandwidth efficiency are offset by its greater processing demands, which we aim to mitigate with specialized hardware.

Following transcoding, the segments are cached temporarily and then stored on S3 based on configuration preferences.

Edge: The Portal for Playback​

The Edge component is the go-to for initiating video playback. It crafts unique playback sessions for each viewer request, retrievable through authenticated sessions. This design ensures that playback can be dynamically controlled and revoked as needed.

We employ LL-HLS with custom enhancements for low latency, alongside a spec-compliant mode for broader compatibility, achieving approximately 500ms latency from real-time.

Player: The Interface for Engagement​

Our video player is a testament to innovation, built from scratch in Rust and compiled to WebAssembly for high performance. Its ease of integration is a standout feature, facilitating the seamless addition of our player into various web services.

API: Orchestrating Video Service Interactions​

The Scuffle API serves as the control hub for your live streaming needs, offering straightforward yet powerful features. Streamers can fine-tune their broadcasts in real-time by adjusting transcoding parameters for the best quality, managing recording options to capture their live sessions, and deciding on storage solutions between Scuffle's own servers or integration with AWS S3 buckets.

Room creation and management are made simple, with the ability to configure settings for different events or viewer requirements, ensuring secure access through robust streamer and viewer authentication mechanisms. The API also simplifies video content management, allowing for organized storage, retrieval, and deletion of video recordings, and configuration of playback options to suit various content delivery strategies.

Through the current API, Scuffle provides the essential tools required for a comprehensive and controlled streaming experience, with an eye on simplicity and functionality.

Looking Ahead: Expanding the Horizons of Live Streaming​

As we continue to innovate and enhance the Scuffle platform, there are exciting features on the horizon designed to amplify viewer engagement and provide detailed insights into streaming performance.

Insertable Data Packets: We are working towards enabling our customers to insert custom data packets into their live streams. This feature will empower broadcasters to send tailored content, such as user-specific messages or interactive elements, directly to viewers through the Player SDK.

Advanced Ad Systems: Tailoring ad experiences is on our roadmap. We aim to introduce sophisticated ad systems that cater to different regions and viewer demographics. This will allow for targeted advertising, enhancing the relevance of ads for viewers and increasing the value for advertisers.

Comprehensive Analytics: To equip our customers with a deeper understanding of their audience, we're developing an advanced analytics system. It will track viewer engagement metrics across various dimensions such as geographical regions and demographic data, providing actionable insights to shape future content and strategies.

These forward-looking features are designed with our commitment to providing a comprehensive and cutting-edge live streaming platform that not only meets the current demands but also anticipates the future needs of our users.

Libraries​

To achieve our vision, we have meticulously crafted several video libraries in Rust, encompassing codecs and protocols crucial for our operations:

• h264 - H264 header decoder
• h265 - H265 header decoder
• av1 - AV1 header decoder
• aac - AAC header decoder
• mp4 - MP4 muxer/demuxer
• flv - FLV demuxer
• rtmp - RTMP protocol implementation
• transmuxer - Transmuxing from FLV to MP4
• amf0 - AMF0 encoder/decoder
• exp_golomb - Exponential-Golomb encoder/decoder

These are set for integration into our main branch by year-end, marking our foray into the live streaming domain.

Contributing: Join the Scuffle Community​

We're immensely grateful for the ongoing support and invite contributions to Scuffle. Whether it's through our Discord community or GitHub repository, your expertise can help shape the future of live streaming with Scuffle.

The Benefits of IP Space Ownership​

Owning an IP space empowers you to have full control over your servers' communication with the public internet, giving you several advantages over conventionally assigned IPs from a typical cloud provider:

• Owning your own IP subnets means that you retain your IP addresses even when switching between cloud providers or ISPs. This can significantly ease transitions and migrations, as you don't need to reconfigure your IP addressing scheme each time you make a change.
• With your own Autonomous System Number (ASN), you have direct control over how your traffic is routed. This can lead to performance improvements and increased network reliability.
• Owning your own IP subnets allows you to use the same IP addresses in multiple locations globally. This can make it easier to manage and scale your network, and it's how services like Cloudflare and Google provide their widely-available DNS services.
• If your end-users need to whitelist specific IP ranges for firewall or security reasons, owning your own IP subnets can make this process easier.
• With your own ASN, you are visible on the global routing table. This can allow you to establish direct peering relationships with other networks, reducing your dependence on upstream ISPs and potentially improving your network's performance.
• Owning your own IP subnets means that you are responsible for the reputation of those IP addresses. By ensuring that you use your network responsibly and do not violate any rules, you can maintain a high-quality, trustworthy IP reputation.

The Road to IP Space Acquisition​

The journey starts with creating an account with a Regional Internet Registry (RIR), which, in our case, was the American Registry for Internet Numbers (ARIN). We needed to establish an ORG ID, apply for an Autonomous System Number (ASN), allocate IPv6 addresses, and acquire IPv4 addresses.

Setting up an ORG ID​

An ORG ID on ARIN essentially represents a company owning internet assets like IP ranges or AS numbers. You start without one, so it needs creating, which requires an array of documents validating your company registration status and ownership proof, plus a non-refundable processing fee of $50. Following approval (approximately 1-2 weeks), you can then apply for an ASN, Transfer Pre Approval, and IPv6 Allocation.

Understanding the ASN​

An Autonomous System Number (ASN) is a unique identifier assigned to a network operating under a single external routing policy on the internet. This identifier is essential for routing data across networks efficiently and for implementing multihoming, which allows you to advertise your IP space over multiple ISPs. Despite talks about "lower" AS numbers or 16bit vs 32bit ASNs, there is no practical difference.

The ASN application requires justification of your network setup requirements. Approval leads to an invoice of approximately $550.

Our ASN WHO.IS

The IPv6 Allocation​

Unlike IPv4, the pool of IPv6 addresses is vast enough that you don't need to purchase subnets from a third party. Instead, you can request them directly from your RIR, in our case ARIN. The smallest block of IPv6 addresses you can announce is a /48, but for our needs, we requested a /40 block from ARIN.

In terms of IPv6 allocation, you can either request as an end-user or as an ISP. From ARIN's perspective, an ISP is not only the company providing the last-mile connection to end users, but also any company that provides any service to its customers using IP space. This means that even Platform as a Service (PaaS) companies like ours fall into the category of ISP according to ARIN's guidelines.

The concept of a /48 or /40 block might seem abstract, so to give you a practical understanding, let's consider an example: a /48 block provides enough space to create up to 65,536 networks (or subnets). This could be used to organize a vast number of devices within a single data center. With a /40 block like we requested, we can create up to 256 of these /48 networks, each potentially corresponding to different datacenters or subdivisions within our organization. This gives us significant flexibility for growth and organization of our services.

As with the ASN, you will need to justify why you need the size block you request by explaining how you plan to implement your network setup. Once ARIN approves your request, you will be asked to pay a fee. For us, this fee was $250.

Our IPv4 Range WHO.IS

The Path to IPv4 Addresses​

Acquiring IPv4 addresses is trickier due to ARIN's IPv4 address pool depletion. Either apply to be on the IPv4 waitlist or request pre-approval for purchase from a third party at a premium. We opted for the latter due to the waitlist's length and the constant demand for IPs.

Navigating Transfer Pre-Approval​

A transfer pre-approval facilitates either ASN or IPv4 transfers. For IPv4 addresses, you need to choose a subnet size to apply for. On the public internet, the smallest announceable block is a /24, which equates to 256 IPs. This minimum size means even if you want a single server in two datacenters with unique IPs, you need two /24 blocks. We requested a /22, giving us four /24 blocks and room for expansion.

Purchasing IPv4 Addresses​

Though there are limited brokers for IPv4 addresses, our experience with ipv4.global was excellent - friendly, efficient, and smooth. Following payment, the IP addresses were allocated within a week with an updated WHO.IS. The cost per IP to the broker was $35/IP in our case. There was also an additional cost for transfer fee to ARIN of $375.

Our IPv6 Range WHO.IS

Timeline​

Our journey through IP space acquisition started on the 4th of July with the application for an ORG ID, followed by a request for an ASN, an IPv6 /40 block, and culminating with the purchase of a /22 IPv4 block. The entire process, from start to finish, spanned a month and cost $37,065 in total.

This complex yet rewarding process not only gave us control over our own corner of the internet but also a deep understanding of the world of internet numbers. While intricate, the benefits of having your own IP space, especially if you're planning for substantial growth, are considerable. We are now better prepared for our future networking endeavors and ready to cater to our users' needs more effectively.