The VideoLAN Forums

We have an IP camera which we're doing development work on, it streams live H.264 over RTSP using the same streaming engine as VLC (Live555/WIS-Streamer, latest version 2015.12.22). We're using VLC 2.2.1 Terry Pratchett (Weatherwax).

We have found a REALLY perplexing problem though, and I'm hoping someone here may have seen this before and know what's going on.

Basically, if the time (wall clock time) in the camera is set to certain times, VLC will not play the stream - it will play the first few seconds, then the screen goes grey and eventually it times out. Other times, it will play fine, faultlessly.

I'm still trying to work out what the relationship may be between the system time of the PC VLC's running on and the system time of the camera - it's not down to time difference as I can set the camera time to exactly the same as the PC time and at different times of the day it will work or fail, likewise I can set the two systems to very different times and some will play and some won't.

We can see nothing different in the camera's RTSP stream, no errors, jumps, etc. and other tools such as mPlayer will play the stream perfectly. If I stream the video to a file using openRTSP, VLC will then play it quite happily!

I realise that this at least as likely to be "our" problem as VLC's, as everyone has a different reading of the RFC's when it comes to video + streaming, I was mostly just hoping someone might've seen this sort of behaviour before. Any suggestions at all would be welcome!

I can post stream data and wireshark logs if needed but obviously that can get a bit cumbersome.

Here's VLC's message logs for streaming, this is a "working" stream: And this is a non-working stream:

Even more curiouser it works flawlessly if we set the camera to multicast.

It seems to be related to the time in the camera (so camera wall-clock time Vs RTSP-timestamp) rather than the wall-clock time in the PC Vs Camera.

Maybe camera is sending incorrect RTCP SR compounds?

even in that case

We can see nothing different in the camera's RTSP stream, no errors, jumps, etc. and other tools such as mPlayer will play the stream perfectly. If I stream the video to a file using openRTSP, VLC will then play it quite happily!

We're using VLC 2.2.1 Terry Pratchett (Weatherwax).

I can post Wireshark captures of both working + not working, or just a dump of the SR's, what would be the most useful?

Some test results created as follows:

Wireshark set running...
Camera time set to ~9am, stream started, plays fine.

Here's the SR and RR's sent during that working stream:
(summary from Wireshark)




Here's the SR and RR's sent during that non-working stream:
(summary from Wireshark)

Anything else I can do to move this along? We really need to work out what's going on and what we can do about it.

Hi,

i think my recent post is a bit related:

https://forum.videolan.org/viewtopic.php?f=2&t=130841

I have had these problems ("buffering 0%" or "video 5 secs too late") for a long time in a number of situations.

I think it is because of corrupted RTCP timestamps (you did not provide any resumen of our wireshark tests, btw.. dont feel like reading all that output). If you disable RTCP timestamps, then I think, you will force vlc (and its live555 component) to default to plain RTP timestamps and your problems might disapperar.

(you did not provide any resumen of our wireshark tests, btw.. dont feel like reading all that output)

Do you mean I didn't summarise the wireshark data? If you read back I did ask what form I should post data, which information I might filter out etc. to be most useful & readable but got no answer. If you want the data in ANY form I will gladly provide it, just ask!

I think it is because of corrupted RTCP timestamps. If you disable RTCP timestamps, then I think, you will force vlc (and its live555 component) to default to plain RTP timestamps and your problems might disapperar.

I'm pretty sure our RTCP timestamps are OK, as mentioned our streamer uses the latest Live555 streamer and we can't see any obvious errors in what we're sending. If you mean the problem is with VLC then breaking our stream to appease buggy software seems like a poor solution.

I've noticed that when VLC fails to play the stream, the time counter at the bottom left gets stuck a few seconds in, always something like 00:03 or 00:10, whereas when it runs OK it seems to get a different time after a few seconds, like 2:56:30 or 4:23:12, I'm not sure where that number is coming from (which timestamp information it uses to generate that)?

I think the point is that debugging your problem sounds tedious, if at all possible without your stream. And then, it is unlikely that someone (else) will volunteer their time and make the effort to investigate it.

Rémi, are you saying I should post the raw stream data downloaded by VLC or something like that? As I keep saying, if there is ANYTHING I can provide that will help diagnose this I will happily provide it, but I don't want to spend hours capturing & uploading data that is of no use or "too tedious" for people to look at.

Sorry, I don't have motivation and free time to solve your problem, and possibly not the expertise either.

if there is ANYTHING I can provide that will help diagnose this I will happily provide it, but I don't want to spend hours capturing & uploading data that is of no use or "too tedious" for people to look at.

this will save that time
Should you need timely and/or professional support, you will need to ​fix the problem yourself or to hire a ​consultant.

I appreciate that this is a free forum and that people have other things to do (so do I), but this is the VLC Support forum so I'm just trying to ask politely for a bit of support and avoid spamming a huge data-dump which some would consider anti-social and unhelpful. That's what I mean by not wanting to spend hours capturing useless data - I don't want to waste YOUR time reading it if it's of no use.

So far I haven't had an answer to what data I should post that would be useful to anyone who may be willing & able to help me, it seems like Remi may have an idea on that but is not willing to share it I'm sorry but I don't get it, why post that you won't help but don't tell me your idea on what I should have posted?

If I were to debug, I would want a working link with which to reproduce the problem, or else a packet capture. But that's just me. You should first find somebody to help you before you ask what s/he needs.