[Live-devel] Inhibit UDP/RTP streaming

, they fall back on TCP. What I wanted to know was if our server could always force the client to connect in TCP. As far as I know that would imply altering the m= line(s ) in the SDP description, am I correct? Would it be possible to do that easily in LiveMedia? Thank you, Cristiano. -- Belloni

Re: [Live-devel] Synchro problem and isCurrentlyAwaitingData()

Il 06/04/2011 18:49, Cristiano Belloni ha scritto: Il 06/04/2011 12:04, Cristiano Belloni ha scritto: Hi to all, I wrote a custom shared memory source. it inherits from FramedSource. The shared memory is synchronized via Linux semaphores (simple producer-consumer algorithm), but since I didn&#

Re: [Live-devel] Synchro problem and isCurrentlyAwaitingData()

Il 06/04/2011 12:04, Cristiano Belloni ha scritto: Hi to all, I wrote a custom shared memory source. it inherits from FramedSource. The shared memory is synchronized via Linux semaphores (simple producer-consumer algorithm), but since I didn't want to subclass TaskScheduler, I still

[Live-devel] Synchro problem and isCurrentlyAwaitingData()

elect() did return but still there's no data available? I'm getting really confused on this. Thanks and regards, Cristiano Belloni. -- Belloni Cristiano Imavis Srl. www.imavis.com <http://www.imavis.com> bell...@imavis.com <mailto://bell...@imavis.com> ___

Re: [Live-devel] JPEGVideoRTPSink and Restart markers

r only when you add your own custom code, I'm not going to be able to help you fix it. Dear Ross, LiveJPEGVideoRTPSink adds only a parameters struct to the class members; it does nothing else. Anyway, I'm gonna remove it and investigate further. Regards, Cristiano. -- Belloni Cr

Re: [Live-devel] JPEGVideoRTPSink and Restart markers

lloc, but the crash always come in the OutPacketBuffer destructor, presumably after a free() is made. Regards, Cristiano. -- Belloni Cristiano Imavis Srl. www.imavis.com <http://www.imavis.com> bell...@imavis.com <mailto://bell...@imavis.com> _

Re: [Live-devel] JPEGVideoRTPSink and Restart markers

nd use instead liveMedia's JPEGVideoRTPSink class, the double-free corruption problem is still here, as it was before commenting out the efficiency hack. This means that, at least for me, even your post-2010.10.28 code has problems with the efficiency hack (or so it seems). Regards, Cr

Re: [Live-devel] JPEGVideoRTPSink and Restart markers

the fOutBuf OutPacketBuffer. When the buffer is deleted, it tries to dealloc 4 gigabytes, and glibc gets very angry. Solution: commenting out the efficiency hack seems to make the whole thing work (but the CPU toll without the efficiency hack is too high). Regards, Cristiano. -- Bell

Re: [Live-devel] JPEGVideoRTPSink and Restart markers

nterval == 0) return 0; else return 64; I don't know why you use 1, but in this case you could need to return 65 (64 is the same type of 0, but with DRI markers, and so on). Also, please don't top-post :) Cristiano. -- Belloni Cristiano Imavis Srl. www.imavis.com <http://w

Re: [Live-devel] JPEGVideoRTPSink and Restart markers

