Direct Play
A compatible device receives the original file. The video is not re-encoded. Byte-range requests let the player fetch the needed portion and seek without first downloading the whole movie.
The details behind your playback
The right stream.
Only the work it needs.
Beebo checks your file, your player and your choices. It prefers the original when it can, repackages when that is enough, and converts short pieces as you watch when a different format is needed.
Technical information reviewed . Source implementation, local checks and device validation are identified separately.
Three ways to reach the same player
Direct Stream / remux
When the picture works but the container does not, compatible video can be copied into a streaming container. Audio may be copied or converted independently. Repackaging the picture preserves its encoded bitstream.
On-demand transcoding
The computer encodes a compatible stream when the player, selected quality or subtitle choice requires it. This uses processing power and can change picture or sound quality. The library original stays unchanged.
JIT means just in time. Beebo generates conversion pieces near the position being watched. It does not have to convert the whole movie before playback. This is a practical resource-management design, not proof that Beebo is always faster than another product.
What Beebo checks before choosing a route
| Input | What it changes |
|---|---|
| File and tracks | Container, video and audio codecs, picture dimensions, duration, bitrate, HDR metadata, available soundtracks and subtitles. |
| Receiving player | The device’s declared decoding, container, resolution, HDR and audio capabilities. A capability declaration still needs real playback validation. |
| Viewer choices | Original or a smaller quality profile; selected audio track; text or image subtitles; audio processing. |
| Owner controls | Whether conversion/remux and passthrough are allowed, optional codecs, concurrent conversion limits and connection constraints. |
The lowest-work compatible route is preferred. Asking for a lower resolution or burned-in subtitles can require full conversion even when the original picture would otherwise play.
Picture sizes, bitrates and data use
| Profile | Maximum picture | Target video bitrate | Default stereo audio | Approximate data per hour |
|---|---|---|---|---|
| 1080p | 1920 × 1080 | 8,000 Kbps | 192 Kbps | 3.69 GB |
| 720p | 1280 × 720 | 4,000 Kbps | 160 Kbps | 1.87 GB |
| 480p | 854 × 480 | 1,500 Kbps | 128 Kbps | 0.73 GB |
Picture sizes are bounding boxes: aspect ratio is preserved and smaller sources are not enlarged. Bitrates are configured targets, not measured speed guarantees. Hourly estimates combine the listed video and stereo audio targets using decimal GB, before protocol overhead, retries or bitrate variation. Original playback uses the original file’s bitrate instead.
$ Included for local playback
The conversion controls described here do not require a separate Beebo transcoding upgrade for use on your own computer at home. Hardware, electricity and your connection remain yours. Optional Beebo-managed connectivity is a separate service: check the current service offer and limits. A paid connection cannot make an incompatible player or overloaded computer support a format.
Four different meanings of “4K support”
| Operation | Reviewed implementation | What to expect |
|---|---|---|
| 4K original playback | Built; player/network validation required. | The original 2160p file can retain its original picture when the receiving player supports the file and the connection can sustain its bitrate. |
| 4K repackaging | Built for compatible video streams; player validation required. | Compatible video can be copied into an HLS container without reducing its resolution. First-play preparation can take time. |
| 4K input → 1080p / 720p / 480p | Built conversion route; exact codec/hardware combination needs validation. | A high-resolution source can be converted to the selected lower-resolution output. |
| New 2160p live output | × Not in the current live profiles | The reviewed live quality ladder ends at 1080p. This distinct capability cannot be described as complete and only awaiting a tester. |
How the on-demand engine manages work
Segments, seeking and temporary storage
- H.264 conversion uses HLS with 4-second MPEG-TS segments. Optional AV1 uses fragmented MP4 segments and an initialization segment.
- The playlist represents the full video timeline. A seek far from current work restarts preparation near the requested time.
- Default conversion pacing stops work when more than 45 segments ahead, resumes within 15, and retains 6 behind: roughly 180 seconds ahead and 24 seconds behind at 4 seconds per segment.
- An idle conversion session is removed after about 3 minutes by default. These are session defaults, not a fixed disk-byte allowance or a guarantee that a whole movie is cached.
- Remuxing uses a different path: approximately 6-second pieces aligned to source keyframes. A first keyframe scan may delay start; preparation can be retried instead of promising an instant first frame.
CPU, GPU, queueing and recovery
- Beebo performs a short test encode to discover working encoders, rather than assuming an encoder listed by FFmpeg means a working graphics card is present.
- H.264 candidates include NVENC, QSV, AMF, VideoToolbox and platform-specific VAAPI, with software fallback where available. The inspected Windows bundle includes OpenH264; it does not include libx264 or libx265.
- Protective conversion defaults are 1 job on a low-capacity profile, 2 on a normal profile, or 3 on a high-capacity profile, with one additional slot when hardware encoding is active. Owner overrides and actual workload matter.
- Busy conversion requests use a retry queue. Encoder failures can move the session to another supported encoder or processing method. If every route fails, playback may still fail.
- The base stalled-encoder wait is 10 seconds while a viewer is waiting, adjusted for large input dimensions and low-capacity profiles. It is not a promised startup time.
Optional AV1 and preparation ahead of watching
AV1 output is implemented as an additional opt-in path. Normal negotiation requires owner permission and a player that declares AV1 decoding. It is disabled by default. Compatible hardware or a working software encoder is required, and H.264 is the fallback if no AV1 encoder is usable.
Playing an existing AV1 original is a separate capability from making a new AV1 stream. Current converted output is SDR; a newer codec does not guarantee lossless quality or preserved HDR.
The owner can select an item for background stream preparation. This is a session-cache pilot, not a permanent optimized library or an automatic whole-library overnight scheduler.
What stays the same, and what can change
| Capability | Condition |
|---|---|
| H.264 / HEVC / AV1 originals | Original playback depends on the container and the receiving decoder. Recognizing a codec is not proof that every device decodes it. |
| H.264 / HEVC remux | Compatible video can be copied into fragmented MP4 HLS. Audio may need independent conversion. |
| H.264 conversion | Default live output route, with the three quality profiles above. |
| AV1 conversion | Optional, default-off route; requires suitable host and client. Uses fragmented MP4 HLS. |
| HEVC conversion output | No HEVC live output ladder is advertised here. HEVC input or remux support is a separate fact. |
| HDR | Compatible original/copy routes may retain source HDR. Full conversion currently produces 8-bit SDR. Tone mapping depends on the selected build and available processing filters. |
| Surround and subtitles | Original passthrough, up-to-5.1 audio conversion, subtitle rendering and subtitle burn-in have different conditions. See the home-theater breakdown. |
Technology versions you can compare
This is the September 23, 2026 implementation snapshot. It distinguishes source declarations, resolved dependencies and an observed development runtime. It is not a claim that every downloadable installer contains every later source change. Published download versions and dates appear separately below.
Desktop runtime, playback and packaging
| Component | Version | Evidence type |
|---|---|---|
| Beebo desktop source | 0.1.59 | Application package declaration. |
| Electron | 44.4.3 | Resolved dependency and locally observed development runtime. |
| Chromium | 152.0.7977.130 | Embedded browser observed in that local runtime. |
| Node.js / V8 | 24.21.0 / 15.2.124.28-electron.0 | Embedded engine versions observed locally. |
| React / React DOM | 18.3.1 / 18.3.1 | Desktop dependency lockfile. |
| hls.js browser player | 1.5.20 | Vendored playback library. |
| Vite / esbuild | 8.3.0 / 0.28.2 | Build tools; these versions are not picture-quality specifications. |
| electron-builder | 26.15.3 | Packaging tool. |
| Windows FFmpeg | N-126390-g9fc8c785e2-20260903 | Observed local bundled binary. Actual release package verification is separate. |
| FFmpeg libraries | libavcodec 63.9.100; libavformat 63.6.100; libavfilter 12.4.100; libavutil 61.6.100 | Reported by that Windows binary. |
| macOS FFmpeg recipe | FFmpeg 8.1.3; OpenH264 2.6.0; Opus 1.6.1; libaom 3.15.0; SVT-AV1 4.2.0 | Build-recipe pins, not a binary executed in this review. |
Phone application and playback stack
| Component | Version | Scope |
|---|---|---|
| Beebo Android source | 1.42 · build 43 | Application declaration; minimum SDK 24, compile/target SDK 36. |
| Kotlin / JVM target | 2.0.21 / 17 | Language/plugin and bytecode-target declarations. |
| Android Gradle Plugin / Gradle | 8.5.2 / 8.14.5 | Build-tool declarations. |
| Compose BOM | 2024.09.02 | Dependency-alignment version; not the version of every UI module. |
| Media3 | 1.4.1 | Declared playback, HLS, session and transformation modules. |
| OkHttp | 4.12.0 | Declared network client. |
| WebRTC SDK | 125.6422.07 | Declared real-time connection dependency. |
| Tink Android | 1.23.0 | Declared cryptographic library; features still depend on their implementation. |
| WorkManager / Coil | 2.9.1 / 2.7.0 | Declared background-work and image-loading libraries. |
| Serialization / coroutines | 1.7.3 / 1.8.1 | Declared JSON and asynchronous-work libraries. |
Website and store distributions have different features and dependencies. The website phone build includes Story Mode; the reviewed store flavors exclude it. Some casting and purchase integrations are also distribution-specific. Check the intended download and device page rather than assuming all packages are identical.
Why the exact version is useful
Version numbers help testers reproduce behavior, identify compatibility changes and compare like-for-like builds. They do not establish that one app is faster, safer or higher quality. Decoder support, encoder settings, operating system, driver, display, receiver and network must be recorded too.
Open-source technology names identify components used by Beebo, not endorsements or competitor rankings. The notices distributed with the application remain applicable.
What has been checked, and what a tester confirms
A ✓ Built · local checks passed label identifies the stated local verification scope, with real-user/device testing still needed. A ✓ Device tested label requires a recorded test on the stated equipment. Built · verification pending means implementation was inspected without a matching completed test record in this review. Hardware requirements are conditions, not a failure status.
✓ Built · documented local integration checks
The September 21, 2026 local QA record for desktop 0.1.58 reports original-file range/seek requests, playback negotiation, HLS conversion, remux behavior, text-subtitle conversion and an actual 720p browser playback check. These are scoped historical results; they do not certify every later release or every device.
Broader testing must still confirm real 4K files, graphics drivers, HDR display mode, receiver output, large-file startup, constrained networks and simultaneous viewers. Source-only features above remain built with verification pending until a matching passing record is attached.
A useful playback test report
- Record the app version, distribution, computer, operating system and playback device.
- Use an original or authorized sample and record container, video codec, dimensions, audio and subtitles.
- Record the selected quality and actual path: Direct Play, remux or conversion.
- Check start, seek forward/backward, pause/resume, audio selection, subtitles and reconnect.
- For HDR or surround, check the display/receiver’s actual input mode rather than relying on a library badge.
- Report the result and conditions through the tester page.