Hi,
I remember we had similar discussion earlier regarding packet loss.
Search the archive for subject "[Live-devel] Buffering incoming data with
openRTSP?"
The first byte in the payload has the payload type (I or P or Non-ref P or).
In case of packet loss, keep dropping packets till you get
Hi Steve,
Can you use openRTSP program to receive the stream and check whether it matches
your input frames? This will tell u the difference in nalu header parsing.
>> This worked to a degree. The encoder sends NAL unit types 7 and 8 first and
>> then 1 ... 1, 5, 1 1, 5.
You can conside
Hi,
Have you read the how-to compile guide ?
http://www.live555.com/liveMedia/#config-unix
-Original Message-
From: live-devel-boun...@ns.live555.com
[mailto:live-devel-boun...@ns.live555.com] On Behalf Of ajay kashyap
Sent: Wednesday, March 09, 2011 12:40 PM
To: live-devel
Subject: [Liv
Hi Eugene,
I had seen similar issue before. In my implementation using Live555, for mpeg4
video streaming, VLC starts with green screen and it corrects with the arrival
of subsequent I-frame.
Have you observed the green screen going off after VLC received subsequent
i-frame in the sequence?
If
Hi,
To check whether packets gets dropped at network, you can add debug prints in
liveMedia/MultiFramedRTPSource.cpp
void MultiFramedRTPSource::doGetNextFrame1()
// Check whether we're part of a multi-packet frame, and whether
// there was packet loss that would render this packet unusab
Larry,
SPS and PPS has to be sent to client as part of sprop-parameter-set in SDP.
RFC 3984: section 8.1 talks about how to construct sprop-parameter-set. This
will solve the quicktime problem.
From: live-devel-boun...@ns.live555.com
[mailto:live-devel-boun...@ns.live555.com] On Behalf Of Larry