Live Streaming APIs in 2026: 8 Platforms Developers Can Actually Build On

  • Most live streaming APIs differ not in feature lists but in where they impose latency: at ingest, at the packager, or at the CDN edge. Pick the wrong one and you pay for it in viewer drop-off, not in your bill.
  • RTMP is universal but SRT ingest separates platforms serious about unreliable network conditions; only a handful expose both with documented failover behavior.
  • Pricing at 100 concurrent viewers is nearly irrelevant. The model that looks cheap at 1,000 can cost three to five times more than a competitor at 10,000 without a negotiated contract.
  • Observability is where most platforms quietly fail: webhooks and per-viewer QoE analytics are not the same thing, and you will not know the difference until you are debugging a viewer complaint at 2 a.m.
  • Six platforms are covered in depth; two credible vendors are intentionally held out to reflect the current state of the market and will be added as their documentation and pricing transparency mature.

The best live streaming API for most developer teams building a SaaS product is Mux Live, because its low-latency HLS, mature webhook system, and per-minute billing model are well-documented and predictable at scale. For sub-one-second latency requirements, Cloudflare Stream or api.video are competitive alternatives. Google Cloud Live Stream API and AWS IVS serve teams already committed to those cloud stacks. RTMP and SRT ingest support, DVR window length, player SDK quality, and regional PoP coverage are the architectural variables that actually separate these platforms once you move past 1,000 concurrent viewers.


Why Most Developers Pick the Wrong Live Streaming API

The default assumption is that a live streaming API is just RTMP in and HLS out, and that any platform wrapping those protocols is interchangeable. That assumption costs engineering teams months of rework. The real divergence is in the latency model, the packager architecture, and where the platform puts the processing burden.

Glass-to-glass latency, the time from a camera frame being captured to that frame rendering in a viewer’s browser, depends on four compounding delays: encoder buffer, ingest leg, packager segment length, and CDN propagation. A platform can advertise “low latency” and mean anywhere from 1.5 seconds to 45 seconds depending on which of those four stages they optimized. You need to know which.

The other underappreciated variable is pricing structure. Bandwidth-based billing at 100 concurrent viewers is trivial for any platform. At 10,000 concurrent viewers watching a 4,000 kbps stream for two hours, the difference between platforms that charge per GB delivered and platforms that charge per streaming-minute can be $800 to $4,000 for the same event. That is an architectural decision, not a line item.


What Technical Criteria Actually Separate Live Streaming APIs?

Before the comparison, here is the evaluation framework used across all eight platforms reviewed. Found On AI calls this the Live Stack Audit, seven criteria that expose real architectural differences rather than marketing claims.

  1. Ingest protocols: RTMP, SRT, WebRTC, WHIP. Which are documented with failover behavior.
  2. Glass-to-glass latency: measured as low-latency HLS (LL-HLS), WebRTC playback, or standard HLS, with documented segment sizes.
  3. Packager and ABR output: adaptive bitrate ladder, codec support (H.264, H.265, AV1), and whether the ladder is configurable.
  4. DVR and recording: DVR window length, VOD recording trigger, storage location, and latency penalty from enabling DVR.
  5. Player SDK and playback stack: native iOS/Android SDKs, web player quality, HLS.js compatibility, and CMAF chunked transfer support.
  6. Webhooks and observability: event granularity (stream.started vs. per-viewer QoE), latency of webhook delivery, and whether viewer-level analytics are exposed via API.
  7. Pricing at scale: per-minute vs. per-GB vs. per-concurrent-viewer billing at 100, 1,000, and 10,000 concurrent viewers.

Every platform below is evaluated against all seven criteria. If a platform does not publicly document a criterion, that gap is noted explicitly.

