Why vlc works better with "rtsp://" than with SDP files ?

[sampsa]

Hello,

I get problematic (buggy?) behaviour when telling vlc to read media streams as instructed in a session description protocol (sdp) file.

I don't get the same problems when using the "rtsp://" protocol, even when having exactly the same parameters for the media streams as in the sdp files case.

I am working in a slightly "crowded" wlan network where rtp packet delay / reordering / loss is expected (the packets also probably arrive occasionally in "bursts")

It seems to me that "rtsp://" handles such situations much better than the "sdp" demuxer - although, as I understand it - they should work in identical way.

Let's look at the details (concrete questions are in the end of this message).


1) First scenario, use "rtsp://" to get stream from an ip cam:

vlc -vvv rtsp://user:passwd@ip

Terminal tells me:

...
0x7f62d8000b28] main video output warning: picture is too late to be displayed (missing 49 ms)
[0x7f62d8000b28] main video output debug: picture might be displayed late (missing 9 ms)
[0x7f62d8000b28] main video output warning: picture is too late to be displayed (missing 47 ms)
[0x7f62d8000b28] main video output debug: picture might be displayed late (missing 7 ms)
[0x188bf78] main audio output warning: playback way too late (180291): flushing buffers
[0x188bf78] pulse audio output debug: underflow
[0x188bf78] main audio output warning: playback way too early (-966775): playing silence
[0x188bf78] main audio output debug: inserting 46405 zeroes
[0x188bf78] main audio output warning: playback too early (-48841): down-sampling
[0x7f62d8000b28] main video output debug: picture might be displayed late (missing 1 ms)
...
[0x7f62d8000b28] main video output warning: picture is too late to be displayed (missing 331 ms)
[0x7f62d8000b28] main video output warning: picture is too late to be displayed (missing 291 ms)
[0x7f62d8000b28] main video output warning: picture is too late to be displayed (missing 251 ms)
[0x7f62d8000b28] main video output warning: picture is too late to be displayed (missing 211 ms)
[0x7f62d8000b28] main video output warning: picture is too late to be displayed (missing 171 ms)
...
[0x7f62d8000b28] main video output warning: picture is too late to be displayed (missing 2257 ms)
[0x188bf78] main audio output warning: buffer too late (-2022229 us): dropped
[0x188bf78] main audio output warning: buffer too late (-1982328 us): dropped
[0x188bf78] main audio output warning: buffer too late (-1942382 us): dropped
[0x188bf78] main audio output warning: buffer too late (-1902423 us): dropped
[0x188bf78] main audio output warning: buffer too late (-1862516 us): dropped
[0x188bf78] main audio output warning: buffer too late (-1822589 us): dropped
[0x188bf78] main audio output warning: buffer too late (-1782650 us): dropped
[0x188bf78] main audio output warning: buffer too late (-1742753 us): dropped
[0x188bf78] main audio output warning: buffer too late (-1662818 us): dropped
[0x188bf78] main audio output warning: buffer too late (-1622880 us): dropped
...

The video pixelates and freezes occasionally, but in the end, it always recovers and keeps on playing.


2) Second scenario: another routine/program negotiates the ports with the ip cam using rtsp, say, h264 video should arrive to port 50512 and pcm mulaw audio to port 50514. We launch vlc with:

vlc -vvv streamfile.sdp

where "streamfile.sdp" has:

v=0
o=- 0 0 IN IP4 127.0.0.1
s=No Name
c=IN IP4 127.0.0.1
t=0 0
m=video 50512 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1
m=audio 50514 RTP/AVP 0
a=rtpmap:0 PCMU/8000

After a short while, the terminal says:

...
[0x7fb384008bb8] main input debug: Buffering 99%
[0x7fb384008bb8] main input debug: Buffering 99%
[0x7fb384008bb8] main input debug: Buffering 99%
[0x7fb384008bb8] main input debug: Buffering 99%
[0x7fb384008bb8] main input debug: Stream buffering done (1809 ms in 3930 ms)
[0x7fb384008bb8] main input debug: Decoder buffering done in 0 ms
[0x7fb364000a48] main video output warning: picture is too late to be displayed (missing 112 ms)
[0x7fb364000a48] main video output warning: picture is too late to be displayed (missing 72 ms)
...
[0x7fb364000a48] main video output warning: picture is too late to be displayed (missing 148 ms)
[0x7fb364000a48] main video output warning: picture is too late to be displayed (missing 601 ms)
[0x7fb364000a48] main video output warning: picture is too late to be displayed (missing 1636 ms)
[0x7fb364000a48] main video output warning: picture is too late to be displayed (missing 789 ms)
[0x7fb370c38278] avcodec decoder error: more than 5 seconds of late video -> dropping frame (computer too slow ?)
...

and after doing this for a few times, the video freezes for forever. With the command

netstat -c --udp -an

I can see that data starts piling up to port 50512, i.e. vlc is not reading fast enough / at all from the port.


3) Third scenario: use some other media player to test case (2). If I use:

ffplay streamfile.sdp

It works perfectly..


I have tried scenarios (1) & (2) also with

--network-caching=1000 --aout alsa --alsa-audio-channels 1 --no-xlib --avcodec-hw any --avcodec-skip-frame=1 --avcodec-hurry-up --avcodec-fast


So, the concrete questions are:

A) Why is (1) so much more "sophisticated" than (2) ? (it does much more stuff according to the output, like "buffer too late .. dropped", etc.).
I also tried adding "a=rtcp:50503" into the sdp file (for rtcp syncing) but it did not have any effect.

B) Cases (1) and (2) should be equivalent.. where is the extra information hidden that makes the cases different..?

C) Are there any parameters that can be passed to vlc that make (2) work as well as (1) ?

[Jean-Baptiste Kempf]

That sounds like a bug in VLC live555 module.

[Tomasz_O]

That sounds like a bug in VLC live555 module.

Hi All,

I have exactly the same problem.
Are there any plans to fix the bug you mentioned about?

Regards,
Tomek

[kmf31]

I have noticed that (for me and my system in Linux) udp-streaming between vlc versions vlc-2.0.9 or similar works much better than with recent vlc versions (2.2.3 or similar).

Concerning these error messages:

[0x7f62d8000b28] main video output warning: picture is too late to be displayed (missing 331 ms)
[0x7f62d8000b28] main video output warning: picture is too late to be displayed (missing 291 ms)
[0x7f62d8000b28] main video output warning: picture is too late to be displayed (missing 251 ms)

one may try the option "--clock-synchro=0" and also increasing "--network-caching" to values of 1000, 2000 or even more. This helps a bit with me at least when vlc-2.2.3 is only streaming client (and vlc-2.0.9 the serveur). When vlc-2.2.3 is udp-streaming serveur than it is really bad and I don't have a clear understanding of this because with vlc-2.0.9 both as udp-streaming serveur and client there is no problem at all. Il also tried different caching parameters etc.
Theoretically this might be a question of "old" libararies in my system (in Linux) but just the upd-streaming modules don't use anything other than standard system libs (libc, libthread etc.) and the video streams only use ffmpeg (for codecs) and libdvbpsi (for ts-encapsulation) and for these two libraries one needs in any case different versions between vlc-2.0.9 and vlc-2.2.3 (otherwise vlc would not compile).

Concerning live555 one has of course to look here:
http://www.live555.com/
and report bugs there. Of course there is also the question of having the latest version of live555 installed (normally during compile time of vlc if one uses a static version of live555 which is the default).