LinuxQuestions.org - mplayer streaming PCM problems

- Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)

- - mplayer streaming PCM problems (https://www.linuxquestions.org/questions/linux-software-2/mplayer-streaming-pcm-problems-4175531396/)

mplayer streaming PCM problems

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)

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

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)

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