The 2011 x264 SDTV Releasing Standards

[TVx264SD11 — DRAFT 1]
The SDTV Release Council

2011-01-01 00:00:00Z (1293840000)

TVx264SD11 was signed by the following groups:

BESTÅ CHOSiGT FANTASTiSK iKEA KASSETT KONCiS KNYCK
NYSNÖ OMTYCKT SKÄRPT TOBO

Contents
1 Preamble 2

2 What’s New in TVx264SD11 2

3 General Notes 3
3.1 Previously On and Credits . . . . . . . . . . . . . . . . 4

4 Source Notes 5

5 Release Sizing 6

6 Video 6
6.1 Dimensions . . . . . . . . . . . . . . . . . . . . . . . . 8

7 Audio 8

8 Video Codec and Container 9

9 Subtitles 10

10 Packaging and Naming 10

11 Propers 11

12 Internals 12

1
 13 Acknowledgements 12

List of Tables
1 Sample Reasons when Propering a Nukeable XviD . . 3
2 Source Definitions for SD Releases . . . . . . . . . . . 5
3 Valid Release Sizes for SD Releases . . . . . . . . . . . 6
4 Common Resolutions for SD Releases . . . . . . . . . 8

1 Preamble
The SDTV Release Council was formed in 2010 out of necessity and
oppression from biased nukers and a cartel of TV groups which misrep-
resented the majority of groups that desired a ruleset. Unwritten rules
yielded obscurity and obscurity gave them power. The SDTV Release
Council intends to regulate and standardise the SD releases within the
TV scene in order to abolish some of the outmoded quality-inhibiting
restrictions based on the preferences and assumptions of nukers. This
official document will cover the rules and guidelines for only SD reso-
lution content, excluding sports releases.

2 What’s New in TVx264SD11

The most significant changes in this ruleset is the advance in codecs
with AVC replacing XviD and Vorbis replacing MP3. Although AVC
and Vorbis do not provide the same level of compatibility with older
standalone players, there have been large increases in support by most
major manufacturers and ultimately we feel it is better to push forward
with better quality than to live in the past.
We chose Ogg Vorbis over MP3 or AAC for several reasons. It
tends to sound better than MP3 at lower bitrates (∼ 64kbit/s)1 be-
cause it is designed for the compression of general purpose audio. En-
coding audio at a lower bitrate without sacrificing quality allows for
a higher video bitrate. The format is already supported on WD TV2 ,
Popcorn Hour3 , Mvix4 and “is expected to obtain widespread adop-
tion with a major backing by many hardware based chip manufactures
[sic] and with the release of Google’s new mobile Android platform and
1
See http://preview.tinyurl.com/33wlpz3.
2
See http://preview.tinyurl.com/2wjmc4u.
3
See http://preview.tinyurl.com/22qfm8l.
4
See http://preview.tinyurl.com/3xecxaz.

2
 Google TV by the year 2011.”5 Lastly, unlike MP3 and AAC, Vorbis
is open and doesn’t have intellectual property restrictions that might
hamper its implementation in hardware players.

3 General Notes
1. This standard applies to and will be enforced for all English
releases. Groups that release non-English releases may use this
ruleset if it is agreed upon by the groups of their language and if
there is not a language-specific ruleset that explicitly supersedes
this ruleset.
2. This is a draft of the ruleset and is open to debate and modifi-
cation in its corresponding channel. However, we believe that it
is complete enough for groups to begin using it and for it to be
enforced. For those that are (for whatever reason) unable to join
talks, releasing a well-justified rebuttal is strongly encouraged.
Any post-modifications will be only enforced in the next version
of the ruleset.
3. XviD does not dupe x264. x264 dupes XviD. Exceptions:
(a) The x264 release has a better source than the source of the
XviD release (e.g. HDTV.x264 > PDTV.XviD).
(b) The x264 release is a valid proper of a nukeable XviD re-
lease (e.g. PROPER.HDTV.x264 > nuked HDTV.XviD).
An x264 proper of an XviD release is only valid when the
XviD release is nukeable for a general technical flaw that is
not particular to the video or audio format. Since there are
no official written rules for TV-XViD, please use discretion
and common-sense when propering. Below is a sample of
reasons for valid and invalid x264 propers of nukeable XviD
releases.

Valid Invalid
has.commercial gmc.used
no.ivtc custom.pixel.shape
out.of.sync.throughout bad.audio.bitrate
missing.dialogue oversized

Table 1: Sample Reasons when Propering a Nukeable XviD

5
See http://preview.tinyurl.com/2vtz9yf.

3
 4. Groups that claim to have an eye for quality should be pushing
