Hi everyone—we’re building per-participant audio backups and trying to preserve a mono Opus track using StartEgress with preset: PASSTHROUGH.
In two controlled tests, we observed 711 mono Opus packets leaving the browser in each run, but both delivered Ogg files contained entirely stereo Opus packets. The output also reports GStreamer opusenc as its encoder.
Our request uses one explicit audio track, one file output, and no file type override or advanced encoding settings.
Is this expected for this export path, or are we missing a setting needed to preserve mono? We can share a redacted request and packet-analysis results, and provide export IDs privately if helpful.
Thanks!
We tested both export APIs sequentially with the same controlled synthetic mono source. Both delivered stereo Ogg files despite observing only mono Opus packets leaving the browser.
- StartEgress PASSTHROUGH —
EG_BnsP4BNbETwR: 697 observed outgoing packets, all mono; 1,057 delivered audio packets, all stereo.
- StartTrackEgress —
EG_a9JYmQuoCcwm: 701 observed outgoing packets, all mono; 1,066 delivered audio packets, all stereo.
Both runs selected audio/opus at 48 kHz, with no SDP override. We checked the actual serialized requests: each targeted one exact track and one file output, with PASSTHROUGH set for StartEgress. Both delivered files report two channels and GStreamer opusenc.
Our outgoing observations were taken in Chrome before transport encryption. They end before teardown and are not a receiver-side RTP capture, so we haven’t pinpointed where the conversion occurs. Both exports completed and their test rooms were removed.
Could someone from LiveKit inspect these export IDs and confirm whether they used a passthrough or transcoding pipeline? Is another setting required to preserve mono?
Hi, that PASSTHROUGH setting only applies to video, so the audio is still being decoded and re-encoded to a 2-channel stream. There is no option today to retain the original mono packets in your exported file I’m afraid - your left and right channels should be identical copies of your mono source.
Depending on what you need from your backups, you could specify an audio route in the call to StartEgress so the audio only appears in a single channel, but it is still re-encoded (you would also need to remove your passthrough preset for this to work):
"audio": {
"routes": [
{
"participantIdentity": "mono-publisher4",
"channel": "AUDIO_CHANNEL_LEFT"
}
]
}
I tested the above and, though it works, I know it’s not exactly what you’re asking for.
Or you could downmix the stereo output after export outside of LiveKit
Another option would be to subscribe to the track using one of our Server SDKs and record the original packets yourself. That wouldn’t use Egress, and I haven’t tested it, but server-sdk-go/examples/filesaver at main · livekit/server-sdk-go · GitHub seems to do the job you want (but be sure to specify 1 as the channel count if you want mono).
Thanks, Darryn—this explains what we observed, and we appreciate you testing the routing option.
We’ve revisited our requirement. We’re planning to retain the stereo exports and verify conversion in our processing pipeline.
It would help to clarify in the Egress API docs that PASSTHROUGH applies only to video and that audio is still re-encoded to two channels. We had interpreted it as preserving the encoded audio track too.
Thanks again for the explanation and alternatives!
fair point. The repo is private so I can’t link to it but I have raised a PR to add clarity.