1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
                                                                                
                   ۰                                                          
                   ۰                                                         
                    ۰                                                        
                     ۰                                                     
                      ۰                                                   
                       ۰                         ۰                       
                        ۲                                                 
                         ۲                      ۲                          
                          ۲                   ۲۱                           
                           ۲                 ۲                             
                            ۲               ۲                              
                            ۲            ۲۲                               
                             ۲          ۲۰                                
                              ۲        ۲                                  
                               ۲      ۲                                   
                                                                        
                             ۲۰                              
                           ۲    ۲                       
                         ۱۲                
                  ۲                       ۲           
             ۲                             ۲        
         ۲              ۲۲    
      ۲           ۲  ۲   
   ۱        ۲            ۰    
  ۱     ۲       ۲۰      ۰۲۰ 
  ۰ ۱     ۰۲۲۲۰        ۰۲۲۱ 
  ۰  ۰ ۰  ۰۰۲۲۲۰ ۰        ۱  
     ۰ ۰  ۰۰۲۱          ۱   
     ۲  ۰ ۰۰۲۱ ۰     ۰۲۰   
     ۲ ۰۰۰۲۱    ۰  ۲۲۲    
     ۲ ۰۰۰۲۱ ۰     ۲     
  ۰ ۰۰۰۰۲۱     ۱      
   ۰  ۱۰۰۲۱ ۰  ۰ ۰۲      
   ۲  ۱۱۰۰۲۱ ۰     ۲       
      ۱۱۰۲۱     ۲ ۲۲        
   ۰  ۱۱  ۲۱        ۱۲۱۲        
    ۲   ۲۱۲۲  ۲          
        ۱۱۲۲۲۰          
     ۱    ۲۲۰۲           
         ۲۱           
      ۱   ۰۲            
            ۲۲۲۱            
              ۲                     ۲۲             
        ۲                                           ۱۰            
         ۱                                      
         ۱        ۲۰             
           ۱۲۱              
            ۲۲                         
                                                                                
ͻ
                      The SDTV Release Council Presents                       
        The 2011 x264 SDTV Releasing Standards [TVx264SD11 - DRAFT 1]         
                      2011-01-01 00:00:00Z (1293840000)                       
                                                                              
 TVx264SD11 was signed by the following groups:                               
                                                                              
 Repack reason: IKEA products were chosen to avoid the appeal to authority    
 fallacy. Hai ZoNeNET!                                                        
ͼ


 Contents                                                             Line # 


 1. Preamble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  92
 2. What's New in TVx264SD11 . . . . . . . . . . . . . . . . . . . . . . . . 105
 3. General Notes  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
    3.1 Previously On & Credits  . . . . . . . . . . . . . . . . . . . . . . 187
 4. Source Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
 5. Release Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
 6. Video  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
    6.1 Dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
 7. Audio  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
 8. Video Codec and Container  . . . . . . . . . . . . . . . . . . . . . . . 406
 9. Subtitles  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
10. Packaging and Naming . . . . . . . . . . . . . . . . . . . . . . . . . . 481
11. Propers  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
12. Internals  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574


 List of Tables                                                       Line # 


1. Sample Reasons when Propering a Nukeable XviD . . . . . . . . . . . . . . 164
2. Source Definitions for SD Releases  . . . . . . . . . . . . . . . . . . . 217
3. Valid Release Sizes for SD Releases . . . . . . . . . . . . . . . . . . . 264
4. Common Resolutions for SD Releases  . . . . . . . . . . . . . . . . . . . 353


 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 misrepresented 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
resolution 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] because it is designed for the
compression of general purpose audio. Encoding audio at a lower bitrate without
sacrificing quality allows for a higher video bitrate. The format is already
supported on WD TV[2], Popcorn Hour[3], Mvix[4] and "is expected to obtain
widespread adoption with a major backing by many hardware based chip
manufactures [sic] and with the release of Google's new mobile Android platform
and 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.

[1]: http://preview.tinyurl.com/33wlpz3
[2]: http://preview.tinyurl.com/2wjmc4u
[3]: http://preview.tinyurl.com/22qfm8l
[4]: http://preview.tinyurl.com/3xecxaz
[5]: http://preview.tinyurl.com/2vtz9yf


 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 modification 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 release
       (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          

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 circumstance 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
decision 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 single release. Directory naming
for this will be in the following format:

               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 promos 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. 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 x 480/576   
         and a video bitrate >= 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 release 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.

8. Releases can only dupe or proper releases of the same language (e.g. a
SWEDISH release will not dupe an existing English release 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 target 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.

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. FieldDeinterlace,
BlendFields) are banned. Filters such as Yadif or LeakKernelDeint are
recommended.

7. Resizers that produce bad quality results (e.g. PointResize, BicubicResize)
are banned. A sharp resizer must be used (e.g. Lanczos(4)Resize,
Spline(16/36/64)Resize, etc.).

8. Group watermarks are banned, with the exception of blurring potential
security risking watermarks (e.g. VariableBlur[6], MedianBlur[7], 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]: http://preview.tinyurl.com/2c5qhn4
[7]: http://preview.tinyurl.com/26wus6h

 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 x 352 
                                     640 x 352 
                              Ĵ
                               4:3   512 x 384 
                                     576 x 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 oggenc2[8] is recommended for most releases.

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 technically 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]: http://preview.tinyurl.com/ya9glra


 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).

17. Adaptive DCT must not be disabled (enabled by default).

18. Direct MV prediction mode must be set to auto (--direct auto; default is
spatial).

19. Keyframe Interval must be between 200 and 300. The recommended 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 subtitles 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.

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 language 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 Sample directory if
the release being propered has not already been nuked.

4. Propers are not allowed after a repack has been released; however, 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 internal.

8. Propers based on source parameters (e.g. number of commercials, frame rate,
audio channels or bitrate, etc.) are forbidden.


 12. Internals                                                                


1. All internals must conform to TVx264SD11 rules, with the exception 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 protected 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 INTERNAL.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.

ͻ
  The 2011 x264 SDTV Releasing Standards is best viewed with Terminal font.   
ͼ