Makemkv to Handrake issues after upgrade

[hursto75]

The last couple of movies that I have ripped with MKV are unplayable after going through handbrake. I am using the same process that I used before the upgrade to .13 and .14. Is anyone else having issues?

Thanks,

Brad

[Woodstock]

Have to ask, what version of Handbrake, what settings, what player?

I've been using the nightly builds of HB, using ripping with (almost) every version of MakeMKV since 1.5.6, and, if HB didn't crash during the encoding (it happens!), the files were always playable on VLC, Asus HDP, and Seagate Freeagent Theater.

Now, sometimes HB crashes at 99.99%, when writing to an MP4, and leaves an unplayable file. I have several MKVs that trigger this. Telling HB to encode to an MKV instead of an MP4 eliminates the crash, and the result is playable. But that seems to be a HB issue, and not an MKV issue.

[Romansh]

Now, sometimes HB crashes at 99.99%, when writing to an MP4, and leaves an unplayable file. I have several MKVs that trigger this. Telling HB to encode to an MKV instead of an MP4 eliminates the crash, and the result is playable. But that seems to be a HB issue, and not an MKV issue.

Have you reported it? I'm sure the HandBrake devs would be very interested in seeing a HandBrake encode log, along with a crash log if applicable (e.g. from Mac OS X's Crash Reporter).

[Woodstock]

No, I have not reported it. While I can duplicate it at will, there is nothing showing up in the log files that differs from a successful encoding to the "never finish" encodes, except for the lack of the final statistics and the message saying the encode finished. The x264 statistics are there, but the lines that follow the PSNR stat are never logged.

Examples from when I rip the same MKV to an M4V (first block) vs. an MKV (second block):

Code: Select all

[11:47:54] reader: done. 1 scr changes
[11:47:56] work: average encoding speed for job is 55.650169 fps
[11:47:56] sync: got 515211 frames, 515240 expected
[11:47:57] mpeg2video-decoder done: 515211 frames, 0 decoder errors, 0 drops
[11:47:57] render: lost time: 196111980 (65310 frames)
[11:47:57] render: gained time: 196111980 (245907 frames) (0 not accounted for)
[11:47:57] render: average dropped frame duration: 3002
x264 [info]: frame I:4328  Avg QP:17.83  size: 35764  PSNR Mean Y:46.42 U:49.16 V:49.37 Avg:47.13 Global:46.75
x264 [info]: frame P:132868 Avg QP:20.04  size:  9703  PSNR Mean Y:44.83 U:48.24 V:48.41 Avg:45.67 Global:45.33
x264 [info]: frame B:312704 Avg QP:21.97  size:  2389  PSNR Mean Y:43.83 U:47.98 V:48.13 Avg:44.80 Global:44.46
x264 [info]: consecutive B-frames:  3.0%  5.9% 21.4% 69.7%
x264 [info]: mb I  I16..4: 12.8% 69.4% 17.8%
x264 [info]: mb P  I16..4:  2.7%  8.4%  1.5%  P16..4: 48.1% 16.6% 11.1%  0.0%  0.0%    skip:11.6%
x264 [info]: mb B  I16..4:  0.2%  0.9%  0.2%  B16..8: 40.9%  3.0%  0.5%  direct: 3.6%  skip:50.6%  L0:43.1% L1:52.4% BI: 4.5%
x264 [info]: 8x8 transform intra:67.2% inter:78.6%
x264 [info]: coded y,uvDC,uvAC intra: 67.2% 87.7% 56.3% inter: 18.0% 29.6% 1.3%
x264 [info]: i16 v,h,dc,p: 32% 24% 11% 33%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 17% 15% 26%  6%  7%  7%  7%  7%  8%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19% 20% 17%  6%  9%  8%  9%  6%  7%
x264 [info]: i8c dc,h,v,p: 44% 25% 19% 12%
x264 [info]: Weighted P-Frames: Y:5.7% UV:3.5%
x264 [info]: ref P L0: 53.1% 10.2% 26.0% 10.4%  0.3%
x264 [info]: ref B L0: 79.8% 16.0%  4.2%
x264 [info]: ref B L1: 92.2%  7.8%
x264 [info]: SSIM Mean Y:0.9834446 (17.811db)
x264 [info]: PSNR Mean Y:44.152 U:48.069 V:48.222 Avg:45.079 Global:44.718 kb/s:1019.70

