[Live-devel] For raw H.264, live device source horribly ragged while byte stream file source beautiful

[temp2010 at forren.org]

...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.

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...

On Wed, Feb 20, 2013 at 11:22 AM, temp2010 at forren.org
<temp2010 at forren.org>wrote:

> 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...
>
> Another other advice is greatly appreciated.
>
>
> On Wed, Feb 20, 2013 at 9:34 AM, temp2010 at forren.org <temp2010 at forren.org>wrote:
>
>> I have a MF_H264_DeviceSource derived from DeviceSource, being used
>> by H264VideoOnDemandServerMediaSubsession derived
>> from OnDemandServerMediaSubsession, from top level XXXOnDemandRTSPServer
>> derived from testOnDemandRTSPServer.
>>
>> Viewing my output with VLC, the output is HORRIBLY RAGGED.
>>
>> I took the same data being fed live to the MF_H264_DeviceSource and wrote
>> it out to a file test.h264 instead.
>>
>> First, outside of Live555, I can convert my test.h264 to mp4 with a
>> separate utility, and it plays BEAUTIFUL in Windows Media Player.
>>
>> 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.
>>
>> 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?
>>
>> Your advice is yet again greatly appreciated...
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20130220/84a27412/attachment-0001.html>