[HD 1080p24 Challenge] MPEG2, VC-1 and H264 with real uncompressed source [Archive]

View Full Version : [HD 1080p24 Challenge] MPEG2, VC-1 and H264 with real uncompressed source

Sagittaire

1st August 2007, 13:06

~ HD Benchmark Challenge ~

You think that your standard is the best : prove that ... !!?

A - Introduction

The purpose of this challenge is to determine which is the best codec format encoding for objective test.
HD-DVD & BD can use MPEG2, H264 and VC-1 for video codec.

B - Rules

Rule 1 : Source

Uncompressed source is available Here (http://orange.blender.org/blog/original-lossless-source-available/) for reproduce the test.
Open source Elephant Dream movie, video 1920*1080 PNG lossless, audio 5.1 Flac lossless, 15 691 frames

Rule 2 : Pre-process and encoding

You must use this avisynth script for make encoding:

Source=ImageSource("C:\LossLess\images\%05d.png", start=1, end=15691, fps=23.976)
Source=ConvertToYV12(source, matrix="Rec709")
return source

Other pre-process are not autorized. It's possible to propose example with high quality pre-process (like sharp ... ect) but just for demonstration and not for this challenge.

Video Stream must be like HD-DVD/BD compliant stream. You can use all the compliant audio codec and all the compliant bitrate for audio. This test is just video challenge and not audio challenge. All the video stream must be compliant with these setting:

MPEG2 Encoding
Profil & Level: MP@HL except specific restrictions
Max GOP lenght: 14 frames
Maximum bitrate: 20.0 Mbps, 24.0 Mbps and 28.0 Mbps
Buffer size: 9781 Kbits for principal HD video stream
Horizontal Vector Range: +/- 1024 pixels
Vertical Vector Range: +/- 128 pixels
Other Restrictions Setting: max adaptative GOP at 14, max adaptative bframe at 7

VC-1 Encoding
Profil & Level: AP@L3 except specific restrictions
Max GOP lenght: 14 frames
Maximum bitrate: 20.0 Mbps, 24.0 Mbps and 28.0 Mbps
Buffer size: 14745 Kbits for principal HD video stream
Horizontal Vector Range: unlimited
Vertical Vector Range: unlimited
Other Restrictions Setting: max adaptative GOP at 14, max adaptative bframe at 7

H264 Encoding
Profil & Level: HP@L4.1 except specific restrictions
Max GOP lenght: 14 frames
Maximum bitrate: 20.0 Mbps, 24.0 Mbps and 28.0 Mbps
Buffer size: 14745 Kbits for principal HD video stream
Horizontal Vector Range: +/- 1024 pixels
Vertical Vector Range: +/- 512 pixels
Other Restrictions Setting: max adaptative GOP at 14, max adaptative bframe at 7,
Max reference at 4, Max breference at 3, no film grain modeling

Rule 3 : Bitrate and Max Bitrate

You must use these bitrate/size for encoding:

HD-DVD with "super bitrate" video stream and simple HDDVD authoring:
18 Mbps (Max at 28.0 Mbps) for video stream with +/- 0.5 % for bitrate tolerance
HD-DVD with "medium bitrate" video stream and standard HDDVD authoring:
12 Mbps (Max at 24.0 Mbps) for video stream with +/- 0.5 % for bitrate tolerance
HD-DVD with "low bitrate" video stream and standard HDDVD authoring:
6 Mbps (Max at 20.0 Mbps) for video stream with +/- 0.5 % for bitrate tolerance

NB: we can use HD-DVD structure too on simple DVD DL 12 cm at 8.5 GB

Rule 4 : Visual Tests

Here you can find encoding elementary stream for subjective test ... try to find yourself the best visual quality:

HD-DVD & BD MPEG2 at 18 Mbps: not available
HD-DVD & BD MPEG2 at 12 Mbps: not available
HD-DVD & BD MPEG2 at 6 Mbps (http://jfl1974.free.fr/HDDVD/MPEG2/6Mbps/MPEG2_6Mbps.m2v)

HD-DVD & BD VC-1 at 18 Mbps: not available
HD-DVD & BD VC-1 at 12 Mbps: not available
HD-DVD & BD VC-1 at 6 Mbps (http://jfl1974.free.fr/HDDVD/VC1/6Mbps/VC1_6Mbps.vc1)

HD-DVD & BD H264 at 18 Mbps (http://jfl1974.free.fr/HDDVD/H264/18Mbps/)
HD-DVD & BD H264 at 12 Mbps (http://jfl1974.free.fr/HDDVD/H264/12Mbps/)
HD-DVD & BD H264 at 6 Mbps (http://jfl1974.free.fr/HDDVD/H264/6Mbps/)

Rule 5 : Metrics Tests

SSIM (YV12): IMO the best metric. it uses some HVS properties but not all ...
PDF description for VSSIM (http://www.cns.nyu.edu/~zwang/files/papers/vssim.pdf)

Overall PSNR (YV12): Very good metric test, particullary for Rate Control Quality test ...
MSE = Sum t = 1 -> NFrame Sum x = 1 -> width Sum y = 1 -> height (F'(x,y,t)-F(x,y,t))² / (NFrame*width*height)
Overall PSNR = 10 * Log ( 255² / MSE)

Average PSNR (YV12):The worse metric test but Frame PSNR graph is very good to compare RC strategy ...
MSE = Sum x = 1 -> width Sum y = 1 -> height (F'(x,y,t)-F(x,y,t))² / (width*height)
Average PSNR = Sum t = 1 -> NFrame 10 * Log ( 255² / MSE) / Nframe

SSIM vs PSNR

"For a given reference video and a given compressed video, it is meant to compute a quality metric, based on perceived visual distortion. Unlike the well-known PSNR measure, it's not purely mathematical, and should correlate much better with human vision."

"A higher MSE (and so lower PSNR) should mean that the compressed clip is a worse image but MSE and PSNR are flawed in this respect as numerous tests have shown. However with SSIM, according to tests carried out on the VQEG dataset, a higher Q (SSIM value) has a much better relation to the visual quality of the compressed clip. Despite this, bear in mind the SSIM metric still isn't perfect."

Here (http://multimediacom.free.fr/Download/SSIM.rar) last AviSynth plugin for VSSIM in YV12

Average PSNR vs Overall PSNR

It's easy to increase artificially Average PSNR with Rate Control tweak. In certain case CBR (0% for variability) will be better than real VBR (100% for variability or constant quant). It's generaly not possible with Overall PSNR. Overall PSNR is very good to test Rate Control quality. If difference between Average PSNR and Overall PSNR is very high, "local quality difference" (difference between Pframe or Bframe for exemple) or "scene quality difference" (difference between low motion and high motion for exemple) will be too high and Rate Control for this codec not very good.

Here (http://multimediacom.free.fr/Download/CompareYV12.zip) last AviSynth plugin for Overall PSNR in YV12

Open your avs metric script with VirtualDub. Select file > preview input for run the test. Select file > close video file for obtain final result in log metric files. You must use these AviSynth type script for metric test:

# --> Source Opening <--
Source=ImageSource("C:\LossLess\images\%05d.png", start=1, end=15691, fps=24)
Source=ConvertToYV12(source, matrix="Rec709")

# --> Video Opening <--
video=Mpeg2Source("D:\...\MPEG2_24Mbps.d2v",idct=2)

# --> PSNR analysis <--
compareYV12(video,source,"YUV","OPSNR_MPEG2_24Mbps.log")

# --> Source Opening <--
Source=ImageSource("C:\LossLess\images\%05d.png", start=1, end=15691, fps=24)
Source=ConvertToYV12(source, matrix="Rec709")

# --> Video Opening <--
video=Mpeg2Source("D:\...\MPEG2_24Mbps.d2v",idct=2)

# --> SSIM analysis <--
return SSIM(source,video,"results.csv","SSIM_MPEG2_24Mbps.txt",lumimask=2)

C - Results

At this time here the best result (http://jfl1974.free.fr/HDDVD/Test_Metric.rar) ... but make better if you can ... :devil:

|--------------|---------|---------|----------|---------|---------|
| Codec | PProc | Bitrate | Size | OPSNR | SSIM 2 |
|--------------|---------|---------|----------|---------|---------|
| MPEG2 | No | 5999 | 479233 | 43.08 | 82.55 |
| VC-1 | No | 5994 | 479405 | 44.15 | 85.85 |
| H264 | No | 6007 | 479766 | 46.35 | 89.54 |
|--------------|---------|---------|----------|---------|---------|
| MPEG2 | No | 12001 | 958666 | 46.38 | 91.27 |
| VC-1 | No | 11987 | 957575 | 47.30 | 92.25 |
| H264 | No | 12008 | 959329 | 49.11 | 94.18 |
|--------------|---------|---------|----------|---------|---------|
| MPEG2 | No | 18002 | 1438146 | 47.17 | 93.26 |
| VC-1 | No | 18005 | 1438379 | 49.00 | 94.60 |
| H264 | No | 18009 | 1438862 | 50.53 | 95.74 |
|--------------|---------|---------|----------|---------|---------|
SSIM 0: Lumimask Off
SSIM 1: Lumimask On (Original Lumimask)
SSIM 2: Lumimask On (One2Tech Patch)

H264 vs VC1 vs MPEG2 at 6Mbps
http://jfl1974.free.fr/HDDVD/6Mbps_small.PNG (http://jfl1974.free.fr/HDDVD/6Mbps.PNG)

H264 vs VC1 vs MPEG2 at 12Mbps
http://jfl1974.free.fr/HDDVD/12Mbps_small.PNG (http://jfl1974.free.fr/HDDVD/12Mbps.PNG)

H264 vs VC1 vs MPEG2 at 18Mbps
http://jfl1974.free.fr/HDDVD/18Mbps_small.PNG (http://jfl1974.free.fr/HDDVD/18Mbps.PNG)

H264 at 6Mbps vs MPEG2 at 12 Mbps
http://jfl1974.free.fr/HDDVD/H264_6M_MPEG2_12M_small.PNG (http://jfl1974.free.fr/HDDVD/H264_6M_MPEG2_12M.PNG)

H264 at 12Mbps vs VC1 at 18 Mbps
http://jfl1974.free.fr/HDDVD/H264_12M_VC1_18M_small.PNG (http://jfl1974.free.fr/HDDVD/H264_12M_VC1_18M.PNG)

VC1 encoding by "Anonyme"
Encoding with vc1_enc.exe from VC1 PEP software
See Annexe for complete profil
Video stream are compliant with HDDVD "NTSC" profil

H264 encoding by "Sagittaire"
Encoding with x264.exe
See Annexe for complete profil
Video stream are compliant with HDDVD "NTSC" profil

MPEG2 encoding by "Sagittaire"
Encoding with mencoder.exe from libavcodec MPEG2
See Annexe for complete profil
Video stream are compliant with HDDVD "NTSC" profil

D - Conclusion

At this time for this movie

1) I use certainely the best MPEG2 encoder available in the area for metric: Libavcodec. The result is simply impressive for the old MPEG2 codec. With PP4 the result is even better. Libavcodec produce by far much better metric result here than all the other implementations (HCEnc, TMPGEnc, Mainconcept, Procoder ...).

2) VC1 is a very good surprise for me. For "low/medium bitrate" (high quantisation level) VC1 in unable to fight with H264 but for "High bitrate" the SSIM for VC1 is close to H264. MS say "VC1 is particulary optimized for high bitrate with high resolution" and it's true. Anyway MS claim that VC1 is able to produce the same metric that H264 but it's clearly false here.

3) H264 is simply the best for metric in all situation and particulary for "low bitrate" situation. Anyway differences between VC1 and H264 are not so high for low quantisation encoding.

4) VC1 and H264 at 6/20 Mbps (average bitrate/max bitrate) are unable to produce better quality than MPEG2 at 12/24 Mbps. H264 at 12/24 Mbps produce better quality than MPEG2 at 18/28 Mbps but not VC1. H264 at 12/24 Mbps is unable to produce better quality than VC1 at 18/28 Mbps. MicroSoft annonce (http://www.microsoft.com/windows/windowsmedia/howto/articles/vc1techoverview.aspx#VC1ComparedtoOtherCodecs) ratio between 1:2 and 1:3 for MPEG2 vs VC1 but it's really not the case here. The x264 particularly optimized in its development to obtain very good PSNR is not able to obtain a ratio of 2:1 with MPEG2 in this challenge.

5) Use constrained vbv rate control produce very inconstant quality and use overall or average metric results in this case is very difficult because complex part (motion and/or texture) can produce very bad results for metric. For better results it will be better to use metric graph for part by part comparison. If a codec want produce good overall/average metric here then the codec must have particulary good vbv Rate Control optimization.

IF YOU DON'T AGREE WITH THAT, TRY WITH YOUR ENCODER ... !!!

Sagittaire

1st August 2007, 13:06

Annexe - Update

05.09.2007 - New VC1 encoding
11.08.2007 - All the H264 streams are availables
05.08.2007 - Max adaptative bframe at 7 for VC1, H264 and MPEG2
04.08.2007 - Unlimited range vector for VC1
03.08.2007 - Encoding with libavcodec at 18 Mbps
02.08.2007 - Max adaptative bframe at 7 for VC1
01.08.2007 - Complete Test with x264, pep and libavcodec

will coming ... if you want ... !!!
All the developpers are wellcome ... !!?

Annexe - VBV Compliancy

H264 at 6Mbps, 12Mbps and 18Mbps
http://jfl1974.free.fr/HDDVD/Buffer_H264_6M_small.PNG (http://jfl1974.free.fr/HDDVD/Buffer_H264_6M.PNG) http://jfl1974.free.fr/HDDVD/Buffer_H264_12M_small.PNG (http://jfl1974.free.fr/HDDVD/Buffer_H264_12M.PNG) http://jfl1974.free.fr/HDDVD/Buffer_H264_18M_small.PNG (http://jfl1974.free.fr/HDDVD/Buffer_H264_18M.PNG)

VC1 at 6Mbps, 12Mbps and 18Mbps
http://jfl1974.free.fr/HDDVD/Buffer_VC1_6M_small.PNG (http://jfl1974.free.fr/HDDVD/Buffer_VC1_6M.PNG) http://jfl1974.free.fr/HDDVD/Buffer_VC1_12M_small.PNG (http://jfl1974.free.fr/HDDVD/Buffer_VC1_12M.PNG) http://jfl1974.free.fr/HDDVD/Buffer_VC1_18M_small.PNG (http://jfl1974.free.fr/HDDVD/Buffer_VC1_18M.PNG)

MPEG2 at 6Mbps, 12Mbps and 18Mbps
http://jfl1974.free.fr/HDDVD/Buffer_MPEG2_6M_small.PNG (http://jfl1974.free.fr/HDDVD/Buffer_MPEG2_6M.PNG) http://jfl1974.free.fr/HDDVD/Buffer_MPEG2_12M_small.PNG (http://jfl1974.free.fr/HDDVD/Buffer_MPEG2_12M.PNG) http://jfl1974.free.fr/HDDVD/Buffer_MPEG2_18M_small.PNG (http://jfl1974.free.fr/HDDVD/Buffer_MPEG2_18M.PNG)

+ Mux with Sonic SCA without underflow problem
+ Scan vbv with esa.exe for VC1 stream

Annexe - Profil for encoding

H264 Encoding Profil

@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
@REM >> HDDVD - 1080p - 23.976 fps - progressive - PSNR optimisation
@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

@REM 6Mbps - 1080p24 - 3 pass insame profil

x264.exe --threads 1 --thread-input --keyint 14 --min-keyint 2 --vbv-maxrate 20000 --vbv-init 1.0 --vbv-bufsize 14745 --mvrange 511 --level 4.1 --nal-hrd --bframe 2 --bime --weightb --ref 1 --mixed-refs --direct auto --deblock -1:-1 --qpmin 1 --bitrate 6000 --pass 1 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.25 --partitions "all" --8x8dct --me "hex" --subme 5 --aud --sar 1:1 --progress -o NUL HDDVD-ntsc.avs

x264.exe --threads 1 --thread-input --keyint 14 --min-keyint 2 --vbv-maxrate 20000 --vbv-init 1.0 --vbv-bufsize 14745 --mvrange 511 --level 4.1 --nal-hrd --bframe 2 --b-rdo --bime --weightb --ref 3 --mixed-refs --direct auto --deblock -1:-1 --qpmin 1 --bitrate 6000 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.25 --partitions "all" --8x8dct --me "hex" --subme 6 --no-fast-pskip --no-dct-decimate --trellis 1 --aud --sar 1:1 --progress -o NUL HDDVD-ntsc.avs

x264.exe --threads 1 --thread-input --keyint 14 --min-keyint 2 --vbv-maxrate 20000 --vbv-init 1.0 --vbv-bufsize 14745 --mvrange 511 --level 4.1 --nal-hrd --bframe 2 --b-rdo --bime --weightb --ref 3 --mixed-refs --direct auto --deblock -1:-1 --qpmin 1 --bitrate 6000 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.25 --partitions "all" --8x8dct --me "umh" --subme 7 --no-fast-pskip --no-dct-decimate --trellis 2 --aud --sar 1:1 --progress -o 6000_3.h264 HDDVD-ntsc.avs

@REM 12Mbps - 1080p24 - 3 pass insame profil

x264.exe --threads 1 --thread-input --keyint 14 --min-keyint 2 --vbv-maxrate 24000 --vbv-init 1.0 --vbv-bufsize 14745 --mvrange 511 --level 4.1 --nal-hrd --bframe 2 --bime --weightb --ref 1 --mixed-refs --direct auto --deblock -1:-1 --qpmin 1 --bitrate 12000 --pass 1 --stats "x264_stat.log" --qcomp 0.50 --ipratio 1.10 --pbratio 1.25 --partitions "all" --8x8dct --me "hex" --subme 5 --aud --sar 1:1 --progress -o NUL HDDVD-ntsc.avs

x264.exe --threads 1 --thread-input --keyint 14 --min-keyint 2 --vbv-maxrate 24000 --vbv-init 1.0 --vbv-bufsize 14745 --mvrange 511 --level 4.1 --nal-hrd --bframe 2 --b-rdo --bime --weightb --ref 3 --mixed-refs --direct auto --deblock -1:-1 --qpmin 1 --bitrate 12000 --pass 3 --stats "x264_stat.log" --qcomp 0.50 --ipratio 1.10 --pbratio 1.25 --partitions "all" --8x8dct --me "hex" --subme 6 --no-fast-pskip --no-dct-decimate --trellis 1 --aud --sar 1:1 --progress -o 12000.h264 HDDVD-ntsc.avs

x264.exe --threads 1 --thread-input --keyint 14 --min-keyint 2 --vbv-maxrate 24000 --vbv-init 1.0 --vbv-bufsize 14745 --mvrange 511 --level 4.1 --nal-hrd --bframe 2 --b-rdo --bime --weightb --ref 3 --mixed-refs --direct auto --deblock -1:-1 --qpmin 1 --bitrate 12000 --pass 3 --stats "x264_stat.log" --qcomp 0.50 --ipratio 1.10 --pbratio 1.25 --partitions "all" --8x8dct --me "umh" --subme 7 --no-fast-pskip --no-dct-decimate --trellis 2 --aud --sar 1:1 --progress -o 12000.h264 HDDVD-ntsc.avs

@REM 18Mbps - 1080p24 - 3 pass insame profil

x264.exe --threads 1 --thread-input --keyint 14 --min-keyint 2 --vbv-maxrate 28000 --vbv-init 1.0 --vbv-bufsize 14745 --mvrange 511 --level 4.1 --nal-hrd --bframe 2 --bime --weightb --ref 1 --mixed-refs --direct auto --deblock -1:-1 --qpmin 1 --bitrate 18000 --pass 1 --stats "x264_stat.log" --qcomp 0.15 --ipratio 1.10 --pbratio 1.25 --partitions "all" --8x8dct --me "hex" --subme 5 --aud --sar 1:1 --progress -o NUL HDDVD-ntsc.avs

x264.exe --threads 1 --thread-input --keyint 14 --min-keyint 2 --vbv-maxrate 28000 --vbv-init 1.0 --vbv-bufsize 14745 --mvrange 511 --level 4.1 --nal-hrd --bframe 2 --b-rdo --bime --weightb --ref 3 --mixed-refs --direct auto --deblock -1:-1 --qpmin 1 --bitrate 18000 --pass 3 --stats "x264_stat.log" --qcomp 0.15 --ipratio 1.10 --pbratio 1.25 --partitions "all" --8x8dct --me "hex" --subme 6 --no-fast-pskip --no-dct-decimate --trellis 1 --aud --sar 1:1 --progress -o 18000.h264 HDDVD-ntsc.avs

x264.exe --threads 1 --thread-input --keyint 14 --min-keyint 2 --vbv-maxrate 28000 --vbv-init 1.0 --vbv-bufsize 14745 --mvrange 511 --level 4.1 --nal-hrd --bframe 2 --b-rdo --bime --weightb --ref 3 --mixed-refs --direct auto --deblock -1:-1 --qpmin 1 --bitrate 18000 --pass 3 --stats "x264_stat.log" --qcomp 0.15 --ipratio 1.10 --pbratio 1.25 --partitions "all" --8x8dct --me "umh" --subme 7 --no-fast-pskip --no-dct-decimate --trellis 2 --aud --sar 1:1 --progress -o 18000.h264 HDDVD-ntsc.avs

VC1 Encoding Profil

@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
@REM >> HDDVD - 1080p - 29.97 fps - pulldown 3:2i - PSNR optimisation
@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

@REM 6Mbps - 1080p24 - 2 pass insame profil

vc1_enc.exe -i C:\Master\1920x1080.yuv -o Temp\1080p_1.vc1 -w 1920 -h 1080 -framerate 29.97 -frametype progressive -telecine 1 -addeos -rate 6000 -maxrate 20000 -buffer 1843200 -gopperiod 14 -mvrange 1 -bframes 1 -bframeposopt 1 -bdeltaqp AdaptiveWeak -loopfilter 1 -complexity 2 -chromasearch 4 -motionmatch 2 -perceptual 2 -dquantstrength 0 -favorinterlevel 3 -singlethread 1 -log Temp\stat_1.txt

vc1_enc.exe -i C:\Master\1920x1080.yuv -o Temp\1080p_4.vc1 -w 1920 -h 1080 -framerate 29.97 -frametype progressive -telecine 1 -addeos -rate 6000 -maxrate 20000 -buffer 1843200 -gopperiod 14 -mvrange 1 -bframes 1 -bframeposopt 1 -bdeltaqp AdaptiveWeak -loopfilter 1 -complexity 4 -chromasearch 2 -motionmatch 1 -perceptual 2 -dquantstrength 0 -favorinterlevel 3 -singlethread 1 -2pass Temp\stat_1.txt

@REM 12Mbps - 1080p24 - 2 pass insame profil

vc1_enc.exe -i C:\Master\1920x1080.yuv -o Temp\1080p_5.vc1 -w 1920 -h 1080 -framerate 29.97 -frametype progressive -telecine 1 -addeos -rate 12000 -maxrate 24000 -buffer 1843200 -gopperiod 14 -mvrange 1 -bframes 1 -bframeposopt 1 -bdeltaqp AdaptiveWeak -loopfilter 1 -complexity 2 -chromasearch 4 -motionmatch 2 -perceptual 2 -dquantstrength 0 -favorinterlevel 3 -singlethread 1 -log Temp\stat_2.txt

vc1_enc.exe -i C:\Master\1920x1080.yuv -o Temp\1080p_6.vc1 -w 1920 -h 1080 -framerate 29.97 -frametype progressive -telecine 1 -addeos -rate 12000 -maxrate 24000 -buffer 1843200 -gopperiod 14 -mvrange 1 -bframes 1 -bframeposopt 1 -bdeltaqp AdaptiveWeak -loopfilter 1 -complexity 4 -chromasearch 2 -motionmatch 1 -perceptual 2 -dquantstrength 0 -favorinterlevel 3 -singlethread 1 -2pass Temp\stat_2.txt

@REM 18Mbps - 1080p24 - 2 pass insame profil

vc1_enc.exe -i C:\Master\1920x1080.yuv -o Temp\1080p_7.vc1 -w 1920 -h 1080 -framerate 29.97 -frametype progressive -telecine 1 -addeos -rate 18250 -maxrate 28000 -buffer 1843200 -gopperiod 14 -mvrange 1 -bframes 1 -bframeposopt 1 -bdeltaqp AdaptiveWeak -loopfilter 1 -complexity 2 -chromasearch 4 -motionmatch 2 -perceptual 2 -dquantstrength 0 -favorinterlevel 3 -singlethread 1 -log Temp\stat_3.txt

vc1_enc.exe -i C:\Master\1920x1080.yuv -o Temp\1080p_8.vc1 -w 1920 -h 1080 -framerate 29.97 -frametype progressive -telecine 1 -addeos -rate 18250 -maxrate 28000 -buffer 1843200 -gopperiod 14 -mvrange 1 -bframes 1 -bframeposopt 1 -bdeltaqp AdaptiveWeak -loopfilter 1 -complexity 4 -chromasearch 2 -motionmatch 1 -perceptual 2 -dquantstrength 0 -favorinterlevel 3 -singlethread 1 -2pass Temp\stat_3.txt

Sagittaire

1st August 2007, 14:55

MPEG2 Encoding Profil

@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
@REM >> HDDVD - 1080p - 23.976 fps - progressive - PSNR optimisation
@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

@echo off

@REM -----------------------------------------------------------------------------------------------
@REM
@REM 6 Mbps MPEG2 Mencoder Profil
@REM
@REM -----------------------------------------------------------------------------------------------

@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
@REM >> Output and Input files
@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

@REM Input file name
set E_SRC=HDDVD-ntsc.avs

@REM Output file name
set E_VID=MPEG2_6Mbps.m2v

@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
@REM >> Rate control settings
@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

@REM Set of bitrates
set E_BR=6000

@REM Set of max bitrates (use 9800 max for DVD compliant stream)
set VBV_MBR=20000

@REM Set of max buffer size (use 1835 max for DVD compliant stream)
set VBV_MBS=9781

@REM Set of ratio initial buffer occupency (0.9 is good value)
set VBV_IBO=0.9

@REM Set of first pass quantizer (2 is good value for high bitrate)
set E_IQ=6

@REM Set of min quantizer (1 is good value for high bitrate)
set E_MinQ=2

@REM Set of max quantizer (9 is good value for high bitrate)
set E_MaxQ=31

@REM Set of quantizer variability [0.00;1.00] (0.75 is good value)
set E_VQ=0.75

@REM Set of inter quantizer masking [0.00;1.00] (0.00-0.50 is good interval)
set E_PMSK=0.10

@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
@REM >> GOP structure
@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

@REM Set of max interval KFrame (use 15 for DVD PAL and 18 for DVD NTSC)
set E_MIK=14

@REM Set of max BFrames [0;4] (use 2 max for DVD compliant stream)
set E_MBF=2

@REM Set of Adaptative BFrames [0;2] (desactived is 0, fast is 1 and slow is 2)
set E_ABF=2

@REM Set of Slow Adaptative BFrames Refine [0;10] (0 is full search, higher is faster)
set E_SBF=1

@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
@REM >> Motion estimation settings
@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

@REM Set of ME range [0;9999] (use 128 for DVD compliant stream)
set E_RME=128

@REM Set of Rate Distortion Optimisation [0;2] (2 is the best)
set E_RDO=2

@REM Set of diamond size [-99;6] (negatives values are adaptative diamond)
set E_DIA=-4

@REM Set of comparison function for ME [0;2000] (0 is SAD, 1 is SSE, 2 is SADT, +256 for chroma ME)
set E_CMP=2

@REM Set of previous ME [0;2]
set E_PME=2

@REM Set of BFrame refinements [0;4] (Bframe Quality, 4 is best quality)
set E_BFR=4

@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
@REM >> VUI settings
@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

@REM Display Aspect Ratio (4/3 or 16/9 for DVD compliant stream)
set E_DAR=16/9

@REM DC precision [8;10]
set E_DC=8

@REM Framerate (use 25 for PAL and 24000/1001 or 30000/1001 for NTSC)
set E_FPS=24000/1001

@REM Set intra matrix (use coef > 8 for DVD compliant stream with mencoder)
set E_INTRA=8,16,16,16,17,18,21,24,16,16,16,16,17,19,22,25,16,16,17,18,20,22,25,29,16,16,18,21,24,27,31,36,17,17,20,24,30,35,
41,47,18,19,22,27,35,44,54,65,21,22,25,31,41,54,70,88,24,25,29,36,47,65,88,115

@REM Set inter matrix (use coef > 8 for DVD compliant stream with mencoder)
set E_INTER=16,17,18,18,19,20,21,22,17,18,18,18,19,20,21,23,18,18,18,19,20,22,24,26,18,18,19,20,22,24,27,30,19,19,20,22,25,28,
32,37,20,20,22,24,28,34,40,46,21,21,24,27,32,40,48,58,22,23,26,30,37,46,58,74

@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
@REM >> Mencoder CLI
@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

ECHO.---------------------------------------------------------------
ECHO.First pass ...
ECHO.---------------------------------------------------------------
mencoder.exe -priority idle %E_SRC% -o NUL -ovc lavc -ofps %E_FPS% -passlogfile MPEG2_6Mbps.log -lavcopts vcodec=mpeg2video
:vpass=1:vqscale=%E_IQ%:keyint=%E_MIK%:vqcomp=%E_VQ%:vmax_b_frames=%E_MBF%:vb_strategy=%E_ABF%
:brd_scale=%E_SBF%:vb_qfactor=1.25:vb_qoffset=0.00:vi_qfactor=1.00:vi_qoffset=0.00:me_range=%E_RME%:preme=%E_PME%
:dia=1:predia=1:mbd=%E_RDO%:precmp=0:cmp=0:subcmp=0:mv0:last_pred=0:trell:cbp:dc=%E_DC%:psnr:aspect=%E_DAR%
:inter_matrix=%E_INTER%:intra_matrix=%E_INTRA%:scplx_mask=%E_PMSK%:vqmin=%E_MinQ%:lmin=%E_MinQ%:mblmin=%E_MinQ%
:vqmax=%E_MaxQ%:lmax=%E_MaxQ%:mblmax=%E_MaxQ%:vqblur=%E_VQ%:vrc_strategy=0 -of rawvideo -ffourcc MPG2

@REM @CLS

ECHO.---------------------------------------------------------------
ECHO.Second pass ...
ECHO.---------------------------------------------------------------
mencoder.exe -priority idle %E_SRC% -o NUL -ovc lavc -ofps %E_FPS% -passlogfile MPEG2_6Mbps.log -lavcopts vcodec=mpeg2video
:vpass=3:vbitrate=%E_BR%:keyint=%E_MIK%:vqcomp=%E_VQ%:vmax_b_frames=%E_MBF%:vb_qfactor=1.25:vb_qoffset=0.00
:vi_qfactor=1.00:vi_qoffset=0.00:me_range=%E_RME%:preme=%E_PME%:dia=1:predia=1:mbd=%E_RDO%:precmp=0:cmp=0:subcmp=0
:mv0:last_pred=0:trell:cbp:qprd:dc=%E_DC%:psnr:aspect=%E_DAR%:inter_matrix=%E_INTER%:intra_matrix=%E_INTRA%
:scplx_mask=%E_PMSK%:vqmin=%E_MinQ%:lmin=%E_MinQ%:mblmin=%E_MinQ%:vqmax=%E_MaxQ%:lmax=%E_MaxQ%:mblmax=%E_MaxQ%
:vqblur=%E_VQ%:vrc_strategy=0 -of rawvideo -ffourcc MPG2

@REM @CLS

ECHO.---------------------------------------------------------------
ECHO.Last pass ...
ECHO.---------------------------------------------------------------
mencoder.exe -priority idle %E_SRC% -o %E_VID% -ovc lavc -ofps %E_FPS% -passlogfile MPEG2_6Mbps.log -lavcopts vcodec=mpeg2video
:vpass=3:vbitrate=%E_BR%:keyint=%E_MIK%:vqcomp=%E_VQ%:vmax_b_frames=%E_MBF%:bidir_refine=%E_BFR%:vb_qfactor=1.25
:vb_qoffset=0.00:vi_qfactor=1.00:vi_qoffset=0.00:me_range=%E_RME%:preme=%E_PME%:dia=%E_DIA%:predia=%E_DIA%:mbd=%E_RDO%
:precmp=%E_CMP%:cmp=%E_CMP%:subcmp=%E_CMP%:mv0:last_pred=3:trell:cbp:qprd:dc=%E_DC%:psnr:aspect=%E_DAR%
:inter_matrix=%E_INTER%:intra_matrix=%E_INTRA%:scplx_mask=%E_PMSK%:vqmin=%E_MinQ%:lmin=%E_MinQ%:mblmin=%E_MinQ%
:vqmax=%E_MaxQ%:lmax=%E_MaxQ%:mblmax=%E_MaxQ%:vqblur=%E_VQ%:vrc_maxrate=%VBV_MBR%:vrc_buf_size=%VBV_MBS%
:vrc_strategy=0 -of rawvideo -ffourcc MPG2

Inventive Software

1st August 2007, 17:02

Frame rate in the AviSynth script should be 24 FPS, not 23.976. Otherwise it would be out of sync. ;)

arfster

1st August 2007, 17:24

Might it be worth expanding this to include Bluray? A 24mbit/peak40 or thereabouts.

Might let mpeg2 stretch its legs a bit - after all, bandwidith is the reason nobody ever did mpeg2 HDDVD discs. Similarly, does VC1 catch up to H264 at the very highest bitrates?

Dark Shikari

1st August 2007, 17:48

Sagittaire

1st August 2007, 19:52

The reason VC-1 does well at high bitrates is because the higher the bitrate, the less useful modern encoding features are, because more and more often new blocks have to be encoded rather than old blocks referenced. So all the encoders, regardless of how good they are, slowly converge on each other. This is also why at low bitrates H.264 has such an extraordinary advantage, even more than shown in these tests (1.5-2.5 megabits for 1080p).This is also why MPEG-2 is much closer to H.264/VC-1 at high bitrates than at low bitrates, of course.

Yes but for me the real surprise for this test is the MPEG2 result with Libavcodec.

In about 10 hours my download of Elephant's Dream will be done and I'll encode some new H.264 versions for you with my specially modified version of x264.

Don't forget the hrd patch because respect the vbv compliancy is really a problem for x264 in vbr mode. With hrd patch you can scan the vbv compliancy. If you don't want problem use my profil encoding and particulary the same qcomp for your test.
https://sourceforge.net/project/showfiles.php?group_id=138139

Dethis

1st August 2007, 20:26

Might it be worth expanding this to include Bluray? A 24mbit/peak40 or thereabouts.
.........

?

http://www.w6rz.net/

PuzZLeR

1st August 2007, 20:37

Great work Sagittaire... I can see no subjective analysis whatsoever, and hopefully it's conclusive: H.264 is the winner.

But just to add, and for the moment, let’s be fair. There are some VC-1 "advantages" after all that were and were not tested here. Maybe there is a benefit to VC-1. After all, it does have its “advantages” according to Microsoft et al:

-VC-1 is better at higher bitrates:
Ok, maybe. Even though this test was very close, let's assume as such for the moment for "some tests" at very high bitrates for "some clips". Ok, great. Then again, so can DivX if you give it enough juice. I'm not too familiar with HD rez, but I know that to most eyes, for SD resolutions, there is no difference between any ASP codec and H.264 over 6000kbps, so why should anybody care about this VC-1 feature, even for HD? (If it exists.)

There are some other "strengths" of VC-1 that were not tested (fully) here, which will be challenged and should be noted:

-VC-1 supports FGM:
VC-1 has the early advantage here but only in implementations. FGM is part of the H.264 standard too, and a bit slow out of the gate (maybe due to the deblocking canceling it out?) but I can see that that is being developed better as we speak. Maybe a future test real soon?

-VC-1 retains interlacing more efficiently:
So, in an age that has better storage capacities and better video compression technology, better streaming, wonderful de-interlacers in the encoding and decoding realm, to rid us finally of this horrid picture format that was developed with 1930s technology for the then slower signals, and other purposes that are no longer necessary and for television sets that will soon no longer be manufactured, Microsoft makes the bold move to make sure it’s actually something we need to keep instead of just letting it quietly lapse into obsolete Heaven.

That’s like Microsoft releasing a drug that helps you COPE with stomach-ache when there are other wonderful products on the market that CURE it. What good does that do?

In fact, the world would benefit today with a popular codec that would actually be HORRIBLE at retaining interlacing.

Being on the H.264 camp, I'm actually cheering for VC-1 to win that test.

-Faster processing:
This too is a joke and pure propaganda, and a half-witted effort for leverage to compete and adopt an early market. It may even be a bit of short-sightedness on the part of Microsoft. Let me repeat from a previous post and to strengthen what Dark Shikara and DeaththeSheep said there too. This is what Baseline is with H.264. As hardware gets better and better, and it will, this “advantage” will be reduced to a 0.000000001% time difference. For what? Lower quality video? They can get away with it today with dinky-toy cell phones from 2007, but the law of diminishing returns will definitely apply and render this advantage useless soon enough.

VC-1 can only go so far with a standard only as good as a suped-up ASP codec. Even H.264’s Baseline Profile, which as everyone will agree – will also be useless in the future as well.

Without CABAC, MRFs, 4:4:4 color space, chroma etc, VC-1 is just as good as H.264:
Take away Wayne Gretzky's goals/assists and he would've been just as good as average players. Take away sports cars' vital engine parts for speed and they'd be just as fast as economy cars. Take away a recipe's best ingredients and its cooking techniques and it would be just as good as an average meal...

Congratulations to H.264. The fat lady has sung.

akupenguin

1st August 2007, 21:27

set E_MinQ=2
Did you leave that for 18mbit too? no wonder it saturated.

Golgot13

1st August 2007, 21:46

-VC-1 supports FGM:
VC-1 has the early advantage here but only in implementations.

In HD DVD specification (read HD DVD White), there is a specific FGM option from Thomson.
It can optimize the film grain for H264: it is really first development of FGM for HD DVD use.
And there is a good developpment from CTC to optimize the film grain on CinemaCraft HD express.

-VC-1 retains interlacing more efficiently:

There is lot of option in H264 : PAFF, MBAFF and interlaced....

Without CABAC, MRFs, 4:4:4 color space, chroma etc, VC-1 is just as good as H.264:

Same VC1 HD DVD without preprocessing video, VC1 at 18Mbps on HD DVD is just
as good as MPEG2 at 30Mbps on first BD title.

H.264. The fat lady has sung.

VC1 will be a lady from some book (like Guinness)

Golgot13

Sagittaire

1st August 2007, 21:50

Did you leave that for 18mbit too? no wonder it saturated.

Well I try that with average at 18 Mbps and max at 28 Mbps:

- Min quantizer at 1
- Custom quant matrix with half coef
- encoding without bframe
- Min quantizer at 1 + CQM with half coef + encoding without bframe

Here "half matrix" with low coef:
set E_INTRA=8,8,8,8,9,10,11,12,8,8,8,8,9,11,11,13,8,8,9,9,10,12,14,15,8,8,9,10,12,14,16,18,9,9,10,12,15,17,20,23,10,11,12,14,17,22,
27,33,11,11,14,16,20,27,35,44,12,13,15,18,23,33,44,64
set E_INTER=8,9,10,10,11,11,12,12,9,10,10,10,11,11,12,12,10,10,10,11,11,12,12,13,10,10,11,11,12,12,13,15,11,11,11,12,13,14,15,17,
11,11,12,12,14,16,18,22,12,12,12,13,15,18,23,27,12,12,13,15,17,22,27,34

... ect ect ect

But I find finaly that problem is in fact vbv parameters (vrc_maxrate and vrc_buf_size). Mencoder with these parameters actived says always:"[mpeg2video @ 00C2F900][lavc rc] Using all of requested bitrate is not necessary for this video with these parameters" and make encoding at ~16 Mbps. I have in practice quantizer saturation for easy part and vbv saturation for complex part for mencoder Rate Control. It's strange because CQM at half coef should solve this problem because encoding at 12 Mbps (max at 24 Mbps) produce the good bitrate with the initial matrix. In fact it's perhaps not a quantizer saturation (libavcodec can potentially produce stream with the good bitrate I think) but certainely a RC limitation but I don't know how solve that.

0, 4.00, 31183, 1.#J, 1.#J, 1.#J, 1.#J I
1, 4.00, 834, 1.#J, 1.#J, 1.#J, 1.#J P
2, 4.00, 834, 1.#J, 1.#J, 1.#J, 1.#J P
3, 4.00, 834, 1.#J, 1.#J, 1.#J, 1.#J P
4, 4.00, 834, 1.#J, 1.#J, 1.#J, 1.#J P
5, 4.00, 834, 1.#J, 1.#J, 1.#J, 1.#J P
6, 4.00, 834, 1.#J, 1.#J, 1.#J, 1.#J P
7, 4.00, 834, 1.#J, 1.#J, 1.#J, 1.#J P
8, 3.00, 834, 1.#J, 1.#J, 1.#J, 1.#J P
9, 3.55, 33147, 59.08, 65.00, 60.88, 59.95 I
10, 1.78, 20116, 61.12, 61.95, 62.96, 61.51 B
11, 3.26, 36332, 57.17, 59.67, 58.63, 57.73 I
12, 2.89, 43777, 55.39, 57.30, 57.19, 55.93 I
13, 1.53, 27239, 56.30, 57.29, 57.58, 56.64 B <--- low quantizer saturation
14, 1.77, 39873, 55.39, 56.92, 56.63, 55.81 P
15, 1.69, 42519, 54.88, 56.48, 56.50, 55.36 P
16, 1.57, 44992, 54.48, 55.91, 56.44, 54.97 P
17, 1.55, 47008, 54.10, 55.55, 56.02, 54.59 P
18, 1.82, 65977, 53.40, 54.88, 55.73, 53.94 P
19, 1.51, 31782, 53.38, 54.53, 55.29, 53.83 B
20, 1.51, 52933, 53.22, 54.65, 55.58, 53.76 P
21, 1.61, 74862, 52.80, 54.30, 55.14, 53.34 P
22, 1.65, 31645, 52.62, 53.82, 54.90, 53.12 B
23, 1.54, 80922, 52.39, 53.87, 54.88, 52.95 P
24, 1.55, 32582, 52.17, 53.39, 54.62, 52.69 B
25, 2.32, 99427, 51.69, 53.56, 54.63, 52.35 I
26, 1.57, 29629, 51.85, 53.07, 54.38, 52.38 B
27, 1.44, 68088, 51.91, 53.42, 54.59, 52.50 P
28, 1.50, 68144, 51.72, 53.05, 54.31, 52.27 P
29, 1.49, 70494, 51.59, 52.83, 54.18, 52.13 P
30, 1.47, 72974, 51.50, 52.60, 54.04, 52.01 P
31, 1.55, 101527, 51.37, 52.56, 53.79, 51.88 P
32, 1.73, 30125, 51.01, 51.86, 53.62, 51.49 B
33, 1.45, 75997, 51.24, 52.25, 53.61, 51.72 P
34, 1.50, 108794, 51.14, 52.25, 53.38, 51.62 P
35, 1.69, 30209, 50.76, 51.52, 53.16, 51.21 B
36, 1.46, 81552, 50.99, 51.92, 53.28, 51.45 P
37, 1.51, 114968, 50.95, 51.92, 53.08, 51.40 P
38, 1.57, 31046, 50.62, 51.25, 52.95, 51.04 B
39, 2.02, 162715, 50.35, 51.86, 53.19, 50.95 I
40, 1.36, 27683, 50.46, 51.45, 52.95, 50.95 B
41, 1.44, 88836, 50.61, 51.74, 53.16, 51.13 P
42, 1.52, 121410, 50.55, 51.61, 52.84, 51.03 P
43, 1.62, 30797, 50.20, 50.92, 52.70, 50.65 B
44, 1.48, 127323, 50.48, 51.46, 52.65, 50.93 P
45, 1.64, 30361, 50.12, 50.78, 52.53, 50.55 B
46, 1.45, 132841, 50.37, 51.28, 52.43, 50.80 P
47, 1.54, 31324, 50.00, 50.68, 52.36, 50.43 B
48, 1.40, 98395, 50.29, 51.05, 52.34, 50.70 P
49, 1.13, 70705, 50.49, 51.18, 52.46, 50.88 P
50, 1.13, 80058, 50.50, 51.21, 52.49, 50.89 P
51, 1.17, 27760, 50.18, 50.98, 52.39, 50.61 B
52, 2.13, 186547, 49.67, 51.17, 52.44, 50.26 I
53, 2.12, 19938, 49.72, 51.15, 52.44, 50.30 B
54, 1.16, 83719, 50.35, 51.39, 52.63, 50.82 P
55, 2.10, 18655, 49.67, 51.18, 52.48, 50.27 B
56, 1.20, 73472, 50.35, 51.38, 52.64, 50.83 P
57, 2.14, 18273, 49.77, 51.18, 52.53, 50.35 B
58, 1.20, 72770, 50.36, 51.33, 52.62, 50.83 P
59, 2.05, 18331, 49.74, 51.12, 52.47, 50.31 B
60, 1.19, 71921, 50.33, 51.30, 52.57, 50.79 P
61, 2.10, 18270, 49.73, 51.07, 52.43, 50.29 B
62, 1.18, 71177, 50.32, 51.23, 52.51, 50.76 P
63, 1.16, 23734, 49.96, 50.99, 52.34, 50.44 B
64, 1.25, 71547, 50.27, 51.15, 52.43, 50.71 P
65, 1.34, 23732, 49.91, 50.93, 52.27, 50.39 B
66, 2.24, 177697, 49.47, 51.07, 52.41, 50.09 I
67, 2.15, 18635, 49.57, 51.05, 52.32, 50.16 B
68, 1.21, 78153, 50.08, 51.23, 52.55, 50.59 P
69, 2.10, 18965, 49.45, 51.07, 52.43, 50.08 B
70, 1.24, 71469, 50.07, 51.20, 52.54, 50.58 P
71, 2.15, 18392, 49.50, 51.03, 52.47, 50.12 B
72, 1.22, 72518, 50.08, 51.16, 52.52, 50.58 P
73, 2.10, 18839, 49.46, 50.95, 52.38, 50.07 B
74, 1.24, 58520, 50.02, 51.04, 52.45, 50.51 P
75, 1.25, 60292, 49.99, 50.94, 52.36, 50.46 P
76, 1.27, 61036, 49.97, 50.86, 52.26, 50.42 P
77, 1.26, 72544, 49.96, 50.87, 52.28, 50.42 P
78, 2.09, 19170, 49.31, 50.66, 52.10, 49.88 B
79, 2.29, 175574, 49.25, 50.89, 52.28, 49.89 I

..............................................................

652, 2.43, 119601, 51.25, 53.94, 52.12, 51.74 I
653, 1.61, 15561, 51.48, 54.00, 52.17, 51.92 P
654, 1.96, 22944, 51.42, 53.98, 52.15, 51.88 P
655, 1.81, 31820, 51.39, 53.99, 52.14, 51.85 P
656, 1.79, 36303, 51.35, 53.99, 52.12, 51.82 P
657, 2.17, 54913, 51.47, 54.16, 52.39, 51.97 P
658, 2.17, 62572, 51.37, 54.03, 52.15, 51.85 P
659, 2.00, 52374, 51.27, 53.96, 52.04, 51.75 P
660, 1.84, 43378, 51.25, 53.94, 51.99, 51.73 P
661, 2.01, 49989, 51.22, 53.95, 51.97, 51.70 P
662, 2.09, 55642, 51.27, 53.84, 51.99, 51.73 P
663, 1.97, 53431, 51.27, 53.82, 51.96, 51.72 P
664, 2.06, 59571, 51.21, 53.82, 51.88, 51.67 P
665, 2.07, 70679, 51.19, 53.93, 51.94, 51.67 P
666, 2.49, 125132, 51.18, 53.97, 52.10, 51.69 I
667, 1.99, 66429, 51.16, 53.80, 51.91, 51.63 P
668, 2.00, 58012, 51.17, 53.78, 51.86, 51.62 P
669, 1.91, 60529, 51.19, 53.82, 51.86, 51.65 P
670, 2.32, 77395, 51.66, 54.10, 52.49, 52.12 P
671, 2.32, 102572, 51.13, 53.76, 51.92, 51.61 P
672, 2.24, 83053, 51.14, 53.59, 51.84, 51.58 P
673, 2.09, 76772, 51.19, 53.67, 51.95, 51.64 P
674, 2.17, 83727, 51.23, 53.78, 51.98, 51.69 P
675, 2.20, 83794, 51.30, 53.80, 51.99, 51.75 P
676, 2.12, 68112, 51.38, 53.89, 52.07, 51.83 P
677, 2.10, 71782, 51.36, 53.87, 52.04, 51.80 P
678, 1.99, 66019, 51.30, 53.84, 52.01, 51.75 P
679, 2.02, 71964, 51.33, 53.83, 51.94, 51.76 P
680, 2.55, 128203, 51.29, 53.85, 52.05, 51.75 I
681, 2.12, 78042, 51.32, 53.91, 51.95, 51.76 P
682, 2.05, 69361, 51.32, 53.65, 52.04, 51.75 P
683, 2.15, 71104, 51.28, 53.66, 52.00, 51.72 P
684, 2.40, 90456, 51.90, 54.09, 52.73, 52.33 P
685, 2.33, 106514, 51.13, 53.53, 51.88, 51.57 P
686, 2.08, 86962, 51.14, 53.55, 51.78, 51.57 P
687, 2.16, 93855, 51.13, 53.61, 51.72, 51.56 P
688, 2.21, 94923, 51.22, 53.75, 51.89, 51.66 P
689, 2.25, 92942, 51.28, 53.77, 51.96, 51.72 P
690, 2.29, 95875, 51.29, 53.76, 51.99, 51.74 P
691, 2.47, 113000, 51.42, 53.85, 52.26, 51.88 P
692, 2.86, 351931, 45.51, 50.70, 48.41, 46.47 I
693, 2.06, 191762, 46.60, 51.35, 49.18, 47.49 P
694, 2.38, 184384, 46.07, 50.72, 48.52, 46.94 P
695, 1.60, 201224, 46.78, 50.84, 48.87, 47.56 P
696, 3.11, 83864, 45.02, 50.01, 47.74, 45.95 B <--- vbv Rate Control saturation
697, 4.51, 269827, 42.56, 49.18, 46.04, 43.65 I
698, 3.49, 74549, 44.57, 49.93, 47.39, 45.53 B
699, 1.47, 294604, 47.19, 50.89, 49.04, 47.91 P
700, 2.54, 121299, 46.57, 50.78, 48.67, 47.37 P
701, 2.19, 177560, 46.87, 50.92, 48.87, 47.64 P
702, 3.38, 93627, 44.70, 50.01, 47.48, 45.65 B
703, 2.54, 149302, 46.68, 51.08, 48.83, 47.50 P
704, 2.73, 179867, 46.29, 51.04, 48.83, 47.17 P
705, 2.86, 201532, 45.52, 50.45, 48.03, 46.42 P
706, 2.63, 178208, 45.56, 50.49, 48.10, 46.46 P
707, 2.90, 177841, 45.75, 50.70, 48.31, 46.65 P
708, 6.72, 178265, 41.10, 48.52, 45.20, 42.28 I
709, 4.19, 152399, 42.35, 48.84, 45.75, 43.42 P
710, 4.21, 139688, 42.47, 48.86, 45.77, 43.53 P
711, 5.17, 102597, 41.87, 48.56, 45.30, 42.96 P
712, 3.84, 146217, 43.92, 49.91, 47.03, 44.94 P
713, 4.20, 176606, 43.43, 49.33, 46.48, 44.44 P
714, 6.00, 118947, 41.88, 48.73, 45.50, 43.00 P
715, 6.04, 127393, 41.21, 48.12, 44.79, 42.32 P
716, 5.74, 129653, 41.08, 48.03, 44.72, 42.20 P
717, 5.87, 134357, 40.89, 47.90, 44.54, 42.01 P
718, 5.96, 137014, 40.81, 47.88, 44.44, 41.94 P
719, 6.13, 135191, 41.03, 48.03, 44.64, 42.15 P
720, 5.86, 134757, 40.92, 47.74, 44.49, 42.03 P
721, 2.48, 100787, 52.82, 56.39, 54.80, 53.55 I
722, 1.93, 80482, 53.70, 56.83, 55.41, 54.35 P

Sagittaire

1st August 2007, 22:11

Here my complete profil for 18 Mbps encoding:

@echo off

@REM -----------------------------------------------------------------------------------------------
@REM
@REM 18Mbps MPEG2 Mencoder Profil
@REM
@REM -----------------------------------------------------------------------------------------------

@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
@REM >> Output and Input files
@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

@REM Input file name
set E_SRC=HDDVD-ntsc.avs

@REM Output file name
set E_VID=MPEG2_18Mbps.m2v

@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
@REM >> Rate control settings
@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

@REM Set of bitrates
set E_BR=18000000

@REM Set of max bitrates (use 9800 max for DVD compliant stream)
set VBV_MBR=28000

@REM Set of max buffer size (use 1835 max for DVD compliant stream)
set VBV_MBS=9781

@REM Set of ratio initial buffer occupency (0.9 is good value)
set VBV_IBO=0.9

@REM Set of first pass quantizer (2 is good value for high bitrate)
set E_IQ=3

@REM Set of min quantizer (1 is good value for high bitrate)
set E_MinQ=1

@REM Set of max quantizer (9 is good value for high bitrate)
set E_MaxQ=31

@REM Set of quantizer variability [0.00;1.00] (0.75 is good value)
set E_VQ=0.25

@REM Set of inter quantizer masking [0.00;1.00] (0.00-0.50 is good interval)
set E_PMSK=0.10

@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
@REM >> GOP structure
@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

@REM Set of max interval KFrame (use 15 for DVD PAL and 18 for DVD NTSC)
set E_MIK=14

@REM Set of max BFrames [0;4] (use 2 max for DVD compliant stream)
set E_MBF=2

@REM Set of Adaptative BFrames [0;2] (desactived is 0, fast is 1 and slow is 2)
set E_ABF=2

@REM Set of Slow Adaptative BFrames Refine [0;10] (0 is full search, higher is faster)
set E_SBF=1

@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
@REM >> Motion estimation settings
@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

@REM Set of ME range [0;9999] (use 128 for DVD compliant stream)
set E_RME=128

@REM Set of Rate Distortion Optimisation [0;2] (2 is the best)
set E_RDO=2

@REM Set of diamond size [-99;6] (negatives values are adaptative diamond)
set E_DIA=-4

@REM Set of comparison function for ME [0;2000] (0 is SAD, 1 is SSE, 2 is SADT, +256 for chroma ME)
set E_CMP=2

@REM Set of previous ME [0;2]
set E_PME=2

@REM Set of BFrame refinements [0;4] (Bframe Quality, 4 is best quality)
set E_BFR=4

@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
@REM >> VUI settings
@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

@REM Display Aspect Ratio (4/3 or 16/9 for DVD compliant stream)
set E_DAR=16/9

@REM DC precision [8;10]
set E_DC=8

@REM Framerate (use 25 for PAL and 24000/1001 or 30000/1001 for NTSC)
set E_FPS=24000/1001

@REM Set intra matrix (use coef > 8 for DVD compliant stream with mencoder)
set E_INTRA=8,16,16,16,17,18,21,24,16,16,16,16,17,19,22,25,16,16,17,18,20,22,25,29,16,16,18,21,24,27,31,36,
17,17,20,24,30,35,41,47,18,19,22,27,35,44,54,65,21,22,25,31,41,54,70,88,24,25,29,36,47,65,88,115

@REM Set inter matrix (use coef > 8 for DVD compliant stream with mencoder)
set E_INTER=16,17,18,18,19,20,21,22,17,18,18,18,19,20,21,23,18,18,18,19,20,22,24,26,18,18,19,20,22,24,27,30,
19,19,20,22,25,28,32,37,20,20,22,24,28,34,40,46,21,21,24,27,32,40,48,58,22,23,26,30,37,46,58,76

@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
@REM >> Mencoder CLI
@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

ECHO.---------------------------------------------------------------
ECHO.First pass ...
ECHO.---------------------------------------------------------------
@REM mencoder.exe -priority idle %E_SRC% -o NUL -ovc lavc -ofps %E_FPS% -passlogfile MPEG2_18Mbps.log -lavcopts vcodec=mpeg2video
:vpass=1:vqscale=%E_IQ%:keyint=%E_MIK%:vqcomp=0.0:vmax_b_frames=%E_MBF%:vb_strategy=%E_ABF%:brd_scale=%E_SBF%
:vb_qfactor=1.25:vb_qoffset=0.00:vi_qfactor=1.00:vi_qoffset=0.00:me_range=%E_RME%:preme=%E_PME%:dia=1:predia=1:mbd=%E_RDO%
:precmp=0:cmp=0:subcmp=0:mv0:last_pred=0:dc=%E_DC%:psnr:aspect=%E_DAR%:inter_matrix=%E_INTER%:intra_matrix=%E_INTRA%
:scplx_mask=%E_PMSK%:vqmin=%E_MinQ%:lmin=%E_MinQ%:mblmin=%E_MinQ%:vqmax=%E_MaxQ%:lmax=%E_MaxQ%:mblmax=%E_MaxQ%
:vrc_strategy=0 -of rawvideo -ffourcc MPG2

@REM @CLS

ECHO.---------------------------------------------------------------
ECHO.Second pass ...
ECHO.---------------------------------------------------------------
@REM mencoder.exe -priority idle %E_SRC% -o NUL -ovc lavc -ofps %E_FPS% -passlogfile MPEG2_18Mbps.log -lavcopts vcodec=mpeg2video
:vpass=3:vbitrate=%E_BR%:keyint=%E_MIK%:vqcomp=%E_VQ%:vmax_b_frames=%E_MBF%:vb_qfactor=1.25:vb_qoffset=0.00
:vi_qfactor=1.00:vi_qoffset=0.00:me_range=%E_RME%:preme=%E_PME%:dia=1:predia=1:mbd=%E_RDO%:precmp=0
:cmp=0:subcmp=0:mv0:last_pred=0:trell:cbp:qprd:dc=%E_DC%:psnr:aspect=%E_DAR%:inter_matrix=%E_INTER%:intra_matrix=%E_INTRA%
:scplx_mask=%E_PMSK%:vqmin=%E_MinQ%:lmin=%E_MinQ%:mblmin=%E_MinQ%:vqmax=%E_MaxQ%:lmax=%E_MaxQ%:mblmax=%E_MaxQ%
:vrc_strategy=0 -of rawvideo -ffourcc MPG2

@REM @CLS

ECHO.---------------------------------------------------------------
ECHO.Last pass ...
ECHO.---------------------------------------------------------------
mencoder.exe -priority idle %E_SRC% -o %E_VID% -ovc lavc -ofps %E_FPS% -passlogfile MPEG2_18Mbps.log -lavcopts vcodec=mpeg2video
:vpass=2:vbitrate=%E_BR%:keyint=%E_MIK%:vqcomp=%E_VQ%:vmax_b_frames=%E_MBF%:bidir_refine=%E_BFR%
:vb_qfactor=1.25:vb_qoffset=0.00:vi_qfactor=1.00:vi_qoffset=0.00:me_range=%E_RME%:preme=%E_PME%:dia=%E_DIA%
:predia=%E_DIA%:mbd=%E_RDO%:precmp=%E_CMP%:cmp=%E_CMP%:subcmp=%E_CMP%:mv0
:last_pred=3:trell:cbp:qprd:dc=%E_DC%:psnr:aspect=%E_DAR%:inter_matrix=%E_INTER%:intra_matrix=%E_INTRA%
:scplx_mask=%E_PMSK%:naq:vqmin=%E_MinQ%:lmin=%E_MinQ%:mblmin=%E_MinQ%:vqmax=%E_MaxQ%
:lmax=%E_MaxQ%:mblmax=%E_MaxQ%:vrc_maxrate=%VBV_MBR%:vrc_buf_size=%VBV_MBS%:vrc_strategy=0 -of rawvideo -ffourcc MPG2

pause

@REM Set intra matrix (use coef > 8 for DVD compliant stream with mencoder)
set E_INTRA=8,8,8,8,9,10,11,12,8,8,8,8,9,11,11,13,8,8,9,9,10,12,14,15,8,8,9,10,12,14,16,18,9,9,10,12,15,17,20,23,
10,11,12,14,17,22,27,33,11,11,14,16,20,27,35,44,12,13,15,18,23,33,44,64

@REM Set inter matrix (use coef > 8 for DVD compliant stream with mencoder)
set E_INTER=10,10,10,10,11,11,12,12,10,10,10,10,11,11,12,12,10,10,10,11,11,12,12,13,10,10,11,11,12,12,13,15,
11,11,11,12,13,14,15,17,11,11,12,12,14,16,18,22,12,12,12,13,15,18,23,27,12,12,13,15,17,22,27,34

Sagittaire

2nd August 2007, 01:01

Another little test on my c2d at 2.7 Ghz with ED 18 Mbps 1080p24 stream without hardware decoding:

VC1 decoding with WMVideo decodeur DMO
46.18 fps with CPU between 80 and 90%

H264 decoding with CoreAVC decoder
68.72 fps with CPU between 90 and 100%

I use graphedit with Elecard Chegepuga benchmark. Perhaps a problem for my system ... I don't know?
Why AVC is faster and by far on my system ... ? It's curious ... !!?

akupenguin

2nd August 2007, 06:02

Try CBR rather than CQ3 for the 1st pass.
Try also lmin=0.5 mblmin=0.5

zambelli

2nd August 2007, 09:25

Hi Sagittaire,

Thanks for putting together this test. A few questions/comments:

1) What versions of PEP, x264 and libavcodec were used to produce the encodes?

2) Has the libavcodec MPEG-2 encode been checked for VBV compliance and HD-DVD compliance? I too am surprised with libavcodec's performance - it's usually HC encoder that gets touted as the best free MPEG-2 encoder. I'm wondering if it's perhaps because libavcodec isn't producing perfectly compliant bitstreams.

3) I won't ask you who the "anonymous" VC-1 donor was, but I'll ask you this: who determined the optimal VC-1 encoding settings? Similarly, did anyone advise you on x264 and MPEG-2 encoding settings?

4) Why not ask Microsoft for VC-1 encoding advice? We would've been happy to help. At the very least we could've provided advice on encoding settings.

CruNcher

2nd August 2007, 10:51

Hmm another thread with the same Source ?
Microsoft (codec representatives) said over dozen of times that VC-1 was initialy tweaked for low power grain preservation for HD so i think we really should use a better suited source something more REAL so as it seemes no one can get on the StEm source of the DCI initiative our only possible compare method would be Artificialy Grain Elephants Dream (with a good Grain algorithm one that comes near Hollywoods studio used one), to better compare the most important fact for Hollywood and many Film Lab guys that wan't to preserve as much as possible from the original old Movies look (excludes DRM) ;).
Im not sure wich artificial Grain Software most of the Studios use in their Post Production but i think it will be something that resambles Kodaks Filmstock might be even Software from Kodak, maybe someone knows better here :)

Another little test on my c2d at 2.7 Ghz with ED 18 Mbps 1080p24 stream without hardware decoding:

VC1 decoding with WMVideo decodeur DMO
46.18 fps with CPU between 80 and 90%

H264 decoding with CoreAVC decoder
68.72 fps with CPU between 90 and 100%

I use graphedit with Elecard Chegepuga benchmark. Perhaps a problem for my system ... I don't know?
Why AVC is faster and by far on my system ... ? It's curious ... !!?

Here you can perfectly see from your results that Microsofts VC-1 Decoder is not optimized (compared vs CoreAVC) could you compare with (Mainconcept/Elecards) one too and libvc1 ?
now you could speculate for 10% cpu usage how much more Speed would it result in ;) but 46 fps are enough if you ask me for this system (add audio,parser,renderer (FULL HD) overhead too this results (commercialy also Decryption overhead but done on special DSPs same as Video everywhere now) and you would reach 24 fps for sure fullscreen) so i would say indeed that Microsoft did better tweaked for Decoding Complexity but nothing that couldn't be done with H.264 (on the Decoding side) so it would be no problem to tweak into lower fps and lower cpu utilization there seemes room in CoreAVCs Decoder to achive that. But ofcourse the task is @ Microsoft here to max out the cpu utilization (to achive more frames) and they don't quiet get it @ the moment (on your system).

Sagittaire

2nd August 2007, 11:07

1) What versions of PEP, x264 and libavcodec were used to produce the encodes?

