Transcoding combinations UPnP and Internet Radio

[simoncn]

(13-03-2015 00:35)Pastim Wrote:  Simon, thanks very much for your detailed response. I'll need to go through it in more detail after some sleep, but I have two initial questions.

1. I had understood, and indeed thought I had read on a post somewhere, that for an Internet Radio (not a UPnP device) no transcoding ever took place. Am I wrong? The minimradio sites seem to make no mention of it.

This is because most internet radios should be able to play AAC streams without transcoding. The MinimRadio instructions are intended for people who have a internet radio that was previously playing BBC AAC streams and now want to move to the new HLS streams. They cover everything needed for this scenario without introducing additional complexity by mentioning things that aren't needed such as transcoding.

Quote:2. Why is it useful for the behaviour to be so different depending on whether the codec is explicit or determined by Minimstreamer? Why should a user care how the codec is determined? Surely if it is aac (for instance) the I would want it treated in the same way however this was discovered? It seems to me to make life quite complicated to no apparent benefit. What have I missed?

In the first release of MinimStreamer, the stream type and its transcoding setting (if any) were determined dynamically when the stream was selected for playing. This meant the control point and renderer didn't know in advance what type of stream to expect. Some UPnP control points and renderers handle this OK (e.g., Kinsky and the Linn DS) but many UPnP renderers can't handle this and need to know the stream type before they open the stream for playing.

To solve this problem, the following changes were made:

1) For nontranscoded streams, provide the ability to specify an explicit stream type in the m3u file which enables the stream type to be known in advance.

2) For transcoded streams, add the "*" input type which enables the output type to be known in advance even if the input type isn't known in advance.

In addition, support was added for sending multiple transcoded output streams for a single input stream.

The situation is now as follows:

A) If the stream type isn't specified explicitly, you can do the following:

i) Use the "*" transcoding input type with a single output type to give the control point a single stream type in advance

ii) Use the "*" transcoding input type with mulitple output types to give the control point a choice of stream types in advance

iii) Use the "aac" transcoding input type, so the control point gets a single stream of unknown type and MinimStreamer selects the output type when the stream is opened and the type becomes known (using the caret if specified)

iv) do nothing, so the control point gets a single untranscoded stream of unknown type

B) If the stream type is specified explicitly as "aac", you can do the following:

i) Use the "aac" transcoding input type with a single output type to give the control point a single stream type in advance

ii) Use the "aac" transcoding input type with mulitple output types to give the control point a choice of stream types in advance

iii) do nothing, so the control point gets a single untranscoded stream of known type "aac"

Note the overlap between the transcoding settings for B) i), B) ii) and A) iii). This overlap gives the "aac" input type setting a dual purpose that applies in both the A) and B) cases with different effects.