[Live-devel] UDP packets appear to be empty, forcing switch to TCP in VLC

Dave McMordie mcmordie at viionsystems.com
Thu May 7 08:41:20 PDT 2015


On Wed, May 6, 2015 at 5:23 PM, Ross Finlayson <finlayson at live555.com>
wrote:

> Thanks for the quick response.  I have upgraded both the client and server
> to the May 3rd 2015 edition and the result appears to be the same.  On
> the receiving side I am still getting packets which appear to contain data
> (or random garbage), and the head == tail, so the frame size is zero.  VLC
> still does the switching to TCP thing.  I suspect I am doing something
> wrong in sending my frames, not sure what.  And if so, why would it work
> over TCP?
>
>
> If the problem were with the data that you were streaming, then it’s
> unlikely that streaming would work over TCP, but not UDP.  But to be sure,
> I suggest first running the (unmodified) “LIVE555 Media Server” application
> <http://www.live555.com/mediaServer/>, to test streaming from a file.  I
> suspect, though, that you’ll see the same result: streaming
> RTP/RTCP-over-TCP will work, but RTP/RTCP-over-UDP won’t.
>
> In my experience, problems with receiving RTP/RTCP-over-UDP are almost
> always caused by the presence of a firewall - somewhere between the server
> and client - that’s blocking UDP packets.
>

Thanks for suggesting the LIVE555 Media Server.  Using the -t command, I
used openRTSP to capture a .264 file from my RTSP server instance, and then
I serve it using live555MediaServer.  Now openRTSP can stream it without -t
and without any issues (see output below).  My gut is telling me my code is
doing something wrong in the , and this seems to confirm it.

Having ruled out firewall and UDP transmission issues, what else could
cause RTP-over-UDP to fail when RTP-over-TCP works fine?  Or if nothing
comes to mind, what can I look at to understand why your stream works and
mine sends your code a zillion empty UDP packets (when wireshark shows them
full of data)?

Here is how I am sending the encoded frames which I get from libavcodec to
the DeviceSource (in case this rings any alarm bells):

void H264DeviceSource::populateEncodedImage(pEncodedFrameAndMetadata
frameAndMetadata)
{
    boost::shared_ptr<std::vector<unsigned char> > imgbuf =
frameAndMetadata->encodedFrame;

    if (imgbuf.get()==NULL || imgbuf->empty()){
        Log::e( "H264DeviceSource: encoded buffer is NULL or empty" );
        return;
    }

    if( (int)imgbuf->size() > _internal_buffer_size) {
        Log::e( "H264DeviceSource: Image too large for encoding buffer" );
        return;
    }

    int encodedFrameSize = (int)imgbuf->size();

    int offset = 0;

    if (encodedFrameSize > 4)
    {
        if ((*imgbuf)[0] == 0 && (*imgbuf)[1] == 0 && (*imgbuf)[2] == 0 &&
(*imgbuf)[3] == 1)
        {
            // remove leading 0x00 0x00 0x00 0x01
            // our framer doesn't accept it.
            offset = 4;

        }

    }


    int fs = 0;
    // copy the image:
    for (int i=0; i< encodedFrameSize - offset; i++) {
        if (i >= (int)fMaxSize-1){
            Log::e("RTSP: frame truncated");
            break;
        }
        fTo[i] = (*imgbuf)[i + offset];
        fs++;
    }


    fFrameSize = fs;

}

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Here is the streaming output from using live555MediaServer as the rtsp
server instead of my code:


C:\temp>openRTSP -d 60 -w 640 -h 480 -f 30 -Q -n -l -4 rtsp://
127.0.0.1/test.264
 > test.mp4
Opening connection to 127.0.0.1, port 554...
...remote connection opened
Sending request: OPTIONS rtsp://127.0.0.1/test.264 RTSP/1.0
CSeq: 2
User-Agent: openRTSP (LIVE555 Streaming Media v2015.05.03)


Received 152 new bytes of response data.
Received a complete OPTIONS response:
RTSP/1.0 200 OK
CSeq: 2
Date: Thu, May 07 2015 15:27:35 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER,
SET_PARA
METER


Sending request: DESCRIBE rtsp://127.0.0.1/test.264 RTSP/1.0
CSeq: 3
User-Agent: openRTSP (LIVE555 Streaming Media v2015.05.03)
Accept: application/sdp


Received 678 new bytes of response data.
Received a complete DESCRIBE response:
RTSP/1.0 200 OK
CSeq: 3
Date: Thu, May 07 2015 15:27:35 GMT
Content-Base: rtsp://127.0.0.1/test.264/
Content-Type: application/sdp
Content-Length: 519

v=0
o=- 1431012455409337 1 IN IP4 169.254.222.174
s=H.264 Video, streamed by the LIVE555 Media Server
i=test.264
t=0 0
a=tool:LIVE555 Streaming Media v2015.04.01
a=type:broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:H.264 Video, streamed by the LIVE555 Media Server
a=x-qt-text-inf:test.264
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:500
a=rtpmap:96 H264/90000
a=fmtp:96
packetization-mode=1;profile-level-id=4D401E;sprop-parameter-sets=Z01A
HvIBQHtCAAADAAIAAAMAeB4sWiQ=,aOvvIA==
a=control:track1

Opened URL "rtsp://127.0.0.1/test.264", returning a SDP description:
v=0
o=- 1431012455409337 1 IN IP4 169.254.222.174
s=H.264 Video, streamed by the LIVE555 Media Server
i=test.264
t=0 0
a=tool:LIVE555 Streaming Media v2015.04.01
a=type:broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:H.264 Video, streamed by the LIVE555 Media Server
a=x-qt-text-inf:test.264
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:500
a=rtpmap:96 H264/90000
a=fmtp:96
packetization-mode=1;profile-level-id=4D401E;sprop-parameter-sets=Z01A
HvIBQHtCAAADAAIAAAMAeB4sWiQ=,aOvvIA==
a=control:track1

Created receiver for "video/H264" subsession (client ports 60770-60771)
Sending request: SETUP rtsp://127.0.0.1/test.264/track1 RTSP/1.0
CSeq: 4
User-Agent: openRTSP (LIVE555 Streaming Media v2015.05.03)
Transport: RTP/AVP;unicast;client_port=60770-60771


Received 208 new bytes of response data.
Received a complete SETUP response:
RTSP/1.0 200 OK
CSeq: 4
Date: Thu, May 07 2015 15:27:35 GMT
Transport:
RTP/AVP;unicast;destination=127.0.0.1;source=127.0.0.1;client_port=60
770-60771;server_port=6972-6973
Session: 9AFA7842;timeout=65


Setup "video/H264" subsession (client ports 60770-60771)
Outputting to the file: "stdout"
Sending request: PLAY rtsp://127.0.0.1/test.264/ RTSP/1.0
CSeq: 5
User-Agent: openRTSP (LIVE555 Streaming Media v2015.05.03)
Session: 9AFA7842
Range: npt=0.000-60.000


Received 179 new bytes of response data.
Received a complete PLAY response:
RTSP/1.0 200 OK
CSeq: 5
Date: Thu, May 07 2015 15:27:35 GMT
Range: npt=0.000-
Session: 9AFA7842
RTP-Info: url=rtsp://127.0.0.1/test.264/track1;seq=49597;rtptime=783804364


Started playing session
Receiving streamed data (for up to 60.000000 seconds)...
Data packets have begun arriving [1431012455648]


Thanks again for your help.

Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20150507/9dc8b450/attachment.html>


More information about the live-devel mailing list