BBC HLS streams outside the UK

[Cebolla]

(07-11-2015 23:59)simoncn Wrote:  

(07-11-2015 23:56)pwsheridan Wrote:  Yes I have *:L16 in there at the moment

This explains the problem. See this post for an explanation and instructions on how to fix it.

Simon

Setting the stream information in the .m3u playlist files currently overrides the stream.transcode field value, at least for the BBC HLS streams. So the (reconstituted) AAC stream is what's supplied to the renderer and not the transcoded version given by the stream.transcode field.

I too have a Pioneer N-50 and it does actually support the BBC HLS streams as supplied by MinimStreamer without the need for transcoding to a format other than AAC. The only issue is that the N-50 needs to be told that the supplied stream is an AAC file by setting the file type 'aac' in the stream information, otherwise it doesn't recognise the 'file' type. Hence not setting the AAC file type in the stream information for the BBC HLS streams, such as by only setting '48000' as Paul did, will cause the N-50 not to play the stream.

Actually, I'm not sure if the N-50 is looking for the aac suffix in the stream's pathname or aac metadata in the stream's contents or both, in order to recognise the 'file'.

So, unless Paul requires the *:L16 (or even the *.wav) setting to transcode some network streams other than the BBC HLS ones, it's not really required for the Pioneer N-50. Incidentally, the N-50 does support L16 with both the 44.1kHz and 48kHz sample rates (but not higher).

BTW, I've tested the same low res HLS BBC streams on my N-50 without any of the delay issues that Paul experiencing, though I am based in the UK (and I am running MinimServer/MinimStreamer on a decent enough Win 7 machine).

John

[simoncn]

(08-11-2015 18:31)Cebolla Wrote:  Simon

Setting the stream information in the .m3u playlist files currently overrides the stream.transcode field value, at least for the BBC HLS streams. So the (reconstituted) AAC stream is what's supplied to the renderer and not the transcoded version given by the stream.transcode field.

I believe it is just the sample rate that is overridden incorrectly. I have just noticed this while testing various combinations and I am working on a fix.

Quote:I too have a Pioneer N-50 and it does actually support the BBC HLS streams as supplied by MinimStreamer without the need for transcoding to a format other than AAC. The only issue is that the N-50 needs to be told that the supplied stream is an AAC file by setting the file type 'aac' in the stream information, otherwise it doesn't recognise the 'file' type. Hence not setting the AAC file type in the stream information for the BBC HLS streams, such as by only setting '48000' as Paul did, will cause the N-50 not to play the stream.

I checked the syntax in the link that I gave Paul and it is incorrect. It is not possible to specify the sample rate without also specifying the stream type. My apologies for the incorrect information. The correct syntax is

#EXTINF:-1,[*R3;aac,48000] BBC Radio 3

Quote:Actually, I'm not sure if the N-50 is looking for the aac suffix in the stream's pathname or aac metadata in the stream's contents or both, in order to recognise the 'file'.

So, unless Paul requires the *:L16 (or even the *.wav) setting to transcode some network streams other than the BBC HLS ones, it's not really required for the Pioneer N-50. Incidentally, the N-50 does support L16 with both the 44.1kHz and 48kHz sample rates (but not higher).

BTW, I've tested the same low res HLS BBC streams on my N-50 without any of the delay issues that Paul experiencing, though I am based in the UK (and I am running MinimServer/MinimStreamer on a decent enough Win 7 machine).

John

Thanks very much for this very helpful information. I will post back here when the fix for incorrect sample rate overriding is available.

[pwsheridan]

(08-11-2015 18:52)simoncn Wrote:  

(08-11-2015 18:31)Cebolla Wrote:  Simon

Setting the stream information in the .m3u playlist files currently overrides the stream.transcode field value, at least for the BBC HLS streams. So the (reconstituted) AAC stream is what's supplied to the renderer and not the transcoded version given by the stream.transcode field.

I believe it is just the sample rate that is overridden incorrectly. I have just noticed this while testing various combinations and I am working on a fix.

Quote:I too have a Pioneer N-50 and it does actually support the BBC HLS streams as supplied by MinimStreamer without the need for transcoding to a format other than AAC. The only issue is that the N-50 needs to be told that the supplied stream is an AAC file by setting the file type 'aac' in the stream information, otherwise it doesn't recognise the 'file' type. Hence not setting the AAC file type in the stream information for the BBC HLS streams, such as by only setting '48000' as Paul did, will cause the N-50 not to play the stream.

I checked the syntax in the link that I gave Paul and it is incorrect. It is not possible to specify the sample rate without also specifying the stream type. My apologies for the incorrect information. The correct syntax is

#EXTINF:-1,[*R3;aac,48000] BBC Radio 3

Quote:Actually, I'm not sure if the N-50 is looking for the aac suffix in the stream's pathname or aac metadata in the stream's contents or both, in order to recognise the 'file'.

So, unless Paul requires the *:L16 (or even the *.wav) setting to transcode some network streams other than the BBC HLS ones, it's not really required for the Pioneer N-50. Incidentally, the N-50 does support L16 with both the 44.1kHz and 48kHz sample rates (but not higher).

