[HD-DVD Challenge] MPEG2, VC-1 and H264 with real uncompressed source movie [Archive] - Page 5

trbarry

22nd September 2006, 18:49

Besides the PSNR & SSIM metrics, one of the simple ways to compare the quality of 2 video clips is just visually compare the frame(s) that are the weakest link in the chain.

For the 6 mbps x264 clip the PSNR log shows the min PSNR occurs at frame 2821 (counting from zero). This would supposedly correspond to the 2822.png original file.

I tried to compare this X264 frame from the 12 mbps X264 clip since that's the only one I've downloaded. But when opening that clip with Vdubmod/directshow source it shows frame 2821 to be a black frame, which from the original png files should not be there. Surrounding frames seem okay.

Can anyone verify this?

If this is not a bug it would be nice if anyone could post png caps of the 6 mbps frame 2821 from the different codecs so we can compare the worst of the worst.

I'm not sure what Zambelli's VC-1 worst frame was because of the mismatch at the end. Though I wonder if that too messed up PSNR somewhat.

- Tom

edit: note any frame mismatch will totally hose PSNR results

trbarry

22nd September 2006, 19:40

Ignore my black frame issue above. It seems to be intermittant and related to Vdub searching (Edit Goto) with dshowsource.

But it still would be nice to be able to compare the various frames numbered 2821 if anybody can post them from the 6 mbps encoded tests to see if there is any visible difference.

- Tom

diogen

22nd September 2006, 20:51

The lowest PSNR frame in VC-1/6Mbps encoding is #3218 and it is 33.66.
There are 9 frames with PSNR below 36 and they are all between frames #3178 and #3218.
The frame #2821 has a PSNR of 37.17. Frames between 2810 and 2130 have PSNR between 36.55 and 38.74.
There are multiple groups of frames (e.g. 3597 to 3654) counting 104 in total that have PSNR of 1.#INF

Diogen.

Sagittaire

24th September 2006, 09:51

Hi Sagittaire and all,
maybe there's room for even more juice if you have some spare CPU:
--ref 3 --subme 7 --trellis 2 (--me "umh" ? "esa" even ?!?)
just some ideas...

I my previous test gain is very little between subme 7 + trellis 2 + me "umh" and subme 6 + trellis 1 + me "hex" (for same PSNR size gain is less than 1% with dramatic speed loss). If pengvado can confirm that ?

well, --filter 0:0 should be also better for PSNR...
however i have my doubts about --no-dct-decimate.

for same quant and setting:
- Best PSNR for 0,0
- Best SSIM for -1,-1
- Best size for -2,-2

-1,-1 seem best choice for metric and eyes

Another thing to consider is that real HD-DVD's contain multiple audio tracks (some of which are relatively high bitrate) and PIP secondary video. On AVSForum, one of the compressionists is claiming that full featured HD-DVD disks have the primary video peak bitrate capped at 19 Mbps. So coding with 29.4 Mbps peak bitrate may not be something that happens in the real world of HD-DVD authoring.

If it's true use MPEG2 for HD-DVD become in practice impossible if you want high quality because max bitrate at 19 Mbps is really to low for 1080p and MPEG2. The quality will be like HDTV MPEG2 source ... horrible.

Moreover use multiple "lossless" audio with secondary video is not an obligation for HD-DVD or BR and certainely very bad idea if you use MPEG2 for video codec.

Manao

24th September 2006, 09:58

however i have my doubts about --no-dct-decimate.Trellis allows you to know "exactly" ( PSNR-wise ) when you ought to decimate, so disabling a-priori dct-decimation can't hurt - and should actually improve PSNR.

akupenguin

25th September 2006, 02:59

