Megui settings for anime?

[qnkov]

Hello there. I'm using Megui to encode from 1080p to 720p. Mainly from HorribleSubs. Can someone tell me what are the best settings doing that enconde? Should i use a filter, or better fps, or some other option in the program? Or should i use tunning like Animation or Film?

Format : Matroska
Format version : Version 4 / Version 2
File size : 541 MiB
Duration : 23mn 40s
Overall bit rate : 3 198 Kbps
Encoded date : UTC 2010-02-22 21:41:29
Writing application : no_variable_data
Writing library : no_variable_data
Attachements : OpenSans-Semibold.ttf

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 23mn 40s
Nominal bit rate : 3 072 Kbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.810 fps
Original frame rate : 23.976 (23976/1000) fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.062
Writing library : x264 core 120 r2120 0c7dab9
Encoding settings : cabac=1 / ref=4 / deblock=1:1:1 / analyse=0x3:0x113 / me=umh / subme=8 / psy=1 / psy_rd=0.40:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=8 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=3072 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=6144 / vbv_bufsize=15360 / nal_hrd=none / ip_ratio=1.40 / aq=1:0.60
Default : Yes
Forced : No
Statistics Tags Issue : no_variable_data 1970-01-01 00:00:00 / no_variable_data 2010-02-22 21:41:29
FromStats_BitRate : 3065363
FromStats_Duration : 00:23:40.003000000
FromStats_FrameCount : 34047
FromStats_StreamSize : 544103161

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : A_AAC
Duration : 23mn 40s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 44.1 KHz
Frame rate : 43.066 fps (1024 spf)
Compression mode : Lossy
Language : Japanese
Default : Yes
Forced : No
Statistics Tags Issue : no_variable_data 1970-01-01 00:00:00 / no_variable_data 2010-02-22 21:41:29
FromStats_BitRate : 127999
FromStats_Duration : 00:23:40.086000000
FromStats_FrameCount : 61158
FromStats_StreamSize : 22721375

Text
ID : 3
Format : ASS
Codec ID : S_TEXT/ASS
Codec ID/Info : Advanced Sub Station Alpha
Compression mode : Lossless
Language : English
Default : Yes
Forced : No
Statistics Tags Issue : no_variable_data 1970-01-01 00:00:00 / no_variable_data 2010-02-22 21:41:29
FromStats_BitRate : 140
FromStats_Duration : 00:22:35.550000000
FromStats_FrameCount : 325
FromStats_StreamSize : 23818

[hello_hello]

There's no right answer. The Animation tuning will probably help reduce the file size for animation with a lot of flat sections of colour with little detail (something like the Simpsons) but if there's lots of fine detail or you see detail is being lost (it'll also depend a lot on on the CRF value) try the Film tuning or no tuning at all etc.

Even for animation, you should generally only filter sources that require it for a specific reason. Is the some way you feel the source could be improved? Maybe post a small sample of the source if you need suggestions.

[Melan]

The 720p TV x264 Releasing Standards 2016 a.k.a. tvx264
The.720p.TV.x264.Releasing.Standards.2016-TVx264

[ Intro ]
Since the last revision of this document in 2011, TV-X264 has grown and become a major section that many people contribute to and depend on. This new revision aims to update the standards from 2011 to standards suitable for 2016 and the future. Adding clarity and patching loopholes to once again allow for consistent and quality releases, which was the aim of this standard back in 2011.

Compliance with this document is optional as of its pre date, and mandatory as of 2016-04-10 00:00:00 UTC (1460246400 Unix time).

[ Recommended ]
It is recommended to view the unformatted version of this ruleset bundled within this release.

1) [ HDTV Sources ]
1.1) HDTV is considered as a high definition natively recorded transport stream.
1.2) HDTV sources must not be upscaled, see section 3.
1.3) Providers which downscale 1080i to 720p (e.g. BellTV) are not allowed.

