Thanks. I'm able to view the RTSP stream in VLC and the Onvif device manager, which also uses Live555.
The buffer is plenty big enough, and I'm not seeing truncated bytes. Tim Gee<mailto:tim....@aldiscorp.com> | Senior R&D Engineer Aldis<http://www.aldiscorp.com/> | 10545 Hardin Valley Rd. | Knoxville TN | 37932 o: 865-978-6535 | f: 865-249-6608 ________________________________ From: live-devel-boun...@ns.live555.com <live-devel-boun...@ns.live555.com> on behalf of Ross Finlayson <finlay...@live555.com> Sent: Wednesday, July 24, 2013 4:02 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] testRTSPClient and MJPEG decoding Thanks for the response. Ok, does that mean the data in the sink will have already been processed by JPEGVideoRTPSource::processSpecialHeader()? Yes, but you don't have to concern yourself with how our code works. As I said before, the data that the application-level client code (in this case "testRTSPClient") receives should be a complete JPEG video frame each time. I wonder if there is a bug in the JPEG packet processing because I write each JPEG frame to a file, and each appears very corrupted. It's definitely a JPEG because it opens in an image viewer, and it has the right dimensions. However, each image looks like garbage. What happens when you try playing the stream using VLC? (VLC also uses our RTSP/RTP client code.) I put the following code in testRTSPClient. void DummySink::afterGettingFrame(unsigned frameSize, unsigned numTruncatedBytes, struct timeval presentationTime, unsigned /*durationInMicroseconds*/) { You should also check the value of "numTruncatedBytes" (to make sure that it's zero). If it's non-zero, then that means that your buffer size was too small. 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
