--- Begin Message ---
Hi Team,
This is continuation of my earlier post
(https://www.mail-archive.com/live-devel@lists.live555.com/msg15406.html).
Frames sending as multiple slices is good, because it makes stream more
resilient to packet loss.
Though decoders are able to decode the slice of a frame, our recording system
needs to write a full I/P frame(not a partial frame).
Because during playback of these recordings client will get these recordings as
list of GOPs, if we save these recording as is example 5 FPS data is saved as
10 frames(I1I1P2P2P3P3P4P4P5P5) in two GOPs(GOP1 => I1, GOP2 => I2P2P2
P3P3P4P4P5P5).
Also sometimes we play only I frame / alternate I frames / every 4th I Frame,
these logics also getting affected because of this.
We have done changes in our application code in the live555 callback function
H265BufferSink::afterGettingFrame()
We are getting the marker bit value Boolean rtpMarkerBit =
fSource->curPacketMarkerBit();
Only if it is true(set to 1), we will consider as last frame received and write
the buffered data to file system, till then we will be keep on appending the
data to a buffer.
We checked the RFC(https://www.ietf.org/rfc/rfc3550.txt,
https://www.ietf.org/rfc/rfc3551.txt), it says that "In video streams, the
marker bit MUST be one for the last packet sent for each video
frame<https://learn.microsoft.com/en-us/openspecs/office_protocols/ms-rtp/ba0d6cb2-f11f-4fd4-b08b-2ee9151067f8#gt_74615d14-4462-4a5c-a4aa-73b8cea35d5e>,
and zero for all other packets".
Is this implementation of merging multiple slices of data into a single frame
is correct ?
Please share your input.
Thanks and Regards,
Ranjith
--- End Message ---
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