PlatformMin Latency ModeRTMP IngestSRT IngestWebRTC/WHIP IngestDVR WindowPlayer SDKPricing Model
Mux LiveLL-HLS (~3-4s)YesYesWHIP (beta)Up to 12hMux Player (web, iOS, Android)Per-minute encoded + delivery
Cloudflare StreamLL-HLS / WebRTC (~1s)YesNo (as of public docs)WebRTC via WHIPLimitedEmbedded player; HLS.js compatiblePer-minute stored + per-minute viewed
api.videoLL-HLS (~3-5s)YesNoNoNot nativeWeb, iOS, Android SDKsPer-minute encoded + storage + delivery
AWS IVSUltra-low (~2-3s)Yes (RTMPS)NoNoUp to 4h (Timed Metadata)Player SDK (web, iOS, Android)Per-hour channel + data transfer
Google Cloud Live Stream APIStandard HLS (~30-45s)YesYesNoVia DVR eventsNo native player; bring your ownPer-channel-hour + per-GB output
Wowza VideoLL-HLS / WebRTC (~2-4s)YesYesWebRTCYes (configurable)Web player; SDKs availableMonthly plan or usage-based
Dolby.io Streaming (Millicast)WebRTC (~sub-500ms)YesYesWebRTC nativeLimitedWeb SDK; no native mobile SDKPer-viewer-minute
ImageKit Live (held out)Not publicly documentedUnknownUnknownUnknownUnknownUnknownNot publicly documented

Mux Live: Best for SaaS Products That Need Predictable Billing and Mature Developer Tooling

Mux Live is the reference implementation for API-first live streaming. Its documentation is detailed enough that an engineer can go from zero to a working RTMP ingest endpoint with webhook callbacks in under an hour. The per-minute billing model, encoding minutes plus delivery minutes billed separately, is the most predictable at scale of any platform in this comparison.

Mux’s low-latency HLS delivers 3 to 4 seconds glass-to-glass in optimal conditions. That is not sub-second, but it is consistently achievable without custom CDN configuration. SRT ingest is supported and documented, which matters for production environments where the encoder-to-ingest leg crosses unreliable public internet. The WHIP ingest endpoint is in beta and functional, pointing toward browser-origin streaming without a separate encoder.

Where Mux genuinely differentiates is observability. Its Data product exposes per-viewer QoE metrics, rebuffering rate, startup time, and video quality score via API, not just a dashboard. For a SaaS team building a live video product, that means you can surface stream health inside your own application without screen-scraping a third-party analytics UI. The webhook event model is granular: video.live_stream.active, video.live_stream.idle, video.live_stream.disconnected fire reliably and quickly enough to drive real-time UI state. If you are comparing Mux and Cloudflare Stream in depth, the Mux vs Cloudflare Stream comparison covers the trade-offs at the infrastructure level.

Best for: SaaS teams embedding live video as a product feature who need predictable costs, documented APIs for the full lifecycle (create, ingest, record, deliver, archive), and viewer-level analytics without building a separate data pipeline.


Cloudflare Stream: Best for WebRTC Playback Under One Second at Low Marginal Cost

cloudflare

Cloudflare Stream’s live product has a specific superpower: it supports WebRTC playback via WHIP/WHEP, which means sub-one-second glass-to-glass latency without running your own media server. That is a genuinely hard technical achievement at CDN scale. For use cases like live auctions, sports betting interfaces, or any product where viewer latency above two seconds causes a UX problem, Cloudflare Stream is the only platform in this list that solves the problem without SFU infrastructure.

The pricing model is per-minute stored and per-minute viewed, which is simple but can surprise teams at high viewer counts. A two-hour event with 5,000 concurrent viewers generates 600,000 viewer-minutes. At Cloudflare’s public pricing, that is a calculable number from their pricing page rather than a usage-tier negotiation. The tradeoff is that SRT ingest is not documented in their public API reference, so teams with professional broadcast encoders (Haivision, Teradek) that output SRT natively will need to transcode to RTMP first.

The player is an embedded iframe with HLS.js compatibility, not a programmable SDK in the same class as Mux Player or IVS. Custom player UI requires wrapping the HLS manifest yourself. For products that need branded, fully controlled playback UI, that gap adds engineering time.

Best for: Teams that need sub-one-second WebRTC playback at scale, are already on Cloudflare’s network for DNS or security, and can accept RTMP as the only production ingest path.


api.video: Best for Teams That Want the Fastest Path from Ingest to Embeddable Player

api.video

api.video positions itself as the developer-friendly layer that handles both live and VOD under a single API surface. Its live streaming implementation covers RTMP ingest, LL-HLS output, and embeddable player SDKs for web, iOS, and Android without requiring you to assemble those pieces from separate services. For teams without a dedicated video infrastructure engineer, that integration shortcut is worth real engineering time.

