headers
Michael McCandless | 18 May 2013 23:42

No data from the VND.ONVIF.METADATA subsession

I'm using testRTSPClient to pull an RTSP stream, and I noticed the
camera provides two subsessions:

  [URL:"..."]: Initiated the "video/H264" subsession (client ports 56266-56267)
  [URL:"..."]: Set up the "video/H264" subsession (client ports 56266-56267)
  [URL:"..."]: Created a data sink for the "video/H264" subsession
  [URL:"..."]: Initiated the "application/VND.ONVIF.METADATA" subsession (client ports 49032-49033)
  [URL:"..."]: Set up the "application/VND.ONVIF.METADATA" subsession (client ports 49032-49033)
  [URL:"..."]: Created a data sink for the "application/VND.ONVIF.METADATA" subsession
  [URL:"..."]: Started playing session...

And then I proceed to get many frames, but only for the video/H264
subsession.  I never see any data sent to the afterGettingFrame for
the application/VND.ONVIF.METADATA subsession ... is this expected?

I thought this subsession might provide details from the camera like
maybe motion detection events or something (just a guess)...

Or is there something different I need to do to "start" the metadata
stream?

Thanks!

Mike

_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Permalink | Reply | 0 comments |
headers
Eric HEURTEL | 17 May 2013 13:19

Patch : Modification of Client MediaSession & Subsession to extend SDP attributes in derived class.


>> I think MediaSession::initializeWithSDP() is not parsing first SDP line (which is usually v=0, though unused).
> No, that is incorrect.  The existing code works correctly, parsing all SDP lines.  You're on a 'wild goose chase'.

Perhaps I miss something, but the following spy shows that first SDP 
line is not analyzed.

      //##### We should really check for:
      // - "a=control:" attributes (to set the URL for aggregate control)
      // - the correct SDP version (v=0)
      if (sdpLine[0] == 'm') break;
+fprintf( stderr, "Parsing %.3s\n", sdpLine );

      // Check for various special SDP lines that we understand:

Anyway, I had to modify Client MediaSession & MediaSubsession classes in 
order to be able to extend SDP attributes in derived class (as I exposed 
you some weeks ago).
Here is the patch, including previous correction (is there a preferred 
way to publish code changes to fulfill the LGPL ?).

diff -r 586a4d995691 -r 9b2ceb7000ee liveMedia/MediaSession.cpp
--- a/liveMedia/MediaSession.cpp    mer. sept. 12 13:13:54 2012 +0200
+++ b/liveMedia/MediaSession.cpp    ven. mai 17 12:27:20 2013 +0200
 <at>  <at>  -102,25 +102,23  <at>  <at> 
    if (sdpDescription == NULL) return False;

    // Begin by processing all SDP lines until we see the first "m="
-  char const* sdpLine = sdpDescription;
-  char const* nextSDPLine;
+  char const* sdpLine;
+  char const* nextSDPLine = sdpDescription;
    while (1) {
+    sdpLine = nextSDPLine;
+    if (sdpLine == NULL) break; // there are no m= lines at all
      if (!parseSDPLine(sdpLine, nextSDPLine)) return False;
+
      //##### We should really check for:
      // - "a=control:" attributes (to set the URL for aggregate control)
      // - the correct SDP version (v=0)
      if (sdpLine[0] == 'm') break;
-    sdpLine = nextSDPLine;
-    if (sdpLine == NULL) break; // there are no m= lines at all

      // Check for various special SDP lines that we understand:
      if (parseSDPLine_s(sdpLine)) continue;
      if (parseSDPLine_i(sdpLine)) continue;
      if (parseSDPLine_c(sdpLine)) continue;
-    if (parseSDPAttribute_control(sdpLine)) continue;
-    if (parseSDPAttribute_range(sdpLine)) continue;
-    if (parseSDPAttribute_type(sdpLine)) continue;
-    if (parseSDPAttribute_source_filter(sdpLine)) continue;
+    if (parseSDPAttributes(sdpLine)) continue;
    }

    while (sdpLine != NULL) {
 <at>  <at>  -207,13 +205,7  <at>  <at> 
        // Check for various special SDP lines that we understand:
        if (subsession->parseSDPLine_c(sdpLine)) continue;
        if (subsession->parseSDPLine_b(sdpLine)) continue;
-      if (subsession->parseSDPAttribute_rtpmap(sdpLine)) continue;
-      if (subsession->parseSDPAttribute_control(sdpLine)) continue;
-      if (subsession->parseSDPAttribute_range(sdpLine)) continue;
-      if (subsession->parseSDPAttribute_fmtp(sdpLine)) continue;
-      if (subsession->parseSDPAttribute_source_filter(sdpLine)) continue;
-      if (subsession->parseSDPAttribute_x_dimensions(sdpLine)) continue;
-      if (subsession->parseSDPAttribute_framerate(sdpLine)) continue;
+      if (subsession->parseSDPAttributes(sdpLine)) continue;

        // (Later, check for malformed lines, and other valid SDP 
lines#####)
      }
 <at>  <at>  -330,6 +322,16  <at>  <at> 
    return False;
  }

