reaks in real world code.
>
> No, it works just fine. It just needs to be used properly.
Well, it's escalated quickly from "just use replicator->createStreamReplica()"
to creating new components with intricate
knowledge of the internal workings of Live555.
> In any
gh all the places with
hardcoded C style casts and fix them to use dynamic_cast<> and check for a
StreamReplica. This does then not work for H264 streams, as
isFramedSource() is a private member of FramedSource. Why has it been inherited
as private?
Anyway, currently stream replicating does not
disk for later streaming.
Yes, I know JPEG video is far from ideal, but in this case it's a question of a
demo that would prerecord some minutes
of live camera footage and then replay said material over and over again. H264
tends to drop frames and have glitches
even when run over localhost wh
...
Here fSource is a StreamReplicator and not a JPEGVideoSource, so the cast will
be bogus.
Would perhaps be better to use dynamic_cast<> here, then the sanity check would
work. As the
StreamReplica class is internal to StreamReplicator specialHeaderSize
>
> The reason for this is that the first
> "createNewStreamSource()"/"createNewRTPSink()" calls are to create 'dummy'
> objects that the RTSP server uses to get the stream's SDP description (for
> the RTSP 'DESCRIBE" command). These two objects are then deleted (thus the
> "FYI" above). Then, 'real' source and sink objects are created.
Yes, that seems to be normal behavior.
So far there doesn't seem to be any error in what I'm trying to do, but the
stream simply is not playing. Is there
really a startPlaying() being called for the replicated stream too?
--
Jan Ekholm
jan.ekh...@d-pointer.com
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
case.
So, for MJPEG there are a few issues.
--
Jan Ekholm
jan.ekh...@d-pointer.com
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
file? Later I also need
to be able to save streams that are local cameras multicasted as well as remote
proxied cameras.
--
Jan Ekholm
jan.ekh...@d-pointer.com
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
teNew( envir(), m_subsession->readSource() );
m_replicator = StreamReplicator::createNew( envir(), framer, False );
if ( ! m_subsession->sink->startPlaying(
*m_replicator->createStreamReplica(), ... ) {
means no video is delivered at all anymore. So the replicator does something
f
rtPlaying( * discreteFramer, ... ) ) {
}
This does deliver a video stream, but it's unwatchable. The individual images
are ok, but the video is stuttering
back and forth, as if it was zig-zagging over the time line. There is not too
much documentation for
StreamReplicator and the provided example is quite limited.
--
Jan Ekholm
jan.ekh...@d-pointer.com
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
e using an old version of the code. You should upgrade!
Aha, I see that the new version has removed the parameter. It was a bit
redundant.
Are there any changelogs for changes like these?
--
Jan Ekholm
jan.ekh...@d-pointer.com
___
live-devel mailing
S NAL unit information
> that your RTSP client already got from the downstream server (camera).
With those two changes it works. Thank you for the help. There is btw no
H264VideoRTPSink::createNew() version that takes
the arguments you mention, you need to add the profile-level-id too, bu
se
OutPacketBuffer::maxSize,
but none works.
--
Jan Ekholm
jan.ekh...@d-pointer.com
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
that had me debugging all kinds of code. It's not particularly clear when
Live555 takes
ownership of something or gives it to your code. Smart pointers would be the
way to
go here, of course.
Just in case someone googles for "bad file descriptor&
way that the 'blocking TCP send() with
> timeout' hack was implemented in the previous revision.
>
> Please upgrade to the latest version: 2014.05.14
I think the same bug was discussed here in another thread last week, so I
actually guessed it
was already fixed. But you never know if
I've spent enough time trying to debug that and
must move on for now. I hope to find the problem later when I get more familiar
with Live555, it's not an easy library to use.
I'm sorry for the time I've wasted for all readers.
One t
sense. If you want to test a client-server
> combination, then start with one combination that you know works OK
> ("testOnDemandRTSPServer" with "openRTSP"), then change only one end at a
> time as you continue your testing.
I can test tomorrow with one of the test servers against my client. But even a
badly working client
should not be able to cause problems (cut stream) for another unrelated client.
--
Jan Ekholm
jan.ekh...@d-pointer.com
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
On 6 maj 2014, at 23:35, Jan Ekholm wrote:
>
> On 6 maj 2014, at 23:07, Ross Finlayson wrote:
>
>> Once again:
>>
>>>> In fact, I suggest that you first run the (unmodified!)
>>>> "testOnDemandRTSPServer" application, using "t
at this combination works OK.
It does, once I got rid of isSSM. Now testRTSPClient runs forever, at least for
a definition of forever that
goes up to 30 minutes. So that at least is not an issue anymore and was my
mistake.
--
Jan Ekholm
jan.ekh...@d-pointer.com
___
amer.cpp", but it's all been rewritten when moving
to OnDemandServerMediaSubsession
and as I learned how to do H264. The only line of code left from that was the
one that did the ServerMediaSession::createNew() call.
Everything else is similar to testOnDemandRTSPServer.
--
Jan E
"camera0"): Liveness indication
RTSP client session (id "133E19DE", stream name "camera0"): Liveness indication
after few seconds, which I did not get when isSSM=True. My own client does not
seem
to send those, but instead I get these every 10 seconds or so:
parseRTSPRequestString() succeeded, returning cmdName "GET_PARAMETER",
urlPreSuffix "camera0", urlSuffix "", CSeq "10", Content-Length 0, with 0 bytes
following the message.
sending response: RTSP/1.0 200 OK
CSeq: 10
Date: Tue, May 06 2014 18:44:53 GMT
Session: 6A8077BD
Content-Length: 10
This is quite complicated... I'm sorry for troubling you with this, but I'm
grasping at straws
trying to get this to work.
Best regards,
Jan Ekholm
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
sockets open and these
time out after a while. When
these time outs occur there seems to be a bigger risk for my client to freeze.
I haven't found out why, but it
only happens when the server is Live555-based.
I also now see that the server always streams over TCP, not UDP a
client. That should tell you if the problem is with your server, or with
> your client.
Great, thank you for those debugging tips! Especially the test applications
will quickly show me if
there is any data delivered at all.
--
Jan Ekholm
jan.ekh...@d-pointer.com
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
look forward to diving deep into the libav code.
So, are there any callbacks, defines or similar to get a bit more info as to
what is
going on?
Kind regards,
Jan Ekholm
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
that can be called from a non-LIVE555 event loop thread.)
I have used triggerEvent() successfully when I did try to run my own Boost
based event loop. It did get too
messy though, but the events worked perfectly.
I think I prefer to handle the ra
On 22 apr 2014, at 19:01, Jan Ekholm wrote:
>
>>> Also, is there some way to know when all clients have disconnected from a
>>> RTSP source
>>> so that I could stop grabbing and encoding frames?
>>
>> This should happen automatically. I.e., wh
et to true as
the camera can only be opened once. I will have to dig deeper so see why the
MJPEG source does not stop.
Both OnDemandServerMediaSubsession are very similar, apart from the H264 one
having the extra dummy
sink to get the aux data.
--
Jan Ekholm
jan.ekh...@d-pointer.com
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
frames? It seems to work
automatically for
my H264 stream, but the MJPEG stream continues encoding forever. Both are
handled using a OnDemandServerMediaSubsession subclass to create the source
and the sink.
I hope these questions make any sense and I'd be happy for any hints.
Best regards,
500 ms caching it seems to
work without any errors. That's really too much delay for my use case though,
but good to know where it comes from.
Thank you for pointing it out to me!
--
Jan Ekholm
jan.ekh...@d-pointer.com
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
d testRTSPClient to provide a real decoding sink in place of
the DummySink,
but I'd like to avoid doing that if possible.
Any ideas? I'm more than happy to be lectured on my bad ways of measuring time
and latency. :)
Best regards,
Jan Ekholm
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
at least, not
> for free) on this mailing list.
Indeed, I understand that.
--
Jan Ekholm
jan.ekh...@d-pointer.com
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
he mechanism that I suggested above (piping "openRTSP" into a
> modified "testH264VideoStreamer"), then you could update the
> "testH264VideoStreamer" some more, by feeding the "StreamReplicator" from the
> input "ByteStreamFileSource&qu
duplicate" the incoming stream into my custom code for doing
the
image manipulation while at the same time keeping the normal proxied stream
working?
I'm sorry if these questions are dumb, but I didn't find anything in the docs
or examples.
Best regards,
Jan Ekholm
___
32 matches
Mail list logo
