The.100.S04E01.PROPER.HDTV.x264-BATV - SanctityDenied: invalid.proper_qualitative.propers.are.not.allowed
The.100.S04E01.HDTV.x264-FLEET - SanctityDenied: totally.fine.no.issues
Are you serious... If youre going to perform bias nukes at least use valid reasons.
Not to mention the fact, when something happens on every SINGLE scene change throughout and isnt a
mastering/time-compression fault rule 126.96.36.199 applies.
Totally fine... Hah!
Check the Sample/ directory or extract the rar.
*tfm.png MPEG2Source().TFM().TDecimate() - AviSynth
*ffmpeg.png ffmpeg -i .ts -vf fps30000/1001,fieldmatch,yadifdeintinterlaced,decimate a.mkv - ffmpeg
# strings x264tv.exe grep fieldmatch
Thanks to the unnamed FLEET member for that...
The source is the problem please... While yes its true that source does have serious issues that will
perplex even an accurate IVTC filter like TFM, Uncomb or Decomb.
ffmpeg leaves behind unique faults which we can use to prove its use, we have purposely picked TFM for
these compares as it did the best job, when using Decomb or Uncomb we found similar combed artifacts to
However while the artifacting was present it wasnt nearly as exacerbated as ffmpegs and thus didnt match
Now.... Nobody can dare explain away why every unique ffmpeg flaw is present in the resulting encode by
FLEET, resulting in a 1:1 pixel match and 1:1 frame match.
FLEET has been using ffmpeg to filter their releases since their inception and before that in IMMERSE,
and before that MEncoder in IMMERSE.
Theyve lied and lied about the use of this banned filter every time theyve been confronted.
Theyve never once in the year+ its been officially banned under the latest ruleset attempted to write
their own IVTC filter as other groups have.
Instead they rely on a banned filter which has been proven TIME AND TIME again beyond a shred of a doubt
to be what they use, making any past or present FLEET release void.
Finally any future FLEET release must be nuked as breaching rule 6.3.1, and then we can have some quality
back in this section.