+// new virtual method. Must be called by derived method.
+Boolean MediaSession::parseSDPAttributes(char const* sdpLine) {
+    // Check for various special SDP lines that we understand:
+    if (parseSDPAttribute_control(sdpLine)) return True;
+    if (parseSDPAttribute_range(sdpLine)) return True;
+    if (parseSDPAttribute_type(sdpLine)) return True;
+    if (parseSDPAttribute_source_filter(sdpLine)) return True;
+    return False;
+}
+
  Boolean MediaSession::parseSDPAttribute_type(char const* sdpLine) {
    // Check for a 
"a=type:broadcast|meeting|moderated|test|H.332|recvonly" line:
    Boolean parseSuccess = False;
 <at>  <at>  -919,6 +921,18  <at>  <at> 
    return sscanf(sdpLine, "b=AS:%u", &fBandwidth) == 1;
  }

+// new virtual method. Must be called by derived method.
+Boolean MediaSubsession::parseSDPAttributes(char const* sdpLine) {
+    if (parseSDPAttribute_rtpmap(sdpLine)) return True;
+    if (parseSDPAttribute_control(sdpLine)) return True;
+    if (parseSDPAttribute_range(sdpLine)) return True;
+    if (parseSDPAttribute_fmtp(sdpLine)) return True;
+    if (parseSDPAttribute_source_filter(sdpLine)) return True;
+    if (parseSDPAttribute_x_dimensions(sdpLine)) return True;
+    if (parseSDPAttribute_framerate(sdpLine)) return True;
+    return False;
+}
+
  Boolean MediaSubsession::parseSDPAttribute_rtpmap(char const* sdpLine) {
    // Check for a "a=rtpmap:<fmt> <codec>/<freq>" line:
    // (Also check without the "/<freq>"; RealNetworks omits this)
diff -r 586a4d995691 -r 9b2ceb7000ee liveMedia/include/MediaSession.hh
--- a/liveMedia/include/MediaSession.hh    mer. sept. 12 13:13:54 2012 +0200
+++ b/liveMedia/include/MediaSession.hh    ven. mai 17 12:27:20 2013 +0200
 <at>  <at>  -103,6 +103,7  <at>  <at> 
    Boolean parseSDPLine_s(char const* sdpLine);
    Boolean parseSDPLine_i(char const* sdpLine);
    Boolean parseSDPLine_c(char const* sdpLine);
+  virtual Boolean parseSDPAttributes(char const* sdpLine);
    Boolean parseSDPAttribute_type(char const* sdpLine);
    Boolean parseSDPAttribute_control(char const* sdpLine);
    Boolean parseSDPAttribute_range(char const* sdpLine);
 <at>  <at>  -284,6 +285,7  <at>  <at> 

    Boolean parseSDPLine_c(char const* sdpLine);
    Boolean parseSDPLine_b(char const* sdpLine);
+  virtual Boolean parseSDPAttributes(char const* sdpLine);
    Boolean parseSDPAttribute_rtpmap(char const* sdpLine);
    Boolean parseSDPAttribute_control(char const* sdpLine);
    Boolean parseSDPAttribute_range(char const* sdpLine);

Regards

E. HEURTEL
Permalink | Reply | 0 comments |
headers
Anthony Griffiths | 16 May 2013 21:41
Picon

newbie: several questions about openrtsp

I'm running centos 5 server - command line only
hi all, newbie here, firstly to my surprise openRTSP actually worked without too much hassle but did throw up a couple of problems.
This is the command that works with my axis 207MW network camera:
openRTSP -d 20 rtsp://<user:password> <at> <cam-ip-afddr>/mpeg4/media.amp
The 20-second video file created has no extension but I can get the file to play by copying it to another location and adding .mp4 to the copy.
However if I use -4 in the command the program throws back "mdatFloating point exception" and terminates. I did the google on this but there are no clear answers. If I add -i the program does create an avi but the resultant file crashes all my players.  Am I missing some component?
Also the audio file is silent. I don't know what kind of audio file rtsp is generating because the filename has no extension and none of my players will play it. Thanks for any pointers.
_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Permalink | Reply | 0 comments |
headers
Terrance Medina | 16 May 2013 19:51

SDP - trouble separating audio/video tracks

I'm streaming audio/video from an IP camera through VLC as the client. I have no documentation on the camera. I need to use rtsp to stream the audio and video channels separately, but I can't seem to get it to work here. Also, from the SDP message it appears to use Live555 v2009.09.28 as its rtsp server. On other cameras I've been able to use something like rtsp://ip:port/control, but it's not working for me here. Below is the sdp message:

Sending request: DESCRIBE rtsp://192.168.1.123/mpeg4 RTSP/1.0
CSeq: 3
User-Agent: LibVLC/2.0.5 (LIVE555 Streaming Media v2012.09.13)
Accept: application/sdp


Received 1308 new bytes of response data.
Received a complete DESCRIBE response:
RTSP/1.0 200 OK
CSeq: 3
Date: Sun, Jan 02 2000 23:48:34 GMT
Content-Base: rtsp://192.168.1.123/mpeg4/
Content-Type: application/sdp
Content-Length: 1147

v=0
o=- 946855189887438 1 IN IP4 192.168.1.123
s=RTSP/RTP stream from Network Video Server
i=mpeg4
t=0 0
a=tool:LIVE555 Streaming Media v2009.09.28
a=type:broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:RTSP/RTP stream from Network Video Server
a=x-qt-text-inf:mpeg4
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:2500
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=640028;sprop-parameter-sets=Z2QAKK2EBUViuKxUdCAqKxXFYqOhAVFYrisVHQgKisVxWKjoQFRWK4rFR0ICorFcVio6ECSFITk8nyfk/k/J8nm5s00IEkKQnJ5Pk/J/J+T5PNzZprQCgDzSpAAAAwHgAABwgYEAAJiWAACrqW974XhEI1A=,aO48sA==;config=0000000167640028ad84054562b8ac5474202a2b15c562a3a1015158ae2b151d080a8ac57158a8e84054562b8ac5474202a2b15c562a3a10248521393c9f27e4fe4fc9f279b9b34d081242909c9e4f93f27f27e4f93cdcd9a6b402803cd2a400000301e00000708181000098960000aba96f7be1784423500000000168ee3cb0
a=x-dimensions: 1280, 960
a=x-framerate: 30
a=control:track1
m=audio 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:256
a=rtpmap:96 MPEG4-GENERIC/16000/2
a=fmtp:96 streamtype=5;profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1408
a=control:track2



Here's what I've tried:
rtsp://192.168.1.123/mpeg4 -- streams both a/v
rtsp://192.168.1.123/track1 -- error, your input can't be opened
rtsp://192.168.1.123/mpeg4/track1 -- error
rtsp//192.168.1.123/mpeg4#track1 -- streams both a/v
rtsp://192.168.1.123/foobar/mpeg4 -- streams both a/v
rtsp://192.168.1.123/mpeg4/foobar -- error

In the VLC toolbar, I can select Video-->VideoTrack-->Disable, to turn off the video, but I need to be able to do this with the rtsp url. Not sure if there's some finer point of the url syntax that I'm missing, but perusing the RFC's hasn't really helped so far.

Thanks!
_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Permalink | Reply | 0 comments |
headers
Eric HEURTEL | 16 May 2013 17:06

SDP first line is skipped

Hi,

I think MediaSession::initializeWithSDP() is not parsing first SDP line (which is usually v=0, though unused).
I've corrected it as follow:

  // Begin by processing all SDP lines until we see the first "m="
  char const* sdpLine;
  char const* nextSDPLine = sdpDescription;
  while (1) {
    sdpLine = nextSDPLine;
    if (sdpLine == NULL) break; // there are no m= lines at all
    if (!parseSDPLine(sdpLine, nextSDPLine)) return False;

    //##### We should really check for:
    // - "a=control:" attributes (to set the URL for aggregate control)
    // - the correct SDP version (v=0)
    if (sdpLine[0] == 'm') break;

    // Check for various special SDP lines that we understand:
    if (parseSDPLine_s(sdpLine)) continue;
    ...
  }

Eric
_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Permalink | Reply | 0 comments |
headers
Alex Shihmanter | 13 May 2013 07:38
Picon

Streaming H.264 Movie via RTP

Hi,

 

I'm streaming an H264 movie using live555. I figured out you need an SDP file in order to play the stream in VLC, so I built one and was able to play my stream. The problem is, after I upgraded my VLC to 2.0.5, the VLC won't play my stream.

 

The SDP file I use is:

 

v=0

o=- 1277647151953158 1 IN IP4 190.40.14.100

s=Session streamed by "testH264VideoAudioStreamer"

i=test-h264-mux.mpg

t=0 0

a=tool:LIVE555 Streaming Media v2007.05.24

a=recvonly

a=type:broadcast

a=charset:UTF-8

a=source-filter: incl IN IP4 * 190.40.14.100

m=video 8554 RTP/AVP 96

c=IN IP4 190.40.15.10/7

a=rtpmap:96 H264/90000

a=fmtp:96 packetization-mode=1; profile-level-id=64001f;sprop-parameter-sets=Z2QAH6zZQLQ9sBEAAAMD6QAB1MCPGDGW,aOvjyyLA;

 

I know it's not a networking problem. Somehow, the VLC 2.0.5 won't play my SDP file, even though the 1.1.11 version of VLC can play it.

 

The VLC 2.0.5 says: "live555 error: no data received in 10s, aborting"

 

This could possibly be a problem in VLC as if I stream the movie through VLC (instead of live555) I can't see the movie also (same problem).

 

After further examination, I found a workaround: I've discovered that the VLC 2.0.5 can stream the H.264 movie (any movie basically) in a method called RTP / MPEG Transport Stream. If I stream through VLC the H.264 movie, I can play it well in VLC 2.0.5 (without the need in an SDP file). Is there a streaming method like this in the live555 that I can choose to stream in (the SDP packets of VLC says it's MP2T)?

 

