webm recordings don't have duration metadata
Reported by
phileste...@gmail.com,
Aug 21 2017
|
||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36 Steps to reproduce the problem: 1. Go on readupnow.com 2. Click "Try a demo" 3. Read aloud until the end of the book and then click stop 4. Click "Hear it" 5. Note that the recorded audio file does not have duration metadata What is the expected behavior? It's expected that the recorded audio file would have duration metadata What went wrong? The recorded audio file did not have duration metadata Did this work before? No Does this work in other browsers? Yes Chrome version: 60.0.3112.101 Channel: stable OS Version: OS X 10.11.3 Flash Version: It works fine on Firefox because that's recorded in an .ogg format
,
Aug 22 2017
Tested the issue on Mac os 10.12.6 using chrome M60 #60.0.3112.101 and M62 #62.0.3192.0 and followed below steps : 1. Opened readupnow.com in chrome and clicked on try a demo. 2. Read the book till the end and clicked to hear it. 3. And could see the time chnaging while hearing and tried to save the recorded file and it has shown a message that file will be mailed by the night. Attached screenshot for reference. @philesterman-- Could you please check screenshot and confirm us if we have missed any steps in reproduicng the issue and help us to triage the issue better. Thanks!
,
Aug 22 2017
Hi there— this is correct. The issue is that the recording is generated ***without a duration***. The recording plays properly....there's just no duration metadata (so skipping ahead doesn't work, for example). This is a correct reproduction of the issue. Thanks!
,
Aug 22 2017
Thank you for providing more feedback. Adding requester "hdodda@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 23 2017
Able to reproduce the issue on Windows 10, Ubuntu 14.04 and Mac 10.12.6 using chrome stable version #60.0.3112.101 and latest canary #62.0.3194.0. Bisect Information: ===================== Good build: 57.0.2950.0 Revision(438011) Bad Build : 57.0.2951.0 Revision(438385) Change Log URL: https://chromium.googlesource.com/chromium/src/+log/d399335bfa3e978a8bc5e74a2fcf31213099a45a..bc2d34472dd3e60dabae58359a7cae0c49ae6555 From the above change log suspecting below change Review URL: https://codereview.chromium.org/2563853003 zqzhang@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner. Thanks...!!
,
Aug 23 2017
It is not related to my change. Should be some issue with recording. CC'ing dalecurtis@ for triaging.
,
Aug 23 2017
,
Aug 26 2017
Any updates on this? Thanks for all the help.
,
Aug 29 2017
,
Sep 27 2017
,
Oct 12 2017
Ping for triaging.
,
Oct 12 2017
This has been discussed in the W3C repo [1] and is mentioned in the README.md: https://chromium.googlesource.com/chromium/src/+/HEAD/third_party/WebKit/Source/modules/mediarecorder/README.md#the-produced-recording-doesn_t-have-duration-or-is-not-seekable philesterman@ please take a look a those. [1] https://github.com/w3c/mediacapture-record/issues/119
,
Oct 12 2017
Thanks for the update. Reposting for onlookers: using a library to reconstruct the cues seems the most usable. E.g.: ffmpeg -i input.webm -c copy output.webm |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by rtoy@chromium.org
, Aug 21 2017