[Live-devel] compilation issue / vcpkg / windows

[g.jaegy]

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.cpp), with a custom source (based on DeviceSource.cpp) which send down NALUs produced by NVEnc (without the NALUs start codes, thanks for your message). I'm using H265VideoStreamDiscreteFramer instead of the H265VideoStreamFramer used in the example. 

And it all works, quality is way better than what I managed to achieve using ffmpeg (packet loss is way lower, even when using multicast, possibly because live555 allowed me to configure the buffer size and has a better send scheme - I assume, haven't dug in the internals that much). Very stable, magically stable actually !

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. I'm using multicast sockets (same as in example). Maybe you have an idea ?

-----Original Message-----
From: live-devel <live-devel-bounces at us.live555.com> On Behalf Of Ross Finlayson
Sent: Friday, February 4, 2022 11:51 AM
To: LIVE555 Streaming Media - development & use <live-devel at us.live555.com>
Subject: Re: [Live-devel] compilation issue / vcpkg / windows



> On Feb 4, 2022, at 11:46 PM, g.jaegy <g.jaegy at imagine3d.fr> 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 and compiler dependent; its use is discouraged.

We could also get around this by allocating a fixed-size 65536-byte buffer instead, as this is the maximum possible size of a UDP (and thus RTP) packet.  I might end up doing this in a future release of the software.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/


_______________________________________________
live-devel mailing list
live-devel at lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel