<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [Live-devel] Streaming H264
difficulties</title></head><body>
<div>(My apologies for the delay in responding to this message.)</div>
<div><br></div>
<blockquote type="cite" cite><font face="Arial" size="-1">I am working
on a RTSP RTP-over-TCP H264 streaming application from a live HW-based
encoder.</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">I have
implemented MyDeviceSource, MyH264VideoStreamFramer,
H264DeviceMediaSubsession and MyH264App based on
testOnDemandRTSPServer. In general the application works and I get the
live stream.</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">The intended
viewer application is VLC on a remote machine in the same LAN, where
bandwidth is a non-issue.</font></blockquote>
<blockquote type="cite" cite> </blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">I've
encountered 2 obstacles that have been giving me a hard
time:</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">1.
"Glitches" in the video output. After every (quite small)
amount of frames the video "glitches" and I get block
artifacts, and frames that seem to jump back in time. From playing
around with the presentation times, I thought it might be related to
this.</font></blockquote>
<div><br></div>
<div>Possibly - see below.</div>
<div><br></div>
<div><br></div>
<blockquote type="cite" cite><font face="Arial" size="-1">My approach
to fPresentationTime is to set it to gettimeofday() every GOP (i.e.
SPS/PPS frames), and increment by 1000000/FPS for every encoded
frame.</font></blockquote>
<div><br></div>
<div>Does your H.264 stream contain "B" frames? If so,
then note that the presentation times should *not* be monotonic
increasong, and therefore your method of setting
"fPresentationTime" is incorrect.</div>
<div><br></div>
<div>If you stream does contain "B" frames, then I suggest
that you look at the "MPEG4VideoStreamDiscreteFramer" code
for a model of how to properly set "fPresentationTime" for
H.264 frames.</div>
<div><br></div>
<div><br></div>
<blockquote type="cite" cite><font face="Arial" size="-1"> The
encoder encodes frame by frame only.</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">When I use
openRTSP as the client, the video file is saved perfectly, which no
glitches.</font></blockquote>
<div><br></div>
<div>That is not surprising, because "openRTSP" does not
care about presentation times; it just records the incoming data that
it sees.</div>
<div><br></div>
<div><br></div>
<blockquote type="cite" cite> <font face="Arial" size="-1">2. The
streaming server (OS is Linux2.6) is also used for other
cpu-intensive processes. This is a requirement. The machine is
practically constantly at 100% cpu usage. However, it practically does
not use any network resources.</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">When this is
the situation, the video glitches become overwhelming, and it seems
the client has a very hard time handling the stream and sometimes even
disconnects.</font></blockquote>
<div><br></div>
<div>What happens when you run your server machine *without* these
other CPU-intensive processes?</div>
<div><br></div>
<div>It sounds like you may just have an underpowered
computer...</div>
<x-sigsep><pre>--
</pre></x-sigsep>
<div><br>
Ross Finlayson<br>
Live Networks, Inc.<br>
http://www.live555.com/</div>
</body>
</html>