[10.8.0 - beta2] Transcoding of audio files fails because of incorrect output codec parameter. #3760

Closed
opened 2025-12-21 22:42:36 +01:00 by backuprepo · 8 comments
Owner

Originally created by @caiusseverus on GitHub (Apr 21, 2022).

Please describe your bug

Transcoding of audio files does not work correctly in 10.8.0 beta 2 because a parameter in the ffmpeg command line is incorrect. Specifically, setting a sample rate of 44.1kHz while using the opus codec as output will fail, because opus does not support 44.1 kHz sample rates.

Example ffmpeg command line:
/usr/lib/jellyfin-ffmpeg/ffmpeg -i file:"/mnt/media/music/Eminem/Relapse (2009)/CD 01/Eminem - Relapse - 05 - Bagpipes from Baghdad.flac" -threads 0 -vn -ab 128000 -ac 2 -ar 44100 -id3v2_version 3 -write_id3v1 1 -y "/mnt/process/transcode/jellyfin/c13649e1959c1d92e29a51b96290c979.opus"

This fails with the error message:

Stream mapping:
  Stream #0:0 -> #0:0 (flac (native) -> opus (libopus))
Press [q] to stop, [?] for help
[libopus @ 0x56309830d1c0] Specified sample rate 44100 is not supported
Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height

The problem is independent of input file format.

Running the command without specifying the option -ar 44100, or changing it to -ar 48000 fixes the problem and transcoding happens as expected:

/usr/lib/jellyfin-ffmpeg/ffmpeg -i file:"/mnt/media/music/Eminem/Relapse (2009)/CD 01/Eminem - Relapse - 05 - Bagpipes from Baghdad.flac" -threads 0 -vn -ab 128000 -ac 2 -id3v2_version 3 -write_id3v1 1 -y "/mnt/process/transcode/jellyfin/c13649e1959c1d92e29a51b96290c979.opus"

Stream mapping:
  Stream #0:0 -> #0:0 (flac (native) -> opus (libopus))
.
.
size=    4614kB time=00:04:43.05 bitrate= 133.5kbits/s speed=45.8x

Jellyfin Version

10.8.0

if other:

beta 2

Environment

- OS: Ubuntu 20.04
- Virtualization: None
- Clients: Symfonium (android)
- Browser: N/A
- FFmpeg Version: jellyfin-ffmpeg 4.4.1-4-focal
- Playback Method: transcode
- Hardware Acceleration: N/A
- Reverse Proxy: nginx

Jellyfin logs

No response

FFmpeg logs

No response

Please attach any browser or client logs here

No response

Please attach any screenshots here

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct
Originally created by @caiusseverus on GitHub (Apr 21, 2022). ### Please describe your bug Transcoding of audio files does not work correctly in 10.8.0 beta 2 because a parameter in the ffmpeg command line is incorrect. Specifically, setting a sample rate of 44.1kHz while using the opus codec as output will fail, because opus does not support 44.1 kHz sample rates. Example ffmpeg command line: `` /usr/lib/jellyfin-ffmpeg/ffmpeg -i file:"/mnt/media/music/Eminem/Relapse (2009)/CD 01/Eminem - Relapse - 05 - Bagpipes from Baghdad.flac" -threads 0 -vn -ab 128000 -ac 2 -ar 44100 -id3v2_version 3 -write_id3v1 1 -y "/mnt/process/transcode/jellyfin/c13649e1959c1d92e29a51b96290c979.opus"`` This fails with the error message: ``` Stream mapping: Stream #0:0 -> #0:0 (flac (native) -> opus (libopus)) Press [q] to stop, [?] for help [libopus @ 0x56309830d1c0] Specified sample rate 44100 is not supported Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height ``` The problem is independent of input file format. Running the command without specifying the option ``-ar 44100``, or changing it to ``-ar 48000`` fixes the problem and transcoding happens as expected: ``/usr/lib/jellyfin-ffmpeg/ffmpeg -i file:"/mnt/media/music/Eminem/Relapse (2009)/CD 01/Eminem - Relapse - 05 - Bagpipes from Baghdad.flac" -threads 0 -vn -ab 128000 -ac 2 -id3v2_version 3 -write_id3v1 1 -y "/mnt/process/transcode/jellyfin/c13649e1959c1d92e29a51b96290c979.opus"`` ``` Stream mapping: Stream #0:0 -> #0:0 (flac (native) -> opus (libopus)) . . size= 4614kB time=00:04:43.05 bitrate= 133.5kbits/s speed=45.8x ``` ### Jellyfin Version 10.8.0 ### if other: beta 2 ### Environment ```markdown - OS: Ubuntu 20.04 - Virtualization: None - Clients: Symfonium (android) - Browser: N/A - FFmpeg Version: jellyfin-ffmpeg 4.4.1-4-focal - Playback Method: transcode - Hardware Acceleration: N/A - Reverse Proxy: nginx ``` ### Jellyfin logs _No response_ ### FFmpeg logs _No response_ ### Please attach any browser or client logs here _No response_ ### Please attach any screenshots here _No response_ ### Code of Conduct - [X] I agree to follow this project's Code of Conduct
backuprepo 2025-12-21 22:42:36 +01:00
  • closed this issue
  • added the
    bug
    label
Author
Owner

@Lewis-CJ commented on GitHub (May 6, 2022):

I can confirm this issue, also using symfonium
// opus will fail on 44100
13df026f6b/MediaBrowser.Controller/MediaEncoding/EncodingHelper.cs (L5370)

What is OutputAudioSampleRate in this line? Does it come from symfonium's request?
Should opus be upsampled to 48k?