x27;m done with the "double free" issue (I'm investigating!), I'll gladly post a patch for MJPEG! Thanks & Regards, Cristiano. -- Belloni Cristiano Imavis Srl. www.imavis.com <http://www.imavis.com> bell...@imavis.com <mailto://bell...@imavis.com> ___

Re: [Live-devel] JPEGVideoRTPSink and Restart markers

Il 27/10/2010 09:32, Francisco Feijoo ha scritto: Thanks for the quick response Ross, Note that the existing "JPEGVideoRTPSink" code already does this. You should not have to reinvent the wheel here. I think I should explained this better. I don't know how to obtain the qFactor from one M

Re: [Live-devel] JPEGVideoRTPSink and Restart markers

Il 27/10/2010 02:39, Ross Finlayson ha scritto: I'm trying to create a rtsp server to stream MJPEG images. Ugh. JPEG is a *terrible* codec for video streaming. I agree, but *everyone* requests JPEG as an entry point. Onvif, for example, requests MJPEG/RTP streaming as a MUST IMPLEMENT.

Re: [Live-devel] Tricky bug in RTSP-on-HTTP server implementation?

-40821000 rw-p 4080 00:00 0 40821000-4090 ---p 40821000 00:00 0 be9a8000-be9bd000 rwxp be9a8000 00:00 0 [stack] If you need more info, I'm gonna collect them as soon as I can. Best Regards, Cristiano. -- Belloni Cristiano Imavis Srl. www.imavis.com <http://www.im

Re: [Live-devel] Tricky bug in RTSP-on-HTTP server implementation?

very old; our RTSP client implementation has changed significantly since then. Yes, I can confirm it occurs even with the Oct 20 / 2010 version of openRTSP. I'm downloading the latest version right now and will make you know if everything's ok as soon as I test it extensively. As usual,

[Live-devel] Tricky bug in RTSP-on-HTTP server implementation?

IONS rtsp://192.168.1.97/video RTSP/1.0 CSeq: 1 User-Agent: openRTSP (LIVE555 Streaming Media v2010.04.09) (second packet, *not* ignored this time). The problem is found randomly in the systems. Probably it depends on the net stack, networking hardware and/or network load and lag. Can you

Re: [Live-devel] RTSP-over-HTTP and inconsistent SETUP requests.

. Works like a charm. Thank you. Cristiano. -- Belloni Cristiano Imavis Srl. www.imavis.com <http://www.imavis.com> bell...@imavis.com <mailto://bell...@imavis.com> ___ live-devel mailing list live-devel@lists.live555.com http://lists.live55

Re: [Live-devel] RTSP-over-HTTP and inconsistent SETUP requests.

. I'm getting very tired of this, too, and I can assure you I share your feelings. I'm sincerely astonished that big manufacturers as Milestone just can't stick to these simple standards. I've already contacted Milestone developers and informed them on these bugs (and on ot

[Live-devel] RTSP-over-HTTP and inconsistent SETUP requests.

a reference: http://developer.apple.com/quicktime/icefloe/dispatch028.html , but unfortunately it doesn't answer my question). Best Regards, Cristiano. -- Belloni Cristiano Imavis Srl. www.imavis.com <http://www.imavis.com> bell...@imavis.com <mailto://bell...@imavis.com> _

[Live-devel] RTSPOverHTTPServer is no more?

I implement to make RTSP over HTTP work? Thanks, Best Regards, Cristiano. -- Belloni Cristiano Imavis Srl. www.imavis.com <http://www.imavis.com> bell...@imavis.com <mailto://bell...@imavis.com> ___ live-devel mailing list live-devel@lists

Re: [Live-devel] GET_PARAMETERS used as a ping request and VLC

ed, because we already use the client's RTCP "RR" packets as a 'liveness' indicator. (This hack will be removed when we fix the problem with RTP-over-TCP (RSN, I hope).) Great! Thank you! Regards, Cristiano. -- Belloni Cristiano Imavis Srl. www.imavis.com <http://www.ima

Re: [Live-devel] GET_PARAMETERS used as a ping request and VLC

timeout value? RTSPServer.cpp modify or there's a better solution? Regards, Cristiano. -- Belloni Cristiano Imavis Srl. www.imavis.com <http://www.imavis.com> bell...@imavis.com <mailto://bell...@imavis.com> ___ live-devel mailing

Re: [Live-devel] GET_PARAMETERS used as a ping request and VLC

if the option is listed, VLC has the right to use it), even if it's a brain-dead schema. Regards, Cristiano. -- Belloni Cristiano Imavis Srl. www.imavis.com <http://www.imavis.com> bell...@imavis.com <mailto://bell...@imavis.com> __

[Live-devel] GET_PARAMETERS used as a ping request and VLC

te VLC, but let every client download it (its browser-plugin, in fact) straight from the site. Conversely, I cant' just switch to UDP, as TCP streaming is the only things that just works in case of blocking firewalls, routers, and all the sweet things you can encounter on the modern

Re: [Live-devel] ONVIF support in Live555

Cristiano Belloni wrote: Matt Schuckmann wrote: We use MJPEG over RTP to send on demand hi resolution still images along side our video which is lower res H.264. Is there an extension to the MJPEG standard that allows JPEG over 2k x 2k? If so we'd be interested in implementing it. M

Re: [Live-devel] ONVIF support in Live555

to support the extension in liveMedia involves writing support for RTP header extension in liveMedia lib, and writing an MJPEG source and sink that can handle the ONVIF headers in your application code (Ross, correct me if I'm wrong). Regards, Cristiano. Cristiano Belloni wrote: Ross Finlays

Re: [Live-devel] ONVIF support in Live555

s all you have, and you got to live with it. That's why people still are still interested in it (for sake of completeness there's another - secondary - reason, i.e. retrocompatibility with older software). Regards, Cristiano. -- Belloni Cristiano Imavis Srl. www.imavis.co

[Live-devel] ONVIF support in Live555

If not, should we develop support for this subset of ONVIF standard, and the code shoul be ok for you, would you eventually include it in live555 liveMedia libraries' future releases? Thanks, Best Regards, Cristiano. -- Belloni Cristiano Imavis Srl. www.imavis.com <http://www.imav

[Live-devel] Set a limit for RTSP Client connections.

session (aka return a NULL pointer). Would it work? Additionally, the increase and decrease counter operations wouldn't have to be mutually exclusive because the library works in a non-threaded fashion, is it right? Thanks in advance, Cristiano. -- Belloni Cristiano Imavis Srl. www

Re: [Live-devel] RTSP stops after 5 minutes

Shiva and Ron, could you please monitor the client / camera interaction with sniffer tools like Wireshark or Tcpdump? The behaviour seems compatible with my very same problem (connection shut down after a while, only in tcp mode), and in my case it is due to openRTSP not sending RR packets (th

Re: [Live-devel] RR packets not sent by openRTSP in TCP mode

Ross Finlayson wrote: Ross Finlayson wrote: This is very strange - I can't reproduce this at all. When I run a server ("live555MediaServer") on a FreeBSD computer, and "openRTSP -t" on a Mac OS X computer, I see that "openRTSP" is sending - and the the server is receiving - the RTCP "SR" repo

Re: [Live-devel] RR packets not sent by openRTSP in TCP mode

Ross Finlayson wrote: This is very strange - I can't reproduce this at all. When I run a server ("live555MediaServer") on a FreeBSD computer, and "openRTSP -t" on a Mac OS X computer, I see that "openRTSP" is sending - and the the server is receiving - the RTCP "SR" reports just fine. Why SR

[Live-devel] RR packets not sent by openRTSP in TCP mode

liveMedia package (though I can observe this behaviour in older builds, too) without modifications. Thanks and best regards, Cristiano Belloni. -- Belloni Cristiano Imavis Srl. www.imavis.com <http://www.imavis.com> bell...@imavis.com <

Re: [Live-devel] [Question] Streaming transmission rate of liveMedia Server

it works >> perfectly. >> > > That must be because you are streaming from a live source. If you > are streaming from a live source, then it's perfectly OK (in fact, > preferred) to not set "fDurationInMicroseconds" (which means that it > retains it

Re: [Live-devel] [Question] Streaming transmission rate of liveMedia Server

ect. (Note the numerous examples of this in the source > code.) > I've always wondered what value "fDurationInMicroseconds" should take in video frames. A simple answer is probably 1 sec / framerate. Is it toio simple or am I correct? Anyway, I set it to 0 in

Re: [Live-devel] Paths in RTSP requests

e a character > other than "/" in the RTSP URLs - e.g., > rtsp://host/video:MPEG4:stream[number] > ? This would require no change to the existing code. > To achieve URL-uniformity with existing IP cameras, for example. Nearly all of them use URLs like that. Cristiano

[Live-devel] Paths in RTSP requests

e file does not exist in the filesystem). Regards, Cristiano. -- Belloni Cristiano Imavis Srl. www.imavis.com <http://www.imavis.com> [EMAIL PROTECTED] <mailto://[EMAIL PROTECTED]> ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel

[Live-devel] Estimated Bitrate

to divide it by 1000. I know it only affects the frequency of RTCP packets, but it's just to be sure. Regards, Cristiano. -- Belloni Cristiano Imavis Srl. www.imavis.com <http://www.imavis.com> [EMAIL PROTECTED] <mailto://[EMAIL PROTECTED]> ___

Re: [Live-devel] How to implement non-blocking fashion in custom doGetNextFrame()

Cristiano Belloni wrote: > [EMAIL PROTECTED] wrote: > >> 1. Are you inheriting from FramedSource, from DeviceSource, or >> modifying DeviceSource? >> > Inheriting from FramedSource. > >> 2. Is "isAwaitingData()" function an abbreviation for

Re: [Live-devel] How to implement non-blocking fashion in custom doGetNextFrame()

stions, I'd be interested in looking at what you've written. I > enjoy working with the filter code. The source you've posted isn't > enough for me to help more specifically. Can you post all / more of > your file or just send it to me? > ~xo Currently I&#x

Re: [Live-devel] How to implement non-blocking fashion in custom doGetNextFrame()

alled anytime a DelayQueue::HandleAlarm calls AlarmHandler::HandleTimeout (which in turn calls handleTimeout, and so on). Please note I can only see *if* a frame is ready. When / where in the code should I check that, in order to get my doGetNextFrame called? Regards, Cristiano -- Belloni Cristian

[Live-devel] How to implement non-blocking fashion in custom doGetNextFrame()

frames until the next frame is acquired, filling rapidly the CPU resources. Thanks. Regards, Cristiano. -- Belloni Cristiano Imavis Srl. www.imavis.com <http://www.imavis.com> [EMAIL PROTECTED] <mailto://[EMAIL PROTECTED]> ___ live-dev

Re: [Live-devel] My MPEG4 Source does not make MPEG4ESVideoRTPSink set marker bits.

Cristiano Belloni wrote: > Hi, I'm streaming MPEG4 and use FFMPEG library to encode MPEG4 frames > from my own live source. > > I wrote my own FramedSource subclass and that does the trick. > > The problem is, MPEG4ESVideoRTPSink does not set the marker bits at > all.

[Live-devel] My MPEG4 Source does not make MPEG4ESVideoRTPSink set marker bits.

nd set the pictureEndMarker everytime I have a complete frame? Is there no way to have my marker bits set just subclassing FramedSource, just like I did with H263 streaming? Thanks and regards, Cristiano. -- Belloni Cristiano Imavis Srl. www.imavis.com <http://www.imavis

Re: [Live-devel] [Live-develop] Problems with delete in MediaSink.cpp

Cristiano Belloni wrote: > Ross Finlayson wrote: > >> Cristiano, >> >> What you're doing looks OK. Perhaps the first thing you could look >> into is to check whether your RTPSink (subclass)'s destructor is >> somehow getting called more

Re: [Live-devel] [Live-develop] Problems with delete in MediaSink.cpp

nnounceStream(rtspServer, sms, streamName, inputSink); Am I doing something wrong? Regards, Cristiano. -- Belloni Cristiano Imavis Srl. www.imavis.com <http://www.imavis.com> [EMAIL PROTECTED] <mailto://[EMAIL PROTECTED]> ___ live-devel ma

Re: [Live-devel] GroupsockHelper.cpp and weird problems with long startuptimes for applications

Ross Finlayson wrote: > (A reminder: Serious professionals do not use "@gmail.com" email addresses :-) > I'm curious about that. Why? :) -- Belloni Cristiano Imavis Srl. www.imavis.com [EMAIL PROTECTED] __

[Live-devel] [Live-develop] Problems with delete in MediaSink.cpp

signed char rtpPayloadTypeIfDynamic, FramedSource* inputSource) { return H263plusVideoRTPSink::createNew(envir(), rtpGroupsock, rtpPayloadTypeIfDynamic); } Is it the correct way to create the sink? And what could cause the corrupt or double-delete in ~OutPacketBuffer? Thanks i

