, SO51 8BZ. Company Number : 03428325
From: live-devel [mailto:live-devel-boun...@ns.live555.com] On Behalf Of Ross
Finlayson
Sent: 08 May 2015 08:48
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Multiple NALUs concatenated together in one
afterGettingFrame
Is t
> Is there a way we, as the RTSPClient caller, can determine when RTP frames
> have been lost
Yes, look at “RTPReceptionStats”. Note (in “testProgs/playCommon.cpp”) how the
“openRTSP” client implements the “-Q” (report QOS stats) option:
http://live555.com/openRTSP/#other-options
om] On Behalf Of Ross
Finlayson
Sent: 06 May 2015 20:47
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Multiple NALUs concatenated together in one
afterGettingFrame
Comparing these to the packet capture, […] the I frame at packet numbers 19289
to 19463 where the mar
> Comparing these to the packet capture, […] the I frame at packet numbers
> 19289 to 19463 where the marker bit is set.
Note the RTP sequence numbers in these packets: 9159 to 9340.
Now do you see the problem? (Hint: 9340-9159 > 19463-19289)
Congratulations! You’ve just demonstrated somethin
- development & use
Subject: Re: [Live-devel] Multiple NALUs concatenated together in one
afterGettingFrame
Thanks, I was trying to get something concrete by analysing the network stream.
This camera is unusual (compared to others we have) in that it sends an SPS and
a PPS before every I frame.
> Thanks, I was trying to get something concrete by analysing the network
> stream.
> This camera is unusual (compared to others we have) in that it sends an SPS
> and a PPS before every I frame.
> The SPS/PPS share an RTP frame in a STAP with no marker bit, while the I/P
> frames are in FU-A pa
51 8BZ. Company Number : 03428325
From: live-devel [mailto:live-devel-boun...@ns.live555.com] On Behalf Of Ross
Finlayson
Sent: 01 May 2015 18:17
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Multiple NALUs concatenated together in one
afterGettingFrame
Our sof
> Our software uses liveMedia as an RTSP client to connect to network cameras
> to receive H.264 frames.
> Our sink is being passed data from (presumably) the FramedSource class in
> response to data arriving from the camera/RTSP/H.264 video source and being
> depacketised.
OK, it sounds like y
Re: [Live-devel] Multiple NALUs concatenated together in one
afterGettingFrame
Simply put, a single call to afterGettingFrame in my file sink is receiving a
single large “frame” that actually consists of an SPS, PPS, and the I frame in
one single byte stream with no prefix or separator between
> Simply put, a single call to afterGettingFrame in my file sink is receiving a
> single large “frame” that actually consists of an SPS, PPS, and the I frame
> in one single byte stream with no prefix or separator between them.
But where is this data coming from? I.e., what in your code is feed
, SO51 8BZ. Company Number : 03428325
From: live-devel [mailto:live-devel-boun...@ns.live555.com] On Behalf Of Ross
Finlayson
Sent: 01 May 2015 16:50
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Multiple NALUs concatenated together in one
afterGettingFram
I’m having a very hard time understanding exactly what problem you’re having.
In particular:
> It's missing the H.264 prefixes between NALUs and joined them together in one
> afterGettingFrame call
What is “It”? I.e., where is this data coming from? I.e., are you a client, a
server, a proxy
Good morning all.
We're trying to track down an issue we're seeing very occasionally.
This manifested itself as a crash in our code when storing the SPS frames where
the size overrun the 1KiB buffer we'd allocated for it (now fixed).
I was originally thinking it was memory corruption elsewhere ca
13 matches
Mail list logo