...I'm getting closer, but still hoping for a hint on how to solve the puzzle.  In H264VideoStreamParser, log2_max_frame_num defaults to 5, but the SPS NAL unit sets it to 8.  In the ByteStreamFileSource case, the SPS NAL occurs twice, with the stream seemingly restarting a moment after it starts in the first place.  In my live MF_H264_DeviceSource case, there's a restart of sorts, and thus a re-default to 5, but my actual stream isn't restarting.  So from there down, log2_max_frame_num is erroneously 5 rather than 8.  This causes the wrong frame_num to get parsed out, leading to frame_num NOT differing, leading to overly compressed presentation time.  <div>
<br></div><div>So WHY is this restart happening?  Do I simply save the SPS (and PPS) NAL's from my stream and drop a repeat in later?  Or do I make the restart not happen?  Or something else.  This "restart", in detail, relates to checkForAuxSDPLine1() function, which seems to be simply checking for something to be OK.  Then after it the real job starts.  Thus the apparent restart...<br>
<br><div class="gmail_quote">On Wed, Feb 20, 2013 at 11:22 AM, <a href="mailto:temp2010@forren.org">temp2010@forren.org</a> <span dir="ltr"><<a href="mailto:temp2010@forren.org" target="_blank">temp2010@forren.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">FYI, I've re-enabled tracing in H264VideoStreamParser::parse(), and am comparing the working ByteStreamFileSource to the failing MF_H264_DeviceSource, of essentially the same stream.  So far I find that the working ByteStreamFileSource is causing the parse to update the presentation time every eight (8) NAL units, due to "(frame_num differs in value)".  However, the failing MF_H264_DeviceSource is causing the parse to update the presentation time only every 64 (one example) NAL units.  Thus I think it's squeezing presentation time so much it can't be rendered properly.  So I'm trying to figure out where frame_num comes from and how my live send of the same stream might be messed up...<div>

<br></div><div>Another other advice is greatly appreciated.<div><div class="h5"><br><br><div class="gmail_quote">On Wed, Feb 20, 2013 at 9:34 AM, <a href="mailto:temp2010@forren.org" target="_blank">temp2010@forren.org</a> <span dir="ltr"><<a href="mailto:temp2010@forren.org" target="_blank">temp2010@forren.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have a MF_H264_DeviceSource derived from DeviceSource, being used by H264VideoOnDemandServerMediaSubsession derived from OnDemandServerMediaSubsession, from top level XXXOnDemandRTSPServer derived from testOnDemandRTSPServer.  <div>


<br></div><div>Viewing my output with VLC, the output is HORRIBLY RAGGED.<div><br></div><div>I took the same data being fed live to the MF_H264_DeviceSource and wrote it out to a file test.h264 instead.  </div><div><br></div>


<div>First, outside of Live555, I can convert my test.h264 to mp4 with a separate utility, and it plays BEAUTIFUL in Windows Media Player.  </div><div><br></div><div>Second, when I play my test.h264 through existing Live555 ByteStreamFileSource, being used by H264VideoFileServerMediaSubsession, from top level XXXOnDemandRTSPServer derived from testOnDemandRTSPServer, it views BEAUTIFUL on VLC.</div>


</div><div><br></div><div>So it seems I must have some connectivity problem with my MF_H264_DeviceSource substitute for ByteStreamFileSource.  But what?  It mostly just passes frames through, so I doubt it's dropping them.  Is it maybe a timestamp thing?  What else might it be?</div>


<div><br></div><div>Your advice is yet again greatly appreciated...</div>
</blockquote></div><br></div></div></div>
</blockquote></div><br></div>