Handle multiple I/P slices

[R, Ranjith]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20230728/0f372790/attachment.htm>