Is something missing in my SDP? Or Is there an option in live555 that can stream H264 as MPEG Transport Stream?

 

Any help would be much appreciated.

 

Thanks,

Guy.

 

_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Permalink | Reply | 0 comments |
headers
Braden Ackerman | 10 May 2013 19:50
Favicon
Gravatar

Audio skipping - Seems to be timing related

Greetings,

Thank you Ross for your response mid-week.
I believe I've correctly implemented your suggestion, but I'm still experiencing the same issue.

Recap: I'm trying to send mu-law audio over RTP. The audio comes from the microphone on an ios device, via AudioQueue. 

I'm following testWaveAudioStreamer.
I've subclassed FramedSource and pass the audio through uLawFromPCMAudioSource after it's stored in a circular FIFO buffer (after being returned from the ios AudioQueue callback after mic capture).

Issue: I get "skipping" ~ 0.5 sec audio, then ~ 0.5 sec silence.
The buffer is still under running (causing a sleep in deliverFrame() which I believe should never be happening once I have this correctly implemented).

As per Ross' excellent suggestion I've set fDurationInMicroseconds like this:

    int fNumChannels =1;

    int fBitsPerSample = 16;

    int fSamplingFrequency = 8000;

     unsigned fPlayTimePerSample = 1e6/(double)fSamplingFrequency;

      unsigned bytesPerSample = (fNumChannels*fBitsPerSample)/8;

    fDurationInMicroseconds =(unsigned)((fPlayTimePerSample*fFrameSize)/bytesPerSample);

