@rorie (also @wcarle): I have done some testing of my own and believe to have found out what the problem is.
The short of it is: Akamai will occasionally serve a malformed video segment that repeats (part of) the audio stream, but not the video stream. The player seems to handle this by continuing to play that segment's audio stream while the video stream of the next segment starts playing.
The initial suspicion came from playing around with ffmpeg and a GB video delivered through HLS. I noticed that ffmpeg would occasionally warn about non-monotonous audio timestamps. If that warning was present in the log, the created video file contained a loop identical to what has been observed by me and others in this thread. If the same video was downloaded with ffmpeg *without* any of these warnings appearing in the log, the video file did not contain any audio repetitions.
In order to catch this while watching a video on the site I used Fiddler to capture all of my browser's traffic while viewing a GB video (today's Moonlighter QL in this case).
Once I hit an audio loop I simply repeated the requests for the last dozen or so segments and compared the sizes. Since I've found through my ffmpeg testing that requesting a segment again is unlikely to deliver another malformed one, this quickly allowed me to single out a segment that had changed between the two requests:
This way I was able to dump the malformed and the non-malformed segment #174 as well as the preceding and subsequent segments from Fiddler's cache and can share them here if you want to have a look for yourselves:
When examining the malformed segment with ffprobe or mediainfo we can see that the audio stream has a duration of ~19 seconds, while the video stream lasts the expected 10 seconds:
$ ffprobe -show_entries "stream=duration,codec_name,codec_type" segment174_6_av_malformed.ts
<snip!>
[STREAM]
codec_name=h264
codec_type=video
duration=10.009678
[/STREAM]
[STREAM]
codec_name=aac
codec_type=audio
duration=18.965333
[/STREAM]
All other segments show the same 10 seconds for the video and audio stream.
Based on Akamai's documentation (at least the public part) I assume they use some kind of on-the-fly repackaging from mp4 to HLS. Given my observations this leads me to believe there might be a problem with the repackaging process of the video on their end, which will occasionally result in malformed segments like these being served to viewers.
Based on these results and other testing I have done with hls.js I do not believe that the audio looping is caused by an issue with the Giant Bomb player or the hls.js library that is used to play back HLS content.
While I'm not too familiar with the underlying specs for MPEG-TS and HLS I do assume that an audio track longer than the video track is not permitted in a standard-conforming segment (hence me referring to it as malformed). While it might be possible to work around this inside of hls.js, ultimately this is something Akamai has to fix on their end.
As an aside: this issue happens a lot more recently. At least as far as I can tell. It happened three times to me during the Wreckfest QL!
Edit: Edited out some typos that sleepy me left for you to find.
Log in to comment