Rodn3y

Hello,

I noticed that a couple videos are missing from the /api/videos endpoint. For instance the latest episode of "Die Another Friday" and "This is the run" are not listed in there. Other premium content like older episodes of those two shows are included however.

I'm just have fairly simple query parameters: format=json, offset=0, limit=25 and my API key.

While I like the redesign overall there are a few small things I think could be improved:

• The audio podcast player looks a bit weird since it's just the video player, I'd prefer a smaller version that also allows the description/download/rss stuff to sit below and be visible without having to pause the podcast
• Similar thing for videos: descriptions/download buttons below so they're always visible
• Player controls (e.g. quality options) can be cut off at the sides as if the player was in an iframe rather than part of the site

I got a bit bored and turned this into a simple website that shows the results of bi-daily automatic tests: rodney.io/audioloopdetector/

Update:Both my automatic and manual tests indicate this issue is finally fixed!

Interestingly that it also appears that the speed of the CDN has increased for uncached/old content across the board.

At least right now the situation still seems unchanged.

I noticed that the error message I get from ffmpeg changed from "Non-monotonous DTS in output stream" (WARN) to "Application provided invalid, non monotonically increasing dts to muxer in stream" (ERROR) i.e. Akamai did something but it's still borked. I'd have to spend a lot more time going through ffmpeg source code and take a closer look at the segments to figure out what has changed.

How this seems to manifest is that instead of an audio loop being at the end of a segment, it is now at the beginning. They are also shorter (2-3 seconds). I'll see if I can provide some more example segments tomorrow.

Edit - Here is an example segments for this new kind of audio loop from today's Spectrum Retreat QL:

• segment127_0_av_malformed.ts
• segment127_0_av.ts

@forcen: There's a post about video downloads that says the limit is 25 20, though in reality it's higher. And yes it applies to unoffical video apps since those can't access the HLS streams (which would be something nice to get with the upcoming changes btw).

The HTML5 mode will actually use more data because there's a bit of overhead to HLS. While I have not tested this with GB I checked another site some time ago and the overhead for HLS compared to direct MP4 streaming was around 3-4%.
That might not necessarily mean that it is cheaper for GB, Akamai could bill it differently for example. But I wouldn't worry too much about it.

@forcen said:

Progressive mode counts against your video download limit (since it's technically the same as downloading the video), therefore you can only watch a limited number of videos per day. Though that limit is probably high enough that you're unlikely to actually run into any issues with that.

@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:

• segment173_6_av.ts
• segment174_6_av.ts
• segment174_6_av_malformed.ts
• segment175_6_av.ts

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.

Ok thanks for the update. I created a small workaround in my scripts by doing a HEAD request with "8000" instead of "4000" in the url to determine if that rendition is available. It's not ideal as it counts against the download limit but works for the time being.

@rorie hey have you heard anything new about this? Unfortunately there's still no way to get the new 8000 kbit HD version from the API.