I my previous test gain is very little between subme 7 + trellis 2 + me "umh" and subme 6 + trellis 1 + me "hex" (for same PSNR size gain is less than 1% with dramatic speed loss). If pengvado can confirm that ?
For "-m7 -t2 -r3 --me=umh" vs "-m6 -t1 -r2 --me=hex" (with other settings as per Sagittaire's encode (http://forum.doom9.org/showthread.php?p=878427#post878427)), I get 6% lower bitrate per psnr and 2.1x slower encoding.

If you're tweaking for speed, the first option I'd drop is -A=all. p4x4 is close enough to useless at 480p, don't even think of using it at 1080p. It improved bitrate by all of 0.18% at a cost of 7.3% time, which is a far worse tradeoff than "-m7 -t2 -r3 --me=umh".

Dethis

25th September 2006, 08:12

@ akupenguin

do you have any tweaks in mind so that the x.264 encoded file doesn't violate the 29400Kbps limit?
In Sagittaire's 6Mbps_x.264 encode the avg bitrate of the 2972 to 2881 frames is 30.8 Mbps with peaks over 34.0 Mbps

Sagittaire

25th September 2006, 12:12

For "-m7 -t2 -r3 --me=umh" vs "-m6 -t1 -r2 --me=hex" (with other settings as per Sagittaire's encode (http://forum.doom9.org/showthread.php?p=878427#post878427)), I get 6% lower bitrate per psnr and 2.1x slower encoding.

If you're tweaking for speed, the first option I'd drop is -A=all. p4x4 is close enough to useless at 480p, don't even think of using it at 1080p. It improved bitrate by all of 0.18% at a cost of 7.3% time, which is a far worse tradeoff than "-m7 -t2 -r3 --me=umh".

AAArrrrrgggggghhhhhhhh ... 6% for size gain. I will try that. I don't know very well the reference limit for HD-DVD. I will use -r2. Speed is not a problem here: more than 30 hours for each vc1 encoding (esa with h264 is certainely faster).

do you have any tweaks in mind so that the x.264 encoded file doesn't violate the 29400Kbps limit?
In Sagittaire's 6Mbps_x.264 encode the avg bitrate of the 2972 to 2881 frames is 30.8 Mbps with peaks over 34.0 Mbps

Max bitrate is not strict local max bitrate (150 Kbits max for each frame here). You use buffer too and max size can be higher than 150 Kbits for each frame.

891, 3.00, 400619, 42.55, 50.19, 45.93, 43.67 I
892, 5.00, 66317, 41.64, 50.41, 46.43, 42.92 B
893, 5.00, 68902, 41.35, 50.09, 46.08, 42.63 B
894, 2.00, 327465, 43.63, 50.33, 46.33, 44.64 P
895, 4.00, 86100, 41.84, 50.32, 46.05, 43.07 B
896, 4.00, 87712, 41.81, 50.27, 46.05, 43.04 B
897, 3.00, 259266, 43.07, 49.89, 45.88, 44.10 P
898, 4.00, 86277, 41.86, 50.00, 45.84, 43.06 B
899, 4.00, 85971, 41.56, 49.81, 45.61, 42.77 B
900, 3.00, 226414, 42.63, 49.51, 45.45, 43.67 P
901, 4.00, 80828, 41.62, 49.52, 45.31, 42.78 B
902, 4.00, 80060, 41.32, 49.37, 45.04, 42.49 B
903, 3.00, 149087, 42.44, 49.50, 45.36, 43.50 P
904, 4.00, 71735, 41.68, 49.44, 45.18, 42.82 B
905, 5.00, 340193, 39.38, 48.41, 43.41, 40.61 I

This MPEG2 stream is perfectly complaint with vbv (29.4 Mbps and 9781 Kbit for buffer) but size for Iframe can be higher than 400 Kbits or if you make local bitrate convertion higher than 80 Mbps.

akupenguin

25th September 2006, 16:19

I don't know very well the reference limit for HD-DVD. I will use -r2.
If it's level 4.1, then the limit is -r3. (Theoretically 4 refs in P-frames and 3 in B-frames, but x264 uses the same number for both, so 3 is the max.)

drmpeg

26th September 2006, 09:43

I will add 5.1 audio at 448 Kbps (FAAC) in next update.

I've determined that the uncompressed audio files (at least the stereo ones) sync to 24 fps, not 23.976 fps.

Ron

Sagittaire

26th September 2006, 22:49

I've determined that the uncompressed audio files (at least the stereo ones) sync to 24 fps, not 23.976 fps.

Ron

I see that ... I see that ... thx

Update

26.09.2006 - MPEG2 and H264 files with audio are available
19.09.2006 - MPEG2 metric result
18.09.2006 - H264 metric result

H264 files (x264) with AAC 5.1 (FAAC) at 448 Kbps
MPEG2 files (libavocodec) with ac3 5.1 at 448 Kbps

NB : 24 Mbps MPEG2 file is not strictly vbv compliant (but not far I think) because RC for this quality level is really difficult with Mencoder.
NB : H264 files are not updated files with insame quality setting

For "-m7 -t2 -r3 --me=umh" vs "-m6 -t1 -r2 --me=hex" (with other settings as per Sagittaire's encode), I get 6% lower bitrate per psnr and 2.1x slower encoding.

Like always akupenguin (and skal) show the light. At maximum quality x264 improvement done 0.25 dB ...

D:\Mes dossiers\Codec\x264>x264.exe --keyint 15 --min-keyint 1 --vbv-maxrate 29
00 --vbv-bufsize 9500 --qpmin 15 --level 4.1 --bframe 2 --b-rdo --bime --weight
--ref 3 --mixed-refs --direct auto --filter -1:-1 --bitrate 6000 --pass 3 --st
ts "H264_6Mbps.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.33 --analyse "all"
-8x8dct --me "umh" --subme 7 --no-fast-pskip --no-dct-decimate --trellis 2 --pr
gress -o H264_6Mbps.mp4 azerty.avs
avis [info]: 1920x1080 @ 25.00 fps (15691 frames)
x264 [warning]: width or height not divisible by 16 (1920x1080), compression wi
l suffer.
x264 [info]: using cpu capabilities MMX MMXEXT SSE 3DNow!
mp4 [info]: initial delay 1 (scale 25)
x264 [info]: slice I:1131 Avg QP:21.23 size:101765 PSNR Mean Y:48.68 U:58.62
V:57.22 Avg:49.62 Global:47.37
x264 [info]: slice P:6870 Avg QP:21.70 size: 37554 PSNR Mean Y:47.98 U:57.52
V:56.23 Avg:48.97 Global:46.68
x264 [info]: slice B:7690 Avg QP:23.36 size: 12691 PSNR Mean Y:47.49 U:60.02
V:58.22 Avg:48.59 Global:45.95
x264 [info]: mb I I16..4: 39.0% 42.3% 18.7%
x264 [info]: mb P I16..4: 11.0% 11.3% 2.0% P16..4: 29.6% 7.6% 3.3% 0.4%
.2% skip:34.6%
x264 [info]: mb B I16..4: 0.6% 1.2% 0.3% B16..8: 10.5% 1.3% 2.4% direct
2.2% skip:81.5%
x264 [info]: 8x8 transform intra:45.4% inter:57.7%
x264 [info]: direct mvs spatial:75.9% temporal:24.1%
x264 [info]: ref P 79.1% 14.4% 6.5%
x264 [info]: ref B 76.8% 14.8% 8.4%
x264 [info]: SSIM Mean Y:0.9881195
x264 [info]: PSNR Mean Y:47.792 U:58.826 V:57.280 Avg:48.829 Global:46.346 kb/s
5999.51

encoded 15691 frames, 0.65 fps, 6000.57 kb/s

Dethis

27th September 2006, 10:29

....

This MPEG2 stream is perfectly complaint with vbv (29.4 Mbps and 9781 Kbit for buffer) but size for Iframe can be higher than 400 Kbits or if you make local bitrate convertion higher than 80 Mbps.

Sorry, I don't get it.:(

400,619 bits / 1024 = 391 (Kbits per frame) * 25 fps = 9,781 Kbps local bitrate (9781 !!!! hmmm .. equal to the buffer's size).

I aggree it's perfectly HD-DVD compliant (<29,400Kbps)

Sagittaire

27th September 2006, 11:14

Sorry, I don't get it.:(

400,619 bits / 1024 = 391 (Kbits per frame) * 25 fps = 9,781 Kbps local bitrate (!!!! 9781 !!! equal to the buffer's size).

I aggree it's perfectly HD-DVD compliant (<29,400Kbps)

Sorry unit is bytes and not bits

400 Kbytes = 400 * 8 = 3 200 Kbits
3 200 *25 = 80 Mbps

in fact you don't understand how work vbv ... :readfaq:

Max bitrate work with buffer and if local bitrate is superior to max bitrate then the buffer is emptied. Local bitrate can be superior to the max bitrate if the buffer is not empty and can't if the buffer is empty ...

For HD-DVD max local bitrate can be 60 Mbps for 0.320 sec, For DVD max local bitrate can be 12 Mbps for 0.920 sec ... ect ect

Dethis

27th September 2006, 15:51

Sorry unit is bytes and not bits.....

400 Kbytes = 400 * 8 = 3 200 Kbits
3 200 *25 = 80 Mbps

in fact you don't understand how work vbv ... :readfaq:

Max bitrate work with buffer and if local bitrate is superior to max bitrate then the buffer is emptied. Local bitrate can be superior to the max bitrate if the buffer is not empty and can't if the buffer is empty ...

For HD-DVD max local bitrate can be 60 Mbps for 0.320 sec, For DVD max local bitrate can be 12 Mbps for 0.920 sec ... ect ect

I am really sorry . :( I should have imagined the typo (bits->bytes).

Anyway thanks for the info Sagittaire.:thanks:

And :thanks: :thanks: :thanks: for your efforts to objectively valuate all codecs.

drmpeg

28th September 2006, 10:51

NB : 24 Mbps MPEG2 file is not strictly vbv compliant (but not far I think) because RC for this quality level is really difficult with Mencoder.

The 24 Mbps MPEG-2 file is not VBV compliant by a very large amount. It looks to me like there is a bug in the rate control for 24 Mbps Average, 29.4 Mbps Peak. When it gets low in the VBV, it codes a gigantic frame and totally violates the VBV.

http://img153.imageshack.us/img153/1893/lib24vbvdk9.th.jpg (http://img153.imageshack.us/my.php?image=lib24vbvdk9.jpg)

The 12 Mbps encode is okay.

http://img153.imageshack.us/img153/5154/lib12vbvhm2.th.jpg (http://img153.imageshack.us/my.php?image=lib12vbvhm2.jpg)

Ron

zambelli

29th September 2006, 01:41

Hi Sagittaire,

I just exchanged some emails with our resident HD-DVD guru (sspears from AVSForum, in case you read that forum) and he pointed out that your VBV size is incorrect.

According to the HD-DVD specs, these are the allowed VBV buffer sizes:

1843200 bytes for Main Video HD
937984 bytes for Main Video SD
929792 bytes for Sub Video HD
242688 bytes for Sub Video SD

So it looks like the buffer size is more like 500 msec, not 320 msec.

MuTeK

29th September 2006, 11:49

Elecard H264 Encoder.
2passVBR 6mbps, HssRate = 29.4mbps, CpbSize = 9.78 Mbit

Quality: OPSNR = 46.17, SSIM = 89.44

And VBV buffer:
http://img220.imageshack.us/img220/3451/elecardavc6mbps2passot5.th.gif (http://img220.imageshack.us/my.php?image=elecardavc6mbps2passot5.gif)

bond

29th September 2006, 17:08

Manao

29th September 2006, 17:41

MuteK : how come your VBV isn't always empty, excepted on complicated scenes ?

zambelli

30th September 2006, 01:30

12Mbps VC-1 encoding done. WME9 wmcmd.vbs was used, as before, with the latest v11 WMV encoder DMO.

Command line:
-input ED_1920x1080.avi -output Elephant_1080p25_12Mbps_B2_P80_Loop1_MM2_MSL4_MSR0.wmv -videoonly -v_codec WVC1 -v_mode 4 -v_bitrate 12000000
-v_peakbitrate 29400000 -v_peakbuffer 320 -v_keydist 0.6 -v_framerate 25 -v_performance 80 -v_bframedist 2 -v_loopfilter 1 -v_mmatch 2 -v_mslevel 4 -v_msrange 0

Average Bitrate: 12177994 bps
Filesize: 957,624,858 bytes
Overall PSNR: 47.6286
Minimum PSNR: 33.7551 (this time I made sure the last frame was trimmed)
Average SSIM: 92.03065060

Sagittaire

1st October 2006, 21:13

akupenguin wrote this:
http://forum.doom9.org/showthread.php?p=730001#post730001

--analyse "all" is compliant with level 4.1 ... yes or not?

I just exchanged some emails with our resident HD-DVD guru (sspears from AVSForum, in case you read that forum) and he pointed out that your VBV size is incorrect.

According to the HD-DVD specs, these are the allowed VBV buffer sizes:

1843200 bytes for Main Video HD
937984 bytes for Main Video SD
929792 bytes for Sub Video HD
242688 bytes for Sub Video SD

So it looks like the buffer size is more like 500 msec, not 320 msec.

yes drmpeg say that. Anyway I use the same vbv setting for all codec. If 14 745 Kbits is compliant then 9781 too.

The 24 Mbps MPEG-2 file is not VBV compliant by a very large amount. It looks to me like there is a bug in the rate control for 24 Mbps Average, 29.4 Mbps Peak. When it gets low in the VBV, it codes a gigantic frame and totally violates the VBV.

Argh ... I will try to obtain better result with libavcodec.

akupenguin

1st October 2006, 21:28

akupenguin write this:
http://forum.doom9.org/showthread.php?p=730001#post730001

--analyse "all" is compliant with level 4.1 ... yes or not?
Yes as of r573. Not when I wrote that.

Sergey A. Sablin

2nd October 2006, 07:07

MuteK : how come your VBV isn't always empty, excepted on complicated scenes ?

why should it be?

zambelli

2nd October 2006, 07:57

yes drmpeg say that. Anyway I use the same vbv setting for all codec. If 14 745 Kbits is compliant then 9781 too.
Well, sure, but then we're doing a disservice to all the codecs here. If the spec allows for a bigger buffer, why not use it?

As a general note, I think a lot of readers of this thread are confused about what the thread is trying to accomplish. The title makes it sound like we're trying to produce HD-DVD/BluRay compliant video bitstreams, but we've already somewhat strayed away from those guidelines. Is the point to produce the best encoding? Or find the best codec? Or find the best encoder software?

Manao

2nd October 2006, 08:04

Sergey A. Sablin

2nd October 2006, 08:20

Because you did an encoding in VBR @ 6 mbps, while the VBV buffer was configured at 29.4 mbps. Since you never saturate your VBV, you have "average bitrate = (VBV bitrate * duration + VBV end - VBV begin ) / duration". Hence, you have average bitrate = 29.4 mbps. So there's a problem, becaue obviously the average bitrate wasn't 29.4 mbps.

strange formulae to compute avc buffer level... I thought you know something about HRD - it is a bit different from mpeg-2 VBV model (and VC-1 too as it nearly same as mpeg-2).
hint: in avc buffer never saturated at the top, and because of high scale-down of a picture you just dont see how it stays without filling in the middle.

foxyshadis

2nd October 2006, 09:40

akupenguin

2nd October 2006, 10:10

strange formulae to compute avc buffer level... I thought you know something about HRD - it is a bit different from mpeg-2 VBV model (and VC-1 too as it nearly same as mpeg-2).
hint: in avc buffer never saturated at the top, and because of high scale-down of a picture you just dont see how it stays without filling in the middle.
VBV is the same, no matter what codec you're using.
That said, there are multiple ways to consider it.
The standard way is: send bits at the maximum rate allowed, except when the buffer is full. This is the most useful model for the encoder to think of, and the easiest to write. If this method were used, then Manao's comment holds.
It is also possible to think of VBV as: send bits at whatever speed you feel like, as long as they arrive some time before the decoder needs them. This method may be more useful for a real muxer, but is not appropriate for examining how much of the VBV was needed. It's also not appropriate for any sort of comparison, since there is no one unique graph that can be generated from a given bitstream.

Sagittaire

2nd October 2006, 10:18

Well, sure, but then we're doing a disservice to all the codecs here. If the spec allows for a bigger buffer, why not use it?

As a general note, I think a lot of readers of this thread are confused about what the thread is trying to accomplish. The title makes it sound like we're trying to produce HD-DVD/BluRay compliant video bitstreams, but we've already somewhat strayed away from those guidelines. Is the point to produce the best encoding? Or find the best codec? Or find the best encoder software?

1) I think that for VC-1 and H264 9781 Kbits is enought for 6 Mbps and 12 Mbps encoding (no VBV saturation or really limited vbv saturation). I think that 14400 Kbits could be usefull only for 24 Mbps encoding because the average bitrate is really close to the max bitrate. I fact I think that better buffer will be always really usefull only for MPEG2 in this challenge.

2) Well I know the buffer for VC-1 but not exactly for MPEG2 and H264. I choose these vbv values (9781 Kbits for buffer and 29.4 Mbps for max bitrate) simply because I know that these value are compliant for HD-DVD and BD and for all the codec.

Somebody know the buffer which should be used ?
- For MPEG2, VC-1 and H264
- For HD-DVD and BD

Is the point to produce the best encoding? Or find the best codec? Or find the best encoder software?

1) Try to find the best choice for low, meduim and high bitrate.
2) Try to find codec ranking with best possible encoder software for each standard.

If H264 Elecard encoder produce the best result I will choose Elecard for AVC encoder.

Sergey A. Sablin

2nd October 2006, 10:26

VBV is the same, no matter what codec you're using.
That said, there are multiple ways to consider it.
The standard way is: send bits at the maximum rate allowed, except when the buffer is full. This is the most useful model for the encoder to think of, and the easiest to write. If this method were used, then Manao's comment holds.
It is also possible to think of VBV as: send bits at whatever speed you feel like, as long as they arrive some time before the decoder needs them. This method may be more useful for a real muxer, but is not appropriate for examining how much of the VBV was needed.

there also exist an

Annex C
Hypothetical reference decoder
(This annex forms an integral part of this Recommendation | International Standard)

and I think there is no need to discuss of a most useful or more easiest way how one wants to calculate it. Elecard Buffer analyzer works in a really standard way.

drmpeg

2nd October 2006, 11:28

Somebody know the buffer which should be used ?
- For MPEG2, VC-1 and H264
- For HD-DVD and BD

BD numbers are:

MPEG-2 MP@HL = 9,781,248 bits (1,222,656 bytes) (maximum of MP@HL)
MPEG-2 MP@ML = 1,835,008 bits (229,376 bytes) (maximum of MP@ML)

H.264 MP or HP Level 4 or 4.1 = 30,000,000 bits (3,750,000 bytes)
H.264 MP or HP Level 3.2 = 24,000,000 bits (3,000,000 bytes)
H.264 MP or HP Level 3.1 = 16,800,000 bits (2,100,000 bytes)
H.264 MP or HP Level 3 = 12,000,000 bits (1,500,000 bytes)

VC-1 AP@L3 = 30,000,000 bits (3,750,000 bytes)
VC-1 AP@L2 = 30,000,000 bits (3,750,000 bytes)

Ron

Sergey A. Sablin

2nd October 2006, 11:30

BD numbers are:
H.264 MP or HP Level 4 or 4.1 = 30,000,000 bits (3,750,000 bytes)
H.264 MP or HP Level 3.2 = 24,000,000 bits (3,000,000 bytes)
H.264 MP or HP Level 3.1 = 16,800,000 bits (2,100,000 bytes)
H.264 MP or HP Level 3 = 12,000,000 bits (1,500,000 bytes)
Ron

coud you tell me pls where did you get these numbers from?

Sergey A. Sablin

2nd October 2006, 12:19

It's also not appropriate for any sort of comparison, since there is no one unique graph that can be generated from a given bitstream.

which comparison you are talking about here? the only one I can see is compliance to given restrictions (buffer state), i.e. there is no underflow for VBR case and no overflow/underflow in CBR case.
So why one need unique graph for any compression standard?

drmpeg

2nd October 2006, 12:53

which comparison you are talking about here? the only one I can see is compliance to given restrictions (buffer state), i.e. there is no underflow for VBR case and no overflow/underflow in CBR case.
So why one need unique graph for any compression standard?
The leak rate on a muxer can be higher than the bitrate indicated in the video elementary stream. However, it can be graphed. It's just done differently. You examine the level of the elementary stream buffer at every byte of the multiplex. Then at the DTS, all the picture bits are removed from the buffer (for that picture).

Ron

Sergey A. Sablin

2nd October 2006, 13:28

The leak rate on a muxer can be higher than the bitrate indicated in the video elementary stream. However, it can be graphed. It's just done differently. You examine the level of the elementary stream buffer at every byte of the multiplex. Then at the DTS, all the picture bits are removed from the buffer (for that picture).

Ron

Ron,

you are right, but I still do not see what one want to compare here. The goal is to check encoder ouput, whether it is compliant with spec or not. And the matter is to check this by standard way - ie how it is defined in spec, right? So what we are talking about then?

drmpeg

2nd October 2006, 13:46

Ron,

you are right, but I still do not see what one want to compare here. The goal is to check encoder ouput, whether it is compliant with spec or not. And the matter is to check this by standard way - ie how it is defined in spec, right? So what we are talking about then?

I believe what akupenguin was getting at is that the rules for VBV are fixed, and the results are always the same for a bitstream. But in a mux, the leak rate can be different, so the results will be different depending on that leak rate.

However, both HD-DVD and BD use a multiplex, so you have to be both VBV and T-STD compliant.

Ron

Sergey A. Sablin

3rd October 2006, 10:12

I believe what akupenguin was getting at is that the rules for VBV are fixed, and the results are always the same for a bitstream. But in a mux, the leak rate can be different, so the results will be different depending on that leak rate.

However, both HD-DVD and BD use a multiplex, so you have to be both VBV and T-STD compliant.

Ron

I hope we agreed that at least elementary stream have to be compliant with spec. (and then if it need to be muxed T-STD compliant of course)

So we've downloaded two x264 clips: 6 and 12 mbps and checked both for AVC HRD model with next parameters:
buffer size: 9.5 mbit,
hss rate: 29.4 mbps,
init delay: 0.291 sec (which is 90% of buffer size))

Here is two pictures of buffer state:

6 mbps (ok):
http://img220.imageshack.us/img220/7382/x2646mbps2passvbvdy0.th.gif (http://img220.imageshack.us/my.php?image=x2646mbps2passvbvdy0.gif)

12 mbps (failed):
http://img215.imageshack.us/img215/9292/x26412mbps2passvbvxv1.th.gif (http://img215.imageshack.us/my.php?image=x26412mbps2passvbvxv1.gif)

To be compliant 12 mbps stream must have nearly 50 mbps hss rate with given buffer size. Though it is allowed by level 4.1, but not by rules of this comparison.

I think there is no need to download 24 mbps and verify it...

I also have some doubts about VC-1 compliance too, but didn't have a chance to verify it yet.

Sergey.

Sagittaire

3rd October 2006, 10:44

I hope we agreed that at least elementary stream have to be compliant with spec. (and then if it need to be muxed T-STD compliant of course)

So we've downloaded two x264 clips: 6 and 12 mbps and checked both for AVC HRD model with next parameters:
buffer size: 9.5 mbit,
hss rate: 29.4 mbps,
init delay: 0.291 sec (which is 90% of buffer size))

