Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[AndrewFG]

Currently the MC DLNA server has a few missing features as follows:

• It has weak support for adding DSP effects. In particular where the DSP effect would result in a change in the sample rate, the bit depth, or channel count, or the duration.
• It has weak support for Seek. In particular when transcoding audio tracks where the Seek destination is beyond the current extent of the transcoder output buffer file.
• It has weak support for serving files transcoded to formats other than Original, or the single defined Convert target format.

There are a number of reasons for the above.

1. The MC DLNA Server transcoder can only start transcoding from a time offset of zero.
2. The MC DLNA Server transcoding target formats only include the limited choice of PCM L16, L24, MP3, and WAV.
3. The MC HTTP server does not check or honor the renderer's Accept mime type requests.
4. The MC HTTP server does not provide an Accept-Ranges header on all file types.
5. The MC HTTP server does not always provide a proper Content Length on all file types.
6. The MC DLNA Server settings do not allow it to pre-calculate the impact of DSP functions on the transcoded file size.
7. The MC DLNA Server settings provide three Modes Original, Convert if Needed, and Always convert, but none for Convert As Requested by renderer.

With the likely migration of MC to use the SOX transcoder engine, the MC server could support transcoding from a time offset greater than zero (transcoder seek) -- thus addressing 1. above.  With the SOX transcoder engine the MC server could also support transcoding to many other audio formats than the current L16, WAV, MP3 -- thus expanding the choices on 2. above, and enabling 3. above. And with relatively simple code changes (see below), MC could solve the issues 3. thru 6. above. And if MC were to introduce another Server Mode = Convert As Requested by renderer it would solve issue 7.

The fundamental barrier, underlying all of the above, is item 5. -- namely that the coders are not willing to offer a Content-Length value on transcoded files. This is certainly difficult because, in the case you are transcoding, you cannot know the length of the transcoder output file until after the transcoding is fully complete; whereas you have to offer the Content-Length immediately. The solution is, obviously, whenever you do not know the precise Content-Length value, you offer instead an ESTIMATED Content-Length value. Where the estimated Content-Length value equals the Duration in seconds (which MC does know in advance) X the BytesPerSecond throughput of the transcoder's output music format.

Making this jump from timidly declining to offer a precise Content-Length value, to boldly offering an ESTIMATED Content-Length value, is really all that it takes. The rest is just coding..

In the attachment is some pseudo code that I wrote, showing how to implement items 1. thru 7. above on the MC server side. Some of the code in my attachment would also need to be duplicated in the part of MC that calculates the FileSize and BytesPerSecond attributes that it offers in the UPnP metadata which it provides in its responses to CDS:Browse and in its AVT:Set(Next)AVTransportURI commands.

C'mon guys, please use this. It's free..

[Hendrik]

I've already answered this in another thread, we're *not* using SoX for transcoding in MC22, or any forseeable future. We're only using its resampling algorithm (ie. SoX Resampler library).

[AndrewFG]

Hi Hendrik,

Ok.

But if you did do that, you could certainly improve the MC DLNA feature set as I have mentioned.

Alternatively you could use your existing transcoder engine and add a seek offset functionality to that.