[API Request] Expose codec, container, full codec

[Tolriq]

Type of change

API extension

Proposal description

Now that we split the query in 2 and already have bitrates and samplerate let's finish the missing data.

Expose new fields for songs:

• codec: Short well known codec name (pcm, mp3, ...)
• container: The container (webm, mkv, dsd, ...)
• full codec: The full codec name with details like the different variations of pcm

Backward compatibility impact

No response

Backward compatibility

• No backward compatibility impact.

API details

TBD depending on the choice made.

Security impacts

No response

Potential issues

As discussed before this adds more data to the json payloads, but this greatly help apps to decide to request transcoding or not.

The simple solution would be to only return the extended data in the getSong endpoint but for the moment we have no process / documentation solution to indicate that a field for a response should only be filled for a specific endpoint so it requires to define that too if we go that road.

Alternative solutions

No response

[dweymouth]

I think adding full codec info to the base payloads might be not desirable depending on how much info we want to add there, and introducing a new endpoint getCodecInfo that takes multiple song IDs and returns the long-form codec info for each could be a way to go. The short-form codec and container could be made part of the base song payload.

[Tolriq]

It's information that users like to have for display purpose and for filtering (as said too :p)

Typically they can make smart playlists for HQ audio, filter low quality media and many other things.

[epoupon]

Ah yes indeed, missed that one. Now you know we really don't read you :)

And maybe I missed this too, but what is "full codec info" vs codec+container?

[Tolriq]

Well it was said too :)

It was the first version of the proposal that gave a limited know list of codecs, and so needed a way to provide the complete one.

[epoupon]

Ok so now? we remove this info and just focus on container/codec?

[Tolriq]

#87 (reply in thread) ? :)

[Tolriq]

So to move on this I suggest we simplify and return to the very initial stuff of returning the codec and container as returned by ffmpeg.
They are well known and every server that will transcode will use ffmpeg so will use those values for the transcoding part.

Having consistent values in the returned data and for the future transcoding api makes things easy and simple.

ffprobe -formats for the containers
ffprobe -codecs for the codecs

We do not enforce any list as new codecs can be added in future ffmpeg versions.

[Tolriq]

Tag lib does not return any actual proper value and is ultra limited in what in support.
Precise data is needed for transcoding and transcoding will require ffmpeg anyway.

Edit: For raw limited display only purpose we already have a field in the API.

[deluan]

I agree with @epoupon that forcing the server to use ffmpeg to scan files is not desirable. I think this could be implemented as a new endpoint that receives a list of ids and return the codec info for those ids only. This can be cached in the server for future requests. But having to process this beforehand (during import) can make the scan process really slow for servers that rely on taglib (most of them?)

[Tolriq]

Taglib does not return proper data to be used.

We can rely on a new endpoint but for one song, if we allow multiple then I ask for the 300k in one shot and it's not working.

And at that point we can directly build the transcoding API that goes with it.

[deluan]

Taglib does not return proper data to be used.

Yes, I understand that, but don't think forcing the server to run ffprobe/ffmpeg on every scanned song is a solution here.

We can rely on a new endpoint but for one song, if we allow multiple then I ask for the 300k in one shot and it's not working.

I think the idea with for this endpoint (suggested by @dweymouth) would be to call it when you add songs to the playqueue, so the client can add the proper transcoding parameters at that moment.

And at that point we can directly build the transcoding API that goes with it.

I personally think this should be the way to go, instead of debating on a half-backed solution.

[Tolriq]

You do not need to prepare 300 songs in advance you need to transcode the one you play. Preparing all the queue just slow down playback on the client. It's the same for the lyrics you don't need to extract all the queue lyrics on the start.

And there's 2 different needs, the transcoding engine, but also exposing actual data that users can use for filtering.
All other non subsonic providers expose proper codec and container for that purpose.
We now have sample rate and others but still miss proper codecs for that need.

So if no ffmpeg then that need is not possible to fit as we can't do 300000 request to get all the data one by one.

Anyway the real urgency is the transcoding part as it's really limiting Subsonic but exposing proper codec is a frequent user need that should be tacked at some point.