(I let the job run for 7+ hours after it hit this point before killing it)

Code: Select all

[15:06:50] reader: done. 1 scr changes
[15:06:52] work: average encoding speed for job is 50.509285 fps
[15:06:53] sync: got 515211 frames, 515240 expected
[15:06:53] mpeg2video-decoder done: 515211 frames, 0 decoder errors, 0 drops
[15:06:53] render: lost time: 196111980 (65310 frames)
[15:06:53] render: gained time: 196111980 (245907 frames) (0 not accounted for)
[15:06:53] render: average dropped frame duration: 3002
x264 [info]: frame I:4328  Avg QP:17.83  size: 35764  PSNR Mean Y:46.42 U:49.16 V:49.37 Avg:47.13 Global:46.75
x264 [info]: frame P:132868 Avg QP:20.04  size:  9703  PSNR Mean Y:44.83 U:48.24 V:48.41 Avg:45.67 Global:45.33
x264 [info]: frame B:312704 Avg QP:21.97  size:  2389  PSNR Mean Y:43.83 U:47.98 V:48.13 Avg:44.80 Global:44.46
x264 [info]: consecutive B-frames:  3.0%  5.9% 21.4% 69.7%
x264 [info]: mb I  I16..4: 12.8% 69.4% 17.8%
x264 [info]: mb P  I16..4:  2.7%  8.4%  1.5%  P16..4: 48.1% 16.6% 11.1%  0.0%  0.0%    skip:11.6%
x264 [info]: mb B  I16..4:  0.2%  0.9%  0.2%  B16..8: 40.9%  3.0%  0.5%  direct: 3.6%  skip:50.6%  L0:43.1% L1:52.4% BI: 4.5%
x264 [info]: 8x8 transform intra:67.2% inter:78.6%
x264 [info]: coded y,uvDC,uvAC intra: 67.2% 87.7% 56.3% inter: 18.0% 29.6% 1.3%
x264 [info]: i16 v,h,dc,p: 32% 24% 11% 33%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 17% 15% 26%  6%  7%  7%  7%  7%  8%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19% 20% 17%  6%  9%  8%  9%  6%  7%
x264 [info]: i8c dc,h,v,p: 44% 25% 19% 12%
x264 [info]: Weighted P-Frames: Y:5.7% UV:3.5%
x264 [info]: ref P L0: 53.1% 10.2% 26.0% 10.4%  0.3%
x264 [info]: ref B L0: 79.8% 16.0%  4.2%
x264 [info]: ref B L1: 92.2%  7.8%
x264 [info]: SSIM Mean Y:0.9834446 (17.811db)
x264 [info]: PSNR Mean Y:44.152 U:48.069 V:48.222 Avg:45.079 Global:44.718 kb/s:1019.71
[15:06:53] mux: track 0, 449900 frames, 2191027302 bytes, 1019.62 kbps, fifo 8
[15:06:53] mux: track 1, 805822 frames, 343666117 bytes, 159.93 kbps, fifo 512
[15:06:53] mux: track 2, 805822 frames, 343660878 bytes, 159.93 kbps, fifo 512
[15:06:53] mux: track 3, 3375 frames, 7744800 bytes, 3.60 kbps, fifo 8
[15:06:53] decomb: deinterlaced 23414 | blended 8711 | unfiltered 417775 | total 449900
[15:06:53] libhb: work result = 0
Rip done!
HandBrake has exited.

When it happens, it takes one of the CPUs to 100% until I kill the job. And it has always worked if the target is an MKV file.

Short of sending one of the 3 to 7GB files that causes it to the HB people (which would not be legal), I don't see where they would get anything useful out of my report.

[Romansh]

Short of sending one of the 3 to 7GB files that causes it to the HB people (which would not be legal), I don't see where they would get anything useful out of my report.

Well, they don't accept 7 GB copyrighted samples anyway. But the log still contains some information (source, settings) which may help in reproducing the issue. If a developer can reproduce your issue, then the chances of it getting fixed are greatly improved…