634d very slow navigating AVC

#1
I have an Avermedia Dark Crystal HD capture station that I am trialling. It produces MPEG-4 AVC + MPEG2 audio in a transport stream. If I configure it to record HD 1920 x 1080i 20Mbit/sec videoredo is very slow to move around the recording file. Hopping around in 1 second increments takes between 1 and 2 seconds, ie at best 'realtime'. 10 second hops are similarly very slow. MPEG-2 HD 20Mbit/sec editing is quite quick.

A quick stream fix to .mp4 does not improve the speed.

I know AVC is far more complex a compressor compared to MPEG-2 but I wasn't expecting that sort of performance drop.

I am doing this on a core2quad (2.4GHz) with 4Gb RAM under Win 7 64 bit. More RAM does not appear to make any signifcant difference. I can supply a few megabytes of the output of the Avermedia if need be.
 

Dan203

Senior Developer
Staff member
#2
There are a couple of things that can cause this. First off the file is stored on a local drive right? Not a network share or external USB drive? VRD is very much disk bound so a fast drive can make a big difference.

The other thing with H.264 is some encoders will use really, really, long GOPs. I've seen files with GOPs that are 10 seconds long. This can really slow down seeking.

If you don't know GOPs are "Group Of Pictures" consisting of one I or IDR frame and a bunch of B or P frames. B and P frames can only be decoded if you first decode all the frame the frames that come before them starting with the last I/IDR frame. So if the GOP is super long then it can cause a long delay if you try to seek to a frame near the end of the GOP. You can tell If this is the case by enabling the seek by I frame setting, and then looking at the time codes. To set this up go to Tools->Options->Navigation and set the "Shifted" option under the Left/Right Arrows section to "Move next I-frame". Then open your video, hold Shift and hit the right arrow key. If the I frames are more then a second or so apart then this would explain the slowness.

That being said now that you have that setup you'll probably find that I frame seeking is a lot faster. So I'd recommend you use the nav bar to land roughly where you want, use the Shift+Right/Left to get as close as you can, then use the fine tune slider or frame step to land on the exact frame. This should be a lot faster then the seek by X seconds functions.

Another option, if it's available, is to configure the encoder in your capture device to use shorter GOPs. If there is a way to set it to insert an I/IDR frame every second or so it will speed up seeking quite a bit. It will also improve editing performance.

Dan
 
Last edited:
#3
The file is on a local hard disk connected via SATA2, I frame spacing is 12 frames and the GOP structure appears to be IBBPBBPBBP etc.

The reason I step through at x seconds (10 is my preference) is the way I chop ads out of files. I find that automated ad removal takes longer and produces less reliable results than me simply skipping through the file and marking it up manually. This works quite well with MPEG-2 (it hops as fast as the keyboard repeat rate) but with the MPEG-4 AVC output of the avermedia (not tried transport streams from other sources) skipping around in 10 second hops gets 1 or 2 hops per second.
 

Dan203

Senior Developer
Staff member
#4
1-2 hops per second is about normal for H.264. Especially 1080i. H.264 takes a lot more CPU power to decode then MPEG-2, so it's always going to be slower then what you were use to. I thought you said originally that it was taking 10 seconds to make one 10 second jump. That's wouldn't be normal. But 1-2 10 second hops per second is about right. I only get maybe 2-3 10 second hops per second on a brand new i7-2700K with SSD and 8GB of RAM.

One thing that can help, if it's an option, is to encode the file as CBR. The more consistent the bitrate the easier it is for us to seek around in the file, so it may speed things up a bit.

Dan
 
#5
Fair enough. Would it be useful to have the option to skip multiple I frames? At the moment VR only has step to the next, but I wonder if being able to skip to the nth I frame would be a quicker way to seek over longer distances.
 

Dan203

Senior Developer
Staff member
#6
Actually I found another way. Go to Tools->Options->Navigation and set value for "Force I frame seeks" to 9. That will make it so your 10 second jumps will land on the nearest I frame, rather then exactly 10 seconds. In my test it increased the seeking speed drastically.

Sorry I didn't mention this sooner, but this is one of those things that existed before I started working here and I didn't even realize it was there until just now. :)

Dan
 
#9
Thanks, Dan. Setting "Force I frame seeks" to 9 has VRD moving through Hidef recordings off Freeview (DVB-T2) like they were mpeg2 files.
 

Dan203

Senior Developer
Staff member
#10
I tried a setting of 1-10 and it made no difference.
Setting that setting to 9 will force an I-frame seek instead, which is the fastest method available. If it's still slow then it's either the file or your machine. Try running the file through Quick Stream Fix and then navigating the fixed file. If that's better then it's likely the original file. If not then it's likely your machine.

Dan
 
#11
I use Simple x264 Launcher to encode my files. It uses a default key-frame (IDR-Frame, in H.264) distance of 250. Navigating that is quite slow. If I set it to 0 then navigation is as fast as MPEG2 but that increases the file size on 90 minutes of footage by 300 MB. I assume then that other applications must do that if their resulting videos are fast to navigate? I can't afford to lose that amount of space because over 7 files on a Bluray disc that could mean the difference between fitting 6 videos on a disc instead of 7 so I decided on a compromise of a key frame of 50. Then the video is only increased by 72MB and it's at least fast enough to navigate where it's no longer painfully slow although it's not as fast as before.
 

Dan203

Senior Developer
Staff member
#12
250 is really high. A typical MPEG-2 file uses a GOP length of 15-20 frames. That means it has an entry point every 1/2 second or so. At 250 it means there are only entry points every 8 seconds or so. So if you try to land on a frame that is at the very end of that sequence it would have to decode roughly 8 seconds worth of video to get the frame you want. Even with a fast PC that can be slow, and with a slow PC it can be really slow. 50 is more reasonable, and should produce decent results on a higher end PC.

Dan
 

Danr

Administrator
Staff member
#13
Actually three things affect navigation speed. The most critical, as you've discovered, is the I/IDR frame distance. A value of 1-2 seconds is generally quite reasonable.

The other two are, bit rate, lower bit rates mean moving less data, and the third is # of reference frames. When navigating we skip decoding non-reference frames, so if you using features like B-frame references and Pyramiding B-frames this can results in slower decoding. You can also reduce the number of reference frames being used at any one time. As with I/IDR distance (aka GOP size), these effect quality and bit rates.

Another approach is to look at this from a bit rate perspective. If you need to fit xx minutes of video on a blu-ray, just set the GOP size and the bit rate to the desired value to make it fit and let the encoder figure out how to maximize the quality. This works really really well with 2 pass encoding.
 
Top