Audio ondurationchanged event spammed multiple times with different durations
Reported by
joeypm...@gmail.com,
Aug 22
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36 Steps to reproduce the problem: 1. Just open the included HTML file. 2. Check the console.log output. What is the expected behavior? There is 1 log entry with the duration, for example: ondurationchanged to 192.444082 What went wrong? Multiple ondurationchanged events are called. Every time it's called, the duration appears to be a few milliseconds longer for some reason. At least Edge just show one ondurationchanged log, which appears to be 192.444082. I didn't have the possibility to test more browsers other than Edge, FireFox, Chrome, Chromium and Opera. I think it might be caused by the MP3 being misformed somehow, as there is a second MP3 URL included in the testfile which can be used as a control case (the crowd-cheering.mp3 one). This second MP3 doesn't trigger this "bug". It also doesn't make a difference wether the file is loaded locally or from a URL. Did this work before? N/A Does this work in other browsers? No Opera does exactly the same as chromium Firefox does the same as Chromium, except it doesn't instantly "spam" ~8 different times, but it only happens once per playback Edge does what I expect it to do and only log to the console once Chrome version: 68.0.3440.106 Channel: stable OS Version: 10.0 Flash Version:
,
Aug 23
,
Aug 23
,
Aug 23
This is a combination of VBR plus invalid Xing metadata generally. I'll double check to make sure some ffmpeg bug hasn't come in, but not much we can do here unless we attempt to decode the whole file ahead of time. See previous discussion on issue 419974 .
,
Aug 23
Actually this one might have just been a bug in M68, it seems to work fine in M69 - so possibly fixed by our ffmpeg roll. Can you check chrome canary, dev, or beta and see if this is an issue for you? I'm not able to reproduce a problem there.
,
Aug 24
Ah, this is related to Chrome having fast seeks enabled for mp3 content. I'm not sure if Edge is using the Xing seek TOC which is present in your test clip. The crowd cheering one is CBR w/o a TOC which explains the differences in behavior. When doing fast seeks with the inaccurate xing toc, we don't always know the true timestamp, so we have to guess a little bit. Our pipeline code then sees timestamps beyond the expected duration and notifies of an increase in duration. This is a compromise we took since seeks without the xing toc over low bandwidth connections can be abysmal -- we essentially need to read the entire file. I'll try to find some time to test edge on a simulated 3G connection to see how it does here -- if it still does fine we might try to find some way to improve our accuracy here.
,
Sep 7
Yeah, edge is downloading the whole file upfront which is why it has an accurate duration -- that's not a huge problem with this file, but for ones that are 10s to 100s of megabytes in size it ruins the startup time. Chrome is only downloading enough to start playback and guess at the duration, so this is working as intended.
,
Sep 8
I see, still thanks for the description above though. Managed to fix it by reencoding the file with FFmpeg! |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by hongchan@chromium.org
, Aug 22