To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Issue with serving raw UDP transport streams using
testOnDemandRTSPServer
I have just installed a new version (2024.04.19) of the code that will likely
fix this problem.
Sometimes the PCR (timestamp) within a Trans
I have just installed a new version (2024.04.19) of the code that will likely
fix this problem.
Sometimes the PCR (timestamp) within a Transport Stream can jump by an
unexpectedly large amount. This was messing up the duration estimate that our
“MPEG2TransportStreamFramer” was computing - resu
That's good, thanks for the update.
Andy
From: live-devel on behalf of Ross
Finlayson
Sent: 18 April 2024 17:16
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Issue with serving raw UDP transport stre
Andy,
Thanks for the report. I was able to reproduce this problem, and am currently
working on tracking down the cause and coming up with a fix. Stay tuned…
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
___
live-devel mailing list
liv
TransportUDPServerMediaSubsession -> openRTSP
If you need any further information, please let me know.
Thanks as ever.
Andy
From: live-devel on behalf of Ross
Finlayson
Sent: 14 April 2024 16:11
To: LIVE555 Streaming Media - development & use
Subject:
> On Apr 10, 2024, at 8:01 AM, Andy Hawkins wrote:
>
> I made a small modification to the source for testOnDemandRTSPServer to
> specify that the input stream to a MPEG2TransportUDPServerMediaSubsession is
> 'raw' UDP and tested this against a multicast M2T stream. This seems to work
> fine,
Hi,
I made a small modification to the source for testOnDemandRTSPServer to specify
that the input stream to a MPEG2TransportUDPServerMediaSubsession is 'raw' UDP
and tested this against a multicast M2T stream. This seems to work fine, I can
connect multiple clients to the RTSP server and retri