Here is two pictures of buffer state:

6 mbps (ok):
http://img220.imageshack.us/img220/7382/x2646mbps2passvbvdy0.th.gif (http://img220.imageshack.us/my.php?image=x2646mbps2passvbvdy0.gif)

12 mbps (failed):
http://img215.imageshack.us/img215/9292/x26412mbps2passvbvxv1.th.gif (http://img215.imageshack.us/my.php?image=x26412mbps2passvbvxv1.gif)

To be compliant 12 mbps stream must have nearly 50 mbps hss rate with given buffer size. Though it is allowed by level 4.1, but not by rules of this comparison.

I think there is no need to download 24 mbps and verify it...

I also have some doubts about VC-1 compliance too, but didn't have a chance to verify it yet.

Sergey.

Arrrrrggggghhhhh .... but really interessing ... lol

1) What did you use for check vbv compliancy?
2) I have an "old" AVC elecard encoder (CLI, encoder.exe, 26.01.2006). I can use it for this challenge?
3) You know the official vbv/cpb buffer for H264 and HDDVD?

Sergey A. Sablin

3rd October 2006, 11:15

Arrrrrggggghhhhh .... but really interessing ... lol

1) What did you use for check vbv compliancy?
2) I have an "old" AVC elecard encoder (CLI, encoder.exe, 26.01.2006). I can use it for this challenge?
3) You know the official vbv/cpb buffer for H264 and HDDVD?