2) [ AHDTV Sources ]
2.1) Analogue HDTV is considered as a high definition captured stream from the analog output (e.g. Component, DVI, HDMI) of a set-top box.
2.2) Captures must be done at the native broadcast format of the source.
2.2.1) Captures from devices which are unable to output a native format must be restored to the original framerate.
2.2.2) If captures cannot be completely restored to their native framerate, such as a single dupe frame every 1000 or blended/ghost frames due to mangling from the set-top box or capture device, this is considered a technical flaw.

3) [ HR.PDTV Sources ]
3.1) High-Resolution PDTV is considered as non-high definition content which has been upscaled and broadcasted on a high definition channel.
3.1.1) Windowboxed content (large black bars on all sides) lack sufficient source resolution to be considered HR.PDTV, and is not allowed.
3.2) Video must be cropped and resized to fit within a maximum resolution of:
3.2.1) 960x720 for aspect ratios less than 1.78:1.
e.g. 1920x1080 --> Crop(240,0,-240,-0) --> 1440x1080 --> 960x720
3.2.2) 960x540 for aspect ratios greater than or equal to 1.78:1.
e.g. 1920x1080 --> Crop(2,0,-2,-0) --> 1916x1080 --> 960x540
1280x720 --> Crop(2,0,-2,-0) --> 1276x720 --> 960x540

4) [ Codec ]
4.1) Video must be H.264/MPEG-4 AVC encoded with x264 8-bit.
4.1.1) Custom builds of x264 (e.g. x264-tMod, x264-kMod) are allowed and must be based off the x264 codebase.
4.2) x264 headers must remain intact and must not be modified or removed.
4.3) x264 must be kept up to date, with a maximum allowance, or grace period, of 60 days before groups are required to update to the latest revision.
4.3.1) The official x264 git repository is the only reference for determining the current revision: http://git.videolan.org/?p=x264.git;a=summary
4.3.2) The 60 day grace period must only be applied at pre time, not the tagged encoded date.
4.3.3) The grace period is only applicable to the revision preceding the latest update and does not reset active grace periods of preceding revisions.
e.g. 2016-01-01: Revision A is used.
2016-01-02: Revision B is committed, 60-day grace period begins for revision A.
2016-01-05: Revision C is committed, 60-day grace period begins for revision B.
2016-03-02: Revision A is no longer allowed, Revision B or C may be used.
2016-03-05: Revision B is no longer allowed, Revision C must be used.
4.4) Constant Rate Factor (--crf) must be used.
4.4.1) CRF values below 18 and above 23 are never allowed.
4.4.2) Justification must be listed in the NFO for the use of non-standard CRF values.
4.4.2.1) Groups are not required to follow non-standard CRF values used by another group.
4.4.2.2) It is suggested that if the average video bitrate exceeds 5000kb/s, a higher CRF value should be chosen, when possible.
4.5) Standard CRF values are as follows:
┌─────────────────┬───────┬─────────────────────── ────────────────────┐
│ Compressibility │ CRF │ General Examples │
├─────────────────┼───────┼─────────────────────── ────────────────────┤
│ High │ 18-19 │ Scripted, Talk Shows, Animation, Stand-Up │
│ Medium │ 20-21 │ Documentary, Reality, Variety, Poker │
│ Low │ 22-23 │ Sports, Awards, Live Events │
└─────────────────┴───────┴─────────────────────── ────────────────────┘
4.6) Settings cannot go below what is specified by preset (--preset) 'slow'.
e.g. --subme 7 or --me hex are not allowed.
4.7) Level (--level) must be '4.1'.
4.8) Colour matrix (--colormatrix) may be optionally set to 'bt709'.
4.9) Colour space (--output-csp) must be 'i420' (4:2:0).
4.10) Sample aspect ratio (--sar) must be '1:1' (square).
4.11) Deblocking (--deblock) must be used. Values used are left to the discretion of the group.
4.12) Keyframe interval (--keyint) must be at least 200, and at most 300.
4.12.1) It is recommended to let x264 decide which value to use, but 10*framerate is a good guideline (e.g. Film=240, PAL=250, NTSC=300).
4.12.2) For 50 or 60 FPS content, the maximum keyframe interval must be at least 200, and at most 600.
4.13) Minimum GOP length (--minkeyint) must be 30 or less.
4.13.1) It is recommended to let x264 decide which value to use, but 1*framerate is a good guideline (e.g. Film=24, PAL=25, NTSC=30).
4.13.2) For 50 or 60 FPS content, values of 60 or less must be used for the minimum GOP length.
4.14) Custom matrices are not allowed.
4.15) Zones (--zones) are not allowed.
4.16) x264 parameters must not vary within a release.
4.17) Optional tuning (--tune) parameters allowed are: 'film', 'grain' or 'animation'.
4.18) Suggested command line: x264 --crf ## --preset slow --level 4.1 --output out.mkv in.avs

