<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    Hi Ross,<br>
    <br>
    On 01/17/2013 04:50 PM, Ross Finlayson wrote:
    <blockquote
      cite="mid:EB0282A6-36F5-4673-B102-8C0238AFACC2@live555.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <div>
        <blockquote type="cite">I'm trying to stream live H.264 video
          and live G.711 audio, using<br>
          testMPEG1or2AudioVideoStreamer.cpp as an example.</blockquote>
        <div><br>
        </div>
        I'm not sure how much of an 'example' the
        "testMPEG1or2AudioVideoStreamer" code can be, given that it
        streams from a file source, and uses completely different codecs
        (and thus uses completely different "RTPSink" subclasses).  But
        anyway...</div>
      <div><br>
      </div>
      <div><br>
      </div>
    </blockquote>
    Well, that's the only example I've found that streams both video and
    audio.<br>
    I was also looking at testWavAudioStreamer and
    testH264VideoStreamer.<br>
    <br>
    <blockquote
      cite="mid:EB0282A6-36F5-4673-B102-8C0238AFACC2@live555.com"
      type="cite">
      <div>
        <blockquote type="cite"> Both video<br>
          and audio come from hardware encoders. As soon as encoded
          buffer<br>
          is available, live555 code is notified via event trigger
          associated<br>
          with media source. I'm using VLC to play the stream.<br>
          <br>
          The problem is that video freezes almost immediately.<br>
          If only video is streamed, there's no problem.<br>
          <br>
          I suspect that audio can starve video since audio frame size
          produced<br>
          by encoder is 160 bytes and some find of aggregation is
          required.<br>
          Does this sound right ?<br>
        </blockquote>
        <div><br>
        </div>
        That's a possibility.  However a more likely cause of problems
        like this is that you are setting "fPresentationTime"
        incorrectly for one or both of your audio and video substreams -
        so they end up being non-synchronized at the receiver (VLC) end.</div>
      <div><br>
      </div>
      <div>For each frame delivered by your input source,
        "fPresentationTime" must be set properly, and must be aligned
        with 'wall clock' time - i.e., the time that you'd get by
        calling "gettimeofday()".</div>
    </blockquote>
    <br>
    I do set fPresentationTime using gettimeofday() in my implementation
    of DeviceSource. It's the same class for both video and audio.<br>
    <br>
    Felix.<br>
  </body>
</html>