1) Elecard Buffer Analyzer - http://www.elecard.com/products/products-pc/consumer/streameye-tools/
2) We may provide you latest one, but buffer restrictions you are using are really strict - I'm afraid no one encoder will do good work here.
3) yes, but as it is still confidential information I can't publish it here.

Sagittaire

3rd October 2006, 11:57

Q. You know the official vbv/cpb buffer for H264 and HDDVD?
R. yes, but as it is still confidential information I can't publish it here.

Buffer is confidential information ... ???

buffer restrictions you are using are really strict

It's a good information. I will use the same that VC1 for H264.

Sagittaire

3rd October 2006, 12:01

Sergey A. Sablin

3rd October 2006, 12:35

Annexe - Update

03.10.2006 - buffer for H264 is confidential but use 14400 Kbits is certainely compliant with HDDVD
02.10.2006 - official buffer for VC1 is 14400 Kbits or 480 ms for better HD-DVD compliancy
26.09.2006 - MPEG2 and H264 files with audio are available
19.09.2006 - MPEG2 metric result
18.09.2006 - H264 metric result

you could try to use BluRay buffer restrictions provided by Ron instead of "unknown" HD-DVD.
the other question is - how you want to proceed with x264? even with 30 mbit buffer 12mbps stream still underflowed by 38.5 mbit...