Re: [Live-devel] MPEG4ESVideoRTPSource: Two frames at the price of one packet!

rames at once, or to add "out of band" data to a frame. Thanks anyway, Cristiano. -- Belloni Cristiano Imavis Srl. www.imavis.com <http://www.imavis.com> [EMAIL PROTECTED] <mailto://[EMAIL PROTECTED]> ___ live-devel mailing lis

[Live-devel] MPEG4ESVideoRTPSource: Two frames at the price of one packet!

;s not, is there a way to stuff some special data in the frame that will be read from my custom sink, so that the sink could tell it's two frames instead of one and divide them accordingly? Thank you very much, Cristiano. -- Belloni Cristiano Imavis Srl. www.imavis.com <http://www.imav

Re: [Live-devel] RTSP Client subclassing questions.

Cristiano Belloni wrote: > Because it will mean creating also my own > subclass of "MediaSubSession", and of "MediaSubsessionIterator", as far > as I know. Errata corrige: should be: 'Because it will mean creating also my own subclass of "MediaSession

Re: [Live-devel] RTSP Client subclassing questions.

Ross Finlayson wrote: > It sounds like you are trying to implement your own (nonstandard) RTP > payload format - therefore I'm not able to help you. However, if you > still wish to proceed down this route, then you will need to (i) > implement your own subclass of "MultiFramedRTPSink" for trans