- Well pep.exe seem time limited but not vc1_enc.exe and vc1_enc.exe seem more simple to use with potentialy unlimited pass number with easy CLI change. vc1_enc.exe seem really good tool for make test. Version is VC-1 Sequential Encoder v 1.06 (7/12/2006 build).

- For x264 the most important is the vbv compliancy. I use an old but special build (rev 618) with thread, AQ and hrd patch. You can use If you want the last thrahald build too for make this test:
https://sourceforge.net/project/showfiles.php?group_id=138139

- I use simply the last mencoder build for libavcodec:
http://ffdshow.faireal.net/mirror/mplayer/

2) Has the libavcodec MPEG-2 encode been checked for VBV compliance and HD-DVD compliance? I too am surprised with libavcodec's performance - it's usually HC encoder that gets touted as the best free MPEG-2 encoder. I'm wondering if it's perhaps because libavcodec isn't producing perfectly compliant bitstreams.

Yes really incredible result for libavcodec, isn't it? For me it's the real surprise in this test. Well mencoder don't produce directly HDDVD compliant stream but only flags problem. I use all the MP@HL compliant setting (buffer a 9781 Kbit, max bitrate under 29.4 Mbps, 2 adaptatives bframes, max GOP at 14, max range vector at 128 pixels ... etc etc). I make the encoding with mencoder and I use these tools for patch the flags:
- ReStream for the ratio flags (must be 16/9)
- LevelPatcher for the level flags (always MP@ML by default for libavcodec but it's just a flag)
- dgpulldown for add pulldown flags
- add end of sequence with hexadecimal editor

After I scan the stream with streameyes for vbv compliancy: no problem. After I mux the stream with Sonic SCA in HDDVD project and always no problem (Sonic scan the stream with GOP, level, ratio and underflow compliance). After I play the stream on HDDVD soft player and always no problem. Final test is to play on Toshiba SAP and always no problem. You can download the 6Mbps stream from libavcodec here if you want make scan.
HD-DVD & BD MPEG2 at 6 Mbps (http://jfl1974.free.fr/HDDVD/MPEG2/6Mbps/MPEG2_6Mbps.m2v)

Libavcodec outperform HCEnc and all the other MPEG2 encoder (profesionnal or not) for metric. For example in this test HCEnc obtain only 41.75 dB for OPSNR and 77.97 for SSIM with 6 Mbps encoding. Anyway libavcodec is really a complex tool ... I use this tool just for maximal MPEG2 performance.

3) I won't ask you who the "anonymous" VC-1 donor was, but I'll ask you this: who determined the optimal VC-1 encoding settings? Similarly, did anyone advise you on x264 and MPEG-2 encoding settings?

Well it's a optimized metric profil with insame setting for third pass (complexity at maxi, chroma at maxi, motion at maxi), adaptative bframe with light adaptative ratio quantisation. Some HVS tweak for better SSIM performance (defaut dquant setting, adaptative deadzone, adaptative favorinterlevel). But it's perhaps not the best setting ... ?

Anyway the result is a really better SSIM than your WMV9 AP encoding. The OPSNR is worst but seem to be a RC problem like I say to ben (really bad frame in complex part) and we don't know if your WMV9 AP encoding is really compliant with the vbv setting (really important for OPSNR result).

4) Why not ask Microsoft for VC-1 encoding advice? We would've been happy to help. At the very least we could've provided advice on encoding settings.

