Handbrake: The compressed mp4 video is too laggy when seeking?

HandBrake for Mac support
Forum rules
An Activity Log is required for support requests. Please read How-to get an activity log? for details on how and why this should be provided.
Post Reply
curious_developer
Posts: 9
Joined: Sat Nov 24, 2018 5:14 am

Handbrake: The compressed mp4 video is too laggy when seeking?

Post by curious_developer »

I am currently using Handbrake (version 1.1.2 / Mac) to compress my mp4 videos. Now the videos that are being compressed are of frame rate 30, and I specified in Handbrake the frame to be (same as source).

Now before compressing the videos the seeking is pretty fast, which mean if I hold the seeker and move it around the video moves fast.

But after compressing the videos the seeking becomes laggy, which mean if I hold the seeker of the player and move it around the video moves in a slow way (laggy way).

Can someone please explain why this happens?

Why compression is affecting the seeking? What can I do to fix this?

These are the Logs:

Code: Select all


HandBrake Activity Log for Session: 2018-11-24 12:34:26 +0200
Handbrake Version: 1.1.2 (2018090500)
Logs.mp4
Preset: Fast 1080p30 (Modified)
[12:34:26] macgui: QueueCore scanning specifically for title: 1
[12:34:26] CPU: Intel(R) Core(TM) i5-5250U CPU @ 1.60GHz
[12:34:26]  - Intel microarchitecture Broadwell
[12:34:26]  - logical processor count: 4
[12:34:26] hb_scan: path=/Users/hasanaboutaam/Desktop/ScreenFlow.mp4, title_index=1
udfread ERROR: ECMA 167 Volume Recognition failed
disc.c:323: failed opening UDF image /Users/hasanaboutaam/Desktop/ScreenFlow.mp4
disc.c:424: error opening file BDMV/index.bdmv
disc.c:424: error opening file BDMV/BACKUP/index.bdmv
[12:34:26] bd: not a bd - trying as a stream/file instead
libdvdnav: Using dvdnav version 6.0.0
libdvdread: Encrypted DVD support unavailable.
libdvdread:DVDOpenFileUDF:UDFFindFile /VIDEO_TS/VIDEO_TS.IFO failed
libdvdread:DVDOpenFileUDF:UDFFindFile /VIDEO_TS/VIDEO_TS.BUP failed
libdvdread: Can't open file VIDEO_TS.IFO.
libdvdnav: vm: failed to read VIDEO_TS.IFO
[12:34:26] dvd: not a dvd - trying as a stream/file instead
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/Users/hasanaboutaam/Desktop/ScreenFlow.mp4':
  Metadata:
    major_brand     : mp42
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    creation_time   : 2018-11-23 08:29:10
  Duration: 00:01:12.40, start: 0.000000, bitrate: 488 kb/s
    Stream #0:0(und): Audio: aac (LC) [mp4a / 0x6134706D]
      44100 Hz, stereo, fltp, 2 kb/s (default)
    Metadata:
      creation_time   : 2018-11-23 08:29:10
    Stream #0:1(und): Video: h264 (Main) [avc1 / 0x31637661]
      yuv420p, tv, bt709/bt709/bt709
      1280x720, 483 kb/s
      30 fps, 3k tbn (default)
    Metadata:
      creation_time   : 2018-11-23 08:29:10
      encoder         : JVT/AVC Coding