The latency is LL-HLS in the 3 to 5 second range. That puts it in the same tier as Mux, not faster. DVR is not a native feature in the documented API, so if your use case requires viewers to rewind a live stream, you are building that yourself on top of recorded VOD assets. The webhook model is functional but less granular than Mux’s, covering stream lifecycle events without per-viewer QoE signals.

Pricing is per-minute encoded, per-GB stored, and per-GB delivered, with a free tier that includes meaningful live streaming minutes for development. At 10,000 concurrent viewers, delivery costs will dominate and you will want to model those numbers carefully from the public pricing page before committing. If you are evaluating api.video for a broader video infrastructure decision beyond live streaming, the best video API platforms for developers comparison covers the VOD capabilities alongside live.

Best for: Small-to-mid engineering teams building their first live video feature who want a single API for live ingest, playback, and recording without stitching together separate services.


AWS IVS: Best for Teams Building Interactive Live Experiences Inside the AWS Ecosystem

AWS IVS

Amazon Interactive Video Service is the only platform in this list built natively for interactive live content: Timed Metadata lets you inject synchronized data events into the stream that fire in the player at precisely the right video frame. That capability is hard to replicate on other platforms and makes IVS the default choice for live shopping, trivia, polling overlays, and any experience where viewer interaction must be frame-accurate.

Latency is documented as ultra-low, typically 2 to 3 seconds in published AWS content, achieved via a custom protocol over RTMPS ingest and a proprietary playback SDK. The catch is that the low-latency mode requires the IVS Player SDK, not generic HLS.js. If you have an existing player stack you cannot replace, IVS’s latency advantage disappears because standard HLS output carries the familiar 20 to 30 second delay.

Pricing is per-channel-hour for the live encoding plus per-GB data transfer out, charged at standard AWS CloudFront rates for delivery. At 10,000 concurrent viewers, CloudFront egress costs add up faster than the encoding costs. Teams already paying for AWS Reserved capacity or Enterprise Support have a natural negotiation lever here that standalone developers do not.

Best for: AWS-native product teams building interactive live experiences (live commerce, game shows, synchronized polling) where Timed Metadata and frame-accurate interactivity justify the SDK lock-in.


Google Cloud Live Stream API: Best for Broadcast-Grade Encoding with Full GCP Control

google cloud

Google Cloud Live Stream API is a different product category than the others on this list. It is a transcoding engine, not a turnkey live video platform. You define input endpoints, output manifests, and channel configurations via API; Google handles the encoding. Distribution, player, and storage are separate GCP services you wire together. That gives infrastructure engineers complete control and gives product engineers a significant amount of additional work.

The platform supports both RTMP and SRT ingest, which is one of the few documented SRT implementations in a hyperscale cloud. Codec support includes H.264 and H.265. DVR is implemented via event clips rather than a continuous rolling window, which requires careful event management in your application layer. Glass-to-glass latency in standard configuration is 30 to 45 seconds, appropriate for broadcast distribution but not for interactive live products.

Pricing is per-channel-hour for encoding plus per-GB for output delivered via Cloud CDN. The billing is clean and predictable for teams already modeling GCP spend. Teams not already on GCP should weigh the operational overhead of managing a multi-service architecture against the turnkey options above.

Best for: Engineering teams at media companies or broadcasters already on GCP who need broadcast-grade encoding control, SRT ingest from professional encoders, and are comfortable assembling their own delivery and player stack.


Wowza Video: Best for Teams That Need SRT, WebRTC, and RTMP Under One Contract

Wowza The 20 Best Private Video Hosting Services for 2026 Ranked and

Wowza Video is the oldest infrastructure vendor in this comparison, and that history shows in the ingest protocol support. RTMP, SRT, and WebRTC ingest are all documented and production-tested. For broadcast workflows where the encoder (hardware or software) speaks SRT natively, Wowza does not require a protocol translation step that could add latency or failure points.

Output includes LL-HLS and WebRTC playback paths, with configurable DVR windows. The player SDK covers web and has iOS/Android libraries. Webhook support exists but is less granular than Mux’s event model. Observability at the per-viewer level requires Wowza’s analytics add-on rather than being native to the core API.

Pricing is available as monthly plans with defined stream hours and viewer hours, or as usage-based billing. The monthly plan model is easier to budget for teams with predictable live event schedules; the usage model suits infrequent large events. At 10,000 concurrent viewers, enterprise plan pricing applies and requires a sales conversation. That opacity is a genuine evaluation friction compared to platforms with fully public pricing calculators.