Well perfect way for me would to have the encoder for make test and tweak particulary for Rate Control. But If you want make simply encoding the challenge is open ... :thanks:

foxyshadis

2nd August 2007, 11:20

Did you test with Quenc at all? Or have the rc changes dragongodz made been folded back into lavc?

Inventive Software

2nd August 2007, 11:21

@Sag: Any particular reason for using 23.976 as opposed to the 24 FPS that Elephants Dream was mastered in? 24 FPS is supported by HD-DVD too y'know. I know it's a small thing, but every little thing counts. ;)

As for film graining, if you really want to test how the codecs retain film grain (which they should do, it's part of the movie IMHO, makes it feel less clinical) adding an AviSynth filter, either before converting to YV12 or after depending on the filter used would do good IMO.

Sagittaire

2nd August 2007, 11:46

Did you test with Quenc at all? Or have the rc changes dragongodz made been folded back into lavc?

Well I don't use QEnc because I can tweak all the possible quality and RC setting for Libavcodec with Mencoder.

Anyway I think that QEnc use RC from XviD for better vbv compliancy. I can use XviD RC with Mencoder too but here I use the Libavcodec RC. I don't scan the code for Libavocodec but the RC seem really new and Mencoder make always vbv compliant stream now. In fact Mencoder is really slow in the complex part with constrained RC setting actived: look like multiple reencoding frame for respect vbv compliancy.

Software @Sag: Any particular reason for using 23.976 as opposed to the 24 FPS that Elephants Dream was mastered in? 24 FPS is supported by HD-DVD too y'know. I know it's a small thing, but every little thing counts.

Well it's typically an authoring problem and not really a encoding problem. 23.976 or 24 fps don't change anything for the final result (aka quality)

Dark Shikari

2nd August 2007, 11:53

I got the warning on my second pass:

x264 [warning]: DPB size (18800640) > level limit (12582912)

Is this a problem? Commandline is

./x264HRDOpt.exe --threads 1 --thread-input --keyint 14 --min-keyint 2 --vbv-maxrate 20000 --vbv-init 1.0 --vbv-bufsize 14745 --mvrange 511 --level 4.1 --nal-hrd --bframe 2 --b-rdo --bime --weightb --ref 3 --mixed-refs --direct auto --deblock -1:-1 --qpmin 1 --bitrate 6000 --b-pyramid --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.25 --partitions "all" --8x8dct --me "hex" --subme 6 --no-fast-pskip --trellis 1 --aud --sar 1:1 --progress -o 6000_3.h264 elephantsDream.avs

akupenguin

2nd August 2007, 12:15

Pyramid increases the required DPB size. It's not so useful anyway with only 2 B-frames.

Sagittaire

2nd August 2007, 12:17

Try CBR rather than CQ3 for the 1st pass.
Try also lmin=0.5 mblmin=0.5

Like always ... you solve the problem. Encoding at 18 Mbps in progress. And I think that this little tweak can improve the 6 and 12 Mbps encoding too :eek:

:thanks:

Dark Shikari

2nd August 2007, 12:17

Pyramid increases the required DPB size. It's not so useful anyway with only 2 B-frames.
So do I need to turn off --b-pyramid to generate a compliant stream?

Sagittaire

2nd August 2007, 12:22

So do I need to turn off --b-pyramid to generate a compliant stream?

Compliant with the level 4.1 imply compliant with HDDVD/BD specifications. Moreover like say akupenguin pyramid bframe is completely useless with 2 bframes. Use my complete profil if you don't want problem and particulary my qcomp setting.

drmpeg

2nd August 2007, 13:06

@Sag: Any particular reason for using 23.976 as opposed to the 24 FPS that Elephants Dream was mastered in? 24 FPS is supported by HD-DVD too y'know.
24.0 fps is not supported in HD-DVD, only Blu-ray.

Ron

Golgot13

2nd August 2007, 13:35

24.0 fps is not supported in HD-DVD, only Blu-ray.

Ron

Yes and not, because HDDVD support now more framerate in advanced content version.
I have a new HD DVD authoring software which support 1080 60P !!!
Specification of HD DVD change (ex: no more version 3 = advanced content and standard content
on same disc). You can read the change on DVD Forum news paper.

Golgot13

vsv

2nd August 2007, 17:49

HDDVD authoring tool support also 25fps content but where is hardware players (firmware) ?
Same situation will be for 1080p60 :)

benwaggoner

2nd August 2007, 18:05

VC-1 Encoding
Profil & Level: AP@L3 except specific restrictions
Max GOP lenght: 14 frames
Maximum bitrate: 20.0 Mbps, 24.0 Mbps and 28.0 Mbps
Buffer size: 14745 Kbits for principal HD video stream
Horizontal Vector Range: +/- 1024 pixels
Vertical Vector Range: +/- 256 pixels
Other Restrictions Setting: max adaptative GOP at 14, max adaptative bframe at 2

What do you mean by "max adaptive bframe at 2"? Do you mean max of 2 B-frames? If so, why that requirement? It isn't required in HD DVD or VC-1. There's at least one shipping studio title I know of that goes up to 7 B-frames.

Sagittaire

2nd August 2007, 18:29

What do you mean by "max adaptive bframe at 2". Do you mean max of 2 B-frames? If so, why that requirement? It isn't required in HD DVD or VC-1. There's at least one shipping studio title I know of that goes up to 7 B-frames.

yes we make encoding with 7 bframes for VC1 but without quality improuvement. akupenguin explain very well why more than 2 or 3 bframe is completely useless in practice. For example VC1 will use 7 bframes for completely black scene: in this case you save size for the black scene itself but the size saved for the complete movie is really ridiculous. Anyway if you want make encoding with 7 bframes for this challenge you can try ... it's HDDVD compliant ... but don't expect major quality improuvement.

akupenguin

2nd August 2007, 18:55

Then why list it as a restriction?

Sagittaire

2nd August 2007, 18:57

Then why list it as a restriction?

Well it's true ... why not.

Annexe - Update

02.08.2007 - Max adaptative bframe at 7 for VC1
01.08.2007 - Complete Test with x264, pep and libavcodec

will coming ... if you want ... !!!
All the developpers are wellcome ... !!?

benwaggoner

2nd August 2007, 19:09

Well it's true ... why not.

Annexe - Update

02.08.2007 - Max adaptative bframe at 7 for VC1

Thanks! I agree that it's unlikely to make a difference with this particular clip, but on general principal I'd like to use only the spec restraints.

zambelli

3rd August 2007, 00:12

- Well pep.exe seem time limited but not vc1_enc.exe and vc1_enc.exe seem more simple to use with potentialy unlimited pass number with easy CLI change. vc1_enc.exe seem really good tool for make test. Version is VC-1 Sequential Encoder v 1.06 (7/12/2006 build).
Thanks. Is that December 7th or July 12th?

The command-line encoder in the PEP package is really more of a test tool (I think it might even be deprecated at this point). The studios are all using the non-cmd-line encoder.

Well it's a optimized metric profil with insame setting for third pass (complexity at maxi, chroma at maxi, motion at maxi), adaptative bframe with light adaptative ratio quantisation. Some HVS tweak for better SSIM performance (defaut dquant setting, adaptative deadzone, adaptative favorinterlevel). But it's perhaps not the best setting ... ?
I'll see if I can come up with a better set of settings. The 3rd pass in vc1_enc.exe is not a true automated 3rd pass. It's just reusing the 2nd pass log but the further passes aren't really designed to take any significant advantage of the log. 3rd pass encoding is typically done manually by handpicking scenes that need additional tweaking.

Anyway the result is a really better SSIM than your WMV9 AP encoding. The OPSNR is worst but seem to be a RC problem like I say to ben (really bad frame in complex part) and we don't know if your WMV9 AP encoding is really compliant with the vbv setting (really important for OPSNR result).
The WMV9 encodings I did are definitely fully VC-1 compliant (VBV too) but I never checked them for true HD-DVD compliance.
It's no surprise that PEP did a better encoding job than WMV9 DMO. :)

Another question: how did you decode the VC-1 ES? Did you make sure deblocking/deringing was disabled in the decoder?

zambelli

3rd August 2007, 00:22

But ofcourse the task is @ Microsoft here to max out the cpu utilization (to achive more frames) and they don't quiet get it @ the moment (on your system).
Yeah, the Windows WMV decoder is definitely not as optimized as it could be. It uses only 2 threads and there's a lot of legacy junk in there (lots of backwards compatibility to worry about). A true VC-1 decoder written from scratch and optimized for playback on modern CPUs would definitely be able to decode a lot faster. I'm curious to see how optimized the FFmpeg/Libavcodec VC-1 decoder can get.

zambelli

3rd August 2007, 00:27

As for film graining, if you really want to test how the codecs retain film grain (which they should do, it's part of the movie IMHO, makes it feel less clinical) adding an AviSynth filter, either before converting to YV12 or after depending on the filter used would do good IMO.
I've played around with TrBarry's AddGrain filter and it does do a good job of making the ED source much more complex to encode.

Things to keep in mind:
1) AddGrain adds grain randomly so it'd be necessary to save the result to an intermediate AVI before feeding it to every encoder. If you encoded from .avs directly, you'd get different grain in every AVS instance. :)

2) Film grain preservation would need to be evaluated manually. I wouldn't trust SSIM to care enough about grain. We know how happy SSIM gets about deblocking filters. :)

Sagittaire

3rd August 2007, 02:28

Thanks. Is that December 7th or July 12th?

I'am french ... 7/12/2006 mean December 7th ... ;-)

The command-line encoder in the PEP package is really more of a test tool (I think it might even be deprecated at this point). The studios are all using the non-cmd-line encoder.

Seem produce the same result with the same setting. You can't set the deblocking level flags with pep.exe (no deblocking option ?).

I'll see if I can come up with a better set of settings. The 3rd pass in vc1_enc.exe is not a true automated 3rd pass. It's just reusing the 2nd pass log but the further passes aren't really designed to take any significant advantage of the log. 3rd pass encoding is typically done manually by handpicking scenes that need additional tweaking.

Better size prediction anyway.

Another question: how did you decode the VC-1 ES? Did you make sure deblocking/deringing was disabled in the decoder?

VC1 stream here use internal PP flags. Internal flags adjust automatically the PP decoding for the DMO decoder if you don't use Force Process Mode command line registry and I don't use this command registry.

Anyway you have all the command line, build encoder, source for encoding and test, and the VC1 encoding at 6Mbps for reproduce the result:
HD-DVD & BD VC-1 at 6 Mbps (http://jfl1974.free.fr/HDDVD/VC1/6Mbps/VC1_6Mbps.vc1)

It's a challenge: if you can produce better results then I would be happy to report them.

Sagittaire

3rd August 2007, 02:43

Annexe - Update

03.08.2007 - Encoding with libavcodec at 18 Mbps
02.08.2007 - Max adaptative bframe at 7 for VC1
01.08.2007 - Complete Test with x264, pep and libavcodec

will coming ... if you want ... !!!
All the developpers are wellcome ... !!?

|--------------|---------|---------|----------|---------|---------|
| Codec | PProc | Bitrate | Size | OPSNR | SSIM 2 |
|--------------|---------|---------|----------|---------|---------|
| MPEG2 | PP0 | 5999 | 479233 | 43.08 | 82.55 |
| VC-1 | N/A | 5994 | 478824 | 43.75 | 86.41 |
| H264 | N/A | 6007 | 479766 | 46.35 | 89.54 |
|--------------|---------|---------|----------|---------|---------|
| MPEG2 | PP0 | 12001 | 958666 | 46.38 | 91.27 |
| VC-1 | N/A | 11986 | 957521 | 46.71 | 92.44 |
| H264 | N/A | 12008 | 959329 | 49.11 | 94.18 |
|--------------|---------|---------|----------|---------|---------|
| MPEG2 | PP0 | 17988 | 1434719 | 47.17 | 93.26 |
| VC-1 | N/A | 17930 | 1432338 | 48.28 | 94.60 |
| H264 | N/A | 18009 | 1438862 | 50.53 | 95.74 |
|--------------|---------|---------|----------|---------|---------|
SSIM 0: Lumimask Off
SSIM 1: Lumimask On (Original Lumimask)
SSIM 2: Lumimask On (One2Tech Patch)

PuzZLeR

3rd August 2007, 18:10

Hmmm.... I do wonder about these tests sometimes.

The reason is that no matter how wonderful these new codecs are, they are certainly limited when encoding from an MPEG-2 source. Why is this used to test them?

Encoding from this source, the max quality of H.264 and VC-1 will be asymptotically closer to "perfect" by adding bitrate, only "perfect" with an infinite amount of bitrate, and "perfect" is really only as good as the MPEG-2 source.

Sure, encoding from an MPEG-2 source, and the test results here have some inference to the "real picture", but these codecs weren't only designed to encode from an MPEG-2 source.

For example, with x264, CRF<10 doesn't exist with MPEG-2, and would be futile to use it with MPEG-2 source. This would be used for the "real" source.

Raw uncompressed HD video is about 300GB-400GB per hour. I'd love to see what these codecs can REALLY do - this would be the "real picture" and this is how, I'm convinced, we can all view how much better H.264 is than VC-1.

Can anybody test this if they have the means? I certainly can look into it...

foxyshadis

3rd August 2007, 18:35

I've played around with TrBarry's AddGrain filter and it does do a good job of making the ED source much more complex to encode.

Things to keep in mind:
1) AddGrain adds grain randomly so it'd be necessary to save the result to an intermediate AVI before feeding it to every encoder. If you encoded from .avs directly, you'd get different grain in every AVS instance. :)

I modified AddGrain (called AddGrainC) to include a seed parameter to make it deterministic. I'm also still working on and off on a pseudo-fgm method, that works with ffdshow and any video format, but I sort of lost interest since I don't watch many movies now.

jethro

3rd August 2007, 19:42

Hmmm.... I do wonder about these tests sometimes.

The reason is that no matter how wonderful these new codecs are, they are certainly limited when encoding from an MPEG-2 source. Why is this used to test them?

Erm, maybe I misunderstood something but did you look at the title of this thread? This test IS made from raw uncompressed source.

Raw movie frames (21GB lol) can be downloaded from
http://media.xiph.org/ED/

More about the movie
http://orange.blender.org/

benwaggoner

3rd August 2007, 19:43

I modified AddGrain (called AddGrainC) to include a seed parameter to make it deterministic. I'm also still working on and off on a pseudo-fgm method, that works with ffdshow and any video format, but I sort of lost interest since I don't watch many movies now.
Very interesting!

Can you recommend some settings that you think would be appropriate for our testing here?

benwaggoner

3rd August 2007, 20:19

VC-1 Encoding[/COLOR]
Horizontal Vector Range: +/- 1024 pixels
Vertical Vector Range: +/- 256 pixels

Another minor tweak - there's no HD DVD spec requirement about Horizontal/Vertical search range. Again, I doubt it'd matter in this test, but there's no reason to specifically constrain the range.

Sagittaire

3rd August 2007, 21:00

benwaggoner

3rd August 2007, 21:26

Well I don't remenber where I read that. There are no limitation for range vector at level 3 for VC1?
Nor for HD DVD.

PuzZLeR

4th August 2007, 00:26

This test IS made from raw uncompressed source.You're absolutely right. My bad. I got confused with another thread and the fact that "Elephant's Dream" is a commercially available DvD. Thought they were converting from that.

Then by all means - valid test!

Golgot13

4th August 2007, 18:36

Well I don't remenber where I read that. There are no limitation for range vector at level 3 for VC1?

There is on the web only in "public version" (warez web site) a doc White Book from Sonic.
And I know it have inside more restricted than HD DVD specification (but the stream restrictions
on the book are compliant with HD DVD).