BTW, I've tested the same low res HLS BBC streams on my N-50 without any of the delay issues that Paul experiencing, though I am based in the UK (and I am running MinimServer/MinimStreamer on a decent enough Win 7 machine).

John

Thanks very much for this very helpful information. I will post back here when the fix for incorrect sample rate overriding is available.

I have an update Simon to my streaming problem and as I read Johns previous post regarding using a Windows 7 machine. I decided to stop the Minimserver on the QNAP NAS and run the Minimserver from my Windows 10 Asus N550Jv Laptop. I also had to install ffmpeg on the Laptop. I have been running all BBC Radio channels since this morning and I have had no dropouts. Would the Qnap Nas Minimserver App be the reason for the dropouts? Anyway I am very happy that the Streams are all working perfectly at the moment. The Qnap Nas is the TS 410. Regards Paul

[Cebolla]

Paul

If the QNAP NAS is struggling because it's doing the extra AAC to L16 transcoding (which requires the external convertor to be used by MinimStreamer, so using ffmpeg in your case), you still have the simpler (& less burden on NAS's resources) option of just using the AAC stream extracted by Minimstreamer from the BBC HLS source (& so no need for the *:L16 transcoding option nor ffmpeg) for the N-50.

As I mentioned above, the N-50 requires the AAC stream type to be set in the stream information for each of the BBC HLS streams in the BBC radio.m3u file,
eg:
#EXTINF:-1,[*R3] BBC Radio 3
becomes:
#EXTINF:-1,[*R3;aac] BBC Radio 3

You could also add the 48000 sample rate for completeness, though I haven't found an issue with N-50 one way or the other so long as the 'aac' is still there. So using the above example:
#EXTINF:-1,[*R3;aac,48000] BBC Radio 3

BTW, are you using the *:L16 transcoding option for streams other than the BBC HLS ones?

[simoncn]

(09-11-2015 17:53)pwsheridan Wrote:  I have an update Simon to my streaming problem and as I read Johns previous post regarding using a Windows 7 machine. I decided to stop the Minimserver on the QNAP NAS and run the Minimserver from my Windows 10 Asus N550Jv Laptop. I also had to install ffmpeg on the Laptop. I have been running all BBC Radio channels since this morning and I have had no dropouts. Would the Qnap Nas Minimserver App be the reason for the dropouts? Anyway I am very happy that the Streams are all working perfectly at the moment. The Qnap Nas is the TS 410. Regards Paul

I checked the specs on the TS-410. It has a low-powered CPU and this might be the reason for the dropouts when transcoding to L16. You can confirm this by using Resource Manager on the QNAP to display the CPU usage. If it reaches 100% when the dropouts occur, this is the cause of the problem.

[pwsheridan]

(09-11-2015 21:57)simoncn Wrote:  

(09-11-2015 17:53)pwsheridan Wrote:  I have an update Simon to my streaming problem and as I read Johns previous post regarding using a Windows 7 machine. I decided to stop the Minimserver on the QNAP NAS and run the Minimserver from my Windows 10 Asus N550Jv Laptop. I also had to install ffmpeg on the Laptop. I have been running all BBC Radio channels since this morning and I have had no dropouts. Would the Qnap Nas Minimserver App be the reason for the dropouts? Anyway I am very happy that the Streams are all working perfectly at the moment. The Qnap Nas is the TS 410. Regards Paul

I checked the specs on the TS-410. It has a low-powered CPU and this might be the reason for the dropouts when transcoding to L16. You can confirm this by using Resource Manager on the QNAP to display the CPU usage. If it reaches 100% when the dropouts occur, this is the cause of the problem.

Yes John I have carried out the suggestions you made and dropouts are more frequent with not using *:L16 I also do not use it for other streams I will report back about Simons suggestion about the Qnap resource manager CPU usage.

[simoncn]

(09-11-2015 22:17)pwsheridan Wrote:  I will report back about Simons suggestion about the Qnap resource manager CPU usage.

I had the wrong name for this. It's actually the Resource Monitor tab within System Status.

[simoncn]

(08-11-2015 18:52)simoncn Wrote:  I believe it is just the sample rate that is overridden incorrectly. I have just noticed this while testing various combinations and I am working on a fix.

This fix is available now in MinimServer update 71.

[Cebolla]

(09-11-2015 22:17)pwsheridan Wrote:  Yes John I have carried out the suggestions you made and dropouts are more frequent with not using *:L16

Ok that's certainly unexpected, as I'd assumed that the external decoder was being used by MinimStreamer just to transcode the AAC stream to L16. That is, in addition to the decoding done by MinimStreamer to reconstruct that AAC stream from the BBC HLS AAC source stream in the first place.

From what you're saying, it sort of implies that the external decode is actually dealing with the original BBC HLS AAC source stream directly and at the same time producing the L16 output. Could be wrong, though, on all counts!

[Cebolla]

(09-11-2015 22:51)simoncn Wrote:  

(08-11-2015 18:52)simoncn Wrote:  I believe it is just the sample rate that is overridden incorrectly. I have just noticed this while testing various combinations and I am working on a fix.

This fix is available now in MinimServer update 71.

Excellent, thanks Simon.