towards the format that has improved on encoding efficiency, can
produce relatively higher quality at the same or lower bitrate
and is rapidly gaining hardware support. It is expected that all
groups that release SDTV will eventually use x264 so we may
then ban XviD in a future revision.
5. Under exceptional circumstances, the council has the power to
override a global (un)nuke put in place by a nukenet. Such a cir-
cumstance would occur for example if a release is being contested
within a nuke war. The release in question may be brought to
the attention of the council who may then decide on the validity
of the release. If the council does decide on the matter, that de-
cision is final and should be treated as if it were written within
the standard itself. If a council decision is made, the release shall
be nuked or unnuked with “council.decision reason” as the
reason.
6. Episodes that air back-to-back without a natural break such as
full credits or commercials in between must be encoded as a sin-
gle release. Directory naming for this will be in the following for-
mat: Series.Title.S##E##-##.EXTRA.TAGS.SOURCE.x264-GRP

3.1 Previously On and Credits

1. Any previously on footage should be included in the release, but
it is not required. No release may be propered for glitches in or
missing portions of previously on footage.
2. Credits that are overlaid on actual show content are required to
be included.
3. Credits that run cleanly, i.e. with no modifications such as pro-
mos for upcoming shows, are encouraged but not required.
4. Credits run with promos for other shows are not recommended,
but may optionally be included.

4
4 Source Notes

Source Definition
WebRip Web stream that is officially available to a limited
region or for a limited time (excluding P2P, etc.).
DSR Standard Definition stream that does
not meet the PDTV criteria.
PDTV Standard Definition stream with a resolution of
704/720 × 480/576 and a video bitrate of ≥
1.5 mbps if MPEG4 or ≥ 3 mbps if MPEG2.
WS Stream with an aspect ratio > 1.70.
HDTV High Definition non-upscaled 720p/1080i/p stream.

Table 2: Source Definitions for SD Releases

1. The source MUST be digital (the raw transport stream) and

must not be passed through analog devices such as capture cards
or slingboxes. Examples of digital sources include USB, Firewire,
or Ethernet from a receiver, or using an ATSC, QAM, or DVB
tuner.
2. HDTV > WS.PDTV > PDTV > WS.DSR > DSR > WebRip
3. Releases that are of lower quality than an already available re-
lease are considered dupes (e.g. PDTV dupes WS.PDTV, but
HDTV does not).
4. A WebRip may be released only when: (1) the TV rip was not
released and (2) the web stream is only available to a limited
region or for a limited time.
5. If a live event (e.g. concert, awards show, etc.) is interrupted, the
ripper must include the approximate total length of the removed
interruptions within the NFO.
6. Releases with a questionable source may be pre-nuked for up to
48 hours after pre with the reason “source.sample.requested” if
there is legitimate reason to do so (e.g. suspicion of mislabeled
source). The release group then has 48 hours to provide a sample
(at least 10 seconds in length) of the source before the release
becomes properable.
7. Releases with non-English audio for the majority of the duration
must be tagged with the language used.

5
 8. Releases can only dupe or proper releases of the same language
(e.g. a SWEDISH release will not dupe an existing English re-
lease and cannot proper it).

5 Release Sizing

Runtime Size (MiB)

00:12:00–00:19:00 139
00:16:00–00:26:00 186
00:24:00–00:38:00 279
00:33:00–00:51:00 373
00:49:00–01:17:00 559
01:06:00–01:42:00 746
01:39:00–02:34:00 1119
02:12:00–03:25:00 1493

Table 3: Valid Release Sizes for SD Releases

1. Runtimes not listed in the above table must:

• be scaled to meet a bitrate of between 928kbps and 1472kbps
• have a file size equal to a division or multiple of a division of
4479MiB, e.g. 4479MiB ÷ 3 = 1493MiB × 2 = 2986MiB.
2. If the length of the release is nearing the recommended maximum
length, the ripper can opt to use the next recommended size in
the interests of quality.
3. CD sizes are long since obsolete and are forbidden.
4. Splitting a release into multiple files is forbidden.
5. A release may be a maximum of 2MiB oversized.
6. A release may be a maximum of 4MiB undersized when the tar-
get size is less than 559MiB, or a maximum of 8MiB when the
target size is 559MiB or above.

6 Video
1. The appropriate deinterlace and IVTC methods must be used
when necessary.

6
 2. Duplicate frames must be removed unless required to maintain