Sergey.

Sagittaire

3rd October 2006, 12:40

you could try to use BluRay buffer restrictions provided by Ron instead of "unknown" HD-DVD.

30000 Kbits is HD-DVD compliant ... ???

the other question is - how you want to proceed with x264? even with 30 mbit buffer 12mbps stream still underflowed by 38.5 mbit...

I will use your AVC encoder ... ;-)

We may provide you latest one

zambelli

4th October 2006, 10:25

Annexe - Update
26.09.2006 - MPEG2 and H264 files with audio are available
19.09.2006 - MPEG2 metric result
18.09.2006 - H264 metric result
I think you missed my 12Mbps VC-1 result - http://forum.doom9.org/showpost.php?p=881472&postcount=220 - and I also uploaded the 6Mbps VC-1 encoding to you recently.

Sagittaire

4th October 2006, 13:59

I think you missed my 12Mbps VC-1 result - http://forum.doom9.org/showpost.php?p=881472&postcount=220 - and I also uploaded the 6Mbps VC-1 encoding to you recently.

I wait benwagonner encoding for choose the best possible way for VC1 (from MS).

Moreover the buffer for the challenge became 14400 Kbits (480 ms or 12 frames at 25 fps) for better VC1 HDDVD compliance ...

The official H264 buffer seem really higher than official VC-1 buffer but I will choose certainely the same buffer for better direct comparison between VC-1 and H264.