[12:34:26] scan: decoding previews for title 1
[12:34:26] scan: audio 0x0: aac, rate=44100Hz, bitrate=2067 Unknown (AAC) (2.0 ch)
[12:34:26] scan: 10 previews, 1280x720, 30.000 fps, autocrop = 0/0/6/6, aspect 16:9, PAR 1:1
[12:34:26] libhb: scan thread found 1 valid title(s)
[12:34:26] macgui: QueueCore scan done
[12:34:26] macgui: QueueCore started encoding Logs.mp4
[12:34:26] 1 job(s) to process
[12:34:26] macgui: QueueCore with preset Fast 1080p30 (Modified)
[12:34:26] starting job
[12:34:26] decomb filter thread started for segment 0
[12:34:26] decomb filter thread started for segment 1
[12:34:26] decomb filter thread started for segment 2
[12:34:26] decomb filter thread started for segment 3
[12:34:26] decomb check thread started for segment 0
[12:34:26] decomb check thread started for segment 1
[12:34:26] decomb check thread started for segment 2
[12:34:26] decomb check thread started for segment 3
[12:34:26] mask filter thread started for segment 0
[12:34:26] mask filter thread started for segment 1
[12:34:26] mask filter thread started for segment 2
[12:34:26] mask filter thread started for segment 3
[12:34:26] mask erode thread started for segment 0
[12:34:26] mask erode thread started for segment 1
[12:34:26] mask erode thread started for segment 2
[12:34:26] mask erode thread started for segment 3
[12:34:26] mask dilate thread started for segment 0
[12:34:26] mask dilate thread started for segment 1
[12:34:26] mask dilate thread started for segment 2
[12:34:26] mask dilate thread started for segment 3
[12:34:26] yadif thread started for segment 0
[12:34:26] yadif thread started for segment 1
[12:34:26] yadif thread started for segment 2
[12:34:26] work: only 1 chapter, disabling chapter markers
[12:34:26] job configuration:
[12:34:26]  * source
[12:34:26]    + /Users/hasanaboutaam/Desktop/ScreenFlow.mp4
[12:34:26]    + title 1, chapter(s) 1 to 1
[12:34:26]    + container: mov,mp4,m4a,3gp,3g2,mj2
[12:34:26]    + data rate: 488 kbps
[12:34:26]  * destination
[12:34:26]    + /Users/hasanaboutaam/Desktop/Logs.mp4
[12:34:26]    + container: MPEG-4 (libavformat)
[12:34:26]      + align initial A/V stream timestamps
[12:34:26]  * video track
[12:34:26]    + decoder: h264
[12:34:26]      + bitrate 483 kbps
[12:34:26]    + filters
[12:34:26]      + Comb Detect (mode=3:spatial-metric=2:motion-thresh=1:spatial-thresh=1:filter-mode=2:block-thresh=40:block-width=16:block-height=16)
[12:34:26]      + Decomb (mode=39)
[12:34:26]      + Framerate Shaper (mode=1:rate=27000000/900000)
[12:34:26]        + frame rate: 30.000 fps -> constant 30.000 fps
[12:34:26]      + Crop and Scale (width=1268:height=720:crop-top=0:crop-bottom=0:crop-left=6:crop-right=6)
[12:34:26]        + source: 1280 * 720, crop (0/0/6/6): 1268 * 720, scale: 1268 * 720
[12:34:26]    + Output geometry
[12:34:26]      + storage dimensions: 1268 x 720
[12:34:26]      + pixel aspect ratio: 1 : 1
[12:34:26]      + display dimensions: 1268 x 720
[12:34:26]    + encoder: H.264 (libx264)
[12:34:26]      + preset:  fast
[12:34:26]      + profile: main
[12:34:26]      + level:   4.0
[12:34:26]      + quality: 20.00 (RF)
[12:34:26]  * audio track 1
[12:34:26]    + decoder: Unknown (AAC) (2.0 ch) (track 1, id 0x0)
[12:34:26]      + bitrate: 2 kbps, samplerate: 44100 Hz
[12:34:26]    + mixdown: Stereo
[12:34:26]    + encoder: AAC (Apple AudioToolbox)
[12:34:26]      + bitrate: 160 kbps, samplerate: 44100 Hz
[12:34:26] yadif thread started for segment 3
[12:34:26] sync: expecting 2172 video frames
[12:34:26] encx264: min-keyint: 30, keyint: 300
[12:34:26] encx264: encoding at constant RF 20.000000
[12:34:26] encx264: unparsed options: level=4.0:ref=2:8x8dct=0:weightp=1:subme=6:vbv-bufsize=25000:vbv-maxrate=20000:rc-lookahead=30
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x264 [info]: profile Main, level 4.0
[12:34:26] sync: first pts video is 0
[12:34:26] sync: "Chapter 1" (1) at frame 1 time 0
[12:34:26] sync: first pts audio 0x0 is 0
[12:34:51] reader: done. 1 scr changes
[12:34:52] work: average encoding speed for job is 85.523369 fps
[12:34:52] comb detect: heavy 0 | light 2 | uncombed 2170 | total 2172
[12:34:52] decomb: deinterlaced 0 | blended 2 | unfiltered 2170 | total 2172
[12:34:52] vfr: 2172 frames output, 0 dropped and 0 duped for CFR/PFR
[12:34:52] vfr: lost time: 0 (0 frames)
[12:34:52] vfr: gained time: 0 (0 frames) (0 not accounted for)
[12:34:52] aac-decoder done: 3117 frames, 0 decoder errors
[12:34:52] h264-decoder done: 2172 frames, 0 decoder errors
[12:34:52] sync: got 2172 frames, 2172 expected
[12:34:52] sync: framerate min 30.000 fps, max 30.000 fps, avg 30.000 fps
x264 [info]: frame I:8     Avg QP: 6.46  size: 20947
x264 [info]: frame P:565   Avg QP:19.74  size:   210
x264 [info]: frame B:1599  Avg QP:24.61  size:    84
x264 [info]: consecutive B-frames:  1.2%  1.1%  2.1% 95.6%
x264 [info]: mb I  I16..4: 87.5%  0.0% 12.5%
x264 [info]: mb P  I16..4:  0.0%  0.0%  0.1%  P16..4:  0.2%  0.0%  0.0%  0.0%  0.0%    skip:99.7%
x264 [info]: mb B  I16..4:  0.0%  0.0%  0.0%  B16..8:  0.1%  0.0%  0.0%  direct: 0.0%  skip:99.8%  L0:51.6% L1:46.5% BI: 1.9%
x264 [info]: coded y,uvDC,uvAC intra: 12.6% 12.4% 7.0% inter: 0.0% 0.0% 0.0%
x264 [info]: i16 v,h,dc,p: 95%  4%  0%  0%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 32% 22% 24%  4%  4%  3%  4%  3%  4%
x264 [info]: i8c dc,h,v,p: 85%  7%  8%  0%
x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x264 [info]: ref P L0: 77.5% 22.5%
x264 [info]: ref B L0: 84.4% 15.6%
x264 [info]: ref B L1: 93.5%  6.5%
x264 [info]: kb/s:46.41
[12:34:52] mux: track 0, 2172 frames, 419719 bytes, 46.36 kbps, fifo 4096
[12:34:52] mux: track 1, 3120 frames, 18720 bytes, 2.07 kbps, fifo 4096
[12:34:52] libhb: work result = 0


