Hi,
My live555-based RTSP video server is not working for multicast streams
when accessed from VLC via an RTSP URL such as:
rtsp://10.100.10.71:554/Stream0
When I use wireshark to view the IGMP packets I notice that the
following line is missing from the Session Description protocol returne
Hi,
My video encoder/server takes a PAL TV input, h.264 encodes it, and
streams it out on an RTP multicast stream to a decoder.
I am finding that the decoder output is somewhat erratic and not
decoding smoothly when compared to the original input to the encoder.
The decoder (3rd party) is b
S and video, as long as I can count on the frames always being in this
order. On a p-frame, I just need to advance the presentation time.
This seems very complicated compared to just calling gettimeofday()
every frame, am I missing something here?
Regards
David
On 2021-07-29 9:57 am, DJM-Avale
Hi Ross,
Connecting a RTSP client to receive a multicast RTP stream should not
change the RTP stream at all - so (unless you have a firewall
or other middlebox somewhere that is altering the RTP stream) there
must be a mistake in the way that your RTSP server application
is delivering this s
So, I suggest adding, to your server code, code that compares the value
of 'fPresentationTime" computed your new way,
with the value that would be computed by calling "gettimeofday()", and
print out the difference
Thanks, Ross. I assume you mean, if the new presentation time becomes
diffe
Hi,
My embedded video server outputs an H264 Multicast video stream at
25fps.
It is a requirement that multiple VLC client sessions join the stream
via ONVIF which results in an RTSP handshake to get the multicast SDP
details to join.
This works fine, however when each new client joins I
Hi Ross,
Apologies, I couldn't find that thread from last year for some reason. I
know it's not netiquette to resubmit the same question so could we
please consider this a continuation of that previous thread?
I had thought I'd reduced this issue to a negligible point but not so. I
had pat
Hi Ross,
OK, so we've established (again!) that your problem is that your
server's presentation times are not properly aligned with 'wall clock'
time
(the time that you'd get by calling "gettimeofday()"). This is
necessary because the periodic RTCP "SR" ("Sender Report") packets -
sent by t
So, this RTCP SR logic is calling gettimeofday() and changing
fPresentationTime outside of my control?
No, it's not setting your "fPresentationTime" at all. Only your code
does that. The "RTCP SR logic" is calling "gettimeofday()" to set the
timestamps in RTCP "SR" packets (that are use
