<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><div>Hello,</div><div> </div><div>In your documents, you may see "4.8 Fragmentation Units (FUs)", it description how to split our bitstream into FUs</div><div> </div><div>Regards,</div><div>Min</div><div><br></div>At 2015-03-10 06:08:55,"Philipp Kroos" <philipp.kroos@gmail.com> wrote:<br> <blockquote id="isReplyContent" style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div dir="ltr">Hi,<div><br></div><div>I was recently beginning to implement a h.265 streamer using the x265 code and the live555-RTP-library. I noticed that there might be an incompatibilty between the approaches taken by x265 and by live555. However, they explicitly mention the likeliness of this issue in their code and state that they are adhering to the definition of the h264/5 standard:</div><div>The NAL-units I'm receiving from the encoder are prefixed with the MPEG-start code 0x00 0x00 0x00/1 (0x01). This results in an error in the RTP-server which does not allow this startcode in the payload. I don't know that much (if anything) about the definition, but at least the declaration of the header here <a href="https://tools.ietf.org/html/draft-ietf-payload-rtp-h265-07#page-16">https://tools.ietf.org/html/draft-ietf-payload-rtp-h265-07#page-16</a> seems to support live555's standpoint.</div><div>I have no problems to read and write recognizable files with x265, but to pass the output to the RTP protocol, the only solution I found was to manually skip the first relevant bytes of the NAL units (which seems to work fine anyways).  </div><div><br></div><div>Is there a better solution for this?</div><div><div><span style="font-size: 13.19px;">Hopefully someone can clarify this for me. </span><br></div><div><span style="font-size: 13.19px;"><br></span></div><div><span style="font-size: 13.19px;">Thank you, Philipp</span></div></div></div>
</blockquote></div>