audio sync.
3. 50/60fps sources must be dropped to 25/30fps.
4. PAL material that has been broadcast in another region may be
converted back to the original frame rate if there is no quality
loss suffered as a result (e.g. a 60fps NTSC source of a video
broadcast filmed at 50fps may be converted back to 25fps with
a filter such as rePal).
5. Reconverting the frame rate of an interlaced source to a higher
frame rate (e.g. a PAL 25fps interlaced source to 29.97fps) is
not allowed if the source would have to have a bob deinterlace
technique applied to achieve the desired frame rate.
6. Deinterlacers that produce bad quality results (e.g. FieldDein-
terlace, BlendFields) are banned. Filters such as Yadif or LeakKer-
nelDeint are recommended.
7. Resizers that produce bad quality results (e.g. PointResize, Bicu-
bicResize) are banned. A sharp resizer must be used (e.g. Lanc-
zos(4)Resize, Spline(16/36/64)Resize, etc.).
8. Group watermarks are banned, with the exception of blurring
potential security risking watermarks (e.g. VariableBlur6 , Medi-
anBlur7 , etc.).
9. Imperfections lasting the majority of the release may be dealt
with by the group as long as there is minimal impact on viewing
quality (e.g. cropping out a news ticker placed at the bottom of
the video frame by the broadcasting network).
10. Negligible video glitches do not warrant a nuke if they occur
between scene changes or are otherwise known to be the fault of
the broadcaster.
11. Network inserted commercials must be removed.
12. The video must not have local overlays (e.g. weather, breaking
news, Amber Alerts, etc.) that exceed five minutes in length,
cause a change in video format (i.e. drop to PDTV on an HDTV
release), or cause loss of dialogue or video. The proper release
must be completely free of such overlays to be considered valid;
merely having less spam is not enough.
13. Any other modification of the original content prior to or after
encoding is strictly forbidden (e.g. intros, outros, betweenos).
14. Pixel shape must be square.
6
See http://preview.tinyurl.com/2c5qhn4.
7
See http://preview.tinyurl.com/26wus6h.

7
 6.1 Dimensions
1. Width:
• 576–672 pixels for sources with an AR of 1.70-3.00.
• 512–672 pixels for sources with an AR of 1.00-1.69.
2. Common resolutions include:

16:9 624 × 352

640 × 352
4:3 512 × 384
576 × 432

Table 4: Common Resolutions for SD Releases

3. Upscaling must be kept at a minimum for low resolution sources

(typically 480i) and is banned for all higher resolution sources.
4. Black borders must be cropped to their maximum. In the event
of changing aspect ratios, the cropping must be tailored towards
the widest frame within the release.
5. SD sources may be overcropped by a maximum of 2px. HD
sources may be overcropped by a maximum of 4px.
6. The aspect ratio must be within 3% of the source display aspect
ratio.
7. Height and width must be MOD16.

7 Audio
1. Must be VBR Ogg Vorbis or the original untranscoded stream.
2. The original stream should only be used at the ripper’s discretion
and must provide a valid reason for use within the NFO.
3. Audio sources with more than two channels (e.g. Dolby Digital)
must be downmixed to stereo.
4. Ogg must be encoded VBR with a target of between 64kbps
and 128kbps for multichannel sources and between 48kbps and
96kbps for mono sources. “-b 64” on encoders such as oggenc28
is recommended for most releases.
8
See http://preview.tinyurl.com/ya9glra.

8
 5. If the source bitrate is lower than 64kbps (multichannel) or
48kbps (mono), the target bitrate must be the highest possible
bitrate and a notice should be placed in the NFO file.
6. Encoding a multichannel source to mono or a mono source to
stereo is forbidden.
7. Resampling is forbidden.
8. Audio that is more than 100ms out of sync is considered techni-
cally flawed.
9. Audio must not have severe drops resulting in the inability to
understand material dialogue.
10. Multiple audio tracks are forbidden.
11. Dupes based on audio format are forbidden.

8 Video Codec and Container

1. Must use x264 (no older than 30 revisions).
2. Must use MKV as the container.
3. Encoding must be 2-pass VBR.
4. Target bitrate must be a minimum of 928kbps. If, for whatever
reason, this cannot be achieved then a reasonable justification
must be included in the NFO and a source sample must be placed
in the Sample directory for issues relating to the source.
5. AVC Profile must be Main Profile (3.0) or higher.
6. Subpixel Refinement must be 6 or 7 (--subme 7; default is 7).
7. Motion estimation method must be hex or higher (--me hex;
default is hex).
8. Trellis must be 0 or 1 (--trellis 1; default is 1).
9. Macroblock options must be default or “all” (--partitions all).
10. Reference Frames must be 3 (--ref 3; default is 3).
11. Adaptive Quantization must be used (enabled by default).
12. CABAC encoding must be used (enabled by default).
13. Deblocking must be used (enabled by default).
14. B-frames must be 3 or higher (--bframes 3; default is 3).
15. B-pyramid must be normal (--b-pyramid normal).
16. Adaptive b-frames must be used (enabled by default).