5) [ Video / Resolution ]
5.1) Resolution must be mod 2.
5.2) Upscaling is not allowed.
5.3) Adding borders is not allowed.
5.4) Multiple video tracks are not allowed.
5.5) English spoken titles with foreign overlays, not intended by content creators (e.g. locations, on-screen text shown in another language) are not allowed, use INTERNAL.
5.5.1) This does not apply to opening titles or credits, but to relevant show content only.
5.6) Non-English spoken titles with hardcoded English subtitles must be tagged as SUBBED.
5.6.1) English spoken titles with hardcoded English subtitles present for English spoken scenes must be tagged as SUBBED.
5.6.2) English spoken titles with hardcoded Non-English subtitles present for English spoken scenes are not allowed, use INTERNAL.
5.6.3) Hardcoded subtitles added by content creators are exempt (e.g. Alien hardsubs, drunk talk hardsubs, hardsubs due to muffled mic).
5.7) Dupes based on resolution are not allowed.
5.7.1) Except in situations of releases with a different aspect ratio. The relevant tag must be used, and the reason mentioned in the NFO.
5.7.2) Releases which contain at least an additional 20 pixels worth of video on any side are not considered dupes. These releases must be tagged as WS or OM (open matte) and not proper, and the original release must not be nuked.
5.8) Black borders and anything (e.g. coloured borders, duplicate lines, dirty pixels, full-time tickers) that is not part of the video must be cropped.
5.8.1) Retention or removal of faded edges is left to the discretion of the group. Inclusion of faded edges is not a technical flaw, and cannot be propered.
5.8.1.1) Faded edges refer to a line of pixels which are of similar appearance to pixels' parallel to the video frame.
5.8.2) In the case of varying aspect ratios throughout the video, cropping must be done to the most common frame size (e.g. primary view of the pitch during sports, studio view during talk shows).
5.8.3) Cropping of letterboxed sources with hardcoded subtitles positioned within the black borders is left to the discretion of the group. Video may be left uncropped or cropped evenly both top and bottom to the widest frame without removing any subtitles.
5.8.3.1) Cropping out hardcoded subtitles entirely is allowed, only when they are not required, leaving any trace of subtitles or over-cropping actual picture to remove subtitles is considered to be a technical flaw.
5.8.4) Video may be over or under cropped by a maximum of 1px per side. Over or under cropping by more than 1px per side is considered a technical flaw.
5.9) 720p refers to a maximum display resolution of 1280x720.
5.9.1) 720i or 720p sources must be cropped as required and must not be resized.
5.9.2) 1080i or 1080p sources must be cropped and resized as required, with width at 1280 and/or height at 720.
5.10) Resized video must be within 0.5% of the original aspect ratio.
Original AR = (SourceWidth û [CropLeft + CropRight]) / (SourceHeight û [CropTop + CropBottom])
Release AR = EncodeWidth / EncodedHeight
AR Error % = [(Original AR û Release AR) / Original AR] * 100

Target resolution when resizing to maintain mod2 and reduce AR error:
TargetHeight = TargetWidth / [(SourceWidth û [CropLeft + CropRight]) / (SourceHeight û [CropTop + CropBottom])]
The correct mod 2 value can also be calculated from the ceiling of TargetHeight if the value is odd, and the floor of TargetHeight if the value is even.

6) [ Filters ]
6.1) IVTC or deinterlacing must be applied as required.
6.2) Only smart deinterlacers, such as Yadif or QTGMC, must be used.
6.2.1) FieldDeinterlace must not be used for deinterlacing.
6.3) Only accurate field matching filters, such as TIVTC or Decomb, must be used for inverse telecining (IVTC).
6.3.1) Filters included in MEncoder, MJPEG tools, libav, libavcodec or FFmpeg must not be used for IVTC.
6.3.2) Deinterlacing filters must not be applied to telecined sources as a method of inverse telecine.
6.4) Only sharp resizers, such as Spline36Resize, BlackmanResize or LanczosResize/Lanczos4Resize, must be used.
6.4.1) Simple resizers, such as Bicubic, PointResize or Simple, are not allowed.

7) [ Framerate ]
7.1) Constant frame rate (CFR) must be used.
7.1.1) Variable frame rate (VFR) methods are not allowed.
7.2) True 50 / 60 FPS video must be released at 50 / 60 FPS. True 25 / 30 FPS video released at 50 / 60 FPS is not allowed and considered a technical flaw.
7.2.1) Failure to apply a deinterlacer with bobbing enabled (e.g. QTGMC, Yadif(mode=1)) to double framerate (bob) 25i / 30i video back to true 50 / 60 FPS, is considered a technical flaw.
7.2.2) In cases of varying framerates of 25 / 30 FPS and true 50 / 60 FPS, the framerate of the main feature must be used (e.g. studio for talk shows, game coverage for sports).
7.2.3) In rare situations, 25 / 50 FPS sources must be restored to 24 or 30 FPS.
7.2.4) In rare situations, 30 / 60 FPS sources must be restored to 25 FPS.
7.3) Sources which contain footage at varying FPS throughout (hybrid sources) and may or may not require IVTC is left to the discretion of the group. The NFO must list a reason as to the final decision.
7.3.1) It is assumed that the majority of a title contains enough unique frames at 30,000/1,001 FPS to warrant a higher framerate. If it can be proven IVTC/decimating does not result in any loss of unique frames, this is considered a technical flaw.
7.4) Native and converted framerates refers to the standard in which the video was produced.
7.4.1) NTSC produced video is native to NTSC.
7.4.2) PAL produced video is native to PAL.
7.4.3) NTSC produced video that is broadcast in PAL is considered as converted video.
7.4.4) PAL produced video that is broadcast in NTSC is considered as converted video.
7.5) Converted video that has significant abnormalities (e.g. blended frames, jerky playback due to missing or duplicate frames) due to the conversion and cannot be reversed to the native format must be tagged as CONVERT.
7.5.1) Converted video which does not have significant abnormalities do not require the CONVERT tag and must not be nuked for the conversion.
7.6) Dupes based on framerate are not allowed, use INTERNAL.

8) [ Audio ]
8.1) Audio must be in the original format provided.
8.1.1) Transcoding audio is not allowed.
8.1.2) Audio which is broadcasted as AAC LATM or LOAS (e.g. Freeview) must have the headers converted to AAC ADTS without transcoding.
8.2) Multiple language audio tracks are allowed.
8.2.1) The default audio track must be the language intended for release (e.g. An English release containing English, German and Russian audio tracks, must have the default flag set on the English track).
8.2.2) The correct ISO 639 language code supported by MKVToolnix must be set for all secondary audio tracks, default may be left undefined.
8.2.2.1) In situations where the language is not supported by MKVToolnix, 'und' must be used.
8.3) If the original language of a title is not English:
8.3.1) An English dubbed track is allowed as a secondary audio track.
8.3.2) Releases containing only a dubbed audio track must be tagged as DUBBED.
8.4) Dupes based on multiple audio tracks or audio format are not allowed, use INTERNAL.