-----

The fDurationInMicroseconds works out to 500000 microseconds, which would make sense as each buffer returned from the ios AudioQueue is about 0.5 seconds. 

I'll paste some output from VLC. If anyone can point me in the right direction to correct my error here I'd appreciate it immensely.

FYI, I'll be posting this code publicly once it's working for all to use.

Thanks so much for your time, and the hard work on an excellent library.

Best regards,

Braden Ackerman

VLC complains like this: 

main warning: timing screwed, stopping resampling

main warning: buffer too late (179500), up-sampling

main warning: buffer way too late (358875), dropping buffer

main warning: buffer way too late (230875), dropping buffer

main warning: buffer way too late (356000), dropping buffer

main warning: buffer way too late (228000), dropping buffer

main warning: buffer way too late (356000), dropping buffer

main warning: buffer way too late (228000), dropping buffer

main warning: buffer way too late (356000), dropping buffer

main warning: buffer way too late (347500), dropping buffer

main warning: buffer way too late (219500), dropping buffer

main warning: buffer way too late (347500), dropping buffer

main warning: buffer way too late (219500), dropping buffer

main warning: buffer way too late (347500), dropping buffer

main warning: buffer way too late (219500), dropping buffer

main debug: audio output is starving (-720558), playing silence

main warning: buffer way too late (322098), dropping buffer

