I captured with Wireshark and there is a difference between the 2
streaming methodes, the Qvidium seems to allow more time before to
send the next frame and the frame is composed of many UDP packet
when Live555 try to gather perfectly the packets during the time and
I guess it is stressing too much the DTE-3114 to treat this
bandwidth on the fly.
Then, I would like to know if it is possible to change the way to
send packet on the network to try to make my test bench working.
Yes, perhaps - although I'm a bit surprised that our server is
behaving in the way that you describe, so I suggest that you first
try to investigate some more why this is happening.
The code that determines the time gap between successive groups of
188-byte Transport Stream 'packets' that make up a network packet is
in "liveMedia/MPEG2TransportStreamFramer.cpp", line 147: The
calcuation of "fDurationInMicroseconds". This calculation is a
running estimate, based on the PCR timestamps seen in the Transport
Stream data.
The value of "fDurationInMicroseconds" is then used by the RTP
streaming code ("MultiFramedRTPSink") to figure out how long to wait
before sending each outgoing network packet.
So, if you wanted to change the time gaps between successive network
packets, you would do so by (somehow) changing the calculation of
"fDurationInMicroseconds" in the "MPEG2TransportStreamFramer" class.
But, as I noted above, I suggest that - before diving in to chage
this code - you first try to figure out why the current code is
producing the behavior that you're seeing. Perhaps there's something
strange about your data's PCR timestamps that is causing this??
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
