'Decomb' ...now you need it, now you don't

General questions or discussion about HandBrake, Video and/or audio transcoding, trends etc.
Post Reply
markfilipak
Regular User
Posts: 116
Joined: Thu Aug 01, 2019 8:58 pm

'Decomb' ...now you need it, now you don't

Post by markfilipak » Wed Sep 11, 2019 4:16 am

===== Case #1 =====

The source is '00051.m2ts'. ffprobe reports:
  • frames.frame. ... .interlaced_frame=1
  • frames.frame. ... .top_field_first=1
  • frames.frame. ... .repeat_pict=0
The source is hard telecined. The origin is known to be film.

The transcodes are:
#1: UNFINISHED BUSINESS, Telling Dieter's Story i30-to-p24 D.O.O.O.O 18.Q .mkv - 89,189,761 bytes ...'Detelecine' only
#2: UNFINISHED BUSINESS, Telling Dieter's Story i30-to-p24 D.D.O.O.O 18.Q .mkv - 89,189,761 bytes ...adds 'Deinterlace Detection'
#3: UNFINISHED BUSINESS, Telling Dieter's Story i30-to-p24 D.D.DD.O.O 18.Q .mkv - 43,385,885 bytes ...adds 'Decomb'

#1 & #2 are identical and have motion-object combing.
#3 is perfect (i.e., a snake's body motions & even scene transitions do not produce combing).

Conclusion: 'Deinterlace Detection' doesn't matter except for 'Decomb', which does matter. This result is entirely expected.

===== Case #2 =====

The source is '00045.m2ts'. ffprobe reports:
  • frames.frame. ... .interlaced_frame=1
  • frames.frame. ... .top_field_first=1
  • frames.frame. ... .repeat_pict=0
...same as Case #1

The source is hard telecined. The origin is known to be film.
...same as Case #1

#1: An Attempt at Reflection i30-to-p24 D.O.O.O.O 18.Q .mkv - 25,899,669 bytes ...'Detelecine' only
#2: An Attempt at Reflection i30-to-p24 D.D.O.O.O 18.Q .mkv - 25,899,669 bytes ...adds 'Deinterlace Detection'
#3: An Attempt at Reflection i30-to-p24 D.D.DD.O.O 18.Q .mkv - 14,888,778 bytes ...adds 'Decomb'

#1 & #2 are identical and are perfect.
#3 has motion-object combing (i.e., jungle tree leaves overhead & grasses underfoot scintillate during panning shot).

Conclusion: 'Decomb' is adding motion-object combing, but how? This result is unexpected.

=====

When MPV's deinterlace ('d') control is 'on', both source scenes ('00051.m2ts' & '00045.m2ts') play perfectly. Any ideas what MPV's developers are doing that HB's developer's aren't? Or am I simply missing something? It seems to me that if there was a way to pipe MPV's frames to HB for encoding, it would be nirvana.

Post Reply