9) [ Glitches / Missing Footage ]
9.1) Where audio or video issues are unavoidable due to a live-broadcast or mastering issues, a release must not be nuked until a valid proper, repack or rerip which does not exhibit the same flaw is released.
9.2) Scrolling or other alert messages added by the broadcasting station (e.g. Weather or Amber alerts) appearing for a cumulative total of at least 30 seconds throughout the entire release is considered a technical flaw.
9.3) Video frame abnormalities (e.g. Abnormal snipes/pop-ups, banner advertisements that do not fade out entirely) as a result of broken splicing originating from the broadcasting station is considered a technical flaw.
9.4) Missing or repeated video footage without any loss of dialogue must be at least 2 seconds long at any one instance to be considered a technical flaw.
9.4.1) Except in situations where on-screen text is lost due to missing footage. Loss of on-screen text is considered a technical flaw.
9.4.2) Except in situations where minor missing or repeated video footage flaws are present throughout the majority of the release. Excessive flaws such as these are considered a technical flaw.
e.g. Video frame glitches occurring every 2 minutes throughout the entire release but only in the amount of 1 second per instance, is considered excessive and a technical flaw.
Repeated footage occurring every 5 minutes throughout the entire release but only in the amount of 1.5 seconds per instance, is considered excessive and a technical flaw.
Video frame glitches of 1 second per instance occurring 6 times throughout the entire release is NOT considered excessive or a technical flaw.
9.5) Audio which drifts at least 120ms at a single point or a total of at least 120ms between multiple points throughout the entire release is considered a technical flaw.
e.g. Sync drifting +120ms after 10 minutes is considered a technical flaw.
Sync drifting +80ms after 5 minutes, -40ms after 15 minutes, for a total of 120ms, is considered a technical flaw.
9.6) Glitches that occur in any audio channel present (e.g. L, R, C, SL, SR) are considered a technical flaw.
9.6.1) Glitches are defined as, but not limited to: missing dialogue, repeated dialogue, inability to understand dialogue, bad channel mix, large gaps within playback, persistent clicks/pops/muted/echoing/muffled audio.

10) [ Editing / Adjustments ]
10.1) Minor adjustments to video or audio tracks (e.g. duplicating or removing frames, channel count) in order to prevent issues with playback or sync is allowed.
10.2) Multi-episode releases with no clear delineation between episodes (e.g. end credits) must not be split.
10.3) Including previously-on footage is optional, but recommended.
10.4) Including upcoming/teaser/scenes from the next episode footage found at the conclusion of an episode is optional, but recommended.
10.5) Credits must be included if they contain unique show content. (e.g. bloopers, outtakes, dialogue, unique uninterrupted soundtrack, in memory of message)
10.5.1) End credits must only be considered optional if they do not contain unique show content (e.g. regular plain credits with or without promos), and may be removed at the discretion of the group.
10.5.2) A simulcast which does not contain unique content in the credits cannot be propered from a primary broadcaster which contains unique content, use EXTENDED.
10.5.3) If a different broadcaster or re-broadcast of a show contains unique content not present in the original broadcast, the first release cannot not be propered, use EXTENDED.
10.5.3.1) In situations where a unique uninterrupted soundtrack is the only additional unique content included in the credits, use of EXTENDED is not allowed, use INTERNAL.
10.5.3.2) It is recommended, but not required, to include unique content included in the credits that was omitted from the original broadcast.
10.6) Inclusion of bumper segments, 5-20 second segments containing coming up/preview/backstage footage (e.g. SNL, Cops) is optional and at the discretion of the group.
10.6.1) In situations where bumper segments have been omitted in the first release, a secondary release which includes all bumper segments is allowed and must be tagged as UNCUT.
10.6.2) In situations where bumpers are included:
10.6.2.1) All bumper segments must be free of any technical flaws.
10.6.2.2) All bumper segments must be included, missing any bumper segment is considered a technical flaw.
10.6.3) Small segments containing actual show content, not containing coming up/preview/backstage footage, are not considered as bumper segments (e.g. Talking Dead, Comic Book Men, Portlandia).
10.7) Any unrelated video (e.g. commercials, rating cards, viewer/content warnings), regardless of duration (e.g. 1 faded/half opacity frame or 10 seconds) must be completely removed.
10.7.1) Content warnings can be retained or removed at the discretion of the group, except when they are intended by content creators and must be retained (e.g. Tosh 0, Robot Chicken, South Park, Law and Order SVU).
10.7.1.1) This does not apply to scripted or animation content. Content warnings not intended by content creators must always be removed in these cases.
10.7.1.2) Following the opening segment for non-scripted and non-animation content, all content warnings which precede each segment must be removed.
10.7.2) Sponsorship advertisements which are integrated into show content and cannot be removed (e.g. Jimmy Kimmel, Talking Dead, Deadliest Catch) are exempt.
10.7.3) Show transition cards appearing at the start or end of segments on some broadcasters (e.g. Seven, Channel 4, ITV1) can be retained or removed at the discretion of the group.
10.7.4) Opening and closing interleaves (e.g. HBO opening animation, ... presents, this has been a ... production, ... original series) can be retained or removed at the discretion of the group, except when they contain show content and must be retained.
10.8) Any unrelated audio (e.g. alerts, commercials), regardless of duration (e.g. 100ms or 10 seconds) must be completely removed.
10.8.1) Except when a broadcaster (e.g. ABC) splices unrelated audio into the beginning of a segment, that does not result in sync issues.

