Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: stream conversion on the fly (Read 13393 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

stream conversion on the fly

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:

Code: [Select]
cvlc http://xx.xx.xxx.x:8875 -pipe | faad -f 2 -w | lame - - | some-kind-of-streaming-application-here


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  .

stream conversion on the fly

Reply #1 –
I've done something similar to convert WMA to MP3.

I used the following sequence:
  • mplayer to receive the stream and write the raw PCM output to a named pipe.
  • LAME to convert to MP3, again to a named pipe.
  • 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.
I'm on a horse.

stream conversion on the fly

Reply #2 –
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
I'm on a horse.

stream conversion on the fly

Reply #3 –
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:
Code: [Select]
mkfifo test_pipe
cvlc http://xx.xx.xxx.x:8875 --sout '#duplicate{dst=std{access=file,mux=mp4,dst=test_pipe}}'
faad -o - test_pipe|lame -V2 - test.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:
Code: [Select]
cvlc http://xx.xx.xxx.x:8875 --sout '#duplicate{dst=std{access=file,mux=mp4,dst=-}}' | faad -o - | lame -V2 - test.mp3

faad returns "Error opening file: -"

Then I tried this:
Code: [Select]
cvlc http://xx.xx.xxx.x:8875 --sout '#duplicate{dst=std{access=file,mux=mp4,dst=-}}' | faad -o - <- | lame -V2 - test.mp3

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.

stream conversion on the fly

Reply #4 –
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.

stream conversion on the fly

Reply #5 –
In your post to the VLC forum you say:

Quote
None of the transcode options vlc is capable of works for mp4a stream with the vlc version that came with Mandriva 2009.0 (0.9.3 Grishenko), in case anybody else was trying.

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.
I'm on a horse.

stream conversion on the fly

Reply #6 –
Quote from: Synthetic Soul on
...
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.


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.

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


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.

Code: [Select]
#!/bin/bash
#cvlc http://xx.xx.xxx.x:8875 --sout '#duplicate{dst=std{access=file,mux=mp4,dst=-}}' | faad -o - - | lame -V2 - test.mp3 --doesn't work
rm test_pipe
killall -9 vlc
mkfifo test_pipe
cvlc http://xx.xx.xxx.x:8875 --sout '#duplicate{dst=std{access=file,mux=mp4,dst=test_pipe}}'
faad -o - test_pipe | lame -V2 - test.mp3


Regards

stream conversion on the fly

Reply #7 –
I can get MPlayer to do this with a named pipe, using Debian.

Console 1:
Code: [Select]
mkfifo /tmp/turk.wav
mplayer -vo null -vc null -ao pcm:fast:nowaveheader:file=/tmp/turk.wav http://94.75.222.9:8875

Console 2:
Code: [Select]
lame -r --signed --little-endian -s 44.1 --bitwidth 16 --noreplaygain --silent -b 96 /tmp/turk.wav /tmp/turk.mp3

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.
I'm on a horse.

stream conversion on the fly

Reply #8 –
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.

stream conversion on the fly

Reply #9 –
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:
Code: [Select]
... AAC file format detected...
Trying to force audio codec driver family libmad...
Requested audio codec family [faad] (afm=faad) not available.
Enable it at compilation.
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
[aac @ 0xa8f7600]Implicit channel configuration is not implemented. Update your FFmpeg version to the newest one from SVN. If the problem still occurs, it means thatyour file has a feature which has not been implemented.
Could not open codec.
ADecoder init failed :(
ADecoder init failed :(
Cannot find codec for audio format 0x4134504D.

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!

stream conversion on the fly

Reply #10 –
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:

Code: [Select]
  Input options for RAW PCM:
    -r              input is raw pcm
    -x              force byte-swapping of input
    -s sfreq        sampling frequency of input file (kHz) - default 44.1 kHz
    --bitwidth w    input bit width is w (default 16)
    --signed        input is signed (default)
    --unsigned      input is unsigned
    --little-endian input is little-endian (default)
    --big-endian    input is big-endian

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:

Code: [Select]
PCM: Samplerate: 44100Hz Channels: Stereo Format s16le

The above was taken from the Debian output.  s16le means "signed 16 bit little endian".
I'm on a horse.

stream conversion on the fly

Reply #11 –
Quote from: Synthetic Soul on
Great, I'm glad you've managed to find a resolve.

Me too, thanks to you! Thanks for the lame switches too, I thought it was weird that the man pages did not include them.
Quote
...
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).
...

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.