Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FFmpeg-WHIP: Initially, the latency was about 150ms, but it later increased to approximately 480ms #3222

Closed
winlinvip opened this issue May 14, 2023 · 8 comments
Labels
legacy Related to Janus 0.x

Comments

@winlinvip
Copy link

What version of Janus is this happening on?
0.10.10. The bug is present in version 0.10.10, but it may also exist in other versions, including the latest one.

Have you tested a more recent version of Janus too?
No. Since we haven't tested it with the latest version, it doesn't appear to be related to the version.

Was this working before?
No.

Is there a gdb or libasan trace of the issue?
No.

Additional context
We are currently exploring ways to enable ffmpeg to support WHIP. We conducted tests using Janus and the results were positive, with very low subsecond latency.

At first, the latency was around 150ms, but it later rose to approximately 480ms, as depicted in the images below.

image image

As we do not possess extensive knowledge of Janus, we are unable to debug the code ourselves. Therefore, we would greatly appreciate your assistance in identifying potential solutions to address this issue.

Replay steps

We have provided a step-by-step reproduction of this issue, which should allow you to reliably reproduce it. This issue is not occurring randomly.

@lminiero
Copy link
Member

lminiero commented May 15, 2023

An increased delay suggests that something may be wrong with respect to the RTCP exchange. How advanced is RTCP support in your WHIP integration?

@atoppi
Copy link
Member

atoppi commented May 18, 2023

v0.10.10 is from two years ago, please try to experiment with a recent Janus version or you might encounter other issues that could have already been solved!

My advice for debugging the issue is to do a pcap through the admin API of both pub and sub legs, then study the RTP timestamps and check the origin of the skew.

@lminiero
Copy link
Member

v0.10.10 is from two years ago, please try to experiment with a recent Janus version or you might encounter other issues that could have already been solved!

I hadn't noticed the test was made against v0.10.10... then obviously yes, test the latest 0.x or master.

@lminiero
Copy link
Member

That said, I don't see this delay with master. I've tried capturing the screen, using a stopwatch page demo, and the delay seemed constantly around 100/120ms to me (I've kept it open for some time).

Screenshot_2023-05-18_17-27-04

@lminiero
Copy link
Member

lminiero commented Jun 1, 2023

Closing as apparently not an issue.

@lminiero lminiero closed this as completed Jun 1, 2023
@winlinvip
Copy link
Author

winlinvip commented Jun 2, 2023

I conducted a test on version 1.1.4 and found that the latency remains the same, at approximately 520ms.

  Starting Meetecho Janus (WebRTC Server) v1.1.4

To replicate the problem, you can follow the instructions provided at ossrs/ffmpeg-webrtc#1 (comment)

@lminiero
Copy link
Member

lminiero commented Jun 2, 2023

I already saw the instructions: how do you think I tested it the last time? 😉
As I already said, I don't get those delays. Sounds like an issue in your Janus setup maybe?

@winlinvip
Copy link
Author

winlinvip commented Jun 2, 2023

I got it. 👍 If you're unable to reproduce this issue, it's possible that the problem is specific to my environment. In that case, we can close this issue, and it's unlikely that others will encounter the same problem.

I have updated the picture that shows the usage of FFmpeg+Janus. I used your snapshot, which has a latency of about 120ms.

image

Thank you for your attention. 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
legacy Related to Janus 0.x
Projects
None yet
Development

No branches or pull requests

3 participants