> 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
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
