HLS Video/Audio Sync Issues

[scalhoun]

When I stream my mp4 file directly audio and video are in sync. But when I use the hls version the audio is way out of sync with video.

Does anyone have any tips to avoid this issue? My video files are > 1gb and have the meta data at the beginning of the file.

I am using the default local config from README.md with aio support.

Thanks in advance!

[erankor]

can you send a link to some mp4 file that is showing this problem ?
we have been using this module on hundreds of thousands of videos and haven't experienced any out of sync, so maybe your videos are encoded in some special way that causes it.
you can also send it to me in private if you prefer - eran.kornblau at kaltura dot com

[erankor]

I checked it out, this is caused because the audio track in this mp4 is 0.7 behind the video track.
When I initially looked at this, I guessed this was the problem, but didn't see it since for some reason mediainfo does not report it correctly:
root@pa-front-stg2 ~# mediainfo kingsway_20150830_b48b38.mp4 | grep relative
Delay relative to video : 66ms

ffprobe is showing it correctly:
root@pa-front-stg2 ~# /web/content/shared/bin/ffmpeg-2.1.3-bin/ffprobe-2.1.3.sh -i kingsway_20150830_b48b38.mp4 -show_packets -select_streams a 2>/dev/null | grep pts_time | head -1
pts_time=0.700000

root@pa-front-stg2 ~# /web/content/shared/bin/ffmpeg-2.1.3-bin/ffprobe-2.1.3.sh -i kingsway_20150830_b48b38.mp4 -show_packets -select_streams v 2>/dev/null | grep pts_time | head -1
pts_time=0.000000

I need to add parsing of the elst mp4 atom in order to extract this info, will add it to the todo

[scalhoun]

Nice! Thanks so much for checking that out. I'll just keep an eye on this thread for the update.

[erankor]

Hi @scalhoun,

Sorry for the very long delay, and thanks for your patience.
I pushed a fix to this issue here: #190.
The fix eliminates most of the out of sync issue, I say 'most' and not 'all' since in the sample you sent me, the audio track is delayed by 0.7 sec while the video track is ahead by 0.06 sec. The code currently supports only positive shifts, so it will apply a shift of 0.7 sec while it should actually apply 0.76 sec, but this is far less disturbing than how it used to be.

Eran

[scalhoun]

Sweet thanks!

-- 
Shane Calhoun
Sent with Airmail

On December 6, 2015 at 11:22:58 AM, erankor (notifications@github.com) wrote:

Closed #142.

—
Reply to this email directly or view it on GitHub.