VLC fails to read legitimate sdp files (even files generated by VLC itself)

[sampsa]

Hello,

I have serious problems in reading sdp information for RTP sessions. Here are two quick tests that demonstrate them:

1) Generate an .sdp file with VLC. It seems that VLC fails to read sdp files it has generated by itself..! This example is easy to try @home (confirming this bug(?) takes ~ 1 minute).

Let's send a screencast to port 50001 of the localhost:

cvlc screen:// --avcodec-hw any -vvv --sout-rtp-sdp="file:///home/sampsa/kokkelis.sdp" --sout '#transcode{vcodec=h264,acodec=none,vb=2048,mux=ts,fps=5}:rtp{dst=127.0.0.1,port=50001}'

(one can also skip "mux=ts")

The session description file appears in "/home/sampsa/kokkelis.sdp"

Then, while that screencast is running, open another vlc instance with

vlc -vvv kokkelis.sdp

Does not work at all.. the output gives:

...
0x7ff370003ae8] live555 demux debug: version 2014.01.13
[0x7ff370003ae8] live555 demux debug: RTP subsession 'video/H264'
[0x7ff364008b78] main input debug: selecting program id=0
[0x7ff370003ae8] live555 demux debug: setup start: 0.000000 stop:0.000000
[0x7ff370003ae8] live555 demux debug: play start: 0.000000 stop:0.000000
[0x7ff370003ae8] main demux debug: using demux module "live555"
[0x7ff364008b78] main input debug: looking for a subtitle file in /home/sampsa/
[0x7ff370c25f18] main decoder debug: looking for decoder module matching "any": 39 candidates
[0x7ff370c25f18] avcodec decoder debug: trying to use direct rendering
[0x7ff370c25f18] avcodec decoder debug: allowing 4 thread(s) for decoding
[0x7ff370c25f18] avcodec decoder debug: avcodec codec (H264 - MPEG-4 AVC (part 10)) started
[0x7ff370c25f18] avcodec decoder debug: using frame thread mode with 4 threads
[0x7ff370c25f18] main decoder debug: using decoder module "avcodec"
[0x7ff370c38d08] main packetizer debug: looking for packetizer module matching "any": 21 candidates
[0x7ff370c38d08] packetizer_h264 packetizer debug: found NAL_SPS (sps_id=0)
[0x7ff370c38d08] packetizer_h264 packetizer debug: found NAL_PPS (pps_id=0 sps_id=0)
[0x7ff370c38d08] main packetizer debug: using packetizer module "packetizer_h264"
[0x7ff370db6598] main demux meta debug: looking for meta reader module matching "any": 2 candidates
[0x7ff370db6598] lua demux meta debug: Trying Lua scripts in /home/sampsa/.local/share/vlc/lua/meta/reader
[0x7ff370db6598] lua demux meta debug: Trying Lua scripts in /usr/lib/vlc/lua/meta/reader
[0x7ff370db6598] lua demux meta debug: Trying Lua playlist script /usr/lib/vlc/lua/meta/reader/filename.luac
[0x7ff370db6598] lua demux meta debug: Trying Lua scripts in /usr/share/vlc/lua/meta/reader
[0x7ff370db6598] main demux meta debug: no meta reader modules matched
[0x7ff364008b78] main input debug: `file:///home/sampsa/kokkelis.sdp' successfully opened
[0x167f468] qt4 interface debug: IM: Setting an input
[0x7ff370003ae8] live555 demux error: no data received in 10s, aborting
...

We can dirty-test that there is stuff coming from the socket with ..

vlc -vvvv udp://@127.0.0.1:50001

.. which tells that there is data coming out indeed (this is not a network problem)


2) Generate .sdp file with another program

ffmpeg -f x11grab -s 1920x1080 -r 25 -i :0.0 -vcodec libx264 -f rtp rtp://127.0.0.1:50001

FFmpeg sprouts the SDP info on the screen by default ..

v=0
o=- 0 0 IN IP4 127.0.0.1
s=No Name
c=IN IP4 127.0.0.1
t=0 0
a=tool:libavformat 56.4.101
m=video 50001 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1

.. I edit that into a file (and yes, I have tried substituting the enters with "\r\n") and launch VLC:

vlc -vvv gen.sdp

I get the same problem as in (1).

One can again confirm (see above) that this is not a network problem.

- Can you confirm this behaviour (I am using VLC 2.1.6) ?
- UPDATE: I have confirmed this behaviour also in VLC 2.2.x.
- Is this a bug or what?
- What am I doing wrong, if any?


Regards,

Sampsa


P. S. Found this one:

http://stackoverflow.com/questions/1480 ... -using-vlc

It claims that VLC does not care about the port specified in the sdp file (=bug). Is this so?

P. S. S. Maybe this bug is back from the dead..?

https://trac.videolan.org/vlc/ticket/7772

[Rémi Denis-Courmont]

VLC 2.1.6 is no longer supported.

[sampsa]

Exactly same problem occurs also in 2.2.x

[Rémi Denis-Courmont]

live555 complains that it receives no data. If the problem is the same with FFmpeg as the source, then it's likely a live555 bug. In that case, you are at the wrong venue.

[sampsa]

.. and if I go to the live555 forum, they will tell me that it is VLC's fault, right?

It could actually be that VLC does not pass the information correctly to live555.

.. so, should I file a bug report to VLC, to live555 or both?

[Rémi Denis-Courmont]

You have all the data, and we have none. You figure it out.

[sampsa]

Dear Remi,

The bug (and the data) is trivial to reproduce as I demoed in the original question - did you give it a try..?

I'm just wondering if I should ..

1) File a VLC bug report with the example producing the bug
2) Compile latest VLC from the source and figure the bug out by myself
3) Do both (1) and (2)

[sampsa]

Live555, file "MediaSession.cpp" has the following line ..

if (protocolIsRTP && !fMultiplexRTCPWithRTP) {
fClientPortNum = fClientPortNum&~1;
// use an even-numbered port for RTP, and the next (odd-numbered) port for RTCP
}

I changed in the above examples, the port number to even and that seemed to do the trick..!

So it was, instead of RTFM, only RTFSC

[Jean-Baptiste Kempf]

Live555, file "MediaSession.cpp" has the following line ..

if (protocolIsRTP && !fMultiplexRTCPWithRTP) {
fClientPortNum = fClientPortNum&~1;
// use an even-numbered port for RTP, and the next (odd-numbered) port for RTCP
}

I changed in the above examples, the port number to even and that seemed to do the trick..!

So it was, instead of RTFM, only RTFSC

Did you submit the patch?

[sampsa]

nope

[Rémi Denis-Courmont]

The rule is:
- if RTCP is not muxed and the SDP port is even, then the RTP port is the SDP port and the RTCP port is the SDP port plus one,
- if RTCP is not muxed and the SDP port is odd, then the RTP port is the SDP port plus one and the RTCP port is the SDP port,
- if RTCP is muxed, then the RTP port and the RTCP port are both equal to the SDP port.