Recording format and quality

Our trunk is set to store recordings in opus. Using batch export of recordings (/api/v2/recording/batchrequests), which according to documentation pulls the original recording, we get a file without file ending that we can change to .ogg and play.

If we pull the same recording using /api/v2/conversations/{conversationId}/recording and specifies formatId to OGG_OPUS we receive a .ogg file that is about 3-4 times lager than the recording from the batch request. So there seems to be some sort of transcoding happening even we request the same codec and container. Is that correct?

We want to export recordings in the best possible quality. The batch export function without transcoding seemed to be the correct method, but single exported recording returns a lager file. Can you clarify what's happening on your backend and what API we should use for best quality?

Best regards
Jonas

The batch requests endpoint delivers the recording file in the format specified on the trunk's configuration. Note that the extension of a file has no bearing on its content. I'd guess that if you've configured your trunk for opus, that's what you're getting from batch requests. Your audio player is probably reading the file contents and recognizing that the file extension is incorrect, but playing it anyway. If you believe the audio files are not in the correct formats, please open a case with PureCloud Care.

By using ffprobe and opusinfo I managed to pull additional data that mostly answers my original question. Files from both API's are opus, but with different average bitrate.

My question came from that you are transcoding a low-bitrate opus recording to a higher-bitrate opus recording, basically adding worthless data and consuming CPU. Not an actually issue, but you might want to change that to reduce load from transcoding. If source codec equals destination codec, don't transcode. :slight_smile:

Please report this via a case with PureCloud Care so it can be prioritized and addressed. The backend shouldn't be producing different results for the same codec. (And if by some chance that's intentional for some reason, it needs to be documented)

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.