May be Ben can give the video restriction for HD DVD (VC1 sure, may be H264 too).
It was not the first ask about the video restriction for HD DVD, may be you or Zambelli
will answer (I'm sure not, but I hope...).

Regards,

Golgot13

Sagittaire

4th August 2007, 23:23

There is on the web only in "public version" (warez web site) a doc White Book from Sonic.
And I know it have inside more restricted than HD DVD specification (but the stream restrictions
on the book are compliant with HD DVD).

In fact it's simply the setting for command registry from WMV9 AP
http://www.microsoft.com/windows/windowsmedia/howto/articles/codecadvancedsettings.aspx#MotionSearchRange

May be Ben can give the video restriction for HD DVD (VC1 sure, may be H264 too).
It was not the first ask about the video restriction for HD DVD, may be you or Zambelli
will answer (I'm sure not, but I hope...).

In fact the most important for quality are:
- GOP lenght at 14 (it's sure for HDDVD?)
- Vecteur range values are good for MPEG2 and H264. It's not really important for quality anyway.
- 7 adaptatives bframes for H264 and MPEG2? It's not really important for quality anyway.
- The big problem is buffer: 9781 for MPEG2, 14745 for VC1 and perhaps 30000 for H264?

Annexe - Update

04.08.2007 - Unlimited range vector for VC1
03.08.2007 - Encoding with libavcodec at 18 Mbps
02.08.2007 - Max adaptative bframe at 7 for VC1
01.08.2007 - Complete Test with x264, pep and libavcodec

will coming ... if you want ... !!!
All the developpers are wellcome ... !!?

drmpeg

5th August 2007, 01:21

Another minor tweak - there's no HD DVD spec requirement about Horizontal/Vertical search range. Again, I doubt it'd matter in this test, but there's no reason to specifically constrain the range.
I see that Sagittaire has made the motion vector range for VC-1 unlimited. Actually, he was correct to begin with. The motion vector range is limited in the VC-1 specification for AP@L3 to -1024/+1023.75 horizontal and -256/+255.75 vertical.

Ron

Dark Shikari

5th August 2007, 01:54

I have a really annoying problem...

I'm running the SSIM test and the number printed in the csv file by the SSIM test is not the number printed on the screen.

The screen value (shown in the output) is around 0.98-0.99 in most frames and is correct. The value in the saved file is around 0.5-0.8 and is completely wrong... but they're for the same frame!

What could be wrong? I'm using the correct script/etc.

akupenguin

5th August 2007, 02:01

02.08.2007 - Max adaptative bframe at 7 for VC1
And why only VC1? While I haven't seen the HD-Blu-DVD-Ray spec, there is no possible technical reason to limit number of B-frames in MPEG2 or H264 either.

Sagittaire

5th August 2007, 02:05

I see that Sagittaire has made the motion vector range for VC-1 unlimited. Actually, he was correct to begin with. The motion vector range is limited in the VC-1 specification for AP@L3 to -1024/+1023.75 horizontal and -256/+255.75 vertical.

Ron

mvrange 1 setting is adaptive and can search up to 512x256 pixels. We tested with mvrange 3 (1024x512 pixels in my memory) but this setting don't change the quality like for the other codec. For Libavcodec for example I use motion at +/- 128 pixel for V/H range and seem really not a problem for libavcodec ... ;-)

Sagittaire

5th August 2007, 02:20

And why only VC1? While I haven't seen the HD-Blu-DVD-Ray spec, there is no possible technical reason to limit number of B-frames in MPEG2 or H264 either.

I would have to keep the bframe at 2 for the VC1... lol

Why speak about completely useless setting for quality ? max GOP lenght or max buffer are by far more important than large bframe number or large motion vector range.

Dark Shikari

5th August 2007, 02:27

Well though SSIM still isn't working right the OPSNR (Global PSNR) as reported by x264 is 46.37 at 6001kbps, which beats the current one.

I'll try to get SSIM working before I submit the logs.

Sagittaire

5th August 2007, 02:29

Dark Shikari

5th August 2007, 02:34

You have certainely a source-encoding desynchro somewhere.
Actually, there was a one-frame sync issue before, but I fixed it long ago.

Using "subtract" shows a nearly perfect encode (with a tiny bit of noise showing the difference). And the SSIM reported on the screen is correct. Its just that the SSIM reported on the screen isn't the SSIM written to disk.

It also can't be a desynchro because, for example, there is a very long section where it gives me 0.87 SSIM. That section has some scenes with very low motion, where desynch would give very high SSIM. And it has scenes with very high motion, where desync could give as low as 0.5 SSIM. But the SSIM is nearly constant...

Sagittaire

5th August 2007, 02:39

Actually, there was a one-frame sync issue before, but I fixed it long ago.

Using "subtract" shows a nearly perfect encode (with a tiny bit of noise showing the difference). And the SSIM reported on the screen is correct. Its just that the SSIM reported on the screen isn't the SSIM written to disk.

It also can't be a desynchro because, for example, there is a very long section where it gives me 0.87 SSIM. That section has some scenes with very low motion, where desynch would give very high SSIM. And it has scenes with very high motion, where desync could give as low as 0.5 SSIM. But the SSIM is nearly constant...

try to fix that with xxx=AssumeFPS(xxx,25) for the source and the encoding.

akupenguin

5th August 2007, 02:41

Why speak about completely useless setting for quality ? max GOP lenght or max buffer are by far more important than large bframe number or large motion vector range.
To simplify the rules; don't impose arbitrary constraints that don't actually matter.
I would be happy with a comparison of unconstrained VBV and GOP, but those actually are constrained in some circumstances so it's up to you what you want to compare.

Dark Shikari

5th August 2007, 02:49

try to fix that with xxx=AssumeFPS(xxx,25) for the source and the encoding.
Changed nothing...

1.000000,0.000000
1.000000,0.000000
1.000000,0.000000
1.000000,0.000000
1.000000,0.000000
1.000000,0.000000
1.000000,0.000000
1.000000,0.000000
1.000000,0.000000
1.000000,0.000000
1.000000,0.000000
1.000000,0.000000
1.000000,0.000000
1.000000,0.000000
1.000000,0.000000
1.000000,0.000000
1.000000,0.000000
0.859322,0.000007
0.948180,0.000550
0.965571,0.005960
0.964541,0.019131
0.963200,0.042045
0.959394,0.074574
0.956373,0.114236
0.953453,0.158541
0.949925,0.204425
0.946661,0.251496
0.942690,0.297007
0.941106,0.339777
0.939467,0.379720
0.937427,0.417226
0.935186,0.451787
0.932795,0.483719
0.930243,0.513539
0.927655,0.541749
0.926063,0.568288
0.924068,0.593254
0.921780,0.616798
0.920453,0.638959
0.917377,0.660497
0.914097,0.681218
0.912452,0.700811
0.911031,0.719925
0.909452,0.737590
0.907213,0.753739
0.905705,0.768649
0.903450,0.782323
0.904477,0.795505
0.899458,0.806337
0.900177,0.817413
0.896104,0.820151
0.896978,0.821368
0.896090,0.822303
0.893987,0.822636
0.892555,0.823039
0.893955,0.824572
0.892872,0.825510
0.891226,0.825848
0.892669,0.827248
0.891866,0.827950
0.890329,0.828055
0.891505,0.829170
0.890780,0.829560
0.889334,0.829460
0.890810,0.830348
0.890095,0.830587
0.888991,0.830056
0.888855,0.830063
0.890288,0.829152
0.891272,0.829616
0.890589,0.829536
0.888957,0.828590
0.890311,0.828816
0.889489,0.828476
0.888026,0.827348
0.889213,0.827524
0.888319,0.827035
0.886644,0.825562
0.887876,0.825454
0.886921,0.824555
0.885153,0.822932
0.884522,0.822114
0.885601,0.820418
0.886591,0.820470
0.886132,0.819940
0.885308,0.818468
0.887169,0.818338
0.886982,0.817383
0.885903,0.815621
0.887288,0.815311
0.886701,0.814147
0.885179,0.812256
0.886386,0.811729
0.885384,0.810263
0.883742,0.807864
0.882930,0.806333
0.884083,0.803457
0.884996,0.802472
0.884227,0.800705
0.882626,0.797564
0.883727,0.795909
0.882473,0.793082
0.880607,0.788911
0.881234,0.786163
0.879552,0.781846
0.877459,0.776738
0.878202,0.773359
0.876956,0.769064
0.875143,0.763991
0.874693,0.760527
0.875399,0.755677
0.876061,0.753632
0.875119,0.751138
0.873281,0.747208
0.874164,0.745321
0.872700,0.742762
0.870950,0.738418
0.872100,0.735692
0.871463,0.732210
0.869850,0.727695
0.870702,0.725389
0.868842,0.721745
0.867508,0.717171
0.867527,0.714998
0.869043,0.710753
0.870287,0.708823
0.869943,0.706475
0.868544,0.702917
0.869265,0.700860
0.867461,0.697816
0.866388,0.691727
0.867583,0.690574
0.867263,0.688661
0.866101,0.685302
0.867528,0.683905
0.866755,0.681107
0.865166,0.677110
0.865006,0.674474
0.866233,0.669985
0.867673,0.668536
0.867287,0.666189
0.866106,0.662506
0.868536,0.661107
0.869133,0.658654
0.868697,0.654937
0.870590,0.653757
0.870174,0.651497
0.868936,0.648008
0.870631,0.647035
0.870131,0.644883
0.868908,0.641559
0.868618,0.639710
0.870395,0.636294
0.871375,0.635723
0.871137,0.634330
0.869787,0.631031
0.871178,0.630320
0.870394,0.628514
0.868904,0.625036
0.870283,0.624187
0.869591,0.622313
0.868028,0.619059
0.869435,0.618591
0.868695,0.616717
0.866955,0.613454
0.866402,0.611726
0.867358,0.608393
0.868482,0.607952
0.867926,0.606767
0.866460,0.603474
0.867545,0.603054
0.866240,0.601419
0.864043,0.598229
0.864654,0.598152
0.864261,0.597085
0.863747,0.594630
0.866323,0.595315
0.866718,0.594632
0.866297,0.592426
0.866477,0.592238
0.867817,0.589712
0.868607,0.590823
0.868047,0.590876
0.866585,0.588671
0.867504,0.589442
0.866959,0.588935
0.866042,0.586316
0.867893,0.587106
0.867537,0.586249
0.866481,0.583842
0.867848,0.584737
0.867824,0.584439
0.866838,0.582154
0.867023,0.581637
0.868089,0.578876
0.869407,0.579969
0.869427,0.580009
0.868813,0.577788
0.871144,0.578705
0.872251,0.578284
0.872815,0.576089
0.875847,0.576976
0.877001,0.576480
0.877246,0.574208
0.879627,0.575125
0.880108,0.574610
0.878661,0.572402
0.877614,0.572274
0.877701,0.569543
0.877494,0.570809
0.876097,0.570986
0.873773,0.569075
0.873833,0.570281
0.872530,0.570372
0.870694,0.568181
0.871458,0.569215
0.870899,0.568870
0.869658,0.566725
0.870816,0.567685
0.870534,0.567303
0.870022,0.565039
0.870907,0.564865
0.872807,0.562268
0.874055,0.563231
0.873762,0.563200
0.872144,0.561069
0.874467,0.561269

is the first ~200 frames of SSIM even though x264 reported an SSIM of over 0.9885 :)

Sagittaire

5th August 2007, 02:53

To simplify the rules; don't impose arbitrary constraints that don't actually matter.

I used this limitation for H264 because in practice x264 don't work with more than 2 bframes (trahald nal_hrd and pulldown patch, pyramid bframe) and x264 produce the best result a this test.

I would be happy with a comparison of unconstrained VBV and GOP, but those actually are constrained in some circumstances so it's up to you what you want to compare.

Well in fact it's 9 781 for MPEG2 (MP@HL), 14 745 for VC1 ... but 30 000 Kbits is perhaps complaint for HDDVD too (BD use 30 000 Kbits). I don't have clear answer on this subject: Sergey A. Sablin say 30 000 Kbits and benwaggoner say 14 745 for all the video codec. 30 000 vs 14 745 will not change the result for 6/20 Mbps (average/max) encoding but it's not the case for 18/28 Mbps encoding.

Sagittaire

5th August 2007, 02:56

is the first ~200 frames of SSIM even though x264 reported an SSIM of over 0.9885 :)

You can upload your file somewhere ... ?

Dark Shikari

5th August 2007, 03:04

You can upload your file somewhere ... ?
The output .h264 stream? Its quite large... I'll see if I can find a place. Do you have an FTP I could dump it on overnight?

Edit: Found a site of that should be able to barely fit it with a few megabytes margin. I'll post the link in the morning.

Dark Shikari

5th August 2007, 05:38

Download the raw H264 stream, 6Mbit (http://tjhsst.edu/~jgarrett/6000_3.h264)

pandy

5th August 2007, 15:08

B - Rules

Rule 1 : Source

Uncompressed source is available Here (http://orange.blender.org/blog/original-lossless-source-available/) for reproduce the test.
Open source Elephant Dream movie, video 1920*1080 PNG lossless, audio 5.1 Flac lossless, 15 691 frames

Hm. i think that ED is not optimal source due their artificial character.
Please also use a raw sources which represent other than artificial generated images sources (i believe that over 60 - 70% sources are CG free).

eg such as
http://www.ldv.ei.tum.de/Members/tobias/sequences

PS
Please use also interlace not only progressive source.

Dark Shikari

5th August 2007, 15:14

MfA

5th August 2007, 15:35

SSIM cares much less about noise than PSNR.

As for interlaced, lets just pretend it doesn't exist and stick to 720p50/60 ... you can't test interlaced content in isolation, the technology necessary to display it on modern displays (motion compensated deinterlacing) will interact with the coding artifacts and we don't have equivalent technology available to do the testing in software. Besides, interlacing is the spawn of evil.

Dark Shikari

5th August 2007, 15:56

Anyways can someone check out my above posted H.264 stream? Since I can't get the SSIM to work.

Since the OPSNR is better than the one currently posted and the optimization I used is tuned for SSIM, not PSNR, it should be pretty good...

Tack

5th August 2007, 16:05

[...]the technology necessary to display it on modern displays (motion compensated deinterlacing) [...]Do any modern consumer level displays do motion compensated deinterlacing? I thought even the more higher end consumer displays were pretty much motion adaptive across the board.

Sagittaire

5th August 2007, 16:25

Sagittaire

5th August 2007, 16:27

Annexe - Update

05.08.2007 - Max adaptative bframe at 7 for VC1, H264 and MPEG2
04.08.2007 - Unlimited range vector for VC1
03.08.2007 - Encoding with libavcodec at 18 Mbps
02.08.2007 - Max adaptative bframe at 7 for VC1
01.08.2007 - Complete Test with x264, pep and libavcodec

will coming ... if you want ... !!!
All the developpers are wellcome ... !!?

buzzqw

5th August 2007, 16:38

could you update the encoding string on first page ?

thanks!

BHH

Sagittaire

5th August 2007, 16:40

Download the raw H264 stream, 6Mbit (http://tjhsst.edu/~jgarrett/6000_3.h264)

your encoding produce 89.73031441
My encoding produce 89.54523791

Dark Shikari

5th August 2007, 16:41

your encoding produce 89.73031441
My encoding produce 89.54523791
\o/ It worked, mine's top now :cool:

For the curious, I used my optimized SSIM-SATD x264 build (patched with nal-hrd) with the following commandline (third pass):

./x264HRDOpt.exe --threads 1 --thread-input --keyint 14 --min-keyint 2 --vbv-maxrate 20000 --vbv-init 1.0 --vbv-bufsize 14745 --mvrange 511 --merange 64 --level 4.1 --nal-hrd --bframe 2 --b-rdo --bime --weightb --ref 3 --mixed-refs --direct auto --deblock -1:-1 --qpmin 1 --bitrate 6000 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.25 --partitions "all" --8x8dct --me "umh" --subme 7 --no-fast-pskip --trellis 2 --aud --sar 1:1 --progress -o 6000_3.h264 elephantsDream.avs

The --merange was probably unnecessary and slowed it down a lot given my very slow ME function.

arfster

5th August 2007, 19:32

Hm. i think that ED is not optimal source due their artificial character.
Please also use a raw sources which represent other than artificial generated images sources (i believe that over 60 - 70% sources are CG free).

eg such as
http://www.ldv.ei.tum.de/Members/tobias/sequences

I'd agree with this - you're always going to get the above objection unless you have some high quality outdoors origin stuff. At the very least you'd end up with two sets of data, and some potentially interesting comparisons.

Does anyone know what would be the best approach for encoding the above though? Just feed them into avisynth, or is some processing needed beforehand? I'd be willing to do it anyway, got a couple of fast PCs here - just would be nice to get some expert advice before encoding away for several days :-)

Inventive Software

6th August 2007, 10:50

This is also why I suggested about a film grain filter for the AviSynth script, but you'd need something that generates the same grain each time AviSynth is loaded.

pandy

6th August 2007, 12:47

The problem with live-action footage is that often it has a lot of noise when unprocessed, meaning that SSIM is really testing the noise-retention ability of the codec, rather than quality.

Hmmm - noise is natural part of video, noise is good coz:
- subjective sharpening
- less banding
- bitrate stabilisation

So proper amount of noise is very important but the problem is how many noise we need to achieve a good, high quality video.
Noise itself is not problem.

pandy

6th August 2007, 12:50

This is also why I suggested about a film grain filter for the AviSynth script, but you'd need something that generates the same grain each time AviSynth is loaded.

Hm... better idea is to generate uncompressed noise video clip (as a reference) and add to the another clip. Always the same, equal for all.

Dark Shikari

6th August 2007, 13:39

your encoding produce 89.73031441
My encoding produce 89.54523791
Can you update the first post with the new numbers?

akupenguin

6th August 2007, 13:50

Hmmm - noise is natural part of video, noise is good coz:
- subjective sharpening
Add it at playback time.
- less banding
Noise hides banding if it's added at playback time.
Noise increases banding at any given bitrate if it's added before encoding, because it takes bits away from the actual content.
- bitrate stabilisation
You mean, wastes bitrate equally everywhere. And why do you care about a "stable" bitrate anyway? You don't see bitrate, you see quality.

Noise is always a problem. The only argument for including it in a test is that non-CG movies have a certain amount of unavoidable noise, and you want the test to reflect the imperfect real world.

Inventive Software

6th August 2007, 14:08

What about commercial CG movies like The Incredibles, Finding Nemo, and the like? They AFAIK don't have noise....

Sharktooth

6th August 2007, 14:12

They have added noise (studios are used to that) and since there arent uncompressed sources available there will sourely be DCT noise from codecs...

Sagittaire

6th August 2007, 17:34

Can you update the first post with the new numbers?

Unfortunaly there are a bug from nah_hrd flag for trahald patch. StreamEyes show big overflow. Anyway I think that it's just HRD flags problem and stream is certainely internaly HDDVD compliant. Anyway no doubt that your build obtain better SSIM than my build.

Dark Shikari

6th August 2007, 17:37

Unfortunaly that are a bug from nah_hrd flag for trahald patch. StreamEyes show big overflow. Anyway I think that it's just HRD flags problem and stream is certainely internaly HDDVD compliant. Anyway no doubt that your build obtain better SSIM than my build.
Wait, I used the same NAL_HRD patch that you did; why did mine have problems and yours didn't?

Sagittaire

6th August 2007, 18:10

Wait, I used the same NAL_HRD patch that you did; why did mine have problems and yours didn't?

I use in fact an old build with different NAL_HRD patch. Anyway no problem for your patch itself: the SSIM is better.

Dark Shikari

6th August 2007, 18:35

I use in fact an old build with different NAL_HRD patch. Anyway no problem for your patch itself: the SSIM is better.
Ah so the current NAL-HRD doesn't actually work right anyways :p

Yeah, I'm still trying to improve the SSIM. I'm currently working on optimizing the metric used by RDO, hopefully that will yield some results.

akupenguin

6th August 2007, 18:38

Yes, the reason the HRD patch isn't applied is that it doesn't attempt to generate the right numbers, it just fills in the HRD fields with something. And I don't know how to compute the right numbers either, so I can't fix it.

Sagittaire

6th August 2007, 18:50

Yes, the reason the HRD patch isn't aplpied is that it doesn't attempt to generate the right numbers, it just fills in the HRD fields with something. And I don't know how to compute the right numbers either, so I can't fix it.

I will report the bug to trahald ...

benwaggoner

6th August 2007, 23:13

I'm still trying to track down some film source with clear rights I can distribute for parallel testing with some other content. Looks like I've got an angle on something we shot ourselves.

But before I spend a bunch of time on getting the assets unarchived and edit something together, I just wanted to make sure folks aren't going to immediately object to anything I do on the grounds that I cherrypicked :).

So, this worth me spending some (probably a bunch!) of time on?

Sagittaire

6th August 2007, 23:23

I'm still trying to track down some film source with clear rights I can distribute for parallel testing with some other content. Looks like I've got an angle on something we shot ourselves.

Not possible to have trailer from major studio for example ... ???

Anyway why not make encoding for this source in a first time. I want see if my vc1 profil is really bad ... lol.

4) Why not ask Microsoft for VC-1 encoding advice? We would've been happy to help. At the very least we could've provided advice on encoding settings.

... but no encoding from MS at this time.

Golgot13

6th August 2007, 23:46

Not possible to have trailer from major studio for example ... ???

Yes, it is very hard to have some right (I know, need to explain many time it's for test
and there is no money...). It is same for trailers because major studio need agreement from producer.

Anyway why not make encoding for this source in a first time. I want see if my vc1 profil is really bad ... lol.

... but no encoding from MS at this time.

May be MS team are in holiday but Ben is here :)
I have the same result than you, Sagitaire, with the vc1_enc on PEP solution (1.06).
I think PEP can not do a better quality (near of surely).

I can give some HDV footage from Tri-CCD camcorder but it is MPEG2 HD video file.

Regards,

Golgot13

benwaggoner

6th August 2007, 23:46

Not possible to have trailer from major studio for example ... ???
As uncompressed source with wide-open redist rights? That's a lot to ask, and I haven't found one yet.

Trailers are also somewhat different than a movie, which can change things. A LOT more time spent in fades to/from blacks and in title slides, a lot less in credits. Often more shots...

Anyway why not make encoding for this source in a first time. I want see if my vc1 profil is really bad ... lol.
That'll happen in parallel, but folks a pretty heads down this week.

benwaggoner

7th August 2007, 00:54

So, it looks like the source I could share is right now about 45 minutes of 10-bit 4:2:2 D5 telecined from 35mm. It's stuff we shot ourselves, of a tall ship (Lady Washington) in the Puget Sound. Lots of shots of water, the ship, sailors doing stuff on the ship. So, I'm thinking about doing something like:

10 total minutes
Focusing on the more complex bits, but with a variety to stress rate control.
Matted to 1.85:1
With some fades to/from black and cross dissolves
Some kind of motion graphics opening credits and scrolling credits at the end. I'll keep those short, to have the same ballpark percent of credits as a typical film.

How does that sound? Not like there are any explosions in there, but some good frames with a nice combination of high detail (rigging) and flat gradients (the sky). Some good handheld stuff.

Inventive Software

7th August 2007, 10:47

That sounds excellent! Gimme...... :D

zambelli

7th August 2007, 11:38

So, it looks like the source I could share is right now about 45 minutes of 10-bit 4:2:2 D5 telecined from 35mm.
Ben, do you plan on subsampling that down to YV12? I suppose we could share out v210 copies, but the download sizes would be ridiculous and the ambiguity of having everybody do their own downsampling to 4:2:0 would be too great to yield consistent results.

Sagittaire

7th August 2007, 11:57

Ben, do you plan on subsampling that down to YV12? I suppose we could share out v210 copies, but the download sizes would be ridiculous and the ambiguity of downsampling to 4:2:0 would be too great to yield consistent results.

compression with really efficient lossless codec (open source like ffv1 for example) could be really usefull here.

zambelli

7th August 2007, 12:06

VC1 stream here use internal PP flags. Internal flags adjust automatically the PP decoding for the DMO decoder if you don't use Force Process Mode command line registry and I don't use this command registry.
Oh, I wouldn't be so sure that the DMO decoder respects the PP flags in the VC-1 bitstream. :) But since neither CoreAVC nor FFfdshow do postprocessing for H.264 by default, it's probably best if VC-1 postprocessing is forced OFF in the DMO too. I always disable it when doing any PSNR/SSIM tests.

This test IS made from raw uncompressed source.
On that subject... The Elephants Dream PNGs, while uncompressed RGB, are not perfect. The downsampling to 8-bits per channels was done with significant banding in dark areas. Not that it really affects the encoder comparison, but if this was an HD-DVD/BluRay production competition, this "ED" source would be a great example of a poor master. :)

The big problem is buffer: 9781 for MPEG2, 14745 for VC1 and perhaps 30000 for H264?
I'm pretty sure we established that the buffer size was the same for all 3 codecs in the HD-DVD spec:
http://forum.doom9.org/showthread.php?p=881160#post881160

I see that Sagittaire has made the motion vector range for VC-1 unlimited. Actually, he was correct to begin with. The motion vector range is limited in the VC-1 specification for AP@L3 to -1024/+1023.75 horizontal and -256/+255.75 vertical.
Well, if that's the maximum, there's no point in limiting it. And in a 1920x1080 encode that range would be pretty useless anyway. If an object is moving that much between frames, it might be time for an I frame. ;)

mvrange 1 setting is adaptive and can search up to 512x256 pixels. We tested with mvrange 3 (1024x512 pixels in my memory) but this setting don't change the quality like for the other codec. For Libavcodec for example I use motion at +/- 128 pixel for V/H range and seem really not a problem for libavcodec ... ;-)
In the Microsoft VC-1 encoders only one of the MV Range settings is adaptive - the rest are fixed. And the adaptive setting doesn't even go all the way up to maximum. It's generally always best to use the adaptive MVRange setting because setting too large of an MVRange can actually result in false positive matches - and takes a very long time.

but no encoding from MS at this time.
Sorry, been busy. I'll try to encode something when I catch some free tme.

zambelli

7th August 2007, 12:08

compression with really efficient lossless codec (open source like ffv1 for example) could be really usefull here.
You don't have to worry about that, Ben likes to talk about Lagarith nearly as much as he likes to talk about VC-1. ;)

benwaggoner

7th August 2007, 14:59

Ben, do you plan on subsampling that down to YV12? I suppose we could share out v210 copies, but the download sizes would be ridiculous and the ambiguity of having everybody do their own downsampling to 4:2:0 would be too great to yield consistent results.
I was thinking an IYUV .AVI file, for the reasons you suggest.

Although i don't know that the download size would be that much better :). I'd obviously .zip it up as well.

benwaggoner

7th August 2007, 15:00

compression with really efficient lossless codec (open source like ffv1 for example) could be really usefull here.
Yeah, Lagarith would be the other thing I might use. The nice thing about IYUV is that it'll decode on Mac as well.

Inventive Software

7th August 2007, 15:17

How big would the download be roughly? If it's uncompressed, then it'd be about 30 GB+, surely?

Sagittaire

7th August 2007, 15:34

I'm pretty sure we established that the buffer size was the same for all 3 codecs in the HD-DVD spec:
http://forum.doom9.org/showthread.ph...160#post881160

14 745 for VC1, H264 and MPEG2? Problem is that 14 745 Kbits is not compliant with MP@HL profil. With all the professional MPEG2 encoder you can't use 14 745 Kbits for buffer, 9781 Kbits is always the max available. Moreover 30 000 Kbits for H264 seem work for Toshiba HDDVD player.

akupenguin

7th August 2007, 16:50

With all the professional MPEG2 encoder you can't use 14 745 Kbits for buffer
But you're using libavcodec, which will ignore MP@HL if you tell it to.

zambelli

7th August 2007, 18:46

14 745 for VC1, H264 and MPEG2? Problem is that 14 745 Kbits is not compliant with MP@HL profil. With all the professional MPEG2 encoder you can't use 14 745 Kbits for buffer, 9781 Kbits is always the max available. Moreover 30 000 Kbits for H264 seem work for Toshiba HDDVD player.
Well, as we know, players are not always the best measure of compliance. Just because something plays doesn't mean it's made according to the standard. I bet most DVD players would play bitrates above 9.8 Mbps these days too, for example.

hank315

7th August 2007, 19:14

Sagittaire

7th August 2007, 19:45

I don't understand why the VBV buffer is a problem for HD MPEG2.
This clip is 1920*1080, average bitrate: 18000, max bitrate: 28000 and a buffer of 9781 Kbits.
Let's scale it down to DVD-SD 720x576 resolution which means only 1/5 of the nr. of Macroblocks.
This yields an average bitrate: 3600, max bitrate 5600 and a buffer of 1956 Kbits.
For DVD-SD an average bitrate of 6000 and max bitrate of 9000 is quite normal with a buffer of 1835 Kbits.

So IMHO the VBV buffer isn't the problem but bitrate is...

The delta for relative complexity scene is really very high for Elephant Dream. At 18 Mbps there are very simple part (quantizer saturation at q1) and really complex part (vbv saturation at q10). It's a very hard source for Rate Control. It's really hard for HCEnc in these complex part to keep good quality: the PSNR for HCEnc is simply very low in these part and produce low OPSNR.

Now comparison between HDDVD and DVD
- average at 6Mbps and max at 8 Mbps for 720*480*24 frame
if there are vbv saturation you can't use buffer and Iframe size are directly limited by max bitrate: 8000000/(720*480*24) = 0.96 bits/pixel for IFrame
- average at 18Mbps and max at 28 Mbps for 1920*1080*24 frame
if there are vbv saturation you can't use buffer and Iframe size are directly limited by max bitrate: 28000000/(1920*1080*24) = 0.56 bits/pixel for IFrame

And in practice HDDVD don't use 28 Mbps for max bitrate (it's a possible scenario but only with 3 DD+ at 640 Kbps for example). If you make HDDVD with PIP and/or trueHD the max bitrate will be at 20 - 24 Mbps. The problem for HDDVD vs BD is not capacity (30 GB is good) but band-width (30.24 Mbps). BD can use MPEG2 with higher band-width at 45 Mbps and capacity is not really the problem.

hank315

7th August 2007, 21:51

if there are vbv saturation you can't use buffer and Iframe size are directly limited by max bitrate: 8000000/(720*480*24) = 0.96 bits/pixel for IFrame
This situation is very rare, mostly you run into VBV trouble after loading the large I-frame, not at the end of a GOP.
Also an encoder should never run into such a situation, it should know it has to handle such an I-frame at the start of a new GOP so in my eyes your example is more a RC/bitrate problem than a VBV problem.
I wanted to point out that it's more likely you will run into VBV problems at DVD-SD resolutions than at HD resolutions because the VBV/bitrate ratio is much worse for DVD-SD.
The buffer size for HD is large enough, only the relative low maximum bitrate may prevent to fill it fast enough.

Sagittaire

8th August 2007, 01:12

This situation is very rare, mostly you run into VBV trouble after loading the large I-frame, not at the end of a GOP.

Well it's the case for HCEnc and all the encoder for this source in really complex part. HCEnc must use very high quantizer to respect the vbv in these complex part.

Also an encoder should never run into such a situation, it should know it has to handle such an I-frame at the start of a new GOP so in my eyes your example is more a RC/bitrate problem than a VBV problem.

well this H264 encoder have this problem for this source (GOP at 14 frames). Libavcodec have this problem too.

H264 encoding at 12 Mbps, max at 24 Mbps
2809 1.6533 +0.0668 37 -38 38.7684 48.5288
2810 1.8734 +0.0755 36 -38 37.8276 48.5122
2811 2.1074 +0.0738 47 -43 36.9203 48.4915
2812 2.3277 +0.0617 44 -45 36.0954 48.4663
2813 2.3589 +0.0705 43 -52 36.0339 48.4409
2814 2.5663 +0.0639 53 -53 35.2827 48.4106
2815 2.6009 +0.0671 50 -50 35.1891 48.3799
2816 2.6380 +0.0578 51 -59 35.0715 48.3485
2817 2.6734 +0.0648 54 -54 34.9776 48.3167
2818 2.4900 +0.0804 49 -50 35.6235 48.2897
2819 2.4826 +0.0919 50 -50 35.6302 48.2629
2820 2.4433 +0.1026 49 -49 35.7463 48.2370
2821 2.2726 +0.1086 44 -44 36.3861 48.2151
2822 2.2432 +0.1087 46 -45 36.4622 48.1936
2823 2.2279 +0.1196 41 -46 36.5156 48.1726
2824 2.2211 +0.1186 43 -47 36.5375 48.1518
2825 2.2214 +0.1280 40 -40 36.5295 48.1310
2826 2.0731 +0.1160 38 -40 37.1995 48.1136
2827 2.1982 +0.1196 42 -41 36.6129 48.0935
2828 2.0714 +0.1200 42 -41 37.2132 48.0762
2829 2.2099 +0.1283 45 -45 36.5766 48.0561
2830 2.0709 +0.1192 38 -38 37.2061 48.0390
2831 2.9655 +0.0514 64 -64 34.0914 48.0027 <- Iframe
2832 2.4976 +0.0801 49 -49 35.6044 47.9776
2833 2.2904 +0.0944 45 -42 36.3462 47.9569
2834 2.2667 +0.0954 49 -42 36.4126 47.9366
2835 2.2310 +0.1075 43 -44 36.5147 47.9170
2836 2.2219 +0.1220 43 -43 36.5280 47.8975
2837 2.2238 +0.1325 53 -53 36.5191 47.8780
2838 2.2259 +0.1298 44 -44 36.5085 47.8586
2839 2.2068 +0.1288 52 -52 36.5622 47.8396
2840 2.2114 +0.1295 43 -45 36.5384 47.8205
2841 2.2121 +0.1353 47 -47 36.5312 47.8015
2842 2.2070 +0.1219 43 -45 36.5618 47.7828
2843 2.2054 +0.1269 41 -43 36.5629 47.7641
2844 2.2074 +0.1250 46 -46 36.5438 47.7455
2845 2.9122 +0.0635 69 -69 34.2024 47.7126 <- Iframe
2846 2.4790 +0.0932 56 -54 35.6329 47.6896
2847 2.2892 +0.1022 44 -58 36.3465 47.6704
2848 2.2697 +0.1131 44 -44 36.4097 47.6516
2849 2.2609 +0.1154 43 -43 36.4440 47.6330
2850 2.2521 +0.1191 45 -43 36.4518 47.6146
2851 2.2488 +0.1335 46 -46 36.4714 47.5963
2852 2.2642 +0.1307 47 -47 36.4313 47.5780
2853 2.2554 +0.1303 44 -44 36.4677 47.5599
2854 2.2477 +0.1266 49 -46 36.4789 47.5419
2855 2.2355 +0.1285 46 -46 36.4976 47.5241
2856 2.2429 +0.1292 51 -45 36.4888 47.5064
2857 2.2482 +0.1373 39 -49 36.4906 47.4888
2858 2.2539 +0.1304 46 -46 36.4805 47.4712
2859 2.7649 +0.0622 50 -53 34.7370 47.4443
2860 2.4919 +0.0875 48 -49 35.6332 47.4228
2861 2.3022 +0.0976 40 -42 36.3175 47.4048

Manao

8th August 2007, 11:32

Well it's the case for HCEnc and all the encoder for this source in really complex partDon't make generalisation. It's not because none of the encoders you're using handle correctly the complex parts of the video that it's impossible to do so.

Hank315 is right. An encoder should be able to make big intra frame, and the size of these frames should be restricted by the VBV size, not by the average frame size at the maximum bitrate.

Sagittaire

8th August 2007, 12:27

Don't make generalisation. It's not because none of the encoders you're using handle correctly the complex parts of the video that it's impossible to do so.

In fact I speak about vbv saturation with this source. All the encoder in VBR mode with classic curve compression setting will have difficulty to maintain quality (aka quantizer) in these really complex part.

Hank315 is right. An encoder should be able to make big intra frame, and the size of these frames should be restricted by the VBV size, not by the average frame size at the maximum bitrate.

Well I'am agree with that. But it's in practice not always the case. I think for example there are very high improvement potential for Libavcodec Rate Control.

Inventive Software

9th August 2007, 12:06

That may be the case, but remember libavcodec borrows from several other open-source projects as and when it's needed, so for rate-control, what's best in the OS world?

Sagittaire

10th August 2007, 03:03

The command-line encoder in the PEP package is really more of a test tool (I think it might even be deprecated at this point). The studios are all using the non-cmd-line encoder.

Well now test with pep.exe at 6 Mbps with PP1 forced: 43.33 dB

Minimum Average Maximum

Y: Mean Absolute Deviation: 0.0000 13.5207 5.4359
U: Mean Absolute Deviation: 0.0000 0.8102 1.8150
V: Mean Absolute Deviation: 0.0000 0.8846 1.5686
Sum: Mean Absolute Deviation: 0.0000 25.6513 3.6997

Y: Mean Deviation: -0.9311 0.6090 1.0109
U: Mean Deviation: -0.3636 0.0775 0.5885
V: Mean Deviation: -0.5276 0.0748 0.3277
Sum: Mean Deviation: -0.6207 1.3430 0.6739

Y: Mean Square Error: 0.0000 4.1491 65.0187
U: Mean Square Error: 0.0000 0.6987 6.8956
V: Mean Square Error: 0.0000 0.7902 5.9206
Sum: Mean Square Error: 0.0000 3.0142 43.4682

Y: Root Mean Square Error: 0.0000 1.8002 8.0634
U: Root Mean Square Error: 0.0000 0.7003 2.6259
V: Root Mean Square Error: 0.0000 0.7548 2.4332
Sum: Root Mean Square Error: 0.0000 1.5514 6.5930

Y: PSNR: 30.0004 41.9513 1.#INF
U: PSNR: 39.7451 49.6881 1.#INF
V: PSNR: 40.4072 49.1536 1.#INF
Sum: PSNR: 31.7491 43.3391 1.#INF
Minimum Average Maximum

Mean Absolute Deviation: 0.0000 25.6513 3.6997
Mean Deviation: -0.6207 1.3430 0.6739
PSNR: 31.7491 43.3391 1.#INF

And now result with vc1_enc.exe with PP1 in flag: 43.75 dB

Minimum Average Maximum

Y: Mean Absolute Deviation: 0.0000 12.3687 5.4406
U: Mean Absolute Deviation: 0.0000 0.7497 1.5126
V: Mean Absolute Deviation: 0.0000 0.8131 1.4572
Sum: Mean Absolute Deviation: 0.0000 23.4965 3.6962

Y: Mean Deviation: -1.0000 0.3257 0.6041
U: Mean Deviation: -0.1913 0.0610 0.6475
V: Mean Deviation: -0.4243 0.0506 0.3930
Sum: Mean Deviation: -0.6667 0.7927 0.4057

Y: Mean Square Error: 0.0000 3.8036 67.1990
U: Mean Square Error: 0.0000 0.5776 4.8270
V: Mean Square Error: 0.0000 0.6528 4.0074
Sum: Mean Square Error: 0.0000 2.7408 44.9051

Y: Root Mean Square Error: 0.0000 1.6975 8.1975
U: Root Mean Square Error: 0.0000 0.6459 2.1970
V: Root Mean Square Error: 0.0000 0.6934 2.0019
Sum: Root Mean Square Error: 0.0000 1.4620 6.7011

Y: PSNR: 29.8572 42.3289 1.#INF
U: PSNR: 41.2941 50.5149 1.#INF
V: PSNR: 42.1022 49.9830 1.#INF
Sum: PSNR: 31.6078 43.7521 1.#INF
Minimum Average Maximum

Mean Absolute Deviation: 0.0000 23.4965 3.6962
Mean Deviation: -0.6667 0.7927 0.4057
PSNR: 31.6078 43.7521 1.#INF

