java通信vlc的缓冲问题 [英] buffering issue with java communicating vlc

问题描述

我是 Socket 通信的新手，所以我可能是错的，但请提供建议或至少给出方向！

I'm a newbie to Socket communication, so I may be wrong, but please advice or at least give the direction!

我正在根据 http://www.csee.umbc.edu/~pmundur/courses/CMSC691C/lab5-kurose-ross.html#appendix 查看 http://www.java2s.com/Open-Source/Android/UnTagged/mynpr/com/webeclubbin/mynpr/RTSPserver.java.htm

I'm implementing an RTSP server according to http://www.csee.umbc.edu/~pmundur/courses/CMSC691C/lab5-kurose-ross.html#appendix taking a look to the similar code from http://www.java2s.com/Open-Source/Android/UnTagged/mynpr/com/webeclubbin/mynpr/RTSPserver.java.htm

目前我正在响应 OPTIONS 请求.为了使第一种方法更容易，我决定根据为 vlc 和 gstreamer rtsp 之间的一些实际通信完成的示例 RTSP 请求/响应日志对答案进行硬编码.

At the moment I'm implementing responce to the OPTIONS request. To make it easy in the first approach, I decided to hardcode the answer according to the sample RTSP request/response log done for some real communication between vlc and gstreamer rtsp.

所以，用 vlc URL -vvv 记录的日志说:

So, the log recorded with vlc URL -vvv says:

Sending request: OPTIONS rtsp://localhost:8554/test RTSP/1.0
CSeq: 2
User-Agent: LibVLC/2.0.8 (LIVE555 Streaming Media v2013.04.30)


Received 183 new bytes of response data.
Received a complete OPTIONS response:
RTSP/1.0 200 OK
CSeq: 2
Public: OPTIONS, DESCRIBE, GET_PARAMETER, PAUSE, PLAY, SETUP, SET_PARAMETER, TEARDOWN
Server: GStreamer RTSP server
Date: Tue, 10 Sep 2013 19:56:53 GMT


Sending request: DESCRIBE rtsp://localhost:8554/test RTSP/1.0
CSeq: 3
User-Agent: LibVLC/2.0.8 (LIVE555 Streaming Media v2013.04.30)
Accept: application/sdp

即

RTSP/1.0 200 OK
CSeq: 2
Public: OPTIONS, DESCRIBE, GET_PARAMETER, PAUSE, PLAY, SETUP, SET_PARAMETER, TEARDOWN
Server: GStreamer RTSP server
Date: Tue, 10 Sep 2013 19:56:53 GMT

部分长度为 183 字节

part is 183 bytes length

我正在根据示例写入缓冲区:

I'm writing to the buffer right according to the example:

 try{
        System.out.println("S -> C");
        System.out.println("RTSP/1.0 200 OK");
        System.out.println("CSeq: "+RTSPSeqNb);
        //System.out.println("Session: "+RTSP_ID);
        if (responceType==OPTIONS) {System.out.println("Public: OPTIONS, DESCRIBE, GET_PARAMETER, PAUSE, PLAY, SETUP, SET_PARAMETER, TEARDOWN");};
        if (responceType==OPTIONS) {System.out.println("Server: GStreamer RTSP server");                                                        };
        if (responceType==OPTIONS) {System.out.println("Date: Tue, 10 Sep 2013 19:56:53 GMT");};
        RTSPBufferedWriter.write("RTSP/1.0 200 OK"+CRLF);
        RTSPBufferedWriter.write("CSeq: "+RTSPSeqNb+CRLF);
        //RTSPBufferedWriter.write("Session: "+RTSP_ID+CRLF);
        if (responceType==OPTIONS) {RTSPBufferedWriter.write("Public: OPTIONS, DESCRIBE, GET_PARAMETER, PAUSE, PLAY, SETUP, SET_PARAMETER, TEARDOWN"+CRLF);};
        if (responceType==OPTIONS) {RTSPBufferedWriter.write("Server: GStreamer RTSP server"+CRLF);                                                        };
        if (responceType==OPTIONS) {RTSPBufferedWriter.write("Date: Tue, 10 Sep 2013 19:56:53 GMT"+CRLF);            };
        RTSPBufferedWriter.write("Session: "+RTSP_ID+"\r"+CRLF);
        RTSPBufferedWriter.flush();

        //RTSPBufferedWriter.newLine();
        System.out.println("RTSP Server - Sent response to Client.");

    }
    catch(IOException ex)
    {
        System.out.println("Exception caught: "+ex.getStackTrace());
        //    System.exit(0);
    }

和 vlc 日志说

Opening connection to 127.0.0.1, port 6666...
...remote connection opened
Sending request: OPTIONS rtsp://127.0.0.1:6666/autostream.mjpg RTSP/1.0
CSeq: 2
User-Agent: LibVLC/2.0.8 (LIVE555 Streaming Media v2013.04.30)


Received 193 new bytes of response data.
[0x7fd01c001178] live555 demux debug: connection timeout
[0x7fd01c001178] live555 demux error: Failed to connect with rtsp://127.0.0.1:6666/autostream.mjpg

其中 CRLF 是 '\n'.在我用

Where CRLF is '\n'. Before I tried CRLF="\r\n" (and no +"\r"+ in the last line) with

Received 198 new bytes of response data.

那么，有什么问题吗?vlc在等什么?为什么示例中的默认分隔符不起作用?

So, what is wrong there? What vlc is waiting for? Why default delimeters from the example doesn't work for it?

推荐答案

在我将问题发布到 stackoverflow 之后，我似乎总能找到答案...

I looks like I always find the answer to my questions after I publish them to stackoverflow...

DOUBLE CRLF 应该放在通常 RTSP 协议的最后一个标头之后9，而不是示例中使用的自定义标头).

DOUBLE CRLF should stand after the last header for the usual RTSP protocol 9not the customized one used in the example).

这篇关于java通信vlc的缓冲问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！