On attempting to update an existing code base that builds under C++17, we’re
now getting this build error:
live555/BasicUsageEnvironment/BasicTaskScheduler.cpp: In member function
‘virtual void BasicTaskScheduler::SingleStep(unsigned int)’:
live555/BasicUsageEnvironment/BasicTaskScheduler.cpp:1
On Dec 15, 2021, at 2:09 AM, Laszlo Ast wrote:
>
> I successfully used stunnel
...
> socat was the simplest solution.
Simple and unsuccessful beats complicated and successful?
It sounds like you’ve got some weeks or months to wait for a non-guaranteed
solution, so unless you’re going to writ
On Dec 14, 2021, at 4:35 PM, Laszlo Ast wrote:
>
> different tricks (socat and RTSP proxies)
Did you try stunnel or nginx as the HTTP to HTTPS proxy? Those are more likely
to implement the wide array of TLS functionality your end devices require than
the more limited socat.
__
On Aug 18, 2021, at 10:23 AM, Ross Finlayson wrote:
>
> Thanks again for the report. This was not a serious issue, but I’ve just
> released a new version (2021.08.18) of the code that should make ‘valgrind’
> happy.
Valgrind is rather heavy-weight, essentially being a software CPU emulator at
On Aug 5, 2020, at 4:45 PM, Ross Finlayson wrote:
>
> you should make sure that the resulting “.mkv” (or “.webm”) file contains
> frequent ‘key frames’ (at least one per second; preferably more frequent than
> this)
A large part of the reason H.264 and newer are able to get higher rates of
co
On Jul 2, 2020, at 1:47 AM, Ross Finlayson wrote:
>
> If your OS handles “socket()” with a granularity of 10ms, then you need a
> better OS.
It’s not socket(), it’s select(), and he’s got the timeval parameter set, so
it’s expected to delay.
However, 10ms feels short here. 60 fps is 16 ms.
On Thu, Jun 25, 2020 at 11:40 AM Ross Finlayson
wrote:
> I’ve just installed a new version (2020.06.25) of the code that fixes this.
>
The current release has a bunch of *.hh files in the "include" dir's parent
with the .cpp file. e.g.
live/liveMedia/MPEG2TransportStreamDemuxedTrack.hh
On Mar 26, 2020, at 3:36 AM, Zhang Qian（张倩） wrote:
>
> If user modifies the system time for device, seems it will impact A/V sync
> for client. How can I avoid this problem?
Have your user switch to calling adjtimex(2) instead:
http://man7.org/linux/man-pages/man2/adjtimex.2.html
Yes, it’
On Feb 25, 2020, at 8:03 AM, Ross Finlayson wrote:
>
> On Feb 26, 2020, at 3:56 AM, Ralf Globisch wrote:
>>
>> That's great news Ross, can't wait to try it out.
>>
>> Are there currently any plans for supporting audio (e.g. AAC) in the
>> pipeline?
>
> Possibly, but I’d first need an example
On Aug 29, 2019, at 10:39 AM, Vishnu Mohan wrote:
>
> I meant to say is there a reason/s why Webrtc is not a good method for
> webserver based streaming implementations ?
Ross said in his first reply that he had a bunch of compatibility problems. I
haven’t tried to implement anything involv
On May 22, 2019, at 8:06 AM, Saurabh Modi via live-devel
wrote:
>
> Since the JPEG RTP payload header has only 8 bits for storing width and
> height, therefore it will not be able to store resolution greater than 2048
> or 3MP. Is there a way we can stream JPEG having resolution greater than 3
On Feb 22, 2019, at 8:46 AM, Kevin Bailey wrote:
>
> My plan was to just add a layer ontop of live555 like libsodium to handle my
> encryption.
There’s more to security protocol design than just blindly running everything
through AES-128.
Cisco’s released an SRTP implementation on GitHub unde
On Feb 21, 2019, at 4:42 PM, Kevin Bailey wrote:
>
> the amount of data being encrypted needs to match the amount of data received
> on the client end. Or at the very least the number of packets going out and
> coming in need to be the same. I found that neither is the case.
I believe you’re t
A couple of clarifications:
On Feb 19, 2019, at 2:23 PM, Warren Young wrote:
>
> ...RTP-over-HTTP…is the only TCP-based protocol I believe Live555 supports.
I mean the only A/V streaming protocol, of course. I’m excluding RTSP in that
characterization.
> you’ll need to sniff
On Feb 19, 2019, at 11:57 AM, Kevin Bailey wrote:
>
> I wanted my RTSP stream to be UDP based not TCP based to take advantage of
> the latency advantage UDP has over TCP. However I noticed the following when
> I took a look at netstat while my program was running:
>
> ~# netstat | grep 8554
>
On Feb 19, 2019, at 11:53 AM, Kevin Bailey wrote:
>
> Maybe this doesn't have anything to do with my clean up code?
Indeed it doesn’t. The “problem” is that Live555 doesn’t set SO_REUSEADDR,
which it is technically correct to do:
https://stackoverflow.com/a/3233022/142454
You can set it
On Dec 28, 2018, at 10:31 AM, Ross Finlayson wrote:
>
> 1/ In your H.264 encoder - i.e., between the creation of a raw video frame,
> and the time that it is encoded into (one or more) H.264 NAL units.
Ross didn’t go into any detail on this point, Kevin, so I thought I’d weigh in
on it.
I th
As in subject; they’re in a block starting around line 700 or so.
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
On Aug 28, 2018, at 4:25 PM, Shyam Kaundinya
wrote:
>
> At times I see artifacts on the Rx side. Any thoughts on what may cause this
> behavior and how to fix it ?
Live555 is set up as a real-time streaming library primarily, not a YouTube
style buffer-and-play pseudo-streaming system. That
On Aug 23, 2018, at 1:13 PM, Bill Barnett
wrote:
>
> We are looking for help to determine why the first 7 to 10 seconds of mp4
> data video is not displayed in most instances.
Tell whoever wrote that interface that “NTSC” and “720p” are incompatible terms.
As to your question, it’s obvious fr
On May 30, 2018, at 8:28 PM, Ross Finlayson wrote:
>
>> On May 30, 2018, at 7:16 PM, Warren Young wrote:
>>
>> On May 30, 2018, at 7:34 AM, GENESTIER Denis
>> wrote:
>>>
>>> Then if you disconnect the Ethernet wire of the computer B, the server
On May 30, 2018, at 7:34 AM, GENESTIER Denis
wrote:
>
> Then if you disconnect the Ethernet wire of the computer B, the server will
> close the session, the RTP and RTCP sockets (in UDP mode), but not the RTSP
> connection (in TCP)
I’d say the real mystery here is how the UDP streams are bein
On Feb 15, 2018, at 4:41 PM, Warren Young wrote:
>
> Your best remaining option — if moving to WebRTC, HLS, etc. —
Dropped a packet: ”…is not an option…”
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/m
On Feb 15, 2018, at 12:45 PM, Ross Finlayson wrote:
>
>> With older version of browsers we used vlc npapi plugin, and the videos
>> where synchronized, but now it’s impossible to use it.
>
> Why? If I were you, I would continue to investigate using web browser
> ‘plugins’ for existing RTSP/RT
On Dec 6, 2016, at 3:15 PM, Jeremiah Morrill
wrote:
>
> The protected RTSPServer constructor has a parameter for the socket FD.
RTSP is a TCP-based protocol. Messing about with its socket will have no
effect on how the *UDP* multicast packets go out.
There is such a thing as RTP over TCP, b
On Dec 6, 2016, at 11:55 AM, Weber, Patrick
wrote:
>
> Clearly I *could* do what has been suggested from within my application (the
> top layer is C#/.NET, so the System.Web assembly has everything needed)
Not according to this SO answer:
https://stackoverflow.com/questions/7333764/
You ma
On Dec 5, 2016, at 7:27 AM, Weber, Patrick
wrote:
>
> Thanks for the response. Is there a non-default way (via C++ API) to select
> the NIC/IP address? My application may use multicast for other purposes (Web
> service discovery, for example), and I need to have it active on each NIC.
These
On Nov 25, 2016, at 2:49 AM, Robin Swoboda wrote:
>
> So could it be an option to implement send and receive callbacks into live555
> that we could use an own HTTPS client that performs the encryption
If you’re using RTSP *and* RTP over HTTPS, you don’t need to modify Live555,
for the server s
On Oct 28, 2016, at 6:57 AM, Ross Finlayson wrote:
>
>> Also, whilst I'm not arguing about the validity or otherwise of the cameras
>> response (I'm no RTP expert), isn't it reasonable to interpret this as a
>> security hole in the live555 library?
>
> No, because IP source addresses can alway
On Sep 28, 2016, at 2:30 PM, Ross Finlayson wrote:
>
>> Speaking of options: why don't you use getopt()?
>
> Last time I checked (admittedly, several years ago), “getopt()” wasn’t
> available for Windows developers who use Visual Studio.
Henry Spencer’s public domain getopt() implementation po
On Jun 16, 2016, at 5:18 PM, Ross Finlayson wrote:
>
>> Okay, how about RTSP + RTP over HTTP, proxied by an HTTPS reverse proxy?
>
> As you noted (in your earlier message), that (or RTSP+RTP over TLS) should
> work ‘as is’ right now, if you have an appropriate tunnel set up between the
> clien
On Jun 16, 2016, at 3:48 PM, Ross Finlayson wrote:
>
> Re. SRTP in RTSP (and why it’s not going to happen anytime soon): I addressed
> this a couple of weeks ago:
Okay, how about RTSP + RTP over HTTP, proxied by an HTTPS reverse proxy?
___
live-deve
On Jun 16, 2016, at 2:37 PM, Ross Finlayson wrote:
>
>> interesting, this makes the access to the stream secure but what about after
>> the authentication? If I succesfully initiate an RTSP stream I have a flow
>> of packets comming to my client. Are these packets encypted or protected in
>> s
On Apr 4, 2016, at 11:03 AM, Ross Finlayson wrote:
>
> dot: not found
dot is a separate tool, part of graphviz, which draws the inheritance graphs.
Without dot, no graphs.
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.
On Dec 11, 2015, at 4:08 AM, Christiano Belli
wrote:
>
> I want to kill and start openRTSP from a Perl script that owns the user
> www-data.
Let’s be clear here: the Perl script does not “own” www-data. Your script may
be running under that user’s permissions, but it is the OS that owns the
On 6/21/2014 20:06, minus wrote:
OpenRTSP test sample always stops after 2 minutes. Why it happens and
how to prevent it?
What is the server?
Is it unicast or multicast?
Is it always exactly 120 seconds, or does it vary somewhat?
What is the command line you are passing to openrtsp?
Detail
On 6/5/2014 05:06, Adrian Kovacs wrote:
Currently I use a 1280 x 800 AVC video 25 frame/sec,
Are you encoding that video on the same system in real time? 2-4
streams of 1 megapixel @ 25 fps AVC is pretty aggressive.
If you're streaming preencoded files, are you doing intelligent disk
read
On 6/5/2014 04:04, Ross Finlayson wrote:
(In particular, if your network is WiFi, note that multicast generally
performs very poorly over WiFi networks.)
Yes, wifi is a problem for all real-time systems.
First, the speeds claimed for wifi are basically marketing BS. A "54
Mbit/s" wireless n
On 4/28/2014 02:34, Cheng Lei wrote:
If delete default gateway ip addrss, then run the test program
testRTSPClient, CPU percentage is 6%, then I add the default gateway ip
by using cmd such as "route add default gw 192.168.122.1", CPU decrease
to 1%. If you guys know the issue, please help, than
On 4/22/2014 16:03, Goran Ambardziev wrote:
On this line VS says: "HEAP: Free Heap block 3043560 modified at 304361c
after it was freed"
What does the stack trace look like when this happens?
To eliminate any possible leaks that I might have in my code,
It sounds like the opposite of a leak
On 4/14/2014 08:24, Amir Marzouk wrote:
I'm looking for how to increase the number of concurrent clients. I
found in this link that i need to redefine "FD_SETSIZE". but I have not
found how and where?
This is pretty basic stuff, a thing you should know as a programmer
regardless of your use o
On 4/3/2014 14:24, Ross Finlayson wrote:
I have no doubt that MJPEG is useful for many things. However,
streaming is not one of them.
What if the streaming is done over HTTP or RTP-over-TCP? That solves
your packet loss concern:
http://www.live555.com/liveMedia/faq.html#jpeg-streaming
On 4/3/2014 02:27, Ross Finlayson wrote:
JPEG video streaming is a bad idea (that nobody should really be doing
in 2014)
Intra-frame compression is perfectly sensible for IP cameras on private
LANs, especially when you're doing things like motion detection on the
server side, rather than on-
On 3/18/2014 16:34, Ross Finlayson wrote:
In contrast, the "LIVE555 Media Server" application uses a subclass of
"RTSPServer" (named "DynamicRTSPServer") that will serve any file that's
accessible to the server.
mediaServer seems to be smart enough not to follow .. in paths, so not
"any" file,
On 3/18/2014 13:24, lonely heart wrote:
Does anyone have an implemented RSTP server to stream the video file
which the client has requested.
The testOnDemandRTSPServer program that comes with Live555 does exactly
that.
The user DOES NOT want to allow all the
files,
testOnDemandRTSPServer
On 2/25/2014 14:33, Ross Finlayson wrote:
The "RTSPClientConnection" object gets deleted if the call to
"readSocket()" in
"RTSPServer::RTSPClientConnection::incomingRequestHandler1()" (line 786
of "RTSPServer.cpp) returns a value < 0 - which should happen when the
remote (i.e., client) end of th
On 2/25/2014 09:17, Warren Young wrote:
because it wants you to call recv() one last time and get -1, which is
how BSD sockets (and Winsock) signal that condition.
I meant 0, of course.
___
live-devel mailing list
live-devel@lists.live555.com
http
On 2/24/2014 06:36, Martínez Contador, Daniel [ELIMCO] (CA) wrote:
This is an educated guess. In Cygwin the RTSPClientConnection
socket doesn't close explicitly after a TEAR. The read bitmask
in the call to select in BasicTaskScheduler remains active
and the call returns immediately by some reas
On 2/19/2014 05:12, Martínez Contador, Daniel [ELIMCO] (CA) wrote:
The overuse happens with binaries from CYGWIN, but not with MINGW.
So you changed the development platform, but you blame Live555?
Science says that if you change one variable and the behavior changes,
chances are that the thi
On 2/6/2014 19:53, Ross Finlayson wrote:
I am using test app MPEG2TransportStreamIndexer.
In file MPEG2IndexFromTransportStream.cpp,when it got error
"Unexpectedly large PES header size" its close all handles and goes down.
Please put your Transport Stream file (the one that produces this error
On 1/30/2014 17:44, Ross Finlayson wrote:
I haven't seen this at all with the unmodified
"testMPEGTransportStreamer" code - which is what you should be using to
test this.
My point in asking is to learn why behavior changes when you change that
one aspect of the existing code.
At that time,
In an attempt to reduce the number of global variables in
testMPEG2TransportStreamer.cpp, I made videoSource a local variable in
play(), then said
Medium::close(videoSink->source());
in afterPlaying().
This appears to work, but if you watch the FD count, it goes up by one
per pass throug
On 1/10/2014 13:04, Ross Finlayson wrote:
I'm not planning on making any non-standard, Windows-specific additions
to the code.
If you're immovable on that point, then someone needs to write a .def
file for the DLL, which is *painful* for a large C++ library like
live555: http://msdn.microsoft
On 1/8/2014 02:37, Kari Kallioinen wrote:
Any ideas or haven't I noticed something?
Does it work if you build a shared library?
If so, try adding -fPIC to the command line. Some embedded systems
require relocatable code.
___
live-devel mailing li
On 1/7/2014 07:01, Kari Kallioinen wrote:
And I have no Idea why libliveMedia.a is broken. libgroupsock.a is
working one and it is compiled and linked with same flags as libliveMedia.a.
With cross-compilation involved, you must have at least two toolchains
installed. You might even have thre
On 12/17/2013 12:00, Robson Nunes wrote:
i'm not being able to make it on Visual Studio
2012. Could you help me out, please?
Toggle the checkbox. You know, the one over there. In that dialog.
Since I'm feeling generous, I will also give some specific advice in
response to your nonspecific q
On 12/9/2013 14:19, Ross Finlayson wrote:
No, this is not a "critical potential error". It's not even an "error".
It is a compiler *warning* (usually given by some old versions of
Microsoft's Visual C++ compiler).
I don't think VC++ is wholly wrong to warn about this. The object isn't
com
On 11/25/2013 13:54, Bruno Abreu wrote:
What we've noticed is that after the TEARDOWN from each client we can see a
socket left in CLOSE_WAIT state.
That means the client sent FIN, the server stack sent ACK, and nothing
else happened. Because TCP is bidirectional, the server is allowed to
c
On 11/12/2013 16:22, Umar Qureshey wrote:
I have been told second-hand that the TS muxer in Live555 is broken.
Told by whom, and what exactly do they mean by "broken"?
TS covers a whole lot of ground, and I have yet to use a TS muxer that
can produce every legal type of TS file. "Broken" ma
On 9/20/2013 00:42, Ross Finlayson wrote:
Anyway, what I didn't make sufficiently clear in my January 2011 email
was that when I ran my experiment, altering our server code (along with
the index file format) to stream TS files using precise (rather than
predicted) inter-Transport-Packet duration
On 9/19/2013 16:13, Ross Finlayson wrote:
I took a look at this idea back in January 2011, and decided that it
probably wouldn't be worth the trouble:
http://lists.live555.com/pipermail/live-devel/2011-January/013083.html
Okay, let's go back through it point by point:
1a. Index file change.
A
On 9/19/2013 16:17, Ross Finlayson wrote:
1/ It'd be a lot of work.
We thought it would be easy. Since it isn't, never mind.
(Live Networks, Inc. is not a charity.)
You're always welcome to send us a work proposal. We may or may not
accept it, but we will consider it.
3/ We already su
Posts to the mailing list tell me there is some unspecified problem with
the MP4/QuickTime file format related to A/V synchronization, and this
is given as the reason there is no MP4FileServerMediaSubsession class in
the library yet. (Or equivalently, an MP4FileServerDemux class, so you
could
Currently live555MediaServer requires CBR or near-CBR files when
streaming from MPEG-TS. The explanation I've read on the list is that
this is because it makes determining the pacing of frame delivery
easier. As I understand it, the server has an internal model of the
video bit rate, and it c
On 8/13/2013 15:25, Ross Finlayson wrote:
If you really want to
change a video stream from 25 fps to 10 fps, then you should be dropping
frames from the input;
That would give very stuttery video -- 10 doesn't divide evenly into 25
-- and isn't practical for an inter-frame codec like H.264 any
On 6/19/2013 23:59, Ross Finlayson wrote:
A project to support this
has been proposed, but has not yet been sufficiently funded - see
http://live555.com/funded-projects/live555-mkv.html
Would you please put a goal thermometer[*] on these pages? I think you
could get certain interested parties
Ross, it looks like you accidentally shipped RTSPServer.cpp with a
#define DEBUG line in it.
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
On 6/4/2013 19:08, Ross Finlayson wrote:
Ultimately, I don't see why it needs to call bind() at all in this
program since a UDP sender is just tossing packets out onto the
network. It's not receiving anything.
Yes it is. It's also receiving RTCP "RR" reports from receiving clients.
Okay, bu
If you say
$ strace -e bind ./testMPEG2TransportStreamer
you find that it calls bind() twice, once for 0.0.0.0:1234, and another
time for the "find my IP" hack.
Ultimately, I don't see why it needs to call bind() at all in this
program since a UDP sender is just tossing packets out onto
On 5/22/2013 09:12, Michael Levin wrote:
After converting the file to ts (using testH264VideoToTranspotStream) I
try to play the new file with VLC and get many frames lost cause of dealys:
If you compile the library with the DEBUG macro set, you should get a
line beginning with "MPEGVideoStre
The attached patch adds unconditional URL decoding to the "urlSuffix"
part of the URL only.
I added this so I could have spaces in file names, though it has other
benefits. For one thing, since RTSP specifies that header info is to be
interpreted as UTF-8, it means we get Unicode file name su
On 12/28/2012 14:04, feriel ben ghorbel wrote:
Actually and as you said Warren I used Embedding VLC plugin in a
HTML Page(browser: Mozilla Firefox) using Apache2 and all is
included with Ubuntu(11.10)
my problem is when I reach the Html Page ; the stream ".ts" is not
working and usually M
On 12/26/2012 07:38, feriel ben ghorbel wrote:
Bonjour ,
You're going to get more help if you use English than French.
Est ce que en utilisant "live555MediaServer" peut on afficher un flux
ou plusieurs flux ".ts" à travers un browser ??
VLC has a browser plugin that can catch MPEG TS stream
On 12/19/2012 02:04, kingaceck wrote:
..
I find that after "sock = socket(AF_INET, type|SOCK_CLOEXEC, 0); " the
sock value is -1 and the errno is 24.
errno 24 is EMFILE, on a Linux box, which means there are too many files
open by the current user. Since you say you're running it 16 times
On 9/20/2012 5:11 AM, Warren Young wrote:
libx264 is pretty much incapable of true CBR. You have to do
null-stuffing to get a CBR-like result, and even then, you end up with a
fair bit of variability. I have bitrate graphs to prove it. :)
Someone emailed me privately asking about those
On 9/11/2012 2:54 PM, Mojtaba Nouri wrote:
We had the same problem, and we solved it by creating cbr ts files
stuffed with NULL packets.
The following thread shows the ffmpeg command parameters to create h.264
cbr files:
http://stackoverflow.com/questions/7125446/encoding-h-264-cbr-videos-with-ff
On 9/10/2012 5:51 PM, Warren Young wrote:
If you take
a guess at the GOP length, you can infer frame rate.
I meant bit rate, obviously.
We've tried to get a CBR stream out of ffmpeg, just to prove to
ourselves that stream variability is the problem. We haven't succeeded.
On 9/7/2012 10:13 PM, Ross Finlayson wrote:
We've been unable to create files that stream as
smoothly as our old MPEG-2 files.
Our code has trouble streaming MPEG Transport Stream files that are
extremely VBR (variable bit rate), which is what I suspect your file is.
Yes, that's right. It av
We've been using live555MediaServer with MPEG-2 A/V in TS files
successfully for quite some time now, but we are now experimenting with
H.264 in TS. We've been unable to create files that stream as smoothly
as our old MPEG-2 files.
Here is my latest ffmpeg command attempt:
ffmpeg -i original
On 8/20/2012 8:27 PM, Sid Price wrote:
As I asked, do you know of a tool I could use
to convert the test files I have been supplied with to plain PCM
Try http://sox.sf.net/
I don't see your format on the codec page[*] but it's too easy not to
just try it. If you don't have it installed, it'
On 8/17/2012 9:40 AM, Ross Finlayson wrote:
My hope was to reduce this to an absolute minimum by changing to a
true event driven server.
I don't understand this comment at all. The server *is* a "true event
driven" server. All LIVE555 applications are event driven.
He's referring to Windows
On 8/17/2012 9:17 AM, Sid Price wrote:
My hope was to reduce this to an absolute
minimum by changing to a true event driven server.
Is this WinCE or WinRT?
WinCE has a lot of hacks in it w.r.t. sockets, in order to minimize
kernel size. Basically, a lot of stuff is either unsupported or
em
On 8/1/2012 3:53 AM, Shlomi wrote:
I am using a TI DaVinci processor to create a h264 file.
When trying to stream this file with testH264VideoStreamer, the cpu goes up
to 80% (which is bad for me since it is already in use by other
applications).
When trying to stream the slamtv60.264 found on th
On 7/27/2012 5:07 PM, Ross Finlayson wrote:
I'm
puzzled by why so many programmers these days seem afraid (or unaware)
to do this.
I think it's a legacy of 1990s Windows and Mac OS: poor IPC, poor
process management, etc. But they had threads, which avoids the need
for either.
Now we've g
On 7/27/2012 4:24 AM, kl222 wrote:
CMake is used to
control the software compilation process using simple platform and
compiler independent configuration files. CMake generates native
makefiles and workspaces that can be used in the compiler environment of
your choice.
It probably fixes the tra
On 7/27/2012 12:20 AM, Saurabh Gandhi wrote:
The system worked fine for over two days
You aren't using an old version of Live555 are you? They fixed an
integer overflow bug 8 months ago to let MPEG2TransportStreamFramer
manage a stream for more than a few days.
after two days we experien
On 7/26/2012 11:57 AM, techvalens testing wrote:
/Locale.hh:47:123: error: xlocale.h: No such file or directory
You probably passed the wrong platform name to genMakefiles, but that's
only a guess, because you haven't said what your platform is, or what
you passed.
If your actual platform
On 7/26/2012 11:45 PM, Ross Finlayson wrote:
If it turns out that you really do need to create a custom server,
because the proxy server doesn't do what you want
I'm curious as to why you think this?
Just covering bases. It wouldn't be the first time I read a vague
question and answered the
On 7/26/2012 1:49 AM, d.santan...@tiscali.it wrote:
stat.h file which is not available under WindowsCE:
"libce plugs the holes in Microsoft Visual C++ runtime for Windows CE,
making it more compatible with ANSI C."
https://code.google.com/p/libce/
On 7/26/2012 12:57 AM, sofia Mora wrote:
I have been studying testOnDemandRTSPServer code and I want to do
streaming by taking input from a live source by using a rtsp address.
It sounds like you're trying to reinvent the Live555 proxy server:
http://www.live555.com/proxyServer/
hav
On 7/9/2012 2:15 PM, Michael L. Boom wrote:
I need the unmodified version to compare.
Googling the file name in quotes gave me this: http://goo.gl/SdU3e
I also direct you to the FAQ on modifying the code:
http://www.live555.com/liveMedia/faq.html#modifying-and-extending
*Always* make a pri
On 6/27/2012 12:41 AM, Ross Finlayson wrote:
if the receiving program bind()s to INADDR_ANY. So isn't the fix
simple? bind() each socket to the multicast address of interest.
We've been through this many times before (note the links in my previous
message). This suggested 'fix' does not
On 6/26/2012 8:42 AM, Ross Finlayson wrote:
It seems we face some problems to receive several streams using
different multicast groups on same port.
Are you using Linux? The Linux kernel has a bug[*] whereby different
sockets joining different IP multicast groups with the same port number
will
On 6/9/2012 12:47 AM, Ross Finlayson wrote:
Unfortunately there are many environments for which linking won't work
if the space character is present;
Which ones? I'll be more able to help you find a workable fix if I can
set up a VM for one or more of them.
On 6/2/2012 12:55 AM, Ross Finlayson wrote:
the command
genMakefiles freebsd
should be putting this space character in the Makefiles OK.
Sure, but that doesn't fix the fact that BSD make will strip them right
back out. I think that's what the OP has run into.
I said it before in this threa
On 5/31/2012 1:07 PM, Meftah Tayeb wrote:
any good apropriate tool to use?
Perhaps ffmpeg. But that wouldn't be on topic here, would it?
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
On 5/29/2012 5:34 AM, Tarun Batra wrote:
Is there any way in testMPEG2TransportStreamer.cpp to know the frame
rate of the file it is streaming
Try subclassing MPEG2TransportStreamFramer, and keeping track when its
getNextFrame() method is called. Between that and gettimeofday(), you
sho
On 5/28/2012 8:09 AM, Ketan Gholap wrote:
i was wondering how to
find out the bit/byte rate of streaming of live media server,that i can
print on the console???
If you're streaming using an RTPSink object, call its octetCount()
method at two known times. Then:
double mbits_sent =
On 5/18/2012 3:26 AM, Ross Finlayson wrote:
I solved the ar issue the following solution :
In Makefile.tail, I added a space in the line
$(LIBRARY_LINK)$@ $(LIBRARY_LINK_OPTS) \
between $(LIBRARY_LINK) and $@...
But you shouldn't have to do this, because the space is already present
- at the en
On 5/30/2012 7:22 AM, Anthony Brown wrote:
rewriting main() to use stdin
would allow it to be used on the end of a pipe or redirection yes?
This much looks easy to do. The indexer gets its input data from a
ByteStreamFileSource, and one of its virtual ctors (createNew()) takes a
FILE* in
1 - 100 of 134 matches
Mail list logo
