-
Notifications
You must be signed in to change notification settings - Fork 32
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
Use ffmpeg to limit the read rate instead of setTimeout
#52
Comments
We previously used the -re flag but it resulted in desynchronized audio/video for certain hls streams: |
Interesting, I'll see if the related |
This is the stream I was testing with which was bugged: https://rbmn-live.akamaized.net/hls/live/590964/BoRB-AT/master_1660.m3u8 |
Did some more testing with the It assumes that the entire frame will arrive at once, which is not the case. At least on my Node.js installation, the incoming buffer size maxes out at 64KB, which is definitely not enough to contain the whole video frame, which can reach up to 1MB. This results in an effective frame rate of 1/3 to 1/4 actual. Using the About the |
Unfortunately it wasn't just hls streams that had this weird behavior. Author of issue also reported that some local mkv video files also had delayed audio when the |
About ffplay: It has an internal packet queue, which allows it to buffer a few hundred KBs of video to smooth out the playback. Not sure if we can add some kind of buffer in the library. |
Currently,
setTimeout
is used inAudioStream
andVideoStream
to control the read rate of the media. FFmpeg has a built-in flag-re
that does the same thing, and is potentially better? Need some more experimenting to see whether there's an improvement, and whether it impacts actual live streams (RTSP, SRT,...)Some info about the flag: https://ffmpeg.org/ffmpeg.html#:~:text=as%20live%20streaming.-,%2Dre%20(input),-Read%20input%20at
The text was updated successfully, but these errors were encountered: