MSE: Opus CodecDelay is not handled correctly if two opus files are appended back to back |
||||
Issue descriptionIf we take the same opus file and append it twice, offsetting the first to start after the second, CodecDelay is only discarded for the first file. In the demo below, you hear a beep at 12 seconds, showing the codec delay for the second append is not processed. DEMO: https://storage.googleapis.com/chcunningham-chrome-shared/opusb2b/audioMse.html
,
Dec 9 2016
Yes - its just trimming.webm appended twice with the second append offset by the duration of the first append.
,
Dec 9 2016
If you cat those two files together would they play in ffplay / vlc?
,
Dec 9 2016
Seems not to. The first 12 seconds plays (with a beep at the start), but thats it. I think this is expected though. FFmpeg's demuxer probably parses the segment with length described in the initial EMBL header and never sees the second concatenated file. Aside: I am surprised to hear a beep at the start. This is freshly synced/built ffplay. Perhaps they don't setup the decoder config in the same way we do.
,
Dec 9 2016
Probably anytime MSE sees an OPUS config with preroll it needs to issue a config change to make this work?
,
Dec 9 2016
Yeah, I think that would work fine. I wonder the best way to avoid opus hacks in SourceBufferStream. We could do something like assign each opus config a unique id when its parsed - that way config.Matches() would always return false for configs produced from different opus files.
,
Aug 23
,
Aug 27
,
Aug 27
|
||||
►
Sign in to add a comment |
||||
Comment 1 by dalecur...@chromium.org
, Dec 8 2016