Dear Ross,
As always, thank you for your thorough explanation.
Regarding this same thing, today I stumbled upon a situation where
"afterGettingframe" is passing me an I-frame that is 73kB+ big !
I have read this post:
http://lists.live555.com/pipermail/live-devel/2013-April/016816.html
and I am baffled, as the maximum UDP packet size is supposed to be ~ 65
kB, and, on the other hand, as you pointed out, live555 does not
assemble NAL slices, but that is the job for the decoder.
The only logical way of making sense of all this is ..
UDP packets: max ~ 65 kB
=> are assembled to .. => (this is done by live555)
NAL slices
=> are assembled to .. => (done by the encoder)
Complete frames, made of several NAL slices
Am I on the right track here .. ?
Regards,
Sampsa
On 05.09.2016 10:18, Ross Finlayson wrote:
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
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
