[API Request] Advanced transcoding #121
Replies: 3 comments 12 replies
-
|
Thank you for starting this discussion. |
Beta Was this translation helpful? Give feedback.
-
|
Should the application of ReplayGain be part of this change (driven from the client as only it can handle auto)? This is one of the areas currently lacking in my LMS & Symfonium setup when casting. |
Beta Was this translation helpful? Give feedback.
-
|
I would also add to the discussion, the ability to NOT transcode, including to raw. The issue I've been running into is related to DSD playback, especially via UPnP. I use Symfonium as my playback app of choice, as well as a mechanism to stream to UPnP devices. What I've found to be what seems like an issue with opensubsonic itself is that DSD files get converted to "raw" when streaming them via UPnP, and wrapped in a .flac container. This confuses the heck out of renderers. Out of 3 renders, only one can make sense of this type of stream. Upmpd (MPD with libupnp bolted on, basically) handles this. However, Neutron and UAPP cannot make sense of it, and want to treat the stream as PCM. Neutron does recognize the stream as DPCM (PCM containing DSD), but still cannot manage to play it properly. I've been emailing back and forth with the folks who make Neutron, and thus far, the only solution we've been able to come up with, is to enable PCM to DSD conversion, forcing the Neutron to do the DSD thing. This, however, is far form ideal, as it greatly increases CPU usage (15% when playing DSD from Neutron itself, to 83% or more when doing the conversion work around). I've isolated (as best I can) this to be a function of opensubsonic itself. The server I use is Navidrome, but the same behavior is exhibited when using lms as the server. Symfonium properly stream .dsf / dsd to UPnP renderers when not using a subsonic media provider. So the constant here is opensubsonic. I don't believe this would be an issue if either the .dsf file was served up without being converted to "raw," especially when being sent to an external player (this would likely require communication from the client to the server), or some how come up with a solution for DSD that otherwise works. It seems, to me, that everything was designed with only PCM in mind. Which, is not unreasonable. Probably 96% of music libraries are lossy or PCM. However, DSD is a thing, and it should be supported properly. I've talked to folks working on Navidrome, Neutron, and Tolriq over at Symfonium. Everyone claims their portion of the equation is working properly (with the exception of Nuetron not properly broadcasting .dsf / dsd capabilities, but fixing that did not result in any different behavior). Thus, it must be a design issue / oversight. Even the ability to manually specify rules based on file type / codec / bitrate* via server the config file would be fine by me. Clearly, this would be far from the best, most elegant solution, but I'd take it. Either that, or everyone needs to switch their UPnP renders to using libupnp, as it is the most modern implementation and seems to be the only thing that works properly :) It's probably a bit unfair for me to editorialize this much, as I lack the technical understanding of how osub works, but these are just my observations as a frustrated user. I'm happy to test anything that needs testing.
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Type of change
API extension
Proposal description
This is the first step to discuss the future transcoding API extension that give a lot more control over when and to what to transcode.
This is necessary to give a lot more liberty to clients to request media they can play or cast to other device with proper quality control. When you can't play DSD files for example, it's better to transcode to FLAC than low quality mp3.
Or when your device does not support sampleRate over 48Khz it's better to reduce sample rate then low quality mp3.
There is 2 different approach to this need that have different impacts on the client or the servers.
1 - Client side decision
Leave the transcoding decision and target to the client
Issues:
2 - Server side decision
Leave the transcoding decision and target to the server.
Issues:
Other platforms
Other platforms like Emby, Plex, Jellyfin all do solution 2. But since they are a single server for a give API endpoint there's no drawback of multiple servers writing their own transcoding decision engine.
Backward compatibility impact
No response
Backward compatibility
API details
TBD
Security impacts
No response
Potential issues
No response
Alternative solutions
No response
Beta Was this translation helpful? Give feedback.
All reactions