This project has moved and is read-only. For the latest updates, please go here.

Conversion Failure - Interlace Problems?

Nov 29, 2014 at 2:34 AM
I had my first ever "bad transcode" on an episode the other night. Source was a 576i MPEG2 broadcast into a .TS file

I'm using quicksync and the build was the 11/19/2014

It may have been a one-off but I thought i'd share the log with you in case there's anything to be learnt.
I've put the log and a screen-shot of the resulting file in a folder in earlyaccess called "Griffo"

Nov 29, 2014 at 2:51 AM
Thanks for sharing that. We just analyzed and here's what happened. (it's an interlacing issue)

MCEBuddy scans your video for interlacing results (check for progressive, top, bottom and unknown frames). However this is a VERY intensive process so to save time MCEBuddy only analyzes the 120 seconds of the video, 300 seconds into the video (5 minutes), i.e. 5th to 7th minute. In your case the results were:
2014-11-24T23:52:00 MCEBuddy.AppWrapper.FFmpegMediaInfo --> Parsed Single frame Interlace Detection. Results ->
Top Frame First -> 486
Bottom Frame First -> 0
Progressive Frames -> 1798
Undetermined Frames -> 708
This basically told MCEBuddy heuristically that it's a progressive video, there are some interlaced frames but more progressive frames. Today videos typically have both types of material (interlaced and non interlaced mixed in the same stream). E.g. While the main show/movie may be progressive, the advertisements in between may be interlaced. Or vice versa, the movie may be an older movie that is interlaced and the advertisement is progressive. So there is no "correct" answer of should I deinterlace the video or not. The good news is that handbrake has a special mode that's enabled called decombing that selectively deinterlaces the video where required. However since MCEBuddy removes the commercials before the conversion (under normal circumstances) it should ideally be left with only interlaced or progressive content. Since decombing is also a slow process, in order to optimize time spent MCEBuddy will try to analyze the 120 seconds of video (5th to 7th minute) and then enable or disable decombing/deinterlacing as appropriate.

In your case since the results shows more progressive content than interlaced content, MCEBuddy turned off the decombing which obviously was incorrect since you had interlaced content. This issue is because of the location where MCEBuddy tested the video for interlacing results (5th to 7th minute) and got it wrong. The "ideal" solution would to be to leave decombing on all the time (not deinterlacing since deinterlacing progressive content will reduce quality and ofcourse as you can see not deinterlacing interlaced content is also bad, so decombing is best, check and interlace each frame as required) but that will significantly increase time.
The other option is to Analyze the entire video for interlaced content (not just 120 seconds) but that too takes a lot of time.

The only option for us to change the location of the interlace check (say 7th to 10th minute) maybe increase the duration slightly to avoid adverse impact on the overall timelines.

In your case, the solution is simple. Turn off the Automatic Quality detection in the conversion task options and it'll default to using the decomb, which, while slower, will ensure 100% accurate results and quality everytime.

Hope this helps and thanks for your feedback
Marked as answer by rboy1 on 11/28/2014 at 7:10 PM
Nov 29, 2014 at 3:10 AM
We are looking at the performance figures and in the next build will try to analyze fro 600 seconds 240 seconds into the video, ie skip the first 4 minutes and analyze 10 mintues. It will add about 3 minutes to the overall conversion time but will make it more reliable
Nov 29, 2014 at 3:11 AM
Try and the next build on the same video if you can and let us know the results.
Nov 29, 2014 at 4:13 AM
You guys constantly amaze me with your rapid response and support. Thank you for the very detailed response, it makes sense.

I'll download the latest build, but unfortunately the original file was deleted as part of the conversion process so I don't have it to re-test.

Dec 3, 2014 at 10:29 AM
Just in case someone comes across this later. Setting the decomb to on permanently seems to have fixed the problem. As suggested this has resulted in a hit to the transcode rate - droppeing from a normal 180fps to between 98 and 140fps with the average being closer to around 100fps for the conversion of mpeg2 576i/p material. Intel NUC i5 using Quicksync.