HandBrake

Posted: **Sat Nov 24, 2018 5:23 am**

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.

Posted: **Sat Nov 24, 2018 8:21 am**

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

https://handbrake.fr/docs/en/latest/hel ... y-log.html

Posted: **Sat Nov 24, 2018 10:52 am**

rollin_eng I posted the logs.

Posted: **Sat Nov 24, 2018 5:13 pm**

Your logs look fine. What player is being used? Have you compared in VLC?

Posted: **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)

Posted: **Sat Nov 24, 2018 6:07 pm**

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.

Posted: **Sat Nov 24, 2018 9:49 pm**

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

Try the fastdecode tune.

Posted: **Sun Nov 25, 2018 7:51 am**

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?

Posted: **Sun Nov 25, 2018 10:11 am**

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.

Posted: **Sun Nov 25, 2018 10:36 am**

So what should I do? Can't I use keyint=x? Please help I don't really understand these media stuff?

Posted: **Sun Nov 25, 2018 10:51 am**

What should x be? Please tell me if I should use it and why this way is not recommended?

Posted: **Sun Nov 25, 2018 1:08 pm**

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.

Posted: **Sun Nov 25, 2018 1:30 pm**

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).

Posted: **Sun Nov 25, 2018 1:51 pm**

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.

Posted: **Sun Nov 25, 2018 2:45 pm**

. The playback enviroment is (quick time player).

Is QuickTime Player still 32 bit?
Compared perforfance with VLC and other players?

Posted: **Sun Nov 25, 2018 3:24 pm**

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

Posted: **Sun Nov 25, 2018 5:43 pm**

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?

HandBrake

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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