Anyway I can't understand why each codec have different buffer restriction.

benwaggoner

4th October 2006, 21:44

I wait benwagonner encoding for choose the best possible way for VC1 (from MS).
Best possible? You've got a long wait :). That's like waiting for the x264 guys to finish their codec and stop with all the crazy updating.

I'll get you some samples when I can, but go ahead and use Zambelli's encodes for the time being.

Dethis

11th October 2006, 14:30

@ Sagittaire, Zambelli, Dr1394, Mutec

Would you be kind enough to upload logs of your Elephand Dream's encodings (6-12-24 Mbps).
i.e. frame Number - frame type (I,P,B) - dec. time, frame size (bytes).

Not just to calm down my curiosity about their vbv behavior but also to help me model & evaluate my simplistic vbv-checking spreadsheet.

Thanks in advance.

zambelli

11th October 2006, 19:47

@ Sagittaire, Zambelli, Dr1394, Mutec
Would you be kind enough to upload logs of your Elephand Dream's encodings (6-12-24 Mbps).
i.e. frame Number - frame type (I,P,B) - dec. time, frame size (bytes).
Not just to calm down my curiosity about their vbv behavior but also to help me model & evaluate my simplistic vbv-checking spreadsheet.
I think I'll re-encode the 6 and 12 Mbps VC-1 videos, now that the buffer size has been raised for VC-1. I'll post the PSNR logs and frame logs when they're done.

