Jumpy video when exported
Pass1 opened this issue · comments
Using the Chrome App, the video is jumpy. An example can be seen here:
https://www.youtube.com/watch?v=sbt2P54ZjRQ&feature=youtu.be
The video feed comes from the Fatshark V2 on board DVR. The format was not supported, so it was converted to H264, H264 forced 30FPS and MP4 (using handbrake).
MP4 did not work, and both H264 formats jumped like in the Youtube video.
When viewed in the chrome app, everything looks fine though.
OS: Mac OS 10.10.4
Chrome: 44.0.2403.155 (64-bit)
It seems like this could happen if the video wasn't seekable for some reason, the Blackbox log viewer basically sets the current time to a precise value before every frame. Maybe try the option in Handbrake for Web Optimized? I think this includes more seeking information.
If that doesn't work, can you upload the H264 flight video somewhere like Dropbox so I can try it out?
Hi there!
I tried converting from handbrake with the tick mark on "Web optimised", but the problem is still there. I have linked below the original, and the web optimised.
Web optimised:
https://www.dropbox.com/s/ww6afo5n2ufd9ry/PICT0013_web.mp4?dl=0
Original:
https://www.dropbox.com/s/9wxcolg9mq9qhot/PICT0013.AVI?dl=0
Thanks for your time!
I've now confirmed this problem with your video. Oddly I now have that same issue using my H.264 videos recorded with a Mobius Actioncam. I'm not sure if Chrome updated or if I broke something, I'm investigating now.
I think this is a general bug with seeking of video in Chrome, because I also observe it when dragging the graphs (which causes video seeks to occur instead of regular forward playing, which seems to work fine). It might be due to this Chrome bug:
What should we do now?
On 31/ago/2015, at 15:17, Nicholas Sherlock notifications@github.com wrote:
I think this is a general bug with seeking of video in Chrome, because I also observe it when dragging the graphs (which causes video seeks to occur instead of regular forward playing, which seems to work fine). It might be due to this Chrome bug:
http://code.google.com/p/chromium/issues/detail?id=66631
—
Reply to this email directly or view it on GitHub.
So the reported Chrome bug's investigation says that it is specific to certain formats of input video which are difficult to seek in (like H264). I'm not entirely convinced that is true, so I will replicate some of their tests.
In any case it's possible that in Handbrake you can configure it to convert your flight video to H.264 format using "all I-frames". If Chrome's bug analysis is correct, then Chrome should be able to seek through that video with no jumping issues. I think you can do that by setting keyint to 0 or 1:
https://trac.handbrake.fr/wiki/x264Options
https://sites.google.com/site/linuxencoding/x264-ffmpeg-mapping
Ah yep, that fixes the problem. In Handbrake when you're converting your flight video, make sure the video codec is H.264, and add "keyint=1" to the "additional options" box:
Chrome should be able to seek properly in the re-encoded flight video since the video frames will all be keyframes, so there are no more jumps when Blackbox exports the video.
I've now added a note to the UI that directs people to a re-encoding guide I've added to the readme:
https://github.com/cleanflight/blackbox-log-viewer/blob/master/Readme.md
Hopefully Chrome can get this bug fixed.
Actually the problem is not the video itself. What you made with "keyint=1" parameter is a workaround. Let me explain what keyint=1 is causing. When it is 1, h264 encoder records every frame as a seperate compressed image. So there will be no "inter-frame" compression, such a compression is called "intra-frame" compression.
When you give an intra-only compressed h264 to Chrome, no problems. It can deceode each frame successfully, and it is the requested frame, perfectly... But such a compression is very close to saving each frame as a separate JPEG file. We all know that, this is not the most efficient way of video compression. If we do so, we do not make any use of PB frames, and bitrate will go higher, or video quality will get lower.
I posted example videos to this bug: https://code.google.com/p/chromium/issues/detail?id=66631
You can see that, I posted different keyint settings. And keyint=1, which is called intra, works perfectly. But I can not use intra in my video player. I will need to use 50x bandwidth for the same video quality!
I inspected this bug a lot. With a standart h.264 video, say it has keyint=250 frames, evey key-frame will make Chrome not to seek for another 2 frames. So you can not seek to frame 248 and frame 249. Most of the time keyint setting is variable. It is not best for an encoder to have fixed keyframe intervals. Actually the best way to encode a video is, placing the key-frames (called I-frames) to video-cut frames. So scene to scene changes. And there is no fixed interval for this. So please don't think that Chrome has fixed this.
This bug is open for many many years, and no one takes care. Chrome seems to behave as if there is no such a bug in h.264 seeking. I suspect that, they do not want to support h.264 correctly. It is also very slow to seek video in Chrome compared to other browsers, such as IE, Edge, Safari... Maybe they only want to have vp9 codec in web world, who knows?
Hi Guys,
Despite trying all the good advice here I still get jumpy video when exporting dvr footage from blackbox... see - https://www.youtube.com/watch?v=0O2ZT678X7g
DVR is from Skyzone V02 goggles and does not have any problems when viewing in blackbox.
Anyone got any ideas??
@stu22uk what version of blackbox log viewer are you using? The published in the chrome store or the manually installed from master?
It's the current release "app" through the chrome Web browser.
In the main page: https://github.com/cleanflight/blackbox-log-viewer there's a paragraph: Flight video won't load, or jumpy flight video upon export
Have you tested this solution?
Yes, that page/link is referenced earlier in the thread. I followed that advice to the letter but despite this I still get the effect you see in my video.
I wondered if there are any other settings people have tried when using handbrake to encode their DVR footage that may help...