🐛 Bug Report: Downloaded videos have no audio track

Start in src/utils.rs at Media::parse and in templates/utils.html at the download link, then trace how the DASH or HLS media URLs are exposed. The issue describes separate video and audio representations and notes that audio filenames vary by post, so read the manifest or playlist rather than guessing a filename. Done means the downloaded video includes audio and plays like the post; consider the reported remuxing approach and its ffmpeg dependency.

Describe the bug

Using the download link on a v.redd.it video post saves a file that has no sound. The video plays with sound in the browser on the same instance, so the audio stream is reachable - it is just not part of the downloaded file.

As far as I can tell from the source, this is because Reddit stores a video post as separate DASH representations - a video-only track and one or more audio-only tracks - and the download link points at the video-only one:

• Media::parse in src/utils.rs assigns media.url from the API's fallback_url (the video-only DASH_<height>.mp4) and media.alt_url from hls_url.
• The download link in templates/utils.html is <a href="{{ post.media.url }}" download="{{ post.media.download_name }}">, so it serves fallback_url verbatim.
• In-browser playback with HLS enabled uses alt_url, where the player combines the video and audio streams. That is why the page has sound and the saved file does not.

This also explains why the symptom is easy to miss: with Use HLS off, playback is silent too, so the download at least matches what you heard. With Use HLS on - the default on the instance I used - the page has audio and the download silently does not.

Steps to reproduce the bug

1. Ensure Use HLS is on in settings (default on the instance below).

2. Open any v.redd.it post that has audio (not a GIF-type post).

3. Play it in the browser and confirm that it has sound.

4. Click download (dl on mobile).

5. Open the saved file in any player - it is silent.

6. ffprobe on the file reports a single stream, with no Audio entry:

   <paste ffprobe output here>
   

What's the expected behavior?

The downloaded file should contain the audio track as well, so that it plays back the same way it does on the post page.

Additional context / screenshot

Environment:

• Instance: https://redlib.catsarch.com
• Version: v0.36.0
• Git commit: 0ec5147860f66f7ded5f5d88beaf2bf655dedd85 (deployed 2026-10-17)
• Browser:

Note on that commit, so it is not a distraction: this instance runs a fork that has seven unmerged PRs applied on top of upstream. Per git compare it is 52 commits ahead of a4d36e9 and 0 behind, so it includes all of current main. I checked the fork's diff against the relevant code and none of its patches touch this path - the only media change is the added rich:video branch from #549 (for external transcoded media, which does not apply to a native v.redd.it post), and the download link in templates/utils.html is unmodified. So I believe this is upstream behavior rather than a fork artifact, but I am happy to re-verify on a vanilla instance if that is preferred.

Related, but I believe distinct:

• #105 asks for the ability to download HLS videos with sound. It was filed before the download button existed (added in #173), so it reads as a feature request for a missing capability rather than a report that the shipped button produces a file missing a stream. Happy for this to be folded into #105 if you prefer.
• #504 is about downloaded files being corrupt (moov atom not found), which is a different failure mode - here the file is valid and plays, it just has no audio.

On the cost concern raised in #105 about pushing encoding onto the server: combining the two DASH tracks does not require transcoding, only remuxing into an MP4 container (ffmpeg -i <video> -i <audio> -c copy -movflags +faststart out.mp4). That is I/O-bound rather than CPU-bound, so it is considerably cheaper than re-encoding - though it does still mean buffering the streams and an ffmpeg dependency.

If a muxing step is not wanted at all, even exposing the audio representation (so the audio track can be fetched and combined client-side, or at least downloaded separately) would be better than handing out a video-only file with no indication that a stream is missing. Note that the audio filename is not stable across posts - older posts use DASH_audio.mp4, newer ones DASH_AUDIO_128.mp4 or DASH_AUDIO_64.mp4 - so it should be read from the DASH manifest or the HLS playlist rather than guessed.

• I checked that the instance that this was reported on is running the latest git commit, or I can reproduce it locally on the latest git commit