Sagittaire

12th October 2006, 18:40

I think I'll re-encode the 6 and 12 Mbps VC-1 videos, now that the buffer size has been raised for VC-1. I'll post the PSNR logs and frame logs when they're done.

Wait a little time please. I will make new rules for real world HDDVD encoding certainely more like that...

MPEG2 Encoding
Profil & Level: MP@HL except specific restrictions
Max GOP lenght: 15 frames
Maximum bitrate: 20.0 Mbps or 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 15, max adaptative bframe at 2

VC-1 Encoding
Profil & Level: AP@L3 except specific restrictions
Max GOP lenght: 15 frames
Maximum bitrate: 20.0 Mbps or 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 15, max adaptative bframe at 2

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

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 +/- 1 % for bitrate tolerance
HD-DVD with "medium bitrate" video stream and standard HDDVD authoring:
12 Mbps (Max at 20.0 Mbps) for video stream with +/- 1 % 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 +/- 1 % for bitrate tolerance

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

Multiplexing for all the stream must be at 30.24 Mbps and in reality the max bitrate for video will never at 29.8 Mbps. Standard HDDVD authoring use actually secondary video stream (certainely in SD) and/or Multiple HD audio stream. For this reason all the actual HDDVD movie use max bitrate at ~ 20 Mbps for the principal video stream.