Sorry, please change the title to

"HLS video got error after I upgraded to Chrome 64.0.3282.119"

Thank you.

Here are my comments from the github, FFmpeg says:

[aac @ 0x7f834f8f5000] SSR is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented.
[aac @ 0x7f834f8f5000] If you want to help, upload a sample of this file to ftp://upload.ffmpeg.org/incoming/ and contact the ffmpeg-devel mailing list. (ffmpeg-devel@ffmpeg.org)

I'm surprised this worked at all in previous versions since apparently this has been an issue for years:

https://trac.ffmpeg.org/ticket/1693

Probably this generated a non-fatal decoder error in the past, but resulted in a/v sync and other subtle issues over the lifetime of the stream.

I don't think we should work around this issue by ignoring these errors. The SSR packets have duration, so skipping them gradually accumulates a/v sync issues. Which means these streams do not play correctly in any version of Chrome, though prior to M64 they did not fail entirely.

I don't have an ETA for when we can provide SSR support; I'll see what it takes to implement, but it's probably at least a quarter away. This along with a need for loudness metadata may require us to switch AAC decoding libraries; specifically fdk-aac has support for both of these AAC types,

https://github.com/mstorsjo/fdk-aac

Though as with any new library this would require legal, security, and performance review -- so again it would take some time even if we can switch.

Dalecurtis,

Sorry that I just know you are the contributors of Chromium.

Many of our old videos have this issues now. 
Do you have any approaches so we can play these "broken" videos in newest Chrome?

Thank you.

Thank you.

Unfortunately the only way to fix this is to re-encode the AAC audio streams w/o using SSR.

Notably Firefox does not play this audio stream either; but seems to entirely reject the audio stream, thus avoiding any errors.

Actually I'm not sure what's happening in Firefox, it seems to be configuring a wmf-audio decoder but no audio comes out.

Hello,

My Firefox can play this video with audio stream.
My Firefox version is Firefox Quantum 58.0.1 (64 bits) which is the newest version.

But it is very wired that the newest versions of Firefox, Safari, IE can play this "broken" video. 

Isn't that possible to use other approach to patch Chrome so that it can play this video? 

Thank you.

Hmm, I think audio is just entirely broken in Firefox for me for some reason; given that it's using the OS level decoder just like Edge, it should play fine there.

There's no possible quick patch to Chrome to allow this file to play; we can revert to the old state, but even on M63 it was losing ~1 second of a/v sync every 10 seconds (try in M63 and notice that audio cuts out at 18 seconds vs the clip duration of 20 seconds).

We'll have to add support for SRR and that's going to take time. To get these files playing in Chrome you will have to re-encode them.

Is it possible to revert to the old state for recently release before SSR support? I know there is sync problem in the video but at least these types of videos can play well and it makes Chrome more compatible. 

Thank you. 

I agree that this issue should be elevated. As a video publisher this is affecting hundreds of our videos (and thousands of our clients). While we are able to re-encode the videos, the task is time consuming. For the first time we are advising users (that are experiencing the issue) to not use Chrome. 
 