11) [ Subtitles ]
11.1) Subtitles for English spoken titles without foreign dialogue are optional, but encouraged.
11.2) English spoken titles with foreign dialogue must include a separate subtitle track for forced subtitles.
11.2.1) Foreign dialogue subtitle tracks must be set as forced and it is considered a technical flaw if not done correctly.
11.2.2) In situations where the source video stream contains hardcoded subtitles for English spoken titles with foreign dialogue, a separate subtitle track for the forced subtitles is not required.
11.2.3) If a broadcaster which is primarily English spoken (e.g. FOX, BBC) does not contain hardcoded subtitles for scenes with foreign dialogue in the video stream, then forced subtitles are not required but recommended.
11.3) Non-English spoken titles without hardcoded subtitles must include an English subtitle track set as forced before it is considered to be an English release.
11.4) Subtitles must be extracted from the original source.
11.4.1) Fan-made or custom subtitles are not allowed.
11.5) Adjustments and edits (e.g. adjusting timecodes, fixing grammar, spelling, punctuation errors) may be made to subtitle tracks.
11.6) Subtitles must be muxed into the final MKV in text based format, i.e. SubRip (.srt) or SubStation Alpha (.ssa/.ass).
11.6.1) Subtitles must not be set as default or forced unless otherwise specified.
11.6.2) The correct ISO 639 language code supported by MKVToolnix must be set for all subtitle tracks.
11.6.2.1) In situations where the language is not supported by MKVToolnix, 'und' must be used.
11.7) External subtitles located in 'Subs' directories are not allowed.
11.8) Dupes based on subtitles are not allowed, use INTERNAL.

12) [ Container ]
12.1) Container must be Matroska (.mkv). MKVToolnix is the recommended muxer.
12.1.1) Custom muxing tools are allowed. However, the output must adhere to the Matroska specifications and must retain identical compatibility with demuxers as files created with MKVToolnix.
12.2) Support for file streaming and playback from RAR is mandatory.
12.3) Matroska header compression must not be enabled.
12.4) Chapters are allowed, and recommended for long events (e.g. long poker games to mark each round).
12.5) Watermarks, intros, outros or any other forms of defacement in any track (e.g. video, audio, subtitles, chapters) are not allowed.

[leghorn]

@Melan:

Isn't this warez related?

[jagabo]

The x264 settings used in that particular video are about:

--preset=slow --tune=animation --ref=4 --bframes=3 --vbv-maxrate=6144 --vbv-bufsize=15360

And it was encoded as 2-pass VBR with an average bitrate of 3072 kbps.

But just because a particular video gives good results at that bitrate doesn't mean all videos will look as good at that bitrate. Different videos require different bitrates.