0

I am streaming a raw .h264 video file via RTSP using LIVE555.

To receive the stream I am using ffplay. However, when watching the video I notice bad video quality and a bunch of errors in the ffplay-console:

Input #0, rtsp, from 'rtsp://xx.xx.xxx.x/stream': sq=    0B f=0/0
  Metadata:
    title           : stream
    comment         : stream
Duration: N/A, start: 0.099989, bitrate: N/A
    Stream #0:0: Video: h264 (High), yuv420p(tv, smpte170m/smpte170m/bt470m), 16
80x1050 [SAR 1:1 DAR 8:5], 60 fps, 60 tbr, 90k tbn, 120 tbc
[h264 @ 03f92100] RTP: missed 46 packetsq=   28KB sq=    0B f=1/1
[h264 @ 03f92100] RTP: missed 74 packetsq=   23KB sq=    0B f=1/1
[h264 @ 03f92100] RTP: missed 43 packets
[h264 @ 03f92100] RTP: missed 35 packetsq=  179KB sq=    0B f=1/1
[h264 @ 05710640] left block unavailable for requested intra4x4 mode -1 at 0 38
[h264 @ 05710640] error while decoding MB 0 38, bytestream 48108
[h264 @ 05710640] Cannot use next picture in error concealment
[h264 @ 05710640] concealing 2989 DC, 2989 AC, 2989 MV errors in P frame
[h264 @ 051043c0] left block unavailable for requested intra4x4 mode -1 at 0 26
[h264 @ 051043c0] error while decoding MB 0 26, bytestream 5894
[h264 @ 051043c0] concealing 4249 DC, 4249 AC, 4249 MV errors in I frame
[h264 @ 03f92100] RTP: missed 68 packetsq=   28KB sq=    0B f=1/1
[h264 @ 03f92100] RTP: missed 31 packetsq=  153KB sq=    0B f=1/1
[h264 @ 052a0020] concealing 3292 DC, 3292 AC, 3292 MV errors in I frame
[h264 @ 052a0020] Cannot use next picture in error concealment1/1
[h264 @ 052a0020] concealing 2190 DC, 2190 AC, 2190 MV errors in P frame
[h264 @ 03f92100] RTP: missed 69 packetsq=   27KB sq=    0B f=1/1
[h264 @ 052a0020] concealing 3732 DC, 3732 AC, 3732 MV errors in I frame
[h264 @ 03f92100] RTP: missed 26 packetsq=   30KB sq=    0B f=1/1
...

How can I determine what's wrong here? Either with the stream or the file?

chrisp
  • 569
  • 4
  • 24

2 Answers2

1

RTP: missed <N> packets

The LIVE555 Media Server uses RTP over UDP by default unless the RTSP client demands a TCP stream.

UDP is considered an unreliable protocol because there's no guarantee of delivery, the packets can arrive at the destination in a different order and/or duplicated.

If the underlying network connection is not reliable you can experience a lot of packet loss like in your case and the stream will play with a lot of errors.

aergistal
  • 29,947
  • 5
  • 70
  • 92
  • This sounds understandable. However, with TCP it retransmissions all the packets and makes the image even worse. What factors could possibly make the connection that bad? – chrisp Aug 31 '15 at 08:59
  • There can be many causes: latency caused by many hops/distance, not enough bandwidth or network congestion, hardware performance or faulty hardware, bad cabling, software issues. – aergistal Aug 31 '15 at 09:04
  • I agree. There can be -many- causes. But how can I narrow it down? Are there debugging methods for networking? I've never really done that before and I'm not sure how professionals debug their network connections. – chrisp Aug 31 '15 at 17:42
  • Start with the common network troubleshooting tools like ping, traceroute etc. – aergistal Sep 01 '15 at 07:39
0

You don't have enough bandwidth available to receive this stream (or to send it alternatively).

The RTP: missed packet message tells you so. Going through TCP can only make things worst, not better, since TCP use more bandwidth for headers and the AIMD algorithm used to fit the channel's bandwidth will loose more packet (Additive increase multiplicative decrease).

There is nothing you can do, except reducing the encoding bitrate (if you have control on it), improve buffering (if you have control on it), or use a different protocol that'll pre-buffer the stream.

xryl669
  • 3,376
  • 24
  • 47