> On Jan 4, 2024, at 8:24 PM, R, Ranjith via live-devel
> wrote:
>
> But I want to confirm where in Live555 code where the packet is getting
> discarded
Packets are not being discarded anywhere in the LIVE555 code. Note that a
LIVE555-based server simply sits in a loop, writing a sequence
--- Begin Message ---
Hi Dan ,
I understand that increasing the compression rate will reduce the data size and
issue may not occur.
As you said it will affect the quality of the image or decoding may take more
time.
But I want to confirm where in Live555 code where the packet is getting
disca
I apologize if this doesn't make sense in your implementation, but if the
device mfg does not have (or want to give you) a way to slice large packets -
another approach might be to set the compression on the camera much higher.
I've not run into a camera or encoder that does not have some form o
--- Begin Message ---
Hi Ross,
I am yet to ask the device team to check that part, before that I want to
confirm by increasing the socket buffer size(and working) or see some error
logs in Live555 layer where the packets are dropped(because of high key frame
size).
Thanks and Regards,
Ranjith
> On Jan 4, 2024, at 12:43 AM, R, Ranjith via live-devel
> wrote:
>
>
> Please share your input.
Did you do the following, as I advised:
> HOWEVER, your real problem is your IP camera: It is sending key frames as
> single H.264/H.265 NAL units that are much, much too large for video
> st
--- Begin Message ---
Hi Ross,
As per your suggestion I tried increasing the socket buffer size, still we
observe the same issue.
This is the command used in OpenRTSP, OpenRTSP.exe -v -b 100 -B 100 -P
60
I added logs in line 616 in "MultiFramedRTPSource.cpp" that is inside
"Reorderin
