mplayer streaming PCM problems

horde · 01-18-2015, 05:43 AM

Not sure where to put this question (as so many questions start off) but I'm posting some information tonight just in case I'm overlooking something obvious.

I have been capturing the BBC radio stream using mplayer/lame and was intending to capture 170 minutes of stream. the first three nights the mp3 produced all stopped after they had captured 95,110Kb of information (about 1:41:27 of stream - so nowhere near the 170 mins I expected).

Basically the command I used was:

Code:

mplayer -cache 1024  mms://wmlive-nonacl.bbc.net.uk/wms/bbc_ami/radio1/radio1_bb_live_int_eq1_sw0 -vc null -vo null -ao pcm:file=/dev/fd/3 3>&1 2>logs/test.log 1>&2 | lame -h  - /mediaData/Family/Music/BBCRadio/x.mp3

However if I split it into 2 commands :

Code:

mplayer -cache 1024  mms://wmlive-nonacl.bbc.net.uk/wms/bbc_ami/radio1/radio1_bb_live_int_eq1_sw0 -vc null -vo null -ao pcm:file=/mediaData/Family/Music/BBCRadio/x.wav 2>logs/test.log 1>&2

This produced a file 3.7Gb big when I cancelled it

I then then followed it with:

Code:

lame -h --nohist /mediaData/Family/Music/BBCRadio/x.wav  /mediaData/Family/Music/BBCRadio/x.mp3

and this produced a file 170,659Kb in size (about 3:02:02 in length).

From the above I assume both mplayer and lame are capable of processing lareg streams/files by themselves and so it must be the combining them that causes the problem.

I also did another test where I converted the larger file down to about 2G in size using:

Code:

head -c 2G /mediaData/Family/Music/BBCRadio/x.wav >/mediaData/Family/Music/BBCRadio/x2.wav

and then ran lame on this file. It produced a file that was 94,692kb in size (just under the size where the piped stream conversion stops), which perhaps indicates that I'm hitting some sort of 2G pipe limit - but I'm open to any suggestions.

I'm running openSuSe 13.2 64 bit, LAME 3.99.5 64bits, and MPlayer -4.8.

My limits are set as:

Code:

ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 10990
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 10990
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Any suggestions would be much appreciated as I haven't found any information on piping size limitations (but maybe that is just my searching ability)

horde · 01-18-2015, 09:55 PM

Just a follow up. I now dont believe it is a pipe issue as such. I ran the following:

Code:

