Transcoding combinations UPnP and Internet Radio

[Pastim]

(13-03-2015 10:27)simoncn Wrote:  

(13-03-2015 00:35)Pastim Wrote:  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.

OK. Thanks very much indeed. I now believe I understand what happens in most cases. I also believe I now see more clearly what has been puzzling me.

I have 2 UPnP renderers with different characteristics, and I want to use the best I can on each. This turns out to be wav24/L16.

In due course I may have some streams I know are aac, such as current BBC radio, and I can force this in the playlist file (don't worry - I don't plan on tweaking the URLs myself). I may also have some streams that I don't know are aac, but minimserver finds out.

If I use aac:wav24/L16 the known aac streams will be processed as I like, but the unknown ones will not, since the 1st choice is always used (so I guess I had better use L16/wav24 instead?).

If I use *:wav24/L16 the known aac streams won't be processed as I want.

If I use both, the aac one will be used, since minimstreaming discovcers it is aac, and the * one ignored.

Is that all correct?

The only way round this that I can see is that I will have to make sure that I find out what the streamed codec is for any station I might ever play via minimstreamer and specify it in the playlist file.