Hi there,

I have a receiver at home which can read internet radio streams via its network card, however the only format supported is mp3. I also happen to have a media server, which I use to stream my playlists to the receiver. Now there are a couple of radio streams I really would like to listen via my receiver, but these are all mp4a streams as reported by vlc. My project is to try converting them to mp3 streams on the fly, using my media server and re-stream to the receiver. I am aware of the fact that this might be a very CPU intensive task and not so efficient, but having invested about a week on this now, I just want to try and see it. I tried vlc for this, but the two versions I tried (0.8.6c and 0.9.3 Grishenko) failed to do the task. The first one actually successfully converted the stream to mp3, but the playback was reduced by half, so the stream converted to a slow motion one! The second one just produced noise (like modem noise) instead of a real stream. Therefore I am now trying to do this now as follows:



Now strangely, faad reports unsupported audio format with this line. It is version 2.6 and I am using Mandriva linux 2008.0 on the media server. Why would faad not support an mp4a stream? Did anybody encounter this before? Am I missing something?

Any pointers or alternative ideas will be greatly appreciated. Running an audio cable from the server to the receiver would be really hard, since the server is upstairs and the receiver is downstairs across another room .

I've done something similar to convert WMA to MP3.

I used the following sequence:

1. mplayer to receive the stream and write the raw PCM output to a named pipe.
2. LAME to convert to MP3, again to a named pipe.
3. ezsteam to pass MP3 stream to icecast.

However, I have no experience with mplayer and mp4.

NB: With the above, LAME took most CPU, but even then it was very minimal.

BTW, I started testing using VLC. I had to give up on it due to a bug causing a huge delay picking up MMS streams.

I was using --sout and transcode to get VLC to output the audio as MP3. I was using VLC's inbuilt icecast support to push it straight to my icecast server but you could output to named pipe or HTTP stream I guess.

http://wiki.videolan.org/Transcode

Thanks for the replies Synthetic Soul. mplayer, at least the version I have does not recognize the mp4a stream; I wish it did. As you recommended, I could get it work via a named pipe, but unfortunately it was not real-time, or in other words on the fly. vlc read the stream and wrote it to a named pipe first, then after a TERM signal faad converted it to wav, followed by lame converting it to mp3:

About the code above, "faad -w" option is really not doing its job, therefore I found this workaround to relay the output to stdout.

The following code seems to make vlc to output to stdout via an unnamed pipe, but then faad cannot read from the stdin:

faad returns "Error opening file: -"

Then I tried this:

It really looked like it was working, with vlc running and no error messages from faad, etc. but no test.mp3 was written at the end. I don't know what failed during the test run.
Part of this is probably because of my inexperience in coding.

Here is my final conclusion about this issue, in case anybody else is trying. In summary, when you record an mp4a stream, it is unreadable until the recording stops. That is probably because a moov box/atom is added only after completion of the recording process. That makes piping of mp4 files practically impossible, since decoders do not recognize the pipe in mp4 format without the moov box/atom in place.

Here is a link on this issue from vlc forums.

Regards.

In your post to the VLC forum you say:


I wouldn't have thought that this would depend on the source. I would have thought that, if the player can play the stream, then it should be able to transcode it. This is why I'm a little confused about your issue. Of course, I am likely to just be over-simplifying things.

Can you give an example source URI?

NB: I see your point about "on the fly", but I appeared to be getting very little latency using a named pipe. I don't really see a couple of seconds as an issue, as long as you get to hear what is being played. Bear in mind VLC or mplayer will buffer (by default) in any case.

Personally I don't think it is a distribution issue either. I think it is more likely a vlc version issue, but I just wanted to be very specific, that is why I included the OS type and version.



The example source URI is this. I have heard from other people a number of different scenarios, such as transcoding at normal speed but mono instead of stereo, etc. using vlc's transcode module.

I completely agree with you on latency issues, it is not really important. However, at least the script I wrote first launches vlc in the first line, supposedly piping into a named pipe, but it actually is not somehow, because of the mp4 moov box/atom issue I believe. The pipe remains at zero bytes throughout the whole streaming duration. The conversion string in the second line is executed only after vlc finishes its job, even if you direct the output to a file instead of named pipe. This is probably because of my lousy script, which causes much more than the latency you are talking about. I tried sending the vlc to the background by putting a '&' at the end of this line, but again, until the mp4 recorded is closed, faad or another session of vlc cannot decode or play this file. It is being recorded though, with the file increasing in size during the recording session, as opposed th the named pipe scenario.



Regards

I can get MPlayer to do this with a named pipe, using Debian.

Console 1:

Console 2:

The file "turk.mp3" appears fine to play.

I guess this really doesn't help you, if your MPlayer does not accept the stream. Frustrating. MPlayer reports itself as "MPlayer 1.0rc2-4.3.2-DFSG-free".

NB: I had no joy with VLC (testing on Windows). I was getting white noise with anything I tried.

My mplayer is playing the sample url without problems.
I'm using Debian Lenny and mplayer from marillat's repositories.
version: 1:1.0.rc2svn20080706-0.1
sourcelist: deb http://www.debian-multimedia.org lenny main
Try this one if the other doesn't work.

Many thanks to Synthetic Soul and PaJaRo,

My mplayer version seems to be MPlayer SVN-1.rc2.23.r28791.2mdv2009.0-4.3.2, which happens to be from backports repository. Although I don't use that repository for updates, somehow this package inserted itself as an update. When run to capture and decode the stream it reports the following:

It seems like this package of mplayer was compiled without faad support (neither faad2 nor libavcodec I believe). I down graded it back to MPlayer 1.0-1.rc2.18.2plf2009.0-4.3.2 and Wala!. It works like a charm now .

Synthetic Soul, I looked for lame documentation about some of the options you used (e.g. --signed, --little-endian) but could not locate them. Would you be so kind to point where to read about these ?

Once again, many thanks!

Great, I'm glad you've managed to find a resolve.

The LAME switches are described here: http://lame.cvs.sourceforge.net/*checkout*...ml/switchs.html

You can also just execute LAME --longhelp on the command line for a brief overview. Here's the (most) relevant section:


It sounds like you are totally fine as is; however I'll throw this out there in case anyone else tries this on a different flavour of Linux: when we set this up on a CentOS box we had to add the -x switch, otherwise we got white noise. This was obviously an endian issue, and could possibly have been solved by swapping --little-endian with --big-endian (which are listed on --longhelp but don't appear to be in the online docs).

Edit: MPlayer actually tells you the details of the output in this line:


The above was taken from the Debian output. s16le means "signed 16 bit little endian".

Me too, thanks to you! Thanks for the lame switches too, I thought it was weird that the man pages did not include them.

Well, what can I say, thank you again, because I was experimenting with my desktop when I reported the success yesterday, whereas my media server runs on Mandriva 2008.0 with an earlier version of mplayer. When I run the script that worked on my desktop, I got the white noise as the output, but I knew what exactly I should do; putting the -x switch helped me get rid of it immediately.

Just as a last remark, I also arbitrarily selected a cache size of 9 MB and cache-fill min ratio of 50 % before mplayer starts outputting, considering the speed of data transmission between Turkey and US might suffer at times.

Many thanks again, for helping me to find the resolution after days of work.