<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    Hello Ross,<br>
    <br>
    Thanks for the previous reply. <br>
    Could you please let us know if, there is there an alternate
    solution available to stream H.264 video without using the
    FUAFragmenter's intermediate buffer? If there is no solution
    available then, what can we do to achieve it (like writing a
    subclass or so)?<br>
    <br>
    Thanks and regards,<br>
    Sudan<br>
    <br>
    <table class="moz-email-headers-table" border="0" cellpadding="0"
      cellspacing="0">
      <tbody>
        <tr>
          <th nowrap="nowrap" valign="BASELINE" align="RIGHT">Subject: </th>
          <td>Re: [Live-devel] [live_devel] H264FUAFragmenter buffer</td>
        </tr>
        <tr>
          <th nowrap="nowrap" valign="BASELINE" align="RIGHT">Date: </th>
          <td>Tue, 15 May 2012 00:21:44 -0700</td>
        </tr>
        <tr>
          <th nowrap="nowrap" valign="BASELINE" align="RIGHT">From: </th>
          <td>Ross Finlayson <a class="moz-txt-link-rfc2396E" href="mailto:finlayson@live555.com"><finlayson@live555.com></a></td>
        </tr>
        <tr>
          <th nowrap="nowrap" valign="BASELINE" align="RIGHT">Reply-To:
          </th>
          <td>LIVE555 Streaming Media - development & use
            <a class="moz-txt-link-rfc2396E" href="mailto:live-devel@ns.live555.com"><live-devel@ns.live555.com></a></td>
        </tr>
        <tr>
          <th nowrap="nowrap" valign="BASELINE" align="RIGHT">To: </th>
          <td>LIVE555 Streaming Media - development & use
            <a class="moz-txt-link-rfc2396E" href="mailto:live-devel@ns.live555.com"><live-devel@ns.live555.com></a></td>
        </tr>
      </tbody>
    </table>
    <br>
    <br>
    The "H264FUAFragmenter" class was introduced - as an intermediary
    between "H264VideoRTPSink" and its input source - to handle the
    (common) case of input H.264 NAL units that are too large to fit
    into an outgoing RTP packet.  In this case, the data gets fragmented
    over multiple RTP packets.
    <div><br>
    </div>
    <div>Normally, this can be handled by the "MultiFramedRTPSink"
      subclass (e.g., "H264VideoRTPSink") only, without requiring an
      extra intermediate object.  However, for some reason that I can't
      quite remember, the RTP payload format for H.264 video made it
      necessary to use an intermediate object to handle the
      fragmentation.</div>
    <br>
    <br>
    <div apple-content-edited="true">
      <span class="Apple-style-span" style="border-collapse: separate;
        color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal;
        font-variant: normal; font-weight: normal; letter-spacing:
        normal; line-height: normal; orphans: 2; text-indent: 0px;
        text-transform: none; white-space: normal; widows: 2;
        word-spacing: 0px; font-size: medium;"><span
          class="Apple-style-span" style="border-collapse: separate;
          color: rgb(0, 0, 0); font-family: Helvetica; font-style:
          normal; font-variant: normal; font-weight: normal;
          letter-spacing: normal; line-height: normal; orphans: 2;
          text-indent: 0px; text-transform: none; white-space: normal;
          widows: 2; word-spacing: 0px; font-size: medium;">Ross
          Finlayson<br>
          Live Networks, Inc.<br>
          <a moz-do-not-send="true" href="http://www.live555.com/">http://www.live555.com/</a></span></span>
    </div>
    <br>
    <br>
  </body>
</html>