Push or pull
Each stream is created as push or pull and keeps that type. Push: your encoder (OBS, vMix, Larix, hardware) sends RTMP to the server URL with a dedicated key; recommended H.264, AAC, 2-second keyframes, 30 fps. Pull: give a source address and whycloud reads it: rtmp(s)://, rtsp:// (IP cameras), srt://, an HLS playlist (m3u8) or an MP4 file (looped). H.264/AAC pass through; other codecs are converted. A dropped source is reconnected automatically. Only the source address of a pull stream can be edited. On whycloud servers, addresses that resolve to private networks are rejected.
Input quality and renditions
The input resolution is detected from what arrives and shown in the studio. The source rendition is always passed through without re-encoding; lower renditions (720p, 480p, 360p) are produced in multi-bitrate mode and never above the input. If the input resolution changes, the ladder is realigned the next time the stream is idle. Each extra rendition is billed as rendition-hours.
Player, embeds and themes
Every stream has a video player, an audio player and an HLS URL. Embed the iframe in your site. Query parameters: ?theme= (onyx, aurora, ember, velvet, jade, gold, ocean, pearl; default whycloud), ?muted=0|1, ?audio=1, ?title=. Set the default theme and start-with-sound under Settings → Player; it applies to all existing links and embeds. When browsers block autoplay with sound, the player starts muted and unmutes on the first tap or click. On phones a tap on the picture shows the controls and never pauses.
When the source stops
If the encoder or source stops sending, the player blurs the last picture and shows a "source disconnected" notice; already shown segments are never replayed. Playback resumes at the live edge as soon as new segments arrive. After 90 seconds without a source the player shows "stream ended" and starts again automatically when the stream returns.
Custom player domain
Streams on whycloud servers are served over HTTPS on the whycloud player domain behind the whycloud CDN. To use your own domain (behind your CDN or any CDN), point it over HTTP to the origin shown under Settings → Custom player domain. Pointing at the server root is fine: the /s/<id>/ path is detected automatically. whycloud reads player.json from your domain and accepts it only if it belongs to the stream; links and embeds then use your domain.
Your server or whycloud servers; pricing
On your own Docker host or Kubernetes cluster processing and traffic use your resources and only service management is billed. On whycloud servers whycloud resources are used as well. Metered items: live hours, rendition-hours, viewer-hours, GB delivered to viewers (whycloud servers), pull hours, restream destination-hours and GB-hours of recordings stored on whycloud servers. Prices are shown separately for your servers and for whycloud.
Audience reports
Reports show the share of watch minutes by country, ISP, device, operating system and browser. Viewer addresses do not leave the streaming server; only the /24 (IPv6 /48) network is used for location. The location database is refreshed daily. Behind a CDN the viewer address is read from WhyCloud-Connecting-IP or X-Forwarded-For.
Restreaming and recording
Up to four RTMP/RTMPS destinations receive the stream simultaneously; each is independent and changes apply without interrupting the stream. Recording is manual or automatic, files are kept for 24 hours and can be trimmed or exported to your S3.
Engine and player updates
New engine and player releases are first tested on one stream, then rolled out gradually. Live streams are never interrupted: they are updated hours later. A stream that is not healthy after an update returns to its previous release automatically.
Deliver through WhyCloud from your own server
For a stream on your own server or cluster, turn on “Deliver through WhyCloud” in the studio. The renditions your server already produces are copied (no re-encode) to a WhyCloud streaming server, where they are only packaged into HLS; no transcoding happens at WhyCloud, and the edges and CDN handle delivery and traffic. Your server sends one copy of each rendition however many people watch. The card shows the video player, audio player, HLS and embed code, and the sending state of every rendition.
Your domain on WhyCloud delivery
Enter a domain or subdomain (for example live.example.com) on the delivery card. On WhyCloud DNS the records are created automatically; otherwise a TXT ownership record and a CNAME to the CDN target are shown (ALIAS/ANAME for an apex). Click Check after adding them; a certificate is issued automatically and the player opens at the root of your domain (https://live.example.com/).
When the streaming server gets ready
A few seconds after it starts, the engine on your server or pod reports its own status straight to WhyCloud over HTTPS, so the address and key appear immediately. The report covers only that stream and is signed with a per-stream token. Without internet access the status still arrives through the agent, a little later. If “being prepared” takes long, open the operation and check the agent and Docker (or the pods in whycloud-streaming) under Infrastructure.