> On Jan 31, 2020, at 1:37 PM, Jonathan Brady
> wrote:
>
> On 31/01/2020 20:38, Ross Finlayson wrote:
>>> On Jan 31, 2020, at 9:30 AM, Jonathan Brady
>>> wrote:
>>>
>>> Ross,
>>>
>>> Just a quick note to let you know that compilation with MSVC is broken due
>>> to the changes for TLS:
>>>
On 31/01/2020 20:38, Ross Finlayson wrote:
On Jan 31, 2020, at 9:30 AM, Jonathan Brady
wrote:
Ross,
Just a quick note to let you know that compilation with MSVC is broken due to
the changes for TLS:
In particular on line 1942 of liveMedia/RTSPClient.cpp the cast to const
u_int8_t * of data
> On Jan 31, 2020, at 9:30 AM, Jonathan Brady
> wrote:
>
> Ross,
>
> Just a quick note to let you know that compilation with MSVC is broken due to
> the changes for TLS:
>
> In particular on line 1942 of liveMedia/RTSPClient.cpp the cast to const
> u_int8_t * of data.
In FreeBSD (and prob
Ross,
Just a quick note to let you know that compilation with MSVC is broken
due to the changes for TLS:
In particular on line 1942 of liveMedia/RTSPClient.cpp the cast to const
u_int8_t * of data.
Removing the cast fixes the problem, I think this is because const char
* is signed using th
> On Jan 31, 2020, at 5:12 AM, Hansen Jan Rørgård
> wrote:
>
> Hi,
>
> Using cppcheck I noticed the following in the LIVE555 2020-01-28 version:
>
> DynamicRTSPServer.cpp :
> Line 65 : Return NULL; => fid is leaked
No. That line is reached only if “fid” is NULL.
> MatroskaFile.cpp:
>
> On Jan 31, 2020, at 3:20 AM, Avramoni, Sorin wrote:
>
>
> Hi,
>
> The video gets really bad when I try to mux it with audio, however audio is
> played ok. One thing that may go wrong is that my video encoder generates one
> access unit that contains multiple NAL units, what I do to be com
Hi,
Using cppcheck I noticed the following in the LIVE555 2020-01-28 version:
DynamicRTSPServer.cpp :
Line 65 : Return NULL; => fid is leaked
MatroskaFile.cpp:
Line 689 : Calculation of size to allocate requires parenthesis
Best Regards
Jan Rørgård Hansen
Senior Engineer
Communication Solution
Hi,
The video gets really bad when I try to mux it with audio, however audio is
played ok. One thing that may go wrong is that my video encoder generates one
access unit that contains multiple NAL units, what I do to be compliant is that
I parse it and extract one nal unit at a time, remove N
Thanks for sending me an example H.265 file. This file seems OK, and when I
convert it to a Transport Stream file (using our
“testH265VideoToTransportStream” application), this plays OK as well.
If your problem is occurring only when you try to multiplex together video and
audio (rather than j