@Lewis-CJ commented on GitHub (May 6, 2022): I can confirm this issue, also using symfonium // opus will fail on 44100 https://github.com/jellyfin/jellyfin/blob/13df026f6b8d288acc0201d1076ed0c401c61043/MediaBrowser.Controller/MediaEncoding/EncodingHelper.cs#L5370 What is OutputAudioSampleRate in this line? Does it come from symfonium's request? Should opus be upsampled to 48k?
Author
Owner

@caiusseverus commented on GitHub (May 6, 2022):

Opus has a list of specific sample rates that it supports: https://en.wikipedia.org/wiki/Opus_(audio_format)#Bandwidth_and_sampling_rate

Since it doesn't support 44.1 kHz directly, the closest sample rate it does have is 48 kHz so that should be used.

I don't know if the sample rate is being set incorrectly as a result of Symfonium incorrectly specifying it, or the bug is in that existing code that should be handling this problem.

Either way, jellyfin shouldn't try to set an incompatible sample rate as a transcoding parameter.

@caiusseverus commented on GitHub (May 6, 2022): Opus has a list of specific sample rates that it supports: https://en.wikipedia.org/wiki/Opus_(audio_format)#Bandwidth_and_sampling_rate Since it doesn't support 44.1 kHz directly, the closest sample rate it does have is 48 kHz so that should be used. I don't know if the sample rate is being set incorrectly as a result of Symfonium incorrectly specifying it, or the bug is in that existing code that should be handling this problem. Either way, jellyfin shouldn't try to set an incompatible sample rate as a transcoding parameter.
Author
Owner

@Shadowghost commented on GitHub (May 6, 2022):

Would be nice if you could test with #7716 applied.

The PR chooses the next lower sampling rate.

@Shadowghost commented on GitHub (May 6, 2022): Would be nice if you could test with #7716 applied. The PR chooses the next lower sampling rate.
Author
Owner

@caiusseverus commented on GitHub (May 6, 2022):

Would it not be preferable to choose the next higher sample rate rather than the lower to avoid losing bandwidth? eg Choosing 24 kHz for a 44.1 kHz stream means you only get an audio bandwidth of 12 kHz which is not the full audible range. Most music audio will be 44.1 kHz because that is the CD sample rate.

@caiusseverus commented on GitHub (May 6, 2022): Would it not be preferable to choose the next higher sample rate rather than the lower to avoid losing bandwidth? eg Choosing 24 kHz for a 44.1 kHz stream means you only get an audio bandwidth of 12 kHz which is not the full audible range. Most music audio will be 44.1 kHz because that is the CD sample rate.
Author
Owner

@Lewis-CJ commented on GitHub (May 8, 2022):

Yes I agree with caiusseverus: do not use a lower sampling rate.
If the sampling rate is less than 48 kHz, go one rate up. This will almost always end up being 48 kHz, which is the opus default. An alternative would be to just default to 48 kHz with ffmpeg no matter what.

From the docs:

Internally Opus stores data at 48000 Hz, so that should be the default value for Fs. However, the decoder can efficiently decode to buffers at 8, 12, 16, and 24 kHz so if for some reason the caller cannot use data at the full sample rate, or knows the compressed data doesn't use the full frequency range, it can request decoding at a reduced rate. Likewise, the decoder is capable of filling in either mono or interleaved stereo pcm buffers, at the caller's request.

https://opus-codec.org/docs/opus_api-1.3.1/group__opus__decoder.html

I'm not sure if ffmpeg will fill with zeros or interpolate, but as it is nicely put here, if someone worries about that, they should leave it as FLAC!

@Lewis-CJ commented on GitHub (May 8, 2022): Yes I agree with caiusseverus: do not use a lower sampling rate. If the sampling rate is less than 48 kHz, go one rate up. This will almost always end up being 48 kHz, which is the opus default. An alternative would be to just default to 48 kHz with ffmpeg no matter what. From the docs: > Internally Opus stores data at 48000 Hz, so that should be the default value for Fs. However, the decoder can efficiently decode to buffers at 8, 12, 16, and 24 kHz so if for some reason the caller cannot use data at the full sample rate, or knows the compressed data doesn't use the full frequency range, it can request decoding at a reduced rate. Likewise, the decoder is capable of filling in either mono or interleaved stereo pcm buffers, at the caller's request. https://opus-codec.org/docs/opus_api-1.3.1/group__opus__decoder.html I'm not sure if ffmpeg will fill with zeros or interpolate, but as it is nicely put [here](https://wiki.xiph.org/OpusFAQ#But_won.27t_the_resampler_hurt_the_quality.3F_Isn.27t_it_better_to_use_44.1_kHz_directly.3F), if someone worries about that, they should leave it as FLAC!
Author
Owner

@Shadowghost commented on GitHub (May 8, 2022):

The PR was already changed to upsample if inbetween, so no worries :)

@Shadowghost commented on GitHub (May 8, 2022): The PR was already changed to upsample if inbetween, so no worries :)
Author
Owner

@Lewis-CJ commented on GitHub (May 9, 2022):

Excellent work by all involved! I've tested and can confirm it works as expected.

@Lewis-CJ commented on GitHub (May 9, 2022): Excellent work by all involved! I've tested and can confirm it works as expected.
Author
Owner

@caiusseverus commented on GitHub (Jun 8, 2022):

Going to close this as the problem is fixed.

@caiusseverus commented on GitHub (Jun 8, 2022): Going to close this as the problem is fixed.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: starred/jellyfin#3760
No description provided.