And here the xml project for pep.exe:
- default RC and HVS setting from 1080p_HDDVD.PEP.xml template
- Complexity at maxi, Chroma at maxi, bframe at 7

<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/DigitalMedia/Codecs/2006/12/01/ParallelEncoderProject">
<ProjectName>Project1</ProjectName>
<PublishedFileURL>C:\Master\Project1.vc1</PublishedFileURL>
<PublishedLogFileURL>C:\Master\Project1.log</PublishedLogFileURL>
<OutputDirectory>C:\Master</OutputDirectory>
<SourceFiles>
<SourceFile>C:\Master\1920x1080.yuv</SourceFile>
</SourceFiles>
<AllowPtoISwitch>true</AllowPtoISwitch>
<AspectRatioIndex>1</AspectRatioIndex>
<BFrames>7</BFrames>
<Bitrate>6000</Bitrate>
<BufferSize>1843200</BufferSize>
<ChromaSearch>full</ChromaSearch>
<ClosedCaptionsPresent>false</ClosedCaptionsPresent>
<ColorFormatFlag>false</ColorFormatFlag>
<Denoise>false</Denoise>
<EncoderComplexity>4</EncoderComplexity>
<EncodingMode>VBR</EncodingMode>
<EncodingHeight>1080</EncodingHeight>
<EncodingWidth>1920</EncodingWidth>
<FrameRate>29.97</FrameRate>
<GOPLength>14</GOPLength>
<GOPType>Open</GOPType>
<Height>1080</Height>
<InterlaceMode>InterlacedTelecine</InterlaceMode>
<LoopFilter>true</LoopFilter>
<MarkIn>0</MarkIn>
<MarkOut>15689</MarkOut>
<MinEncodeQP>1.0</MinEncodeQP>
<MVRange>1</MVRange>
<PeakBitrate>20000</PeakBitrate>
<PDeltaQP>0.0</PDeltaQP>
<PerceptualOptionLevel>3</PerceptualOptionLevel>
<Segments>1</Segments>
<ThreadCount>0</ThreadCount>
<Width>1920</Width>
<BDeltaQP>
<Relative>0.0</Relative>
</BDeltaQP>
<FirstPassSettings>
<ChromaSearch>off</ChromaSearch>
<EncoderComplexity>0</EncoderComplexity>
<MVRange>0</MVRange>
</FirstPassSettings>
<CodecData>
<Property name="BFramePosOpt" type="long" value="1"/>
<Property name="DarkNoiseControl" type="long" value="0"/>
<Property name="DCBias" type="long" value="1"/>
<Property name="DQuantStrength" type="long" value="4"/>
<Property name="FavorInterLevel" type="long" value="3"/>
<Property name="MotionMatch" type="long" value="4"/>
</CodecData>
<UIData>
<RecentPublishedFileURL/>
</UIData>
</Project>

If you want really result from pep then I can use result from pep.
Anyway previous result from vc1_enc.exe with optimized setting are really better for PSNR/SSIM.
If the xml profil is not the best, it's possible to make other encoding with better xml profil.

benwaggoner

10th August 2007, 05:42

@ Sagittaire,

Running your first pass at Complexity 2 with MVRange 1 will give you better rate control that your current settings.

Threadcount 1 would also help a bit in some of the shots with a lot of vertical motion.

And 7 B-Frames? I thought we said that wasn't going to help :)! Well, if you're doing segment reencoding, that might work nicely for the credits, saving you some bits to use on the main feature. But the main sequence should use 1 or 2 B-frames.

Perceptual option in general tunes for visual quality instead of PSNR. In theory, using it could rise SSIM and lower PSNR, but I haven't tested that much with objective measures.

There's probably a few other things, but it's late and my XML translater is tired :).

zambelli

10th August 2007, 10:40

Well now test with pep.exe at 6 Mbps with PP1 forced: 43.33 dB
And now result with vc1_enc.exe with PP1 in flag: 43.75 dB

What do you mean by "in flag"? If you're talking about the bitstream PP flags, they're not useful, WMV9 Decoder DMO doesn't care about them at all. With "in flag" you're probably just using automatic PP.

Also, why PP1? There's no need for post-processing in PSNR/SSIM calculation. CoreAVC decoder isn't doing postprocessing, neither are HD-DVD players, so it's only fair that no PP gets used for VC-1 decoding too.
<BFrames>7</BFrames>
Seriously? You're not setting the maximum there - you're actually telling the encoder to insert 7 B-frames between every reference frame! I'm surprise the PSNR wasn't 20 dB. :)
<MVRange>1</MVRange>
Use adaptive MV range if possible.
<PerceptualOptionLevel>3</PerceptualOptionLevel>
Is this Dquant or Adaptive Dead Zone? I can't remember the mapping of the XML properties off top of my head.
If it's dquant, enable it only for I & P frames, and probably only use it on 12 and 18 Mbps encodes.

<BDeltaQP>
<Relative>0.0</Relative>
</BDeltaQP>

When doing the 12 and 18 Mbps encodes, you can probably set this to 1.0.
<FirstPassSettings>
<MVRange>0</MVRange>
</FirstPassSettings>
I think this should be opposite - use short range in 1st pass and use adaptive in 2nd pass.

If the xml profil is not the best, it's possible to make other encoding with better xml profil.
I'll try to get an optimized version out to you soon.

Golgot13

10th August 2007, 11:05

Hi all,

Ben and Zambelli, thank you to give nice comment about the option of VC1 encoder
(PEP or WM9). Sagitairre try to do the best VC1 encoded file with ED source.
If you not agree with some option => you can, yourself, make a best encoding of this file.

I sure Ben can make the perfect encoding from PEP :cool:

Regards,

Golgot13

Inventive Software

10th August 2007, 11:12

For shits and giggles, I have the uncompressed SD source, cause I'm nearly gone on HD space and can't have the HD source yet. Can VC-1 people (Sagittaire, benwaggoner, zambelli etc) recommend command-lines for the wmcmd.vbs, or a PRX with certain settings? And registry settings if need be. ;)

EDIT: And what in holy terminology is PEP?! :D

GmorG McRoth

10th August 2007, 11:27

EDIT: And what in holy terminology is PEP?! :D

Ether short for "Penis Enlarging Pump", or name of command line VC1 encoder.

CruNcher

10th August 2007, 12:19

benwaggoner

10th August 2007, 20:19

I think this should be opposite - use short range in 1st pass and use adaptive in 2nd pass.
For this clip, I think we'd actually want to use adaptive for both passes, since there's some pretty high-motion spots.

Encoding with a single thread would also get another slight boost in shots with vertical motion.

benwaggoner

10th August 2007, 21:38

Camera and Lense ? Resolution ?, it sounds good especialy the water scenes a uncompresed screenshot of the scene would be nice to have an idear of how the transfer looks :)
Not sure - I'll be picking up some of the raw source next week.

Sagittaire

11th August 2007, 00:34

What do you mean by "in flag"? If you're talking about the bitstream PP flags, they're not useful, WMV9 Decoder DMO doesn't care about them at all. With "in flag" you're probably just using automatic PP. Also, why PP1? There's no need for post-processing in PSNR/SSIM calculation. CoreAVC decoder isn't doing postprocessing, neither are HD-DVD players, so it's only fair that no PP gets used for VC-1 decoding too.

Well I don't know really the HDDVD specifications for VC1. But if you can set the PP in bitstream flag it's perhaps because hardware decoding will use post-process. Post process for VC1 is perhaps a official decoding way and part of the standard for this codec?
http://forum.doom9.org/showthread.php?p=870488#post870488

Seriously? You're not setting the maximum there - you're actually telling the encoder to insert 7 B-frames between every reference frame! I'm surprise the PSNR wasn't 20 dB. :)

Yes seriousely. Bframe are adaptative here. VC1 will use 7 bframe only if it's usefull. Anyway certainely that for 99% of time vc1 will use 0,1,2 or 3 bframe exactly like the other codec.

Use adaptive MV range if possible.

previous xml pep profil use adaptative MV range.

Is this Dquant or Adaptive Dead Zone? I can't remember the mapping of the XML properties off top of my head.
If it's dquant, enable it only for I & P frames, and probably only use it on 12 and 18 Mbps encodes.

Previous profil for vc1_enc.exe use this setting.

I think this should be opposite - use short range in 1st pass and use adaptive in 2nd pass.

Well don't change anything. First pass generate only stat and frame type for second pass and quant/size prediction. You have better prediction if you use the same setting for the first and second pass. vc1_enc.exe profil use 3 pass only for produce best possible prediction in the last pass.

I'll try to get an optimized version out to you soon.

Well it's useless. If you compare VC1 and H264 for each frame then H264 will produce better result for 99% of the time (or something like that) in this challenge. You can tweak the rate control like you want (with segment reencoding if you want) and with "better" setting (we use the best for PSNR) but it will be impossible for VC1 to obtain a better PSNR than for H264 or even close to H264.

Sagittaire

11th August 2007, 00:50

Running your first pass at Complexity 2 with MVRange 1 will give you better rate control that your current settings.

vc1_enc.exe use complexity at 3 and adaptative range for second pass.

Threadcount 1 would also help a bit in some of the shots with a lot of vertical motion.

Massive paralleling is certainely not good too for quality and Rate Control.

And 7 B-Frames? I thought we said that wasn't going to help :)! Well, if you're doing segment reencoding, that might work nicely for the credits, saving you some bits to use on the main feature. But the main sequence should use 1 or 2 B-frames.

pep can use 7 bframe if the core want use 7 frame. Doesn't change anything for quality anyway. You want 7 bframes in the challenge specification for VC1: profil use 7 bframes.

Perceptual option in general tunes for visual quality instead of PSNR. In theory, using it could rise SSIM and lower PSNR, but I haven't tested that much with objective measures.

Perceptual Option is certainely adaptative quantisation. AQ can reduce PSNR but it's generaly not a massive degradation.

zambelli

11th August 2007, 03:06

Well I don't know really the HDDVD specifications for VC1. But if you can set the PP in bitstream flag it's perhaps because hardware decoding will use post-process. Post process for VC1 is perhaps a official decoding way and part of the standard for this codec?
http://forum.doom9.org/showthread.php?p=870488#post870488
It's in the standard, but it's optional as far as I know. I'm fairly sure HD-DVD doesn't do post-processing.

Yes seriousely. Bframe are adaptative here. VC1 will use 7 bframe only if it's usefull. Anyway certainely that for 99% of time vc1 will use 0,1,2 or 3 bframe exactly like the other codec.
Shouldn't I be telling YOU how the VC-1 encoder works? ;) That sets the default B-frame count to be 7 frames. If you've got access to PEP, you also have access to VC-1 Analyzer so you should be able to see how long the B series are.

You want 7 bframes in the challenge specification for VC1: profil use 7 bframes.
Ben was asking that the B-frame restriction be removed because it's not in the HD-DVD spec. Nobody said 7 B-frames should always be used. And like I said, PEP will use the number of B-frames you specify as the default, even if adaptive B frames are enabled. Adaptive merely means that the encoder might or might not insert B-frames in certain cases despite expected pattern in a GOP. That's a very small percentage of cases though.

first and second pass. vc1_enc.exe profil use 3 pass only for produce best possible prediction in the last pass.
As I mentioned, there's little point to using the 3rd pass - it's not designed to do anything drastically differently than the 2nd pass, like automatically finetune ratecontrol or something.

Well it's useless. If you compare VC1 and H264 for each frame then H264 will produce better result for 99% of the time (or something like that) in this challenge. You can tweak the rate control like you want (with segment reencoding if you want) and with "better" setting (we use the best for PSNR) but it will be impossible for VC1 to obtain a better PSNR than for H264 or even close to H264.
One step at a time. Right now I just want to ensure that we find the settings that yield the best SSIM score we can get for VC-1 encodings. Whether the Microsoft scores are higher or lower than x264 scores is something we can worry about later.

Sagittaire

11th August 2007, 09:45

It's in the standard, but it's optional as far as I know. I'm fairly sure HD-DVD doesn't do post-processing.

Well I don't know. And for me this part is really more important than max bframe number for HDDVD standard. Anyway optional does'nt mean anything. It's yes or no.

Shouldn't I be telling YOU how the VC-1 encoder works? ;) That sets the default B-frame count to be 7 frames. If you've got access to PEP, you also have access to VC-1 Analyzer so you should be able to see how long the B series are.

Well I use simply an OSD function from another directshow filter for scan the Frametype and Framesize.

Ben was asking that the B-frame restriction be removed because it's not in the HD-DVD spec. Nobody said 7 B-frames should always be used. And like I said, PEP will use the number of B-frames you specify as the default, even if adaptive B frames are enabled. Adaptive merely means that the encoder might or might not insert B-frames in certain cases despite expected pattern in a GOP. That's a very small percentage of cases though.

If vc1 work correctly max bframe number with adaptative placement will use bframe only if it's necessary. For example in difficult part with high motion vc1 will not use bframe because use bframe for this particular scenario is less efficient than Pframe. I scan different vc1 stream from HDDVD and for example "Chronicles of Riddick" movie encoding use 7 adaptatives bframes and certainely that all the other vc1 stream from Universal use this setting for bframe.

As I mentioned, there's little point to using the 3rd pass - it's not designed to do anything drastically differently than the 2nd pass, like automatically finetune ratecontrol or something.

Well it's true but we use the best possible vc1 profil for have the best possible OPSNR/SSIM result.

One step at a time. Right now I just want to ensure that we find the settings that yield the best SSIM score we can get for VC-1 encodings. Whether the Microsoft scores are higher or lower than x264 scores is something we can worry about later.

Well VC1 and MPEG4 ASP produce most of the time similar result for metric. And MPEG4 ASP is never able to fight to H264 with metric.

Sagittaire

11th August 2007, 13:58

And other test with setting from benwaggoner. Result is only little better for OPSNR. Anyway result for SSIM is 85.72 and previous vc1_enc.exe profil produce SSIM at 86.41. Like I always say vc1_enc.exe produce exactly the same result for quality than pep.exe. Use pep.exe don't change anything and use vc1_enc.exe is really more simple for make test. The initial profil for vc1_enc.exe is IMO the best for produce the highest OPSNR/SSIM result.

Well now test with pep.exe at 6 Mbps with PP0: 44.10 dB for OPSNR and 85.72 for SSIM

Minimum Average Maximum

Y: Mean Absolute Deviation: 0.0000 13.1763 4.5640
U: Mean Absolute Deviation: 0.0000 0.7642 1.7663
V: Mean Absolute Deviation: 0.0000 0.8234 1.6109
Sum: Mean Absolute Deviation: 0.0000 24.8400 3.1151

Y: Mean Deviation: -1.0000 -0.5879 0.6439
U: Mean Deviation: -0.3941 0.0236 0.6183
V: Mean Deviation: -0.4885 0.0192 0.5467
Sum: Mean Deviation: -0.6667 -0.8277 0.3945

Y: Mean Square Error: 0.0000 3.4889 43.9233
U: Mean Square Error: 0.0000 0.5766 6.1960
V: Mean Square Error: 0.0000 0.6391 4.7024
Sum: Mean Square Error: 0.0000 2.5286 29.4009

Y: Root Mean Square Error: 0.0000 1.5742 6.6275
U: Root Mean Square Error: 0.0000 0.6369 2.4892
V: Root Mean Square Error: 0.0000 0.6793 2.1685
Sum: Root Mean Square Error: 0.0000 1.3636 5.4223

Y: PSNR: 31.7039 42.7039 1.#INF
U: PSNR: 40.2097 50.5222 1.#INF
V: PSNR: 41.4076 50.0752 1.#INF
Sum: PSNR: 33.4472 44.1020 1.#INF
Minimum Average Maximum

Mean Absolute Deviation: 0.0000 24.8400 3.1151
Mean Deviation: -0.6667 -0.8277 0.3945
PSNR: 33.4472 44.1020 1.#INF

And now result with vc1_enc.exe with PP1 in flag: 43.75 dB for OPSNR and 86.41 for SSIM

Minimum Average Maximum

Y: Mean Absolute Deviation: 0.0000 12.3687 5.4406
U: Mean Absolute Deviation: 0.0000 0.7497 1.5126
V: Mean Absolute Deviation: 0.0000 0.8131 1.4572
Sum: Mean Absolute Deviation: 0.0000 23.4965 3.6962

Y: Mean Deviation: -1.0000 0.3257 0.6041
U: Mean Deviation: -0.1913 0.0610 0.6475
V: Mean Deviation: -0.4243 0.0506 0.3930
Sum: Mean Deviation: -0.6667 0.7927 0.4057

Y: Mean Square Error: 0.0000 3.8036 67.1990
U: Mean Square Error: 0.0000 0.5776 4.8270
V: Mean Square Error: 0.0000 0.6528 4.0074
Sum: Mean Square Error: 0.0000 2.7408 44.9051

Y: Root Mean Square Error: 0.0000 1.6975 8.1975
U: Root Mean Square Error: 0.0000 0.6459 2.1970
V: Root Mean Square Error: 0.0000 0.6934 2.0019
Sum: Root Mean Square Error: 0.0000 1.4620 6.7011

Y: PSNR: 29.8572 42.3289 1.#INF
U: PSNR: 41.2941 50.5149 1.#INF
V: PSNR: 42.1022 49.9830 1.#INF
Sum: PSNR: 31.6078 43.7521 1.#INF
Minimum Average Maximum

Mean Absolute Deviation: 0.0000 23.4965 3.6962
Mean Deviation: -0.6667 0.7927 0.4057
PSNR: 31.6078 43.7521 1.#INF

And here the xml project for pep.exe:
- All HVS setting desactived for produce best PSNR.
- 1 thread for the encoding (curious way for P.E.P., isn't it?)
- Complexity at maxi, Chroma at maxi, bframe at 2.

<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/DigitalMedia/Codecs/2006/12/01/ParallelEncoderProject">
<ProjectName>Project1</ProjectName>
<PublishedFileURL>C:\Master\Project1.vc1</PublishedFileURL>
<PublishedLogFileURL>C:\Master\Project1.log</PublishedLogFileURL>
<OutputDirectory>C:\Master</OutputDirectory>
<SourceFiles>
<SourceFile>C:\Master\1920x1080.yuv</SourceFile>
</SourceFiles>
<AllowPtoISwitch>true</AllowPtoISwitch>
<AspectRatioIndex>1</AspectRatioIndex>
<BFrames>2</BFrames>
<Bitrate>6000</Bitrate>
<BufferSize>1843200</BufferSize>
<ChromaSearch>full</ChromaSearch>
<ClosedCaptionsPresent>false</ClosedCaptionsPresent>
<ColorFormatFlag>false</ColorFormatFlag>
<Denoise>false</Denoise>
<EncoderComplexity>4</EncoderComplexity>
<EncodingMode>VBR</EncodingMode>
<EncodingHeight>1080</EncodingHeight>
<EncodingWidth>1920</EncodingWidth>
<FrameRate>29.97</FrameRate>
<GOPLength>14</GOPLength>
<GOPType>Open</GOPType>
<Height>1080</Height>
<InterlaceMode>InterlacedTelecine</InterlaceMode>
<LoopFilter>true</LoopFilter>
<MarkIn>0</MarkIn>
<MarkOut>15689</MarkOut>
<MinEncodeQP>1.0</MinEncodeQP>
<MVRange>1</MVRange>
<PeakBitrate>20000</PeakBitrate>
<PDeltaQP>0.0</PDeltaQP>
<PerceptualOptionLevel>0</PerceptualOptionLevel>
<Segments>1</Segments>
<ThreadCount>1</ThreadCount>
<Width>1920</Width>
<BDeltaQP>
<Relative>0.0</Relative>
</BDeltaQP>
<FirstPassSettings>
<ChromaSearch>off</ChromaSearch>
<EncoderComplexity>2</EncoderComplexity>
<MVRange>1</MVRange>
</FirstPassSettings>
<CodecData>
<Property name="BFramePosOpt" type="long" value="1"/>
<Property name="DarkNoiseControl" type="long" value="0"/>
<Property name="DCBias" type="long" value="1"/>
<Property name="DQuantStrength" type="long" value="0"/>
<Property name="FavorInterLevel" type="long" value="3"/>
<Property name="MotionMatch" type="long" value="4"/>
</CodecData>
<UIData>
<RecentPublishedFileURL/>
</UIData>
</Project>

Golgot13

11th August 2007, 14:46

Well now test with pep.exe at 6 Mbps

Hi Sagitaire,

You will do the 12Mbps encoding too ?

Sagittaire

11th August 2007, 14:55

Hi Sagitaire,

You will do the 12Mbps encoding too ?

No simply because pep.exe can't produce better result than vc1_enc.exe (in 2 pass). But really simple for me to obtain these encoding en make test. I have better human/material resource than MS ... lol

Golgot13

11th August 2007, 15:17

I have better human/material resource than MS ... lol

No, you are wrong, this challenge prouve nothing because it is not same workflow than us on HD DVD title.....
And because it can prouve that H264 have a better "Visual Quality", with or without grain (see other thread).....

But if this challenge can prouve something good about VC1, I think we could see the resource power of MS...

All companies on SMPTE or ITU or EBU use the metric to compare the quality of some codecs or standards
but I surprise that some company don't want to accept this metric when it's bad for themself...

Sagittaire

11th August 2007, 15:23

All companies on SMPTE or ITU or EBU use the metric to compare the quality of some codecs or standards
but I surprise that some company don't want to accept this metric when it's bad for themself...

http://www.microsoft.com/windows/windowsmedia/howto/articles/vc1techoverview.aspx#VC1ComparedtoOtherCodecs

"In Microsoft's own internal tests, VC-1 performs 2 to 3 times better than MPEG-2. In other words, to achieve a given PSNR, MPEG-2 requires a bit rate up to 3 times higher than VC-1. These results were measured using both low-motion and high-motion video sequences. Microsoft also compared VC-1 with H.264 and found that both codecs have comparable performance when PSNR is plotted against bit rate."

Sagittaire

11th August 2007, 21:34

Annexe - Update

11.08.2007 - All the H264 streams are availables
05.08.2007 - Max adaptative bframe at 7 for VC1, H264 and MPEG2
04.08.2007 - Unlimited range vector for VC1
03.08.2007 - Encoding with libavcodec at 18 Mbps
02.08.2007 - Max adaptative bframe at 7 for VC1
01.08.2007 - Complete Test with x264, pep and libavcodec

will coming ... if you want ... !!!
All the developpers are wellcome ... !!?

vsv

12th August 2007, 15:19

http://www.microsoft.com/windows/windowsmedia/howto/articles/vc1techoverview.aspx#VC1ComparedtoOtherCodecs

"In Microsoft's own internal tests, VC-1 performs 2 to 3 times better than MPEG-2..."

May be 20-30% better?

Sagittaire

12th August 2007, 15:27

May be 20-30% better?

Manao say that there are 25% between MPEG2 and MPEG4 ASP for efficiency. VC1 and ASP produce similar result for metric.

Dark Shikari

12th August 2007, 16:00

May be 20-30% better?
It probably depends on the bitrate.

At low bitrates, WMV destroys MPEG-4 ASP, and H.264 destroys WMV just as much.

At high bitrates they all just start to converge.

vsv

12th August 2007, 17:07

It probably depends on the bitrate.

Yes, i agree. Difference at 10Mbps possible 30% but at 20Mbps very small. At 25-30Mbps no matter what codec. Any good mpeg2 encoder with quality source able to do nice picture.
For 3xDVD (HDDVD9) i prefer h264 (free x264 or non expensive mainconcept encoder) to encode at abr 6-8Mbps.
VC1 may be good with tools for handmade polishing.
VC1 as codec without eyes and hands of Compressionists and able to do segment (within frame and between frames) reencoding can not be better than h264.

zambelli

13th August 2007, 01:24

I don't understand why you're being stubborn about the suggestions I'm giving you. I'm giving your first-hand information but for some reason you're choosing to trust other sources. :confused:

Well I don't know. And for me this part is really more important than max bframe number for HDDVD standard. Anyway optional does'nt mean anything. It's yes or no.
Fine. The answer is NO then: no post-processing is done on VC-1 video in HD-DVD decoding.
Well I use simply an OSD function from another directshow filter for scan the Frametype and Framesize.
Like I said: if you've already got access to PEP, try using VC-1 Analyzer/Viewer tool that comes with it. That's what it's for.

If vc1 work correctly max bframe number with adaptative placement will use bframe only if it's necessary.
Correctly? What's correct? The VC-1 specification doesn't define how one should implement B-frame encoding, so how can there be a correct way?
I scan different vc1 stream from HDDVD and for example "Chronicles of Riddick" movie encoding use 7 adaptatives bframes and certainely that all the other vc1 stream from Universal use this setting for bframe.
The studios are NOT encoding with PEP set to use 7 B-frames. This is just not happening.
Well it's true but we use the best possible vc1 profil for have the best possible OPSNR/SSIM result.
What does that mean? Why would you do it anyway if I said it won't make a difference?
Well VC1 and MPEG4 ASP produce most of the time similar result for metric. And MPEG4 ASP is never able to fight to H264 with metric.
In the interest of keeping this comparison authorative, I would highly recommend also doing A/B/C frame comparisons in Avisynth and posting links to PNG-compressed screen captures. As long as you're only relying on PSNR and SSIM, there will always be people (from all sides) arguing that PSNR/SSIM aren't representative enough of human perception. I say this not because I think it would favor one codec or another (I haven't even done the comparisons myself yet), but because I think it would make the comparison more valuable.

Trahald

13th August 2007, 05:57

Unfortunaly there are a bug from nah_hrd flag for trahald patch. StreamEyes show big overflow. Anyway I think that it's just HRD flags problem and stream is certainely internaly HDDVD compliant. Anyway no doubt that your build obtain better SSIM than my build.Sorry late to thread. Issue was fixed (before i knew it was broken) in patch 'g'
Yes, the reason the HRD patch isn't applied is that it doesn't attempt to generate the right numbers, it just fills in the HRD fields with something. And I don't know how to compute the right numbers either, so I can't fix it.The values in the patch are thought out values (ie based on info available in any available papers) although some are best interpretations as some settings are not 100% clear from documents. Also based on reviewing pro streams. No generic values are used.
The updated patch has generated streams that do not overflow. (for testing i even allowed for tiny buffers and x264s existing rate control kept things in check) Having said that, the patch would still have to be labeled alpha until clearer specs come out or it ages out (ie its success over time outways the fact the settings arent verified)

Now back to the challenge... :)

Trahald

13th August 2007, 06:00

Sagittaire, you may already be aware of this but streameye tools also support vc1 ie for checking gop pattern

Sagittaire

13th August 2007, 10:44

I don't understand why you're being stubborn about the suggestions I'm giving you. I'm giving your first-hand information but for some reason you're choosing to trust other sources. :confused:

Well I use all your suggested setting and profil for this test.
http://forum.doom9.org/showthread.php?p=1032840#post1032840

Anyway you don't have human/material ressource for make this little encoding (10 min). I can make that for you if you post your complete xml profil with your ideal setting. Time for make that is just 10 min ... no more.

Fine. The answer is NO then: no post-processing is done on VC-1 video in HD-DVD decoding.

Really bad for visual quality at low bitrate. Really bad for SSIM too. I will make all the encoding with your suggested setting and profil with pep.exe exactly like you want but the result will be not better ...

Correctly? What's correct? The VC-1 specification doesn't define how one should implement B-frame encoding, so how can there be a correct way?

The best way for choose frame placement is evaluate each situation. Bframe are not alway the best efficient way and by far. For example Livavcodec use RDO for the bframe placement (really really slow) and never use bframe in large zone for Elephant Dream movie. x264 use really good and faster process for frame placement (not for the fade anyway) and if you choose 3 bframes or 1000 bframes with x264 the result will be in practice the same. For example with bframe at 3 for ED x264 use the same bframe number than Pframe number. If I understand correctly VC1 use always the default max possible bframe number and bframes are just adaptative for fade and flash part. It's really curious way for adaptative bframe.

The studios are NOT encoding with PEP set to use 7 B-frames. This is just not happening.

Well perhaps only for credit with segment encoding. I scan 7 bframes for black frame in Riddick vc1 stream.

In the interest of keeping this comparison authorative, I would highly recommend also doing A/B/C frame comparisons in Avisynth and posting links to PNG-compressed screen captures. As long as you're only relying on PSNR and SSIM, there will always be people (from all sides) arguing that PSNR/SSIM aren't representative enough of human perception. I say this not because I think it would favor one codec or another (I haven't even done the comparisons myself yet), but because I think it would make the comparison more valuable.

Well this test is just metric comparison and not visual comparison. I don't say "H264 is better visually than VC1". I just say "here for this source H264 is better that VC1". It's an objective test and by definition you can't contradict that (make encoding if you want ... it's a challenge). And MS use PSNR too:
http://www.microsoft.com/windows/windowsmedia/howto/articles/vc1techoverview.aspx#VC1ComparedtoOtherCodecs

One useful objective metric is the peak signal-to-noise ratio (PSNR) plotted against bit rate. PSNR is the ratio between the maximum value of a signal (255 for 8-bit video) and the quantization noise. A higher PSNR indicates a less noisy signal. For any codec, PSNR is expected to increase at higher bit rates, because higher bit rates translate to less aggressive compression. Thus, a graph that plots PSNR against bit rate shows the performance of the codec over a range of compression settings.

In Microsoft's own internal tests, VC-1 performs 2 to 3 times better than MPEG-2. In other words, to achieve a given PSNR, MPEG-2 requires a bit rate up to 3 times higher than VC-1. These results were measured using both low-motion and high-motion video sequences. Microsoft also compared VC-1 with H.264 and found that both codecs have comparable performance when PSNR is plotted against bit rate.

And it's false for this source and certainely for many other simply because MPEG-2 never requires a bit rate up to 3 times higher than VC-1 to achieve a given PSNR.

Inventive Software

13th August 2007, 11:12

I can see this thread turning into a "Push all evidence against VC-1" thread. Makes for good reading though. ;)

@zambelli, benwaggoner: How good are the encoders that either WMcmd.vbs or WME use? Are they due for an update any time soon?

Sagittaire

13th August 2007, 11:30

I can see this thread turning into a "Push all evidence against VC-1" thread. Makes for good reading though. ;)

No ... It's really simple to contradict my result. MS can make the encoding.

1. I use encoding from vc1_enc.exe for result
2. MS say that this tool don't produce good result

3. I use encoding from pep.exe for the result (without better result)
4. MS say that there are not the "good" setting

5. I use encoding from pep.exe with "good" setting for the result (without better result)
6. MS say that it's not the "good" source for make test.

http://on10.net/Blogs/benwagg/elephants-dream-720p--2-mbps/

Inventive Software

13th August 2007, 11:32

TBF to all parties though, you have a source, you need the codec to adapt and encode the source as best as possible.

Why not just use the WMcmd.vbs?

Sagittaire

13th August 2007, 11:38

TBF to all parties though, you have a source, you need the codec to adapt and encode the source as best as possible.