9
17. Adaptive DCT must not be disabled (enabled by default).
18. Direct MV prediction mode must be set to auto (--direct spatial;
default is spatial).
19. Keyframe Interval must be between 200 and 300. The recom-
mended setting is --keyint 10 × FPS.
20. Min GOP Size must be between 20 and 30. The recommended
value is the rounded output FPS (--min-keyint FPS).

9 Subtitles
1. Subtitles are optional.
2. VobSub (.sub and .idx) or SubRip (.srt) are the preferred
formats.
3. Subtitles must be muxed into the MKV. “Subs” directories are
forbidden.
4. Out-of-sync subtitles do not warrant a nuke (e.g. realtime, pre-
prepared, scrolling or otherwise broadcaster-delayed subtitles).
5. Removing official broadcast-sponsor advertisements from subti-
tles is optional.
6. Group watermarks in subtitles are strictly forbidden.
7. Hard subtitles will only be allowed when the source exhibits such
subtitles in the picture itself.
8. Release muxed with subs must still adhere to the aforementioned
filesizes.
9. Multi-language subtitles cannot be used as a basis for a dupe.

10 Packaging and Naming

1. Releases must be packaged within a RAR archive with M0 (store)
compression.
2. RAR archives must be split into 15 or 20 MB parts (where 1 MB
is defined as 1,000,000 bytes). 50 MB and 100 MB parts are
allowed when packaging files larger than 1119 MiB. RAR sets
may not be larger than 101 RARs when using old-style volume
names.
3. Inclusion of RAR recovery records is recommended.
4. Encryption or password protection is strictly forbidden.

10
 5. An SFV is required for each set of RAR files.
6. All filenames must be unique to avoid dupes.
7. An NFO file is required and should contain the following:
• Release Name
• Group Name
• Release Date
• Video Information (Codec, Bitrate, Resolution, etc.)
• Audio Information (Codec, Bitrate, Channels, etc.)
8. Release directories should generally be named like the following
example in order to maintain consistency within the scene:
• Series.Title.S##E##.EXTRA.TAGS.SOURCE.x264-GRP
• Variety.Show.YYYY.MM.DD.Guest.EXTRA.TAGS.SOURCE.x264-GRP
9. Releases may use the PREAIR tag if they are pred before the air
date in the country of origin, but may not be nuked for missing
it. Nukers should use discretion before nuking a release that
appears to have the wrong date as many taped shows are pred
in advance of airing in the country of their origin.
10. Releases must contain a sample between 40–90 seconds long
taken directly from the complete release content. The sample
must have a unique filename and must be placed within the
“Sample” directory.
11. Using a renamed RAR as a Sample is forbidden.
12. The following additional tags are considered valid: PROPER, REPACK,
RERIP, REAL, READNFO (with discretion), INTERNAL, UNCUT, SUBBED
(i.e. hardsubbed), LD, PREAIR, DIRFIX, NFOFIX, SAMPLEFIX.
13. Releases with non-English audio must be tagged with the lan-
guage used (e.g. SWEDISH, not SVENSKA) and appended with the
LD tag if the language is dubbed (e.g. SWEDISH.LD).

11 Propers
1. Propers are permitted in the case of previous technical flaws.
2. Propers must state the proper reason and which release is being
propered within the release NFO.
3. Propers must provide proof of technical flaws within the Sam-
ple directory if the release being propered has not already been
nuked.

11
 4. Propers are not allowed after a repack has been released; how-
ever, flawed repacks may be propered.
5. Propers based on audio codec are forbidden.
6. Propers based on video codec are forbidden.
7. Propers based on ripper decisions (e.g removal of pre-/post-show
footage, network-specific footage, etc.) are forbidden. Use inter-
nal.
8. Propers based on source parameters (e.g. number of commer-
cials, frame rate, audio channels or bitrate, etc.) are forbidden.

12 Internals
1. All internals must conform to TVx264SD11 rules, with the ex-
ception of minor known technical issues and non-conforming sizes
or audio codecs. Using the INTERNAL tag to try and protect a
severely flawed release from nukes is forbidden.
2. The following audio codecs may be used for internals: AC3, MP2,
Ogg Vorbis, or MP3. Releases using other codecs are not pro-
tected from nukes by the INTERNAL tag.
3. Using INTERNAL.DIRFIX as a cheap attempt at avoiding a
nuke is forbidden. If the release is technically flawed, it is still
deemed nukeable both before and after an attempted INTER-
NAL.DIRFIX and the DIRFIX shall be nuked for fix.for.nuke.

13 Acknowledgements
The authors of this ruleset wish to gratefully acknowledge the authors
of TVx2642k8, TVX2K7, TXSRS11 for their dedication and arduous
work of which many of these rules and guidelines were based upon.
Special thanks to the reviewers and the real signers of this ruleset.

12