Video webm is glitching while I update the property "currentTime"
Reported by
fanthoma...@gmail.com,
Dec 26 2016
|
||||||||||||||||||||||||||||||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
Steps to reproduce the problem:
Copy / paste this bunch of code :
<body onload="start()">
<script type="text/javascript">
var seekable = true;
var player;
function start() {
player = document.createElement("video");
player.src = "449_256.webm";
player.onseeked = function(){ seekable = true; }
document.body.appendChild(player);
requestAnimationFrame(update)
}
function update(){
if(seekable){
seekable = false;
player.currentTime += 0.1;
}
requestAnimationFrame(update)
}
</script>
</body>
What is the expected behavior?
The video should look like... a video
What went wrong?
The video is so glitched that you cannot even imagine what you are actually watching
Did this work before? N/A
Chrome version: 55.0.2883.87 Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 24.0 r0
Please fix it !
Thank you for all your work !
,
Dec 27 2016
fanthomas.lecoz@ In order to triage this issue could you please help us with the sample http/jsfiddle page and required steps to reproduce the scenario. So that we can reproduce the scenario on our end. Thank you...
,
Dec 27 2016
I will do that, but don t you see the problem in the "preview-player" of my attached video file ? Just try to seek in your player and you will see what I mean ( i dont see the problem on mobile device) I ll comeback with a jsfiddle soon Le 27 déc. 2016 10:51, "kkal… via monorail" < monorail+v2.2099402154@chromium.org> a écrit :
,
Dec 27 2016
Hello again ! Here is a html page that shows the problem (sorry I don't know how to add an external ressource on jsfiddle ) http://www.kizoa.fr/tests/bug.html Thank you for your help !
,
Dec 27 2016
(I just would like to precise that this bug only happen in chrome on a computer (not on mobile) ; I now test with this current page, using the player provided by chrome to seek the attached file given in this post and it works as expected in firefox) I think - but I may be wrong - that this problem always exists in chrome but was imperceptible because of the size of the video. My video is very small (110 ko only) , and a very small imprecision during the video process has a big impact on the screen. Thank you again for your help
,
Dec 28 2016
"status : unconfirmed" ???
,
Jan 3 2017
,
Jan 5 2017
Issue 677499 has been merged into this issue.
,
Jan 9 2017
Hello Google-guys ! Happy new year ! I just would like to precise that I have this bug with every webm file I'm using (and I have around one thousands). My files are very small because I'm trying to convert a flash-app into a webgl-app and each webm contains what used to be a short SWF movie. Most of my files have a very small duration, less than 3 seconds, and because I can potentially have 10 webm at the same time in the page, I'm using 256x256 webm files ; that's why the size of the files are so small. I considered the fact to use png-spritesheet instead of webm-video ; everything worked perfectly but the size of webm files are 5-10x smaller than a 2048x2048 png spritesheet (even if I optimize it) and that's why I would prefer to use webm. Just to show you that the issue is not isolated, I send you some of my webm files. The problem is viewable with every of them : first, push the play button then grab the playhead-cursor and try to seek. Thank you for your work Best regards
,
Jan 10 2017
That sounds a lot like an encoding issue. Though, I'm no specialist. +dalecurtis@ who might be able to confirm.
,
Jan 10 2017
Hello ! Thank you for your message. I really doubt it comes from the encoding. Webm files are created using FFMPEG from a sequence of png-image, it's really really basic. If you think it can help to solve the issue, I can send you the exact FFMPEG command I'm using to create the files but I really doubt the problem come from here because I'm using a lot of video file in the app I'm working on, every of them are created using FFMPEG without any problem. I'm rebuild in html5/webgl an existing app built in Flash ; there is maybe 100 millions of vidéo files in our server and the only problem we have concern the small webm files like the ones I attached in this post Moreover, the webm file are seekable "correctly" in firefox... Try to open this current page in firefox, then try to seek one of my video and it will work as expected. I'm really sorry for you guys but I'm 99% sure that the problem come from Chrome since the issue is only visible in Chrome
,
Jan 10 2017
(and actually, it also work as expected on the android version of chrome ; the problem only concern chrome for desktop (with different version of windows) )
,
Jan 10 2017
These videos only have a single keyframe at the beginning, for whatever reason seeking is seeking to an exact point, which is incorrect. It should always return time zero and drop frames until the requested seek point. What command line are you using to encode this?
,
Jan 10 2017
Hello ! Thank you for your message. I will send you the command tomorrow because it's 22:20 in France and I'm not at the office but if it works in firefox - and it works better than expected, it's like I could seek frame by frame in real time - , don't you think the problem may come from chrome ? Did you try to play and seek my files in firefox ? - the glitsh-rendering is certainly a bug no ? It only happen on chrome on windows 7-8-10 (didn't try with XP / Apple ) -
,
Jan 11 2017
Hello ! Here is the FFMPEG command we are using to create the webm from a sequence of png file : ffmpeg.exe -pattern_type sequence -y -start_number 1 -i C:/Users/PIXVISIO/Desktop/videoPNG/img_%d.png -r 30 -c:v libvpx -pix_fmt yuva420p -metadata:s:v:0 alpha_mode='1' -vf scale='256x256' C:/Users/PIXVISIO/Desktop/WEBMS/movie.webm Thank you !
,
Jan 11 2017
I'm sorry, I speak a bit too much but I just would like to say that I disagree with what you said before "It should always return time zero and drop frames until the requested seek point" This is not a solution, and this is not at all a "seeking"... If I put my playhead at 50% , I do not expect that my video stay blocked at the first frame, I expect to see the frame located at the half of the video. I'm sorry - really - to insist but if firefox can do it, why Chrome couln't do it while Google is the creator of webm format ? I'm trully sorry to be so harsh with you ; you - google teams - are all my heros and I admire your work a lot, but because you are my hero I expected you to do a great work all the time - and then I expect you to fix the bug - Thank you again for all your work
,
Jan 19 2017
Thank you for providing more feedback. Adding requester "kkaluri@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 26 2017
Someone pointed me at this issue. The problem is the files are malformed. Every frame is marked as a key frame in the container even though there is really only one key frame in the beginning of the file. So Chrome thinks every frame is seekable. I would file a bug on FFmpeg list with your command line and a file.
,
Jan 26 2017
Hello ! Thank you for your message but I trully don't understand why you don't just admit that the problem come from Chrome.... Can you please TRY TO PLAY IT IN FIREFOX ?! Sorry to scream but I repeat the same thing again and again and again and it's like nobody never try to play the file outside of chrome just to see if it works as expected or not.... I really doubt that the problem come from my file because firefox is able to seek it frame-by-frame perfectly and also because my FFMPEG command is pretty simple. Either firefox produce miracle, either Chrome bug... If Webm was a format made by Mozilla, I could understand why firefox can do something impossible to do with Chrome but Webm was made by Google and then it's incredible to see that Chrome doesn't support it as well as firefox... (sorry for my approximative english, it's not my native language)
,
Jan 26 2017
I deleted comment #23 because there was some wrong info and I didn't want to confuse this issue.
,
Jan 26 2017
I tested in Firefox. Yes the file seeks but actually doesn't blend correctly with alpha, so it doesn't work perfectly. But that still doesn't change the fact that the file is malformed. I went and looked and we actually fixed this issue in FFmpeg in 2015. So my guess is you are using an older version of FFmpeg to make these files. I attached a file I made with one of your files with a newer version of FFmpeg. Here was my command line: ffmpeg -i d78b7ba1-8927-4169-8d0e-145b99428a0f -pix_fmt yuva420p -c:v libvpx -auto-alt-ref 0 calc_alpha.webm Now even if you create proper webm files with alpha, there is a bug in Chrome with seeking with Webm and alpha. So I am going to go ahead and mark this issue a duplicate of the older issue. I will also make two suggestions: 1. If your files do not need alpha encode them without alpha and you will not have any problems. 2. If you do need alpha and crbug.com/497889 gets fixed your files sill may not work, so I would suggest updating your FFmpeg.
,
Jan 27 2017
Hello ! Thank you for your messages and your time. Unfortunately, I'm a bit surprise because the file you attached in your message (made with a newer version of FFMPEG) has exactly the same problem of seek (but now the alpha channel doesn't work as expected anymore) I'm sorry but I'm still thinking that there is a problem in Chrome somewhere. Thank you again for your time (and all your work)
,
Jan 27 2017
Yes there is. Please see: https://bugs.chromium.org/p/chromium/issues/detail?id=497889 |
||||||||||||||||||||||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||||||||||||||||||||||
Comment 1 by fanthoma...@gmail.com
, Dec 26 2016