Why not just use the WMcmd.vbs?

Simply because WMcmd.vbs can't produce HDDVD/BD compliant stream. Moreover WMcmd.vbs don't produce better result than pep.exe simply because the core is less advanced (big problem for fade with WMcmd.vbs stream).

CruNcher

13th August 2007, 16:26

Simply because WMcmd.vbs can't produce HDDVD/BD compliant stream. Moreover WMcmd.vbs don't produce better result than pep.exe simply because the core is less advanced (big problem for fade with WMcmd.vbs stream).

in wich terms RateControll ? or basic stuff like I,P Quality, so what i mean is if you take ratecontroll out of the equation would pep.exe and vc1_encoder.exe be more efficient also (seeing that there is a 1 year difference i doub't somehow only Ratecontroll has been improved) ?
im planing todo a noise/grain preservation test but really starting from 0 so ratecontroll wouldn't be that much important yet

benwaggoner

13th August 2007, 17:01

Anyway you don't have human/material ressource for make this little encoding (10 min). I can make that for you if you post your complete xml profil with your ideal setting. Time for make that is just 10 min ... no more.
I don't want to pull folks of finishing the next release of PEP/CineVision PSE for this, no. But I've asked our skilled PEP operators to take a look at the source and make some more definitive recommendations.

Really bad for visual quality at low bitrate. Really bad for SSIM too. I will make all the encoding with your suggested setting and profil with pep.exe exactly like you want but the result will be not better ...
No one is making HD DVD discs @ 6 Mbps, especially not full frame, sso the lack of postprocessor isn't an issue for actual titles. Unlike a loop filter, which actually helps add real image detail to a title, postprocessing just hides artifacts.

The best way for choose frame placement is evaluate each situation. Bframe are not alway the best efficient way and by far. For example Livavcodec use RDO for the bframe placement (really really slow) and never use bframe in large zone for Elephant Dream movie. x264 use really good and faster process for frame placement (not for the fade anyway) and if you choose 3 bframes or 1000 bframes with x264 the result will be in practice the same. For example with bframe at 3 for ED x264 use the same bframe number than Pframe number. If I understand correctly VC1 use always the default max possible bframe number and bframes are just adaptative for fade and flash part. It's really curious way for adaptative bframe.
In the version of PEP you have, the B-frame value is the target for content. Additional B-frames might be used for flash frames, and they can be turned off entirely for fades. But the B-frame control you're using isn't analagous to what you have in x264.

We understand the value of a more dyamic B-frame insertion process. Although for HD optical data rates and typical content, the current setup has been fine. And of course with PEP, the B-frame pattern can be manually set per segment.

Well this test is just metric comparison and not visual comparison. I don't say "H264 is better visually than VC1". I just say "here for this source H264 is better that VC1". It's an objective test and by definition you can't contradict that (make encoding if you want ... it's a challenge). And MS use PSNR too:
http://www.microsoft.com/windows/windowsmedia/howto/articles/vc1techoverview.aspx#VC1ComparedtoOtherCodecs
That's a pretty old article. Personally, I'm not that big a fan of PSNR. It's a good metric to keep an eye on (a big spike can show a problem), but as our codec has evolved, we've deployed more and more techniques that improve visual quality while reducing PSNR. SSIM is better, but assumes a perceptually uniform luma curve, and so underestimates the importance of high precision in the low luma range when seen on modern displays with elevated blacks. The latter is something the studios find really important, and our codec spends a lot of bits making sure there isn't blocking in black on consumer displays, even though that blocking wouldn't be seen on a calibrated CRT. SSIM and PSNR don't pick up on that.

buzzqw

13th August 2007, 17:23

pep or vc1_enc are freely avaiable ? where ?

thanks!

BHH

Golgot13

13th August 2007, 17:24

That's a pretty old article.

Only one year like the first version of this challenge :D

Personally, I'm not that big a fan of PSNR.

Same, but you (MS), ITU, EBU,.. use it.

It's a good metric to keep an eye on (a big spike can show a problem), but as our codec has evolved, we've deployed more and more techniques that improve visual quality while reducing PSNR. SSIM is better, but assumes a perceptually uniform luma curve, and so underestimates the importance of high precision in the low luma range when seen on modern displays with elevated blacks. The latter is something the studios find really important, and our codec spends a lot of bits making sure there isn't blocking in black on consumer displays, even though that blocking wouldn't be seen on a calibrated CRT. SSIM and PSNR don't pick up on that.

Nice, but to test some optimization, you need to have some metric result (except statistic satisfaction ;) ).
MPEG format reduce the data picture don't see by eye/brain, MPEG format
use the last research about this (from many year and use too on other codec).
H264 last version available of this research have lot of optimization and option for it.

Ben, I like your post but I prefer to see some thing:
If not agree show a other way to test the codec ?
May be ITU, EBU, DVB, MPEG (MPEG Committee) will use your tool or protocol to evaluate
the picture quality of codec.:rolleyes: :p

(MPEG Committee: http://www.chiariglione.org/mpeg/ )

Golgot13

13th August 2007, 17:30

pep or vc1_enc are freely avaiable ? where ?

Not free, only for MS partener (free) or >50.000$

buzzqw

13th August 2007, 17:34

@Golgot13
ouch... i hoped that was free... at least will help spreading of wvc1 encoding

thanks anyway!

BHH

Golgot13

13th August 2007, 17:34

Ben can you make YES or NOT the best VC1 encoding for ED ?

If NOT, I will conclude that H264 is really the best codec.

If YES, I must to see result and conclude for ED movie (CG movie) what codec is the best (may be VC1 but I doubt).

I hope that some journalist (french, I prefer) will write some thing about this (dead line for September is this week)...

Last, I listen that Toshiba will release new firmware (very soon) to correct last problem when it play H264 codec
(HD DVD player are optimized for VC1 because there is lot of VC1 HD DVD title and especially MS supervise).

zambelli

14th August 2007, 05:59

Ben can you make YES or NOT the best VC1 encoding for ED ?
One of our co-workers had some time last week to try encoding this with PEP 1.0.7. We've got a 12 Mbps VC-1 encode now that scores 47.62 dB PSNR and 92.70 SSIM, versus 46.71 dB PSNR and 92.44 SSIM of Sagittaire's VC-1 encode. The video was encoded with PEP 1.0.7 (currently in development), but with Dquant entirely off. This seems to be telling us that SSIM doesn't care about blockiness in dark and smooth areas - something that HD-DVD and BluRay studios do care about very much. So we'll continue looking into this, but it's far from being our #1 priority at this moment.

If NOT, I will conclude that H264 is really the best codec.
... the best codec for generating highest SSIM scores, perhaps. :rolleyes:

I hope that some journalist (french, I prefer) will write some thing about this (dead line for September is this week)...
I hope anyone writing an article about this challenge actually understands that it is just a metric comparison, as Sagittaire has stated in his own words.

zambelli

14th August 2007, 06:09

In Microsoft's own internal tests, VC-1 performs 2 to 3 times better than MPEG-2. In other words, to achieve a given PSNR, MPEG-2 requires a bit rate up to 3 times higher than VC-1. These results were measured using both low-motion and high-motion video sequences. Microsoft also compared VC-1 with H.264 and found that both codecs have comparable performance when PSNR is plotted against bit rate.

And it's false for this source and certainely for many other simply because MPEG-2 never requires a bit rate up to 3 times higher than VC-1 to achieve a given PSNR.
I think you guys are nitpicking over this quote. You're taking an MPEG-2 best case scenario (let's face, nobody expected MPEG-2 to do this well in this challenge) and saying that Microsoft's claims are universally false, which is a bit of a stretch.

And yeah, I know that marketing folks are always very eager to pick the best test results instead of average or worst test results, but even when taken with a grain of salt, I don't think saying VC-1 is 2-3 times more efficient than MPEG-2 is far from the truth. If somebody said the same about MPEG-4 ASP, I'd consider it to be a true statement. Most DVDs, for example, are encoded at 5-6 Mbps. Ripping those DVDs and re-encoding them to XviD at ~2 Mbps has been the principle this website was founded on. Isn't that essentially the same claim of 2-3 times better efficiency?

Manao

14th August 2007, 07:11

Isn't that essentially the same claim of 2-3 times better efficiency?But mpeg4 isn't 2-3 times more efficient than mpeg2. Mpeg2 in DVD has a gop of 12/15 frames ( that's a 20% bitrate loss ). Mpeg4 @ 2mbps doesn't have the same level of details than mpeg2 @ 5mbps ( even if, instead of reencoding the mpeg2, you started from the same uncompressed source ).

Golgot13

14th August 2007, 09:59

One of our co-workers had some time last week to try encoding this with PEP 1.0.7. We've got a 12 Mbps VC-1 encode now that scores 47.62 dB PSNR and 92.70 SSIM, versus 46.71 dB PSNR and 92.44 SSIM of Sagittaire's VC-1 encode. The video was encoded with PEP 1.0.7 (currently in development),

Can you give a link to donwload video ?
Sagitaire will put a video link on first page.

With same measure than MS comparison codec:
So at 12Mbps: H264 from x264 is the best codec than VC1 from PEP and MPEG2 from libavcodec.
And , if the result is true (I don't have the video), VC1 really best than MPEG2 at 12Mbps.

but with Dquant entirely off. This seems to be telling us that SSIM doesn't care about blockiness in dark and smooth areas - something that HD-DVD and BluRay studios do care about very much.

How can you measure the blockiness on video?
Some professional H264 encoder have some psychovisual option with 5 level to optimize this.
So I think if you have some measure tool some people can continue the challenge on this way of comparison.
It will be necessary if the PSNR measure between two codec (here, VC1 and H264) is less than 0.7dB
but there is a difference of 2.6dB at 6Mbps and 1.49dB at 12Mbps

So we'll continue looking into this, but it's far from being our #1 priority at this moment.

I hope to see better quality on HD DVD, and I know MS do the best of VC1.

... the best codec for generating highest SSIM scores, perhaps. :rolleyes:

SSIM of H264 is better :p
Yes, VC1 is better than MPEG2, fortunately

I hope anyone writing an article about this challenge actually understands that it is just a metric comparison, as Sagittaire has stated in his own words.

Yes, the same metric used by MS last year to compare VC1 at all codec:
http://www.microsoft.com/windows/windowsmedia/howto/articles/vc1techoverview.aspx#VC1ComparedtoOtherCodecs

And the conclusion was:
In Microsoft's own internal tests, VC-1 performs 2 to 3 times better than MPEG-2. In other words, to achieve a given PSNR, MPEG-2 requires a bit rate up to 3 times higher than VC-1. These results were measured using both low-motion and high-motion video sequences. Microsoft also compared VC-1 with H.264 and found that both codecs have comparable performance when PSNR is plotted against bit rate.

Zambelli can you update this MS weblink because it is not true ? (and I'm not sure it was true too).:rolleyes:

Sagittaire

14th August 2007, 10:05

zambelli

14th August 2007, 11:59

Can you give a link to donwload video ? Sagitaire will put a video link on first page.
Sure. I'll try to remember to upload it tomorrow at work.
I hope to see better quality on HD DVD, and I know MS do the best of VC1.
Well, fortunately our development efforts are focused at the segment of the market where eyes count more than metrics. ;)
Zambelli can you update this MS weblink because it is not true ? (and I'm not sure it was true too).:rolleyes:
One best case scenario MPEG-2 test doesn't make it universally false! If anything needs to be corrected in that article, it's that codec standards can't be compared in terms of PSNR - only codec implementations can. The article should really be saying "Microsoft VC-1 encoder is 2-3 times more efficient than xyz MPEG-2 encoder".

Golgot13

14th August 2007, 12:31

One best case scenario MPEG-2 test doesn't make it universally false!

Yes and no.

If anything needs to be corrected in that article, it's that codec standards can't be compared in terms of PSNR - only codec implementations can.

May be you can change the sentence about PSNR ?

The article should really be saying "Microsoft VC-1 encoder is 2-3 times more efficient than xyz MPEG-2 encoder".

If you can not change, can you put/update with your results and show how the test was made (encoders used,...) ?

arfster

14th August 2007, 12:35

Would have to be a pretty garbage mpeg2 implementation in the worst case scenario to be 2x worse at the same bitrate. 3x worse..... never going to happen, was never going to happen.

Dark Shikari

14th August 2007, 14:37

Would have to be a pretty garbage mpeg2 implementation in the worst case scenario to be 2x worse at the same bitrate. 3x worse..... never going to happen, was never going to happen.
At very low bitrates the advantages and disadvantages of codecs begin to show.

I can make a watchable H.264 movie at 720p at 1 megabit. MPEG-2 can't get close to that.

It converges at higher bitrates of course. I assume that Microsoft did their tests at lower bitrates to accentuate the difference between VC-1 and MPEG-2.

benwaggoner

14th August 2007, 15:47

Would have to be a pretty garbage mpeg2 implementation in the worst case scenario to be 2x worse at the same bitrate. 3x worse..... never going to happen, was never going to happen.
Well, 2x is a pretty vague metric.

Certainly, VC-1 can do 640x480 @ 1 Mbps better than MPEG-2 can do @ 2 Mbps with plenty of cases. MPEG-1/2 really fall off a cliff beyond a certain point, lacking any in-loop deblocking.

Golgot13

14th August 2007, 16:03

Well, 2x is a pretty vague metric.

Certainly, VC-1 can do 640x480 @ 1 Mbps better than MPEG-2 can do @ 2 Mbps with plenty of cases. MPEG-1/2 really fall off a cliff beyond a certain point, lacking any in-loop deblocking.

Yes, I agree, but I think that MPEG4 ASP produce same result too.
I will be nice to test it (may be if Sagitaire can do it, because sure Ben you can not).

benwaggoner

14th August 2007, 16:38

Yes, I agree, but I think that MPEG4 ASP produce same result too.
I will be nice to test it (may be if Sagitaire can do it, because sure Ben you can not).
I'd be interested in seeing that as well (althogh it's not entirely germane here, as it's not supported by any HD optical media format).

Remember we need to test that with postprocessing turned off as well, to match the workflow of other codecs.

Sagittaire

14th August 2007, 16:54

Yes, I agree, but I think that MPEG4 ASP produce same result too.
I will be nice to test it (may be if Sagitaire can do it, because sure Ben you can not).

At this time I make other test and encoding. Anyway for this challenge I have I think the best possible result for H264 and for MPEG2. pep 1.07 can certainely produce really better result for OPSNR but not for SSIM. I will remake VC1 encoding with part by part encoding for optimal result ...

zambelli

14th August 2007, 20:02

At very low bitrates the advantages and disadvantages of codecs begin to show.

I can make a watchable H.264 movie at 720p at 1 megabit. MPEG-2 can't get close to that.

It converges at higher bitrates of course. I assume that Microsoft did their tests at lower bitrates to accentuate the difference between VC-1 and MPEG-2.
I'm also guessing that might've been the case. I haven't seen the tests, but it sounds like they picked a PSNR, then raised bitrates until the PSNR matched. This is a different approach entirely than the one of this challenge because it is approaching the problem from the opposite angle (fixed PSNR, variable bitrate). Though I'm sure the upper "3 times" figure might've had some wishful marketing thinking applied to it, the "2 times" figure doesn't sound wrong at all. Like I said, if somebody told me they could get DVD quality at 3 Mbps with VC-1, MPEG-4 or H.264 - wouldn't that sound like a reasonable claim?

Anyway, I'll see if I can track down the author of the article in question and get more info about the tests. I'm no fan of technical ambiguity in articles either.

zambelli

14th August 2007, 20:06

At this time I make other test and encoding. Anyway for this challenge I have I think the best possible result for H264 and for MPEG2. pep 1.07 can certainely produce really better result for OPSNR but not for SSIM. I will remake VC1 encoding with part by part encoding for optimal result ...
Note that our higher PEP 1.0.7 score was attained by disabling dquant entirely. While that's typically not something we'd do in a real HD-DVD encoding scenario, it seems to favor PSNR & SSIM here, so I guess you should make sure you disable it in your further encoding too. As much of the work in PEP 1.0.7 has been focused on dquant, you should probably be able to get very similar results with PEP 1.0.6 when Dquant is turned off.

akupenguin

15th August 2007, 03:50

Like I said, if somebody told me they could get DVD quality at 3 Mbps with VC-1, MPEG-4 or H.264 - wouldn't that sound like a reasonable claim?
That sounds reasonable, but that's comparing those codecs against MPEG-2 + DVD restrictions (GOP, VBV, etc). Unrestricted MPEG-2 can also get DVD quality at less than DVD bitrates (though obviously not as much less as modern codecs).

zambelli

15th August 2007, 09:52

Here's a link to the new 12 Mbps VC-1 encode I mentioned in post 150 (http://forum.doom9.org/showthread.php?p=1033723#post1033723):

http://www.citizeninsomniac.com/video/ED_Microsoft_12Mbps_NoDQ.vc1

This was encoded with PEP 1.0.7 (unreleased), with dquant disabled.

crypto

16th August 2007, 20:59

Note that our higher PEP 1.0.7 score was attained by disabling dquant entirely. While that's typically not something we'd do in a real HD-DVD encoding scenario, it seems to favor PSNR & SSIM here, so I guess you should make sure you disable it in your further encoding too.

This is exactly one of the results, when relying on PSNR & SSIM alone. It can lead the codec development and the evaluation of settings into a totally wrong direction.

I would second the statement about caring about blockiness in dark and smooth areas or smooth fades are more important than metrics.

I remember when HD-DVD (VC-1) and Bluray (MPEG-2, AVC) entered the market with different visual experiences, people loved VC-1.

Maybe JND metrics would be more appropriate.

Trahald

16th August 2007, 22:34

I remember when HD-DVD (VC-1) and Bluray (MPEG-2, AVC) entered the market with different visual experiences, people loved VC-1.Just to be fair, any early unfavorable bluray reviews i saw were all mpeg2 based.

CruNcher

16th August 2007, 23:57

If i could propose something i would say we add 2 other metrics to this test (currently doing this for my stuff) this way we could also see how efficient they are under such real life conditions, the metrics i propose are both developed by MSU the Blocking measure and the Bluring measure they show quiet well results in my firsts tests.
This multi metrics way could enhance the overall look also in terms of tweaking it into a desired one http://www.compression.ru/video/quality_measure/info_en.html#start :), but it should be clear that only in combination it makes sense to tweak upon them especialy seeing that they not proven to be efficient enough.

benwaggoner

17th August 2007, 00:37

zambelli

17th August 2007, 03:36

If one was to do a series of A/B visual comparisons between an H.264 encoder and a VC-1 encoder in HD encoding scenarios, what you would probably find is that neither encoder completely blows the other out of the water for all content. There'd probably be frames where one looked better than the other (perhaps due to different ratecontrol & ME), and then there might be other frames where within the same frame some areas look better on one and other areas look better on the other encoder (perhaps due to different transforms, quantization, AC preservation, etc). It's rarely a clean-cut "this encoder wins hands down" situation. I've even heard compressionists say one encoder works better with titles from a particular studio, for example, simply due to the frequency ranges created by certain transfer equipment. This is why you often hear people in the HD-DVD/BluRay encoding world say the H.264 and VC-1 encoding solutions are "close enough" in terms of quality, meaning that ease of use, speed of workflow and degree of human interaction required often play a greater role in the selection of a codec than PSNR, SSIM, and other mathematical metrics.

I don't say this to discredit SSIM - it's a metric that I've used often and have evangelized quite a lot to other people on the codec team at Microsoft - but I simply want to illustrate the point that the HD-DVD/BluRay world tends to play by very different rules than some other video encoding market segments. Their goal is really to achieve transparency to the source - as much as possible within their given constraints. This is why they have professional compressionists whose job is to tinker with encodes and do segment re-encoding until they truly have the best possible result.

In the context of this challenge, the 18 Mbps example would probably be most similar to the conditions and requirements of HD-DVD encoding. 6 Mbps, on the other hand, might be better comparable to VOD offerings, IPTV, digital cable, etc, where quality doesn't need to be transparent to the source - it simply needs to be "watchable" and "good enough". A whole different set of requirements and criteria rule that world so I think one has to keep that in mind when evaluating this challenge too. The qualities/objections that matter at 18 Mbps aren't the same as the ones that matter at 6 Mbps.

Golgot13

17th August 2007, 09:12

I would second the statement about caring about blockiness in dark and smooth areas or smooth fades are more important than metrics.

I remember when HD-DVD (VC-1) and Bluray (MPEG-2, AVC) entered the market with different visual experiences, people loved VC-1.

Maybe JND metrics would be more appropriate.

Yes and No:
About Blu-Ray in MPEG2: Sony's compressionist are stup*d guy, because they used a bad MPEG2 encoder.
Second, BluRay titles were the first with true video: movie without preprocessing video
(no remove grain, no change contrast, sharpen,...)

About HD DVD, all first HD DVD used the best preprocessing video (less grain,
sometime without grain,change contrast, sharpen,...). Now with optimization of PEP
we can have better video with grain preserve (nice picture, thank you MS team).

Golgot13

17th August 2007, 09:21

I'd certainly be interested in seeing the results of new metrics.

Comparing blocking/blurring between codecs would be particularly interesting, and also comparing different post-processing techniques for more PC-based playback.

I'm agree with you.
And it will be a new development way for encoder opitimization. Ateme software and Mainconcept software
have nice options for grain and "psychovisual" optimization.

If we have new "metric" (for blocking, bluring, ...), I'm sure we will have better encoder (VC1, H24, VP6, MPEG2,...)

CruNcher

17th August 2007, 10:17

Exactly that's what im currently doing (doing since years actually) ;)

honai

17th August 2007, 13:46

This is why they have professional compressionists whose job is to tinker with encodes and do segment re-encoding until they truly have the best possible result.

No, they don't. I hate to say it, but that statement is objectively untrue. Unless these production facilities fired the old ones from the DVD era and magically grew new ones over night I don't see how you could get "compressionists" who don't screw up titles as they did with previous DVD releases. Point is that the vast majority of "compressionists" out there have very little understanding of their tools, the source material and the encoding process itself. (And don't get me started on audio compression.) It's like putting someone with 4 weeks of college courses in MS Word to work with Adobe InDesign and tell him to produce the next Newsweek edition. Eventually he'll come up with something ... and then blame the source/the editors/the reporters/the software for the bad results.

It's a sad state where your average scene encoder can put out better encodes from HD disc material than "professional compressionists" from raw, uncompressed 4:4:4 scans. The majority of the latter are not professional, and they don't compress but mutilate.

By the way: This situation is even more so perpetuated by complementary "professional HD disc reviewers" *cough* highdefdigest *cough* who make ridiculous claims about the "three-dimensional, palpable, flawless transfer" of such mutilated releases where even the casual observer could count numerous glaring mastering errors. It's like the mute teaching the blind how to see.

Unless guys like zambelli, who obviously wield some influence in that process, straighten their act up and admit that a vast array of releases are being butchered by those facilities I don't see the situation improving. Think of the initial Fifth Element release, where customer dissatisfaction and market pressure actually spawned a remastering. Ridiculous claims like "professional compressionists whose job is to tinker with encodes and do segment re-encoding until they truly have the best possible result" are counter-productive in that respect. Overall the industry is doing a really bad job right now, and we need more pressure so that we actually get the best possible result.

vsv

19th August 2007, 14:55

Compressionist Stacey Spears said:

"I finally got around to looking at the x264 encode of ED. (12 Mbps version) and it looks great! None of the AVC encoders used for HD DVD or BD are as good as the x264 encoder. If I had to rate them in order of quality it would go:

Thompson
MEI
Sony
Cinema Craft
Toshiba

Both Paramount and Universal have left the choice up to the compressionist w/r/t which codec to use for a given title. They really just want the best looking title they can get. Sadly, things are now date driven, so titles have to be done quickly. HDM is coming out of R&D and now people are wanting to make some money, so they can't afford to tweak until it is perfect anymore." (http://www.avsforum.com/avs-vb/showpost.php?p=11342184&postcount=120)

CruNcher

19th August 2007, 15:41

Hehe then he should try Mainconcepts Encoder and Ateme also :P if he likes those pro stuff, they in some degress even better then current x264 but not for much long for sure
and x264 bitstreams are yet still more decoding complex then Atemes for example (same levels same settings) dunno about Mainconcept situation ;)

zambelli

20th August 2007, 03:23

Unless guys like zambelli, who obviously wield some influence in that process
That's nice of you to think so, but I really have no influence over the mastering and encoding practices in the HD-DVD/BluRay encoding market.
"professional compressionists whose job is to tinker with encodes and do segment re-encoding until they truly have the best possible result" are counter-productive in that respect. Overall the industry is doing a really bad job right now, and we need more pressure so that we actually get the best possible result.
My impression is that the dedication to quality has been much higher than in DVD production, especially in these early days of the medium. As Stacey stated in that quoted post, the release schedule is indeed growing more and more date driven so we'll have to see how long the studios can stay quality-focused, but if you compare the early days of DVD to the early days of HD-DVD/BluRay encoding - it's a night and day difference.

708145

20th August 2007, 11:03

As Stacey stated in that quoted post, the release schedule is indeed growing more and more date driven so we'll have to see how long the studios can stay quality-focused, but if you compare the early days of DVD to the early days of HD-DVD/BluRay encoding - it's a night and day difference.

If I may ask, how much time is left in working days for each title?
Less than 3?

arfster

20th August 2007, 19:19

Compressionist Stacey Spears said:

[url=http://www.avsforum.com/avs-vb/showpost.php?p=11342184&postcount=120]"I finally got around to looking at the x264 encode of ED. (12 Mbps version) and it looks great! None of the AVC encoders used for HD DVD or BD are as good as the x264 encoder.

Interesting. That's either a fairly severe criticism of the professional stuff (given the money at stake pro stuff really shouldn't be outperformed by open source), or an enormous credit to the x264 coders.

Probably both.

CruNcher

20th August 2007, 21:03

zambelli

22nd August 2007, 05:44

arster it's a difference if a company researchs their entire lifetime on video only or has multiple sectors of research and then you have the guys that are behind this and especialy if it's a buisness changes aren't such fast provided to compressionists look for example VC-1 consumer encoder is 1 year old technology compare that with almost daylie new builds from x264 such a release shedule is unthinkable for open source, but thats because there aren't 1000 instances new developments have to go through in a buisness (Development,several big boses who decide how to make the most money with it,marketing,pr,design studios,private betas with 3rdparties :P all of this is slowing down imense (the brains behind it (coders) have allready created 2 new generations before the old one is finaly going out LOL) in small research companies alot of those isn't the case some is, for open source most of the times none of the above is the case so its lightning fast from coding to enduser sometimes 1 day even hours and really heavy projects even minutes compare that to waiting for a new VC-1 endconsumer encoder from MS 1 year long that is crazy how slow that is, but i think that sometimes to fast can also be a problem :P it can endup in stress situations for example efficiency testing you test something and know the next day everything, could have changed and you start again ;) definatly nothing humans are made for but definatly alot better then to wait 1 year for mini progresses, because of all the politics behind it :P.
You bring up a lot of good points. The advantage of small projects (open or closed source) is definitely in the quick turnaround time. In small projects bugs can be fixed and new builds can be released in hours, new features can be implemented in a matter of days, etc. There's no doubt that a project's efficiency starts decreasing once you pass a certain "sweet spot" in size. On the other hand, I think large and slower projects definitely benefit from more thorough testing. With projects like x264, for example, practically every build is a beta build and every user is a tester. (My favorite examples are projects like Exact Audio Copy which after 8 years of development still haven't officially reached v1.0 :D ). Larger projects tend to set major milestones and handle testing between milestones in a more closed environment, hopefully producing more stable major builds for the public releases. Having dedicated people with a responsibility to find bugs and ensure stability goes a long way and is definitely more reassuring and efficient than just relying on random users to find the bugs for you.

pandy

22nd August 2007, 10:23

Noise hides banding if it's added at playback time.
Noise increases banding at any given bitrate if it's added before encoding, because it takes bits away from the actual content.

No, proper noise (optimal from source point of view) is always ok - for example for linearization of quantizier

You mean, wastes bitrate equally everywhere. And why do you care about a "stable" bitrate anyway? You don't see bitrate, you see quality.

Yes but adding some noise can subjectively improve quality

Noise is always a problem. The only argument for including it in a test is that non-CG movies have a certain amount of unavoidable noise, and you want the test to reflect the imperfect real world.

Yes, noise is always problem due of nature of noise so very frequently instead noise we use regular patterns which are similar to the noise.

CruNcher

22nd August 2007, 10:56

With projects like x264, for example, practically every build is a beta build and every user is a tester

Yep, but that's happening in our daylie lives more and more see the CE market same situation, because everything relies on firmware (software) now, this also gives alot of Power to the industry (industry = certain groups of humans) deciding what the user can and what not and especialy what he has to pay for, with this developments comes great responsibility by the industry for the whole society not to missuse this power, but @ the moment they do, so they shouldn't be suprised if other try to avoid being put in that scenario (controled) we are humans after all and everyone knows history and everyone knows how so much ended and Microsoft is @ the moment in the same position as the Roman Empire @ that time now and definatly has to change to survive.
But for Americans this is hard to understand because in Shool you only learn American History allways from the American view (Patriotical), but hey if i look sometimes into the history and compare it with our situation now i allways think what are we doing we repeat everything we did wrong in the past and that on a worldwide base not only America makes the same mistakes but everyone, for what have we been teached history in Shool sometimes i can just think for the fun of it :P

akupenguin

22nd August 2007, 11:10

No, proper noise (optimal from source point of view) is always ok - for example for linearization of quantizier
Give an example of such "optimal" noise? And what does it have to do with quantizers, linear or otherwise?

Yes but adding some noise can subjectively improve quality
That's what I said -- at playback time.

Yes, noise is always problem due of nature of noise so very frequently instead noise we use regular patterns which are similar to the noise.
If you agree that noise is a problem, then why are you trying to emulate it? Just making it non-random doesn't make it take any fewer bits.

Sharktooth

22nd August 2007, 12:40

@cruncher: Roman empire was not evil @ all.

arfster

22nd August 2007, 17:54

With projects like x264, for example, practically every build is a beta build and every user is a tester.

True - but you could also that's exactly the case for all drivers put out by NVidia and ATI, which are hardly tiny companies. X264 is a paragon of stability and maturity compared to the stuff those two produce.

Dark Shikari

22nd August 2007, 18:05

True - but you could also that's exactly the case for all drivers put out by NVidia and ATI, which are hardly tiny companies. X264 is a paragon of stability and maturity compared to the stuff those two produce.Agreed: proprietary and expensive does not mean stable or reliable. In fact it often means it was kludged together by a bunch of incompetents, and then Very Highly Paid Consultants were hired to fix it up, after which the company released it 6 months ahead of schedule, long before it was finished.

zambelli

23rd August 2007, 07:13

Agreed: proprietary and expensive does not mean stable or reliable. In fact it often means it was kludged together by a bunch of incompetents, and then Very Highly Paid Consultants were hired to fix it up, after which the company released it 6 months ahead of schedule, long before it was finished.
I didn't mean to bring up x264 as a bad example - it certainly seems to be a very stable project. I just mentioned it as a pretty common example of the "latest build is the greatest build" trend in software projects. In many small projects (open and closed source) believing that the latest incremental build is neccessarily also the best build tends to be more a form of blind faith than actual confidence based on testing. Large projects tend to have a more strictly defined plan, goals, milestones, which *usually* (but not always) leads to more stable milestone releases.

Anyway... We're off-topic again, and I'd hate to see this thread derailed and closed like the VC-1 vs H.264 thread, so I'll stop talking about software engineering philosophies now. :)

MfA

23rd August 2007, 13:50

Maybe JND metrics would be more appropriate.
Hell no.

crypto

23rd August 2007, 18:49

Hell no.

OK, it was just an idea. I already wondered why nobody mentioned it before. :D

MfA

24th August 2007, 11:51

There was a JND like metric for Avisynth. The approach was quite popular before SSIM came around since it was almost as simple. The only problem is that it just doesn't correlate that well with subjective testing (IMO because there is a big mismatch between local frequency spaces and the way the HVS works).

cannuck

27th August 2007, 12:27

H.264 will be supported natively by most new graphics cards. NVidia, ATI and Intel have made a commitments to have full support for it. This means better than HD video on your PC will become possible in the not so distant future.

http://www.kaourantin.net/

The above quote is from Adobe's Prinicpal Engineer for Flash Player, Tinic Uro.

What exactly is he saying?

cannuck

27th August 2007, 12:33

Hmmm...

I wonder if Tinic Uro would be interested in joining this particular discussion? Be good to have another corporate view of the H.264 world.

CruNcher

27th August 2007, 15:38

he allready visits here (he lists links to doom9) and many video engineers from commercial R&D companies actually do :)
and yes what he actually says is that the 100 kb Mainconcept Decoder is gonna do Hardware Acelleration with Nvidia/ATI/Intel cards soon :)
also very interesting the Flash Decoder is 10 bit capable (High 10 Profile) :P

cannuck

29th August 2007, 18:54

I wonder why Motion JPG-2000 isn't included in the comparison here. Some Motion JPG-2000 companies claim that Motion JPG-2000 is 10 times faster than VC-1.

At the same time there is a study that concludes that:
At very high resolution and high bit-rates, Motion-JPG-2000 clearly outperforms H.264/AVC"

http://64.233.167.104/search?q=cache:dGvLLNoK74IJ:www.f4.fhtw-berlin.de/~barthel/paper/spie03_marpe_et_al.pdf+Jpeg2000+versus+h.264&hl=en&ct=clnk&cd=1&gl=ca

Sergey A. Sablin

29th August 2007, 19:46

I wonder why Motion JPG-2000 isn't included in the comparison here. Some Motion JPG-2000 companies claim that Motion JPG-2000 is 10 times faster than VC-1.

At the same time there is a study that concludes that:

http://64.233.167.104/search?q=cache:dGvLLNoK74IJ:www.f4.fhtw-berlin.de/~barthel/paper/spie03_marpe_et_al.pdf+Jpeg2000+versus+h.264&hl=en&ct=clnk&cd=1&gl=ca

it is comparison of pure intra coding, ie each picture is encoded as a key frame, thus limiting H.264 abilities.

one of the reasons why MJ2K isn't widely used is its complexity on decoding - it is far slower than performance of block based codecs. 10 times faster? BS!

Golgot13

29th August 2007, 20:18

I wonder why Motion JPG-2000 isn't included in the comparison here.

Because it's not compliant with HD DVD or BD (see first page)

Some Motion JPG-2000 companies claim that Motion JPG-2000 is 10 times faster than VC-1.

Yes but it don't have the same limitation (vbv and other contraint).

cannuck

29th August 2007, 22:41

Because it's not compliant with HD DVD or BD

Oops! ;)