main warning: buffer way too late (194098), dropping buffer

main warning: buffer way too late (322098), dropping buffer

main warning: buffer way too late (194098), dropping buffer

main warning: buffer way too early (-177606), clearing queue

main warning: timing screwed, stopping resampling

main warning: buffer too early (-51609), down-sampling

main warning: timing screwed, stopping resampling

main warning: buffer too late (128016), up-sampling

main warning: buffer way too early (-231484), clearing queue

main warning: timing screwed, stopping resampling

main warning: buffer way too late (245727), dropping buffer

main warning: buffer too late (117727), up-sampling

main warning: buffer way too late (297227), dropping buffer

main warning: buffer way too early (-126440), clearing queue

main warning: timing screwed, stopping resampling

main warning: buffer way too late (195604), dropping buffer

main warning: buffer too late (67604), up-sampling

main warning: audio output out of sync, adjusting dates (-44447 us)

main warning: computed PTS is out of range (36360), clearing out

main warning: timing screwed, stopping resampling

main warning: not synchronized (-44445 us), resampling

main warning: buffer too early (-44445), down-sampling

main debug: audio output is starving (-971888), playing silence

rtp warning: 1 packet(s) lost

main debug: End of audio preroll

rtp warning: 1 packet(s) lost

main debug: End of audio preroll

main warning: resampling stopped after 1060698 usec (drift: 0)

main warning: buffer too late (179500), up-sampling

rtp warning: 1 packet(s) lost

rtp warning: 1 packet(s) lost

main debug: End of audio preroll

main warning: resampling stopped after 894671 usec (drift: -179375)

rtp warning: 1 packet(s) lost

main debug: End of audio preroll

main warning: buffer too late (179500), up-sampling

main warning: buffer way too early (-370330), clearing queue

main warning: timing screwed, stopping resampling


