> Nothing happens afterwards and when I look at the H264 files created, they
> are indeed empty (despite my firewall being off).
I suspect that your “FramedSource” subclass (that encapsulates your encoder) is
not properly delivering NAL unit data to its downstream object (a
“H264VideoStreamDisc
Hi Ross,
Thanks for your help, I modified a few things and was able to make more
progress. The stream can now be initialized and received, but it blocks
there:
Received 185 new bytes of response data.
Received a complete PLAY response:
RTSP/1.0 200 OK
CSeq: 5
Date: Sun, Oct 06 2019 13:25:06 G
> On Oct 5, 2019, at 7:40 PM, Philippe Noël
> wrote:
>
> Hi Ross,
>
> It is not that, I tried turning off my firewall and it didn't work. The fact
> is, with or without the firewall, the rtsp url from my application doesn't
> move further than what I showed earlier, while a test url stream
Hi Ross,
It is not that, I tried turning off my firewall and it didn't work. The
fact is, with or without the firewall, the rtsp url from my application
doesn't move further than what I showed earlier, while a test url stream
like rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov wo
> On Oct 5, 2019, at 6:12 PM, Philippe Noël
> wrote:
>
> When I try to receive with openRTSP, the diagnostic output is:
>
> Created new TCP socket 3 for connection
> Connecting to 10.0.0.4, port 8554 on socket 3...
>
> It seems like it can't establish the connection, because nothing happens
When I try to receive with openRTSP, the diagnostic output is:
Created new TCP socket 3 for connection
Connecting to 10.0.0.4, port 8554 on socket 3...
It seems like it can't establish the connection, because nothing happens
after that. I looked further and I think I am streaming the TCP, but I
> On Oct 5, 2019, at 5:41 PM, Philippe Noël
> wrote:
>
> I tried with openRTSP and it says it's connecting to the stream but never
> actually connects, despite the server code actually saying the packets are
> being streamed.
What does that mean? What specifically is the diagnostic output
I tried with openRTSP and it says it's connecting to the stream but never
actually connects, despite the server code actually saying the packets are
being streamed. Any idea what might cause this?
Philippe
On Sat., Oct. 5, 2019, 19:50 Ross Finlayson, wrote:
>
>
> > On Oct 5, 2019, at 3:44 PM, P
> On Oct 5, 2019, at 3:44 PM, Philippe Noël
> wrote:
>
> That said, when I try to test my RTSP stream with VLC, nothing happens, any
> idea what might be going wrong?
VLC is not our software, so we can’t help you with this. Instead, you should
first be using “testRTSPClient” or “openRTSP”
Hi Ross,
I'm sorry, I should've better explained my problem and I really appreciate
the feedback. I was actually directly connecting my encoder to Live555
without a pipe and indeed I had the 'start codes' so I removed them, fixed
a few more problems and it pretty much works. I can now see the byte
You haven’t explained exactly how you’re connecting your encoder to (your
modified) “testH264VideoStreamer” code, but I’m guessing that you have a pipe
(or whatever the equivalent is called in Windoze) that connects the two. If
so, the problem of “packets being sent, clumped together, every 5 s
Hi Philippe,
I may have had a similar issue to what I think you are referring to.
My issue was there was an internal buffer of a pre-fixed size of 1000
holding H264 frames. Only when the buffer was full would Live555 pass the
frame(s) to the next Sink. Live555 would need to be updated to ignore t
Hi,
I've been working on integrating live streaming of a Windows desktop
(captured through DirectX11 and encoded with Nvidia NvEnc) through
testH264VideoStreamer. Globally I've been able to connect them, but the
stream aborts pretty quickly and I found the following behavior:
Packets seem to be s
13 matches
Mail list logo
