Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Transcoding combinations UPnP and Internet Radio
13-03-2015, 10:48
Post: #21
RE: Transcoding combinations UPnP and Internet Radio
(13-03-2015 10:45)simoncn Wrote:  
(13-03-2015 10:32)Pastim Wrote:  So you are saying that transcoding can take place for Internet Radios, but doesn't (usually) need to. Is that correct?

Yes. This is what Zeewier is doing.

In the taxonomy that I gave earlier, this transcoding comes under case A) iii).
Find all posts by this user
Quote this message in a reply
13-03-2015, 10:54
Post: #22
RE: Transcoding combinations UPnP and Internet Radio
(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.
Find all posts by this user
Quote this message in a reply
13-03-2015, 11:29
Post: #23
RE: Transcoding combinations UPnP and Internet Radio
(13-03-2015 10:54)Pastim Wrote:  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?).

You can use the caret to override the default of using the first choice. This is why I suggested in an earlier post that you could use aac:wav24/L16/-^ to ensure that "unknown" aac streams don't get transcoded.

Quote: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?

If you use both (for UPnP), the "*" setting will be used for unknown streams and the "aac" setting will be used for known aac streams.

Quote: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.

This would be required if you want to use different transcoding settings for the same stream on different renderers. if you are OK with using a single transcoding setting for all renderers, you can leave the stream type as unspecified and use the caret as described above to get the transcoding that you want.
Find all posts by this user
Quote this message in a reply
13-03-2015, 11:45
Post: #24
RE: Transcoding combinations UPnP and Internet Radio
(13-03-2015 11:29)simoncn Wrote:  
(13-03-2015 10:54)Pastim Wrote:  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?).

You can use the caret to override the default of using the first choice. This is why I suggested in an earlier post that you could use aac:wav24/L16/-^ to ensure that "unknown" aac streams don't get transcoded.

Quote: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?

If you use both (for UPnP), the "*" setting will be used for unknown streams and the "aac" setting will be used for known aac streams.

Quote: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.

This would be required if you want to use different transcoding settings for the same stream on different renderers. if you are OK with using a single transcoding setting for all renderers, you can leave the stream type as unspecified and use the caret as described above to get the transcoding that you want.
I did ask. And now I don't understand again. Surely what I or anyone else would want is for anything aac to be processed in the same way every time. I really don't care how the type is determined. Why should I?

Sorry. I had better go away. I am clearly unable to explain myself, or comprehend your very thorough answers, and I must be very stupid. Apologies for wasting your time once more.
Find all posts by this user
Quote this message in a reply
13-03-2015, 13:19 (This post was last modified: 13-03-2015 13:20 by simoncn.)
Post: #25
RE: Transcoding combinations UPnP and Internet Radio
(13-03-2015 11:45)Pastim Wrote:  I did ask. And now I don't understand again. Surely what I or anyone else would want is for anything aac to be processed in the same way every time. I really don't care how the type is determined. Why should I?

Sorry. I had better go away. I am clearly unable to explain myself, or comprehend your very thorough answers, and I must be very stupid. Apologies for wasting your time once more.

The internet radio case isn't the same as the UPnP case. In the UPnP case, the control point can receive multiple streams with different types and choose one of these streams based on what it knows about renderer capabilities. In the internet radio case, there is no UPnP control point so MinimStreamer is sending a single stream and it needs to be MinimStreamer that makes the choice.

You said in an earlier post that you want to be able to mix multiple UPnP renderers and internet radios when using the same MinimServer instance and the same transcoding settings. In this case, it isn't possible for "aac to be processed in the same way every time" because the UPnP processing is necessarily different from the internet radio processing.
Find all posts by this user
Quote this message in a reply
13-03-2015, 14:25
Post: #26
RE: Transcoding combinations UPnP and Internet Radio
(13-03-2015 13:19)simoncn Wrote:  
(13-03-2015 11:45)Pastim Wrote:  I did ask. And now I don't understand again. Surely what I or anyone else would want is for anything aac to be processed in the same way every time. I really don't care how the type is determined. Why should I?

Sorry. I had better go away. I am clearly unable to explain myself, or comprehend your very thorough answers, and I must be very stupid. Apologies for wasting your time once more.

The internet radio case isn't the same as the UPnP case. In the UPnP case, the control point can receive multiple streams with different types and choose one of these streams based on what it knows about renderer capabilities. In the internet radio case, there is no UPnP control point so MinimStreamer is sending a single stream and it needs to be MinimStreamer that makes the choice.