_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Permalink | Reply | 0 comments |
headers
Kalkere, Giridhara(IE10 | 10 May 2013 04:07
Picon
Favicon

Setting the frame rate and resolution during the rtsp connection

Dear Ross,

 

I am using the LIVE555 Frame work for the IP camera streaming.

 

Basically camera is set for a frame rate and resolution. I can set these parameters in the camera web page.

But would like to stream the camera with my own framerate and resolution, this will be decided dynamically.   

 

I am using the RTSPClient class to establish the connection.

 

It will be great if you can guide me to handle this scenario.

Is there any facility or mechanism in the LIVE55 framework to do this?

 

Thanks and Regards,

Giri

_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Permalink | Reply | 0 comments |
headers
Matt Schuckmann | 9 May 2013 21:04
Favicon

A couple of minor issues

I just thought I'd bring up a couple of minor code issues that I 
recently ran into.

1. config.armlinux has carriage return line feed line endings and none 
of the other config files have this. Normally I wouldn't care but my 
automated build system uses quilt and patch to add -D defines to the 
compile options and patch under cygwin has problems with this type of 
line ending. I can work around it but it is annoying and it took me a 
while to figure out what the problem was.

2. Why is Boolean a #define, for MSC and BORLAND compilers this is 
really bad form. Currently it is causing me problems with boost template 
code that uses  Boolean for a typename in a template, can it be a typedef?

3. What is the deal with header files directly in liveMeda (i.e. not in 
liveMedia/include) I would assume that we are not supposed to use them 
but one of my developers recently used the BitVector.hh header, which 
seems reasonably general purpose should it be moved to the include 
directory?

Thanks,
Matt S.
Permalink | Reply | 0 comments |
headers
Marathe, Yogesh | 8 May 2013 06:12
Picon
Favicon

SRTP support

Does live555 support SRTP?

 

Regards,

Yogesh.

 

_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Permalink | Reply | 0 comments |
headers
John Senior | 8 May 2013 00:24
Favicon

Potential enhancement for SAP/SDP parser

Hello live555 Support,

I work for VBrick Systems and VLC is popular with our streaming appliance customers.  We've received
several requests to make VBrick's H.264 live streaming appliance SAPs compatible with the VLC SAP
listener. (VBrick MPEG-2 and Windows Media streaming appliance SAPs are already compatible with VLC.)
Our experiments show that one line in our H.264 SAP is causing the trouble -- the time description line, or "t=0,0".
This is an example of our H.264 SAP message that will not appear on the VLC playlist:

v=0
o=- 0000000000 1 IN IP4 172.22.113.64
s=JohnS-7000 Program 1
i=VBrick Streaming Video
c=IN IP4 239.22.113.66/63
b=AS:8102
a=packetsize:1452
a=packetformat:RAW
a=mux:m2t
a=author:My Author
a=copyright:My Copyright
a=X-StreamID:T2
a=tool:VBrick 3.0.0
t=0,0
m=video 4444 udp 33
a=X-H264_TTSVidV1
m=audio 4444 udp 36
a=X-H264_TTSAudV1

But our experiments show that just a minor modification to move the t=0,0 line above the attribute lines
will get it to appear on the VLC playlist, like this:

v=0
o=- 0000000000 1 IN IP4 172.22.113.64
s=JohnS-7000 Program 1
i=VBrick Streaming Video
c=IN IP4 239.22.113.66/63
b=AS:8102
t=0,0
a=packetsize:1452
a=packetformat:RAW
a=mux:m2t
a=author:My Author
a=copyright:My Copyright
a=X-StreamID:T2
a=tool:VBrick 3.0.0
m=video 4444 udp 33
a=X-H264_TTSVidV1
m=audio 4444 udp 36
a=X-H264_TTSAudV1

The VLC SAP configuration options "Try to parse the announce" and "SAP Strict mode" do not seem to affect
VLC's behavior with our H.264 SAPs.

Unfortunately, we are reluctant to change this on our side because we deliberately moved the "t=0,0" line
in our newer H.264 appliances (as compared to our older MPEG-2 appliances) to achieve better alignment
with Section 5 of RFC 4566:

 Some lines in each description are REQUIRED and some are OPTIONAL,
 but all MUST appear in exactly the order given here (the fixed order
 greatly enhances error detection and allows for a simple parser).
 OPTIONAL items are marked with a "*".
 Session description
 v= (protocol version)
 o= (originator and session identifier)
 s= (session name)
 i=* (session information)
 u=* (URI of description)
 e=* (email address)
 p=* (phone number)
 c=* (connection information -- not required if included in
 all media)
 b=* (zero or more bandwidth information lines)
 One or more time descriptions ("t=" and "r=" lines; see below)
 z=* (time zone adjustments)
 k=* (encryption key)
 a=* (zero or more session attribute lines)
 Zero or more media descriptions

 Time description
 t= (time the session is active)
 r=* (zero or more repeat times)

 Media description, if present
 m= (media name and transport address)
 i=* (media title)
 c=* (connection information -- optional if included at
 session level)
 b=* (zero or more bandwidth information lines)
 k=* (encryption key)
 a=* (zero or more media attribute lines)

I posted this information to the VLC developer forum and I was told that in this case the SAP/SDP parsing is
being handled by the live555 library that in integrated with VLC. (VLC version is 2.0.6)  Would the live555
supporters consider enhancing their SAP/SDP parser to be more flexible and more compatible with RFC 4566?

Thanks for your help.

Regards,

- John

John Senior  |  VP of Systems Engineering  |  VBrick Systems, Inc.  |  203-303-0117  |  johns <at> vbrick.com<mailto:johns <at> vbrick.com>
Permalink | Reply | 0 comments |

Gmane