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

[Ross Finlayson]

> 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/