You said in an earlier post that you want to be able to mix multiple UPnP renderers and internet radios when using the same MinimServer instance and the same transcoding settings. In this case, it isn't possible for "aac to be processed in the same way every time" because the UPnP processing is necessarily different from the internet radio processing.
Simon, I believe you are suggesting *:wav24/L16, aac:wav24/L16/-^ will provide a general solution to aac transcoding whether aac is explicit or not. Can you explain how that works for UPnP of different capabilities plus Internet Radios?
Find all posts by this user
Quote this message in a reply
13-03-2015, 17:29
Post: #27
RE: Transcoding combinations UPnP and Internet Radio
(13-03-2015 14:25)Pastim Wrote:  Simon, I believe you are suggesting *:wav24/L16, aac:wav24/L16/-^ will provide a general solution to aac transcoding whether aac is explicit or not. Can you explain how that works for UPnP of different capabilities plus Internet Radios?

For an internet radio:

When MinimStreamer opens the stream and detects its type is aac, it sends the stream to the internet radio as an untranscoded aac stream because of the caret position in the aac:wav24/L16/-^ setting.

For a UPnP control point and renderer playing an aac stream whose type is specified as aac in the m3u file:

The control point gets three streams of types wav24, L16 and aac. It selects one (starting with wav24) based on the capabilities of the selected renderer.

For a UPnP control point and renderer playing an aac stream whose type is not specified in the m3u file:

The control point gets two streams of types wav24 and L16. It selects one (starting with wav24) based on the capabilities of the selected renderer.
Find all posts by this user
Quote this message in a reply
13-03-2015, 17:53
Post: #28
RE: Transcoding combinations UPnP and Internet Radio
(13-03-2015 17:29)simoncn Wrote:  
(13-03-2015 14:25)Pastim Wrote:  Simon, I believe you are suggesting *:wav24/L16, aac:wav24/L16/-^ will provide a general solution to aac transcoding whether aac is explicit or not. Can you explain how that works for UPnP of different capabilities plus Internet Radios?

For an internet radio:

When MinimStreamer opens the stream and detects its type is aac, it sends the stream to the internet radio as an untranscoded aac stream because of the caret position in the aac:wav24/L16/-^ setting.

For a UPnP control point and renderer playing an aac stream whose type is specified as aac in the m3u file:

The control point gets three streams of types wav24, L16 and aac. It selects one (starting with wav24) based on the capabilities of the selected renderer.

For a UPnP control point and renderer playing an aac stream whose type is not specified in the m3u file:

The control point gets two streams of types wav24 and L16. It selects one (starting with wav24) based on the capabilities of the selected renderer.
Thanks.

You quote 3 cases, where I had thought there were 4. From previous answers my understanding was that if a '*' case is provided and aac is not explicit, the aac case is ignored, even for Internet Radio, in the same way as for UPnP. Was that incorrect? From your answer it seems that is a significant difference in processing rules that I have missed somewhere down the line.

If the aac case had not been supplied I understand Internet Radio would then have used the '*' case (where ^ is invalid) so would pick the first choice.
Find all posts by this user
Quote this message in a reply
13-03-2015, 18:25
Post: #29
RE: Transcoding combinations UPnP and Internet Radio
(13-03-2015 17:53)Pastim Wrote:  Thanks.

You quote 3 cases, where I had thought there were 4. From previous answers my understanding was that if a '*' case is provided and aac is not explicit, the aac case is ignored, even for Internet Radio, in the same way as for UPnP. Was that incorrect? From your answer it seems that is a significant difference in processing rules that I have missed somewhere down the line.

If the aac case had not been supplied I understand Internet Radio would then have used the '*' case (where ^ is invalid) so would pick the first choice.

The * case is used by UPnP only, not by internet radio.
Find all posts by this user
Quote this message in a reply
13-03-2015, 18:41
Post: #30
RE: Transcoding combinations UPnP and Internet Radio
(13-03-2015 18:25)simoncn Wrote:  
(13-03-2015 17:53)Pastim Wrote:  Thanks.

You quote 3 cases, where I had thought there were 4. From previous answers my understanding was that if a '*' case is provided and aac is not explicit, the aac case is ignored, even for Internet Radio, in the same way as for UPnP. Was that incorrect? From your answer it seems that is a significant difference in processing rules that I have missed somewhere down the line.

If the aac case had not been supplied I understand Internet Radio would then have used the '*' case (where ^ is invalid) so would pick the first choice.

The * case is used by UPnP only, not by internet radio.
Ah Ha! At last. Somewhere down the line, having said I was missing something fundamental, I have never noticed that this was the case. You may well have said so, or implied so, but I've not taken it in. You did say 'will not be transcoded' against my examples of this, but I did not realise the full import of what you said (I foolishly assumed that you meant it was somehow picking up the - part without the ^). So I have always assumed it was not completely ignored, and so have gone round and round in ever decreasing circles failing to find a workable solution that I can understand and make work.

If there are others who might fall into the same confusion it might help to have a brief mention in the user guide.

I won't ask why this is the way it works, I'm just happy to now know.

Thanks again.
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)