I'm conducting a systematic evaluation of video generation platforms for a high-volume content pipeline, and Fliki is currently in the testing phase. My initial benchmarks for desktop export quality are within acceptable parameters for the target use case (social media clips). However, the mobile export workflow is producing results that fail to meet even baseline quality thresholds, which presents a significant operational blocker.
The test methodology is as follows:
* **Source Material:** A 60-second script with 3 distinct visual scenes, generated using Fliki's "Realistic" AI avatar.
* **Export Process:** Identical script and assets exported twice via the Fliki mobile application (iOS v2.4.1).
* Test A: "Standard" quality preset.
* Test B: "HD (1080p)" quality preset selected.
* **Analysis:** Side-by-side frame analysis on a calibrated monitor, with bitrate extraction using `ffprobe`.
The results are conclusive and problematic:
```bash
# Desktop Export (Web, HD setting)
Stream #0:0: Video: h264 (High), yuv420p, 1920x1080, 5987 kb/s
# Mobile Export, Test B (App, HD setting)
Stream #0:0: Video: h264 (Baseline), yuv420p, 1920x1080, 1852 kb/s
```
The mobile application is enforcing the H.264 Baseline profile, which is inefficient for compression, and the bitrate is approximately 70% lower than the desktop counterpart despite the identical resolution setting. Visually, this manifests as pronounced macroblocking in gradients, blurring of text overlays, and a complete loss of fine detail in the AI avatar's features. The output is functionally unusable for any platform where visual fidelity matters.
My questions for the community and any Fliki representatives are data-specific:
1. Is this a known, intentional compression profile for the mobile application to reduce processing load or data transfer, or is it a defect?
2. Are there any hidden configuration parameters (e.g., a CRF value or target bitrate) that can be adjusted client-side to override this?
3. What is the official benchmark for the "HD" export setting? The variance between platforms suggests the label is not governing a consistent quality target.
From a cost-modeling perspective, if the mobile output is permanently degraded, it forces the workflow back to the desktop, which reduces platform utility. I need to determine if this is a temporary constraint or a fundamental architectural limitation before proceeding with integration.
-ek
Show me the numbers, not the roadmap.
> Side-by-side frame analysis on a calibrated monitor
There's your first mistake. You're bringing lab equipment to a phone-fight.
The mobile app isn't magically worse. It's prioritizing different things. Smaller screen means they can get away with a much lower bitrate because compression artifacts are less visible. They're almost certainly using a faster, less efficient encoder preset to save CPU cycles and battery on a phone. Baseline profile versus High confirms it - that's about decoder compatibility and processing overhead.
You're benchmarking for a "high-volume content pipeline" but testing on a *mobile app*? That's like evaluating a freight train by pushing it down the street. Use the API or stick to the web platform. The mobile export is a convenience feature for one-offs, not a production tool.
-- old school
You're focusing on the bitrate difference, which is the symptom, but the key finding is the **profile**. Baseline vs. High is the real smoking gun here.
A lower bitrate on mobile could be rationalized for speed/battery. But Baseline profile restricts the encoding tools available, forcing more bitrate to achieve the same visual quality. It's the wrong tool for the job if "HD" is the claim. The app is likely using a hardware encoder with limited profile support, which makes sense for live streaming but not for a quality-focused export.
Your methodology is solid. The data shows they're not just compressing more, they're using a fundamentally inferior encoding scheme on mobile, regardless of the resolution tag. I'd rerun the test checking the `x264-params` if possible - you'll likely find `cabac=0` and `ref=1`, which confirm the Baseline constraints.
Garbage in, garbage out.