[Live-devel] Reading custom packets (was: Re: RTSP Client subclassing questions.)

my internal buffer, and I need to copy it at the beginning of the packet (removing the header in the meanwhile). How can I do this? Thanks, Cristiano. -- Belloni Cristiano Imavis Srl. www.imavis.com <http://www.imavis.com> [EMAIL PROTECTED] <mailto://[EMAIL PROTECTED]>

Re: [Live-devel] RTSP Client subclassing questions.

to set up a function that's called every time an RTP packet is received? 2) If there is, will the packtes be in order (i.e. function for packet n is called _after_ function for packet n-1 and _before_ packet n+1)? 3) Is there a way to set up a function that's called every time an RT

Re: [Live-devel] RTSP Client subclassing questions.

Cristiano Belloni wrote: > Ross Finlayson wrote: > >>> Ross Finlayson wrote: >>> >>> >>>>> However, I need some info: the camera I'm contacting does not send normal >>>>> video frames, but custom ones. I need to

Re: [Live-devel] RTSP Client subclassing questions.

Ross Finlayson wrote: >> Ross Finlayson wrote: >> However, I need some info: the camera I'm contacting does not send normal video frames, but custom ones. I need to unpack every RTP packet (_in order_), read the custom headers, reconstruct the frames and decode them on

