I detected this while testing a local CL enabling FLAC-in-ISOBMFF for MSE.

To make sure this wasn't due to something in my FLAC CL, I repro'ed the same issue using MSE with AAC-in-MP4 (fragmented) on Chrome (Linux) 59.0.3071.115 (Official Build) (64-bit).

Repro steps:
1) extract attached large_timestamp_gap_spam.tar.gz
2) python -m SimpleHttpServer 8000
3) browse to http://localhost:8000/test.html
4) Observe spam in chrome://media-internals at the config change point, but otherwise the audio plays twice just fine.

See comments in the test.html regarding details.
Basics of the test structure:
Sequence appendmode append of:
InitSegment+MediaSegment(s) of AAC-LC 22050Hz media, then
InitSegment+MediaSegment(s) of AAC-LC 44100Hz media.
Play.

Example spam:
00:00:02 800	error	Large timestamp gap detected; may cause AV sync to drift. time:2949453us expected:3018594us delta:-69141us
00:00:02 845	error	Large timestamp gap detected; may cause AV sync to drift. time:2971812us expected:3065034us delta:-93222us
00:00:02 860	error	Large timestamp gap detected; may cause AV sync to drift. time:2995961us expected:3111473us delta:-115512us
...
00:00:05 425	error	Large timestamp gap detected; may cause AV sync to drift. time:5573059us expected:8266303us delta:-2693244us
00:00:05 446	error	Large timestamp gap detected; may cause AV sync to drift. time:5596075us expected:8312743us delta:-2716668us
00:00:05 485	error	Large timestamp gap detected; may cause AV sync to drift. time:5619295us expected:8359183us delta:-2739888us

It seems to me that the DecoderStreamTraits<DemuxerStream::AUDIO>'s audio_timestamp_validator_ might be missing a necessary reset somewhere around the kConfigChanged processing (local additional logging confirmed that no OnStreamReset() was done after the very first at beginning of playback).
 

Deleted: large_timestamp_gap_spam.tar.gz 101 KB

large_timestamp_gap_spam.tar.gz 101 KB Download