Re: [Live-devel] correct way to use TaskScheduler::unscheduleDelayedTask?

2016-09-01 Thread Helmut Grohne 
On Fri, Aug 26, 2016 at 08:48:23AM -0600, Ross Finlayson wrote:
> > On Fri, Aug 26, 2016 at 12:07:45PM +0200, Ross Finlayson wrote:
> >> Yes, you are correct here.  Fortunately, there is an easy fix (which I’ll 
> >> add to the code in the near future): Set “fNext” to NULL at the start of 
> >> the handler function (“sendNext()”).  Ditto for the other places in the 
> >> code where the same thing is done.
> > 
> > That's exactly what my patch does.
> 
> No, it’s not.  Your patch does a whole lot more (all of the “afterGetting()” 
> changes).  There’s no way I’m going to apply such a large patch to the code 
> base (especially because, as I noted before, the proper long term solution 
> (replacing the “fNextTask” mechanism entirely) will be a non-trivial change 
> as well).

The sole purpose of those changes is to separate those afterGetting
calls into ones that do set fNextTask to NULL and those that don't.

I do agree though that applying it as is may be harmful, because it
breaks API, because the API is broken and it is impossible to correctly
use it. I also agree that replacing the fNextTask mechanism would be
even better.

It appears that your 2016.08.27 release did pull the bulk of the other
changes of my patch. Thank you.

> Well, maybe - but I don’t see the point of having two or more threads share a 
> single (special, thread-safe) “TaskScheduler” (subclass) object, while 
> (somehow) making sure that the threads don't share access to any other 
> LIVE555 object.  Why not just have the threads use different “TaskScheduler” 
> (and “UsageEnvironment”) objects - something that’s much safer?  But anyway, 
> if you want to go the route of writing and using your own single (special, 
> thread-safe) “TaskScheduler” (subclass) object, you’re on your own.  That’s 
> not something that I’m going to endorse.

Let me propose a good reaons to use a TaskScheduler from multiple
threads: Consider an application that separates stream capture and
stream delivery (using liveMedia) into different threads. Then captured
frames need to be communicated to liveMedia for transmission. It seems
that a good way to do so is creating a trigger and then passing frames
via TaskScheduler::triggerEvent from the capturing thread. Thus the only
method that non-liveMedia threads invoke is TaskScheduler::triggerEvent
and this seems to already be endorsed by the FAQ, no?

Quoting the FAQ:
| Note that "triggerEvent()" is the only LIVE555 function that may be
| called from an external (i.e., non-LIVE555) thread.

The reason that I am using my own TaskScheduler instead of
BasicTaskScheduler is that BasicTaskScheduler::triggerEvent is not
thread-safe.

Using different TaskScheduler objects is not possible, because the
purpose of sharing the same object is to mediate communication (via
triggerEvent). Using different objects would mean never delivering any
frames.

Helmut
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

[Live-devel] Fragmented intra frames

2016-09-01 Thread sampsa 

Hi,

I am casting a webcam as H264 with ffmpeg ..

.. and then I pass the sdp file (and mediasession/subsessions) to the 
live555 library.


My sink is based on the example "DummySink" class and works ok with a 
variety of webcams.


However, with ffmpeg casted stream, I get frames along these lines (this 
is what "afterGettingFrame" of my modified DummySink passes me):


nal_unit_type : 7 ( Sequence parameter set )
nal_unit_type : 8 ( Picture parameter set )
nal_unit_type : 5 ( Coded slice of an IDR picture )
nal_unit_type : 5 ( Coded slice of an IDR picture )
nal_unit_type : 5 ( Coded slice of an IDR picture )
nal_unit_type : 5 ( Coded slice of an IDR picture )
nal_unit_type : 1 ( Coded slice of a non-IDR picture )
nal_unit_type : 1 ( Coded slice of a non-IDR picture )

It seems that the I frame is in multiple slices.  I assumed that live555 
would compose the slices and give me the I frames as a single slice/nal 
unit.


Is there some H264DiscreteFramer kind of filter I should be using?

Regards,

S.


___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

[Live-devel] Live555 Proxy Server sometimes does not proxy source after connection loss

2016-09-01 Thread Erik Montnemery 
Hi,

Most of the time, the proxy server reconnects to the source after a
loss of connection to a source, but every now and then I observe one
of the following issues:
1) The proxyserver reconnects to the source, but no data frames are
forwarded to the clients.
An example log of scenario 1) is pasted below

2) The proxy server does not reconnect to the source, and clients to
the proxy server are being told:
RTSP/1.0 404 File Not Found, Or In Incorrect Format
An example log of scenario 2) is pasted below

Any suggestions for how to debug this further are most welcome.

I'm able to reproduce the issues by forcing a source to reconnect to
the network, but it's not 100% reproducible.
1) seems much more difficualt to reproduce than 2).

/Erik

