Issue metadata
Sign in to add a comment
|
drawImage fails silently when drawing non 16:9 video
Reported by
germain....@gmail.com,
Mar 30 2017
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Steps to reproduce the problem: 1. Load a non 9:16 video 2. Try to draw that video on a canvas using ctx.drawImage 3. repeat the operation using requestAnimationFrame What is the expected behavior? The expected behaviour is to see the video play back on the canvas alongside the normal video What went wrong? Non 16:9 videos failed to be drown on the canvas Did this work before? Yes Chrome 56 Does this work in other browsers? N/A Chrome version: 57.0.2987.133 Channel: stable OS Version: OS X 10.12.3 Flash Version: I thought at first that this could be due to CORS issues and cache in Chrome so I tried to run this demo in a browserstack VM that is free of all "cache" and the problem was still happening. I saw a related issue in the bug tracker but not sure if that is the same problem. https://bugs.chromium.org/p/chromium/issues/detail?id=705975&q=drawImage&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified Let me know if you need any more information, Thanks
,
Mar 30 2017
So I dug a bit more into that issue, the video that is not working is 405px wide and 720px tall. Interestingly, if I transcode that video using ffmpeg and make it 406px wide it will work fine... You will find below the ffmpeg command I run: ffmpeg -i input.mp4 -c:v libx264 -c:a aac -filter_complex "scale=406:720" -s 406x720 output-406.mp4 From my testing, it looks like serving that file from the same origin or from a different origin does not matter Now, if I run the same ffmpeg command to make the video 404px wide, it will not work. I'm a bit unsure of the chrome internals so I can't really debug further. You will find attached the transcoded video that works Hope that helps, thanks
,
Mar 30 2017
Re-triaging as a video bug, since the sounds like an issue with the media player. The entry point that blink uses for grabbing a frame is WebMediaPlayerImpl::paint.
,
Mar 30 2017
+mac folk since it seems to be working fine on Linux.
,
Mar 30 2017
Probably a dup of issue 701060 .
,
Mar 30 2017
Upon re-reading, I'm certain enough of that to close this one. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by nyerramilli@chromium.org
, Mar 30 2017