cat /mediaData/Family/Music/BBCRadio/x.wav | lame -h --nohist - /mediaData/Family/Music/BBCRadio/x4.mp3
LAME 3.99.5 64bits (http://lame.sf.net)
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding <stdin> to /mediaData/Family/Music/BBCRadio/x4.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III (11x) 128 kbps qval=2

and that worked fine - it processed all 3G of data.

Perhaps it's an issue with

Code:

pcm:file=/dev/fd/3

horde · 01-19-2015, 08:46 PM

ok - moving along.

If I run this:

Code:

 mplayer -cache 1024  mms://wmlive-nonacl.bbc.net.uk/wms/bbc_ami/radio1/radio1_bb_live_int_eq1_sw0 -vc null -vo null -ao pcm:file=/dev/fd/3 3>&1 2>logs/test.log 1>&2 | cat >/mediaData/Family/Music/BBCRadio/x6.wav

and then go and open up VLC, VLC shows that the length of the wav file is 1 hr 41 mins (even after 6 secs of recording so it looks like the header is specifying the limit and then lame is just working to that limit.

I have seen NOWAVEHEADER as an option somewhere (and I think I have tried it but will test again)

horde · 01-21-2015, 06:01 PM

OK - next stage. As far as I can tell if mplayer puts out the PCM file with a header then the generated file will will have a default length of 2Gb - which lame then accepts and will only process that much stream data. If I put NOWAVEHEADER on mplayer and the -r option on LAME I am expected to provide all of the necessary header information to LAME to allow it to decode.

To get the header information I got mplayer to generate a file directly with WAVEHEADER using the following:

Code:

mplayer -cache 1024  mms://wmlive-nonacl.bbc.net.uk/wms/bbc_ami/radio1/radio1_bb_live_int_ep1_sl0 -vc null -vo null -ao pcm:waveheader:file=/mediaData/Family/Music/BBCRadio/x7.wav

and then used soxi and mediainfo to display the format:

Code:

kevin@mediaserver:~> mediainfo /mediaData/Family/Music/BBCRadio/x7.wav
General
Complete name                            : /mediaData/Family/Music/BBCRadio/x7.wav
Format                                   : Wave
File size                                : 13.4 MiB
Duration                                 : 39s 938ms
Overall bit rate mode                    : Constant
Overall bit rate                         : 2 822 Kbps

Audio
Format                                   : PCM
Format profile                           : Float
Codec ID                                 : 3
Codec ID/Hint                            : IEEE
Duration                                 : 39s 938ms
Bit rate mode                            : Constant
Bit rate                                 : 2 822 Kbps
Channel(s)                               : 2 channels
Sampling rate                            : 44.1 KHz
Bit depth                                : 32 bits
Stream size                              : 13.4 MiB (100%)


kevin@mediaserver:~> soxi /mediaData/Family/Music/BBCRadio/x7.wav
soxi WARN wav: wave header missing extended part of fmt chunk

Input File     : '/mediaData/Family/Music/BBCRadio/x7.wav'
Channels       : 2
Sample Rate    : 44100
Precision      : 24-bit
Duration       : 00:00:39.94 = 1761280 samples = 2995.37 CDDA sectors
File Size      : 14.1M
Bit Rate       : 2.82M
Sample Encoding: 32-bit Floating Point PCM

Lame will encode this file to mp3 flawlessly so I generated another file (NOWAVEHEADER) and ran lame as:

Code:

lame  --nohist -r --signed -m s  --verbose -s 44.1 --bitwidth 32 -b 128 /mediaData/Family/Music/BBCRadio/x7.wav /mediaData/Family/Music/BBCRadio/x7.mp3
Assuming raw pcm input file
LAME 3.99.5 64bits (http://lame.sf.net)
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding /mediaData/Family/Music/BBCRadio/x7.wav
      to /mediaData/Family/Music/BBCRadio/x7.mp3
Encoding as 44.1 kHz stereo MPEG-1 Layer III (11x) 128 kbps qval=3

misc:

        scaling: 0.95
        ch0 (left) scaling: 1
        ch1 (right) scaling: 1
        huffman search: best (outside loop)
        experimental Y=0
        ...

stream format:

        MPEG-1 Layer 3
        2 channel - stereo
        padding: off
        constant bitrate - CBR
        using LAME Tag
        ...

psychoacoustic:

        using short blocks: channel coupled
        subblock gain: 1
        adjust masking: 0 dB
        adjust masking short: 0 dB
        quantization comparison: 9
         ^ comparison short blocks: 9
        noise shaping: 2
         ^ amplification: 1
         ^ stopping: 1
        ATH: using
         ^ type: 4
         ^ shape: 4 (only for type 4)
         ^ level adjustement: -3 dB
         ^ adjust type: 3
         ^ adjust sensitivity power: 1.000000
        experimental psy tunings by Naoki Shibata
           adjust masking bass=-0.5 dB, alto=-0.25 dB, treble=-0.025 dB, sfb21=0.5 dB
        using temporal masking effect: yes
        interchannel masking ratio: 0.0002
        ...

    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
  1530/3059   (50%)|    0:01/    0:03|    0:03/    0:07|   20.820x|    0:03
Writing LAME Tag...done
ReplayGain: -12.3dB

The file that gets generated has incredible static over the top of the radio stream - nothing at all like the file generated from the 'HEADERED' file. Everything looks good but I have a feeling that the -m s may not be signalling thatthe input isa 2 channel stream but I cant find a parameter to set that.

Time to pause and think about next steps but I'm thinking that transcoding on the fly for streams greater than 100 mins will just refuse to work

also tried --bigendian and -x and --bitwidth 24 all of which gave worse results