Since Motion JPG-2000 is used in theatres , I wonder how it got excluded from the specs for HD DVD? Another one of M$'s gambits?

http://www.groklaw.net/article.php?story=20070829070630660

Golgot13

29th August 2007, 23:48

Oops! ;)

Since Motion JPG-2000 is used in theatres , I wonder how it got excluded from the specs for HD DVD?

Simple=> money

And I don't know if there are some manufacture compagny which made a chipset decoder.

Sagittaire

30th August 2007, 01:27

Oops! ;)

Since Motion JPG-2000 is used in theatres , I wonder how it got excluded from the specs for HD DVD? Another one of M$'s gambits?

http://www.groklaw.net/article.php?story=20070829070630660

No MPEG2, H264 and VC1 produce simply better result at the same bitrate. Pure intra coding is not a really efficient way for best quality/bitrate performance ...

CruNcher

31st August 2007, 00:01

@benwaggoner
any estimation when you gonna release the source you talked about ?

Golgot13

31st August 2007, 07:41

@benwaggoner
any estimation when you gonna release the source you talked about ?

Ben can not release the source now because it's period of show and seminar (IFA, IBC, CEDIA,...), we need to wait 1-2 week
I will may be see him and talk about the VC1 efficient (some people on this forum made test with movie grain and... :D :p )

zambelli

31st August 2007, 07:53

Oops! ;)

Since Motion JPG-2000 is used in theatres , I wonder how it got excluded from the specs for HD DVD? Another one of M$'s gambits?
You really overestimate Microsoft's influence in the HD-DVD forum and the video industry in general. For most part Microsoft is considered an underdog in the video industry and is far from commanding others what to do. The OOXML is completely unrelated to Microsoft's video efforts. Yeah, I know, same company, so clearly it's all related, right? Well, no. There's really no coordinated effort going on on that level.

Manao

31st August 2007, 08:11

MJPEG 2K was not considered for HD DVD because it requires a bitrate of 60+ Mb/sec. That means 50 GB just for a 2 hours long movie.

Cinema uses MJPEG 2K because it's simpler. They can afford the bitrate ( the limit is the harddrive bandwidth, not its capacity ), and they want visually lossless. At the time they took the decision, H264 was just being standardized, didn't have 8x8 DCT, was as complicated as JPEG2K to decode in intra, and was poorly rated against Mpeg2 at high bitrates.

CruNcher

31st August 2007, 11:41

Ben can not release the source now because it's period of show and seminar (IFA, IBC, CEDIA,...), we need to wait 1-2 week
I will may be see him and talk about the VC1 efficient (some people on this forum made test with movie grain and... :D :p )

Yes and im making steady progress i found what could be a problem in x264s block prediction heavy use of intra blocks @ low subme ;) and also other things are on my list but i have a real life too :P and also testing some brandnew HVS stuff i can't talk about yet ;)

cannuck

1st September 2007, 21:25

Yeah, I know, same company, so clearly it's all related,

Well that's a good guess;) It's that simple for some people (like me). Again, it's not just OOXML, if you check out GROKLAW, you will easily see that the issue(s) is much larger. There are allegations there, about M$ trying to destroy FOSS, and Linux "communities" - which (if true) would have a profound impact on everything.

I assume that you are in a "Pay For Say" situation, so you can't say anything different than what you are saying about this issue.

zambelli

2nd September 2007, 09:14

I assume that you are in a "Pay For Say" situation, so you can't say anything different than what you are saying about this issue.
There's nothing different to be said about it. I've been working at Microsoft for 5 years and I have never heard anybody talk about destroying FOSS or Linux, especially not on a product team level. There is no dirty secret to tell because there is no dirty secret to begin with.

Sagittaire

2nd September 2007, 09:26

Well that's a good guess;) It's that simple for some people (like me). Again, it's not just OOXML, if you check out GROKLAW, you will easily see that the issue(s) is much larger. There are allegations there, about M$ trying to destroy FOSS, and Linux "communities" - which (if true) would have a profound impact on everything.

I assume that you are in a "Pay For Say" situation, so you can't say anything different than what you are saying about this issue.

Well I don't like always the same simplist "M$ is evil" and "Open Source is beautifull". We live in a real world and in this world we must pay the factures. In this real world MS must pay its developers. In this real world MS must simply make money just like all the other company in the world.

Anyway in this challenge Open Source (x264 implementation) produce better objective result than MS (PEP implementation).

CruNcher

2nd September 2007, 20:00

There's nothing different to be said about it. I've been working at Microsoft for 5 years and I have never heard anybody talk about destroying FOSS or Linux, especially not on a product team level. There is no dirty secret to tell because there is no dirty secret to begin with.

hehe zambelli you know this ;)

/\
/ \
/ \
/ \
/ \
/ \
/ \
/ \
/ \
/ \
/ \
/ \
/________________________\

Golgot13

3rd September 2007, 00:20

I've been working at Microsoft for 5 years and I have never heard anybody talk about destroying FOSS or Linux, especially not on a product team level.

This thread is not to talk about this....
But last problem of MS patents use by open source like Linux...:rolleyes:
After some Linux companies signed agreement with MS.... ???

There is no dirty secret to tell because there is no dirty secret to begin with.

In all company there is some secret, it's business.

I don't see Ben at IFA... :(
I don't see any link for video source with grain to close this Summer Challenge...

Beastie Boy

3rd September 2007, 14:42

It would be great if this thread could get back on topic and concentrate on producing some results.

Cheers, Beastie.

Sharktooth

3rd September 2007, 15:09

Results have been produced.
Look at the updated conclusions on the first page.

Beastie Boy

3rd September 2007, 15:36

Sorry. I thought the idea was for people to try and better the previous results and come up with some optimal settings for each bitrate / codec combination. Has this already been done? If so, I need to re-read this thread and take a look at the videos produced.
And on with the OT rantings :D

Cheers, Beastie.

Sharktooth

3rd September 2007, 15:57

yes, you're right, but it seems no one has produced better results than the actual ones.

Golgot13

3rd September 2007, 17:23

Sorry. I thought the idea was for people to try and better the previous results and come up with some optimal settings for each bitrate / codec combination.

The result is available but MS said it was not good because video source is CG.
I made some test:
H264 is better than VC1 from Cinevision PSE (but X264 can not produce better quality
than Mainconcept core :) ).

We wait a video source with grain from MS. It will available soon in middle of September
after all shows and seminars.

Dark Shikari

3rd September 2007, 20:11

(but X264 can not produce better quality than Mainconcept core :) ).
Expect this to change soon :)

Sagittaire

5th September 2007, 11:29

Golgot13

11th September 2007, 21:13

Hi all,

a post to remember at Ben we wait "the" source.
I don't have any true answer if I will can use the new core 1.07 of PEP.
I sure Ben will use it to made encoding file (but I prefer to test it too).

I made some test of VC1 on good film source (without grain ;) because digital movie)
I really surprise by the good quality of VC1 at 8Mbps on this source, but H264 version is better :p .

CruNcher

11th September 2007, 21:23

@Golgot13

Encoding/Decoding Complexity of both compared vs the Quality Difference ? was it far away ?

Golgot13

11th September 2007, 23:40

@Golgot13
Encoding/Decoding Complexity of both compared vs the Quality Difference ? was it far away ?

Only to finish this thread.
Some people are not agree to say what it is the best codec.
Ben said it is not same result with video with grain (movie grain) and promised a video source.

There is some reason that the industry (broadcast, IPTV box,...) choosed H264
May be some people can say on IBC if there were H264 solution for broadcaster TV, mobile provider,...
(If I say it some people will not believe me)

benwaggoner

12th September 2007, 00:09

Hi all,

a post to remember at Ben we wait "the" source.
I don't have any true answer if I will can use the new core 1.07 of PEP.
I sure Ben will use it to made encoding file (but I prefer to test it too).
I think I said I'd try to get it done "a few weeks after IBC" and IBC just ended today :).

I've got all the source on a drive, but need to build my new workstation first.

Golgot13

12th September 2007, 11:24

... and IBC just ended today :).

:eek: :eek:

I've got all the source on a drive, but need to build my new workstation first.

Intel Quad Core + NVidia card 8500 (at minimum) will be enough for VC1 and H264 encoding :rolleyes:
The really problem of HD encoding is the size of uncompressed video (size and speed of hard disk).
My dream for HD encoding it's a hardware HD encoder like BitPack of digital vision
which can encode in VC1, MPEG2 and H264.

Golgot13

17th September 2007, 09:14

I think I said I'd try to get it done "a few weeks after IBC" and IBC just ended today :).

What sort of sequence there are on this video source ?
Movie with 3D, war, paysage,.. ?

I saw last bad new for MS today in EU. I hope you will not have same problem with VC1 toolkit
given only at some specific companies 6 or 9 month before others.

Sharktooth

17th September 2007, 12:40

ill define it a good news. EU is not US... and the time of the US ubercorporations ruling the world without respecting any laws is coming to an end.

Golgot13

17th September 2007, 14:00

About VC1 vs H264, after other tests this week: H264 can not be compared with VC1.
H264 is better, last developpment for movie grain with or without FGM (or FGT) are good.
And a new actor (great actor) of H264 will propose soon a encoder for HDDVD and BD (only H264).

It will be sure better than Sony, Thomson, CC-HDe,...

About IBC, I surprise that nobody said (except me) there was lot of H264 hardware.
And H264 is used on different broadcast system: broadcast TV by terrestrial, cable, satellite;
IPTV (HD in France) ; mobile phone (all last phone support H264 not VC1 except phone with WinCE OS);
video security system; ...

Sharktooth

17th September 2007, 14:05

yeah, i know that. why do you tell this to me?
maybe my post was confusing... i was referring to M$...

bobololo

17th September 2007, 19:48

About IBC, I surprise that nobody said (except me) there was lot of H264 hardware.
And H264 is used on different broadcast system: broadcast TV by terrestrial, cable, satellite;
IPTV (HD in France) ; mobile phone (all last phone support H264 not VC1 except phone with WinCE OS);
video security system; ...

Actually that has not changed over past years. I would say that H.264 has took over VC-1 on the broadcast market for 2 years in my opinion.

I made a quick stop at Microsoft booth which was rather hidden compared to the main show floor. It was a real labyrinth to get to the topaz lounge ;) Anyway the demonstrated things confirmed that VC-1 is definitely not so adopted in higher end broadcasting (HD / SD DTV, IPTV, etc). Only mobile applications seemed to still get some interest for VC-1.

ps: I was wondering, are you the person from CMC ?

Golgot13

17th September 2007, 21:03

ps: I was wondering, are you the person from CMC ?

If I was a person of CMC, I will be pro-MS because I received MS support 6 or 9 month before all (alone in France...).

And I surprise to know that CMC was interested by H264 (they know you because you talked about them).
This company said that VC1 is the better codec... better than H264... but today they try to find H264 solution...

diogen

18th September 2007, 01:16

Sergey A. Sablin

18th September 2007, 02:06

Golgot13

18th September 2007, 09:44

I lost count how many times local experts (non-MS) proclaimed AVC being so much better than VC-1 that there is no contest. The only thing that I don't get is this: why repeat it so often when only a stupid won't get it by now. I can't believe convincing those few MS employees (that post here) can be of such importance to these know-it-all experts.

Diogen.

+2
Industry understood this many year ago...

But MS with communication (and more...) show that VC1 is better:
http://www.microsoft.com/windows/windowsmedia/howto/articles/vc1techoverview.aspx#VC1ComparedtoOtherCodecs

Sharktooth

18th September 2007, 12:45

As every codecs VC-1 has its own pros and cons. At high bitrates it's not that bad, expecially when it comes to retaining fine details.
However all codecs are converging to transparency at high bitrates... but VC-1 seems to be particularly tuned to reach a very good quality at HD-DVD/BD typical bitrates.
Those bitrates are so high that the difference between VC-1 and h.264 can be no longer spotted.
So, for this kind of usage, VC-1 is a good codec, but affirming it's generally comparable or that beats h.264 is just a big fat lie.

Golgot13

18th September 2007, 14:28

VC-1 is a good codec, but affirming it's generally comparable or that beats h.264 is just a big fat lie.

Agree, it's a lie.

I don't understand why we don't have lot of HDDVD or BD in H264.
HDDVD use VC1 because VC1 encoder was free, but not free today... ???
BD from Sony use MPEG2 because they bought MPEG2 HD encoder or it' realtime encoder ?

Inventive Software

18th September 2007, 15:58

Toshiba has interests in H.264, which also helped develop HD-DVD. VC-1 is primarily base-lined off WMV9, which is MS, which supports HD-DVD. Sony use MPEG-2 because they have THAT much pride, and so little interest in the consumer. ;)

Sagittaire

18th September 2007, 16:08

Inventive Software

18th September 2007, 17:07

diogen

18th September 2007, 17:35

Industry understood this many year ago...Really? How many years ago?
My understanding is AVC is just few years old...
And it was a superior codec the first year maybe on paper...

I can't understand why the argumentation is shifted at will depending on availability of good points.

Industry acceptance.
When comparing codec capabilities, who the f*ck cares about industry acceptance?
Does it actually need to be proven that politics plays at least as much a role in codec decisions than the codec capabilities?
What about workflow? Not being spoiled with access to commercial encoders, I find MS Expression A/B comparison feature
of higher value to me - actually showing what all the myriad parameters mean - than any features command line encoders can offer.

Codec performance.
ED was a good test with a non-representative source. Everybody agrees that at 25Mbps+ codec doesn't matter.
Real life non-CG material (everybody is expecting Ben to provide) should answer the question about grain preservation and such...
Why not wait until this is done before beating the drum of AVC's superiority?

Diogen.

foxyshadis

18th September 2007, 18:20

Compared to H.264 or VC-1 at 15-25 Mbps, perhaps so. But for easy encoding, MPEG-2 is the first way to go for most small-time movie companies that want to switch from DVD to HD-DVD, since it doesn't necessarily mean learning a new software suite.

One point that I've noticed with most H.264 / VC-1 / MPEG-2 codec comparisons in HD, is that the MPEG-2 version is *usually* a bit softer on the eye. But that's the only consistent thing IMHO.

You have to buy the HD package of whatever you use anyway, so as long as it's out there you might as well buy the H.264 or VC-1 package, unless it costs a great deal more. I can't imagine the interfaces of any of them being very different, aside from advanced codec options.

Golgot13

18th September 2007, 20:52

Really? How many years ago?
My understanding is AVC is just few years old...

I can give a simple example at professional people, NAB2005 and NAB2006:
NAB2005, lot of companies talked about VC1 and promised VC1 hardware (there was some H264 solution)
NAB2006, all companies showed H264 solutions and very few VC1 solutions

About H264 the first HD channel (not SD) broadcasted in 2005 and the first HD package (Voom) in 2006.

And it was a superior codec the first year maybe on paper...
You can read this link, VC1 is better but we saw nothing about measure and nothing about other encoder use on test:
http://www.microsoft.com/windows/windowsmedia/howto/articles/vc1techoverview.aspx#VC1ComparedtoOtherCodecs

VC1 is good codec on small CPU computer (like WMVHD) and at 20-25Mbps can make good picture quality
with movie grain (with very few preprocessing).

zambelli

19th September 2007, 04:26

You can read this link, VC1 is better but we saw nothing about measure and nothing about other encoder use on test:
http://www.microsoft.com/windows/windowsmedia/howto/articles/vc1techoverview.aspx#VC1ComparedtoOtherCodecs
I'm sure everybody read it one of the previous 6-7 times that you posted that link. Give it a rest. Yes, there are dubious references in there to "internal tests" of MPEG-2 that I agree should be removed, and though the H.264 references are more specific (DVD Forum's 2002 evaluation) I think they are too old to be in that article at this point. I'll work on having that cleaned up as I don't particularly like seeing marketing mix with technical articles either.

I saw last bad new for MS today in EU. I hope you will not have same problem with VC1 toolkit
given only at some specific companies 6 or 9 month before others.
:eek: Are you serious? Umm, you do realize there's nothing illegal about a company choosing who to do business with based on cost effectiveness, right? If every time a company entered a business partnership it got sued for NOT having partnerships with every other company in the business, every company would be bankrupt by now.

I lost count how many times local experts (non-MS) proclaimed AVC being so much better than VC-1 that there is no contest. The only thing that I don't get is this: why repeat it so often when only a stupid won't get it by now. I can't believe convincing those few MS employees (that post here) can be of such importance to these know-it-all experts.
Most of the time when I get involved in these VC-1 vs H.264 threads I'm primarily ensuring that comparisons of Microsoft VC-1 and other encoders are being done fairly and that VC-1 information is correct and unbiased. I don't have a problem with anybody putting together a fair test and making conclusions of their own. Why exactly certain people feel the need to prove H.264 superiority or demand proof from me about VC-1 superiority when I have in fact never stated that H.264 is an inferior or bad codec - is beyond me too.

diogen

19th September 2007, 04:32

I can give a simple example at professional people, NAB2005 and NAB2006:
NAB2005, lot of companies talked about VC1 and promised VC1 hardware (there was some H264 solution)
NAB2006, all companies showed H264 solutions and very few VC1 solutionsFRExt was finished by the end of 2004.
There couldn't have been much of H.264 solutions by April 2005 (NAB2005).
And according to Tom McMahon from Broadcom, without FRExt H.264 wasn't much better than MPEG-2.
You can read this link, VC1 is better but we saw nothing about measure and nothing about other encoder use on test:
Good point.
So lets not follow Microsoft in this respect and just claim AVC is better (gazillion times) but offer some proof (measure - in your words).

Diogen.

Golgot13

19th September 2007, 07:25

So lets not follow Microsoft in this respect and just claim AVC is better (gazillion times) but offer some proof (measure - in your words).

Yes, you're right but I posted in January on this forum that my company have VC1 toolkit
and I would do comparison. But all company, after, received email of MS which said it's prohibited
because they signed NDA. Today my company don't have a VC1 license (we work with other company for this)
we can have last version (we will test it).

I post a on other thread at Ben if I can use the last version (when we receive it) to make comparison
but he don't said yes or no (there is some NDA to use it).

Golgot13

19th September 2007, 07:27

:eek: Are you serious? Umm, you do realize there's nothing illegal about a company choosing who to do business with based on cost effectiveness, right? If every time a company entered a business partnership it got sued for NOT having partnerships with every other company in the business, every company would be bankrupt by now.

In EU, the "unfair competition" is prohibited

obieobieobie

19th September 2007, 08:16

Oh, come on, Golgot13. Choosing ones business partners is not unfair competition.

