mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-01-23 23:20:51 +01:00
[10.8.0 - beta2] Transcoding of audio files fails because of incorrect output codec parameter. #3760
Labels
No labels
area:database
awaiting-feedback
backend
blocked
breaking change: web api
bug
build
ci
confirmed
discussion needed
dotnet future
downstream
duplicate
EFjellyfin.db
enhancement
feature
future
github-actions
good first issue
hdr
help wanted
invalid
investigation
librarydb
live-tv
lyrics
media playback
music
needs testing
nuget
performance
platform
pull-request
question
regression
release critical
requires-web
roadmap
security
security
stale
support
syncplay
ui & ux
upstream
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: starred/jellyfin#3760
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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:
The problem is independent of input file format.
Running the command without specifying the option
-ar 44100, or changing it to-ar 48000fixes 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"Jellyfin Version
10.8.0
if other:
beta 2
Environment
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
@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?
@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.
@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.
@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.
@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:
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!
@Shadowghost commented on GitHub (May 8, 2022):
The PR was already changed to upsample if inbetween, so no worries :)
@Lewis-CJ commented on GitHub (May 9, 2022):
Excellent work by all involved! I've tested and can confirm it works as expected.
@caiusseverus commented on GitHub (Jun 8, 2022):
Going to close this as the problem is fixed.