Handbrake Edited MP4 Takes a Long Time To Seek

[imdaman]

Hi everyone. I tried to decrease the bitrate of a MP4 in Handbrake using pretty much default settings for everything beside the avg bitrate with turbo & 2-pass. And I noticed that most of the MP4s I edit has issues with seeking the video. Not sure if seeking is the technical term but what I mean is going to a specific time in the video. If I try to seek 30 secs ahead, there's probably a 1 sec pause before the video actually starts playing. If I try to seek maybe 20 mins ahead, there's ~5 sec pause before playing. The video isn't out of sync but it just seems to need to buffer every time I try to seek. Does anyone have any fixes for this, setting I need to change, or maybe another open source editor I can use? I want to keep everything the same as source except decreasing the bitrate.

Here's a mediainfo for the vid but this issue is for most of the mp4 i try to edit:

Format : MPEG-4
Format profile : Base Media
Codec ID : isom
Duration : 29mn 36s
Overall bit rate : 4 073 Kbps
Writing application : Lavf53.29.100

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L3.2
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 29mn 36s
Bit rate : 4 000 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 60.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.072
Stream size : 847 MiB (98%)
Writing library : x264 core 120 r2120 0c7dab9
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x1:0x111 / me=hex / subme=5 / psy=0 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=0 / b_adapt=1 / b_bias=0 / direct=1 / weightb=0 / open_gop=0 / weightp=2 / keyint=300 / keyint_min=30 / scenecut=40 / intra_refresh=0 / rc=abr / mbtree=0 / bitrate=4000 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00
Language : English

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 29mn 36s
Bit rate mode : Constant
Bit rate : 64.1 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Delay relative to video : 17ms
Stream size : 13.6 MiB (2%)
Language : English

[aedipuss]

what are you playing them with?

[poisondeathray]

keyint=300

Longer max keyframe intervals are proportional to longer seektimes

Besides trying other playback software and hardware to rule out playback issues , reducing --keyint will improve slow seek latency . The "cost" of reducing the max interval is worse compression. So since you were doing 2pass avg bitrate, the quality will decrease slightly

[imdaman]

I'm playing with windows media player

[imdaman]

The media info I posted was actually the source file. After conversion I noticed that keyint=600. If there a way to change this in Handbrake?

I tried on laptop too with wmp and it has the delay too. It doesn't have the delay on vlc but for some reason any video I try seeking in vlc is distorted/pixelated video for a few seconds before returning to normal. However, that's a separate issue.

[poisondeathray]

The media info I posted was actually the source file. After conversion I noticed that keyint=600. If there a way to change this in Handbrake?

Try adding keyint=x in the advanced tab commandline box, separated by colon from the previous command, where "x" is the value

https://trac.handbrake.fr/wiki/x264Options

600 would be a 10sec max keyframe interval for 60fps video . If you want faster seeks try 1-2 seconds, so 60 or 120

So just add onto the existing commands

:keyint=120

(or whatever value you choose)

I tried on laptop too with wmp and it has the delay too. It doesn't have the delay on vlc but for some reason any video I try seeking in vlc is distorted/pixelated video for a few seconds before returning to normal. However, that's a separate issue.

Then it's more likely a playback issue or at least a combination of software and long --keyint value . You can try SMPlayer, MPCHC, Potplayer, many others... WMP isn't known as a very good player

[jagabo]

Many players have a "fast seek" option to work around this problem. Instead of seeking to the exact frame you want they seek to the nearest key frame. VLC has such a setting, for example.

[imdaman]

Thanks for the help poisondeathray! I was able to reduce the keyint to be the same as the source. Although there is still a little pause, I'm fine with it.

[jagabo]

In case you are wondering, most high compression codecs get a lot of their compression by not repeating parts of the picture that don't change from frame to frame. So in a talking head shot on a static background one frame will encode the entire picture (an I frame, or keyframe) but the next several frames (P and B frames) will only include the changes due to the moving lips/head of the speaker. Ie, the encoded video says "this frame is the same as the last frame, except for these changes..." Eventually the encoder will create another I frame followed by a bunch more P and B frames. That distance between I frames is the GOP size, or keyframe interval (keyint in x264).

When seeking to the middle of a GOP, to reconstruct that frame the decoder must first decompress the keyframe before the requested frame, then add in all the changes for the B and P frames up to the requested frame. With long GOPs and large frame sizes that can take quite a while. So seeking to frame 599 of a 600 frame GOP requires decompressing 599 frames before the frame can be shown to you.

There are two ways around the problem: using shorter GOPs will work for all players but you get less effective compression (large files in constant quality encodes, less quality with bitrate based encodes). Or you can use a player with a fast seek mode -- it doesn't seek to exactly the frame you specified but the nearest keyframe. For playback that usually fine. For video editing it's catastrophic.

Actually, there's a third way around the problem: get a faster CPU or graphics card, depending on which is doing the decoding!