We have created a video using your recommended settings for handbrake,
we get a green video okay in Admin. the video plays fine in Chrome and you can skip up and down the timeline without any problems
If you use edge to play the same video it runs but if you try skipping up and down the timeline to much it will error with HTML5: Video not properly encoded.
thank you for the bug report.
Are you getting the same error if you open the video file directly? That will let us know if it’s a FV Player bug or if it’s directly in Edge.
Are you getting the same error if you check the video file on FV Player settings page? That one is encoded by Vimeo, so lets see if it’s caused by encoding.
Thanks for your sugestion, i have played the same file using html <video> tag it responds better but finally i got it to go wrong with an error “unable to decode video.”
I ran the test in player settings attached is the output i am not sure if this is what you wanted when you said “Check the video file on fv player settings”
so it seems to be a bug in the MS Edge browser.
I was suggesting you to try to do the same frequent skipping on timeline on the Settings -> FV Player -> Skin video. That will allow us to see if the issue is related to video encoding.
But it could be related to some issue with BunnyCDN too – can you show any error in the logs on their end? Perhaps they block too frequent requests. Each seek operation in a MP4 file is a HTTP range request. You can check that by BunnyCDN support.
Hi Just a quick updating I am still running tests, I am beginning to think it might be to do with the video duration, when i encode a large file in handbrake using exactly the same settings, upload it then play test it in the player it comes up with a warning saying theMoov Atom not found at front of file but it has no problem with shorter videos Might this be a possibility or am i looking in the wrong direction
I set the Video Checker to download bigger portion of the file for analysis, hopefully the moov atom error won’t show up anymore.
It’s not likely related to the issue. It’s probably really just a bug in MS Edge. Perhaps it would be better to figure out HLS encoding for your videos. Here’s our guide for it on AWS: https://foliovision.com/player/securing-your-video/hls-stream It offer video encryption as well, so even if the video is downloaded from your website it won’t play.
you can host the HLS video on any CDN, however I don’t currently have a recommendation for a HLS encoder that runs on your computer like Handbrake does.
KeyCDN do have some recommendations, from ffmpeg (command line tool) to some paid application for Windows: https://www.keycdn.com/support/how-to-convert-mp4-to-hls/
I have been running some tests to see if we can get mpeg dash streams to work, I have got as far as managing to create all of the relevent files on bunnyCDN but once i have done this i dont seem to be able to play using the path to my master.mpd file, can you throw any light on why this might be
you can try to see what our video checker says about it: https://foliovision.com/player/basic-setup/how-to-use-video-checker
However MPEG-DASH won’t play on iOS. It would be better to have these HLS streams as with Hls.js library (and Flash HLS) which is part of FV Player these can play almost everywhere and are better protected than MP4.
I just wanted to get back to you as the MOOV Atom problem still seems to exist on longer duration files i encoded a 5 min X264/MP4 portion of a file and the player sees the moov atom fine i then encoded a 1 hour section of the same file using exactly the same settings but on this file flplayer sayes Moov Atom not found at the beginning of file, i have run the same encoding test using handbrake and AVS video Converter with the same results in both chrome and edge browser. small files it sees the moov atom okay large files it doesn’t, ultimatly i need to encode files of upto 2 hrs 30 mins so this is a problem, we are looking at hls but are not at a point were we can use it yet so i would like to get thus problem with Moov Atom sorted.
I checked that file and in order to properly analyze it I had to download first 8 MB of it. Then I could see the data about the top level atoms:
ftyp (24 bytes)
moov (4881545 bytes)
mdat (2811732700 bytes)
So the moov is placed after 4th MB of the file and since our Video Checker only check first 4 MB of the video file it was not able to find it. We could adjust it to check first 8 MB to work on these long video files, but then it might be slowed down too much on other video files which are not always hosted on some CDN.
So I need to also check if anything changed in HandBrake. Are you sure you are encoding with “Web optimized” checkbox checked?