Transcoding HLS streams to MP3 output

[simoncn]

(27-02-2015 00:27)Tell Wrote:  Simon will settle on the first one then if you can get it to handle the 0-0 probe or whatever it's doing. As said happy to give it a go with any test code.

I've looked at the mp3 log that you posted. Here is the sequence of byte-range requests that the Humax is sending to MinimServer:

Range: bytes=0-0
Range: bytes=0-1
Range: bytes=0-524287
Range: bytes=0-0
Range: bytes=0-1
Range: bytes=0-0
Range: bytes=0-1
Range: bytes=0-1048575
Range: bytes=1048576-

It isn't possible for MinimStreamer to handle this sequence of requests when playing a live network stream, for the following reasons:

1) "byte 0" is likely to have moved to a different point in the stream when the next request in the sequence is received

2) some of these requests require seeking / reading ahead, which isn't possible with a live stream

[Tell]

Thanks Simon is this just a general issue then that it doesn't support live streams. I was going to do a full search to see what anybody was saying about it online and I may refer it to the technical gurus that support the Humax box in their spare time. They will probably say told you so although they haven't told me that yet. So you never know they may join the thread. The gurus can't alter how the box works but embroider functionality around it via custom software loaded in the box.

On a positive note my Raspberry PI arrived, I installed the software and that is working with AAC playing on my Android ready to be transferred to the second location. A few minor teething problems since I hadn't used Linux or a Raspberry PI before but ambled through the screens and where it was putting stuff. So thank you for that. (I did build a computer from it's constituent parts in the 80s (ICs, resistors etc) with a soldering iron, ditto a text text decoder in the 70s... so clipping a case around a circuit board is a doddle in respects, kids have it easy now....).

[simoncn]

(27-02-2015 22:52)Tell Wrote:  Thanks Simon is this just a general issue then that it doesn't support live streams.

Yes, it appears to me that the Humax software was designed to play static disk files only and doesn't cater for playing live streams of unknown length that must be read sequentially in ascending byte order. If the gurus have any thoughts on this point, they are welcome to post them here.

[Tell]

I have another issue Simon on transcoding. Now I have installed Foobar 2000 with the upnp player on my laptop and the server running on the office machine with the MP3 translation parameters in order to check the translated bit rate

stream.convertor: C:\Program Files\FFMPEG\ffmpeg.exe
stream.transcode: aac:mp3

I would expect the AAC streams to give me a top notch MP3 sample rate but it isn't it is 128 kbps rather than 320 although the AAC is running at 320. I'm wondering whether when you called the FFMPEG library you may have picked it up at the default setting ?. I have used to different FFMPEG libraries in case the issue was coming from there but they both give me the same result.

[simoncn]

(02-03-2015 20:48)Tell Wrote:  I have another issue Simon on transcoding. Now I have installed Foobar 2000 with the upnp player on my laptop and the server running on the office machine with the MP3 translation parameters in order to check the translated bit rate

stream.convertor: C:\Program Files\FFMPEG\ffmpeg.exe
stream.transcode: aac:mp3

I would expect the AAC streams to give me a top notch MP3 sample rate but it isn't it is 128 kbps rather than 320 although the AAC is running at 320. I'm wondering whether when you called the FFMPEG library you may have picked it up at the default setting ?. I have used to different FFMPEG libraries in case the issue was coming from there but they both give me the same result.

I've just tried this and like you I'm surprised that ffmpeg doesn't use the sample rate of the input stream when encoding the output stream. It looks like MinimStreamer will need to detect the sample rate of the input stream and set this explicitly for the output stream.

[Tell]

Yes I'm gradually getting my head round these things now, the golden rule to me seems to be to unpack the encoded stream and then repack it to the level of quality you require require. 320 AAC is going to be 320 MP3 for sure. If one is keeping a recorded programme from say AAC audio or TV stream then you encode it to FLAC so you keep a replica of what it was like on the day and on a player that can handle FLAC you can always re-create what you recorded in AAC at the time.

So yes 320 would be 320 since you can't go higher in standard MP3, 192 AAC if such a thing exists on the BBC system would be probably 320 in MP3. So in MP3 you want that added level up lift from a table. There are tables of equivalence of AAC to MP3 on line so possible that up lift is required for live materiel. I normally do a rule of thumb guess.

Perhaps you could assume that all UK HLS streams will require 320 MP3. Whilst the non UK ones 48k and 96k you could put at 192 MP3 perhaps as a rule of thumb.

This is more desirable than a bit by bit rate matching since you need more for MP3 to package up what has been encoded in AAC which will inherently sound better at that bit rate.

[simoncn]

(03-03-2015 01:03)Tell Wrote:  Yes I'm gradually getting my head round these things now, the golden rule to me seems to be to unpack the encoded stream and then repack it to the level of quality you require require. 320 AAC is going to be 320 MP3 for sure. If one is keeping a recorded programme from say AAC audio or TV stream then you encode it to FLAC so you keep a replica of what it was like on the day and on a player that can handle FLAC you can always re-create what you recorded in AAC at the time.

So yes 320 would be 320 since you can't go higher in standard MP3, 192 AAC if such a thing exists on the BBC system would be probably 320 in MP3. So in MP3 you want that added level up lift from a table. There are tables of equivalence of AAC to MP3 on line so possible that up lift is required for live materiel. I normally do a rule of thumb guess.

Perhaps you could assume that all UK HLS streams will require 320 MP3. Whilst the non UK ones 48k and 96k you could put at 192 MP3 perhaps as a rule of thumb.

This is more desirable than a bit by bit rate matching since you need more for MP3 to package up what has been encoded in AAC which will inherently sound better at that bit rate.

It isn't as easy as I expected for MinimServer to detect the bitrate of the input stream and set the output bitrate to match. This is because MinimServer might need to read and analyse a significant amount of audio data from the input stream to calculate the bitrate.

I think the best solution is to provide a new MinimServer transcoding parameter to allow the user to set the bitrate to be used for encoding the output stream.

[Tell]

Simon that's a good solution .

[simoncn]

(03-03-2015 13:47)Tell Wrote:  Simon that's a good solution .

Now available in MinimStreamer 0.5.5.

[Tell]

Thanks.

I'll have a look. On a bit of self help at the minute since I messed up my Pi I think playing with parameters to enable Samba. It disabled MinimServer so I'm doing a complete restore with Noods on the SD card. I don't think it's your latest release since I can't edit. Think I'll retrench back from trying to be clever with Raspberry Pi and wanting Samba working which looking at the posts isn't straight forward.