(My apologies for the delay in responding to this message.)
I am working on a RTSP RTP-over-TCP H264 streaming application from
a live HW-based encoder.
I have implemented MyDeviceSource, MyH264VideoStreamFramer,
H264DeviceMediaSubsession and MyH264App based on
testOnDemandRTSPServer. In general the application works and I get
the live stream.
The intended viewer application is VLC on a remote machine in the
same LAN, where bandwidth is a non-issue.
I've encountered 2 obstacles that have been giving me a hard time:
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.
Possibly - see below.
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.
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.
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.
The encoder encodes frame by frame only.
When I use openRTSP as the client, the video file is saved
perfectly, which no glitches.
That is not surprising, because "openRTSP" does not care about
presentation times; it just records the incoming data that it sees.
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.
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.
What happens when you run your server machine *without* these other
CPU-intensive processes?
It sounds like you may just have an underpowered computer...
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