We have scripts processing that are counting how many videos are affected by this issue and will reprocess, but this new "feature" has broken previous functionality. All other browsers can play these videos fine (including Chrome's 63 and lower).

@chianhsieh: No, sorry we would not revert to behavior that was previously hiding a/v sync issues. 

@chris.macdonald: Are you referring to SSR AAC streams or junk in mp3 files? In the AAC case, they've never worked in Chrome -- accumulating massive a/v sync as time progresses. In the mp3 case, depending on the state of your files a simple remuxing / mp3val pass should be sufficient to fix issue.

It isn't mp3, it is AAC LC.

From ffprobe:

Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 127 kb/s (default)

Can you provide a sample? What does ffmpeg say if you try the following? 

$ ffmpeg -i <file> -vn out.wav

Do you get errors about SSR not being supported? If so you will need to re-encode the AAC audio using a copy of ffmpeg compiled with support for libfdk-aac:

./ffmpeg -acodec libfdk_aac -i <file> -acodec libfdk_aac -vcodec copy out.mp4

Probably you'll want to tune the aac encoding parameters if this is the route you go down.

Yes, I get errors about SSR not being supported. These files play fine in Chrome 63 and lower, and all other major browsers. I can provide a sample file but can the URL be retracted after? The file is too large to upload through the form (22 MB).

Here's the ffmpeg output:

ffmpeg version 3.3.3 Copyright (c) 2000-2017 the FFmpeg developers
  built with Apple LLVM version 8.1.0 (clang-802.0.42)
  configuration: --prefix=/usr/local/Cellar/ffmpeg/3.3.3 --enable-shared --enable-pthreads --enable-gpl --enable-version3 --enable-hardcoded-tables --enable-avresample --cc=clang --host-cflags= --host-ldflags= --enable-libass --enable-libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-libxvid --enable-opencl --enable-videotoolbox --disable-lzma --enable-nonfree --enable-vda
  libavutil      55. 58.100 / 55. 58.100
  libavcodec     57. 89.100 / 57. 89.100
  libavformat    57. 71.100 / 57. 71.100
  libavdevice    57.  6.100 / 57.  6.100
  libavfilter     6. 82.100 /  6. 82.100
  libavresample   3.  5.  0 /  3.  5.  0
  libswscale      4.  6.100 /  4.  6.100
  libswresample   2.  7.100 /  2.  7.100
  libpostproc    54.  5.100 / 54.  5.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Downloads/2201_deGruev_091610_F_Web.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf54.63.104
  Duration: 00:09:39.37, start: 0.000000, bitrate: 302 kb/s
    Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 448x336, 165 kb/s, 29.97 fps, 29.97 tbr, 11988 tbn, 59.94 tbc (default)
    Metadata:
      handler_name    : VideoHandler
    Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 127 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
Stream mapping:
  Stream #0:1 -> #0:0 (aac (native) -> pcm_s16le (native))
Press [q] to stop, [?] for help
Output #0, wav, to 'out.wav':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    ISFT            : Lavf57.71.100
    Stream #0:0(eng): Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, stereo, s16, 1536 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
      encoder         : Lavc57.89.100 pcm_s16le
[aac @ 0x7ff346000600] SSR is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented.
[aac @ 0x7ff346000600] If you want to help, upload a sample of this file to ftp://upload.ffmpeg.org/incoming/ and contact the ffmpeg-devel mailing list. (ffmpeg-devel@ffmpeg.org)
Error while decoding stream #0:1: Not yet implemented in FFmpeg, patches welcome

To be clear these files don't play fine in Chrome 63 or lower; they played, but not well. In the case of the original reporter the audio falls behind by ~1 second for every 10 seconds of video; depending on your actual encoding it could be better or worse.

You should re-encode these files using libfdk_aac as mentioned in c#19, I can't provide a timeline for when Chrome might be able to support this since it's not simple to add.

This bug is also affecting audio-only files where A/V sync is not relevant. It is a very heavy lift to re-encode years worth of these files so I am also, for the first time, telling clients to use a browser other than Chrome. We need these changes undone, at least for a short time, so we can update encoding processes. 

Even if you have audio only files, we were dropping 100ms of audio every second. Which is definitely audible even to untrained ears.

We are facing same exact issue with Audio streams and causing major problem on our platform, any plan on updates ?

Even we are facing the same issue.It is very difficult to re-encode the TBs of audio.Do we have any other option apart from re-encoding?

Count me in the group that prefers Chrome to play these files not well rather than not at all. Instead of re-encoding whole archive libraries with libfdk, it's not possible for the decoder to just ignore the SSR data?

There's some discussion on the ffmpeg bug tracker indicating that the ssr packets can be decoded poorly if we parse and ignore the ssr data first. I'm still investigating if this will work.

Can folks provide a couple for SSR samples here? I want to ensure we are differentiating between bad streams and those that are actually SSR. 

In my case it is not an SSR issue.I am getting :-
[aac @ 0x7fe20f805e00] Input buffer exhausted before END element found

It was playing fine till Chrome 63 and there was absolutely no lag in the audio.

This is the entire output:-

[aac @ 0x7fe20f805e00] Input buffer exhausted before END element found
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '02-01-2018-085638.m4a':
  Metadata:
    major_brand     : mp42
    minor_version   : 0
    compatible_brands: isommp42
    creation_time   : 2018-02-01T03:26:57.000000Z
    com.android.version: 8.1.0
    com.android.manufacturer: Google
    com.android.model: Pixel XL
  Duration: 00:00:18.29, start: 0.000000, bitrate: 132 kb/s
    Stream #0:0(eng): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, mono, fltp, 128 kb/s (default)
    Metadata:
      creation_time   : 2018-02-01T03:26:57.000000Z
      handler_name    : SoundHandle

Deleted: 02-01-2018-085638.m4a 294 KB

02-01-2018-085638.m4a 294 KB Download

The behavior in 64+ is inconsistent with previous versions, and all other browsers. We can/are re-encoding our files but this is taking time. We have invested countless hours to get all our files to work with this new "feature". We have had to analyze all our files, retrieve hard drives from storage, re-export the project files, re-encode the files, re-upload the files, and purge our CDN. So far we've done about twelve hundred videos.

My files are too large to upload here. I can provide a temporary link to a video file that demonstrates the issue, or is there a way I can upload a 23 MB file to you?

Additionally the audio is not out of sync, either the lag is on the scale of milliseconds for all our files or the behavior isn't as it is being described here. Our files range in time between ten minutes and one hour.

Feel free to e-mail me temporary links, dalecurtis@chromium.org

@farmaan: Thanks, your sample seems to suffer from similar issues to the one in c#0 after SSR gain control data is parsed. I'm still trying to determine if that is because the file is damaged or if it's another ffmpeg bug.

@chris.macdonald: Regarding a/v sync, yes, it's looking like the original sample that started this may be corrupt or there's some issue beyond just SSR. I'll take a look and see what the actual a/v sync is on your files.

@farmaan: How did you create that file? It has a junk 2-byte sample at the beginning (0x1208) claiming to be 0.5ms in length.

Hi Dale,

I'm Farmaan's colleague and we were able to discover the root cause of the issue. Turns out the encoder was giving us configuration information in the first instance of the buffer which we were incorrectly muxing into the m4a file (thereby causing the 2 byte junk sample). The error seen when using ffprobe on such a file is "Input buffer exhausted before END element found"

In our fix, we've just chose to ignore the configuration information (which happens just once), thereby not muxing it into the output m4a stream.

This encoding occurred on android using the MediaCodec and MediaMuxer APIs and we never knew about the issue because it played fine on android/chrome (<64).

Do let us know if you need anything from our side.

Hi Dale,

My team is also running into this in a fairly substantial amount of content and I'm a bit concerned that the dragnet may have ended up a bit wide for the deprecation of AAC-SSR. 

We don't use AAC-SSR, just AAC-LC. However, it seems that a subset of our content has fairly minor and seemingly benign encoding errors. These errors show up in ffmpeg with the above commands, but haven't been noticed to affect playback in any notable way and work across all platforms. 

I've reached out to you via e-mail directly as you requested with some example files. Let me know what you think, as this is becoming a fairly major customer facing issue for us and the cost of re-encoding will be non-trivial. 

Thanks!
Derek

Thanks, folks, if you have decoding errors that are not SRR related, please ping  issue 794782 . Lets keep this one for SSR content alone.


To be clear, though the outcome is the same, there was no deprecation of SSR support (which has never existed), we're just now signaling that a parse error has occurred for anything reported invalid by the audio decoder (which we've always done for video). Previously these were silently reported to the console and lead to a/v sync issues if many instances occurred.

So good news and bad news. On the good news, I've submitted a patch upstream that parses and ignores SSR gain control data. Such files will now decode, but sound weird: http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225592.html 

On the bad news, none of the samples I've received failing with the SSR error actually have valid gain control data, they're just corrupt in a way that makes it look like they have gain control data. The original sample and ones I've received privately have been encoded with libfaac, which has never had support for writing gain control data:

https://sourceforge.net/p/faac/faac/ci/648c55c5a0a049e557ac6d40ffe56ef49d4682a7/tree/libfaac/bitstream.c#l716

The encoding string can be found in hexdumps of the files:
00000000 ff f1 4c 80 07 5f fc de 36 00 00 6c 69 62 66 61 |..L.._..6..libfa|
00000010 61 63 20 31 2e 32 36 2e 31 20 28 4e 6f 76 20 31 |ac 1.26.1 (Nov 1|
00000020 34 20 32 30 31 30 29 20 55 4e 53 54 41 42 4c 45 |4 2010) UNSTABLE|

Which means these files are just plain corrupt, rather than not playing due to a missing feature. The patch I'm submitting will have the effect of making this clearer in ffmpeg if upstream accepts it.