> In fact, you *might* try having your “ReplicaJPEGVideoSource” class inherit
> from both “JPEGVideoSource” and “FramedFilter”, but I’m not sure whether or
> not that will work. (I’m wary of multiple inheritance in C++, and haven’t
> used it at all in any of the LIVE555 code so far.))
FYI, I l
> Ok, I think I've found the issue. The culprit here is the StreamReplica class
> which is
> a FrameSource, but it is not a JPEG video source, i.e. it does not return
> True for:
>
> virtual Boolean isJPEGVideoSource();
OK, so yes - that’s the problem.
The data that you feed to “JPEGVideoRTPS
On 17 okt 2014, at 16:48, Ross Finlayson wrote:
>> Yes, I see JPEGVideoRTPSink being destroyed three times as
>> createNewStreamSource() is called three times.
>> First with a clientSessionID=0 and the other times with valid large ids. No
>> idea why three times, perhaps VLC which
>> acts as
> do you have a sample file “test.mjpeg” that works with your example?
No.
Note, BTW, that JPEG video streaming is strongly discouraged; see
http://www.live555.com/liveMedia/faq.html#jpeg-streaming
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_
> By which method (variable?) do sinks and sources actually share the raw video
> data?
To help understand this, I suggest taking a look at the “DeviceSource” model
code (in “liveMedia/DeviceSource.cpp”). Note, in particular, the comments on
lines 102-121.
Ross Finlayson
Live Networks, Inc.
> Yes, I see JPEGVideoRTPSink being destroyed three times as
> createNewStreamSource() is called three times.
> First with a clientSessionID=0 and the other times with valid large ids. No
> idea why three times, perhaps VLC which
> acts as the client does something interesting. Trying with testR
Hi Michael,
do you have a sample file "test.mjpeg" that works with your example?
DISCLAIMER:
This e-mail may contain confidential and privileged material for the sole use
of the intended recipient. Any review, use, distribution or disclosure by
others is strictly prohibited. If you are not the i
Hi Ross,
On one server, before your modification, it was crashing more than once per
hour.
With this new version it seems ok.
Many Thanks,
Michel.
[@@ THALES GROUP INTERNAL @@]
De : live-devel [mailto:live-devel-boun...@ns.live555.com] De la part de Ross
Finlayson
Env
Sorry for double posting, was a mistake.
From: live-devel [mailto:live-devel-boun...@ns.live555.com] On Behalf Of Alan
Martinovic
Sent: Friday, October 17, 2014 11:38 AM
To: live-devel@lists.live555.com
Subject: [Live-devel] Mechanism of passing data from source to sink
Hi,
I've read how the con
Hi,
I've read how the control flow mechanism works
(http://www.live555.com/liveMedia/faq.html#control-flow)
and I'm trying to get the idea of how it works in practice by following the
Elphel example (http://www.live555.com/Elphel/).
I've traced the actual payload to the fTo variable
#ElphelJPEG
Hi,
I've read how the control flow mechanism works
(http://www.live555.com/liveMedia/faq.html#control-flow)
and I'm trying to get the idea of how it works in practice by following the
Elphel example (http://www.live555.com/Elphel/).
I've traced the actual payload to the fTo variable
#ElphelJPEG
On 17 okt 2014, at 04:34, Ross Finlayson wrote:
>> I've use Live555 for some prototypes for a while now and it's working quite
>> well so far. My use cases
>> are to act as a cental video hub for a number of remote surveillance cameras
>> as well as locally connected
>> USB cameras and serve H
Ok, I think I've found the issue. The culprit here is the StreamReplica class
which is
a FrameSource, but it is not a JPEG video source, i.e. it does not return True
for:
virtual Boolean isJPEGVideoSource();
This is what is checked in:
Boolean JPEGVideoRTPSink::sourceIsCompatibleWithUs(MediaS
13 matches
Mail list logo
