HD Video Statistics


#1

I am experimenting with video settings and wondered about Dropped Frames vs. Decoded Frames stats that are reported by the system.

Originally I was trying to reduce video lag and occasional freezing but that was corrected by reducing the GEOMUX: GOP Length to 1 per Brian G’s suggestion in a prior post. What a difference that makes BTW.

I then stumbled across the SETTINGS:VIDEO:Show Video Player statistics and wondered at the results I saw in particular the Dropped Frames stats.

The video itself as seen in my screen capture is really quite good but, what should I make of those discarded packets?

And, does anyone have any other recommendationsBench Testing HD Video for tuning?


#2

Quick Summary: If you are seeing significant Dropped Frame rates in your cockpit video statistics try disabling the use of Hardware acceleration in Chrome advanced settings.

Background:
The weekend is here and I’ve had time to dig in further–
It seems the statistics reported in the cockpit display relate to the on-screen (Chrome browser) display of the ROV’s real-time images. Meaning-- number of packets received by Chrome and number dropped by Chrome.

I’m deducing this (hopefully correctly) by noticing that the statistics on dropped packets are markedly improved when I navigate away from the cockpit (though it is still active in the background but not refreshing the screen at all-- then return to it. Dropped Frame rate does not increment.

I checked my Rev of Chrome and I’m up to date.
I checked my system and have all current (Mac) OS and Drivers (including Graphics accelerator card).

I note that I have a responsibly powerful machine-- 2.6GHz Intel Core 5 with 16 Gigs memory and and Intel Iris 1536 Graphics accelerator card, 500Gig Solid State Drive.

As part of testing I changed the frame rates and the resolution and found no improvements in the dropped frame rate-- always hovering around 30-50%

I next investigated ways to try and force the system to use the Graphics Accelerator Card. There is a Chrome Setting: Advanced Settings: System: Use Hardware Acceleration when available-- but this was already selected.

Looking at the CPU monitor I found a process called: VTDecoderXPCService which was consuming most of my CPU cycles in in conjunction with Chrome and Chrome Helper.

A google search revealed that the VTDecoderXPCService is a Sandboxing service in OSX. Though there aren’t many (any) high level descriptions about it I did find this helpful article:

https://medium.com/@cwgem/a-random-encounter-with-videotoolbox-a25a5bc6b24f#.xx3gsrthf.

I also found a reference in a help thread re: Chrome Dropped Frames that suggested disabling the “Use hardware acceleration when available” feature-- seems counter intuitive but worth trying. (Requires Chrome reboot)

WOW-- what a difference that made. Dropped frames dropped to around 1-5%.
I also noticed VTDecoderXPCService left the system monitor or had such a low CPU % that it left the screen.

I can only assume the VTDecoderXPCService was invoked by Chrome as part of Hardware Acceleration but I am not certain of that.

My CPU cycles significantly increased as a result of the hardware acceleration change-- but I think it’ll be OK. Not sure how it will impact battery life etc.


#3

Hi @ROVBrooke,

First, kudos for digging so deep into what is going on with the video.

Dropped frames are frames that the decoder process in chrome throws out for whatever reason. It can be pretty finicky. The recording process is not affected by the dropped frames that you see on the video statistics, and should be reliably recorded without drops for the most part.

To explain more about why there are differences when turning hardware accel on and off in Chrome, the current version of the video stream that you are using is missing a set of special parameters in the H264 bitstream which tell the decoder that it should only buffer one frame, that there will be no B-frames, and that no frames will be coming out of order. The software decoder in Chrome doesn’t seem to care about those parameters being missing, but the hardware decoder does, as it relies on them for making the best decisions from an optimization viewpoint. In a newer version of the camera server, we have been able to parse the H264 bitstream, modify and rebuild those parameter sets with values that leads to extremely low latency, and as a result, the decoder ends up not waiting for a buffer of 15 frames and choking as we push in new data (resulting in dropped frames in Chrome).

These improvements will be rolled out over time as we have the opportunity. For now, using the software decoder on a decent CPU will give you the best results. On mobile, you are forced to use the hardware decoder, so no guarantees there until the new software is ready.

Additionally, if recording quality is your goal, I would recommend against using a GOP length of 1. While 1 will allow the decoder to recover more quickly, the image quality will be severely degraded. As the video is coming across at 30fps, using a GOP length of 30 means that it will take up to one second for the decoder to recover from an error, so you can tune the GOP to your needs between 1 and 30, with video quality being improved as you increase it.


#4

Hi Charles, Thanks for this reply. I will put all the recommendations to use and see what combination of settings well with my config.

In the meantime I’ll look forward to the new builds that incorporate your enhancements.

I did post a couple of other questions re: post dive video replay as well. Wondering if you have opinions/best practices. This past weekend’s dive wouldn’t play back even after 48 hrs of waiting. Cache had plenty of files stored in it but I could never get them to replay. Roughly 45 min worth at 1080/30fps. Not sure if there was something I could do to help the re-assembly process along.

I also wonder if there is a cache extract utility that can re-assemble them or is that process proprietary?

Many thanks for the insight and great work you all do.

Best
Br-


#5

@ROVBrooke

It turns out that there were a couple bugs when trying to retrieve long recording sessions in the data page which have been fixed in a new release candidate that we will hopefully be pushing this week. This should resolve your issue with downloading the recorded video from the Data page. In the event that this doesn’t fix your particular issue, we should be able to recover it, as long as you don’t clear your browser’s cache in the meantime. The manual cache retrieval method is a bit of a nuisance and differs by OS, so let’s wait and see if the new update resolves the issue first. In addition to the retrieval fixes, the other improvements that I mentioned in my previous post will also be making their way in, so you may start seeing better latency and less dropped frames at the decoder.

We will post the new release on the forum, but I will also ping you here when we do so.

Cheers,
Charles