Thanks.
Last edited by curious_developer on Sat Nov 24, 2018 10:51 am, edited 1 time in total.
rollin_eng
Veteran User
Posts: 4840
Joined: Wed May 04, 2011 11:06 pm

Re: Handbrake: The compressed mp4 video is too laggy when seeking?

Post by rollin_eng »

Could you please post your HB logs, instructions can be found here:

https://handbrake.fr/docs/en/latest/hel ... y-log.html
curious_developer
Posts: 9
Joined: Sat Nov 24, 2018 5:14 am

Re: Handbrake: The compressed mp4 video is too laggy when seeking?

Post by curious_developer »

rollin_eng I posted the logs.
Deleted User 13735

Re: Handbrake: The compressed mp4 video is too laggy when seeking?

Post by Deleted User 13735 »

Your logs look fine. What player is being used? Have you compared in VLC?
Woodstock
Veteran User
Posts: 4614
Joined: Tue Aug 27, 2013 6:39 am

Re: Handbrake: The compressed mp4 video is too laggy when seeking?

Post by Woodstock »

I do not see an entry in the log for the HTTP streaming being optimized... Which would be important to some players when seeking.

It is missing if not specified in the Summary tab, but should display in the destination->container area as:
+ optimized for HTTP streaming (fast start)
Deleted User 13735

Re: Handbrake: The compressed mp4 video is too laggy when seeking?

Post by Deleted User 13735 »

Woodstock wrote: Sat Nov 24, 2018 5:38 pm I do not see an entry in the log for the HTTP streaming being optimized... Which would be important to some players when seeking.

It is missing if not specified in the Summary tab, but should display in the destination->container area as:
+ optimized for HTTP streaming (fast start)
Yes, that could delay start times when played over streaming protocol. Seek times? Not so sure, but one thing to try.
mduell
Veteran User
Posts: 8187
Joined: Sat Apr 21, 2007 8:54 pm

Re: Handbrake: The compressed mp4 video is too laggy when seeking?

Post by mduell »

Low performance playback environment + high efficiency encoding will make for slow seeking.

Try the fastdecode tune.
curious_developer
Posts: 9
Joined: Sat Nov 24, 2018 5:14 am

Re: Handbrake: The compressed mp4 video is too laggy when seeking?

Post by curious_developer »

The playback enviroment is (quick time player).

