[Live-devel] rtspTestClient consumes the first bytes of each packet? How to prevent?

Eric.Brandt at nikon.com Eric.Brandt at nikon.com
Thu May 30 14:39:19 PDT 2019


Thanks Ross, I'll take a look at your suggestions and follow up with any additional questions.

This may be an elementary question but where can I find the standards documents upon which live555 is based, so that I can read/understand the data flow better without asking so many questions? Is it entirely in RFC2326, or are there other sources? Thanks.

-Eric.

-----Original Message-----
From: live-devel [mailto:live-devel-bounces at us.live555.com] On Behalf Of Ross Finlayson
Sent: Thursday, May 30, 2019 4:26 PM
To: LIVE555 Streaming Media - development & use <live-devel at us.live555.com>
Subject: Re: [Live-devel] rtspTestClient consumes the first bytes of each packet? How to prevent?

> However, when supplying the fReceiveBuffer data from ‘afterGettingFrame()’, the av_parser_parse2() never finds a packet, because the testRTSPClient has consumed the 0x0001 header at the start of the h.264 packet.

No, “testRTSPClient” has not ‘consumed’ the 0x00 0x00 0x00 0x01 (I assume that is what you meant) ’start code’ - because it was never there to begin with.  The RTP payload format for H.264 specifies that RTP packets contain H.264 NAL units, without any ’start codes'.  So that’s what our (and other standards-compliant) server sends, and thus it’s what “testRTSPClient” receives.

If the receiver happens to need the ’start codes’ (e.g., in order to do decoding), then it’s the responsibility of the receiver to add them.

I suggest that you use our existing “H264VideoFileSink” class, which will write the incoming H.264 stream to a file (use the file name “stdout” to get standard output, if you want to pipe it), with ’start codes’ before each NAL unit.

Or, alternatively, just use our “openRTSP” application:
	openRTSP -v rtsp://your-rtsp-url | ffmpeg-reading-from-stdin


> 3.       The sizes of the data received in fReceiveBuffer are clearly not entire frames…

Correct.  They’re NAL units, not necessarily entire frames.  But “ffmpeg” will still be able to decode them (when ’start codes’ are prepended to them).


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/


_______________________________________________
live-devel mailing list
live-devel at lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel



More information about the live-devel mailing list