I have this project building as a Dlll on Windows without any code changes.
CMake is my build system though (never used CMake GUI) so I can simply set in
my main CMakeLists.txt:
set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON)
This option does a lot of magic for MSVC that I never cared to look into, bu
I have done some light testing in this area.
Speculating a little here based on what you said, it seems like you’d want
scalable video, from an RTSP camera stream, delivered to the web (and support
mobile web browsers).
Web RTC is the “right way” to go and believe Ross is working on something f
(last reply got rejected, so trying again w/o trimming response)
Haven't tried this, so grain of salt.
The protected RTSPServer constructor has a parameter for the socket FD.
I think you could first, subclass the RTSPServer class so you can pass in your
own socket fd.
Using system calls w/ C++
Haven't tried this, so grain of salt.
The protected RTSPServer constructor has a parameter for the socket FD.
I think you could first, subclass the RTSPServer class so you can pass in your
own socket fd.
Using system calls w/ C++ or using .NET, initialize your own socket bound to
the NIC you p
Sorry to interject in you guys’ conversation, but I think there’s a bit of
confusion (maybe by me even).
It sounds like Gaurav wants to use Live555 w/ with a TLS socket for encrypted
media transmission over a network.
I could be incorrect, but since I have not seen a network abstraction in pla
AFAIK, there’s no built in mechanism for adaptive streaming.
There are some things you can do, but may not be flexible enough. For
instance, if you have a low-res-h264 and high-res-h264 version of a video, in
the server code, you could switch which file you are reading from, seek to the
same p
>>I have an application that has its own event loop when manipulating/reading
>>sockets
So it sounds like you would like to use your event loop with the live555
library. I have some experience here. I was able to get libuv event loop and
live555 work together. You should be able to do the sa
>> But perhaps you’ve defined your own subclass of “BasicTaskScheduler0”, and
>> are declaring an object of that subclass statically??
Yeah it’s a subclass of BasicTaskScheduler0, which (through many feet of
abstraction) was getting initialized statically. In the subclass I have the
mechanic
I’ve come across an issue where a BasicTaskScheduler0 gets statically
initialized (ran before main(…)) and the DelayQueue gets stuck in an infinite
loop.
I’ve found that the problem is in DelayQueue.cpp in the constructor of
DelayQueue.
DelayQueue::DelayQueue()
: DelayQueueEntry(ETERNIT
ing the winsock
include to "#include ".
I don't have the listen/accept methods finished yet to host an RTSP servers but
hope to get that in there soon!
Just thought I'd share as others may want to use this great RTSP library on the
win8 pl
After you parse the nal records from parseSPropParameterSets, store them.
For each sample that comes through, construct the buffer you send to your
upstream decoder like this:
Where start_code is 4 bytes 0x00, 0x00, 0x00, 0x01
[start_code][NAL_record_1][start_code][NAL_record_2][start_code][sam
Thanks so much! Just tried it out and works as you said!
This will surely appease my pedantic overlords =)
-Jer
From: live-devel-boun...@ns.live555.com
[mailto:live-devel-boun...@ns.live555.com] On Behalf Of Ross Finlayson
Sent: Tuesday, April 16, 2013 2:51 PM
To: LIVE555 Streaming Media - dev
Thank you so much for your quick reply. I'm always amazed on how quickly you
get back to this list! OTOH, I apologize for how late it took me to get back
to your response.
I could not figure out why my liveMediaPriv was never null on TCP streams.
Even tried directly on an IP camera's RTSP in
Hello,
I'm running the latest version ( live.2013.04.08.tar.gz ) on Windows 7, for
both rtsp client and server. I believe I have read all the old archives
relating to basicUsageEnvironment->reclaim() and that
basicUsageEnvironment->liveMediaPriv will be null if you close all your
mediums.
I
Thank you very much for taking the time to respond!
I hate JPEG streaming too, but the unfortunate part is we have a lot of
customers with investments with (old) MJPEG video encoders. It's a slow, but
eventual process in moving them to H264 encoders.
You are also 100% correct with your assessm
going wrong (besides using Windows hehe) and if there was a better way to fix
this.
Thanks for any help!
-Jeremiah Morrill
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
I went with a 1 thread per rtsp client and regret it from a scaling
perspective. The stack mem needed plus the overhead of having a thread gets to
be too much when you get into a large amounts of streams.
The library is _very_ well written to be non blocking and given the speed of
your slowes
You can probably use openRTSP as a good starting point for the code that does
the RTSP, but it's a lot more work than just that. Here's an overview of how
I've done this in the past.
1.)Create a DirectShow source filter (example in the Windows SDK C:\Program
Files\microsoft
sdks\Windows\
While I didn't look at your code in detail, I didn't see you mention what you
did with the h264 "subsession->fmtp_spropparametersets()".
In order for VLC to play, I believe you need to send the NAL units. Try
parsing the fmtp_spropparametersets with parseSPropParameters(...), and write
each re
19 matches
Mail list logo