Looking up through the internet, I found out a suggestion to add this (keyint=x) in the additional options box in the video tab.

I did this and it worked, I set x to 30.

Now the big question is :

WHY DID IT WORK?

WHAT DID IT DO?

IS IT BAD FOR PERFORMANCE?
User avatar
Ritsuka
HandBrake Team
Posts: 1650
Joined: Fri Jan 12, 2007 11:29 am

Re: Handbrake: The compressed mp4 video is too laggy when seeking?

Post by Ritsuka »

A keyframe is faster to decode than another type of frame, because it has to decode only that frame instead of many other frames. It's bad for compressor to any too many keyframes, it will either take more space or have less quality.
curious_developer
Posts: 9
Joined: Sat Nov 24, 2018 5:14 am

Re: Handbrake: The compressed mp4 video is too laggy when seeking?

Post by curious_developer »

So what should I do? Can't I use keyint=x? Please help I don't really understand these media stuff?
curious_developer
Posts: 9
Joined: Sat Nov 24, 2018 5:14 am

Re: Handbrake: The compressed mp4 video is too laggy when seeking?

Post by curious_developer »

What should x be? Please tell me if I should use it and why this way is not recommended?
User avatar
BradleyS
Moderator
Posts: 1860
Joined: Thu Aug 09, 2007 12:16 pm

Re: Handbrake: The compressed mp4 video is too laggy when seeking?

Post by BradleyS »

Ritsuka summed it up pretty clearly. Usually you want to leave it alone, but wanting faster seeking is a fine reason to change it, if you don't mind some loss of compression efficiency (slightly larger files).

Another way to look at it is keyint controls how big a group of pictures can be. If you have 30 frames per second video, setting keyint=30 means you will have an easy seek point every 30 frames or 1 second.

HandBrake's Production presets do something like this to make editing videos easier. If you intend to do some editing or scrub around a lot on a computer after encoding, perhaps try one of those presets instead of changing encoder options manually.
curious_developer
Posts: 9
Joined: Sat Nov 24, 2018 5:14 am

Re: Handbrake: The compressed mp4 video is too laggy when seeking?

Post by curious_developer »

Ahh thanks bradley for your reply, I want to ask you one more question: what values of x I am able to use (what is the range that is safe for me).
User avatar
BradleyS
Moderator
Posts: 1860
Joined: Thu Aug 09, 2007 12:16 pm

Re: Handbrake: The compressed mp4 video is too laggy when seeking?

Post by BradleyS »

For the x264 encoder, keyint may be set between 1 and 250 (frames). The default is the maximum. The encoder can use a shorter GOP if optimal, for instance it may be 100 frames into a GOP and a scene change occurs; typically the encoder will end the GOP and begin a new one by inserting a keyframe. Think of keyint as a limit.

If you're doing video editing after HandBrake encoding, use the official Production presets, which set keyint=12 (half of 24 FPS NTSC film). Half or 1x the source frame rate is a good idea here.

If you just want better seeking during normal playback and aren't bringing your HandBrake encodes into a video editor for further work, try a value 1-2x your source frame rate. Assuming ScreenFlow is capturing at around 60 FPS variable, keyint=60 or 90 or 120 may do what you want.

Or get a faster machine with a fast SSD.
Deleted User 13735

Re: Handbrake: The compressed mp4 video is too laggy when seeking?

Post by Deleted User 13735 »

. The playback enviroment is (quick time player).
Is QuickTime Player still 32 bit?
Compared perforfance with VLC and other players?
User avatar
BradleyS
Moderator
Posts: 1860
Joined: Thu Aug 09, 2007 12:16 pm

Re: Handbrake: The compressed mp4 video is too laggy when seeking?

Post by BradleyS »

QuickTime 7 which is basically gone is. QuickTime X which has been around for some time has always been 64-bit.

This is the real issue with performance, combined with what I assume is a spinning hard disk and not an SSD:

Code: Select all

CPU: Intel(R) Core(TM) i5-5250U CPU @ 1.60GHz
mduell
Veteran User
Posts: 8187
Joined: Sat Apr 21, 2007 8:54 pm

Re: Handbrake: The compressed mp4 video is too laggy when seeking?

Post by mduell »

BradleyS wrote: Sun Nov 25, 2018 3:24 pmcombined with what I assume is a spinning hard disk and not an SSD:
What Mac with a low power 5th gen core CPU ever offered a spinning disk option?
Post Reply