Re: [Live-devel] RTSP Client subclassing questions.

Ross Finlayson wrote: >> However, I need some info: the camera I'm contacting does not send normal >> video frames, but custom ones. I need to unpack every RTP packet (_in >> order_), read the custom headers, reconstruct the frames and decode them >> on the fly. >> > > Because your 'custom hea

Re: [Live-devel] Server doesn't interleave reads from pipe and sending packets?

m this, because you're working with your own custom code, > there's not a whole lot more I can suggest. > Do you see any errors in the server code I posted? Thanks, Cristiano. -- Belloni Cristiano Imavis Srl. www.imavis.com <http://www.imavis.com> [EMAIL PROTECTED] &

[Live-devel] Server doesn't interleave reads from pipe and sending packets?

fifo) and blocked write(s) in the fifo (that becomes full while the server is streaming). Maybe it has something to do with the estBitrate in H263plusVideoFileServerMediaSubsession (too large or too short)? Should I subclass and change it? Regards, Cristiano. -- Belloni Cristiano

Re: [Live-devel] [Resolved] info request about H263 / H263plus compatibility

Errr.. I mean "I managed to figure out". > At last, I maneged figured out the problem. > > -- Belloni Cristiano Imavis Srl. www.imavis.com [EMAIL PROTECTED] ___ live-devel mailing list live-devel@l

Re: [Live-devel] [Resolved] info request about H263 / H263plus compatibility

Cristiano Belloni wrote: >> You will need to figure our what about your data is causing the >> parsing to fail. (It is also not inconceivable that our parsing code >> is in error; if so, let is know.) >> >> > > Good. I'll go for it and ho