Best for: Teams with broadcast-grade hardware encoders outputting SRT or WebRTC, who need a single vendor managing ingest, transcoding, and delivery without assembling a multi-cloud architecture.


Dolby.io Streaming (Millicast): Best for Sub-500ms Latency at Broadcast Scale

dolby

Dolby.io Streaming, built on the Millicast WebRTC infrastructure, is the only platform in this comparison that delivers sub-500-millisecond glass-to-glass latency to tens of thousands of concurrent viewers simultaneously via WebRTC fan-out. Every other platform either achieves sub-second via WebRTC for small audiences (video conferencing scale) or achieves large-scale delivery via HLS with seconds of inherent latency. Millicast is the exception because it runs a purpose-built WebRTC SFU network designed for broadcast fan-out, not just peer connectivity.

SRT and RTMP ingest are both supported and documented. The web SDK is mature. The limitation is on the mobile side: native iOS and Android SDKs are not as comprehensive as Mux or IVS, which means mobile playback typically goes through a WebRTC view embedded in a WebView rather than a native player component. That carries performance implications on lower-end Android devices.

Pricing is per-viewer-minute, which is simple to model but expensive at very high concurrent viewer counts for long events. A six-hour event with 10,000 concurrent viewers generates 3.6 million viewer-minutes. Teams should model this explicitly from the public pricing page. For sports, live auctions, or real-time financial data overlays where latency below one second is a product requirement rather than a preference, the cost premium over HLS-based platforms is often justified.

Best for: Products where viewer latency above 500 milliseconds creates a real user experience problem: live sports betting, real-time auctions, synchronized multi-viewer game experiences, or any application where “live” means the viewer and broadcaster are operating in the same moment.


How Much Does a Live Streaming API Cost at 100, 1,000, and 10,000 Concurrent Viewers?

The following is an illustrative scenario, not vendor-provided data. Assume a single 1080p stream at roughly 4,000 kbps total ABR output, two hours of live duration, with the listed concurrent viewer count watching the full duration. Storage and VOD recording costs are excluded. All figures are approximations derived from publicly listed rates; actual costs depend on region, plan tier, and negotiated discounts.

Platform~100 Concurrent Viewers (2h event)~1,000 Concurrent Viewers (2h event)~10,000 Concurrent Viewers (2h event)Billing Unit
Mux Live$10-20$80-150$800-1,500Per-min encoded + per-GB delivery
Cloudflare Stream$5-15$50-120$500-1,200Per-min viewed
api.video$10-25$90-200$900-2,000Per-min encoded + per-GB delivery
AWS IVS + CloudFront$15-30$100-250$1,000-3,000Per-channel-hour + per-GB egress
Google Cloud Live Stream API$20-40$150-350$1,200-4,000Per-channel-hour + per-GB output
Wowza VideoPlan-basedPlan-basedEnterprise pricingMonthly plan or usage
Dolby.io Millicast$10-20$100-200$1,000-2,000+Per-viewer-minute

The takeaway from this model is not a specific dollar figure per platform. The takeaway is that per-GB delivery billing compounds with viewer count and bitrate in a way that per-minute-viewed billing does not. At 10,000 concurrent viewers, a platform charging per-GB for a high-bitrate ABR stream can cost twice what a per-viewer-minute platform charges for the same event. Run your own numbers using each platform’s public pricing calculator before architecture decisions are made.


What Does a Production Live Streaming Architecture Actually Look Like?

Consider a mid-size sports media SaaS product: a broadcaster runs OBS or a hardware encoder (Teradek Bolt or similar) outputting RTMP to a primary ingest endpoint, with a secondary ingest URL configured for automatic failover. The streaming API (Mux or Wowza in this scenario) receives both streams and promotes the secondary automatically on primary failure, firing a webhook that updates the application database state and triggers a status banner in the viewer UI.

The packager generates a 4-rendition ABR ladder: 1080p at 4,500 kbps, 720p at 2,500 kbps, 480p at 1,000 kbps, and 360p at 500 kbps, all delivered over LL-HLS with 2-second segment targets and 200-millisecond partial segments. The viewer player (Mux Player or HLS.js with a custom skin) starts on the highest rendition the viewer’s bandwidth supports and switches down within one segment interval. DVR is enabled with a 4-hour rolling window; the recording API is called post-stream to create a VOD asset from the same ingest without re-uploading.

