Dropping old packet received too late
Closed this issue · 17 comments
Hi Ethan,
When I stop the ffmpeg process and make it listen to the same ports again, it doesn't dump streams initially.
The ffmpeg process prints:
"Dropping old packet received too late"
And it goes on for a while.
Do you know why this happens?
Also is there a way to connect with you, one on one?
Hello,
when stopping the ffmpeg process is the process actually killed?
Also have the relaying consumers been completely stopped?
Hi Ethan,
When I stop the recording I pause the producers associated with the consumer but I don't do anything to the consumers.
Should I pause the consumers as well? Or maybe kill them?
Could you try killing the consumers?
Ok sure.
I will call consumers close and check if that works.
The implementation call for me to start and stop recordings intermittently....
The first time works smoothly.
Once I interrupt the producers, then it starts throwing the error.
Which is why I manipulated the producers.
I will try manipulation of consumers as well.. and let you know soon.
Thank you.
Closing, reopen if issue persists
Hi Ethan,
This issue is still present.
I delete the consumers associated with every instance of recording, when it is stopped.
But I still face this error of max delay reached.
Hello,
Can you check what port ffmpeg uses, then when you delete the ffmpeg process is the port still LISTENING?
Yes, I checked that.
When I delete ffmpeg and close the consumers, the ports are also released from use.
I observed some discrepancy in the VLAN, that may have affected the stream transmission.
Could that be the cause?
I'm creating consumers using pipe transports. So basically I'm receiving streams from another server on the same VLAN.
In this image, as you can see I come across this error randomly.
Does it work okay when you don't use the pipe transport?
Also you could try adding the below to the ffmpeg options
-reorder_queue_size 0
I have not checked if this happens without piped transports either.
I will initiate that implementation and check....
I am using the reorder_queue_size option now, let me see if it solves the situation I have been facing.
I will let you know soon.
This is what I face in the same scenario, after adding the "-reorder_queue_size 0" option.
I am basically stopping a process and starting another one with the same producers.
I am going to change my approach and use new producers with every new recording, maybe that will have an effect on the proceedings.
Finally some success.
I now close consumers, producers and piped transport with every recording closure.
It seems to have stopped the max delay error from ffmpeg, as of now.
I will test thoroughly and respond here. 👍
Great!
Haven't tried with pipeTransport so I can't give a detailed answer..
Cool.
Now maybe this will help others who try using piping.
It works completely fine with piped implementations too.
Must ensure that the transports are renewed with each recording, and not reused.
Great!
Though this is out of the scope of this project, this issue will be referenced whenever a similar issue is created.