> However, with ffmpeg casted stream, I get frames along these lines (this is > what "afterGettingFrame" of my modified DummySink passes me): > > nal_unit_type : 7 ( Sequence parameter set ) > nal_unit_type : 8 ( Picture parameter set ) > nal_unit_type : 5 ( Coded slice of an IDR picture ) > nal_unit_type : 5 ( Coded slice of an IDR picture ) > nal_unit_type : 5 ( Coded slice of an IDR picture ) > nal_unit_type : 5 ( Coded slice of an IDR picture ) > nal_unit_type : 1 ( Coded slice of a non-IDR picture ) > nal_unit_type : 1 ( Coded slice of a non-IDR picture ) > > It seems that the I frame is in multiple slices.
This is actually very good. For streaming H.264 (or H.265) video, it is much better to be transmitting key frames as multiple ‘slice’ NAL units, rather than as a single (very large) ‘key frame’ NAL unit. This makes your stream much more resilient to network packet loss. > I assumed that live555 would compose the slices and give me the I frames as > a single slice/nal unit. No. When streaming (transmitting and/or receiving) H.264/H.265 video, the LIVE555 library deals with NAL units, not complete frames (‘pictures’). When a frame (e.g., a key frame) is broken up into multiple ‘slice’ NAL units, our library transmits/receives each of these ‘slice’ NAL units individually. When receiving the stream, our library does not attempt to ‘reassemble’ the slices into a complete picture; that's the job of the H.264 decoder/renderer (i.e., for your media player). 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