Re: [Live-devel] Possible bug in liveMedia + info request about H263 / H263plus compatibility

> You will need to figure our what about your data is causing the > parsing to fail. (It is also not inconceivable that our parsing code > is in error; if so, let is know.) > Good. I'll go for it and hopefully let the list know what went wrong. Thanks for your help! -- Belloni Cristiano

Re: [Live-devel] Possible bug in liveMedia + info request about H263 / H263plus compatibility

Using strace (it's difficult to debug liveMedia with a debugger when it's running and sending packets), I found that the library seems to block for several seconds on a select(), waiting for three fd, corresponding to sockets and then timeout on the select. (opens the sockets) 17718 socket(PF_I

Re: [Live-devel] Possible bug in liveMedia + info request about H263 / H263plus compatibility

>he good news is that because you set "reuseFirstSource" to True, >this 'close+reopen' will happen only once, regardless of the number >of ciients that you have. However, it's unavoidable (and not a bug), >so you're going to have to find a way to live with it. Ok. > I suggest that you first g

[Live-devel] Possible bug in liveMedia + info request about H263 / H263plus compatibility

Greetings to all, As I explained in the previous emails, I'm trying to set up an rtsp server that streams h263 video, taken from a process that writes the stream on a unix named pipe. The "encoder" process sets up ffmpeg libraries, takes video frames from an analog camera and encodes them in h

[Live-devel] Lot of late pictures skipped by VLC

Hi to everybody, I'm implementing a live rtsp server with liveMedia libraries. I subclassed H263plusVideoFileServerMediaSubsession, so that any time an RTSP client makes a request, it starts a thread which takes frames from an analog camera and encode the frames in h263+ format (encoding is don

Re: [Live-devel] Questions on streaming live H263 videos

stream? Now I'm testing if thread is already started, because starting it in createNewStreamSource would have it started twice. Am I doing the right thing? Regards, Cristiano Belloni. Cristiano Belloni wrote: >> I suggest defining a subclass of >> "H263plusVide

[Live-devel] Re: Questions on streaming live H263 videos

y class, I get similar errors. Where am I doing wrong? Can you point me to some sample code where it is done right? Thanks, Regards, Cristiano Belloni. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel

Re: [Live-devel] Questions on streaming live H263 videos

>You're going to have to figure out yourself why the server is not >streaming. (Remember, You Have Complete Source Code (for the >server), and also a working client.) I'm not surprised, however, >that RealPlayer doesn't wor; it's notoriously non-standards compliant. Also, the odd thing is tha

Re: [Live-devel] Questions on streaming live H263 videos

>I presume you're using a "H263plusVideoFileServerMediaSubsession" >object for your video. I do. >Be sure to set the "reuseFirstSource" >parameter to "True", because you are streaming from a single (live) >source, rather than from a file that's stored on disk. I did. >You're going to have to

[Live-devel] Questions on streaming live H263 videos

an "on demand" fashion. How can I do that? I thought about starting the decoder thread in specialClientAccessCheck method, subclassing RTSPServer class, but I don't think it's the right way to do it (after all, specialClientAccessCheck is for checking

Re: [Live-devel] RTSP H263+ streaming oddities.

Ross Finlayson wrote: > I looked into the code, and found that the problem was the > "H263plusVideoFileServerMediaSubsession" class. It was (incorrectly) > using a (now-obsolete) static RTP payload type. I have now fixed it > to use a dynamic RTP payload type. > > I have now installed a new ve

Re: [Live-devel] RTSP H263+ streaming oddities.

Ross Finlayson wrote: >/ char const* inputFileName = "video-H263-1998-1.3pg"; / > What is the format of this file? Our 'H.263+ parsing' code assumes > that the input file contains raw H.263+ video elementary stream data > *only*. If (judging by the ".3gp" filename suffix) your file is > i

[Live-devel] RTSP H263+ streaming oddities.

ut I don't know how to avoid it). I think the correct solution is using the onDemand approach, but does someone know the reason of its strange behaviour (and how to crcumvent it, of course)? Best regards, Cristiano. -- Belloni Cristiano ___ li