Webhooks from the streaming API POST to an application endpoint within 1 to 2 seconds of stream state changes. The application maps those events to viewer-facing UI states: a pre-stream poster, a live badge, a “stream interrupted” overlay, and a VOD transition when the stream ends. Per-viewer QoE data, if the platform exposes it, feeds a monitoring dashboard via the analytics API. A CDN-level DRM layer (Widevine, FairPlay) wraps the HLS manifests for premium content protection. For a deeper look at DRM integration in video delivery, the best video DRM software platforms comparison explains the trade-offs between DRM implementations.


Which Live Streaming APIs Support RTMP and SRT Ingest?

RTMP is the baseline. Every platform reviewed here supports it. SRT is where platforms diverge, and the difference matters in three specific situations: encoding from a hardware device on a congested network, sending a contribution feed across a long-haul internet path, or integrating with professional broadcast infrastructure that has standardized on SRT.

Among the six platforms covered in depth, Mux, Google Cloud Live Stream API, Wowza, and Dolby.io Millicast document SRT ingest. Cloudflare Stream and api.video do not, based on their public documentation. If your encoder outputs SRT natively and packet loss on the ingest leg is a real concern for your deployment environment, that narrows the field to four.

WHIP (WebRTC HTTP Ingest Protocol) ingest is emerging as the standard for browser-origin streaming without OBS. Mux has it in beta; Cloudflare and Dolby.io support it in production. For a SaaS product where end users stream directly from their browser rather than a dedicated encoder, WHIP ingest combined with WebRTC or LL-HLS playback is the architecture to evaluate.


Two Platforms Held Out: What to Watch

Two vendors with credible live video infrastructure are not included in the rated comparison above. Their documentation, pricing transparency, or live-specific feature maturity did not meet the threshold for a fair architectural comparison at the time of this writing.

Gcore Streaming has a distributed CDN with live streaming capabilities and SRT ingest documentation, but its developer API surface for live specifically, webhooks, analytics, player SDK, is not documented to the same depth as the platforms above. It is a legitimate outreach target for a future update, particularly for teams with European latency requirements.

Phenix Real Time Solutions targets sub-250-millisecond WebRTC broadcast delivery for enterprise clients, primarily in sports and live events. Pricing is entirely enterprise and not publicly disclosed, and the API documentation requires a sales-gated access request. When those constraints change, the platform warrants a direct comparison against Dolby.io Millicast for the real-time use case.


Frequently Asked Questions

What is the difference between a live streaming API and a live streaming SDK?

A live streaming API is the server-side interface: REST or WebSocket endpoints for creating streams, managing ingest endpoints, triggering recordings, and consuming webhooks. A live streaming SDK is the client-side library that wraps player initialization, adaptive bitrate switching, and QoE event collection in your application code. Most production platforms offer both. You need the API to manage stream lifecycle and the SDK to control playback in the viewer’s browser or mobile app. Some platforms, like api.video and Mux, bundle both under a single product; others, like Google Cloud Live Stream API, provide only the server-side component and expect you to bring your own player.

Which live streaming API has the lowest glass-to-glass latency?

Dolby.io Streaming (Millicast) achieves sub-500-millisecond glass-to-glass latency via WebRTC fan-out at scale. Cloudflare Stream also achieves sub-one-second via WebRTC/WHEP playback. Mux and AWS IVS target 2 to 4 seconds with low-latency HLS. Standard HLS configurations on any platform carry 20 to 45 seconds of inherent latency due to segment buffering. The right latency target depends on the use case: sub-500ms for live auctions and sports betting, 2 to 4 seconds for most interactive live products, and 10 to 30 seconds is acceptable for linear broadcast distribution.

How much does a live streaming API cost at 10,000 concurrent viewers?

For a two-hour event at 1080p with 10,000 concurrent viewers, expect roughly $500 to $4,000 depending on platform and billing model, based on illustrative estimates from public pricing rates. Per-GB delivery billing compounds at high viewer counts and high bitrates, while per-viewer-minute billing scales linearly. Platforms like Cloudflare Stream and Mux tend to be more predictable at this scale than cloud-native options like AWS IVS with CloudFront egress. At 10,000 concurrent viewers, contact the vendor for volume pricing regardless of which platform you are evaluating.