(I'm from Europe)

Golgot13

19th September 2007, 09:42

Oh, come on, Golgot13. Choosing ones business partners is not unfair competition.
(I'm from Europe)

No, when you give a software for free at one company (or 2 only) and help to make a product, you lock the market.
Because this software was alone to make sure a product compliant with specification (others software worked at the end of 2006).

And MS choosed only two partner only in Europe about this.
All other company which asked to have this software (without support because MS can't support much company)
received no answer (I'm not alone for this).

Some companies lost time and money (no contract because they can not produce HDDVD).
And HDDVD format lost too, because they was only two companies (with MS support)
which can produce HDDVD in Europe (Q2-Q3 2006). Today it's better because MS made Technical Training
to have more company which could make HDDVD (so in Europe, there are more HDDVD project).

Golgot13

19th September 2007, 10:08

FRExt was finished by the end of 2004.
There couldn't have been much of H.264 solutions by April 2005 (NAB2005).
And according to Tom McMahon from Broadcom, without FRExt H.264 wasn't much better than MPEG-2.

You're right, but FRExt is for professional application (like Studio Profile with MPEG4 Part2).
Today, H264 used by TV Broadcaster are in 8bit and 4:2:0 (Last year in Main Profil and this year in High Profil).
And it's same for HD disc and box (IPTV).

Do you know if there is some chipset with support "High 10", "High 4:2:2" and "High 4:4:4" ?

I sure when it will be available we will see some new professional HD VTR
(Sony and Panasonic use today FPGA on Camcorder for Intra at High 10).

diogen

19th September 2007, 15:02

I have to say upfront, I'm not privy to any inside information.
This compression thing is my hobby and has less than nothing to do with my day job.
Do you know if there is some chipset with support "High 10", "High 4:2:2" and "High 4:4:4" ?No, I don't.
But reading the insiders' posts on AVS I got the impression there is not much to be gained abobe 4:2:2/10bit.

You're right, but FRExt is for professional application (like Studio Profile with MPEG4 Part2).My understanding is FRExt Extensions make AVC the great codec it is today and are applicable to 4:2:0/8bit (what BD/HD use) as well.

BTW, does x264 use some features that are from FRExt domain?

Diogen.

diogen

19th September 2007, 15:20

I have a VC1 encoder to make my test but I can not publish C'mon, Golgot13.
If you have some internet/forum posting experience, you should know how to make public the results of your encodings without risking them being traced back to you.

Diogen.

akupenguin

19th September 2007, 15:57

You're right, but FRExt is for professional application (like Studio Profile with MPEG4 Part2).
FRExt is a collection of tools. Some of them are like studio profile (extra colorspaces and bit depths), others are useful for all applications (adaptive dct size and cqm).
8x8dct really should have been in baseline profile.

Golgot13

19th September 2007, 16:12

you should know how to make public the results of your encodings without risking them being traced back to you.

Yes, but the video used (with movie grain) is copyrighted...
And some people will say it's not true measure because they can not reproduce it(if they don't have this video).
We wait the video from Ben.

And the contact of Sagitaire use VC1enc.exe, I can make for H264 (like MS with VC1) my encoding option.

About FRExt, it was adopted in July 2004.

benwaggoner

20th September 2007, 01:45

Real life non-CG material (everybody is expecting Ben to provide) should answer the question about grain preservation and such...
Just to update, I have the source, but both my workstations are down right now :(. I'll probably just give up and start doing a proxy edit on my laptop tomorrow, and then conform when my Barcelona is finally up to snuff.

So, we're still a couple weeks out from something final. If folks are interested, I might make a SD test encode of it available earlier to give folks a taste of the source, cuts, etcetera. The goal is to make it "realistically challenging" so I welcome suggestions for the kinds of edits and such people would like in this kind of test clip.

Sagittaire

20th September 2007, 05:13

Just to update, I have the source, but both my workstations are down right now :(. I'll probably just give up and start doing a proxy edit on my laptop tomorrow, and then conform when my Barcelona is finally up to snuff.

Possible to make lossless encoding with high efficient codec (like FFV1 for example). With directly good color matrix (YV12 bt709). With directly the good pre-process (dithering, dark noise filtering ... etc etc).

benwaggoner

20th September 2007, 05:40

Possible to make lossless encoding with high efficient codec (like FFV1 for example). With directly good color matrix (YV12 bt709). With directly the good pre-process (dithering, dark noise filtering ... etc etc).
Yes, I'd be providing a 4:2:0 master for the testing, so we don't have to argue about dithering modes and such.

I've been considering doing either a .zip of an IYUV .avi file, or using Lagarith in its YV12 mode. Either preference?

Probably should start a new thread to discuss this...

Dark Shikari

20th September 2007, 05:49

Yes, I'd be providing a 4:2:0 master for the testing, so we don't have to argue about dithering modes and such.

I've been considering doing either a .zip of an IYUV .avi file, or using Lagarith in its YV12 mode. Either preference?

Probably should start a new thread to discuss this...
FFV1 is probably better than both, and its supported by libavcodec.

ZIP is also a very very bad compressor and will take ages to decompress.

Golgot13

20th September 2007, 10:29

Agree it will be better if we have FFV1 .

Sharktooth

20th September 2007, 12:40

h.264 lossless...

Golgot13

20th September 2007, 13:28

h.264 lossless...

Yes, but the speed to encode and decode will not be same :D.

@Ben:
there is not VC1 lossless option ?
VC1 will be on codec comparison 2007?
(I talked about it in june with you and Zambelli).

Sharktooth

20th September 2007, 13:32

well, if you have a new videocard the decoding can be HW assisted so you will have faster re-encoding... ;)

Golgot13

20th September 2007, 13:56

well, if you have a new videocard the decoding can be HW assisted so you will have faster re-encoding... ;)

Yes I have a Nvidia 8500 but I 'm not sure it can decode H264 with Lossless option (?)

About Fourth Annual MSU H264 comparison, there is some japanese company which is contributor, KDDI Labs
(made the first H264, up to HP@L4.1, editing software at frame accure). I hope to see NTT which have software encoder
(1920x1080 video in H264 at 3Mbps, demo at NAB !!!).
VC1 can be compare like Divx on 3rd Annual MSU...

Inventive Software

20th September 2007, 14:18

Sure it can decode it....... it's just an enormous bitrate over "normal" content is all.

Golgot13

20th September 2007, 14:22

Sure it can decode it....... it's just an enormous bitrate over "normal" content is all.

There is no H264 bitrate limitation of NVidia acceleration.
Because all hardware chipset decoder (ofr H264) are limited by profile and bitrate.

benwaggoner

20th September 2007, 19:51

FFV1 is probably better than both, and its supported by libavcodec.

ZIP is also a very very bad compressor and will take ages to decompress.
Fair enough. But I'm hoping to have a pretty universally playable file, and I think an IYUV .avi file will play back pretty much everywhere, even in QuickTime on a Mac.

One of the benefits of being at Microsoft is my download bandwidth isn't capped :).

Of course, since the content is provided for compression testing, everyone is welcome to use it to test and distribute with lossless codecs as well.

Dark Shikari

20th September 2007, 20:10

Fair enough. But I'm hoping to have a pretty universally playable file, and I think an IYUV .avi file will play back pretty much everywhere, even in QuickTime on a Mac.

One of the benefits of being at Microsoft is my download bandwidth isn't capped :).

Of course, since the content is provided for compression testing, everyone is welcome to use it to test and distribute with lossless codecs as well.An IYUV would be absolutely humongous though, and zipping it would be really pointless because while it would lower its size, ZIP is not designed for video contexts and as such is less efficient than the least efficient lossless codecs in my experience.

You could upload both an FFV1 for the sane people, and a ZIP for the insane people, and see how many people are in their right mind... :D

zambelli

21st September 2007, 10:17

No, when you give a software for free at one company (or 2 only) and help to make a product, you lock the market.
I think you misunderstand the principles of unfair competition. Locking a market means locking out and preventing companies from joining and competing in a market in order to preserve one's domination. Considering that Microsoft wasn't making any money on the VC-1 encoder and that it was in no way preventing authoring companies from encoding for HD-DVD using H.264, MPEG-2 or competing VC-1 encoders - I really don't see how that could even remotely be considered unfair competition.

Just because somebody didn't give you something for free doesn't automatically give you the right to have had it.

And MS choosed only two partner only in Europe about this.
All other company which asked to have this software (without support because MS can't support much company)
received no answer (I'm not alone for this).
We've been over this before. It wasn't a political decision and Microsoft wasn't trying to control the HD-DVD authoring market. It was a simple matter of prioritizing where limited resources should be spent.

VC1 will be on codec comparison 2007?
(I talked about it in june with you and Zambelli).
No, I'm afraid not. MSU extended us a last-minute invitation but we simply couldn't prepare in time for the comparison. It came right around the time we were releasing the VC-1 Encoder SDK and preparing for IBC.

zambelli

21st September 2007, 10:19

Fair enough. But I'm hoping to have a pretty universally playable file, and I think an IYUV .avi file will play back pretty much everywhere, even in QuickTime on a Mac.
We can make a lossless H.264 in MP4 video for the Mac folks. It'll be more useful than an AVI anyway.

Golgot13

21st September 2007, 10:54

Just because somebody didn't give you something for free doesn't automatically give you the right to have had it.

Like Windows Media Player on MS OS, your partner could have code, software and more.
But all other companies could do nothing, and lost part of market or all market.
EU commission was not agree with this (you know). And it was same for the market (HDDVD).
I think it's why there is a inquire of EU commission (and for other reasons)

I didn't know why we could not buy it too, I wasn't agree because it was impossible to have it only.

Golgot13

21st September 2007, 11:03

No, I'm afraid not. MSU extended us a last-minute invitation but we simply couldn't prepare in time for the comparison. It came right around the time we were releasing the VC-1 Encoder SDK and preparing for IBC.

But I think you can ask today to be included on this test because your codec have a big part
of HD disc market.

Do you read the comparison between picture codec test with MS HD Photo and different JPEG2000 codec?
http://www.compression.ru/video/codec_comparison/wmp_codecs_comparison_en.html

Or download the test in PDF format:
http://www.compression.ru/video/codec_comparison/pdf/wmp_codec_comparison_en.pdf

Sharktooth

21st September 2007, 12:43

http://forum.doom9.org/showthread.php?p=1047342#post1047342

Sharktooth

21st September 2007, 13:08

those things make me laugh...

Golgot13

27th September 2007, 12:46

Of course, since the content is provided for compression testing, everyone is welcome to use it to test and distribute with lossless codecs as well.

Ben, I wait the source (since more than one month).
About H264, DirecTV announce 21 more HD channels (in H264), so in USA (MS 's country)
people will can see 51 H264 HD channels and at the end of 2007 there will be 100 H264 HD channel.
For VC1 in IPTV, there is only Swisscom project (?), all others in SD use MPEG2 and H264.

Sharktooth

27th September 2007, 13:10

VC-1 is doomed. Let it die alone...

benwaggoner

27th September 2007, 17:13

VC-1 is doomed. Let it die alone...
In what context?

Given that VC-1 is preinstalled on 95% of the world's computers, it's rather hugely important. Were we to decide to spike it today (which we aren't :)), people would still be using it in huge volume years from now. Don't underestimate the slow pace of codec adoption outside in the general public - we're not even to the point where I consider using VC-1 Advanced Profile "safe" for a general audience unless Silverlight or MCE is being targeted, given how many WMP9 installs on managed desktops there are out there.

Golgot13

27th September 2007, 18:56

VC-1 is doomed. Let it die alone...

I'm agree with Ben about VC1 and computer, but it will be hard to be used by another "support".
H264 and MPEG2 are used on all others type. To my mind, VC1 is good for Handheld system
(need less CPU and consumption) but today some manufactor announce H264 chipset optimized
for Handheld devices (less consumption than chipset of today).

But Ben, it's possible to know when we could test our codecs on the source ? :rolleyes: :)

Can you post too your best VC1 encoding with this source ?

benwaggoner

27th September 2007, 19:12

I'm agree with Ben about VC1 and computer, but it will be hard to be used by another "support".
H264 and MPEG2 are used on all others type. To my mind, VC1 is good for Handheld system
(need less CPU and consumption) but today some manufactor announce H264 chipset optimized
for Handheld devices (less consumption than chipset of today).
You're forgetting that the majority of HD optical discs use VC-1!

But Ben, it's possible to know when we could test our codecs on the source ? :rolleyes: :)

Can you post too your best VC1 encoding with this source ?
I just got back the workstation yesterday afternoon (turns out it was a sound card conflict). Fingers crossed, I'll be able to start logging the video tomorrow.

Golgot13

27th September 2007, 20:53

You're forgetting that the majority of HD optical discs use VC-1!

Yes, sure for HDDVD but there is more and more exception with H264 (in UK, Germany, France,...)
and with BD, Sony prefer MPEG2 (bad implementation sometime) and H264, others H264 and some VC1.

I just got back the workstation yesterday afternoon (turns out it was a sound card conflict). Fingers crossed, I'll be able to start logging the video tomorrow.

I hope you will not use Vista (lot of problem with driver and VC1 encoder)...
Can you say more about this video?
Can you put some pictures from your source?

benwaggoner

27th September 2007, 21:29

Yes, sure for HDDVD but there is more and more exception with H264 (in UK, Germany, France,...)
and with BD, Sony prefer MPEG2 (bad implementation sometime) and H264, others H264 and some VC1.
We'll see how the numbers evolve, but so far we're the leading codec for HD optical - we're clearly very competitive in that market.

I hope you will not use Vista (lot of problem with driver and VC1 encoder)...
Can you say more about this video?
Can you put some pictures from your source?
I've been using Vista for many months for content creation without any issues. Adobe's CS3 Suite was the last public product I needed to be able to move happily to Vista 24x7.

The workstaiton has XP on it right now, but I think I'll put Vista Ultimate on it now just because you said that :).

Golgot13

27th September 2007, 22:03

The workstaiton has XP on it right now, but I think I'll put Vista Ultimate on it now just because you said that :).

The last VC1 encoder work well on Vista OS ?
Nice news to sell more new PC (my company don't want to change it) with better CPU
(there are now some nice motherboard which support well two Intel QuadCore)

benwaggoner

27th September 2007, 23:38

The last VC1 encoder work well on Vista OS ?
Yep, I'm running the new version on my Vista laptop without a hitch.

Sharktooth

3rd October 2007, 20:02

a very slight OT:

http://pdl.warnerbros.com/wbol/uk/movies/300/300_F2_1080P.mov

http://gspsf.vo.llnwd.net/o10/300_Trailer2_8mbps_1080p29.98_5.1.wmv

which one looks better to you?

davidcw

5th October 2007, 10:35

Yes, sure for HDDVD but there is more and more exception with H264 (in UK, Germany, France,...)

It may be just coincidence but my 2 HD-DVD's out of 20 with visible artifacts were both encoded with AVC. Also, Planet Earth which was issued for the American market with an AVC encode didn't handle noisy shadow detail as well as the VC-1 encode and was given a lower picture rating by the reviewing site.
davidcw

Dark Shikari

5th October 2007, 15:13

It may be just coincidence but my 2 HD-DVD's out of 20 with visible artifacts were both encoded with AVC. Also, Planet Earth which was issued for the American market with an AVC encode didn't handle noisy shadow detail as well as the VC-1 encode and was given a lower picture rating by the reviewing site.
davidcwGenerally such artifacting is due to terrible VC-1/H.264 encoders rather than a problem with the standard itself. Theoretically, H.264 is superior to VC-1 in basically every way in terms of quality. Practically, its quite possible for H.264 to look worse in the case of a bad encoder.

davidcw

5th October 2007, 19:45

AVC encode didn't handle noisy shadow detail as well as the VC-1
davidcw

Could this be due to the in-loop filtering of AVC tending to remove more fine detail as it effects up to three pixels on either side off the boundary v's VC-1 effecting only one pixel either side of the boundary ?
davidcw

Edit: Here is the link to the review.

http://hddvd.highdefdigest.com/planetearth_us.html

Dethis

5th October 2007, 23:29

@ davidcw, about planet earth,

You (we) should not draw conclusions, about two encoder's capabilities, comparing one's 1080p24 vs other's 1080i30 encodings. Interlaced encoding at a 17% bigger framerate is a much more difficult task than 1080p24 (for any encoder).

davidcw

6th October 2007, 00:40

Golgot13

7th October 2007, 21:36

Yep, I'm running the new version on my Vista laptop without a hitch.

Are you sure?
It is not slow like (speed to deliver) the video source file
that we wait since August (?)

If somebody can give video file without problem of copyright
to test HD encoder on film movie (with grain).
I really think (with problem of delay) that H264 is clearly better.

All electronic device will use H264 encoder, there were some nice device
( showed on CEATEC ).

zambelli

11th October 2007, 11:28

Thanks for pointing this out. I had overlooked the fact that the AVC encode was 1080i30.
davidcw
I think all VC-1 and AVC encoders used in HD/BD production thus far have been somewhat struggling with interlaced quality. Unlike back in the DVD days, HD encoding has been so focused on progressive content that interlaced encoding is getting left out of the spotlight. There's definitely more progress to be made there, though in my personal opinion, most 1080i content might do better being scaled and encoded as 720p60 content.

zambelli

11th October 2007, 11:29

a very slight OT:
http://pdl.warnerbros.com/wbol/uk/movies/300/300_F2_1080P.mov
http://gspsf.vo.llnwd.net/o10/300_Trailer2_8mbps_1080p29.98_5.1.wmv
which one looks better to you?
Were the sources the same?

Sharktooth

11th October 2007, 13:06

dunno about sources. the .mov source seems more grainy though. however they have almost the same bitrate but what im interested in is what one has less compression artifacts.
i already did a frame by frame comparison but i would like to have some feedback from others.

Golgot13

11th October 2007, 13:45

@Zambelli

No news from Ben for video source.

I hope we will have the source and VC1 encoding file (with PEP 1.07) soon.
Last development of H264 encoder are good (Mainconcept core,...)
and make better quality than PEP 1.06 (or VC1 SDK encoder).

Sharktooth

11th October 2007, 19:06

They dont provide the (in)famous source... they're not participating the MSU codec comparison too...
My guess is they're trying to take some time to "dodge" a smack...

Golgot13

11th October 2007, 21:07

My guess is they're trying to take some time to "dodge" a smack...

They will not dodge.... No, it's MS and the best team who made the famous VC1 codec.
It is :
" VC-1 achieves clearly superior quality to MPEG-2 at comparable bit rates, and has been judged superior to H.264 in several independent studies. "
Sorry Zambelli, I give another time the link:
http://www.microsoft.com/windows/windowsmedia/howto/articles/vc1techoverview.aspx#VC1ComparedtoOtherCodecs

I'm not really independant because I think VC1 can not make better quality than VC1
(since January when MS prohibited all french company to provide any info about PEP and VC1)
but all other people on this forum saw result made by others who are really independant (like Sagitaire, ...)

zambelli

12th October 2007, 10:29

They dont provide the (in)famous source... they're not participating the MSU codec comparison too...
My guess is they're trying to take some time to "dodge" a smack...
...Or the explanation could be something more benign, such as "Ben has been insanely busy, and the timing of MSU's codec comparison didn't really fit well into the MS codec team's schedule". But if you prefer to speculate, who am I to protest.

BTW, I don't think Ben ever said the source he was going to provide would favor VC-1 in any way, so I'm not sure how delaying the source delivery works in favor of MS VC-1.

(since January when MS prohibited all french company to provide any info about PEP and VC1
Where do I even begin? Microsoft can't forbid *everybody* to talk about something, especially about VC-1 which isn't even owned by Microsoft. Microsoft can sign NDAs (Non-Disclosure Agreements) with companies it licenses its software to, which is a fairly standard practice in the software world when pre-release or beta software is in question.

BTW, the text you keep linking to will be changed before the end of the month, removing some of the more ambiguous references to MPEG-2 and H.264. Though I'm sure you'll probably just keep linking to some archive page after that. :rolleyes:

Sharktooth

12th October 2007, 15:21

BTW, I don't think Ben ever said the source he was going to provide would favor VC-1 in any way, so I'm not sure how delaying the source delivery works in favor of MS VC-1.
Here's the dodge...

Beastie Boy

12th October 2007, 15:30

Why does every thread that tries to compare codecs or encoders end up becoming a stream of endless critisism aimed at Microsoft? They make a codec that you are free to use if you wish, but no-one has a gun to your head. If you don't like it and prefer to use an alternative, then move along and find something else to whine about.
When this thread started I was hoping it would be more about optimising codecs to get the best out of each one, and not reduced to a 'mine's better than yours' type of argument that is best suited to a playground.

I am certainly not a MS fanboy but I have a good deal of respect for both zambelli and Ben for continuing to post and offer help in these forums, despite the constant tarade of critism that they have to endure.

Rant over.

Cheers, Beastie.

Sharktooth

12th October 2007, 15:40

The criticism comes when M$ affirmed VC-1 is better than other codecs and that's clearly false (maybe it's only true for MPEG-2...). That's still on their website... Also in the same page they say VC-1 was designed to achieve state-of-the-art (in my dictionary it means the best solution) compressed video quality that may range from very low to very high bitrates. That's false to. Since actually both MPEG-4 AVC and MPEG-4 ASP (and by consequence also VP6 and VP7...) look better at low bitrates, while at high bitrates... well, you have the results here on this thread. So, yes, the criticism comes from the spreading of false informations so that criticism is TOTALLY appropriate.
The conclusion is M$ VC-1 is a mediocre codec. It stands between MPEG-2 and MPEG-4... maybe it will be further developed to something interesting, but the actual situation is MPEG-4 ASP is a preferable choice.

Inventive Software

12th October 2007, 15:57

@Sharktooth: In my SD challenge, I find that the VC-1 encodes I do are actually better than both Xvid and DivX, the ASP codecs using their respective insane settings. I'll do another encode this weekend with Xvid 1.1.3 and DivX 6.7, and you can compare the difference. ;)

Sharktooth

12th October 2007, 16:02

@inventive software: https://forum.doom9.org/showthread.php?p=1051937#post1051937 and https://forum.doom9.org/showthread.php?p=1054468#post1054468

benwaggoner

12th October 2007, 16:35

Sheesh, all this testiness!

As Alex said, things have been unexpecteldy and insanely busy for us both in the last few weeks. I've made some progress on the HD source clip, but it's not close to done - at least another two weeks, sorry. Rest assured, there are plenty of other projects I've had to put on the back burner as well.

I did render out a pretty interesting HD 10-bit motion graphics test if that would tide people over. It's mainly to test our 10-bit to 8-bit conversion, but if people want something to play around with, I can get it posted when I'm on campus next week. I warn you, though - I composed the soundtrack :).

As for all the issues about comparing VC-1 v. H.264, remeber that all we can do as codec nerds is compare implementations, not standards. We've now released our new VC-1 Encoder SDKs to software companies to incorporate in their products, so you'll be able to judge the progress we've made in the last year soon enough. FSDK11 wasn' the end of VC-1 optimization, any more than x264 was frozen in '06.

Inventive Software

12th October 2007, 18:27

Is that 10 bits per channel?

benwaggoner

12th October 2007, 18:38

Is that 10 bits per channel?
10-bit luma. v210.

Golgot13

13th October 2007, 12:04

Where do I even begin? Microsoft can't forbid *everybody* to talk about something, especially about VC-1 which isn't even owned by Microsoft. Microsoft can sign NDAs (Non-Disclosure Agreements) with companies it licenses its software to, which is a fairly standard practice in the software world when pre-release or beta software is in question.

Yes, I know it's so why I stopped or removed part on all my thread about VC1 (see my post at January 2007).
But I would to show only the quality, because nobody (independant person or company)
could compare truly VC1 at other codec. And my company received a release version
not a pre-release or beta-version.

And I think when a software (implementation of Codec) is compare at other it is better for it:
Sagitaire find some bug on PeP (which influence the quality and HDDVD compliant)....

BTW, the text you keep linking to will be changed before the end of the month, removing some of the more ambiguous references to MPEG-2 and H.264.

Nice, so you remove my prefer VC1 reference link because I like to use it :rolleyes: :eek:.

Though I'm sure you'll probably just keep linking to some archive page after that. :rolleyes:

No, I'm not like you I use it because it is on your server and all people can see it. :p :p

45tripp

13th October 2007, 14:02

I think it's eager anticipation for the grain source,
making people a bit twitchy.

With high enough compression, metrics become rather unreliable, yes?
6000k wasn't that much of a compression considering how compressible the source is.

The source with grain, should render metric tests quite useless at high compression.

Personally i'd like to see perceptual analysis by trained eyes.

ty

Golgot13

13th October 2007, 17:37

The source with grain, should render metric tests quite useless at high compression.

Agree

Personally i'd like to see perceptual analysis by trained eyes.

There is lot of developpment and research about it. It 's why there is on professional encoder HVS/ psychovisual option.
But the efficiant of H264 (codec or implementation) give a good advantage...

MfA

13th October 2007, 18:02

Personally i'd like to see perceptual analysis by trained eyes.
Expert viewers can know what codec they are looking at, you run a risk of measuring average bias rather than quality when the differences get small.

Manao

13th October 2007, 19:15

And even worse than that, "trained eyes" don't see the same artifacts "common people" see. Or rather, they see all the artifacts, but weight them differently. So one has to ask whether their point of view is more pertinent than the point of view of the "average user".

benwaggoner

13th October 2007, 22:56

I think it's eager anticipation for the grain source, making people a bit twitchy.
Yeah, fully understood. We'll be using the same clip internally, so I'm on pressure from all ends. But I've been given some other higher priority projects I've got to get done first (which is why I'm working on a gorgeous Saturday afternoon).

45tripp

13th October 2007, 22:58

Expert viewers can know what codec they are looking at, you run a risk of measuring average bias rather than quality when the differences get small.
Impressive.
Still, when is anything ever truly unbiased?

And even worse than that, "trained eyes" don't see the same artifacts "common people" see.
I'd find it interesting.

Or rather, they see all the artifacts, but weight them differently. So one has to ask whether their point of view is more pertinent than the point of view of the "average user".
That could be considered educational.
Helping the average user better spot and understand various artifacts.

And why not align your preferences and biases to those of an advanced user?
I don't see how it can be worse than, or even construed different to, aliging to the bias of a mathematical model.

ty

Golgot13

27th October 2007, 12:21

@Zambelli

- Nice MS update this link about superior quality of VC1 (compare at H264 and MPEG2):
http://www.microsoft.com/windows/windowsmedia/howto/articles/vc1techoverview.aspx#VC1ComparedtoOtherCodecs

But I'm not agree with this:
" On all three measures (resolution, noise, and overall impression), the quality of the Microsoft VC-1 encoder was judged closest to the original D5 master. By comparison, the H.264 encoder that was tested rated as comparable only to MPEG-2 on two of the three measures (resolution and overall impression), and was rated somewhat worse than VC-1 on noise. "

- MS like to say something and don't give any graphs or informations about this affirmation.
- About H264 and noise, I can say that with my all PSNR graph show that H264 is better
than VC1 for video movie with noise (tests release with PeP 1.06).
- The difference is more than 7% PeP 1.07 make (compare with PeP 1.06).

@Ben
- We wait the video to show if H264 or VC1 is better for video movie with noise.
- I don't see lot of post from you on this forum but you answer quickly on DVDlist
when some professional want to use H264 codec (than VC1)...
- To my mind, H264 is better for HDDVD use and VC1 on BD (VC1 can be compare at H264 on HDDVD,
more space so more bitrate to have same PSNR)....

@Sharktooth
You may be say true about MS "dodge" for video because we wait three month soon (for the reign of VC1)...

Sharktooth

27th October 2007, 15:51

yup... have you ever had any doubt about it?

Inventive Software

28th October 2007, 03:20

Bear in mind that they're (Microsoft employees, Mr Waggoner in particular) trying to feed themselves and their families, not just your insatiable encoding habits. ;) It'll come when it comes. I anticipate it as much as anybody else, but I don't bang on about it. ;)

Sharktooth

28th October 2007, 17:15

@Inventive Software: it's just a matter of 5 minutes...

zambelli

29th October 2007, 04:07

But I'm not agree with this:
" On all three measures (resolution, noise, and overall impression), the quality of the Microsoft VC-1 encoder was judged closest to the original D5 master. By comparison, the H.264 encoder that was tested rated as comparable only to MPEG-2 on two of the three measures (resolution and overall impression), and was rated somewhat worse than VC-1 on noise. "

- MS like to say something and don't give any graphs or informations about this affirmation.
- About H264 and noise, I can say that with my all PSNR graph show that H264 is better
You might've missed this part of the text a paragraph earlier:

"For example, the DVD Forum conducted tests in the winter of 2002 to select codecs for the next-generation optical disc standard. Viewers from Hollywood film studios and major consumer electronics companies rated video clips on a scale of 1 to 5 for resolution, noise, and overall impression. Multiple codec implementations were tested, including MPEG-2, VC-1 (provided by Microsoft), H.264, and MPEG-4 Advanced Simple Profile. The baselines against which the codecs were compared were D5 masters and D-VHS (24 Mbps). During the tests, viewers were not told which codec was used to encode each of the clips."

The statements about VC-1 being better than H.264 specifically refer to the comparison in question: 2002's DVD Forum comparison. The article isn't making any generalizations, it's simply stating that Microsoft's VC-1 encoder was judged to look better than some H.264 encoder in a 2002 DVD Forum comparison. It's a simple statement of something that actually did occur.

There's a paragraph even earlier in the article that makes it very clear that every comparison of codecs is a comparison of codec implementations and is not useful for generalizing.

Golgot13

29th October 2007, 14:08

You're true about the state in 2002. I sure that VC1 (aka WMV9) was better than H264
(I was surprise by the quality of WMV on WMVHD title). But in 2002, H264 was in developpement
(not really finish) and today (since 2005) H264 is the best codec for new HD disc format.

I don't understand why you update your website to put old information ???
We are in 2007, and this codec challenge can show if this data information is available today.

Inventive Software

29th October 2007, 15:34

@Golgot: It's called "spin". ;)

IgorC

29th October 2007, 16:41

But in 2002, H264 was in developpement
(not really finish) and today (since 2005) H264 is the best codec for new HD disc format.
Since 2004.

I don't understand why you update your website to put old information ???

"We forget it for obvious reason". Marketing.

Golgot13

29th October 2007, 18:23

I forget

Bear in mind that they're (Microsoft employees, Mr Waggoner in particular) trying to feed themselves

I'm not agree, because if you read my old post you will know that MS use "forum"
to say at professional (on training) and magazine that his technology is better.
So I don't surprise to see some post of MS guys...

@IgorC
You don't test VC1 and H264 encoder in 2004 (?).
I think you talk about FRExt, but it was available at the end of 2004...

IgorC

29th October 2007, 21:31

You don't test VC1 and H264 encoder in 2004 (?).
I think you talk about FRExt, but it was available at the end of 2004...
I think I talk about Ateme H.264
There wasn't need to test VC1 in 2004 simply because it wasn't released.

zambelli

30th October 2007, 05:21

I think I talk about Ateme H.264
There wasn't need to test VC1 in 2004 simply because it wasn't released.
VC-1 didn't really exist as a finished standard until 2006. Most of the codec comparisons between "VC-1" and other codecs between 2002 and 2005 were done on WMV9, essentially. The DVD Forum comparison, for example, actually compared WMV9 Main Profile against H.264 and MPEG-2. All the WMV-HD movies were Main Profile encoded too.

"We forget it for obvious reason". Marketing.
I think you guys are nitpicking now. There's nothing in that article that actually says "VC-1 is better than H.264". There are examples given of comparisons in which VC-1 won or did well, but that's all they are - examples. They're not there to demonstrate general superiority, but to simply show VC-1 doesn't suck. :)

Sharktooth

1st November 2007, 14:57

those are examples of VERY OUTDATED comparisons expecially choosen to make ppl think VC-1 is good and maybe better than h.264...
the reality is a bit different though...

Golgot13

1st November 2007, 16:23

those are examples of VERY OUTDATED comparisons expecially choosen to make ppl think VC-1 is good and maybe better than h.264...
the reality is a bit different though...

Hi Sharktooth,

no way with MS, H264 is the best codec MS know it so we will not see any video to make a comparison
and all informations on MS website which talk about H264 are from H264 in 2002-2004.
Because today VC1 can not be compare with H264 (but with MPEG2 it can).

I'm very disappointed by MS (you know it Zambelli) about the true of VC1
and politic with some authoring studio (in europe, I'm not alone...).

Lot of studio use and will use H264 on new HD optical disc format.

I can show the quality result with last developpment of VC1 but it is impossible
the company, when I work, signed a NDA (and Ben don't say me if I can)....

Golgot13

20th November 2007, 00:03

Hi all,

we will never see something from Ben...
Amirm say that VC1 is the best only... :(

@Sharktooth
You said true, MS dodge the challenge because they can make
better than H264 (we waited one month to have a VC1 file from MS
and saw than 1.07 couldn't do better than H264).

I hope to see more HDDVD in H264 like Transformer (which used Toshiba encoder).

zambelli

21st November 2007, 04:09

What exactly are you waiting for, Golgot13? An HD source? Just any HD source? Does it need to be shot on film, or will HD cam do? How long does it need to be?

I'm not sure why this notion that encoder testing can't continue until a video source is provided. It's not like anybody needs Microsoft's permission to continue testing encoder quality.

Golgot13

21st November 2007, 22:27

What exactly are you waiting for, Golgot13?

The truth. You can say simply that H264 codec produce better quality than VC1 codec.
Ben promised video source with "grain" to proove than VC1 have best result than H264,
but I understand that we will never see it...
"Sharktooth" said true "MS dodge", because you can not produce a better quality than H264 encoder.

I tested the version 1.07 of your encoder and you can not compare it today with H264 encoder.
MS said at everybody that there are more HD title because VC1 is best codec but it's because PeP was/is free...

MS can not produce everytime the "must":
- HDi is good better than BDJ (because problem of implementation between of different BD hardware player)
- VC1 codec is not better than H264 (but on PeP there is some good tool like Xscaler).

All industry use H264: Divx buy Mainconcept (for H264); There are HD camcorder on H264;
some APN can record in H264; H264 is support by 3G mobile phone for videoconference;
HD channel broadcast in H264,....
For VC1, except HD disc (which support both H264 codec too) I saw only Tatari and Inlet's Fathom card
(Inlet card can encode in H264 too...).

I 'm really disappointed by MS behavior.

honai

21st November 2007, 22:34

I 'm really disappointed by MS behavior.

Why exactly do you think Microsoft would care what you and a few other posters at doom9.org think about VC-1? The point is that you didn't even pay anything for this, while Microsoft is a business. So why should they feel obliged to prove anything to you as a non-paying non-customer? I don't get it, to be honest.

Razorholt

21st November 2007, 23:07

The point is that you didn't even pay anything for this.

Maybe because they forgot to put a price on it? Bill is loosing his head, I'm telling you.

The Win OS is included within the computer's price, did you know that? And M$ codecs as well as their other freebies are just marketing tools for you to choose their platform - Nothing wrong with that tho.

I'm also not impressed in VC-1, sorry. Can I say that? Please?

45tripp

21st November 2007, 23:10

good edit!

a nice new accessible source will be nice for everyone to play around with,
regardless of codec 'battles'

honai

21st November 2007, 23:28

@Razorholt

Of course you are entitled to your own opinion. But you are not entitled to Microsoft actually caring about your opinion.

That is the difference.

Inventive Software

22nd November 2007, 00:03

Can I just say that I think VC-1 handles interlaced encoding better than MPEG-4 ASP and AVC? I'm attempting to reduce bitrates and make the encodes appear nicer, after recording from my DVD recorder. It records interlaced, and so far, encoding it to VC-1 beats the s**t out of H.264 and MPEG-4 ASP. Except for the time it takes. Tis why I'll leave it going through the night. ;)

Shinigami-Sama

22nd November 2007, 02:22

Dear lord
I just read this whole thread(2 hours!)
and the last hour of its was zamballie defending himself again
granted he walks into it most of the time

but can we get back on topic?
I was rather enjoying this thread

I will ask around my graphics artist buddies for any good hi-def sauces though

Golgot13

22nd November 2007, 12:32

Why exactly do you think Microsoft would care what you and a few other posters at doom9.org think about VC-1? The point is that you didn't even pay anything for this, while Microsoft is a business. So why should they feel obliged to prove anything to you as a non-paying non-customer? I don't get it, to be honest.

It was not true, MS gave the encoder at few authoring studio companies last year
(thanks for no competition, only big studio receive it no standard/small companies...).
We receive it many months after because there is not enough a real market for HDDVD...
About money, when VC1 is used on HD disc for each disc there is some royalties
which is received by owners of the format (like MPEG2, H264, AC3,...).

Beastie Boy

22nd November 2007, 13:13

And your point is what exactly?

You seem to have hijacked this thread just to complain about MS because you feel left out by them.

Golgot13

22nd November 2007, 14:50

And your point is what exactly?

You seem to have hijacked this thread just to complain about MS because you feel left out by them.

No, I want that thread finish and show what codec is the best.
I made many test on movie source (with and without grain) but I can not give file
(H264 and VC1 stream are signed). The company, where I work, signed a NDA with MS for VC1 encoder.
I can only say that H264 win with my all source (I have sometime some problem
with HDDVD player with H264 stream). But I prefer that it proove on this thread
(I waited the source promised by Ben)

honai

22nd November 2007, 15:04

I realize that you feel strongly about this, and that it's kind of a personal crusade for you to prove it. I have the utmost respect for you perseverance. And I'm sorry to say this, but even if you proved that, it would be absolutely meaningless, pretty much like a bag of rice toppling down somewhere in China.

Nobody cares.

Golgot13

22nd November 2007, 16:39

I have the utmost respect for you perseverance.

To my mind, it's my stupid stubbornness

And I'm sorry to say this, but even if you proved that, it would be absolutely meaningless, pretty much like a bag of rice toppling down somewhere in China.

But after some people will know and use it (H264 codec :p)

Nobody cares.

No there is many professionals here (MS made some advertisement
for this forum and AVS Forum about feedback that HDDVD is good).

So at all authoring studio, HDDVD is really the best support (today), HDi is good
level on interactivity (good job of MS) and H264 can give the best HD video result.

honai

22nd November 2007, 16:58

Golgot13

22nd November 2007, 22:14

and doom9.org is not one of them.

Yes but compressionnist can open their eyes with this thread.
Here we are purist because many professional compresionnist who made/make
HDDVD and BD (more on BD disc ?) use the default preset for all movie,
same preset for all movie they only change the bitrate !!!
Except all movie encoded by MS team: really good quality I bought all HDDVD from them

Amdh

24th November 2007, 22:44

So, As Expected, x264 Beats All The Other Formats, That's Perfect .. I'm Using It Since 2 Years And It's Just Excellent, It's True That MPEG2 Is Still Faster And Receives Much More Support From Hardware Producers But x264 Is Still My Choice. Thanks For The Extreamly Intresting Results.

Hey By The Way, I've Not Even Tried VC-1 Coz I Know That The Quality It Gives Won't Compare With H264

Shinigami-Sama

25th November 2007, 00:40

You assume that the industry is headed by CEOs and CTOs who think logical and reasonable. They don't. ;)

The point is that there are many factors in the decision making process which codec to chose for HD discs, and doom9.org is not one of them.

then who ever is making the decisions needs to give their heads a shake. Theres so much data holed up here in doom9 it makes some universities cry
especially with the codec shoot outs