> On Feb 5, 2022, at 10:43 AM, g.jaegy wrote:
>
> Thanks for your answer.
>
> I was actually running VLC from two different PCs on my LAN.
>
> The fact that multiple clients connect should be fully transparent to me,
> right ? fPresentationTime should continue increasing normally, shouldn't
Thanks for your answer.
I was actually running VLC from two different PCs on my LAN.
The fact that multiple clients connect should be fully transparent to me, right
? fPresentationTime should continue increasing normally, shouldn't it ?
I'm having a week off, I won't be able to get back on this
And people often have problems when running more than one copy of VLC on the
same computer. (This is a VLC problem; nothing to do with LIVE555 or any other
server code.) When you do your tests, make sure that your copies of VLC are
running on *physically different* clients.
Ross Finlayson
Li
I thought that the problem might be related to RTCP; that’s why I asked you to
check your “fPresentationTime” values.
But because the problem seems to arise from your own code, it’s going to be
hard to figure out what’s going wrong.
I suggest starting from the original, unmodified “testH265Vide
Actually the stream plays fine on the newly connected player (#2), only the one
that connected first (#1) has the video frozen...
I'm getting a whole frame from nvenc. I decompose it in multiple NALUs, then
send each of them separately (i.e. each in a different provideFrame() call - or
another
> Only issue I have, when connecting a second client, the video on the first
> client stops one second later, basically the picture is not updated anymore.
> VLC statistics still shows newly decoded blocks and displayed frame, time
> increases, but the picture doesn't change on that first client
Possibly a solution indeed. At least I think it's a bit of a shame to rule out
VC++ because of such a tiny thing !
Anyway, your lib is really great. I've managed to integrated it in a day (dirty
prototype, I admit ;)). I now have a proper integrated RTSP server (based on
testH265VideoStreamer.c
> On Feb 4, 2022, at 11:46 PM, g.jaegy wrote:
>
> OK. Possibly one could also fix the error by using alloca(), possibly leading
> to the same result ?
Unfortunately I’m disinclined to use “alloca()”, because “man alloca” (at least
on FreeBSD) says:
The alloca() function is machine an
OK. Possibly one could also fix the error by using alloca(), possibly leading
to the same result ?
I'm using Visual Studio 2022 and can't really update.
-Original Message-
From: live-devel On Behalf Of Ross Finlayson
Sent: Friday, February 4, 2022 11:28 AM
To: LIVE555 Streaming Media -
> On Feb 4, 2022, at 10:58 PM, g.jaegy wrote:
>
> Upstream accidentally stepped on trying to use C99 VLAs;
> fOutBuf->curPacketSize() is not a constant.
>
> // Hack: Because the MKI + authentication tag at the end of the packet
> would
> // overwrite any following (still to be se
Hi Ross,
Vcpkg is a package manager from Microsoft (see https://vcpkg.io/en/index.html).
vcpkg basically downloads the source from the mentioned website and build it
automatically for you.
Live555 is available as a package. The download link configured in the Live555
vcpkg package was howeve
> On Feb 4, 2022, at 10:58 PM, g.jaegy wrote:
>
> While trying to build live555 through vcpkg (VS packet mananager), I get an
> error as the initial source tar.gz file had changed.
I don’t understand. Where did you get your copy of the LIVE555 code? The only
version of the code that we sup
While trying to build live555 through vcpkg (VS packet mananager), I get an
error as the initial source tar.gz file had changed. I reported the issue to
MS, they fixed the download link, however, with the latest release a
compilation error occurs:
https://github.com/microsoft/vcpkg/compare/mast
13 matches
Mail list logo
