st
need a simple one-shot application.
I am very unfamiliar with Live555 and C++ in general, so excuse me if
this is rather basic.
Thanks,
Tim
--- End Message ---
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailma
be a bug. I am trying to compile a new version in the following pull request but keep getting a message about invalid conversion from 'int*' to 'socklen_t* - https://github.com/Dafang-Hacks/Main/pull/86
Thanks
Hi,
We are using openRTSP as part of a custom firmware for the a series of CCTV cameras - https://github.com/EliasKotlyar/Xiaomi-Dafang-Hacks
We are using openRTSP to capture an MP4 file that we can then send as a notification via Telegram. The Tele
Ok. It was my problem. I should have opened the file as binary. I added the 'b'
to file open mode, and it worked.
FILE *fout = fopen(fname,"wb");
Thanks for your help.
Tim Gee<mailto:tim@aldiscorp.com> | Senior R&D Engineer
Aldis<http://www.aldisco
ld occur.
I'll keep looking.
Tim Gee<mailto:tim@aldiscorp.com> | Senior R&D Engineer
Aldis<http://www.aldiscorp.com/> | 10545 Hardin Valley Rd. | Knoxville TN |
37932
o: 865-978-6535 | f: 865-249-6608
From: live-devel-boun...@ns.live
medSource *src = scs.subsession->readSource();
scs.subsession->sink->startPlaying(*src, subsessionAfterPlaying,
scs.subsession);
if (scs.subsession->rtcpInstance() != NULL) {
scs.subsession->rtcpInstance()->setByeHandler(subsessionByeHandler,
scs.sub
Thanks.
I'm able to view the RTSP stream in VLC and the Onvif device manager, which
also uses Live555.
The buffer is plenty big enough, and I'm not seeing truncated bytes.
Tim Gee<mailto:tim@aldiscorp.com> | Senior R&D Engineer
Aldis<http://www.aldiscorp.com/>
out = fopen(fname,"w");
fwrite(fReceiveBuffer, frameSize, 1, fout);
fclose(fout);
// Then continue, to request the next frame of data:
continuePlaying();
}
Tim Gee<mailto:tim@aldiscorp.com> | Senior R&D Engineer
Aldis<http://www.aldiscorp.com/> | 10545 Hardin
doing this? It appears that
JPEGVideoRTPSource contains a private virtual function called
processSpecialHeader() that is meant for this task, but I don't understand the
Live555 architecture well enough to know how this should get called.
Thanks,
Tim
Tim Gee<mailto:tim@aldiscorp
;s a professional source. And the group is not 'left' by the
socket, as previously discussed.
Quite baffled. I'll continue investigating. I won't rule out kernel
level issues either at this stage!
Thanks,
-Tim
parseRTSPRequestString() succeeded, returning cmdName &
On 18/12/12 11:20, Ross Finlayson wrote:
Unfortunately I wasn't able to reproduce your problem at all. I ran
"testMPEG2TransportStreamer" to continuously stream a Transport Stream
file via multicast, and also ran "testOnDemandRTSPServer" to receive
this multicast stream, and use it as input fo
...RTSP
client session (id "CC070355", stream name "test"): Liveness indication
RTSP
client session (id "CC070355", stream name "test"): Liveness indication
...RTSPClientConnection[0xe23f20]::handleRequestBytes()
read 142 new bytes:TEARDOWN rtsp://10.2.1.182:8554/test/ RTSP/1.0
As you can see - much more data is received, but significantly less than
required!
So, it would seem to me that there's perhaps a timing delta being used
somewhere that becomes wildly incorrect between client connections
(supposing the client count becomes 0).
Hope this helps some!
Thanks and regards,
-Tim
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
estructor may be
the cause of this unexpected behaviour.
Would you suggest I write my own subclassed source and destructor, or do
you think this behavour should be contained within the standard live555
source?
Thanks and regards,
-Tim
___
live
e quite
happy with that! However, when another client arrives later, the
multicast stream source does not appear to become active again. I can
confirm however that createNewStreamSource from
MPEG2TransportUDPServerMediaSubsession.cpp is being called as
it is, can this behaviour be
altered so that the source remains connected in absence of RTSP clients?
Thanks and regards,
-Tim
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
time_base_seconds useconds) {
fTv.tv_sec = seconds; fTv.tv_usec = useconds;
}
#pragma GCC diagnostic pop
Thanks,
Tim
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Ross,
This is fascinating but I can't picture it. What would the design look
like for multiple processes (one per stream as you describe)?
Are there any examples of this that I can take a look at?
Thanks,
Tim
On Fri, Jul 27, 2012 at 1:23 PM, Ross Finlayson wrote:
> When impl
On 18/10/11 09:14, Tim J Shackleton wrote:
On 17/10/11 17:54, Ross Finlayson wrote:
Yes, but are you sure that a wrap-around is, in fact happening (and
is the cause of your problem)? A rough calculation shows that - at 10
Mbps - the "fTSPacketCount" variable (which counts 188-byte
most things. I think I feel quite comfortable with this as a fix. :-)
I will respond with my results next week, when I expect the issue to
manifest on the unpatched version.
Thanks and regards,
Tim
___
live-devel mailing list
live-dev
than a fix, I know.
If this wrap is in fact causing the issue, would you consider it a bug?
If so, is this something you would prefer to address in a later release
or something I should provide a patch for?
Thanks again for your hard work and patience.
Reg
Hi,
when I use live555mediaServer as my rtsp server, I found that it always not
send
the last frame(mpeg4) or slice(h264). I look into the source code, it seems tha
when it come to the last frame, the parser cann't found the next start code, so
the server can't handle the last frame's data cor
PIDs should have the discontinuity_indicator flag when they first
occur in a clip, inspecting the clips and adjusting them accordingly.
Looking forward to your comments,
Thanks,
-Tim
- Original Message -
From: Ross Finlayson
To: LIVE555 Streaming Media - development & use
Sent: Tuesday
than pass through the source PCR?
Thanks and regards,
Tim Shackleton ___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
23 matches
Mail list logo
