I'd guess that sample rate is being reported incorrectly. xhwang@, maybe configs are being detected incorrectly?

give to xhwang@, remove from untriaged bucket.

This is using Clear Key key system which only decrypts the buffers, then we still use the clear audio decoders to decode the decrypted buffers. So it seems to me this is more like a demuxer issue. Assign to wolenetz@ for investigation.

Confirmed repro on linux 59.0.3071.86 (Official Build) (64-bit)

src= version of the audio-only webm indicates 11 second duration in controls, but plays weirdly accelerated (not tone-shifted though) about 5-6 seconds, then ends abruptly.
MSE version plays the whole 11 seconds cleanly.

I'll see what ffplay says about the webm-opus file.

ToT ffplay shows:
[NULL @ 0x7fc118007d40] Error parsing Opus packet header.
    Last message repeated 46 times
[opus @ 0x7fc11804ddc0] LBRR frames 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.
[opus @ 0x7fc11804ddc0] Error decoding a SILK frame.
[opus @ 0x7fc11804ddc0] Error decoding an Opus frame.

Seems to be an ffmpeg related issue (not MSE parser or the decode of the parsed results when the parser is MSE).

Dale - this is something which needs further investigation in FFmpeg / FFmpegDemuxer. Who should this go to?

Hmm. ClearKey decryption is probably why straight-up ffplay doesn't like this. Still, likely the problem is in ffmpeg/ffmpegdemuxer.

Does this happen on M61? Don't see that log message in the code...

I'll try in M61 Debug and see what logs we might get.

Repro of "direct file, audio" in ToT chrome's media-internals shows lots of these:
00:00:06 713	error	Large timestamp gap detected; may cause AV sync to drift. time:141000us expected:81000us delta:60000us
00:00:06 717	error	Large timestamp gap detected; may cause AV sync to drift. time:201000us expected:121000us delta:80000us
00:00:06 719	error	Large timestamp gap detected; may cause AV sync to drift. time:261000us expected:141000us delta:120000us

MSE audio version shows no similar errors in media-internals.

Chrome's MSE parser determines the following audio config:
[1:1:0626/121712.256490:VERBOSE1:source_buffer_state.cc(574)] Audio track_id=2 config: codec: opus bytes_per_channel: 4 channel_layout: 3 channels: 2 samples_per_second: 48000 sample_format: 4 bytes_per_frame: 8 seek_preroll: 80ms codec_delay: 312 has extra data? true encrypted? true

But FFmpegDemuxer (direct file playback) determines a different audio config:
00:00:06 693	info	FFmpegDemuxer: created audio stream, config codec: opus bytes_per_channel: 2 channel_layout: 3 channels: 2 samples_per_second: 48000 sample_format: 2 bytes_per_frame: 4 seek_preroll: 80ms codec_delay: 312 has extra data? true encrypted? true

From #13-14, it seems like ffmpeg is incorrectly determining the sample size (16 bits) versus MSE webm_stream_parser's determination of 32 bits for the stream.

Adding some debug log statements, it looks like FFmpegDemuxer creates the DemuxerStream with an audio config with:
AVSampleFormat 1 (   AV_SAMPLE_FMT_S16,         ///< signed 16 bits )
but later during actual decode attempts, a recreation of the audio decoder config is done using
AVSampleFormat 3 (   AV_SAMPLE_FMT_FLT,         ///< float )

It looks like FFmpeg is changing its determination of sample format in the repro (bad playback) case:
OnFindStreamInfoDone --> AV_SAMPLE_FMT_S16

Later, after libopus_decode->ff_get_buffer->media::GetAudioBufferImpl()->media::FFmpegAudioDecoder::GetAudioBuffer()-->media::AVSampleFormatToSampleFormat(), the sample format is AV_SAMPLE_FMT_FLT.

Dale - this looks increasingly like an ffmpeg + opus issue. Can you pick this up from here/reassign appropriately please?

Dale pointed out we force the sample size to be a float in our pipeline (src= and MSE opus decodes).

david.komer@, please provide an unencrypted version of the webm opus audio file so we can see if the same issue reproduces in that case (this could be a shaka packaging issue).

During playback the ffmpeg log is full of:

[NULL @ 0x1e01fd776500] Error parsing Opus packet header.
[NULL @ 0x1e01fd776500] Error parsing Opus packet header.
[NULL @ 0x1e01fd776500] Error parsing Opus packet header.
[NULL @ 0x1e01fd776500] Error parsing Opus packet header.
[NULL @ 0x1e01fd776500] Error parsing Opus packet header.
[NULL @ 0x1e01fd776500] Error parsing Opus packet header.
[NULL @ 0x1e01fd776500] Error parsing Opus packet header.
[NULL @ 0x1e01fd776500] Error parsing Opus packet header.
[NULL @ 0x1e01fd776500] Error parsing Opus packet header.
[NULL @ 0x1e01fd776500] Error parsing Opus packet header.

I'd guess too much of the packet is encrypted and ffmpeg drops the packet when the header can't be parsed. It's equally possible ffmpeg is expecting too much in the clear. xhwang@ do you know the answer?

+kqyang who's familiar with shaka packager which is used to generate the files.

We are using the same file in SRC and MSE playback and MSE playback is fine. With that it seems unlikely we are encrypting too much that some headers can't be parsed. So it does look like a ffmpeg demuxing issue to me.

Here's an unencrypted version of the webm opus audio file

Deleted: audio.webm 178 KB

	audio.webm 178 KB View Download

Not sure how to quote in this system, but in response to:

"please provide an unencrypted version of the webm opus audio file so we can see if the same issue reproduces in that case (this could be a shaka packaging issue)."

Just to point out, that the bug happens whether the file is encrypted with Shaka Packager or webm_crypt (though Joey mentioned to me that webm_crypt is known to be deprecated to some degree)

@#21-22 thanks for providing the unencrypted version. direct play of that succeeds, indicating something in the encryption and/or parsing/demuxing/decoding of the encrypted version is broken.

@#19-20, I added some extra local logs, and the ffmpeg opus parse error for this repro is always from https://cs.chromium.org/chromium/src/third_party/ffmpeg/libavcodec/opus.c?q=opus.c+package:%5Echromium$&dr&l=144, and in those cases, it's always because frame_bytes is odd.

I suspect this is due to ffmpeg going too far in attempting to scan the input, in part to calculate coded frame durations, in encrypted webm opus streams; our MSE webm parser instead has to rely on the webm container's metadata for block duration or inter-block timestamp delta for simpleblocks (and estimate it at end of clusters if it's not a BlockGroup) when the track is audio and is encrypted. See handling and comments around |encoded_duration| in scope beginning at https://cs.chromium.org/chromium/src/media/formats/webm/webm_cluster_parser.cc?q=encoded_duration&dr=C&l=469.

Over to chcunningham@ who implemented that workaround for Chrome MSE encrypted webm --> this seems like there should be an ffmpeg trac bug filed to get ffmpeg encrypted opus-in-webm demux fixed (or perhaps we'll need to a downstream-only patch like what you did to our MSE parser).

tl;dr: I think ffmpeg is assuming too much is in the clear when preparing to demux encrypted webm opus.

+1 on wolenetz@'s analysis. Unlike video frames, the audio frames are fully encrypted (i.e. Audio does not use subsample encryption). The parser can not parse the packets before it is decrypted. It has to rely on the metadata in the container for encrypted frames.

re: "seems like there should be an ffmpeg trac bug filed" - has that been filed somewhere?