The VideoLAN Forums

Is it true that the VLC media player, when presented with audio of payload type L16 (code 11), assumes that it is at 44100 samples per second and ignores the sample rate given in the "a=rtpmap:11 L16/8000" SDP line?

Maybe? Did you look at the logs?

If you mean the Messages window, with verbosity level 2: it's not exactly a model of clarity, but I can see two occurrences of 44100, even though the SDP specifies 8000.

If you don't mean the Messages window: please tell me where I should be looking. It's the current Windows version of VLC media player - though I'm assuming that the problem is not platform specific.

After I posted the original question, I did another experiment: I crudely repeated every sample 5 times, so that I was generating 40000 samples per second. The audio came out slightly fast and with short gaps, which strongly suggests that VLCMP is replaying at 44100 samples per second.

I would be happy to use any non-compessed format at 8000 samples per second. However, VLCMP appears not to accept G.711 mu-law at all, and appears to assume that L16 is at 44100 samples per second. I haven't tried G.711 A-law yet, though it's a fair bet that, if it doesn't accept mu-law, it doesn't accept A-law either. I am not aware of any other 8000 samples per second formats.

File a bug with your logs from the Message Windows, AFTER having tried VLC 1.2.0 from Nightly Build of VLC

Is it true that the VLC media player, when presented with audio of payload type L16 (code 11), assumes that it is at 44100 samples per second and ignores the sample rate given in the "a=rtpmap:11 L16/8000" SDP line?

VLC does not parse the SDP so far.This is entirely up to what your version of (lib)live555 does. I would expect it supports any sample rate. Then again, remapping static payload types dynamically via SDP is a very bad idea for interoperability; and maybe live555 does not support it. You should really use payload types from 96 upward.

Then again, remapping static payload types dynamically via SDP is a very bad idea for interoperability; and maybe live555 does not support it. You should really use payload types from 96 upward.

You raise an interesting point... but I'm not convinced.

If payload type 11 completely specified the stream, including the sample rate, there would be no point in having an rtpmap line; it would be completely tautologous. As far as I can see from the RFCs I've found, there is nothing set in stone to say that payload type 11 must always be at 44100 samples per second. But if you know differently, please tell me!

Anyway, assuming you're correct: I've tried payload type 96 specified either as "a=rtpmap:96 L16/8000" or as "a=rtpmap:96 L16/8000/1". Both result in a message that ends in "Unknown codec name for payload type 96". Is there a different name I should use for 16 bit LPCM?

Perhaps VLCMP needs a codec name that specified the endian-ness too?

Is there any other codec name and type that I can use for 8000 samples per second, that VLCMP understands?

Then again, remapping static payload types dynamically via SDP is a very bad idea for interoperability; and maybe live555 does not support it. You should really use payload types from 96 upward.

You raise an interesting point... but I'm not convinced.

If payload type 11 completely specified the stream, including the sample rate, there would be no point in having an rtpmap line; it would be completely tautologous. As far as I can see from the RFCs I've found, there is nothing set in stone to say that payload type 11 must always be at 44100 samples per second. But if you know differently, please tell me!

The RTP/AVP specification states that, payload type 11 is L16/44100/1, while dynamic payload types are in the 96-127 range: http://tools.ietf.org/html/rfc3551#section-6

The SDP specification allows omitting a=rtpmap for static payloads. It does not explicitly allow using static or unassigned types dynamically:
http://tools.ietf.org/html/rfc4566#section-6 As such, you should stick to the dynamic range for dynamic payloads, lest you have some interoperability problems. As a practical example, VLC will misinterpret the data if told to open an RTP stream as rtp://@IP_ADDRESS:PORT_NUMBER with dynamically overloaded static payload types, while it will just fail safe for dynamic payload types.

Anyway, assuming you're correct: I've tried payload type 96 specified either as "a=rtpmap:96 L16/8000" or as "a=rtpmap:96 L16/8000/1". Both result in a message that ends in "Unknown codec name for payload type 96". Is there a different name I should use for 16 bit LPCM?

That error comes from liblive555, not from VLC. It simply means your live555 library version does not support L16 decapsulation. You will need to update it. VLC supports L16 since version 0.7.0.

Perhaps VLCMP needs a codec name that specified the endian-ness too?

L16 is always big-endian.

Is there any other codec name and type that I can use for 8000 samples per second, that VLCMP understands?

If you mean static payload types, there iare PCMU and PCMA, i.e. A-law and µ-law.

OK, thanks.

I had already discovered that µ-law works. It was the first format I tried; I couldn't get it to work, though I don't know whether that was the fault of the previous version of VLCMP I had (I upgraded to 1.1.10 this morning) or of something else I did. Now I have confirmed that µ-law works, that's the way I will go forward.

Thanks!