rp.com/> | 10545 Hardin Valley Rd. | Knoxville TN |
37932
o: 865-978-6535 | f: 865-249-6608
From: live-devel-boun...@ns.live555.com on
behalf of Ross Finlayson
Sent: Tuesday, July 30, 2013 2:10 AM
To: LIVE555 Streaming Media - development & use
Subject: R
> I've been looking at the JPEG images in JpegSnoop and hex view. It appears
> that there are 4 extra bytes between the luminance and chrominance
> quantization tables. I've looked at the code for
> JPEGVideoRTPSource::processSpecialHeader(), and I don't yet see why the extra
> bytes would occu
555.com on
behalf of Tim Gee
Sent: Sunday, July 28, 2013 3:59 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] testRTSPClient and MJPEG decoding
I added the line for increasing the receive buffer, but it didn't make the
output images any better. Thanks for t
_
From: live-devel-boun...@ns.live555.com on
behalf of Ross Finlayson
Sent: Sunday, July 28, 2013 12:30 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] testRTSPClient and MJPEG decoding
I'm able to view the RTSP stream in VLC
OK. One thing that VLC is
> I'm able to view the RTSP stream in VLC
OK. One thing that VLC is doing that "testRTSPClient" is not is setting an
extremely large receive buffer (in the operating system) for the RTP socket.
This may be necessary for you, because you're trying to receive a stream that
uses such a ridiculou
; | 10545 Hardin Valley Rd. | Knoxville TN |
37932
o: 865-978-6535 | f: 865-249-6608
From: live-devel-boun...@ns.live555.com on
behalf of Ross Finlayson
Sent: Wednesday, July 24, 2013 4:02 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [
> 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 ca
Valley Rd. | Knoxville TN |
37932
o: 865-978-6535 | f: 865-249-6608
From: live-devel-boun...@ns.live555.com on
behalf of Ross Finlayson
Sent: Tuesday, July 23, 2013 10:12 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] test
> I have been working with the testRTSPClient example for reading from an MJPEG
> camera. I understand that when afterGettingFrame() is called, fReceiveBuffer
> contains the raw RTP packet
You understand incorrectly. All of the RTP (and RTCP) processing is done by
our code; that's why our code
I have been working with the testRTSPClient example for reading from an MJPEG
camera. I understand that when afterGettingFrame() is called, fReceiveBuffer
contains the raw RTP packet, and I need to reformat the header to get
"standard" JPEG files.
What is the recommended method for doing this?
10 matches
Mail list logo
