# Several-second delay rendering video and waveform in audio\_manual for large video files loaded from URLs

**URL:** <https://support.prodi.gy/t/several-second-delay-rendering-video-and-waveform-in-audio-manual-for-large-video-files-loaded-from-urls/7702>\
**Category:** Uncategorized\
**Created:** [October 19, 2026, 7:23pm UTC](https://support.prodi.gy/t/several-second-delay-rendering-video-and-waveform-in-audio-manual-for-large-video-files-loaded-from-urls/7702 "2026-10-19T19:23:43Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![xieh](https://avatars.discourse-cdn.com/v4/letter/x/b19c9b/32.png) [@xieh](https://support.prodi.gy/u/xieh)\
**Post date:** [October 19, 2026, 7:23pm UTC](https://support.prodi.gy/t/several-second-delay-rendering-video-and-waveform-in-audio-manual-for-large-video-files-loaded-from-urls/7702/1 "2026-10-19T19:23:43Z")

</div>

Hi Prodigy team,

I'm using the `audio_manual` interface to annotate video files larger than 100MiB. When a task loads, there is a consistent delay of several seconds before the video player and audio waveform appear in the UI.

**Setup** :

- Prodigy version: `v1.18.8`
- Interface: `audio_manual`
- Video files: \>100MiB
- Media is loaded from URLs (not base64-embedded)

**Observed behavior** :

- After the task loads, the UI shows nothing (no video, no waveform) for several seconds.
- After that delay, both the video and waveform appear.

**Questions** :

- Is this delay expected behavior for large video files in `audio_manual`?
- Is there a supported way to reduce the time to first render?
- Is there a recommended pattern for annotating large video files with this interface (e.g., chunking, media fragments, or a different interface)?

I'd appreciate any guidance on whether this is a known limitation or something that can be addressed through configuration or a custom recipe.

Thanks!

---

<div class="post-metadata">

**Author:** ![ines](https://sea2.discourse-cdn.com/flex020/user_avatar/support.prodi.gy/ines/32/3_2.png) [@ines](https://support.prodi.gy/u/ines)\
**Post date:** [October 21, 2026, 10:22am UTC](https://support.prodi.gy/t/several-second-delay-rendering-video-and-waveform-in-audio-manual-for-large-video-files-loaded-from-urls/7702/2 "2026-10-21T10:22:37Z")

</div>

Hi! Thanks for the detailed report and sorry about this – this definitely sounds a bit longer than it should be.

In general, the interface is optimised for / most tested with shorter files (also to go with Prodigy's "make annotation decisions simple and quick" philosophy) and there'll likely always be _some_ level of loading time as the browser fetches the file and sets up the player.

We can definitely look into whether there are ways to optimise the player (powered by wavesurfer) and UI in general to make it better and faster!

In the meantime, is there a way you can optimise the files upfront to make them smaller? You could do this programmatically with a [custom stream](https://prodi.gy/docs/api-loaders#loaders-stdin) wrapper or similar if you have the files locally, before you serve them by the audio server. Depending on the data, even a slightly lossy compression might work fine for annotation purposes.

(And just for completeness, there's of course also the option to look into whether you can break down the task and work with shorter snippets instead. It's now relatively easy to automatically split files with something like [`faster-whisper`](https://github.com/SYSTRAN/faster-whisper) and then have a postprocessing script that re-aligns the timestamps to the original file. If there is required context, you could for instance provide this as text with the `blocks` interface. Then the annotators could move through the tasks more quickly and have to click less per example, and you'd also have much faster loading times.)