Log 1)
Aug 11 09:12:21 Sending request: OPTIONS
rtsp://192.168.0.124/ch0_0.h264/ RTSP/1.0
Aug 11 09:12:21 CSeq: 73552
Aug 11 09:12:21 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media
v2016.06.26)
Aug 11 09:12:21 Session: 6B8B4567
Aug 11 09:12:21
Aug 11 09:12:21
Aug 11 09:12:21 Received 156 new bytes of response data.
Aug 11 09:12:21 Received a complete OPTIONS response:
Aug 11 09:12:21 RTSP/1.0 200 OK
Aug 11 09:12:21 CSeq: 73552
Aug 11 09:12:21 Date: Thu, Aug 11 2016 15:14:58 GMT
Aug 11 09:12:21 Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY,
PAUSE, GET_PARAMETER, SET_PARAMETER
Aug 11 09:12:21
Aug 11 09:12:21
<- Client stops receiving data around here
Aug 11 09:12:29 Sending request: OPTIONS
rtsp://192.168.0.125/ch0_0.h264/ RTSP/1.0
Aug 11 09:12:29 CSeq: 73589
Aug 11 09:12:29 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media
v2016.06.26)
Aug 11 09:12:29 Session: 66334873
Aug 11 09:12:29
Aug 11 09:12:29
Aug 11 09:12:29 Received 156 new bytes of response data.
Aug 11 09:12:29 Received a complete OPTIONS response:
Aug 11 09:12:29 RTSP/1.0 200 OK
Aug 11 09:12:29 CSeq: 73589
Aug 11 09:12:29 Date: Thu, Aug 11 2016 15:15:05 GMT
Aug 11 09:12:29 Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY,
PAUSE, GET_PARAMETER, SET_PARAMETER
Aug 11 09:12:29
Aug 11 09:12:29
<- A new client is spawned and makes a new connection to the proxy
server here
Aug 11 09:12:51 Opening connection to 192.168.0.124, port 554...
Aug 11 09:12:53
ProxyServerMediaSubsession[rtsp://192.168.0.124/ch0_0.h264/,H264]::closeStreamSource()
Aug 11 09:12:53
ProxyServerMediaSubsession[rtsp://192.168.0.124/ch0_0.h264/,MPEG4-GENERIC]::closeStreamSource()
Aug 11 09:12:59 Sending request: OPTIONS
rtsp://192.168.0.125/ch0_0.h264/ RTSP/1.0
Aug 11 09:12:59 CSeq: 73590
Aug 11 09:12:59 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media
v2016.06.26)
Aug 11 09:12:59 Session: 66334873
Aug 11 09:12:59
Aug 11 09:12:59
Aug 11 09:12:59 Received 156 new bytes of response data.
Aug 11 09:12:59 Received a complete OPTIONS response:
Aug 11 09:12:59 RTSP/1.0 200 OK
Aug 11 09:12:59 CSeq: 73590
Aug 11 09:12:59 Date: Thu, Aug 11 2016 15:15:35 GMT
Aug 11 09:12:59 Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY,
PAUSE, GET_PARAMETER, SET_PARAMETER
Aug 11 09:12:59
Aug 11 09:12:59
Aug 11 09:13:06 ...remote connection opened
Aug 11 09:13:06 Sending request: OPTIONS
rtsp://192.168.0.124/ch0_0.h264/ RTSP/1.0
Aug 11 09:13:06 CSeq: 73553
Aug 11 09:13:06 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media
v2016.06.26)
Aug 11 09:13:06 Session: 6B8B4567
Aug 11 09:13:06
Aug 11 09:13:06
Aug 11 09:13:06 Sending request: PAUSE rtsp://192.168.0.124/ch0_0.h264/ RTSP/1.0
Aug 11 09:13:06 CSeq: 73554
Aug 11 09:13:06 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media
v2016.06.26)
Aug 11 09:13:06 Session: 6B8B4567
Aug 11 09:13:06
Aug 11 09:13:06
Aug 11 09:13:06 Received 156 new bytes of response data.
Aug 11 09:13:06 Received a complete OPTIONS response:
Aug 11 09:13:06 RTSP/1.0 200 OK
Aug 11 09:13:06 CSeq: 73553
Aug 11 09:13:06 Date: Thu, Jan 01 1970 00:00:37 GMT
Aug 11 09:13:06 Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY,
PAUSE, GET_PARAMETER, SET_PARAMETER
Aug 11 09:13:06
Aug 11 09:13:06
Aug 11 09:13:09
ProxyServerMediaSubsession[rtsp://192.168.0.124/ch0_0.h264/,H264]::createNewStreamSource(session
id 1614683546)
Aug 11 09:13:09 Sending request: PLAY rtsp://192.168.0.124/ch0_0.h264/ RTSP/1.0
Aug 11 09:13:09 CSeq: 73555
Aug 11 09:13:09 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media
v2016.06.26)
Aug 11 09:13:09 Session: 6B8B4567
Aug 11 09:13:09
Aug 11 09:13:09
Aug 11 09:13:09
ProxyServerMediaSubsession[rtsp://192.168.0.124/ch0_0.h264/,H264]::createNewRTPSink()
Aug 11 09:13:09
ProxyServerMediaSubsession[rtsp://192.168.0.124/ch0_0.h264/,MPEG4-GENERIC]::createNewStreamSource(session
id 1614683546)
Aug 11 09:13:09
ProxyServerMediaSubsession[rtsp://192.168.0.124/ch0_0.h264/,MPEG4-GENERIC]::createNewRTPSink()
Aug 11 09:13:09 Received 68 new bytes of response data.
Aug 11 09:13:09 WARNING: The server did not respond to our "PAUSE"
request (CSeq: 73554).  The server appears to be buggy (perhaps not
handling pipelined requests properly).
Aug 11 09:13:09 Received a complete PLAY response:
Aug 11 09:13:09 RTSP/1.0 200 OK
Aug 11 09:13:09 CSeq:

[Live-devel] (no subject)

2016-09-01 Thread Cristian Jerez 
Hi,

 

I need help with SAP/SDP.

Can anyone point me to a working software implementation that has SAP
working?

I'm working with RTP streams and would like to use SAP to send the SDP, I
find it very impractical to use a SDP file.

 

Regards

 

Cristian Jerez

___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel