> On Sep 28, 2017, at 10:10 PM, Sergio Andrés Basurco Mancisidor > <sergi...@coherentsynchro.com> wrote: > > What I observe is that the NAL units used for a single decoded frame have > different presentation times.
If multiple (‘slice’) NAL units make up a single frame (picture), then the presentation times are supposed to be the same for each one. If they’re not (assuming, of course, that they’ve all been RTCP-synchronized), then that would be a bug in the encoder (camera). But then you say: > PS: This happens when there are B-frames in the h264 stream Which suggests that perhaps you’re not really talking about multiple NAL units that make up a single frame, but instead are referring to a sequence of NAL units that make up a *group* of frames (beginning with a ‘key’ frame). In any case, if there are B-frames, then the presentation times for successive frames will not be monotonically increasing. This is because frames come out of the encoder (and thus the RTSP/RTP stream) in *decoding* order (i.e., the order in which they should be fed to a decoder), which (if there are B-frames) is different from presentation order (the order in which the frames should be displayed to the user when decoded). So once again, feed the NAL units to your decoder in the order in which they arrive, but use the presentation times to figure out when the frames - once decoded - should be rendered. But this is off-topic for this mailing list, because it’s not really about our software, but instead about decoding and application software that happens to use our software (to get a sequence of NAL units, with presentation times). I suggest that you now use the VLC (open source) media player code as a model, because VLC happens to use our software to receive the RTSP/RTP stream, and then decode/render the H.264 NAL units. 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
