> On Apr 16, 2024, at 2:43 PM, Denis Gottardello
> wrote:
>
>
> Hi, have you plan to implement h265 as codec for mp4 container?
> I'm using this command line
> ./openRTSP rtsp://localhost:554/proxyStream-6
> but I obtain 2 file: one for audio and a second one for video.
Because that’s how “o
Thank you!
I confirm that with version live.2022.12.01.tar.gz I can receive
streams with rtsp-over-https using calls like
openRTSP -T 8881 rtsps://127.0.0.1:12345/whatever
where 8881 would be the https port. The port in the url (12345) is
meaningless. "rtsps" in the url sounds misleading, but thi
> On Dec 2, 2022, at 9:41 AM, Gajdosik Johannes wrote:
>
> Hello Ross,
> I am sorry, it is not fixed yet.
Arggh! Unfortunately I can’t reproduce the exact situation you’re
encountering, so I had to guess the solution, without testing it.
> Analysis: Here is the modified code in RTSPClient::
Hello Ross,
I am sorry, it is not fixed yet.
Analysis: Here is the modified code in RTSPClient::connectionHandler1.
...
// The connection succeeded. If the connection came about from an
attempt to set up RTSP-over-HTTP, finish this now: if
(fHTTPTunnelingConnectionIsPending && !setupHT
> On Dec 1, 2022, at 2:32 AM, Gajdosik Johannes wrote:
>
> Hello Ross,
>
> Now I use the new version live.2022.11.29.tar.gz. And still get the same
> SIGSEGV:
OK, please try again with the next version: 2022.11.30. I think I’ve fixed it
for real this time.
Ross Finlayson
Live Networks, I
ction connectResult is set:
int connectResult = connectToServer(...)
On my computer connectResult is always 0, because connect returns EINPROGRESS.
Therefore fOutputTLS->connect can never be called and fOutputTLS is always
uninitialized.
Later, when the connection is established, connectionHander1 is called
Johannes,
Thanks for the report.
Yes, there was a bug in the RTSP client’s implementation of RTSP-over-HTTP
streaming, when done over TLS. I have just installed a new version
(2022.11.29) of the code that should fix this. (But should you still encounter
problems, let us know.)
Ross Finlays
> On Mar 23, 2021, at 6:16 AM, Tim Stanley wrote:
>
> I accept that the MP4 and Quicktime container may basically be the same but
> there must be some differences, even it is only in the file header. When i
> capture a video using openRTSP mediainfo reports is as a Quicktime container
> but
Ross,
Thanks for your reply
though we are using the -4 flag the video is being encoded into a Quicktime container.
This is a ‘red herring’. The MP4 file format *is*, basically, the QuickTime file format; see
> On Mar 19, 2021, at 4:30 AM, Tim Stanley wrote:
>
> Hi,
>
> We are using openRTSP as part of a custom firmware for the a series of CCTV
> cameras
That’s cool. (Remember that the LIVE555 code is distributed under the GNU
LGPLv3 license; see http://live555.com/liveMedia/faq.html#copyright-
SungHwan,
We don’t support the “Require:” header in “openRTSP” (or in our RTSP client
implementation in general), as it is rarely, if ever, used. I know of no RTSP
server that recognizes/handles this header.
What specific feature do you want to ask for (in a “Require:” header in a
“SETUP” req
)
thanks again,
Patrick
--
Message: 1
Date: Fri, 1 Nov 2019 10:32:18 +0100
From: "P. Min"
To: live-de...@us.live555.com
Subject: Re: [Live-devel] openRTSP, how to capture ONVIF metada stream
co
> You could check this for sure by running ?testRTSPClient? (rather than
> ?openRTSP?), because ?testRTSPClient? outputs a line for every RTP packet
> that it receives.
Thanks, that's useful: indeed only seeing video/H264 packets arrive.
Do you know of a public test camera that produces a met
> On Oct 31, 2019, at 7:31 AM, p...@min.nl wrote:
>
> After that, the video file fills up ok, but the "metadata" file remains empty.
>
> What could be a reason for this?
Without having access to this stream, it’s hard to say for sure. But I suspect
that the server is simply not sending any R
This is very strange. The problem seems to be the "EBADF (Bad file
descriptor)”, which tells us that our event loop is trying to do a “select()”
on a socket that has already been closed. Our code has had bugs like this in
the past, but I had thought that we had caught them all by now.
I suspe
Very well! Many thanks.
giancarlo
Il Sab 7 Lug 2018, 08:37 Ross Finlayson ha scritto:
> I’ve now installed a new version of the code that fixes this problem. (In
> this case, only the “playCommon.cpp” file was changed.)
>
> The problem was much simpler than I’d initially feared. The ‘periodic
I’ve now installed a new version of the code that fixes this problem. (In this
case, only the “playCommon.cpp” file was changed.)
The problem was much simpler than I’d initially feared. The ‘periodic file
output’ mechanism was not working properly if the “-c” (play continuously)
option was al
OK, thanks.
I’ll see if I can reproduce (and then fix) this problem. (Unfortunately, this
could take a long time, given that the problem takes several hours to appear).
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
___
live-devel maili
As concerns the exagerate "-D" value, it was due to my misunderstanding.
Thanks for the tip.
Here you are two real file names (with the relative size) but nothing of
unusual, exept for the absence of expected following file on sequence
(eventually tagged with 22300-22310) and the bug in question:
> Now, speaking about "-P", I've found that after several hours I've launched
> the following command:
>
> openRTSP -D 1 -c -B 1000 -b 1000 -q -F (prefix) -d
> 28800 -P 10 -t (url)
>
> the program stops producing single .mov files, each of 10 seconds, and starts
> produ
On 5/24/2018 16:29, Karl Denninger wrote:
>> On 5/24/2018 15:38, Ross Finlayson wrote:
>>> Karl,
>>>
>>> I can’t help you with your problem with the MP4-format file; however:
>>>
2. Attempting to extract just the video track ("-v") appears to work, and
a file command shows "test.h264: JV
>>>
>> The latest version (3.0.1) of VLC has a known bug that makes it unable to
>> play “.h264” (i.e., raw H.264) video files. However the previous version
>> (2.2.8) of VLC should work OK.
> Unfortunately it appears that the base ExoPlayer can't decode it, which
> strongly implies that whate
Sorry for the top-post but wanted to flag this -- I was wrong about the
".ts" file being able to be consumed, it is not --
05-24 16:58:24.496 12619-12619/com.google.android.exoplayer2.demo
D/EventLogger: Renderer:0 [
Group:0, adaptive_supported=N/A [
[ ] Track:0, id=1/256, mime
On 5/24/2018 15:38, Ross Finlayson wrote:
> Karl,
>
> I can’t help you with your problem with the MP4-format file; however:
>
>> 2. Attempting to extract just the video track ("-v") appears to work, and a
>> file command shows "test.h264: JVT NAL sequence, H.264 video @ L 50", which
>> should be
Karl,
I can’t help you with your problem with the MP4-format file; however:
> 2. Attempting to extract just the video track ("-v") appears to work, and a
> file command shows "test.h264: JVT NAL sequence, H.264 video @ L 50", which
> should be ok. However, I cannot play that with *any* of the
> On Mar 31, 2018, at 12:28 AM, Ing. Mirko Manetti
> wrote:
>
> Does a file format supported by both "opentrsp" and "Live555 media server"
> exist?
Yes - various audio or video ‘Elementary Stream’ file formats, depending on the
codec - including:
- H.264, H.265, MPEG-4 video (filen
Does a file format supported by both "opentrsp" and "Live555 media
server" exist?
Il 30/03/2018 13:12, Ross Finlayson ha scritto:
I have a question about my application. I have a NVR (network video recorder). It's Linux
based and it is based on NXP imx53 SOM (core ARM CORTEX A8) that get st
> I have a question about my application. I have a NVR (network video
> recorder). It's Linux based and it is based on NXP imx53 SOM (core ARM
> CORTEX A8) that get streaming from IP cameras and store files on HDD using
> OpenRTSP in ".mp4" format (-4 option).
> We need also to stream recorded
Janosch,
Sorry for the delay in responding to this; I’m currently dealing with a large
email backlog.
First, I assume that when you play this "rtsp://" stream directly - e.g., using
VLC - it plays OK?
It might be possible to update our MP4-file recording module
(“QuickTimeFileSink”) to overco
> I've acquired video on the Pi using "cat /dev/video0 > test.264" and
> attempted two things with the resulting test.264 file. First, I used it as
> the source for testH264VideoStreamer (same results as before, empty output
> file from openRTSP). Second, I tried to wrap it into an MP4 using Han
Hi Ross,
I've acquired video on the Pi using "cat /dev/video0 > test.264" and
attempted two things with the resulting test.264 file. First, I used it as
the source for testH264VideoStreamer (same results as before, empty output
file from openRTSP). Second, I tried to wrap it into an MP4 using
Hand
> I'm attempting to use testH264VideoStreamer to stream the output of my RPi's
> camera to a LAN, and to receive/open the stream with openRTSP. I've done this
> successfully using a raw h264 file as the source for testH264VideoStreamer,
> however when I attempt to use the output of the Pi's came
Hi Ross,
First, thank you for your response. I updated to the latest version
shortly after posting to the list.
The command is truncated from the GDB output, I am specifying -d 86400
and -P 1800. I am specifying -d basically with the intent of having
cron start the command once a day with
> I have started using openRTSP to try and put together a simple network video
> recorder for some Grandstream IP cameras that I have. I am consistently
> getting segfaults when running on Ubuntu 14.04 with the livemedia-utils
> package installed from apt.
First, please upgrade to the latest v
I've downloaded and compiled the latest tgz and so far i've gotten 2
files written with no segfault, so we will see.
On 09/20/2016 12:34 PM, Eric Tamme wrote:
Hello all,
I have started using openRTSP to try and put together a simple network
video recorder for some Grandstream IP cameras that
> The standard syntax to specify a user name and/or password is:
> "rtsp://:@
It depends on the server. Including “:@“ in the RTSP URL
is a bad idea (because it causes the username and password to be sent over the
net ‘in the clear’. But some servers require this. Other, more sensible
serve
The standard syntax to specify a user name and/or password is:
"rtsp://:@
So you could try ./openRTSP -o rtsp://admin@192.168.0.103
>>> Dave Buchanan 12/18/15 8:51 AM >>>
>
>
>>
>> Hi people
>>
>> First of all thank you for providing the software, which I think is exactly
>> what I am look
>>> ./openRTSP rtsp://192.168.0.103/username=admin
[…]
>>> Received a complete DESCRIBE response:
>>> RTSP/1.0 451 ERROR
>>> Server: H264DVR 1.0
>>> cseq: 3
The error “451” (returned by the server) means “Bad Parameter”. This suggests
that adding “username=admin” to the URL may have been a mist
>
>
>>
>> Hi people
>>
>> First of all thank you for providing the software, which I think is exactly
>> what I am looking for
>> I have the DVR in a remote location and I wish to take an image every minute
>> or so and upload it to a server, this way if the remote location is
>> compromised
thank you. the problem was simply with Vlc playback.
with other players we don't have any issues (mediaPLayer classic or
ffplay).
i can mark this as closed.
thank you ,
giacomo
2015-05-18 20:56 GMT+02:00 Marcin :
> For me the problem is that you need to start recording on an I-Frame
> first. I
For me the problem is that you need to start recording on an I-Frame
first. I deal with that by skipping NAL units that doesnt start with a
keyframe. Otherwise you get trash at the beggining.
Marcin
W dniu 2015-05-18 o 12:28, Giacomo Parmigiani pisze:
Hello,
we have an ip-camera streaming via
> I have tested openRTSP on my IP camera (H264 stream). It saves .mp4 file
> without problem.
>
> 1. The .mp4 file can be played by Linux Mint's default videos player, but
> cannot by VLC.
>
> VLC shows "undef" stuff.
VLC is not our software. Bugs (or apparently bugs) in VLC should be reporte
: jeudi 9 octobre 2014 17:07
À : LIVE555 Streaming Media - development & use
Objet : Re: [Live-devel] openRTSP complain about mpeg4-generic mode
Trying to get an audio stream with openRTSP reports the error
MPEG4GenericRTPSource Warning: Unknown or unsupported "mode": AAC-hbr.
Are
> Trying to get an audio stream with openRTSP reports the error
> MPEG4GenericRTPSource Warning: Unknown or unsupported "mode": AAC-hbr.
Are you using the latest version of the software???
See "liveMedia/MediaSession.cpp", line 1291. When the "MPEG4GenericRTPSource"
object is created, the 'mod
> If i undestand right - the "-d" duration parameter in openRTSP the time since
> the openRTSP started negotiating paramters, right? Because i recive sometimes
> shorter dumps of stream than specified duration (in example, when negotation
> part takes longer than usual).
I'm not sure I understa
No. Our code delivers data (in this case, to the OS pipe, and from there to
your "ffplay" command) once it arrives. The 'increasing delay' that you're
seeing has to be caused by your downstream code (your "ffplay" command) not
consuming data fast enough. Either your "ffplay" command is CPU bo
My next question would be what if some RTP packets are delayed? How will
the client behave? Will it wait for "x" seconds and continue. If it waits
then there will be a delay that may be carried on to the next time the
packets are delayed. Maybe that's where the delay is.
On Sep 18, 2014 6:14 PM,
> I don't know, but it's not "openRTSP". (Our RTSP/RTP client software does
> not include any buffering, or significant delay.) The delay is probably some
> combination of the OS pipe (i.e., the "!"
Oops, I meant 'the "|"', of course (I typed the wrong character).
> ) and "ffplay" itself (i.e.
> here is my command line
>
> ./OpenRTSP -v -Q -D 1 -n rtsp://:554/11 | ffplay -loglevel verbose
> -fflags nobuffer -i pipe:0
>
> Now this delay slowly keeps increasing from 1.5 sec upto 4~5 seconds in about
> 20 minutes. And I assume it will continue to increase with time.
>
> So my questions
Does open broadcast need raw video as input? Live555 is a streamer only.
I decoded my frames using libavcodec(FFMPEG) and then apply them to a
texture using opengl or directx on windows,linux,mac,android or iphone.
same procedure for all.
Libavcodec decodes to YUV422 data, That is a luminance value
> I am seeing an issue when running multiple instances of openRTSP to capture
> h.264 data from multiple IP cameras. I am using command line options to
> allow openRTSP to save the data into 12 second periodic files. I have
> openRTSP compiled and running on QNX 6.5.0 and can stream data from
The diagnostic output from "openRTSP" shows that you are using a (very) old
version of the "LIVE555 Streaming Media" software. We support only the latest
version of the code. Please upgrade to the latest version; see
http://www.live555.com/liveMedia/faq.html#latest-version
Also, I see
1) The server is IP camera. Details below:
Kernel version: Linux 3.0.8 armv5tejl
File system version: TH38R2-ONVIF V2.5.0.6 build 2014-01-26 12:39:49
Here is issuer firmware link:
http://www.en.tpsee.com/firmware/20140127/firmware_HI3518C-V2-ONVIF-V2.5.0.6_20140126123951.bin
Here is the SDK:
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
Martijn,
Thanks for the report. The following change to the code should prevent the
problem:
In "QuickTimeFileSink.cpp", line 321, change
subsession->readSource()->stopGettingFrames();
to
if (subsession->readSource() != NULL)
subsession->readSource()->stopGettingFrames();
I'll
Hi Ross,
Thanks for looking into this. I recompilled with linux-gdb enabled, see
output below.
martijn@shuttle:~/src/live$ gdb /home/martijn/src/live/testProgs/openRTSP
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GN
> Any idea what goes wrong?
Unfortunately not, because I wasn't able to reproduce this crash. Please
recompile everything with "-g" (by doing: "make clean; genMakefiles linux-gdb;
make"), and rerun gdb, so we can see a more detailed stack trace.
Ross Finlayson
Live Networks, Inc.
http://www.l
Hello,
I know that this lists are useful for others, when they have
similar problems.
My system is Gentoo linux x64, afther an emerge -e system, emerge -e world
and upgrade kernel from 3.7.1-gentoo to 3.12.1-gentoo all is perfect now!!!
Is working like an charm!!, dont know for shur but I
Hi,
What i can say it that you try to connect to AirCam camera which has
very limited RTSP implementation and dont count that something will
change in the future.
There is even no beta FW available above version 1.2 that you already have.
Marcin
W dniu 2014-01-08 15:39, Ross Finlayson pisze:
I can't explain the "Bad file descriptor" error; I've never seen that happen
before. Something is wrong either with the operating system on that computer,
or the way in which you built the "LIVE555 Streaming Media" code for that
operating system. (If it's Windows, then perhaps you used the wro
thank you for help and sorry for not posting the link, but
this camera with this log is behind an router
http://pastebin.com/im1Td2zi
with -p 554
http://pastebin.com/i8u4TaHv
and this camera is not, this camera and the pc has routing ip's
http://pastebin.com/pNkGut6V
with -p 554
http://pastebin.
> I'am trayng to play an stream from an ip camera, but is not working until I
> use with -p option to specify the port.
>
> this is the log without -p option:
There wasn't any log here.
> the error is:
> Unable to create receiver for "video/H264" subsession: getsockname() error:
> Bad file
> ProxyServer seems to handle reconnect scenarios pretty well. Would your
> implementation of RTSPClient in ProxyServer be a good model for how to add
> this functionality for client applications?
It depends upon what client application you have in mind, but I imagine so...
> Have you consider
Ross,
Thanks for your replydespite the absence of an actual question :-) A
few days after posting the email to the list, I discovered that this had
been "asked and answered".
ProxyServer seems to handle reconnect scenarios pretty well. Would your
implementation of RTSPClient in ProxyServer b
> I have a quick question regarding the expected behavior of openRTSP client w/
> file output when connection to the server is lost due to reboot, loss of
> connectivity...etc.
The rest of your message didn't contain a question :-) However...
The only reliable way for a client to detect when a
> openRTSP allow to make QOS mesurement and print it when it exits.
> This is nice but do you think it could be an possible evolution to print
> periodically ?
Perhaps, though it's very low priority.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
On 06/08/13 00:45, Ross Finlayson wrote:
OK, the problem here is with the *server* - it should not be hanging
when it receives the client's "TEARDOWN" command. Please contact the
server's manufacturer, and tell them to fix this problem.
However, to allow for this situation occurring (the serv
> Sending request: TEARDOWN rtsp://:554/mpeg4/media.amp/ RTSP/1.0
> CSeq: 7
> User-Agent: /usr/local/bin/openRTSP (LIVE555 Streaming Media v2013.07.31)
> Session: 0723151412
> --
>
> and the output hangs.
OK, the problem here is with the *server* - it should not be hanging whe
Ahh, seems I was a bit premature with my last reply, in my excitement I
had been running the command without the -t switch which doesn't show
the problem.
Now if I run the full command again I get the following in the openRTSP
output after the -HUP signal:
--
inter_packe
On 05/08/13 22:12, Ross Finlayson wrote:
User-Agent: openRTSP (LIVE555 Streaming Media v2011.12.23)
You're running a (very!) old version of the "LIVE555 Streaming Media"
software. You should upgrade.
Ross, thanks for the very quick response.
I've downloaded the latest version and compile
> User-Agent: openRTSP (LIVE555 Streaming Media v2011.12.23)
You're running a (very!) old version of the "LIVE555 Streaming Media" software.
You should upgrade.
> I'm afraid I don't know how to obtain version numbers from openRTSP itself,
> hence I'm referring to the packages included in the
> Using some camera, it is needed to ask for a multicast stream in the RTSP
> SETUP, but openRTSP always set this flag to False.
> If this could help others users, you could find attached a modification that
> add –W to set the forceMulticastFlag to True.
OK, I'll add this to the next release of
Ceszcz!
Marcin wrote:
Hello,
I had to do almost the same goal as You - record incomming AV stream (h264/aac)
to MP4 files. What i did was that live555 only dumped streams into separate
files and then i used MP4Box to merge them into working mp4 file.
Thanks for this hint! I am not able to mux th
Hello,
I had to do almost the same goal as You - record incomming AV stream
(h264/aac) to MP4 files. What i did was that live555 only dumped streams
into separate files and then i used MP4Box to merge them into working
mp4 file.
Greetings,
Marcin
michael.sch...@dlr.de pisze:
Ross wrote:
Ross wrote:
> Michi wrote:
>> Am I correct to think that openRTSP should transcode the raw streams
>> correctly using the -4 option?
>
> In principle, yes (except that our code doesn't do any "transcoding"; it just
> records already-encoded data). However, this is difficult to do well,
> becaus
> Am I correct to think that openRTSP should transcode the raw streams
> correctly using the -4 option?
In principle, yes (except that our code doesn't do any "transcoding"; it just
records already-encoded data). However, this is difficult to do well, because
the ".mp4" file format is ill-suit
> I would like to ask You if this is possible at all
Unfortunately not. This is a completely non-standard RTP profile (and payload
format) that - to my knowledge - isn't publicly described anywhere.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
> Do you think it could be helpful to add in openRTSP such a feature ?
Yes, good idea. It will be included in the next release of the software.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
___
live-devel mailing list
live-devel@lists.li
As we clearly note in the "openRTSP" documentation (web page), and the
"openRTSP" source code itself, we don't recommend using the "openRTSP" code as
a model for your own RTSP client application. Instead, you should use the
"testRTSPClient" application code as a model.
Ross Finlayson
Live Netw
Thanks a lotJ.
From: live-devel-boun...@ns.live555.com
[mailto:live-devel-boun...@ns.live555.com] On Behalf Of Jeremiah Morrill
Sent: Wednesday, March 14, 2012 3:03 AM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] OpenRTSP application
You can probably
> You can probably use openRTSP as a good starting point for the code that does
> the RTSP
FYI, the code for the new "testRTSPClient" demo application is probably a
better model to use than "openRTSP" (which has lots of extra 'bells and
whistles').
Ross Finlayson
Live Networks, Inc.
http://ww
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\
>> Is it possible to not specify a frame-rate?
>
> Of course. However - due to the limitations of the ".mov"/".mp4" file format
> - if you omit this parameter (or if the frame rate varies), it's unlikely
> that you'll end up with a file that you'll be able to play.
Thanks to your help, I have
> My problem is that I get no audio at all
No, you are 'getting audio' just fine, as evidenced by:
> also I know that a file is created: audio-MP4A-LATM-1
The "openRTSP" application reads audio and video data from a RTSP stream, but
does not 'play' it. Instead, it just writes the incoming data
On Feb 9, 2012, at 9:39 AM, Jim Van Vorst wrote:
> Can I use openRTSP to receive a stream, convert to .mp4 or .mov, and pipe to
> another program, or does the container format prevent this?
Yes, the file format prevents this. ".mov"/".mp4" files must be seekable
files; they can't be unseekabl
> When I record a streamed file from an IP camera the file has perfect audio
> sync the first time through but upon scrubbing it loses sync and throws a lot
> of compression artifacts. I found that if I flatten the file or make the
> movie self contained, essentially moving the tracks from the r
>> Is it possible to not specify a frame-rate?
>
> Of course. However - due to the limitations of the ".mov"/".mp4" file format
> - if you omit this parameter (or if the frame rate varies), it's unlikely
> that you'll end up with a file that you'll be able to play.
OK, I will work with the ca
> Is it possible to not specify a frame-rate?
Of course. However - due to the limitations of the ".mov"/".mp4" file format -
if you omit this parameter (or if the frame rate varies), it's unlikely that
you'll end up with a file that you'll be able to play.
Ross Finlayson
Live Networks, Inc.
h
I'm using the live555 library in order to save an RTSP stream from a PTZ
camera. I used the openRTSP program in the "testProgs" directory in order to
test whether it would work with the camera I was using. From the output, the
program was able to connect to and talk to the camera and request
>>> I'm using the live555 library in order to save an RTSP stream from a PTZ
>>> camera. I used the openRTSP program in the "testProgs" directory in order
>>> to test whether it would work with the camera I was using. From the
>>> output, the program was able to connect to and talk to the came
>> I'm using the live555 library in order to save an RTSP stream from a PTZ
>> camera. I used the openRTSP program in the "testProgs" directory in order
>> to test whether it would work with the camera I was using. From the output,
>> the program was able to connect to and talk to the camera
> I'm using the live555 library in order to save an RTSP stream from a PTZ
> camera. I used the openRTSP program in the "testProgs" directory in order to
> test whether it would work with the camera I was using. From the output, the
> program was able to connect to and talk to the camera and r
> When we are writing a quicktime file from an IP address stream the recording
> turns out fine. The issue we are having is that when viewing the file in
> quicktime after the recording we get compression artifacts when scrubbing
> through the timeline, additionally the audio sync is off after s
> Basically, I want to have in the same computer a web server (in my example
> apache) and the live555 media server as RTSP server
You CANNOT do this if these two servers use the same port number. I.e., if you
already have an Apache web server running using port 80, then
"live555MediaServer" c
Thank Ross for your rapid answer
Basically, I want to have in the same computer a web server (in my
example apache) and the live555 media server as RTSP server,therefore I
need apache working as an HTTP proxy for RTSP requests (?)... but in my
tests it did not work. (I don't know if I need to
In general, I see no reason why RTSP-over-HTTP would not work through a HTTP
proxy.
However, I'm confused by your last statement:
> Is there any other possibility in order to support RTSP over HTTP and a web
> service over 80 port in the same machine?
By this, do you mean a RTSP-over-HTTP clien
> I'm trying to capture a RTSP stream from my internet modem.
> The URL is
> "rtsp://mafreebox.freebox.fr/fbxtv_pub/stream?namespace=1&service=202&flavour=hd".
> I can view the stream using VLC but not with openRTSP.
[...]
> Received a complete SETUP response:
> RTSP/1.0 500 Internal Server Error
Hello, first of all thank you all for maintaining this forum so active
I am using openRTSP to recieve a stream with a
.sdp this stream contains video and audio
streams, but I´m only interested in the video,
which is encoded with h264, when i am trying to
decode with ffmpeg I obtain NAL errors
I have been trying to use openRTSP (from liveMedia dated 2010.12.05) to
record clips from an IP camera that supports RTSP streaming of MPEG-4
clips, but the recorded clips would not play back in Quicktime 7.6.8
(1675) on Windows.
I hope you used the "-w ", "-h " and "-f " options.
After analy
: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] openRTSP writing all zeros
>Yes, if I omit the "-m" option the single large file looks the same.
>I've tried using a debugger to trace it back. I'm not at my work
>computer right now, so th
1 - 100 of 205 matches
Mail list logo
