Video conversion failure and Handbrake 1.2.2

Request Type:
BUG

MCEBuddy Version and Type (32bit or 64bit):
2.4.9 - 64

Operating System and Type (32bit or 64bit):
64

Summary of the problem or suggestion:
Video freezes while audio continues to play in mp4 conversions, mostly when another recording is in progress while the conversion is taking place. This has been going on for the past couple of months.

Separately, I have noticed that Handbrake 1.2.2 has its own bug in converting some videos. I use the software away from MCEBuddy on another computer, and have had some unusual failures. Apparently the bugs have been addressed in Nightlies and I am able to convert bug-free with Nightlies.

Also, I have tried to install some of your recommended Intel video drivers. All refused to be installed. I am currently running a 6th Gen i7 Quad with onboard Intel 530 graphics with driver 23.20.16.4973

Steps to replicate the bug:
See above

Screenshots:
The image is clear but not moving while the audio continues uninterrupted. At times the video conversion reprises at a later time in the same recording.


log.zip (656.6 KB)

Your source video is corrupted and has sync issues from which ffmpeg is unable to recover:

2019-06-23T18:36:05 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000014af929a920] PES packet size mismatch
2019-06-23T18:36:05 MCEBuddy.AppWrapper.FFmpeg → Last message repeated 2 times
2019-06-23T18:36:05 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000014afcbdc7a0] Non-monotonous DTS in output stream 0:2; previous: 30718800, current: 30715920; changing to 30718801. This may result in incorrect timestamps in the output file.
2019-06-23T18:36:05 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000014af929a920] PES packet size mismatch
2019-06-23T18:36:05 MCEBuddy.AppWrapper.FFmpeg → Last message repeated 15 times
2019-06-23T18:36:05 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000014af929a920] Invalid timestamps stream=0, pts=5396043679, dts=5396103209, size=3661
2019-06-23T18:36:05 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000014afcbdc7a0] Invalid DTS: 31001754 PTS: 30942224 in output stream 0:0, replacing by guess
2019-06-23T18:36:05 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000014af929a920] PES packet size mismatch
2019-06-23T18:36:05 MCEBuddy.AppWrapper.FFmpeg → Last message repeated 1 times
2019-06-23T18:36:05 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000014afcbdc7a0] Non-monotonous DTS in output stream 0:0; previous: 31022775, current: 31016769; changing to 31022776. This may result in incorrect timestamps in the output file.
2019-06-23T18:36:05 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000014afcbdc7a0] Non-monotonous DTS in output stream 0:0; previous: 31022776, current: 31019772; changing to 31022777. This may result in incorrect timestamps in the output file.
2019-06-23T18:36:05 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000014af929a920] PES packet size mismatch
2019-06-23T18:36:05 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000014afcbdc7a0] Non-monotonous DTS in output stream 0:0; previous: 31022777, current: 31019884; changing to 31022778. This may result in incorrect timestamps in the output file.
2019-06-23T18:36:05 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000014afcbdc7a0] Non-monotonous DTS in output stream 0:0; previous: 31022778, current: 31022775; changing to 31022779. This may result in incorrect timestamps in the output file.
2019-06-23T18:36:05 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000014af929a920] PES packet size mismatch

You can try telling MCEBuddy to use AVIDemux instead of FFMPEG and see if that helps by adding CommercialMergeTool=avidemux to your profile

Thanks. Verified that indeed. I don’t understand why I am getting the corrupted recordings intermittently. I am using a Hauppauge WinTV-DualHD and it has worked like a charm up until a couple of months ago. I have an independent setup, antenna facing same side, and there are no glitches there.

I was going to suggest trying to remove the commercial after the conversion but not sure if that will solve the issue since even handbrake is having trouble processing the video:

2019-06-23T18:39:50 MCEBuddy.AppWrapper.Handbrake → [mpeg2video @ 0000000005089320] invalid cbp at 0 38
2019-06-23T18:39:50 MCEBuddy.AppWrapper.Handbrake → [mpeg2video @ 0000000005089320] invalid cbp at 12 39
2019-06-23T18:39:50 MCEBuddy.AppWrapper.Handbrake → [mpeg2video @ 0000000005089320] 00 motion_type at 11 40
2019-06-23T18:39:50 MCEBuddy.AppWrapper.Handbrake → [mpeg2video @ 0000000005089320] MVs not available, ER not possible.
2019-06-23T18:39:50 MCEBuddy.AppWrapper.Handbrake → [ac3 @ 0000000004de7b40] delta bit allocation strategy reserved
2019-06-23T18:39:50 MCEBuddy.AppWrapper.Handbrake → [ac3 @ 0000000004de7b40] error decoding the audio block
2019-06-23T18:39:50 MCEBuddy.AppWrapper.Handbrake → [ac3 @ 0000000004de7b40] frame sync error
2019-06-23T18:39:51 MCEBuddy.AppWrapper.Handbrake → Encoding: task 1 of 1, 100.00 %[mpeg2video @ 0000000005089320] skipped MB in I-frame at 60 14
2019-06-23T18:39:51 MCEBuddy.AppWrapper.Handbrake → [mpeg2video @ 0000000005089320] skipped MB in I-frame at 86 15

But you can give it a try by settings PreConversionCommercialRemover=false in your profile but if the video is heavily corrupted I doubt it’ll help.

Most common reasons for video corruption are:

  1. Bad OTA/source signals
  2. An update in the TV Tuner driver which is causing sync/timing issues

Thanks, but I now know that I have to solve the OTA capture issue. It is either a driver or antenna issue. I appreciate your help

The “perfect” commercial cut has been the most illusive of all the parts of this process. It has never properly worked. Some times it leaves a whole segment in, and other times cuts out the last segment of the Nightly News. Weird.