[Live-devel] Play out PCR from gettimeofday rather than source stream?
Hi, I have created a modified version of testMPEG2TransportStreamer which will play out a carousel of SPTS files to a multicast address - and it works extremely well except.. The problem that I have encountered is that the output stream contains PCR information from the input source source files, so when one file closes and the next starts playout, PCR does a time-warp back to zero. The net effect of this is attached set-top boxes attempt to adapt however (and I'm guessing here) they pixellate a second or two after the transition and I assume this is because they are playing out their buffer and then briefly panic because something weird has happened to the PCR. So my bright idea was to rather than play out the PCR from the source file, replace it with a PCR derived from gettimeofday. I realise the PCR playout timing might be a little bumpy at transition from one source file to another, however so long as the PCR isn't time warping, I think the mux chain and STBs will cope. I see that timeNow is already stood up in in MPEG2TransportStreamFramer.cpp - is there a quick and dirty way to insert PCR based on this time, at time of playout, rather than pass through the source PCR? Thanks and regards, Tim Shackleton ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Play out PCR from gettimeofday rather than source stream?
Re: [Live-devel] Play out PCR from gettimeofday rather thaHi Ross, Thanks for your reply. You are quite right, the PCR is always more accurate straight out of an encoder, so I have shelved that desperate idea which as it turns out wasn't a problem anyway. I have been inspecting the clips produced by our Bitpack encoder and they do indeed have the discontinuity_indicator set on the first video packet, so there are no CC errors or PCR problems on our PID273, being video. However, when we change clips, we are registering CC errors on PID 0, 64 and 40, being PAT, PMT and Audio respectively. Should the first packet in the clips for these pids contain an adaptation field with discontinuity_indicator true also? Incidentally, when I was chasing the PCR accuracy 'problem', I have noted that under default settings for MAX_PLAYOUT_BUFFER_DURATION (being 0.1s) the PCR jitter is seen at about 35ns, and we do from time to time experience pixellation at broadcast output, however when I reduce this buffer to 0.01s, the jitter is reduced to 16ns and any pixellation during clip playout is gone. I don't understand why that setting should affect the packet presentation timing as the naming of that var would imply to me the length of a FIFO more than anything else. To solve this clip change problem I am now leaning toward the idea of keeping an array of incrementing CC per PID, and playing that out - OR, if the non-PCR carrying PIDs should have the discontinuity_indicator flag when they first occur in a clip, inspecting the clips and adjusting them accordingly. Looking forward to your comments, Thanks, -Tim - Original Message - From: Ross Finlayson To: LIVE555 Streaming Media - development & use Sent: Tuesday, March 22, 2011 1:00 PM Subject: Re: [Live-devel] Play out PCR from gettimeofday rather than source stream? I see that timeNow is already stood up in in MPEG2TransportStreamFramer.cpp - is there a quick and dirty way to insert PCR based on this time, at time of playout, rather than pass through the source PCR? No, not really, and this is a bad idea anyway. The PCR values that were inserted in the files at the time that they were encoded will always be more accurate (and better for decoders to use) than values derived from 'gettimeofday()'. Instead, you should make sure that your TS files have the 'discontinuity_indicator' flag set at the start. Our "MPEG2TransportStreamFramer" code recognizes this flag, as should the decoder in your STB. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -- ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
[Live-devel] Opportunity for unpredictable behaviour in MPEG2TransportStreamFramer
Hi Ross, I have been working on a DeviceSource that I'm feeding into an RTP sink via the MPEG2TransportStreamFramer. The DeviceSource never runs out of data to provide the framer, so it runs for extended periods of time. What I am finding is that after a reasonable period of operation, suddenly the task starts spitting out MPEG frames as fast as the network can carry them. It's as though the framer is incorrectly calculating the playout rate required... I have noticed that such vars as fTSPCRCount, fTSPacketCount, lastPacketNum and so forth are unsigned ints giving them a wrapping capacity of 4 and a bit billion. If a wrap happens, I am expecting the calculations to become wildly wrong. I have stood up a separate instance of the live555 source tree exchanging the variables involved to doubles in order to see if the spurious behavior stops. A hack rather than a fix, I know. If this wrap is in fact causing the issue, would you consider it a bug? If so, is this something you would prefer to address in a later release or something I should provide a patch for? Thanks again for your hard work and patience. Regards, Tim ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Opportunity for unpredictable behaviour in MPEG2TransportStreamFramer
On 17/10/11 17:54, Ross Finlayson wrote: Yes, but are you sure that a wrap-around is, in fact happening (and is the cause of your problem)? A rough calculation shows that - at 10 Mbps - the "fTSPacketCount" variable (which counts 188-byte Transport Stream 'packets') will wrap around in around 7 days. But anyway, if this is a plausible occurrence, then it's probably something we should allow for. Fantastic. I am going to run side by side binaries, one with the existing unsigned, and one with the u_int64_t. I have been playing out content with a mux rate of 8,000kbit/sec and I was seeing the problem occur after about a week and a half and by my math that seems to agree with a calculated value of 9.3 days. I note that using u_int64_t that will extend the wrap time from 9.3 days to 109 million years, which should comfortably exceed the lifetime of most things. I think I feel quite comfortable with this as a fix. :-) I will respond with my results next week, when I expect the issue to manifest on the unpatched version. Thanks and regards, Tim ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Opportunity for unpredictable behaviour in MPEG2TransportStreamFramer
On 18/10/11 09:14, Tim J Shackleton wrote: On 17/10/11 17:54, Ross Finlayson wrote: Yes, but are you sure that a wrap-around is, in fact happening (and is the cause of your problem)? A rough calculation shows that - at 10 Mbps - the "fTSPacketCount" variable (which counts 188-byte Transport Stream 'packets') will wrap around in around 7 days. But anyway, if this is a plausible occurrence, then it's probably something we should allow for. Fantastic. I am going to run side by side binaries, one with the existing unsigned, and one with the u_int64_t. I have been playing out content with a mux rate of 8,000kbit/sec and I was seeing the problem occur after about a week and a half and by my math that seems to agree with a calculated value of 9.3 days. Hi Ross, My test was thwarted by an unexpected shortage of electrons about halfway through, but has now completed. I have run both a task based on the current live555 source, and a task with a modified source tree using u_int64_t side by side, playing out a loop of MPEG2 content that never closes or ends via a DeviceSource. The task that isn't using 64bit integers has, as expected, lost it's mind and is spending a lot of time blocking and using every scrap of CPU available as it tries to play out the MPEG at a ridiculously high rate. The modified version is still working as per normal. The only modifications I have made are as follows: In MPEG2TransportStreamFramer.cpp, class 'PIDStatus' I have changed lastPacketNum to u_int64_t. In include/MPEG2TransportStreamFramer.hh I have changed tsPacketCount, fTSPacketCount and fTSPCRCount types to u_int64_t. Regards, Tim Shackleton ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
[Live-devel] testOnDemandRTSPServer multicast question
Hi Ross, I have been experimenting with a multicast to unicast RTSP relay, as demonstrated in testOnDemandRTSPServer. A behaviour I have noticed, is that the first client connects and receives the stream correctly, and all subsequent connections do too - they can SETUP, PLAY and TEARDOWN to their hearts content... However, if /*all*/ clients leave, the multicast source seems to become closed (though not reported as such in debug), and any clients that try to connect from this point onwards are accepted, but do not receive a video stream. Is this an expected behaviour? And if it is, can this behaviour be altered so that the source remains connected in absence of RTSP clients? Thanks and regards, -Tim ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] testOnDemandRTSPServer multicast question
On 17/12/12 12:18, Ross Finlayson wrote:
Since the "testOnDemandRTSPServer" demonstrates how to stream from
*files* to (unicast) clients, it does not 'demonstrate' multicast to
unicast RTSP relaying at all. Therefore, you must have modified the
supplied application's code in some (unspecified) way. So I don't
really see how I can help you.
I have copied testOnDemandRTSPServer.cpp to another file and modified it
- the modification is simply the removal of all available streams with
the exception of the following block:
// A MPEG-2 Transport Stream, coming from a live UDP (raw-UDP or
RTP/UDP) source:
{
char const* streamName = "mpeg2TransportStreamFromUDPSourceTest";
char const* inputAddressStr = "239.255.42.42";
// This causes the server to take its input from the stream
sent by the "testMPEG2TransportStreamer" demo application.
// (Note: If the input UDP source is unicast rather than
multicast, then change this to NULL.)
portNumBits const inputPortNum = 1234;
// This causes the server to take its input from the stream
sent by the "testMPEG2TransportStreamer" demo application.
Boolean const inputStreamIsRawUDP = False;
ServerMediaSession* sms
= ServerMediaSession::createNew(*env, streamName, streamName,
descriptionString);
sms->addSubsession(MPEG2TransportUDPServerMediaSubsession
::createNew(*env, inputAddressStr, inputPortNum,
inputStreamIsRawUDP));
rtspServer->addServerMediaSession(sms);
char* url = rtspServer->rtspURL(sms);
*env << "\n\"" << streamName << "\" stream, from a UDP Transport
Stream input source \n\t(";
if (inputAddressStr != NULL) {
*env << "IP multicast address " << inputAddressStr << ",";
} else {
*env << "unicast;";
}
*env << " port " << inputPortNum << ")\n";
*env << "Play this stream using the URL \"" << url << "\"\n";
delete[] url;
}
Once again, you haven't said how you have modified the supplied code,
but it sounds like you added a new "OnDemandServerMediaSubsession"
subclass that (1) correctly sets "reuseFirstSource" to True, and (2)
redefines the "createNewStreamSource()" virtual function to create a
new input source object (of some unspecified type...).
Correct, I have specified reuseFirstSource as true. As above, I have
used the code block from the supplied test program, with the multicast
group and port modified to suit local conditions.
If you do this, then, yes, the input source object will get closed
(and its destructor called) whenever the last RTSP client leaves.
This is the proper behavior, because we want the input source to be
closed when noone is requesting its data. (Similarly, when another
client arrives later, "createNewStreamSource()" will get called again,
and a new input source object will get created.)
Now, if that was the behaviour I am observing, then I would be quite
happy with that! However, when another client arrives later, the
multicast stream source does not appear to become active again. I can
confirm however that createNewStreamSource from
MPEG2TransportUDPServerMediaSubsession.cpp is being called as you say it
should be when the client arrives.
I am confident the source is still present on the network, as the source
is directly connected to an ethernet port on the testing machine. I can
see no reason why the library shouldn't be able to resubscribe to this
source, either.
Thanks and regards,
-Tim
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] testOnDemandRTSPServer multicast question
On 17/12/12 12:18, Ross Finlayson wrote: If you do this, then, yes, the input source object will get closed (and its destructor called) whenever the last RTSP client leaves. This is the proper behavior, because we want the input source to be closed when noone is requesting its data. (Similarly, when another client arrives later, "createNewStreamSource()" will get called again, and a new input source object will get created.) Hi Ross, I have just noticed something - when the first client connects, there is an IGMP membership report issued to join the group I have specified for any sources. However, when that first (and only) client tears down the session, there is no IGMP membership report for the 'Leave'. That said, a 'Leave' is issued when the program is subsequently terminated. I suspect that the lack of an IGMP leave in the source destructor may be the cause of this unexpected behaviour. Would you suggest I write my own subclassed source and destructor, or do you think this behavour should be contained within the standard live555 source? Thanks and regards, -Tim ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] testOnDemandRTSPServer multicast question
On 17/12/12 13:53, Ross Finlayson wrote:
First, I'll try to look into exactly what's happening. If there's a
bug in the supplied LIVE555 code, then I'll try to fix it.
Thanks Ross, I appreciate this greatly.
I have done a little further investigation myself and thought I'd share
it with you in case it helps.
I voided my warranty, so to speak, by adding a printf("."); to
BasicUDPSource::incomingPacketHandler1() in order to see when the source
is processing packets.
As expected, no packets are processed until the first client connects to
the RTSP server, at which time packets are processed at an expected rate.
When that client leaves, packets are no longer processed.
When the next client connects, packets seem to be processed, but
remarkably slower than when the first client was connected. Here's the
debug output to illustrate this:
"test" stream, from a UDP Transport Stream input source
(IP multicast address 239.200.1.102, port 5500)
Play this stream using the URL "rtsp://10.2.1.182:8554/test"
accept()ed connection from 10.201.17.53
RTSPClientConnection[0x1ecbed0]::handleRequestBytes() read 121 new
bytes:OPTIONS rtsp://10.2.1.182:8554/test RTSP/1.0
CSeq: 2
User-Agent: LibVLC/2.0.4 (LIVE555 Streaming Media v2012.09.13)
parseRTSPRequestString() succeeded, returning cmdName "OPTIONS",
urlPreSuffix "", urlSuffix "test", CSeq "2", Content-Length 0, with 0
bytes following the message.
sending response: RTSP/1.0 200 OK
CSeq: 2
Date: Mon, Dec 17 2012 20:11:07 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE,
GET_PARAMETER, SET_PARAMETER
RTSPClientConnection[0x1ecbed0]::handleRequestBytes() read 147 new
bytes:DESCRIBE rtsp://10.2.1.182:8554/test RTSP/1.0
CSeq: 3
User-Agent: LibVLC/2.0.4 (LIVE555 Streaming Media v2012.09.13)
Accept: application/sdp
parseRTSPRequestString() succeeded, returning cmdName "DESCRIBE",
urlPreSuffix "", urlSuffix "test", CSeq "3", Content-Length 0, with 0
bytes following the message.
sending response: RTSP/1.0 200 OK
CSeq: 3
Date: Mon, Dec 17 2012 20:11:07 GMT
Content-Base: rtsp://10.2.1.182:8554/test/
Content-Type: application/sdp
Content-Length: 320
v=0
o=- 1355775062508879 1 IN IP4 10.2.1.182
s=Session streamed by VPS-UAT
i=test
t=0 0
a=tool:LIVE555 Streaming Media v2012.11.30
a=type:broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:Session streamed by VPS-UAT
a=x-qt-text-inf:test
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
b=AS:5000
a=control:track1
RTSPClientConnection[0x1ecbed0]::handleRequestBytes() read 176 new
bytes:SETUP rtsp://10.2.1.182:8554/test/track1 RTSP/1.0
CSeq: 4
User-Agent: LibVLC/2.0.4 (LIVE555 Streaming Media v2012.09.13)
Transport: RTP/AVP;unicast;client_port=1612-1613
parseRTSPRequestString() succeeded, returning cmdName "SETUP",
urlPreSuffix "test", urlSuffix "track1", CSeq "4", Content-Length 0,
with 0 bytes following the message.
sending response: RTSP/1.0 200 OK
CSeq: 4
Date: Mon, Dec 17 2012 20:11:07 GMT
Transport:
RTP/AVP;unicast;destination=10.201.17.53;source=10.2.1.182;client_port=1612-1613;server_port=6970-6971
Session: 2283FFFD
RTSPClientConnection[0x1ecbed0]::handleRequestBytes() read 157 new
bytes:PLAY rtsp://10.2.1.182:8554/test/ RTSP/1.0
CSeq: 5
User-Agent: LibVLC/2.0.4 (LIVE555 Streaming Media v2012.09.13)
Session: 2283FFFD
Range: npt=0.000-
parseRTSPRequestString() succeeded, returning cmdName "PLAY",
urlPreSuffix "test", urlSuffix "", CSeq "5", Content-Length 0, with 0
bytes following the message.
sending response: RTSP/1.0 200 OK
CSeq: 5
Date: Mon, Dec 17 2012 20:11:07 GMT
Range: npt=0.000-
Session: 2283FFFD
RTP-Info:
url=rtsp://10.2.1.182:8554/test/track1;seq=12753;rtptime=3031997768
...RTSPClientConnection[0x1ecbed0]::handleRequestBytes() read 147 new
bytes:GET_PARAMETER rtsp://10.2.1.182:8554/test/ RTSP/1.0
CSeq: 6
User-Agent: LibVLC/2.0.4 (LIVE555 Streaming Media v2012.09.13)
Session: 2283FFFD
parseRTSPRequestString() succeeded, returning cmdName "GET_PARAMETER",
urlPreSuffix "test", urlSuffix "", CSeq "6", Content-Length 0, with 0
bytes following the message.
sending response: RTSP/1.0 200 OK
CSeq: 6
Date: Mon, Dec 17 2012 20:11:07 GMT
Session: 2283FFFD
RTSP
client session (id "2283FFFD", stream name "test"): Liveness indication
Re: [Live-devel] testOnDemandRTSPServer multicast question
On 18/12/12 11:20, Ross Finlayson wrote:
Unfortunately I wasn't able to reproduce your problem at all. I ran
"testMPEG2TransportStreamer" to continuously stream a Transport Stream
file via multicast, and also ran "testOnDemandRTSPServer" to receive
this multicast stream, and use it as input for a unicast RTSP server.
I then kept running
openRTSP -d 5 -n
to repeatedly open and receive the stream for 5 seconds, then close
it. Each time, "openRTSP" received data.
So unfortunately you're going to have to track down yourself what is
going wrong.
Hi Ross,
Yes, I shall look into it more deeply. In case it makes any difference,
I'll describe the setup here for you.
Linux 64 bit, multicast source is RAW, not RTP, from an external machine
(In this case a Cisco Digital Content Manager), SPTS at 3.7MBit/sec.
The only mechanical modifications to the testOnDemandRTSPServer that
have been made are reuseFirstSource=True, inputStreamIsRawUDP=True, and
the inputAddressStr and inputPortNum values.
When I run the testOnDemandRTSPServer, I, like you, am able to connect
to it with openRTSP and it says it receives data. /That is not in
dispute/. I thought at first data was completely lacking but as I
described in my previous email, that is not actually the case.
However, if I subsequently try and play from the RTSP server with VLC,
it connects but cannot play because /insufficient data/ appears to be
sent. Are you able to play the transport stream via RTSP successfully
with VLC after a few launches of openRTSP?
I have a hunch at this point that the TransportStreamFramer is not being
reinitialized when a new client arrives (after all clients have left)
and the packet playout rate is no longer correct - but like I said, it's
only a hunch.
In order to make sure I'm on absolutely the right page, I rebuilt the
latest source. I have trimmed testOnDemandRTSPServer from your example
(to cut out all other example instances other than the multicast source)
and made only the modifications I mentioned above. The same results are
exhibited. The source of the test program is as follows:
#include "liveMedia.hh"
#include "BasicUsageEnvironment.hh"
UsageEnvironment* env;
Boolean reuseFirstSource = True;
Boolean iFramesOnly = False;
static void announceStream(RTSPServer* rtspServer, ServerMediaSession* sms,
char const* streamName, char const*
inputFileName); // fwd
int main(int argc, char** argv) {
TaskScheduler* scheduler = BasicTaskScheduler::createNew();
env = BasicUsageEnvironment::createNew(*scheduler);
UserAuthenticationDatabase* authDB = NULL;
RTSPServer* rtspServer = RTSPServer::createNew(*env, 8554, authDB);
if (rtspServer == NULL) {
*env << "Failed to create RTSP server: " << env->getResultMsg() <<
"\n";
exit(1);
}
char const* descriptionString
= "Session streamed by \"testOnDemandRTSPServer\"";
// A MPEG-2 Transport Stream, coming from a live UDP (raw-UDP or
RTP/UDP) source:
{
char const* streamName = "mpeg2TransportStreamFromUDPSourceTest";
char const* inputAddressStr = "239.200.1.102";
portNumBits const inputPortNum = 5500;
Boolean const inputStreamIsRawUDP = True;
ServerMediaSession* sms
= ServerMediaSession::createNew(*env, streamName, streamName,
descriptionString);
sms->addSubsession(MPEG2TransportUDPServerMediaSubsession
::createNew(*env, inputAddressStr, inputPortNum,
inputStreamIsRawUDP));
rtspServer->addServerMediaSession(sms);
char* url = rtspServer->rtspURL(sms);
*env << "\n\"" << streamName << "\" stream, from a UDP Transport
Stream input source \n\t(";
if (inputAddressStr != NULL) {
*env << "IP multicast address " << inputAddressStr << ",";
} else {
*env << "unicast;";
}
*env << " port " << inputPortNum << ")\n";
*env << "Play this stream using the URL \"" << url << "\"\n";
delete[] url;
}
env->taskScheduler().doEventLoop(); // does not return
return 0; // only to prevent compiler warning
}
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] testOnDemandRTSPServer multicast question
On 18/12/12 13:52, Ross Finlayson wrote: No. As you can see from the "MPEG2TransportUDPServerMediaSubsession" implementation, a new "MPEG2TransportStreamFramer" is created (and used as the data source) each time "createNewStreamSource()" is called - i.e., each time we start reading from the input stream. Quite right - I flipped on DEBUG_PCR and clearly a FIRST PCR is present on every fresh client connect (from zero clients). That would clear up that hunch fairly comprehensively. The only thing left then, I suppose, is the socket receiving the data. From the PCR debug it's obvious though, that something is going very wrong, and I cannot see how it can be my multicast source, or the live555 example program supplied. It appears to be a sudden lack of data on ingress, but I can prove that the data is still there, on the wire. It's a professional source. And the group is not 'left' by the socket, as previously discussed. Quite baffled. I'll continue investigating. I won't rule out kernel level issues either at this stage! Thanks, -Tim parseRTSPRequestString() succeeded, returning cmdName "PLAY", urlPreSuffix "test", urlSuffix "", CSeq "5", Content-Length 0, with 0 bytes following the message. sending response: RTSP/1.0 200 OK CSeq: 5 Date: Tue, Dec 18 2012 01:20:49 GMT Range: npt=0.000- Session: 50345F36 RTP-Info: url=rtsp://10.2.1.182:8554/test/track1;seq=59716;rtptime=226380619 *PID 0x21, FIRST PCR 0x004e81a6+1:121 == 114.11 @ 1355793649.575549, pkt #7* PID 0x21, PCR 0x004e8583+0:046 == 114.355269 @ 1355793649.575600 (*diffs 0.021959* @ 0.51), pkt #61, discon 0 => this duration 0.000407, new estimate 0.000407, mean PCR period=30.50 RTSPClientConnection[0x107ff70]::handleRequestBytes() read 147 new bytes:GET_PARAMETER rtsp://10.2.1.182:8554/test/ RTSP/1.0 CSeq: 6 User-Agent: LibVLC/2.0.4 (LIVE555 Streaming Media v2012.09.13) Session: 50345F36 parseRTSPRequestString() succeeded, returning cmdName "GET_PARAMETER", urlPreSuffix "test", urlSuffix "", CSeq "6", Content-Length 0, with 0 bytes following the message. sending response: RTSP/1.0 200 OK CSeq: 6 Date: Tue, Dec 18 2012 01:20:49 GMT Session: 50345F36 PID 0x21, PCR 0x00511ba9+1:073 == 118.122171 @ 1355793649.629560 (*diffs 3.788860* @ 0.054011), pkt #190, discon 0 => this duration 0.029201, new estimate 0.018505, mean PCR period=63.33 PID 0x21, PCR 0x0051f33c+0:0a3 == 119.348539 @ 1355793650.536256 (*diffs 5.015229* @ 0.960707), pkt #243, discon 0 => this duration 0.023139, new estimate 0.026027, mean PCR period=60.75 RTSP client session (id "50345F36", stream name "test"): Liveness indication PID 0x21, PCR 0x00532b7b+1:0de == 121.124886 @ 1355793653.086902 (*diffs 6.791575* @ 3.511353), pkt #340, discon 0 => this duration 0.018313, new estimate 0.027713, mean PCR period=68.00 PID 0x21, PCR 0x0053832a+0:028 == 121.623690 @ 1355793654.444790 (*diffs 7.290380* @ 4.869241), pkt #391, discon 0 => this duration 0.009780, new estimate 0.023433, mean PCR period=65.17 PID 0x21, PCR 0x0053c5d3+1:068 == 122.002926 @ 1355793656.085100 (*diffs 7.669615* @ 6.509551), pkt #458, discon 0 => this duration 0.005660, new estimate 0.018183, mean PCR period=57.25 PID 0x21, PCR 0x006e777b+1:051 == 160.878836 @ 1355793656.848786 (*diffs 46.545526* @ 7.273237), pkt #498, discon 0 => this duration 0.971898, new estimate 0.618801, mean PCR period=55.33 RTSP client session (id "50345F36", stream name "test"): Liveness indication RTSP client session (id "50345F36", stream name "test"): Liveness indication RTSP client session (id "50345F36", stream name "test"): Liveness indication RTSP client session (id "50345F36", stream name "test"): Liveness indication RTSP client session (id "50345F36", stream name "test"): Liveness indication RTSPClientConnection[0x107ff70]::handleRequestBytes() read 142 new bytes:TEARDOWN rtsp://10.2.1.182:8554/test/ RTSP/1.0 ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
