Seems like something went wrong when creating the bug:
"Does this work in other browsers" Should be, Yes.

Asking Dale for initial feedback or alternative owner.

Is the issue unique for Mac OS X or can it be reproduced on other platforms as well?

Likely your media is bad. Audio timestamps are generated based on the decoded samples so they are 100% accurate. If you time the video frames without regard for the audio samples you'll end up with the error messages like those in the log.

@henrika: It can be reproduced on Windows 10 as well.

@dalecur: We're investigating this as well, the HLS we're transmuxing is a live stream with ads stitched into the stream and the fragments comes from different sources. The weird thing is that it works fine on other browsers like firefox & IE11.

Agree with Dale - it seems likely that the timestamps are incorrect in the fragmented mp4. This is easy to get wrong when you're splicing ads into content. 

The audio buffer that comes just before the ad gets spliced in will have some timestamp T and duration D. The timestamp of the next audio buffer, T_next (the first for the ad) should equal T + D. 

When I run the hls.js demo I see T_next = T + D + ~60 msec. 

Re, this point:
> what is happening is that on some specific audio sample, Chrome accounts for 2 audio samples instead of 1.

The durations I'm seeing, including those around the "Large timestamp gap..." look very consistent. 

decoder_stream.cc(565)] OnBufferReady<audio>: 0, timestamp: 136142645 duration: 21333 size: 16 side_data_size: 0 is_key_frame: 1 encrypted: 0 discard_padding (ms): (0, 0)
decoder_stream.cc(565)] OnBufferReady<audio>: 0, timestamp: 136163979 duration: 21333 size: 33 side_data_size: 0 is_key_frame: 1 encrypted: 0 discard_padding (ms): (0, 0)
decoder_stream.cc(565)] OnBufferReady<audio>: 0, timestamp: 136185312 duration: 21333 size: 16 side_data_size: 0 is_key_frame: 1 encrypted: 0 discard_padding (ms): (0, 0)
render_media_log.cc(30)] MediaEvent: MEDIA_ERROR_LOG_ENTRY {"error":" Large timestamp gap detected; may cause AV sync to drift. time:136185312us expected:136121332us delta:63980us"}
decoder_stream.cc(565)] OnBufferReady<audio>: 0, timestamp: 136206645 duration: 21333 size: 16 side_data_size: 0 is_key_frame: 1 encrypted: 0 discard_padding (ms): (0, 0)
decoder_stream.cc(565)] OnBufferReady<audio>: 0, timestamp: 136227979 duration: 21333 size: 16 side_data_size: 0 is_key_frame: 1 encrypted: 0 discard_padding (ms): (0, 0)
decoder_stream.cc(565)] OnBufferReady<audio>: 0, timestamp: 136249312 duration: 21333 size: 16 side_data_size: 0 is_key_frame: 1 encrypted: 0 discard_padding (ms): (0, 0)

This all looks good. 21333 us at 48khz is 1024 samples per buffer - basically no crazy numbers here. No signs of any 2x or .5x size buffers. 


Re, the attached mp4: the distortion is present in both firefox (linux, version 55) and chrome for me. I also tried using ffplay and found it there (along with lots of warning output from the AAC decoder). Looks like that file may have other issues, so I've focused on the hls.js demo steps for now.

Re: Firefox - I think their media clock implementation is different in a way that makes it more forgiving - perhaps they trust the mp4 timestamps more. 

IIRC chrome used to trust the muxed timestamps for pacing the media clock, but found that the numbers are often imprecise. The imprecision doesn't necessarily accumulate, but it does awful things for video smoothness. 

Thanks for sharing your finds!
At the moment we're using a workaround to resolve this on chrome ( When ads aren't playing anymore we move back 0.5s in time ).

I will continue investigating this when I can.