Can I use a live streaming API to build a SaaS product with multi-tenant streams?

Yes, and Mux, api.video, and Cloudflare Stream are all designed for this model. Each allows you to create per-user or per-organization stream keys programmatically, manage multiple simultaneous live streams, and receive per-stream webhooks. The critical architectural question is whether the platform exposes viewer-level analytics per stream via API, so you can surface stream health inside each tenant’s dashboard without building a separate data ingestion layer. Mux Data and AWS IVS both expose viewer QoE metrics via API. api.video’s analytics are primarily dashboard-based.

What is the difference between RTMP, SRT, and WHIP ingest protocols?

RTMP (Real-Time Messaging Protocol) is the universal standard supported by every encoder and every platform. It works well on stable internet but degrades predictably on congested or lossy networks. SRT (Secure Reliable Transport) is purpose-built for unreliable network conditions: it adds ARQ (automatic repeat request) retransmission, encryption, and bonding support at the protocol level. WHIP (WebRTC HTTP Ingest Protocol) enables browser-origin streaming using WebRTC, eliminating the need for a separate encoder application. For production broadcast contribution feeds on uncertain network paths, SRT is the right choice. For user-generated live content from browsers, WHIP is the emerging standard.

Do live streaming APIs handle adaptive bitrate output automatically?

Most platforms in this comparison generate an ABR ladder automatically from a single ingest stream. The default ladder typically includes renditions at 1080p, 720p, 480p, and 360p. Mux, Wowza, and Google Cloud Live Stream API allow you to configure the rendition ladder explicitly via API parameters. AWS IVS generates a fixed ladder based on channel type. Cloudflare Stream and api.video use automatic ladders with less configurability. If your product has specific bitrate or resolution requirements, for example, a low-bandwidth mode for mobile viewers on metered data plans, verify that the platform exposes ABR ladder configuration before committing.

Which live streaming API is best for a startup building its first live video feature?

api.video or Mux Live. api.video has the faster initial integration path, a meaningful free tier for development, and a single API surface covering ingest, playback, and recording. Mux Live takes slightly more setup but provides materially better observability via Mux Data and a more granular webhook model, which matters as the product matures and you need to debug viewer complaints. Both are developer-documented well enough that a single engineer can ship a working live feature in a few days. Avoid Google Cloud Live Stream API and AWS IVS for a first implementation unless you are already deeply embedded in those ecosystems.

How do live streaming APIs handle stream recording and VOD creation?

Recording behavior varies significantly. Mux Live creates a VOD asset automatically from the live stream when recording is enabled, stored in Mux’s infrastructure and accessible via the same asset API used for uploaded video. AWS IVS records to an S3 bucket you specify. Google Cloud Live Stream API outputs to Cloud Storage. api.video stores recordings in its own CDN. The key operational difference is whether recording is enabled at stream creation or can be toggled mid-stream, and whether the VOD asset is available immediately post-stream or requires a processing delay. For products where fast VOD replay after a live event matters, Mux’s automatic VOD creation and near-immediate availability is the strongest implementation.


How to Pick the Right Live Streaming API for Your Architecture

The decision is not which platform has the best feature list. It is which platform’s latency model, ingest protocol support, and billing structure match the specific constraints of your product. A SaaS team embedding live video for the first time has different requirements than a broadcast media company building a distribution layer, even if both use the phrase “live streaming API” in their evaluation search.

Start with latency. If sub-one-second latency is a product requirement, the field narrows to Dolby.io Millicast and Cloudflare Stream. If 2 to 4 seconds is acceptable and observability matters more, Mux is the strongest choice. If you are on AWS and need Timed Metadata for interactivity, IVS. If your encoder speaks SRT and you need broadcast-grade control, Wowza or Google Cloud.

Then model the cost at your expected peak concurrency, not your average. Live events have spikes. The platform that looks affordable at 200 average concurrent viewers may be the most expensive at 8,000 peak viewers during a 20-minute segment. Build that model before signing up for a plan, and check the full video API platform comparison if your requirements include significant on-demand video volume alongside live. The live streaming infrastructure decision and the VOD delivery decision are architecturally connected even when they feel separate in the evaluation process.

Bryan Falcon
Bryan Falcon