OK, understood, I didn't initially get it. Thanks for the explanation, that
makes sense ! I promise I won't annoy you anymore, I apologize for the
inconvenience.
-Original Message-
From: live-devel On Behalf Of Ross Finlayson
Sent: Monday, February 14, 2022 4:09 PM
To: LIVE555 Streaming
> On Feb 15, 2022, at 3:53 AM, g.jaegy wrote:
>
> So, you were right.
>
> Setting fPresentationTime using gettimeofday() solves the problem.
>
> Now, this however means the output frame time is not correlated to the time
> at which the original frame was captured (I'm capturing frames at 3
So, you were right.
Setting fPresentationTime using gettimeofday() solves the problem.
Now, this however means the output frame time is not correlated to the time at
which the original frame was captured (I'm capturing frames at 30Hz, but
possibly the interval between two frames is not 100% c
Actually, I set fPresentationTime to the application time (time got using QPC,
which I saw is also used in gettimeofday()) at which the initial frame was
captured. So, it should be consistent and increasing. All NALUs composing a
single frame have the same presentation time, is that incorrect ?
> On Feb 15, 2022, at 2:44 AM, g.jaegy wrote:
>
> This all works, until a second client connect. In that case, the first client
> stop playing.
>
> I must be doing something wrong, but I don't know what.
>
> Would you have any advice or hint that would allow me to find out what is
> wrong ?
It is not easy to figure out what's wrong.
I'm mostly using the same initialization code as testH265VideoStreamer.cpp
(this code is in the main() function).
I'm using a different implementation of play() however. I've created a custom
class inheriting from FramedSource which is responsible for
Hi Ross,
I confirm there is no problem with using testH265VideoStreamer (along with the
"surfing.h265" file).
So, I'll have to dig into my code to see what's going on... I have absolutely
no idea at this point. It seems it doesn't occur everytime a new client
connects (I would say 50%).
-
