x264 Known Hardware accelleration problems and solutions [Archive]

tetsuo55

20th December 2007, 16:21

Below you will find the settings to create a file that will work on any hardware decoder.
Current problems will be explained and finally i will explain how you can try to convince an older file to work.

What settings to use to create a universally(L4.1) working fileNOTE1:
Follow these 3 steps

STEP 1: Determine the REF frame in DPB limit:

8388608 / (Height X Width) = nREF

The value can never be higher than 16 so round it down if its higherNOTE2

STEP 2: Decide if you want to use B-pyramidsNOTE3:

If B-Pyramids = YES then nREF -1
If B-Pyramids = NO then add "--no-b-pyramid"

STEP 3: Make sure use these commands and never cross the limits, shown here are the highest settings(not marked) or mandatory settings(marked with *):

--VBVMaxBitrate 40000 (highest possible value)
--KeyframeInterval 24*
level-idc = 4.1*
Profile = High*

NOTE1
If a file created with these settings does not work on your hardware it is either not capable of L4.1 decoding or there is something wrong with the universal settings.
Handheld devices do not support L4.1 i have created an alternative setting below.
NOTE2
Currently there is a bug with DXVA(videocards) on several of the decoders, a REF value higher than 11 will not work on all systems or with all players. (if you want to help fix the bug or want more information see the thread here http://forum.doom9.org/showthread.php?p=1170371)
NOTE3
B-pyramids are "broken" in x264, this is why you need to reduce ref frames by 1 to guarantee that it works, and even then it might not be stable at all. if you want to know more and/or help fix it see this thread: http://forum.doom9.org/showthread.php?t=140223

Not all hardware devices support L4.1, these devices need L3.0 settings(A lot of portable devices use even lower settings, please check the manual and use the correct MEgui profile):
Follow these 2 steps

STEP 1: Determine the REF frame in DPB limit:

2073600 / (Height X Width) = nREF

The value can never be higher than 16 so round it down if its higherNOTE2

STEP 2: Make sure use these commands and never cross the limits, shown here are the highest/lowest settings(not marked) or mandatory settings(marked with *):

--vbv-bufsize 10000 (highest possible value)
--vbv-maxrate 12500 (highest possible value)
--KeyframeInterval 24*
level-idc = 3.0*
Profile = High*
--no-b-pyramid*

B-pyramids does not work on most portable devices, so its best to disable it completely.

---

If the file is already encoded but you cannot get it to work you can try the following:

If you have a file that was already encoded, but it doesn't work there are 4 options:
1.Try the file in MPC-HC if it supports you videocard
2.Use h264info to change the header to level3.1 or level4.1 and try your regular player
3.Use a software decoder like coreavc
4.Transcode the file to be Hardware level compliant.

Non-working files usually means that it was encoded with an old version of x264, has too many ref-frames for its resolution/level or was muxed with an old version of mkvmerge.

(The previous post i had here has been archived here: http://forum.doom9.org/showthread.php?p=1170369#post1170369)

EDIT:1 (Added min-keyint 4 to the required settings thanks to the findings in this thread: http://forum.doom9.org/showthread.php?t=140135 )
EDIT:2 (min-keyint 4 removed, x264 already respects these limits by default)
EDIT:3 (Corrected fullhd formula(the incorrectness of the old formula did not effect ref frame caluclation))

Atak_Snajpera

20th December 2007, 18:09

- slower encoding
+ very small improvements in quality

Maybe people creating the frontends for encoding could do the same so files become more hardware-compliant?

I will make necessary changes in my GUI. Thanks for info :)

Dark Shikari

20th December 2007, 21:40

Note the improvement in quality is much greater on anime/cartoon footage, where you can get a 1% increase in quality per bitrate per reference frame even at high numbers.

Atak_Snajpera

20th December 2007, 21:55

What's the point of encoding cartoons with 16ref and not be able to watch them on PS3/X360 or PC with hardware acceleration? In this case I choose compatibility over small increase in quality.

akupenguin

20th December 2007, 21:58

Is it number of reference frames, or is it DPB size (i.e. a Level restriction like every other limited HW decoder under the sun)?

arfster

20th December 2007, 22:01

Is it number of reference frames, or is it DPB size (i.e. a Level restriction like every other limited HW decoder under the sun)?

Copy/pasted this from somewhere that did tests to nail down the cyberlink decoder+dxva limitations:

"1080p - Number of Reference frames must be equal to or less than 4
720p - Number of Reference frames must be be equal to or less than 8
Mixed Reference Frames must be false.
B Frames must equal 2
Adaptive B frames must be false"

Apparently not meeting any of the above causes the 720p 20fps bug, or the 1080p black screen.

Dark Shikari

20th December 2007, 22:04

Copy/pasted this from somewhere that did tests to nail down the cyberlink decoder+dxva limitations:

"1080p - Number of Reference frames must be equal to or less than 4
720p - Number of Reference frames must be be equal to or less than 8
Mixed Reference Frames must be false.
B Frames must equal 2
Adaptive B frames must be false"

Apparently not meeting any of the above causes the 720p 20fps bug, or the 1080p black screen.That's a very heavy set of restrictions... :eek:

akupenguin

20th December 2007, 22:09

That's strange. If you go by memory used, 4 frames of 1080p is equivalent to 9 frames of 720p, not 8.

If Level 4.1 were the only restriction, I might recommend people to restrict refs for hardware compatibility. But non-adaptive B-frames and no mixed refs? that's too harsh. Plus it's just plain a decoder bug, not a legitimate limitation. (As a codec developer, I can confidently say that adaptive B-frames do not require any explicit support. You just implement the standard, and any sequence of frame types is decodable.)

I question the DPB limit too... 1080p 16ref takes 50MB of RAM. Any video card recent enough to decode HD h264 will come with at least 256MB. Unless the decoder's memory is separate from the video memory? in which case it seems wasteful to dedicate 5% (12MB) to only h264 decoding when it could be reused.

Sulik

20th December 2007, 22:15

arfster

21st December 2007, 03:18

To make clear: I've no idea if the above list is right, it was just something I copied off a forum somewhere for my own reference for future encodes. Haven't actually tested it at all.

If anyone needs to do some tests, feel free to point to some samples and I'll play them with my 2600.

NanoBot

21st December 2007, 07:54

Hi,

at least with my 8600gts I found another restriction: I have to uncheck "b-pyramids" during the encode to achieve a playback with full GPU decoding.

C.U. NanoBot

tetsuo55

21st December 2007, 15:31

Well i would be willing to test encodes.

Maybe if we had a few test files, that where encoded in the same format as hddvd/bluray, so they can be easily tested in all hardware compliant software players i could try them and see which ones break on which players.

This way we could find out where the bug really lies and file a good bug-report to the responsible party.

As the issues effect both ATI and NVIDIA i think its safe to say that its not the hardware

UsedUser

22nd December 2007, 03:21

The real restriction is the HD/BD profile & level restriction, ie: high profile, level 4.1.
For the number of references, this means that the maximum is 12288KB/(W*H*1.5):
1920x1080 -> max num_ref_frames = 4
1280x720 -> max num_ref_frames = 9
720x480 -> max num_ref_frames = 16 (max)
I would agree, from my experience troubleshooting, that the profile/level compliance is the issue for DXVA.

The mixed_ref/adaptive B-frames restriction is not a HW restriction, but more likely a bug in the Cyberlink decoder (or demux<->decoder interaction problem, or possibly though unlikely, encoder compliance issue).
I would also agree that the mixed ref / adaptive b-frames issue is with the decoder, and is the source of the 20fps bug, as DXVA will work with the proper number of ref frames, but the 20fps bug persists with adaptive b-frames. I haven't tested mixed ref without adaptive b-frames to isolate it further, but the bug persists when using adaptive b-frames without mixed ref. So at a minimum, adaptive b-frames alone can cause the 20fps bug.

valnar

22nd December 2007, 05:22

As somebody who wants to use DXVA and hardware players (like the Sage HD Extender), keeping to these "standards" is important. Not every playing device has 256MB of RAM.

Since most people use front ends, as tetsuo55 pointed out, it would be great if they could give a warning or perhaps change the default recommendations.

-Robert

tetsuo55

22nd December 2007, 18:20

Well maybe the following tests will help:

-Play a b-frame encoded file with a different decoder (mainconcept and or nero)

-Encode a b-frame file with mainconcept, then try that file on cyberlink, mainconcept and nero.

arfster

22nd December 2007, 18:34

Well maybe the following tests will help:

-Play a b-frame encoded file with a different decoder (mainconcept and or nero)

Afaik neither of those supports VLD acceleration, which is when the problem pops up :-(

Arcsoft seems to support it, but I couldn't get the h264 decoder to work outside the player itself, and the player only plays certain types of video.

tetsuo55

22nd December 2007, 19:58

Afaik neither of those supports VLD acceleration, which is when the problem pops up :-(

Arcsoft seems to support it, but I couldn't get the h264 decoder to work outside the player itself, and the player only plays certain types of video.

Again stressing my point that the file needs to be in a stand-alone player type container, so mkv is obviously out of the question

Crisidelm

24th December 2007, 15:43

Afaik neither of those supports VLD acceleration, which is when the problem pops up :-(

Arcsoft seems to support it, but I couldn't get the h264 decoder to work outside the player itself, and the player only plays certain types of video.

Within Dvb software Dvbviewer the Arcsoft H.264 works fine, and Dvbviewer can be used to play other files, no only for live DVB viewing...

valnar

29th December 2007, 22:38

Is there a megui profile that is recommended to not only give the best quality, but have the highest compatibility for DXVA or hardware players like the Sage HD Extender?

What would those options be for HD or DVD rips?

Robert

Atak_Snajpera

29th December 2007, 22:42

PS3 profile

valnar

29th December 2007, 23:02

PS3 profile

Easy enough! Thanks.
Robert

UsedUser

1st January 2008, 11:02

PS3 profile

Easy enough! Thanks.
Robert
I'm seeing the following settings for the PS3 profile:

--level 4.1 --ref 3 --mixed-refs --bframes 3 --b-pyramid

It includes >2 b-frames, adaptive b-frames, and b-frame pyramids, all of which have been noted for their potential to break DXVA. Unless someone has already tested them @ 1080p + num_ref_frames < 5?

tetsuo55

1st January 2008, 11:10

someone will have to test them, but from what i can find on hardware players it seems that simply using profile 4.1 will fix the problems

cscxk

1st January 2008, 11:28

my test is for 1920*1080,only need to set ref 3 and no b-pyramid.for 1280*720,ref to 6 and no b-pyramid.so i think the first is disable b-pyramid.

UsedUser

1st January 2008, 12:00

my test is for 1920*1080,only need to set ref 3 and no b-pyramid.for 1280*720,ref to 6 and no b-pyramid.so i think the first is disable b-pyramid.
My suspicion is that b-pyramid is involved.

B-pyramid allows b-frames to be used as reference frames for other b-frames. So, if B-pyramid is "on", then the b-frames you have set are counted in the total num_ref_frames.

You can see this formula holds (partially) true in the AVInaptic output. With B-pyramids, num_ref_frames = ref_frames + b-frames (i.e., num_ref_frames = (3 ref_frames) + (3 b-frames) = 6). However, with B-pyramids, it must allow for extra references even at 2 b-frames, as num_ref_frames = (2 ref_frames) + (2 b-frames) = 5.

I'm currently testing the hypothesis that without b-pyramids, you can push the ref_frames up to the max allowed num_ref_frames for L4.1, e.g., 4 @ 1080p, 9 @ 720p.

UsedUser

1st January 2008, 12:57

Well, I made a bit of an error in thinking the ref value could be set to the max allowed num_ref_frames, because that wouldn't allow for the B-frames. So, I have to reject that hypothesis.

However, like cscxk, I have found that, with B-pyramids off, the magic value for ref is 3. num_ref_frames = (3 ref) + (3 B-frames) + (no-B-pyramids) = 4. With num_ref_frames = 4, DXVA works @ 1080p.

I'm thinking what we need, though, is more information about how to predict num_ref_frames.

My new hypothesis is that num_ref_frames won't always equal 4 when ref = 3 and B-frames = 3, if adaptive b-frames is ON.

With adaptive b-frames the encoder decides the number of (consecutive) B-frames, and the B-frames value is then used as a MAXIMUM, rather than a forced number of B-frames. So, my prediction is that for the clips I/we have tested, only 1 B-frame is actually being used with adaptive B-frames turned on. If I'm right, then num_ref_frames will be 6 if ref = 3, B-frames = 3, and B-adapt = no.

If this is true, then to force DXVA compatibility @ 1080p, we really need the following settings to use at most 1 consecutive B-frame and limit num_ref_frames to 4:

--level 4.1 --ref 3 --mixed-refs --bframes 1 --b-adapt

UsedUser

1st January 2008, 13:12

Well, reject that hypothesis as well.

I just tested a clip using the following settings, expecting num_ref_frames = 6:

--level 4.1 --ref 3 --mixed-refs --bframes 3 --no-b-adapt

Adaptive b-frames made no difference. num_ref_frames = 4 in both cases.

So, I still don't know what the magic formula is to arrive at num_ref_frames = 4, but with any clip I've encoded thus far, using the following settings has worked and resulted in successful DXVA @ 1080p:

--level 4.1 --ref 3 --mixed-refs --bframes 3 --b-adapt --no-b-pyramid

So, the only things that need to be changed from the PS3 profile for 1080p are to disable B-pyramids and increase the bitrate to your desired quality/filesize.

As for 720p, I've tested a number of clips with num_ref_frames from 4 to 8, all of which used DXVA, but with choppy playback. I used MP4 instead of MKV, so it isn't the 20fps bug I'm seeing. I need to do more 720p testing.

CruNcher

1st January 2008, 13:44

in some tests of this problem i found out that you can workaround it by useing drect temporal prediction instead of auto or spatial but im not sure why this was the case but it worked and yes b-pyramid shouldn't be used ever for DXVA compatibility and 2 ref frames btw is also the standard for example in Sonic Cinevision. Also something strange is with X264 bitstreams since the begining it seems the bitrate declared flag is wrong you can see this by renameing a .h264 bitstream to .mpv and playback it via PowerDVD then activate the OSD and you gonna see a non changeing bitrate value (also in the information tab the Value is to high for example you encoded AVG 7500 and Max is 10000 kbits it shows you 36 Mbits but it never reached that and only if you rename the bitstream to .mpv you gonna see it or analyzeing it with Elecard Stream analyzer there the Bitrate Declared Field is also visible) in the Counter wich is to high most of the times. With other Encoded Bitstreams from Nero (Ateme) and Mainconcept this value is changeing acordingly to the stream bitrate. Now if you use h264info on such a X264 bitstream without changeing any parameter just run it throug you gonna see suddenly that the counter is moveing but with extreme High values even higher then what it showed as the Hard value before useing h264info on it for example in the case above you gonna suddenly see 2200 Mbits in the Counter hehe, this doesn't seem right to me.

cscxk

1st January 2008, 13:54

valnar

1st January 2008, 16:22

@UsedUser.

Keep those tests coming! Great work!

Robert

UsedUser

2nd January 2008, 00:54

on my system,this could play with DXVA.Job commandline:
--level 4.1 --keyint 999 --min-keyint 1 --ref 3 --mixed-refs --no-fast-pskip --bframes 8 --b-rdo --bime --weightb --direct auto --filter -3,-2 --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --progress --no-dct-decimate --no-psnr

and you see,b-frames is 8
I concur. B-frames can be pushed all the way up to 16 without breaking DXVA, as long as (num_ref_frames < 5 @ 1080p) or (num_ref_frames < 10 @ 720p) and B-pyramids are OFF.

valnar

2nd January 2008, 01:07

I concur. B-frames can be pushed all the way up to 16 without breaking DXVA, as long as (num_ref_frames < 5 @ 1080p) or (num_ref_frames < 10 @ 720p) and B-pyramids are OFF.

Supposedly if you keep bframes below 3 always, you add PS3 and other H.264 device compatibility too. That's what I'm looking for - the ubiquitous configuration that'll work with everything that can handle hi-def up to level 4.1 and hopefully futureproof the files.

-Robert

UsedUser

2nd January 2008, 01:49

I'm fairly confident now that the feature breaking DXVA really is compliance with Profile High@L4.1, which is to say the num_ref_frames value.

What I didn't initially understand, and still don't fully, is the formula that is used to determine the num_ref_frames value, which is distinct from the "ref" value set when encoding. The "ref" value, the "bframes" value, and the "b-pyramid" value all factor into the final "num_ref_frames" value. The "ref" value seems to contribute its value directly, while adding b-frames only contributes 1 (no matter the "b-frames" value), and b-pyramid seems to contribute 2.

For example:

ref=3 adds 3 to num_ref_frames
b-frames=3 adds 1 to num_ref_frames
b-pyramid adds 2 to num_ref_frames
num_ref_frames = 3 + 1 + 2 = 6 (2 more than are allowed @ 1080p)

It is the num_ref_frames value that must comply with High@L4.1, where (num_ref_frames < 5 @ 1080p) and (num_ref_frames < 10 @ 720p).

B-pyramids, adaptive b-frames, mixed ref frames, weighted prediction --- all can be enabled, as long as the resulting encode stays under the limit of num_ref_frames.

The easiest way to reliably meet this requirement while encoding is to set the "ref" value one under the max allowed num_ref_frames and to turn off B-pyramids, because they may unpredictably contribute to num_ref_frames. The B-frames value can be anything you want, but with adaptive b-frames, I believe "3" is still the recommended value, unless you're encoding animation, where "8" or more could be justified.

The following encoding settings allow DXVA to work @ 1080p:

num_ref_frames=4 ref=1 b-frames=3 b-pyramid=on
--level 4.1 --ref 1 --bframes 3 --b-pyramid --b-adapt --b-rdo --bime --weightb --direct auto --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-maxrate 25000 --me umh --merange 12

num_ref_frames=4 ref=3 b-frames=3 b-pyramid=off
--level 4.1 --ref 3 --mixed-refs --bframes 3 --no-b-pyramid --b-adapt --b-rdo --bime --weightb --direct auto --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-maxrate 25000 --me umh --merange 12

num_ref_frames=4 ref=3 b-frames=3 b-pyramid=off b-adapt=off
--level 4.1 --ref 3 --mixed-refs --bframes 3 --no-b-pyramid --no-b-adapt --b-rdo --bime --weightb --direct auto --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-maxrate 25000 --me umh --merange 12

num_ref_frames=4 ref=3 b-frames=16 b-pyramid=off
--level 4.1 --ref 3 --mixed-refs --bframes 16 --no-b-pyramid --b-rdo --bime --weightb --direct auto --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-maxrate 25000 --me umh --merange 12

num_ref_frames=4 ref=4 b-frames=0 b-pyramid=off b-adapt=off
--level 4.1 --ref 4 --mixed-refs --bframes 0 --no-b-pyramid --no-b-adapt --b-rdo --bime --weightb --direct auto --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-maxrate 25000 --me umh --merange 12

The following encoding settings BREAK DXVA @ 1080p:

num_ref_frames=5 ref=2 b-frames=2 b-pyramid=on
--level 4.1 --ref 2 --mixed-refs --bframes 2 --b-pyramid --b-adapt --b-rdo --bime --weightb --direct auto --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-maxrate 25000 --me umh --merange 12

num_ref_frames=6 ref=3 b-frames=3 b-pyramid=on
--level 4.1 --ref 3 --mixed-refs --bframes 3 --b-pyramid --b-adapt --b-rdo --bime --weightb --direct auto --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-maxrate 25000 --me umh --merange 12

num_ref_frames=5 ref=4 b-frames=3 b-pyramid=off
--level 4.1 --ref 4 --mixed-refs --bframes 3 --no-b-pyramid --b-adapt --b-rdo --bime --weightb --direct auto --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-maxrate 25000 --me umh --merange 12

The following encoding settings allow DXVA to work @ 720p:

num_ref_frames=9 ref=9 b-frames=0 b-pyramid=off b-adapt=off
--level 4.1 --ref 9 --mixed-refs --bframes 0 --no-b-pyramid --no-b-adapt --direct auto --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-maxrate 25000 --me umh --merange 12

num_ref_frames=9 ref=8 b-frames=3 b-pyramid=off
--level 4.1 --ref 8 --mixed-refs --bframes 3 --no-b-pyramid --b-adapt --b-rdo --bime --weightb --direct auto --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-maxrate 25000 --me umh --merange 1

num_ref_frames=8 ref=7 b-frames=3 b-pyramid=off
--level 4.1 --ref 7 --mixed-refs --bframes 3 --no-b-pyramid --b-adapt --b-rdo --bime --weightb --direct auto --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-maxrate 25000 --me umh --merange 12

num_ref_frames=7 ref=6 b-frames=3 b-pyramid=off
--level 4.1 --ref 6 --mixed-refs --bframes 3 --no-b-pyramid --b-adapt --b-rdo --bime --weightb --direct auto --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-maxrate 25000 --me umh --merange 12

num_ref_frames=9 ref=6 b-frames=3 b-pyramid=on
--level 4.1 --ref 6 --mixed-refs --bframes 3 --b-pyramid --b-adapt --b-rdo --bime --weightb --direct auto --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-maxrate 25000 --me umh --merange 12

The following encoding settings BREAK DXVA @ 720p:

num_ref_frames=10 ref=9 b-frames=3 b-pyramid=off
--level 4.1 --ref 9 --mixed-refs --bframes 3 --b-pyramid --b-adapt --b-rdo --bime --weightb --direct auto --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-maxrate 25000 --me umh --merange 12

cscxk

2nd January 2008, 02:41

i think you are right."num_ref_frames=4 ref=3 b-frames=16 b-pyramid=off" is power than "num_ref_frames=4 ref=3 b-frames=3 b-pyramid=off b-adapt=off".so "b-adapt=off" is not need.but "num_ref_frames=4 ref=4 b-frames=0 b-pyramid=off" should allow DxVA?

and allow dxva only be limited by num_ref_frames,not other.did you think so?

UsedUser

2nd January 2008, 05:03

"num_ref_frames=4 ref=4 b-frames=0 b-pyramid=off" should allow DxVA?
Yes --- ref=4 b-frames=0 worked with DXVA for me.

and allow dxva only be limited by num_ref_frames,not other.did you think so?
Yeah, the bottom line, I believe, is that allowing DXVA is only limited by the num_ref_frames value.

UsedUser

2nd January 2008, 05:12

One other reasonably important note --- I tested all of the encodes using the Cyberlink H.264 decoder on both an Nvidia 8800GT and an ATI HD2600PRO.

I got a gray screen during playback with every clip using the Nvidia card --- it NEVER successfully displayed a picture.

I got perfect DXVA playback with every compliant clip on the ATI card.

cscxk

2nd January 2008, 06:10

CruNcher

2nd January 2008, 06:24

UsedUser im useing the 8800 GT G92 VP2 too with Cyberlinks Decoder before that a 7600 GS G71 VP1 and all complaint streams are working with the latest PowerDVD Decoder Filter and give me actually almost 0% Cpu Utilization on the G92 now without Sound im really amazed by that. Had no problems yet with it staying in the Parameters (even tried bitstreams with over 200 Mbits ok they where not playing fluid but they played) ( Forceware 192.21 WHQL and 192.28 Beta), but thats true for now only with tested raw bitstreams useing the .mpv extension with PowerDVD.
Those Bitstreams also had no playback problems in .mp4 but in .mkv they gave me often problems with the G71 for example if you have a .mkv where the fps lowers suddenly after some seconds of playback dramaticly down, my experience is that it lowers from normal playback framerate constantly down this constant 20 fps problem i didn't experienced yet (but i watch no anime or vfr stuff that might force timecode problems here with Cyberlinks Decoder that's mostly only used with anime and mkv). Demuxing such lowering fps framerate streams out of the .MKV containter and playback those Bitstreams with PowerDVD (7600 GS G71) worked for me so it must be something else here that has todo with this phenomenon except Hardware Limitations of the Stream itself. I asked Haali about a problem that might be in the way PowerDVD filter parses the container, but haali has not looked into this yet as he doesn't use PowerDVD and it's filters personaly. For Nvidia tough Cyberlinks Decoder seems to be the most compatible for WinXP at least in the meaning of Hardware Playback, so i would advise as hard as it sounds in terms of compatibility screw Matroska .MKV (there is so many Matroska stuff out that plays wrong with Hardware Playback, sometimes its also just stuttering for some frames) and use the standard advised .MP4, for hopefully no Interoperability problems @ the moment with Cyberlinks or any other Decoder on the market and correct Hardware DXVA Playback :(

At the moment also PowerDVD is the only choice for WinXP 8800GT VP2 PureVideo users as it is allways allowing to use Hardware accellerated Playback even with Subtitles and both HD-DVD and Blu-Ray and it makes no difference wich Codec Mpeg-2, VC-1 or H.264 everything works as it should be and is full Hardware accellerated to the capabilities of the Chip (VC-1 has higher CPU utilization as we know on Nvidia).
I tested every Software HD-DVD and Blu-Ray Player on the Market today except Corel WinDVD 9 Plus as it isn't available yet and all of them Show problems with Hardware Playback and the 8800 GT even Arcsoft Digital Theatre 2 wich has problems with Hardware accellerated VC-1 Playback doesn't showing the Video @ all only Software Mode Playback works here (and even then HD-DVD menus are flickering on screen). Nero Showtime does in General not work when the Medium uses Subtitles Hardware Accelleration is disabled on XP (not sure if it's a bug or Limitation but i try to make it known to Ahead and Nero for a long time and now im almost sure it's a Limitation of their Video Rendering usage on XP (VMR9 usage)). The only one that works with Mpeg-2 and H.264 in those regards are PowerDVD and Arcsoft Digital Theatre 2 with Arcsoft haveing the fastest BDJ Engine i saw nowdays but more Problems with HD-DVD and VC-1 then PowerDVD (it's BDJ Engine is not as fast as Arcsoft but works and also Menu Interoperability with HD-DVD and VC-1 is better, no flickering Menus and full Accelleration to the capabilities of the G92) :) But Arcsofts Player Software nevertheless has great Potential if they once squashed this bugs and is allready better then Showtime in Hardware Accelleration regards being used allways even with Subtitles, see http://forum.doom9.org/showthread.php?t=133278: for a inside look into there Software Player :)

kumi

2nd January 2008, 06:31

@Cruncher:

A friendly tip: if you don't add any punctuation at all to your sentences, most people are not going to read past the first 2 or 3 dozen words.

It's unreadable.

foxyshadis

2nd January 2008, 07:30

So basically x264 needs a new parameter to specify the absolute maximum refs any frame can use, to keep b-frame efficiency? Sounds like a good patch if Dark Shikari is interested =D

CruNcher

2nd January 2008, 07:42

Done,can you read and understand it now ?

akupenguin

2nd January 2008, 07:51

So basically x264 needs a new parameter to specify the absolute maximum refs any frame can use, to keep b-frame efficiency?
No, that's what it already has. The new option needed is something to specify DPB size, and just let each frame use as many refs as possible within that constraint. Or I can repurpose --ref to do that: the current method was chosen because direct=temporal benefits from having the same number of L0 refs in all frames, but since direct=spatial is usually better anyway, it's no longer necessary.

CruNcher

2nd January 2008, 08:07

No, that's what it already has. The new option needed is something to specify DPB size, and just let each frame use as many refs as possible within that constraint. Or I can repurpose --ref to do that: the current method was chosen because direct=temporal benefits from having the same number of L0 refs in all frames, but since direct=spatial is usually better anyway, it's no longer necessary.

Ahhh that would also explain why useing direct=temporal workedaround that slowdown problems in my previous tests :)

Here is alot to read about this stuff that drive me almost crazy and the workkaround that actually worked @ that time dunno about the situation now as so much changed again (Mp4box, Mkvmerge,X264,Cyberlinks Decoder, Haalis Splitter, Nvidias Drivers and the new VP2 (PV2))

http://forum.doom9.org/showthread.php?t=124945
http://forum.doom9.org/showthread.php?t=127712

alot of MKV i tested last Month still showed problems not the old ones slowdowns or black screen but now it's that frames are beginn to stutter with Hardware Playback and all of them use X264 so there is definately still something wrong somewhere and we still have a interoperability problem here (wherever it comes from).

Btw the Stream lowcomplexity-highpro-test.mp4 that i tested that time that showed a black Screen this same Stream works in the latest PowerDVD Player directly without a Problem but via Mplayer Classic and Haali or the standard MP4 splitter and Cyberlinks Decoder it just shows the start frame (via VMR9 with Standard Video Renderer i get a Black Screen and i could swear that with Mainconcepts Splitter and Annex B output it would play) and does not start playing the whole thing (jesus). It works in any other Software Player Mplayer or Vlc for example without Problems and also if disabling DXVA in the new PowerDVD filter it plays normal. So the Problem here can't be anything else then how Cyberlinks Decoder handles the other Splitters Information as in combination with its own Splitter via it's own Player it works painless. So most of this Problems arise by a combination of many factors that have to come together for Painless Hardware Accellerated Playback under Windows XP those are (Player Software and it's Rendering Mode, Parser/Splitter and Decoder) if all of these 3 don't work in a absolute interoperable way you will experience Problems with Hardware Accellerated Playback dunno if this is still the case for DXVA 2.0 under Vista as it is more managed there into the platform it seems. Sad thing is Windows is the only Solution @ the moment for Full Hardware Accellerated Playback as even AMD doesn't want to reveal it's UVD inner workings to the Open Source Community yet and most probably never will :(

Athlon 64 X2 2.8 Ghz Toledo Windows XP SP2

lowcomplexity-highpro-test.mp4 <- it's a very simple stream no real goodies of H.264 here even lower complexity than Quicktime
PowerDVD useing Nvidia VP2 G92= 0% Full Hardware Accelleration (how much it stresses the G92 and how much power that utilizes is uknown yet )
CoreAVC 1.6 = upto 13%
Mplayer = upto 14%
VLC = upto 18%

UsedUser

2nd January 2008, 09:24

akupenguin

2nd January 2008, 10:08

What are the implications of repurposing --ref?
It would slightly change the quality and speed of any given ref number. Not the overall quality-per-speed tradeoff, just the mapping of --ref argument to a point on the quality curve. Probably no one would notice.
Another way to think of it is: Currently refs are allocated in a way that's most convenient for the encoder. The alternative is an allocation that maximizes quality per memory use (i.e. Level constraint). If I were to implement the slightly less convenient (for me) but more efficient (for the decoder) arrangement, there's no point in making it just optional.

UsedUser

2nd January 2008, 11:27

It would slightly change the quality and speed of any given ref number. Not the overall quality-per-speed tradeoff, just the mapping of --ref argument to a point on the quality curve. Probably no one would notice.
Another way to think of it is: Currently refs are allocated in a way that's most convenient for the encoder. The alternative is an allocation that maximizes quality per memory use (i.e. Level constraint). If I were to implement the slightly less convenient (for me) but more efficient (for the decoder) arrangement, there's no point in making it just optional.
Given the constraints are being imposed by standards (i.e., High@L4.1) now implemented in hardware and closed-source commercial decoders, it seems it would make the most sense to build in at least the capability to maximize quality within the constraints. I say do it! :)

This discussion is making me curious about the effort required for such changes. Time to dig into the code a bit. :)

CruNcher

2nd January 2008, 11:38

Yep actually that is what all the big companies currently do they try to achive the best visual quality in those given Level constraints and the nearest look and feel to the input source, but visual tweaking should come after stabilizing everything and im personaly not sure if X264 is that Hardware stable yet testing this on such a HD-DVD or Blu-Ray standalone and it's chip i think would reveal where the problems still are hiding (can't test on those as im no SAP user) but i can test it on Nvidias and Atis 2nd Generation Decoder Cores and that's what im currently doing with the G92 and RV670 :)

audyovydeo

2nd January 2008, 12:36

What I didn't initially understand, and still don't fully, is the formula that is used to determine the num_ref_frames value, which is distinct from the "ref" value set when encoding.

UserUser,

from an exchange I had with fsinapsi some time ago, the answer is in : x264/encoder/set.c :

sps->i_num_ref_frames = X264_MIN(16, param->i_frame_reference + sps->vui.i_num_reorder_frames + param->b_bframe_pyramid);

I'm quoting his quote, I am not qualified to delve into code.

What I havent figured out though is that I have always encoded my SD content to sorta-level 3.1, with num_ref_frames =< 6, and it does not seem to get accelerated.

Or maybe it does, sometimes.
hard to figure.

cheers
audyovydeo

valnar

2nd January 2008, 15:36

It is the num_ref_frames value that must comply with High@L4.1, where (num_ref_frames < 5 @ 1080p) and (num_ref_frames < 10 @ 720p).

I think the only questions I have left is why is this the case and how is it enforced by the video cards for DXVA?

"Why" we may never know, but let me expand on "how".

How does the video card know if something is 1080p or 720p to enforce the 5 or 10 num_ref_frames limit? What is it looking for?

What if you encode the video for 721p or 1079p... or 1001p? What value determines the 5 or 10 num_ref_frames limit in the eyes of the video card? Do those numbers have to be hit exactly (720p or 1080p) for DXVA to work at all? Or is it based on a threshold and approximation? ie. Would 900p (half-way between 720 + 1080) mean 7 or 8 num_ref_frames allow you hardware acceleration?

The question is mostly academic since most won't encode for those odd resolutions, but I'm curious.

-Robert

RaynQuist

2nd January 2008, 17:26

...
What value determines the 5 or 10 num_ref_frames limit in the eyes of the video card?
...
Would 900p (half-way between 720 + 1080) mean 7 or 8 num_ref_frames allow you hardware acceleration?

It's the maximum decoded picture buffer that determines the limit.
1920x1080x4 = 8294400
1280x720x9 = 8294400

So 900p would have a limit of
8294400/(1600*900) = 5.76 reference frames

Why does this happen? Because hardware decoders are only going to add as much cache into the chip as necessary, otherwise you'll be wasting transistor / increasing die space. Software decoders can just allocate as much memory as they feel like since you already have hundreds of megs of ram.

Sagekilla

3rd January 2008, 03:20

CruNcher

3rd January 2008, 15:09

Uhh jesus i feel really dumb now, i solved the problem of the lowcomplexity-highpro-test.mp4 after looking again at it, i could have sworn i create it as Level 4.1 but actually it is Level 5.1 that obvously coused the Black Screen with PowerDVD and Haalis Splitter, tough Profile Level is completly ignored by PowerDVD and both the Bitstream and MP4 Parser. Most probably the same case is with Mainconcepts Splitter when setting Annex-B output mode. That's no bad thing not really standard compliant i think, but it's imitating other Software Player (Mplayer and VLC) with Hardware Playback so you never gonna have problems, because even if the Bitstream says Level 5.1 or anything else it will send it to NVIDIA's/ATI's Hardware Decoder anyway and try to playback it. With Haalis Splitter it takes the Bitstream Profile Level into account and stops Playback instantly. Haali could maybe make a Annex-B output mode that would help alot of people without the need to change the Profile Level and Desktop Hardware Playback in combination with PowerDVDs Decoder :) http://forum.doom9.org/showthread.php?p=1082322#post1082322
Im looking now into the other MKV stuttering problems :)

Btw this also means that PowerDVD is perfect for debuging such Problems as we try to solve here i found other streams that stay black and now can be sure it's not coused by the Bitstream Info as such but the Stream itself or the container arround it :)

Streams that playback on G92 VP2:

lowcomplexity-highpro-test.mp4= Num ref frames 1 1280x720 23.976 fps
Track1.mp4= Num ref frames 2 1280x720 29.97 fps
CrowdCross.40000.mp4= Num ref frames 4 1920x1080 24.00 fps fps
blade.mp4= Num ref frames 13 320x240 23.976 fps
christina-highmorenew.mp4= Num ref frames 1 1280x720 23.976 fps
TheGreatestGame_HD_AVC.mp4= Num ref frames 3 1920x1080 23.976 fps
sample_h264_100kbit.mp4= Num ref frames 2 192x242 30 fps
sample_h264_1Mbit.mp4= Num ref frames 2 380x280 30 fps
batman-ateme-3500k-hp.mp4= Num ref frames 6 1280x544 29.97 fps
empire.mp4= Num ref frames 6 1280x720 59.94 fps
hp2-ateme-450k-hp.mp4= Num ref frames 9 720x304 25 fps
The-Island_PPC-Trailer-High_Profile-x264-AAC-CoreAVC.mp4= Num ref frames 4 320x128 23.976
Tractor_HD-High_Profile-x264.mp4= Num ref frames 4 1920x1080 25 fps
crf20.mp4=Num ref frames 3 1440x1080 30 fps
HDTV.mp4= Num ref frames 2 1440x1088 25 fps

Streams that don't playback on G92 VP2:

Num ref frames 7 1920x816 23.976 fps
Num ref frames 2 1920x1088 29.97 fps

only very few doesn't playback and their not done by me ;)

akupenguin

3rd January 2008, 15:58

What does "Annex-B output mode" have to do with anything? It certainly isn't related to Levels.

CruNcher

3rd January 2008, 18:20

I can't tell you the only thing i can say it works if "Annex B output for H.264/AVC" is active and when it isn't it stays dark if the Bitstream Profile Level isn't 4.1, same darkness as with Haalis Splitter :)

foxyshadis

3rd January 2008, 20:48

Every frame of a 1920x1080 film actually takes up 3060KB, just for reference. Don't forget chroma planes. :p

UsedUser

4th January 2008, 11:04

CruNcher, not sure how your post relates to DXVA playback. Are you saying it's the splitter and not the Cyberlink decoder that is imposing a limit of L4.1 for DXVA? Can someone distill this for me?

CruNcher

4th January 2008, 12:45

Exactly UsedUser Cyberlinks own (Demuxer/Splitter) Framework is ignoring the Profile Level either Bitstream (RAW) or when in any other Container (tested at least with it's MP4 Parser) :D, but Haalis splitter somehow gives this information to Cyberlinks Decoder and it seems to accept it and then the result is instant playback stop if Level is 5.1 (standard that X264 saves or saved Guis seem to adapt to this and chose 4.0 here). Im not talking about the Stream itself im talking about the level_idc flag in the Bitstream.

arfster

4th January 2008, 22:30

Yeah, seems the files need to specifiy 4.2 or cyberlink chokes. This guy seems to have a solution (to the 20fps bug, not the ref frames issue):

http://www.avsforum.com/avs-vb/showpost.php?p=12680502&postcount=3872

Tried it on one file, worked perfectly.

valnar

4th January 2008, 23:12

CruNcher

5th January 2008, 08:12

Soon people will realize that there is a new problem with X264 bitstreams (Choppy playback or frame stuttering) it happens somewhere here -> (PBPBBPBBPBBBPBPBPBPBPB) <- couseing frame stuttering (IPPPPPPPPI) <--- is ok as soon as it hit's PBPBBPBPBPB it get's choppy again , and i have no idea why for me it seems to look normal, but it's coming from the bitstream this sample even crashes Mplayer when ariving this and shows frame destruction in VLC. With the G92 it just beginns to stutter here after that PB sequence it playbacks normaly again till it hits the next.

Num ref frames 8:

file type : ES
video stream type : AVC/H.264
resolution : 1280x720
profile:level : High:5.1
aspect ratio : 16x9(unspecified)
interlaced : no
frames count : 2 210
frame size max : 181 878
avg : 22 215
avg/max (I) : 84 716 / 181 878
avg/max (P) : 30 043 / 46 513
avg/max (B) : 6 790 / 14 697
min : 2 535
file size : 49 095 553
--------------------------------------------

framerate declared : 29.97
--------------------------------------------
real : (var) 29.97

bitrate declared : 0
--------------------------------------------
real max : 8 280 354
real avg : 5 326 270
real min : 3 189 049
--------------------------------------------

ok changeing level with h264info to 4.1 fixed the stuttering and also doesn't crash Mplayer or showing Frame Destruction with VLC anymore (demuxed from a MKV) hmm so PowerDVD doesn't really seem to ignore the Level fully or Nvidias Hardware Decoder

Fixed with H264info Hardware Playback works fine now on Nvidias Decoder Core (BSP/VP2) with PowerDVD:

file type : ES
video stream type : AVC/H.264
resolution : 1280x720
profile:level : High:4.1
aspect ratio : 16x9(unspecified)
interlaced : no
frames count : 2 209
frame size max : 182 096
avg : 22 238
avg/max (I) : 84 924 / 182 096
avg/max (P) : 30 070 / 46 535
avg/max (B) : 6 812 / 14 719
min : 2 557
file size : 49 124 422
--------------------------------------------

framerate declared : 29.97
--------------------------------------------
real : (var) 29.97

bitrate declared : 20 000 256
--------------------------------------------
real max : 8 287 307
real avg : 5 331 785
real min : 3 194 323
--------------------------------------------

So not only the Black Screen problems can happen under some circumstances (Parser->Decoder) also random Frame Stuttering and the allways 20 fps playback problems (with B-frame Sequences) can be caused on Hardware if the level_idc flag is to high.

So 2 Playback Problems that can arise now from a to High level_idc flag on Hardware pinpointed. With the extremest (that has nothing todo with the Level) being non playback @ all, because of a to high num_ref_frames flag for a given resolution :)

With this Sample it looks like this on Nvidias Hardware Decoder

1.0 = nope (no playback)
1.1 = nope (no playback)
1.2 = nope (no playback)
1.3 = nope (no playback)
2.0 = nope (no playback)
2.1 = frame errors (all frames)
2.2 = frame errors (all frames)
3.0 = frame errors (all frames) (Should be the target for interoperability with Sonys PSP (480/576) also the target for HD-DVD (480/576) and DVD AVC (480/576) NTSC/PAL)
3.1 = frame errors (all frames)
3.2 = frame errors (all frames)
4.0 = works (Should be the target for interoperability with HD-DVD and Blu-Ray SAPs PS3 and Xbox360 and Desktop Decoders Nvidia/ATI (720/1080))
4.1 = works
4.2 = works
5.0 = frame stuttering (B-frame sequences)
5.1 = frame stuttering (B-frame sequences)

bitrate declared is allways written as 20 000 256 by H264info so wrong for the other Levels bellow 4.0

I think we can be almost sure that if selfmastered X264 HD-DVDs and Blu-Rays playback fine on Nvidias (BSP/VP2) and ATIs (UVD) new Hardware Decoders they should playback fine also on real HD-DVD and Blu-Ray SAPs :) but this is strange as officialy 1280x720p with a framerate of 29.97 isn't supported by HD-DVD @ all only 59.94 NTSC and 50 PAL are (sure this makes no real sense anyway and for sure such mastered 29.97 fps HD-DVDs should work on most SAPs i hope).

I think this also plays a major role when thinking about Domain Transcoding Level 4.0 stuff into a lower level (in the future)

If someone does a X264 encode with High Profile and a resolution of 720/1080 X264 should at least automaticly decide that a level_idc flag of 4.0 is apropiate (could also been done by the Guis themselves by following the decissions of the user (for example resizeing))

UsedUser

5th January 2008, 10:33

So as it stands now:

DXVA requires that the DPB size complies with Profile High@L4.1, meaning num_ref_frames = 4@1080p and 9@720p. Resolutions in between those can have different quantities of reference frames as long as {Height * Width * num_ref_frames <= 8294400} holds true (i.e., 1920x864 can have num_ref_frames = 5, 1280x648 can have num_ref_frames = 10). References and everything included, the actual value for DPB size cannot exceed 12,582,912 for L4.1.

The Cyberlink decoder, when using DXVA, requires the level_idc value to be between 4.0-4.2 in order to achieve smooth playback (sans stuttering or 20fps). If the stream is actually compliant, but the level_idc value is set too high (i.e., L5.1), then the level_idc flag can be changed to L4.1 and the stream will be played back smoothly.

Essentially, people need to encode to the PS3 profile, except with B-pyramids disabled. That would set L4.1 in the stream and comply with the L4.1 restrictions for all streams up to 1080p.

Sound right?

akupenguin

5th January 2008, 10:35

ok changeing level with h264info to 4.1 fixed the stuttering and also doesn't crash Mplayer or showing Frame Destruction with VLC anymore

What stream? I won't believe that without evidence, given that I have the libavcodec sourcecode right here and it completely ignores level.

bitrate declared is allways written as 20 000 256
That can only be a bug in H264info. x264 never specifies bitrate. The standard says that if bitrate is not present, it shall be inferred as the maximum allowed by the level. 20mbit/s is appropriate for levels 3.2 and 4.0, no others.
Or did you use the x264 HRD patch? In that case, it might be a bug in the patch.

Num ref frames 8:
1.0 = nope (no playback)
1.1 = nope (no playback)
1.2 = nope (no playback)
1.3 = nope (no playback)
2.0 = nope (no playback)
2.1 = frame errors (all frames)
2.2 = frame errors (all frames)
3.0 = frame errors (all frames) (Should be the target for interoperability with Sonys PSP (alot of other Mobile Devices) also the target for HD-DVD (480p) and DVD AVC PAL/NTSC)
3.1 = frame errors (all frames)
3.2 = frame errors (all frames)
4.0 = works
4.1 = works (Should be the target for interoperability with HD-DVD and Blu-Ray SAPs and Desktop Decoders Nvidia/ATI (720/1080))
4.2 = works
That checks out. 4.0 is the minimum that has a big enough DPB for 1280x720x8refs. 2.0 doesn't even have enough DPB for one frame.
5.0 = frame stuttering (B-frame sequences)
5.1 = frame stuttering (B-frame sequences)
That's just weird. Good luck figuring it out ;)

CruNcher

5th January 2008, 11:55

What stream? I won't believe that without evidence, given that I have the libavcodec sourcecode right here and it completely ignores level.

Yes, Sorry the Stream is fine with Mplayer and the crash is something really really strange (but really if you have a PC you get used to this strangeness over the years), if the file is named mplayercrash.h264 it works if i rename it to less characters like mplayercras.h264 it crashes after some seconds playback (useing Mplayer for Windows and Smplayer) (jesus).
This must be the funniest bug i ever found :D

ID_VIDEO_CODEC=ffh264
Audio: no sound
Starting playback...
VDec: vo config request - 1280 x 720 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
[swscaler @ 00DA5310]No accelerated colorspace conversion found
[swscaler @ 00DA5310]SwScaler: using unscaled yuv420p -> rgb24 special converter
VO: [directx] 1280x720 => 1280x720 Planar YV12 [zoom]

MPlayer interrupted by signal 11 in module: decode_video
ID_SIGNAL=11
- MPlayer crashed by bad usage of CPU/FPU/RAM.
Recompile MPlayer with --enable-debug and make a 'gdb' backtrace and
disassembly. Details in DOCS/HTML/en/bugreports_what.html#bugreports_crash.
- MPlayer crashed. This shouldn't happen.
It can be a bug in the MPlayer code _or_ in your drivers _or_ in your
gcc version. If you think it's MPlayer's fault, please read
DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and
won't help unless you provide this information when reporting a possible bug.

That can only be a bug in H264info. x264 never specifies bitrate. The standard says that if bitrate is not present, it shall be inferred as the maximum allowed by the level. 20mbit/s is appropriate for levels 3.2 and 4.0, no others.
Or did you use the x264 HRD patch? In that case, it might be a bug in the patch.

Yes it allways sets 20mbit and yes that's not a x264 bug but H264info and i see the bitrate declared stuff is not really needed to keep Hardware compatibility so it's also not interesting @ all.

BTW im asking myself another question (and ofcourse try to find an answer to it) that is if we have a bitstream allready encoded with a to high num_ref_frame flag what would happen if we change it manualy (Hex Edit) to a lower value ?, for sure there would be no Black screen anymore but what else ? (see top level results). In many situation i think it could work even without showing garbage on some Devices at least that's what i hope.

0000000167640033AC56C05005BB0110000003001000000303C8F18313800000 <--- num_ref_frame = 2
0000000167640033AC564014016EC044000003000400000300F23C60C4480000 <--- num_ref_frame = 3

C05005BB0110000003001000000303C8F18313800000 <--- num_ref_frame = 2
4014016EC044000003000400000300F23C60C4480000 <--- num_ref_frame = 3

A: C0 40
B: 50 14
C: 05 01
D: BB 6E
E: 01 C0
F: 10 44
14: 10 04
18: 03 00
19: C8 F2
1A: F1 3C
1B: 83 60
1C: 13 C4
1D: 80 48
BA: 31 32

but where is the flag stored i can't see 20 = 14 or 30 = 1E anywhere hmmm ?

i think its ABCDE
num_ref_frame 2 = C05005BB01
num_ref_frame 3 = 4014016EC0
num_ref_frame 8 = E2405005BA
num_ref_frame 11 = E3005005BA

it worked :) changed the 11 ref frame to 8 and now it plays on the G92 (some block errors appearing here and there now and then but overall it's watchable :)) don't forget this was thought as a workaround to get most of the old non hardware compatible X264 streams working (it won't play 100% correct and question remains if DSPs accept this), but the result is much better then the level 2.1 results from above ;)
I might should add that this way also Software Player show the garbaged blocks, so you should really only use it if it's absolutely necessary (recoding sometimes can be a better solution) as it's a evil bitstream hack ;)

Btw im fixing not my own streams here i never saw a reason to use so much Ref frames or B-frames ever :D it's plain dumb for real footage.
All the streams i ever made so far with X264 are Hardware Compatible from the core (except Level flag), it's the user behind the tool that makes such errors, and alot of people here warned about it before and now those that didn't listen are getting payed for not hearing to our calls (in the end it hurts everyone that want's to play those streams on SAP's or PS3/Xbox360 without recoding them) ;)
It's sad to see that People didn't thought about future proveness of their streams in combination with Hardware Players and used such insane Encoding settings and still do, that really aren't worth it from a Visual Quality Standpoint, we all have warned for this to happen.

And personaly i think it's the best Time to wake up now and force the users to addhere to save settings either doing it via a even smarter acting X264 or via all the GUIs out there, something has to happen keeping interoperable with Hardware Devices or it will continue this way and that can't be the Goal.
Aku i know how you think about forceing, but i think it' absolutely necessary especialy for users that dunno what they do at least the GUI Developers should take this advice finaly into consideration, because you guys are the interface to most users that could create such problematic streams.

tetsuo55

5th January 2008, 18:32

What stream? I won't believe that without evidence, given that I have the libavcodec sourcecode right here and it completely ignores level.

That can only be a bug in H264info. x264 never specifies bitrate. The standard says that if bitrate is not present, it shall be inferred as the maximum allowed by the level. 20mbit/s is appropriate for levels 3.2 and 4.0, no others.
Or did you use the x264 HRD patch? In that case, it might be a bug in the patch.

I think he means level instead of bitrate, i can also confirm that changing the level of a non working file will almost always fix DXVA or PS3 playback.

MKV's floating around on the net can be made compatible by changing the level and then rebuilding to mkv or mp4, most of these where encoded with all kinds of incompatible settings i believe.

there will need to be more tests, but it seems that the only thing causing playback failures is the level in the header, not the level used to encode.

So if someone want to try, encode a file with all the settings you would normally use to create a compatible file, but change the level from 4.1 to 5.1.
When the file is finished, use thishttp://www.avsforum.com/avs-vb/showpost.php?p=12680502&postcount=3872 guide to change the header from 5.1 to 4.1 and then test the file in powerdvd

If that actually works, the same can be tried with ref frames above the limit (DXVA should be using the videocard ram, so that means most people will have 256MB at their disposal)

If that works too, the maximum limit for standalone players, ps3 and dxva has to be found, but i don't think we will get this far

-------------

PS. Seeing as CruNcher foudn that SD h264 also does not get DXVA we should add that to the list of things to fix, maybe setting the level to 4.1 (during encode or afterwards) will fix that too?

CruNcher

5th January 2008, 18:50

I think he means level instead of bitrate, i can also confirm that changing the level of a non working file will almost always fix DXVA or PS3 playback.

MKV's floating around on the net can be made compatible by changing the level and then rebuilding to mkv or mp4, most of these where encoded with all kinds of incompatible settings i believe.

there will need to be more tests, but it seems that the only thing causing playback failures is the level in the header, not the level used to encode.

So if someone want to try, encode a file with all the settings you would normally use to create a compatible file, but change the level from 4.1 to 5.1.
When the file is finished, use thishttp://www.avsforum.com/avs-vb/showpost.php?p=12680502&postcount=3872 guide to change the header from 5.1 to 4.1 and then test the file in powerdvd

If that actually works, the same can be tried with ref frames above the limit (DXVA should be using the videocard ram, so that means most people will have 256MB at their disposal)

If that works too, the maximum limit for standalone players, ps3 and dxva has to be found, but i don't think we will get this far

-------------

I can't agree with this i definately have streams here created with X264 that do not playback on Hardware (in this case Nvidias 2nd Generation Decoder Core BSP/VP2), because they used to insane encoding settings the badest is a 1280x720p encode that uses 11 ref frames and is real footage.

And no SD H264 shouldn't be set to level 4.1 that's also insane 3.x seems to be quiet ok for such purposes.

PS. Seeing as CruNcher foudn that SD h264 also does not get DXVA we should add that to the list of things to fix, maybe setting the level to 4.1 (during encode or afterwards) will fix that too?

If you looked in my test of streams you gonna see that all the SD and bellow stuff gets fully accellerated without problems
http://forum.doom9.org/showthread.php?p=1082369#post1082369

akupenguin

5th January 2008, 19:13

Aku i know how you think about forceing, but i think it' absolutely necessary especialy for users that dunno what they do at least the GUI Developers should take this advice finaly into consideration, because you guys are the interface to most users that could create such problematic streams.
http://mailman.videolan.org/pipermail/x264-devel/2008-January/003922.html
discuss.

tetsuo55

5th January 2008, 20:31

I can't agree with this i definately have streams here created with X264 that do not playback on Hardware (in this case Nvidias 2nd Generation Decoder Core BSP/VP2), because they used to insane encoding settings the badest is a 1280x720p encode that uses 11 ref frames and is real footage.

And no SD H264 shouldn't be set to level 4.1 that's also insane 3.x seems to be quiet ok for such purposes.

If you looked in my test of streams you gonna see that all the SD and bellow stuff gets fully accellerated without problems
http://forum.doom9.org/showthread.php?p=1082369#post1082369

Ah i read your post too fast, i now see that correctly encoded SD streams get accelerated.
I wonder what settings are used to encode scene releases then, seeing as fixing the levels seems to fix all their issues.

You are probably right that they (accidentaly?) never go over the ref frames limit for the used resolutions

http://mailman.videolan.org/pipermail/x264-devel/2008-January/003922.html
discuss.

What that guy is saying, is a better explained version of what i mean, however instead of randomly changing x264 i suggest that we find the limits first.

akupenguin

6th January 2008, 03:30

What that guy is saying, is a better explained version of what i mean, however instead of randomly changing x264 i suggest that we find the limits first.
What limits? The proposal doesn't depend on any particular player, only on the observation that underestimating playback requirements has less severe repercussions than overestimating.

tetsuo55

6th January 2008, 07:41

i did someresearch and i thik this is the correct conclusion:
these are the settings for max quaility + Hardware support.

SD up to DVD(480p ntsc, 576p PAL): High= Profile + Level 3

between 481p ntsc, 577p PAL and 720p : High10 profile + Level 3.1

721p to 1088p: High10 profile + level 4.1

In all cases the ref limit must be taken into consideration

It would seem that high10 is backwards compatible with high, so it should work on all players, also it will only use the 10bit plane if it's actually in the source, or so it seems.

x264 does not encode to high10(yet?) unless it was recently added, so in the case of x264 select high instead is the best quality we're going to get.

I can see why players refuse to play 5.1 files, that level is meant for "2304p"

------

What i can't find out though is, why would it be wrong to transcode a DVD with "high(10) + Levels 4.1 as any HD player should support it.
The only thing i can think of is maybe that the endfile will be bigger?

akupenguin

6th January 2008, 07:49

And no SD H264 shouldn't be set to level 4.1 that's also insane 3.x seems to be quiet ok for such purposes.
Why is it insane for an SD file to exceed 20mbit/s peak bitrate? DVD peaks at 10mbit/s, and that's not enough. Even if H.264 compresses better by a factor of 2 (which is an average, not necessarily applicable to the hardest scenes), I won't claim that 20mbit/s is always transparent.

I can see why players refuse to play 5.1 files, that level is meant for "2304p"
It's reasonable for players to reject 2304p files. That doesn't explain why they reject 480p level 5.1 files. All of the information related to whether a given file is playable (such as DPB) is present in the header; level is not the only bit of information a player has to decide based on. A level is label for a collection of features (each of which is also individually specified), conveniently tabled in the standard to help decoder implementers decide on a common set of features to support, and to provide a shorthand for decoders to say what they support. It was never intended to be used as part of the decoding process.

What i can't find out though is, why would it be wrong to transcode a DVD with "high(10) + Levels 4.1 as any HD player should support it.
What makes you think it is wrong? None of the other threads mentioned any minimum resolution.

tetsuo55

6th January 2008, 09:29

Well in that case its the players/decoders that are "Wrong" by only checking the "level" to decide wether or not the file will work.

Unless this is enforced in the h264 specifications.

Also it would seem then that everything could be encoded with high10 + 5.1 + ref frames limit for used resolution, the outputted file just has to keep saying its 4.2 (the highest compatible level, so the player can (if it even does at all) set up itself for the highest level it can take)

UsedUser

6th January 2008, 10:18

there will need to be more tests, but it seems that the only thing causing playback failures is the level in the header, not the level used to encode.
That's not true. I've demonstrated with my tests that even if a stream declares L4.1 in level_idc, the DPB size (num_ref_frames*resolution) is important for DXVA. The limits for DPB size still exist.

As I just summed up yesterday (http://forum.doom9.org/showthread.php?p=1083095#post1083095), DXVA requires DPB size comply with High@L4.1. Smooth playback sans stuttering/20fps requires the stream's level_idc declare L4.1. Both need to comply for smooth DXVA playback.

akupenguin

6th January 2008, 10:22

Well in that case its the players/decoders that are "Wrong" by only checking the "level" to decide wether or not the file will work.
Unless this is enforced in the h264 specifications.
A bitstream specification says what a stream means, i.e. what decoded pixel values correspond to any given compressed stream. It does not and cannot specify any higher-level behavior of a player, i.e. what a player should do with a file.
So, the players aren't violating the standard by rejecting certain streams, because the standard doesn't say anything about that. They are just following suboptimal behavior in terms of what the user probably wants ("play my movie").

tetsuo55

6th January 2008, 10:37

That's not true. I've demonstrated with my tests that even if a stream declares L4.1 in level_idc, the DPB size (num_ref_frames*resolution) is important for DXVA. The limits for DPB size still exist.

As I just summed up yesterday (http://forum.doom9.org/showthread.php?p=1083095#post1083095), DXVA requires DPB size comply with High@L4.1. Smooth playback sans stuttering/20fps requires the stream's level_idc declare L4.1. Both need to comply for smooth DXVA playback.

So do you think Encoding a file with High@5.1 while keeping the DPB size limit of high@4.1 and then afterwards changing the the level_idc to 4.1 will work? And even if it does, does it matter for the quality of the encode?

A bitstream specification says what a stream means, i.e. what decoded pixel values correspond to any given compressed stream. It does not and cannot specify any higher-level behavior of a player, i.e. what a player should do with a file.
So, the players aren't violating the standard by rejecting certain streams, because the standard doesn't say anything about that. They are just following suboptimal behavior in terms of what the user probably wants ("play my movie").

Okay in that case, i agree with the mailinglist poster that x264(or frontend) should calculate the lowest level_idc that the stream complies to and apply that to the file.

Besides that we should be a preset for hardware compatibility

akupenguin

6th January 2008, 10:40

So do you think Encoding a file with High@5.1 while keeping the DPB size limit of high@4.1 and then afterwards changing the the level_idc to 4.1 will work? And even if it does, does it matter for the quality of the encode?
Yes it will work, and the resulting file will be bitwise identical to encoding at level 4.1. Because x264 doesn't do anything with level_idc other than write it to the file.

CruNcher

6th January 2008, 11:07

Yep but sooner or later X264 has to take full VBV and HRD into account when the next problems should appear then with Hardware Decoders, if that ever happens ofcourse, but the problems arised with XviD @ that time are a good indicator that this could happen anytime again.
Surely the Lowcost DSPs in the begining of that time aren't really comparable with AVC DSPs nowdays, wich are much cleaner designed and support everything from the start (and for sure have more resources left to compensate problematic situations for a longer time then those DSPs back then could).
Also H264s bitrate behaviour even without any VBV seems really strict allready so i doub't this will make any problems @ all, at least with lower bitrate encoding stuff (Professional Mastering of HD-DVD or Blu-Rays could give quiet a different picture, but that's anyways not what X264 was made for and other stuff is available from DivX/Mainconcept (Film) or Ateme (Broadcast) for that purpose wich are a step more Strict in that direction, those btw allready write since a long time the correct level_idc into their bitstreams taking resolution and dpb into account).
But yes i would suggest that when DPB size is in the known parameters, especialy for HD that X264 then writes the given level_idc flag for this situation, but also warns the user if it exceeds those "with a clear message" that this most probably won't playback on Hardware Devices. The GUIs have todo the same warning, not everyone will ever see the X264 cmd where this is shown, this way nothing is forced yet and the user are knowing about the problems that they could experience and can decide themselves if they wan't to riks them or not. Personaly i think that's the nicest solution for now for everyone (especialy the Anime Guys will love that, those for sure sometime in the not so distant future are gonna crowed Doom9 with questions like: "why is my Stream not playing on my HD-DVD/PS3/Xbox360/PSP/ipod" i fear) ;)

tetsuo55

6th January 2008, 11:32

These would seem to be the maximum quality settings, (something could go wrong with the b-pyramid one's as i have not tested to see if their end result is more than 2 (this could be the case in the SD files))

I believe these are the best settings for hardware accelerated h264 files, please correct me if i made a mistake

In ALL cases, profile must be High@4.1

1920x1080p --ref 1 --bframes 3 --b-adapt --b-pyramid
1920x1080p --ref 3 --bframes 3 --b-adapt --no-b-pyramid

1280x720p --ref 6 --bframes 3 --b-adapt --b-pyramid
1280x720p --ref 8 --bframes 3 --b-adapt --no-b-pyramid

720×576p --ref 17 --bframes 3 --b-adapt --b-pyramid
720×576p --ref 19 --bframes 3 --b-adapt --no-b-pyramid

720×480p --ref 21 --bframes 3 --b-adapt --b-pyramid
720×480p --ref 23 --bframes 3 --b-adapt --no-b-pyramid

Manao

6th January 2008, 11:32

OT : CruNcher, don't forget your 2007 good resolution : make short and understandable sentences ;p

CruNcher

6th January 2008, 11:34

tetsuo55

6th January 2008, 11:55

My calculations are wrong,

here is a better list:

http://www.avsforum.com/avs-vb/showpost.php?p=12704376&postcount=3898

Indeed we need a (lot) of help, maybe you could encode small sample files of all types, and it should fit on a single layer DVD, that way all the hardware players (except PSP) can be tested with a single disc. Ofcourse the files should be in a container that all the devices understand.

Testers would give feedback on which files do or do not work.

UsedUser

6th January 2008, 11:59

tetsuo55 i can only test this on the G92 Decoder Core for the moment later time also UVD, it would be nice if other would also test it on Xbox360/PS3 and if possible HD-DVD devices and Sony PSP i think if we get interoperability between those devices we have achived a big thing :)
My previous tests (http://forum.doom9.org/showthread.php?p=1081891#post1081891) demonstrated that the L4.1-compliant settings worked for 1080p and 720p on the ATI HD2600 (UVD chip). I also tested some in-between resolutions to ensure it is a DPB size limitation, and it proved to be true when 1920x864p worked with num_ref_frames = 5. I have since updated the Cyberlink decoder to the latest PowerDVD release (7.3.3516) on my box with the Nvidia 8800GT, and all of the L4.1-compliant files then worked with DXVA.

I have not tested 480p or 576p.

tetsuo55

6th January 2008, 12:06

UsedUser and CruNcher, What settings and players do you use to have DXVA in mkv files? and ar eyou guys using XP(i am)?

CruNcher

6th January 2008, 12:40

Yes windows XP Cyberlinks Decoder and Mplayer Home Cinema Classic for now VMR9 Windowed but i changed from a 7600 GS and still have to check the render changes (if their any) before the nicest was VMR9 Renderless running in the 3D Exclusive Fullscreen mode (ZoomPlayer has this too and can change dynamicly between it and Windowed) it gave the lesst jitter and absolute smooth playback with full Hardware Accelleration of VP1 :). But useing Haalis Splitter without changeing the Level_idc isn't recomended as it takes it into account and can then couse the aformentioned 20 fps or frame stuttering and in the evilst case Black Screen problems (Black Screen only with the Standard renderer (VMR7) with VMR9 you gonna see the first frame and no playback).
Best overall Expierience i currently make with Cyberlinks Player itself, but only because of the fact that it can play DVD,HD-DVD and Blu-Ray has no Menu Problems (there are some HD-DVD Menu problems with ACA content still but they slowly fix them) no Subtitle Problems (some other Player can't hold Hardware Accelleration when displaying subtitles) and all Accellerated and with Nvidias superb Motion Adaptive Deinterlacing if needed. So full Realtime 1920x1080 30i->1920x1080 60p conversion in a Quality that only the best Avisynth stuff can reach nowdays but that much much much much faster it's 1 step better quality then Yadif, so yes you could say it's MCBOB with NNEDI in Realtime (not quiet at least i didn't compared it yet against it or ATIs Deinterlacer) and that all together with the posibility to play most File Formats (and even HD-DVD and Blu-rays for testing from HDD little modification here ;) ) , where i still working on to get it to play even more, as soon as i achived that it will be my prefered player for this time being under Windows ;)

Im currently testing the 8800GT G92 (interoperability HD-DVD, Blu-Ray and DVB-S2 playback) already tested it's Gaming capabilities later im gonna test the new RV670 and finaly compare both against each other :) all the results of this you can read here http://www.forum-3dcenter.org/vbulletin/showthread.php?p=6152250, it's in German im constantly updateing it with results in all areas.

akupenguin

6th January 2008, 15:06

The new option needed is something to specify DPB size, and just let each frame use as many refs as possible within that constraint. Or I can repurpose --ref to do that: the current method was chosen because direct=temporal benefits from having the same number of L0 refs in all frames, but since direct=spatial is usually better anyway, it's no longer necessary.
patch (http://akuvian.org/src/x264/x264_ref_dpb.0.diff). That was easy, now tell me whether it worked.

What should happen (untested):

before:
-r1 -b0: dpb=1, P-frames use 1 refs
-r4 -b0: dpb=4, P-frames use 4 refs
-r1 -b#: dpb=2, P-frames use 1 refs, B-frames use 1/1 refs
-r4 -b#: dpb=5, P-frames use 4 refs, B-frames use 4/1 refs
-r1 -b# --b-pyramid: dpb=4, P-frames use 1 refs, B-refs use 1/1 refs, B-frames use 1/2 refs
-r4 -b# --b-pyramid: dpb=7, P-frames use 4 refs, B-refs use 4/1 refs, B-frames use 4/2 refs

after:
-r1 -b0: dpb=1, P-frames use 1 refs
-r4 -b0: dpb=4, P-frames use 4 refs
-r1 -b#: dpb=2, P-frames use 1 refs, B-frames use 1/1 refs
-r4 -b#: dpb=4, P-frames use 4 refs, B-frames use 3/1 refs
-r1 -b# --b-pyramid: dpb=3, P-frames use 1 refs, B-refs use 1/1 refs, B-frames use 1/2 refs
-r4 -b# --b-pyramid: dpb=4, P-frames use 4 refs, B-refs use 3/1 refs, B-frames use 2/2 refs

foxyshadis

6th January 2008, 15:09

You are probably right that they (accidentaly?) never go over the ref frames limit for the used resolutions

Cruncher did say that there were some block errors. What this means is that the high reference frames are being dropped and blocks referencing them broken, but decoders are much more robust than their anal level-checking gives them credit for. Given the relative distribution of high-ref frames, you could probably relevel even a 16-ref 1080p file and still see only mild artifacting.

UsedUser

7th January 2008, 00:15

UsedUser and CruNcher, What settings and players do you use to have DXVA in mkv files? and ar eyou guys using XP(i am)?
WinXP, ZoomPlayer using Overlay, MPC HC using VMR9 with 3D surfaces, Cyberlink decoder with Haali splitter. One box had an ATI HD2600 (and I'm currently waiting for a replacement) and another has an Nvidia 8800GT.

UsedUser

7th January 2008, 00:27

But useing Haalis Splitter without changeing the Level_idc isn't recomended as it takes it into account and can then couse the aformentioned 20 fps or frame stuttering and in the evilst case Black Screen problems (Black Screen only with the Standard renderer (VMR7) with VMR9 you gonna see the first frame and no playback).
It's not Haali's splitter at fault!

The level_idc is (also) checked by Cyberlink's decoder, as the raw AVC streams without a container exhibit the same stutter symptoms when level_idc is set higher than L4.1, and the same black screen when num_ref_frames is higher than L4.1.

UsedUser

7th January 2008, 00:36

CruNcher

7th January 2008, 01:05

patch (http://akuvian.org/src/x264/x264_ref_dpb.0.diff). That was easy, now tell me whether it worked.

What should happen (untested):

before:
-r1 -b0: dpb=1, P-frames use 1 refs
-r4 -b0: dpb=4, P-frames use 4 refs
-r1 -b#: dpb=2, P-frames use 1 refs, B-frames use 1/1 refs
-r4 -b#: dpb=5, P-frames use 4 refs, B-frames use 4/1 refs
-r1 -b# --b-pyramid: dpb=4, P-frames use 1 refs, B-refs use 1/1 refs, B-frames use 1/2 refs
-r4 -b# --b-pyramid: dpb=7, P-frames use 4 refs, B-refs use 4/1 refs, B-frames use 4/2 refs

after:
-r1 -b0: dpb=1, P-frames use 1 refs
-r4 -b0: dpb=4, P-frames use 4 refs
-r1 -b#: dpb=2, P-frames use 1 refs, B-frames use 1/1 refs
-r4 -b#: dpb=4, P-frames use 4 refs, B-frames use 3/1 refs
-r1 -b# --b-pyramid: dpb=3, P-frames use 1 refs, B-refs use 1/1 refs, B-frames use 1/2 refs
-r4 -b# --b-pyramid: dpb=4, P-frames use 4 refs, B-refs use 3/1 refs, B-frames use 2/2 refs

yep it works now
-r4 -b#: dpb=5, P-frames use 4 refs, B-frames use 4/1 refs
-r4 -b# --b-pyramid: dpb=7, P-frames use 4 refs, B-refs use 4/1 refs, B-frames use 4/2 refs

those 2 didn't work before the dbp 5 showed heavy frame errors and the dbp 7 didnt play @ all, now both work with dbp being 4 :)

Aku what do you think about a new parameter something like --hardware --sapc --forcesapc --hdc wich if used then forces num_ref_frame for the different resolutions :) this way then GUI devs could easily use it when the user want's a more strict Level of Hardware Decoder Compatibility (i think it would even make sense to bundle pictiming,aud,globalheader and hrd under this parameter) :) based on this list maybe ? http://www.avsforum.com/avs-vb/showpost.php?p=12704376&postcount=3898 or a even a easier way just allways allow 4 as maximum if --hdc is set, so if someone is so crazy and does --ref 15 if --hdc is set just ignore it and set it to 4 instead :d *hides*

I'll have to wait until a build is available to test. I'm not set up to build. Anyone able to do this?

Here is the Patched Build http://rapidshare.com/files/81854634/x264-dpb.exe

CruNcher

7th January 2008, 01:08

It's not Haali's splitter at fault!

The level_idc is (also) checked by Cyberlink's decoder, as the raw AVC streams without a container exhibit the same stutter symptoms when level_idc is set higher than L4.1, and the same black screen when num_ref_frames is higher than L4.1.

Yes but Level is not of importance try 5.1 in Bitstream in Cyberlink it will play then try that with Haalis Splitter and Cyberlink Decoder (MP4/MKV) and it won't play @ all with level_idc being 5.1.
Cyberlinks Framework doesn't check for the level_idc at least it doesn't result in a black screen like with Haalis Splitter if the Bitstream signals 5.1 but yes it indeed still shows stuttering (B-frame sequences) if the Level is wrong i wrote that some pages up allready (aku wished me even good luck finding the cause of this).
So the Black Screen with Haalis Splitter could also have another source im not sure the only thing i know is that black screens even with wrong signaled Bitstreams (5.1) can be avoided useing Mainconcepts Mp4 Demultiplexer and Cyberlinks Decoder with "Annex B output for AVC/H.264" checked, this input Cyberlinks Decoder accepts even if the Bitstreams level_idc is 5.1 it doesn't show a Black Screen in this combination, but it does with Haalis Splitter if the level_idc is 5.1 and it's not of interest what the num_ref_frame is level 5.1 is enough to cause a black screen.

So for everyone now, if the level_idc flag of a encoded Bitstream is 5.1 and you mux that into MP4 or MKV and try to playback it useing Haalis Splitter in combination with Cyberlinks Decoder with Hardware Accelleration Enabled the following will happen with VMR7 you gonna see a Black Screen with VMR9 you gonna see the first frame of the file and for both you would just see the slider moving but the time stays on 000000 so no Playback is happening, i hope now you understand what i mean.

UsedUser

7th January 2008, 03:33

Yes but Level is not of importance try 5.1 in Bitstream in Cyberlink it will play then try that with Haalis Splitter and Cyberlink Decoder (MP4/MKV) and it won't play @ all with level_idc being 5.1.

...

So for everyone now, if the level_idc flag of a encoded Bitstream is 5.1 and you mux that into MP4 or MKV and try to playback it useing Haalis Splitter in combination with Cyberlinks Decoder with Hardware Accelleration Enabled the following will happen with VMR7 you gonna see a Black Screen with VMR9 you gonna see the first frame of the file and for both you would just see the slider moving but the time stays on 000000 so no Playback is happening, i hope now you understand what i mean.
No, that's not what I've found at all.

As I've been saying over and over, the actual level of the stream determines DXVA playback, and the level_idc value determines smooth playback. I have found this is true no matter the container (no container, MP4, MKV), no matter the splitter (Haali's, Nero's, no splitter for raw AVC), and no matter the video renderer (VMR7, VMR9 Windowless/Renderless, Overlay).

There are three scenarios:

Stream is L5.1 (exceeds L4.1 DPB size), level_idc = L5.1
Result: No DXVA, black or gray screen

Stream is L4.1 (within L4.1 DPB size), level_idc = L5.1
Result: DXVA, but stuttering or 20fps playback

Stream is L4.1 (within L4.1 DPB size), level_idc = L4.1
Result: DXVA and smooth playback

UsedUser

7th January 2008, 05:07

I'll have to wait until a build is available to test. I'm not set up to build. Anyone able to do this?

Question:

According to your first post, I thought --ref would set DPB size, but obviously with --ref 1, it's not doing that with your patch. Is --ref 1 a special case?
I got my build environment updated and compiled my own build with the DPB patch.

As CruNcher confirmed, it appears the patch works as intended.

I tested the following @ 1080p:

-r4 -b#: dpb=4
-r4 -b# --b-pyramid: dpb=4

DXVA worked for both, but I saw block corruption with B-pyramids.

I also tested the following @ 720p:

-r9 -b#: dpb=9
-r9 -b# --b-pyramid: dpb=4

DXVA worked, but I saw block errors with both. If what foxyshadis said is true, having a DPB size close to the limit is causing the references to be dropped.

I went back and looked at the 720p clips I tested with the svn-709 build as well, and those clips with DPB=9 show block errors, too. The clips are:

-r6 -b# --b-pyramid: dpb=9
-r8 -b#: dpb=9
-r9 -b0: dpb=9

The clips that don't show any errors:

-r6 -b#: dpb=7
-r7 -b#: dpb=8

So, for whatever reason, to ensure good DXVA compatibility, it's still best to stay away from B-pyramids, and to keep DPB<5 for any resolution.

UsedUser

7th January 2008, 05:42

I tested clips at 480p and 576p on my Nvidia 8800GT (G92 decoder).

They worked with DXVA at L4.1, L4.0, L3.2 settings, but showed choppy playback and/or block errors.

My test methodology was to keep the DPB size within L4.1, which at either 480p or 576p allows DPB=16. Then I dropped the level_idc tag from 4.1 to 4.0 to 3.2 to 3.1, looking to see if the L4.1 streams could be decoded smoothly if the level_idc was lower. This demonstrated that the stream itself has to have DPB size within L3.1.

I then encoded 480p and 576p streams at their L3.1 DPB size limits, with the level_idc set at 4.1. DXVA worked, but as with the L4.1 streams with a level_idc of 5.1, playback was choppy with the level_idc set too high. This showed the level_idc needs to be L3.1.

For 480p and 576p, the DPB size needs to stay within L3.1, and the level_idc needs to be L3.1 for smooth playback.

The bottom line overall seems to be that streams need to comply with and declare L4.1 for HD and L3.1 for SD.

The following SD streams had smooth playback with DXVA:

480p, ref=13, bframes=3, DPB=13, level_idc=3.1
576p, ref=11, bframes=3, DPB=11, level_idc=3.1

The following SD streams had choppy playback with DXVA:

480p, ref=16, bframes=16, b-pyramid=on, DPB=16, level_idc=4.1
480p, ref=16, bframes=16, DPB=16, level_idc=4.1
480p, ref=16, bframes=16, DPB=16, level_idc=4.0
480p, ref=16, bframes=16, DPB=16, level_idc=3.2
480p, ref=16, bframes=16, DPB=16, level_idc=3.1
480p, ref=13, bframes=3, DPB=13, level_idc=4.1

576p, ref=16, bframes=16, b-pyramid=on, DPB=16, level_idc=4.1
576p, ref=16, bframes=16, DPB=16, level_idc=4.1
576p, ref=16, bframes=16, DPB=16, level_idc=4.0
576p, ref=16, bframes=16, DPB=16, level_idc=3.2
576p, ref=16, bframes=16, DPB=16, level_idc=3.1
576p, ref=11, bframes=3, DPB=11, level_idc=4.1

akupenguin

7th January 2008, 07:30

DXVA worked for both, but I saw block corruption with B-pyramids.
Next question: what is it about pyramid that your card didn't like?

Experiment 1: Conventional frame order but with B-refs. Apply this patch (http://akuvian.org/src/x264/x264_dxva_pyramid_experiment_all-bref.diff) and encode without pyramid.

Experiment 2: Pyramid order but no B-refs. Apply this patch (http://akuvian.org/src/x264/x264_dxva_pyramid_experiment_no-bref.diff) and encode with pyramid.

Experiment 3: Only a single L1 ref. Apply this patch (http://akuvian.org/src/x264/x264_dxva_pyramid_experiment_no-L1.diff) and encode with pyramid.

All patches should be applied on top of the DPB patch (but not on top of each other).

UsedUser

7th January 2008, 09:35

Experiment 1: Conventional frame order but with B-refs. Apply this patch (http://akuvian.org/src/x264/x264_dxva_pyramid_experiment_all-bref.diff) and encode without pyramid.
FYI - this patch compiled successfully, but the encoder crashes on the first pass. I don't have the time to look into it immediately.

Experiment 2: Pyramid order but no B-refs. Apply this patch (http://akuvian.org/src/x264/x264_dxva_pyramid_experiment_no-bref.diff) and encode with pyramid.
Update: 1080p has no block errors with DPB=4; 720p continues to have block errors with DPB=9.

Experiment 3: Only a single L1 ref. Apply this patch (http://akuvian.org/src/x264/x264_dxva_pyramid_experiment_no-L1.diff) and encode with pyramid.
1080p may have block errors with DPB=4. It's difficult to tell if it's just visible macroblocking because it was difficult to encode, as the blocks only appear in one portion of the clip. I need to test some other clips.
Update: After more testing, I have determined it was not block errors I saw, but macroblocking on a difficult-to-encode segment. Other clips appear ok. Maybe macroblocking and block errors are essentially the same thing, but when I see errors, it doesn't look like regular, old "pixelation".

720p has block errors with DPB=9.

CruNcher

7th January 2008, 12:22

I got my build environment updated and compiled my own build with the DPB patch.

As CruNcher confirmed, it appears the patch works as intended.

I tested the following @ 1080p:

-r4 -b#: dpb=4
-r4 -b# --b-pyramid: dpb=4

DXVA worked for both, but I saw block corruption with B-pyramids.

I also tested the following @ 720p:

-r9 -b#: dpb=9
-r9 -b# --b-pyramid: dpb=4

DXVA worked, but I saw block errors with both. If what foxyshadis said is true, having a DPB size close to the limit is causing the references to be dropped.

I went back and looked at the 720p clips I tested with the svn-709 build as well, and those clips with DPB=9 show block errors, too. The clips are:

-r6 -b# --b-pyramid: dpb=9
-r8 -b#: dpb=9
-r9 -b0: dpb=9

The clips that don't show any errors:

-r6 -b#: dpb=7
-r7 -b#: dpb=8

So, for whatever reason, to ensure good DXVA compatibility, it's still best to stay away from B-pyramids, and to keep DPB<5 for any resolution.

i tested the 1 patch with CRF so far and i had no problems with b-pyramid at all in 1920x1080, strange i try more different combinations later on block errors i only had so far if the num_ref_frame wasn't identical with the encoded value and frame errors only if the level_idc flag was to low and the complexity of the stream to high for the signaled level.
i try 720p later on and yes you right it's not haalis splitter i checked it again it seems to be as you said a combination of both wrong level for wrong num_ref_frame :)

akupenguin

7th January 2008, 13:08

FYI - this patch compiled successfully, but the encoder crashes on the first pass. I don't have the time to look into it immediately.
Oops, you need to encode with at least as many refs as B-frames, otherwise some of the B-frames won't have any future ref.

I'm also interested in how the 3 experiments fare when not stressing the DPB. So try each with "-r2 -b2" and "-r3 -b3".

UsedUser

7th January 2008, 13:20

Oops, you need to encode with at least as many refs as B-frames, otherwise some of the B-frames won't have any future ref.
Hmm... I am using more refs than b-frames. Just checked again to verify, and the encoder still crashes. I'm using the following without b-pyramid:

1080p:
--ref 4 --bframes 3 --b-adapt

720p:
--ref 9 --bframes 3 --b-adapt

Using equal amounts or more b-frames than refs also crashed.

Nil Einne

7th January 2008, 14:04

What's the point of encoding cartoons with 16ref and not be able to watch them on PS3/X360 or PC with hardware acceleration? In this case I choose compatibility over small increase in quality.

Um if you don't have a PS2/X360 and don't intend to play in one, why would you give a damn what they can or can't do?

CruNcher

7th January 2008, 15:24

@Nil Einne
Interoperability allways comes with a drawback, but it allways should be prefered to keep it, this way you can avoid alot of problems in General, especialy for stuff that is based on a Standard and alot of people just wan't (includeing myself) that you have 1 Bitstream that plays everywhere if it's Standard Complaint (no transcoding no anything just take the bitstream and go wherever you want) :). The Next Problem for example is Apples Quicktime it's allready a defacto Standard itself (aside of the Real AVC/H.264 Standard) and it uses much less complexity (at least what Quicktime Player supports and so many are forced to support) and so we have another Problem keeping the Bitstream interoperable with that (sure it's easier to install Mplayer or VLC on a Mac and forget about that Problems, but sadly that's not the way it works), all this is really a Devils Circle. So even people like me that love interoperability need to make decissions, but at least you should try to hold them as low as possible and so HD-DVD and Blu-Ray seem a perfect balanced solution forgeting about Apple Quicktime wich can't deliver that and is really only usable for low complexity encoding (and seeing the rapid development of Hardware solutions it makes no sense anymore to stay that low complex all the time and loseing efficiency). But even if it sounds that easy it isn't that easy. Open Source can provide better Standard Complaint solutions (if some Companies don't want it or doing it wrong) for the User and so improve interoperability that way, but makeing that known to the users i think is the main problem here (and to deliver it in the easiest way possible). Implementing this what we talk about here now successfully means X264 is gonna reach more happy users in the end and for sure it also means alot more attention from different angles :). And exactly those Problems are those that give WMV and Microsoft VC-1 more and more momentum currently and Apple for example really does the wrong thing in many users eyes, but how much quality really goes lost with Apples setting ? and how Visualy relizeable ist that ?, those are questions i try to answer myself currently also. I think a dramaticly change of that Situation is gonna arrive if DivX Inc is gonna present DivX Q together with Mainconcept/Elecard that is gonna to get a new guide for many in the industry and will push H.264/AVC far ahead in fron't of WMV and finaly also force Apple to react (we could also achive the same now, it doesn't need to be a company as DivX Inc to be behind this, never forget where the roots of this company are). But it shouldn't be the Goal in the end to achive that with H.264/AVC (XviD 2.0 AVC or X264) we have to push other stuff and forget about those properiartary things (it's a nice thing to excercise and learn from it anyways in every possible perspective) :)

The nice thing is we have a battle going on here mostly between Microsoft (VC-1) and Sony (AVC) and when 2 parties have a War it's easier for a 3rd party to enter the Stage and get momentum (with more inovative stuff that the user are gonna use and love and then it doesn't matter where that's coming from) ;)

tetsuo55

7th January 2008, 15:26

Um if you don't have a PS2/X360 and don't intend to play in one, why would you give a damn what they can or can't do?

Lets say you have this movie, and you transcode that movie with x264, and then take the disc to a friend, who only has a xbox360, the file would have to be compatible with the xbox 360 in order to work.

I have encountered this problemen quite a few times (most people i know seem to have wildly different setups of video plaback hardware @_@)

Also i think the programmers of x264 would like for their program to be as compatible as possible with all the playback solutions, as this would lead to more users of the program.

audyovydeo

7th January 2008, 15:31

Um if you don't have a PS2/X360 and don't intend to play in one, why would you give a damn what they can or can't do?

Hello ? Don't forget this thread's title :

"x264 + more than 4 ref frames = no DXVA or 20fps bug (ati avivo, nvidia purevideo)"

so everyone who's hoping to get their video card to do what it's marketed to do ought to be interested.

cheers
audyovydeo

tetsuo55

7th January 2008, 18:09

UsedUser

8th January 2008, 03:33

So what would you advice for best overal settings for 720x(any)?
A safe value for 720x(720 or less) would be DPB=8.

Or de they have to be split up in 720x576 and 720x480?
Also would these settings still be valid for the no black space resolutions like.

640x352
608x256
592x448
720x544
640x360
My personal preference, I would use the PS3 profile without B-pyramid for everything. That would result in DPB=3, no matter the resolution.

If I was feeling lucky, I might push up to DPB=5, but that's it. The quality / encoding time balance is good for me right about there. The Ateme encoder in Nero Digital maxes out at 3-5 DPB as well.

I think I've finally arrived at set-it-and-forget options with the PS3 profile sans B-pyramid.

valnar

8th January 2008, 03:56

My personal preference, I would use the PS3 profile without B-pyramid for everything. That would result in DPB=3, no matter the resolution.

But what about this?
The bottom line overall seems to be that streams need to comply with and declare L4.1 for HD and L3.1 for SD.

I've made two profiles just in case - one for SD/DVD and one for HD. The difference is the Level and vbv-maxrate.

I also use CRF instead.

--pass 1 --crf 20 --stats ".stats" --progress --keyint 250 --bframes 3 --qpmin 10 --qpmax 51 --mixed-refs --trellis 1 --ref 3 --filter -2,-1 --subme 6 --direct auto --vbv-maxrate 14000 --me umh --level 4.1 --merange 12 --weightb --b-rdo --bime --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --threads auto --thread-input --no-dct-decimate

-Robert

Sharktooth

8th January 2008, 04:27

Q: would you like to have "DXVA friendly" profiles based on your findings in MeGUI?

UsedUser

8th January 2008, 04:46

Oops, you need to encode with at least as many refs as B-frames, otherwise some of the B-frames won't have any future ref.
-r2 -b2 --no-b-adapt worked. -r3 -b3 --no-b-adapt still doesn't work.

I'm also interested in how the 3 experiments fare when not stressing the DPB. So try each with "-r2 -b2" and "-r3 -b3".
--b-adapt on or off?

UsedUser

8th January 2008, 04:55

Q: would you like to have "DXVA friendly" profiles based on your findings in MeGUI?
It would be great.

My vote would be to have a DXVA-HD profile: PS3 settings, except without B-pyramid; and a DXVA-SD profile: PS3 settings, except without B-pyramid and with --level 3.1.

Though, since we're still working out B-frame issues with B-pyramid, maybe we should wait until the finished patches get into the code.

tetsuo55

8th January 2008, 10:49

Q: would you like to have "DXVA friendly" profiles based on your findings in MeGUI?

It would be great.

My vote would be to have a DXVA-HD profile: PS3 settings, except without B-pyramid; and a DXVA-SD profile: PS3 settings, except without B-pyramid and with --level 3.1.

Though, since we're still working out B-frame issues with B-pyramid, maybe we should wait until the finished patches get into the code.

i think UsedUser is right, we should have it all figured out, and (if needed) x264 should be updated before the gui's

akupenguin

8th January 2008, 11:30

--b-adapt on or off?
If b-adapt has anything to do with compatibility, the decoder is much more crippled than I thought.

shon3i

8th January 2008, 16:02

I found this profiles in Elecard Converter Studio 2.0, and i think will be usefull here

"BluRay SD AVC", resolution if not will be automaticly resized to 720x576 and aspet ratio can be changed, and profile have this options

http://img229.imageshack.us/img229/1678/bluraysd1at2.jpg
http://img229.imageshack.us/img229/7814/bluraysd2bi9.jpg
http://img229.imageshack.us/img229/515/bluraysd3br6.jpg

"BluRay HD AVC", resolution if not will be automaticly resized to 1920x1080 and aspet ratio can be changed, and profile have this options

http://img229.imageshack.us/img229/1048/blurayhd1dj9.jpg
http://img70.imageshack.us/img70/3497/blurayhd2av1.jpg
http://img518.imageshack.us/img518/1059/blurayhd3jc7.jpg

And aslo i found some interesting thing in both, ateme and elecard/mainconcept's documentation for AVC encoders, to use MV Range of 255 for SD and 511 for HD.

Manao

9th January 2008, 12:52

ateme and elecard/mainconcept's documentation for AVC encoders, to use MV Range of 255 for SD and 511 for HDMV Range is given by the level, not by the encoder. And there seem to be a typo in Elecard Converter Studio 2.0, since level 3.2 has a MV range of 511, not 255.

akupenguin

9th January 2008, 13:15

MV Range is limited by level, but the encoder is free to pick a smaller value, and may or may not specify the value it picked in the VUI header.

CruNcher

10th January 2008, 14:49

NVIDIA GeForce 8800 GT
ModeMPEG2_IDCT: [NV12] 720x480 / 1280x720 / 1920x1080
ModeVC1_IDCT: [NV12] 720x480 / 1280x720 / 1920x1080
ModeWMV9_IDCT: [NV12] 720x480 / 1280x720 / 1920x1080
ModeVC1_MoComp: [NV12] 720x480 / 1280x720 / 1920x1080
ModeWMV9_MoComp: [NV12] 720x480 / 1280x720 / 1920x1080
ModeVC1_PostProc: [NV12] 720x480 / 1280x720 / 1920x1080
ModeWMV9_PostProc: [NV12] 720x480 / 1280x720 / 1920x1080
1720AC81-9D1B-4F63-9A37-4A88483D0B87: [NV12]
ModeH264_VLD_NoFGT: [NV12]

AVC/H.264:

ffdshow Video Decoder
Unknown

MainConcept AVC/H.264 Video Decoder [avc1 1920x1080]
Unsupported

CyberLink H.264/AVC Decoder (PDVD7.x) [avc1 1920x1080]
ModeH264_VLD_NoFGT(*)
ModeH264_VLD_FGT
ModeH264_MoComp_PureVideo
NV12 (ModeH264_MoComp_NoFGT)
ModeH264_MoComp_Avivo
ModeMPEG2_IDCT

Nero DVD Decoder [avc1 1920x1080]
ModeH264_MoComp_PureVideo
ModeH264_MoComp_Avivo
GUID_NULL

Nero Video Decoder [avc1 1920x1080]
ModeH264_MoComp_PureVideo
ModeH264_MoComp_Avivo
GUID_NULL

CoreAVC Video Decoder [avc1 1920x1080]
Unsupported

MPEG-2:

fdshow Video Decoder
Unknown

Elecard MPEG-2 Video Decoder [MPEG2 1920x1080]
ModeMPEG2_B
ModeMPEG2_D(*)
ModeMPEG2_A
ModeMPEG2_C

MainConcept MPEG-2 Video Decoder [MPEG2 1920x1080]
ModeMPEG2_B
ModeMPEG2_D(*)
ModeMPEG2_A
ModeMPEG2_C

CyberLink Video/SP Decoder (PDVD7) [MPEG2 1920x1080]
ModeMPEG2_VLD
ModeMPEG2_D
ModeMPEG2_B
ModeMPEG2_C(*)
ModeMPEG2_A

Nero DVD Decoder [MPEG2 1920x1080]
ModeMPEG2_D
ModeMPEG2_C
ModeMPEG2_B
ModeMPEG2_A

Nero Video Decoder [MPEG2 1920x1080]
ModeMPEG2_D
ModeMPEG2_C
ModeMPEG2_B
ModeMPEG2_A

ArcSoft MPEG Video Decoder [MPEG2 1920x1080]
Unsupported

Sonic Cinemaster® VideoDecoder 4.1 [MPEG2 1920x1080]
None

ArcSoft Video Decoder [MPEG2 1920x1080]
ModeMPEG2_D(*)
ModeMPEG2_C
ModeMPEG2_B
ModeMPEG2_A

CyberLink Video/SP BD-HD Decoder (PDVD7.x)
Unknown

ArcSoft DVD Video Decoder
Unknown

VC-1:

ffdshow Video Decoder
Unknown

MainConcept VC-1 Decoder [WVC1 1920x1080]
Unsupported

WMVideo Decoder DMO [WVC1 1920x1080]
ModeVC1_IDCT(*)
ModeVC1_MoComp
ModeVC1_PostProc

Nero DVD Decoder [WVC1 1920x1080]
GUID_NULL

Nero Video Decoder [WVC1 1920x1080]
GUID_NULL

Sonic Cinemaster® VideoDecoder 4.1 [WVC1 1920x1080]
None

This http://bluesky23.hp.infoseek.co.jp/DXVAChecker_1401.zip is a cool programm it analyzes the Dshow filter it's DXVA capabilities and even shows the use of the PureVideo or Avivo API :)
You can also find Parser/Decoder problems that way :)

shon3i

15th January 2008, 16:57

I tested with one HD and one SD resolution.

HD - 1920x1080 - Elecard Conveter Studio 2.0 - Blurray HD AVC profile - 23.976 fps - decodes smoothly in mkv container with DTS audio, no errors.

SD - 720x432 - Elecard Conveter Studio 2.0 - Blurray SD AVC profile - 25.000fps - still have 20fps bug

SD - 720x576 - Elecard Conveter Studio 2.0 - Blurray SD AVC profile - 25.000fps - Everything is fine.

Looks like for SD, resoultion must be 720x576 or 852x480.

EDIT: Did is somebody make Elecard/Mainconcept H264 to decode with HW acceleration?

Sharktooth

15th January 2008, 17:18

Though, since we're still working out B-frame issues with B-pyramid, maybe we should wait until the finished patches get into the code.
Yes, sure, im only asking that coz i will completely re-organize the profiles.

tetsuo55

16th January 2008, 18:45

Any news on the "B-frame issues with B-pyramid"

And shon3i

What level did you select for this one?

SD - 720x432 - Elecard Conveter Studio 2.0 - Blurray SD AVC profile - 25.000fps - still have 20fps bug

bob0r

16th January 2008, 18:50

...

This http://bluesky23.hp.infoseek.co.jp/DXVAChecker_1401.zip is a cool programm it analyzes the Dshow filter it's DXVA capabilities and even shows the use of the PureVideo or Avivo API :)
You can also find Parser/Decoder problems that way :)

This fine is 404, can you upload it somewhere?

TheShadowRunner

16th January 2008, 19:11

Try this :
http://bluesky23.hp.infoseek.co.jp/DXVAChecker_1501.zip
requires .NET 3 (arg)

shon3i

16th January 2008, 19:54

And shon3i

What level did you select for this one?

SD - 720x432 - Elecard Conveter Studio 2.0 - Blurray SD AVC profile - 25.000fps - still have 20fps bugI tryed with 3.2 and 4.1. I doing some testing right now, to see what problem can be.

CruNcher

16th January 2008, 23:07

Also be carefull wrong --sar can also result in Black Screens geez

karspen1

17th January 2008, 23:19

I'm benchmarking gpu dxva performance right now (working at a computer magazine). Do anyone know a (free) high bitrate h.264 sample video that is verified to work with DXVA enabled? Using Cyberlink right now and a having great trouble just to get rid of the dreaded "black screen".

shon3i

18th January 2008, 01:21

TheShadowRunner

18th January 2008, 06:22

this too:
http://www.apple.com/quicktime/guide/hd/
check BBC Japan & BBC Life in the blue.
They work perfect with DXVA and are quite complex encodes (Japan especially).
Later,

TSR

tetsuo55

18th January 2008, 17:13

Q: would you like to have "DXVA friendly" profiles based on your findings in MeGUI?

With the commit of the DPB patch, b-refs and b-pyramids can be maxed out (see here http://forum.doom9.org/showpost.php?p=1088556&postcount=4)

So using the settings form this thread + b-pyramids should result in the best encode:

http://www.avsforum.com/avs-vb/showthread.php?t=972503

Unless anyone finds any problems with the newest x264 and the settings from that thread + b-pyramids than this should now be added to the frontends

shon3i

18th January 2008, 19:29

Like CruNcher says, aslo wrong SAR settings can make 20fps bug or black screen. I have trouble with anamorphic encode 720x576 and signaled with sar 16:11 for pal DVD which equals DAR 16:9, during playback video isn't played smoothly. Looks like sar 1:1 best solution.

valnar

18th January 2008, 19:31

akupenguin

18th January 2008, 21:38

So using the settings form this thread + b-pyramids should result in the best encode:
http://www.avsforum.com/avs-vb/showthread.php?t=972503

Not quite. Not only pyramid was improved, conventional B-frames also used to count against refs. So increment ref compared to that thread.

Do we really need B-pyramids? Even if it works now, I still vote against it.
And you want to sacrifice some compression ratio just because ...?

Sagekilla

19th January 2008, 00:04

Not quite. Not only pyramid was improved, conventional B-frames also used to count against refs. So increment ref compared to that thread.

And you want to sacrifice some compression ratio just because ...?

Agreed.. It sounds like a step backwards to completely remove b pyramids, and I've seen sizeable benefits from using it.

UsedUser

20th January 2008, 08:11

With the commit of the DPB patch, b-refs and b-pyramids can be maxed out (see here http://forum.doom9.org/showpost.php?p=1088556&postcount=4)

So using the settings form this thread + b-pyramids should result in the best encode:

http://www.avsforum.com/avs-vb/showthread.php?t=972503

Unless anyone finds any problems with the newest x264 and the settings from that thread + b-pyramids than this should now be added to the frontends

Not quite. Not only pyramid was improved, conventional B-frames also used to count against refs. So increment ref compared to that thread.

And you want to sacrifice some compression ratio just because ...?
I did some testing with svn-721. B-pyramid is still causing corruption (block errors?), even if the DPB isn't maxed out for L4.1:

1080p DXVA without corruption:
DPB=4: --ref 4 --bframes 3
DPB=3: --ref 3 --bframes 3

1080p DXVA with corruption:
DPB=4: --ref 4 --bframes 3 --b-pyramid
DPB=3: --ref 3 --bframes 3 --b-pyramid

UsedUser

20th January 2008, 08:43

@akupenguin

Just to tidy up, here are all my results from your patch experiments.

No corruption @ 1080p:
2 Ref 2 Bfr B-Pyramid No B-Adapt svn-717M-ref_dpb-dxva_pyramid_experiment_no-bref
3 Ref 3 Bfr B-Pyramid No B-Adapt svn-717M-ref_dpb-dxva_pyramid_experiment_no-bref
4 Ref 3 Bfr B-Pyramid svn-717M-ref_dpb-dxva_pyramid_experiment_no-bref
4 Ref 3 Bfr B-Pyramid Clip2 svn-717M-ref_dpb-dxva_pyramid_experiment_no-L1

Corruption @ 1080p:
2 Ref 2 Bfr No B-Pyramid No B-Adapt svn-717M-ref_dpb-dxva_pyramid_experiment_all-bref

Maybe corruption, maybe just macroblocking on a difficult-to-encode clip @ 1080p:
2 Ref 2 Bfr B-Pyramid No B-Adapt svn-717M-ref_dpb-dxva_pyramid_experiment_no-L1
3 Ref 3 Bfr B-Pyramid No B-Adapt svn-717M-ref_dpb-dxva_pyramid_experiment_no-L1
4 Ref 3 Bfr B-Pyramid svn-717M-ref_dpb-dxva_pyramid_experiment_no-L1

No Corruption @ 720p:
8 Ref 3 Bfr B-Pyramid svn-717M-ref_dpb-dxva_pyramid_experiment_no-bref
7 Ref 3 Bfr B-Pyramid svn-717M-ref_dpb-dxva_pyramid_experiment_no-bref

Maybe corruption, maybe just macroblocking on a difficult-to-encode clip @ 720p:
8 Ref 3 Bfr B-Pyramid svn-717M-ref_dpb-dxva_pyramid_experiment_no-L1

Corruption @ 720p:
9 Ref 3 Bfr B-Pyramid svn-717M-ref_dpb-dxva_pyramid_experiment_no-bref
9 Ref 3 Bfr B-Pyramid svn-717M-ref_dpb-dxva_pyramid_experiment_no-L1

akupenguin

20th January 2008, 08:56

I don't see any pattern in those results

UsedUser

20th January 2008, 09:46

I don't see any pattern in those results
Are there other combinations of encoding options you want tested?

It's up to you to interpret the results, but as best as I can gather:

no-bref: Successful at and below L4.1 limits, except when pushed to higher numbers of ref frames. I will do a few more 720p encodes to see what --ref value is allowable.

all-bref: Unsuccessful: x264 crashed on all encodes except -r2 -b2, where it showed corruption.

no-L1: Maybe successful: When I encoded "Clip2", which was easier to encode, I didn't see any corruption. So, whatever that patch changed likely just made quality suffer to the point that I saw really bad macroblocking on "Clip1". That macroblocking appeared with the no-L1 patch, but didn't appear on the same clip with the other patches.

I try to grab some screen caps to demonstrate the difference b/w what I'm calling "corruption" vs. "macroblocking". I don't understand enough to speak intelligently about it.

UsedUser

20th January 2008, 10:40

shon3i

20th January 2008, 11:37

UsedUser

20th January 2008, 11:58

Screen caps from my test encodes. Click the thumbnail for the full view.

First, comparisons of the patch experiments @ 1080p. Two screen shots [numbered] per clip.

no-bref (good results)
Good: [1] 1080p 2 Ref 2 Bfr B-Pyramid No B-Adapt svn-717M-ref_dpb-dxva_pyramid_experiment_no-bref
http://s63.photobucket.com/albums/h145/exdeus/x264/th_1080p2Ref2BfrB-PyramidNoB-Adaptsvn-.jpg (http://i63.photobucket.com/albums/h145/exdeus/x264/1080p2Ref2BfrB-PyramidNoB-Adaptsvn-.jpg)

Good: [2] 1080p 2 Ref 2 Bfr B-Pyramid No B-Adapt svn-717M-ref_dpb-dxva_pyramid_experiment_no-bref
http://s63.photobucket.com/albums/h145/exdeus/x264/th_1080p2Ref2BfrB-PyramidNoB-Adapts-1.jpg (http://i63.photobucket.com/albums/h145/exdeus/x264/1080p2Ref2BfrB-PyramidNoB-Adapts-1.jpg)

no-L1 (mixed results)
Some blocking: [1] 1080p 2 Ref 2 Bfr B-Pyramid No B-Adapt svn-717M-ref_dpb-dxva_pyramid_experiment_no-L1
This opening part of the test clip is when I see blocking with the no-L1 patch, then the rest of the clip plays without issue. The result for this encode is similar to the other no-L1 encodes. The blocking does not occur with a software decoder, so it is still something related to DXVA.
http://s63.photobucket.com/albums/h145/exdeus/x264/th_1080p2Ref2BfrB-PyramidNoB-Adapts-2.jpg (http://i63.photobucket.com/albums/h145/exdeus/x264/1080p2Ref2BfrB-PyramidNoB-Adapts-2.jpg)

Good: [2] 1080p 2 Ref 2 Bfr B-Pyramid No B-Adapt svn-717M-ref_dpb-dxva_pyramid_experiment_no-L1
http://s63.photobucket.com/albums/h145/exdeus/x264/th_1080p2Ref2BfrB-PyramidNoB-Adapts-3.jpg (http://i63.photobucket.com/albums/h145/exdeus/x264/1080p2Ref2BfrB-PyramidNoB-Adapts-3.jpg)

all-bref (poor results)
Blocking: [1] 1080p 2 Ref 2 Bfr No B-Pyramid No B-Adapt svn-717M-ref_dpb-dxva_pyramid_experiment_all-bref
http://s63.photobucket.com/albums/h145/exdeus/x264/th_1080p2Ref2BfrNoB-PyramidNoB-Adaptsv.jpg (http://i63.photobucket.com/albums/h145/exdeus/x264/1080p2Ref2BfrNoB-PyramidNoB-Adaptsv.jpg)

Blocking: [2] 1080p 2 Ref 2 Bfr No B-Pyramid No B-Adapt svn-717M-ref_dpb-dxva_pyramid_experiment_all-bref
http://s63.photobucket.com/albums/h145/exdeus/x264/th_1080p2Ref2BfrNoB-PyramidNoB-Adap-1.jpg (http://i63.photobucket.com/albums/h145/exdeus/x264/1080p2Ref2BfrNoB-PyramidNoB-Adap-1.jpg)

Next, a comparison of the no-bref patch experiment @ 720p. One screenshot from each clip.

Good: 720p 8 Ref 3 Bfr B-Pyramid svn-717M-ref_dpb-dxva_pyramid_experiment_no-bref
http://s63.photobucket.com/albums/h145/exdeus/x264/th_720p8Ref3BfrB-Pyramidsvn-717M-ref_d.jpg (http://i63.photobucket.com/albums/h145/exdeus/x264/720p8Ref3BfrB-Pyramidsvn-717M-ref_d.jpg)

Blocking: 720p 9 Ref 3 Bfr B-Pyramid svn-717M-ref_dpb-dxva_pyramid_experiment_no-bref
http://s63.photobucket.com/albums/h145/exdeus/x264/th_720p9Ref3BfrB-Pyramidsvn-717M-ref_d.jpg (http://i63.photobucket.com/albums/h145/exdeus/x264/720p9Ref3BfrB-Pyramidsvn-717M-ref_d.jpg)

Lastly, with the no-L1 patch, the DPB=9 clip blue-screened my PC twice when trying to capture in PowerDVD, so I gave up. You get the idea.

UsedUser

20th January 2008, 12:07

@UsedUser, how look that "block errors" in video, because i encode some 1080p, 720p, 576p clips with this settings translated to Elecard Converter Studio including b-pyramids, and i don't saw any problem with DXVA?
If you're using Elecard, then we're talking about completely different things.

I'm testing some experimental patches for x264. For each screen cap, I gave the resolution, the important encoding settings, the x264 revision, and the patches applied.

The "normal" (trunk) builds of x264 have produced good results for HD @ L4.1 and SD @ L3.1, similar to your Elecard settings, though without B-pyramids.

akupenguin

20th January 2008, 13:30

Updated all b-ref patch (http://akuvian.org/src/x264/x264_dxva_pyramid_experiment_all-bref.diff).

And if that still doesn't work for you, here's some clips I made
conventional_b3r1.264 (http://akuvian.org/src/x264/grimm_conventional_b3r1.264)
pyramid_b3r1.264 (http://akuvian.org/src/x264/grimm_pyramid_b3r1.264)
all-bref_b1r1.264 (http://akuvian.org/src/x264/grimm_all-bref_b1r1.264)
all-bref_b2r2.264 (http://akuvian.org/src/x264/grimm_all-bref_b2r2.264)
all-bref_b3r3.264 (http://akuvian.org/src/x264/grimm_all-bref_b3r3.264)
all-bref_b4r4.264 (http://akuvian.org/src/x264/grimm_all-bref_b4r4.264)
no-L1_b3r1.264 (http://akuvian.org/src/x264/grimm_no-L1_b3r1.264)
no-bref_b3r1.264 (http://akuvian.org/src/x264/grimm_no-bref_b3r1.264)

UsedUser

20th January 2008, 22:14

Updated all b-ref patch (http://akuvian.org/src/x264/x264_dxva_pyramid_experiment_all-bref.diff).
Test for dxva_pyramid_experiment_all-bref patch v2. Overall, lots of video corruption with all-bref.

896x480
Good (smooth playback req'd setting L3.1 with h264info):
grimm_conventional_b3r1.264
grimm_no-bref_b3r1.264

Corruption:
grimm_all-bref_b1r1.264
grimm_all-bref_b2r2.264
grimm_all-bref_b3r3.264
grimm_no-L1_b3r1.264
grimm_pyramid_b3r1.264

1080p
Corruption:
3 Ref 3 Bfr No B-Pyramid svn-721-dxva_pyramid_experiment_all-bref
4 Ref 3 Bfr No B-Pyramid svn-721-dxva_pyramid_experiment_all-bref

720p
Corruption:
8 Ref 3 Bfr No B-Pyramid svn-721-dxva_pyramid_experiment_all-bref
9 Ref 3 Bfr No B-Pyramid svn-721-dxva_pyramid_experiment_all-bref

CruNcher

20th January 2008, 22:53

OK here are the results aku (forced Cyberlinks Decoder Framework Parser/Decoder via drag and drop the bitstreams into PowerDVD directly "no directshow intereferences by other parser/splitter or whatever can be caused this way")

Nvidia 8800 GT G92 BSP/VP2 Windows XP SP2 Forceware 169.21 WHQL (Windows "NG" specialy modified Windows XP version by me with very low memory consumption)

grimm_all-bref_b1r1.264 <- OK
grimm_all-bref_b1r2.264 <- OK
grimm_all-bref_b2r2.264 <- OK
grimm_all-bref_b2r3.264 <- OK
grimm_all-bref_b3r3.264 <- OK
grimm_conventional_b3r1.264 <- stuttering in some frames most probably b-frame sequence (wrong level?)
grimm_no-bref_b3r1.264 <- stuttering in some frames most probably b-frame sequence (wrong level?)
grimm_no-L1_b3r1.264 <- stuttering in some frames most probably b-frame sequence (wrong level?)
grimm_pyramid_b3r1.264 <- stuttering in some frames most probably b-frame sequence (wrong level?)

So not the same Results as UsedUser as i only experience these stutterings nothing more (no frame corruption @ all) :) except that their is a slight flickering in the dark scene when the camera moves backward away from the little girl (on the left and right side it's flickering "dark area") but i think thats comeing from the Encode itself not from a HDC problem gonna check with Software Decoding again.

Edit: Yep the flickering is a problem of the encode no frame corruption coused by Hardware Decoding visible to me

Useing H264info Alpha 16 changeing Level to 3.1 fixes all of the stuttering Bitstreams (so all of those playback fine now)

grimm_all-bref_b1r1.264 <- OK
grimm_all-bref_b1r2.264 <- OK
grimm_all-bref_b2r2.264 <- OK
grimm_all-bref_b2r3.264 <- OK
grimm_all-bref_b3r3.264 <- OK
grimm_conventional_b3r1.264 <- OK (after changeing level to 3.1)
grimm_no-bref_b3r1.264 <- OK (after changeing level to 3.1)
grimm_no-L1_b3r1.264 <- OK (after changeing level to 3.1)
grimm_pyramid_b3r1.264 <- OK (after changeing level to 3.1)

I think this is a more efficient way too look for interoperability between X264 and Hardware Decoding doing this via a Directshow based Player like Mplayer Classic and Haali or other Parser (embedding the bitstream into MKV/Mp4/AVI) connecting to Cyberlinks Decoder or others (will most probably result in problems, because of the differences how they are designed and like each other)
100% interoperability between them can't be guranted so it's more efficient to use 1 Framework by a company that is established with their Products and has to addhere to the Standard for them and Cyberlinks Player does play every Standard conform Bitstream (HD-DVD,Blu-Ray) it seems within it's own Framework and in Combination with Nvidias/ATIs Hardware Accelleration APIs)

UsedUser

21st January 2008, 02:36

I think this is a more efficient way too look for interoperability between X264 and Hardware Decoding doing this via a Directshow based Player like Mplayer Classic and Haali or other Parser (embedding the bitstream into MKV/Mp4/AVI) connecting to Cyberlinks Decoder or others (will most probably result in problems, because of the differences how they are designed and like each other))
Well, it's disconcerting that we've arrived at contradictory results using the same decoder (Cyberlink) and same hardware (NVIDIA 8800GT).

However, I've gotten the same results despite the container (testing raw AVC, MKV, MP4), and despite the player (ZoomPlayer, MPC HC, or PowerDVD).

If a clip shows corruption, it shows corruption in the same way, at the same time, no matter the container or player.

I did test the previous clips with an ATI HD2600 and saw similar corruption results. I will have to test these new clips to see if the results are consistent.

CruNcher

21st January 2008, 03:11

Mabye there are differences in the Quality between G92 Chips and their BSP/VP2 Core (would be bad, but i doubt it). Or maybe your problems arise because of Mainboard Chipset problems (so something with the data transfer of the bitstream to the card goes wrong, to slow or gets corrupted on the way to the Core, defective Memory ?, overclock problems?).
Such Problems could pretty well exist i remember the non 100% compatible Via Chipsets to the PCI standard back in the 90s :)
Btw i knew this would happen, more and more people are coming and reporting about Hardware Decoding Problems, but most probably alot of them are guys that have bad non standard complaint bitstreams so suffer from the num_ref_frame problem or level_idc flag problem.
To tell most of those that probably all their streams are useless and need to be reencoded (for some generations of Hardware) especialy those that suffer from the num_ref_frame problem is hard :(

A Mod should made a Sticky and send those people into this thread or they gonna swap all around the board about Hardware Decoding Problems.

Hardware Decoding Problems analysed so far:
Num_ref_frame overusage = Results in a Black Screen (workaround is existing by changeing the num_ref_frame flag but no 100% fix solution most probably reencoding is needed)
level_idc flag wrong = Result is a Black Screen aswell as B-frame decoding problems resulting in either stuttering frames or desecending fps like the 20 fps bug (also has todo with Parser/Splitter/Decoder combination) (workaround is existing by changeing the level_idc flag works 100%)
Wrong --sar = Result is a Black Screen (also here a workaround is exisiting and can fix the encodes but most probably they will be wrongly displayed then on Hardware Decoders)

akupenguin

21st January 2008, 03:44

I added some 720p results. DPB=7 or 8 is fine. DPB=9 is too much.

I think overall, DPB=8 as a max for 720p is a better recommendation, no matter the patches. DPB=3 is generally safer for 1080p, as well.

That implies that the DPB limit is somewhat less than the max allowed by level 4.1 (in particular, that it's between 11059200 and 12441600 bytes whereas level 4.1 is 12582912), so I'd like to know exactly what it is.
Could you encode a variety of resolutions, and determine the max usable number of refs for each?
e.g. encode 1280x720 ref9, 1264x720 ref9, 1248x720 ref9, ..., until one works

CruNcher

21st January 2008, 04:36

Current Trunk (--bframes 0 --ref 9/10 --level 4.1 --sar 1:1)
1280x720 ref10 <- x264 [warning]: DPB size (13824000) > level limit (12582912) (sporadic block errors, still good watchable)
1280x720 ref9 <- OK

--bframes 4 --ref 9 --b-pyramid --level 4.1 --sar 1:1
1280x720 <- OK

UsedUser

21st January 2008, 07:15

Ugh. Well, I have to apologize. It looks like something is definitely wrong with my Nvidia 8800GT setup. I won't be testing there anymore until I get it figured out.

I had been testing everything on both my 8800GT setup and my ATI HD2600PRO setup, until the box with the ATI card had a meltdown.

Now, I've rebuilt that box and did some testing.

All the "grimm" clips look good on the HD2600. No block errors, no corruption, just framerate issues that are resolved by changing to L3.1.

I retested the experimental patches as well. Each of the three experimental patches, and the DPB patch by itself (i.e., svn-721), all showed good playback with DXVA. No corruption issues. DPB=9 @ 720p is still the max, as DPB=10 black screens. DPB=4 @ 1080p is still the max as well. But it doesn't appear that either B-frames or B-Pyramids present an issue with the DPB patch.

Looks like I was leading things in the wrong direction. CruNcher, thanks for checking against my results. I will retest every encode I made since the beginning and see what results I get.

CruNcher

21st January 2008, 08:16

I found another Problem with --sar and Haalis Splitter in combination with Cyberlinks Decoder, it doesn't accept the AR from .MKV files only the Bitstream SAR but when muxed in .MKV it doesn't get the Bitstreams SAR anymore (seems Haalis Splitter can't provide it to the Decoder) and so displays it as 1:1 (Directshow Problem).
Videolan and Mplayer have no problem with this they seem to Parse the Bitstream SAR also when the Bitstream is embeded in .MKV.

shon3i

21st January 2008, 08:27

CruNcher

21st January 2008, 08:35

Yeah but unfortunately that won't work for my Mini-HD-DVD Project if i wan't to maintain Hardware Compatibility and Small Bitrate Resolutions (1440x1080,1280x1080), but ok the question remains if i ever take the bitstream into .MKV after that, most probably then MP4 or let it stay in EVO and that should work allways without problems :) Hmm strange with the Overlay Mixer it works but as soon as you go Fullscreen baam 1:1.

Edit: This really gets over strange now with Overlay Mixer even streams playback that showed a Black Screen before, jesus alot in this regards is messed up with Haalis Splitter and Cyberlinks Decoder, ahh ok no real hardware acceleration then Video: YUY2 1920x1088 (16:9) 29.97fps strange some work in Overlay Mixer with Hardware Accelleration some don't a real chaos :D

shon3i

21st January 2008, 17:05

Edit: This really gets over strange now with Overlay Mixer even streams playback that showed a Black Screen before, jesus alot in this regards is messed up with Haalis Splitter and Cyberlinks Decoder, ahh ok no real hardware acceleration then Video: YUY2 1920x1088 (16:9) 29.97fps strange some work in Overlay Mixer with Hardware Accelleration some don't a real chaos
Yes but there isn't acceleration like you say. You can disable DXVA in Cyberlink Decored with WMR 7/9 and you will get picture. Only with DXVA, black screen is showed

CruNcher

22nd January 2008, 02:41

Yes but i would love to have the whole time Hardware Accelleration working, without thinking about either how to encode stuff correctly or about the combinations of Parser/Splitter/Renderer that allow me to achive that task, this is as unfriendly as it can get :D (and standards are normaly exactly their to prevent such interoperability problems)
The problem in this case with Matroska and Cyberlinks Decoder is that Matroska is no standard and Cyberlink doesn't support it and so the only one that can try to solve this problems is Haali himself.
I would really like to use Matroska the whole time i really like it but such stuff really makes me think of this again and not better stay with MP4 and avoid such problems entirely for all Hardware Capapble Decoders @ the moment and in the future. Also the fact that all the new Devices support MP4 nowdays is a big bonus, that's why i love Sonys PSP and the concept of portability 1 Stream just move it and play it (no reencoding), that's how everything should work :) so you can watch your SD AVC encode on your PC,PS3 and just take it on the go to your PSP without doing anything (thats user friendliness) (and im happy that UMD failed so horribly or we for sure wouldn't have had this possiblity so fast) but ok that's over also now that we have on our PCs no SD anymore but HD so we have to reencode again, but therforce we have a big quality gain also for our portable devices ;)

shon3i

22nd January 2008, 11:19

Atak_Snajpera

22nd January 2008, 13:08

CruNcher

23rd January 2008, 19:06

Finally b-pyramid is working on PSP. However I've noticed one corrupted frame when the thunder hits the tree.
http://www.mediafire.com/?dxdytdmddzk

Everything is fine without b-pyramid
http://www.mediafire.com/?0mmu111invm

Playing those 2 in Hardware Mode on Nvidia via Cyberlink for both the FPS slows down after 7 seconds of playback (it drops suddenly from 24 down to 17 and goes lower and lower) i don't like that. Have to check more carefully whats couseing this. (Useing MPCHC standard MP4 Parser gonna try Haalis).

Drag and Drop into PowerDVD shows the same deacerllerating playback speed problems after 7 seconds so it seems no parser problem @ all. (I would guess level is wrong it looks like the same problem as the continuis 20 fps playback problem just that the fps is constantly droping down over time (maybe when hitting b-frames?). (Or Mp4box is buggy and does something wrong, wouldn't suprise me really :P) gonna check the bitstream.

Bitstream alone shows no playback Problems in Hardware Mode. Muxing with Mp4creator and Mp4box with and without sound and gonna check again ;)

I:\test>mp4creator -create=logo.h264 -rate=23.976 test.mp4
Error decoding sei message

hmmm

ok worked anyways but still decreasing the fps, looked @ the bitstream and the only thing i can see is that their are 2 pp following after a sequence of pbpbpbpbpbpb but could be also pure accident that it slowdown @ the same time as those 2 pp appear in the stream, as the bitstream alone has no playback problems inside of PowerDVD with Hardware accelleration

@UsedUser could you confirm this Problem with your Nvidia Card and Cyberlinks Decoder in combination with Atak_Snajperas Samples please, i also wrote something allready about this decreasing fps problem when i still had my 7600 GS and i think i found a strange workaround @ that time for it , note the decreasing fps also happens with this stream in any other container.

shon3i

23rd January 2008, 20:54

Playing those 2 in Hardware Mode on Nvidia via Cyberlink for both the FPS slows down after 7 seconds of playback (it drops suddenly from 24 down to 17 and goes lower and lower) i don't like that. Have to check more carefully whats couseing this. (Useing MPCHC standard MP4 Parser gonna try Haalis).

I have this problem only when i use wrong level. For example when i use level higher than 3.1 for SD (720x576)

CruNcher

23rd January 2008, 21:19

Nope the problem is another and i found a workaround i think allready for this @ the time it had todo with direct_pred mode

http://forum.doom9.org/showthread.php?t=124945
http://forum.doom9.org/showthread.php?t=127712

EDIT: OK i hope once and forall i found it, it seemes to be the direct_pred option that couses trouble with Cyberlink and PV1 DXVA i found a workarround by useing temporal but after creation of the .mp4 in either avidemux or mencoder it is damaged even if you use temporal prediction you have to first extract the raw stream (from the corrupted .mp4 you get from avidemux/mencoder (it might look ok but it isn't not for the combination of Haali Spliter and Cyberlink Decoder)) with yamb (mp4box) for example and create a new .mp4 this fixes the slowdown problem with Cyberlink once and for all if your stream was set on direct_pred=none/spatial/auto then you won't be able to mux the demuxed raw stream correctly with mp4box again it will end with a damaged .mp4 (not finished) direct_pred=temporal is the only way that i found that avoids this slowdown and remuxing problems with mp4box :) (FINALY)

Im not sure if that really was the problem but @ that time it fixed those slowdowns and i know it was a PAL sequence that i had problems with so the resolution of the stream is not the problem

@Atak_Snajpera
could you redo this sample useing --direct temporal :)

Atak_Snajpera

23rd January 2008, 21:41

The result is even worse in this clip. At the end you will see nice dancing blocks :)

http://www.mediafire.com/?a0j0tgqzbid

shon3i

23rd January 2008, 22:30

Nope the problem is another and i found a workaround i think allready for this @ the time it had todo with direct_pred modeI am not sure, because i saw this problem first time when i encode with Elecard Converter Studio 2.0. When i do a single pass VBR everything was fine, but when i do two passes, clip got 20fps bug. I dont know how to change prediction mode in elecard.

btw in Ateme Digital Serie by default is temopral selected, and with ateme i don't have any problems with DXVA

CruNcher

23rd January 2008, 22:43

No no the problem isn't the 20fps bug its much much worse then that, the Framerate is decreasing constantly after about 5 seconds of playback with Cyberlinks Decoder, that's much much worse then if it would just playback constantly @ 20 fps :), but only in .MP4 .MKV useing Cyberlinks Decoder over Directshow not with the Bitstream itself in Cyberlinks PowerDVD. But also with Mainconcepts Bitstream parser via Directshow and Cyberlinks Decoder (only allways in Hardware Decoding Mode).

@Atak_Snajpera
Yep and it's still decreasing so that isn't the problem (i slowly belive this is either an VBV problem or Cyberlinks Decoder is somehow bugged with this kind of streams when reading them from a container but dunno why this is the case, but it's really the worst case scenario for Hardware Playback via Cyberlinks Decoder and DXVA) Looking @ the stream again i see this 2 pp frames exactly @ the time the problem seems to beginn hmmm (could be also just pure coincidence tough).

http://s6.directupload.net/images/080123/o869sqtb.png

Could you please post the complete encoding settings and all stuff you used to create this stream (Encoding/Muxing) :)

Also i would really like to know if ATIs UVD Decoder shows the same problems with Cyberlinks Decoder in Hardware Mode with this clip.

Could you also please cut a longer version it's hard to see what's happening in Cyberlinks PowerDVD with the MP4 i think it's not the same whats happening in a Directshow Player tough i can see that some Frames go missing, but i can't see the extreme FPS decrease it's going to fast black and i can't be sure that the fps would decrease over the whole time of the playback as it does in a Directshow Player. In MPCHC i'ts very obvious to identify that the FPS is constantly decreasing as playback is very fast slowdowned.

With Hardware Decoding Enabled (Cyberlink Decoder,VMR9 Renderless)

http://s2.directupload.net/images/080123/iebss9mt.png

The FPS is constantly decreasing from 23-24 fps after around 5 secs

Hardware Decoding Disabled (Cyberlink Decoder,VMR9 Renderless)

http://s5.directupload.net/images/080123/qzj8oowo.png

Everything is fine

I tried it with all Mp4 Splitter (Internal Mp4 Splitter,Mainconcept Mp4 Demultiplexer, Haali, Cyberlink-7 Mpeg-4 Splitter) allways the same result in Hardware Mode :(

Atak_Snajpera

24th January 2008, 01:29

I was talking about playback on PSP not PC.

CruNcher

24th January 2008, 01:53

Yes but this is also Hardware Playback and that problems are visible here means there could be problems visible on other Devices (in wich form they showup is another thing).
If X264 is not full hardware compatible then you will get errors in many forms on many devices and those don't have to be the same problems.

So please post your settings and the exact way you created this stream also wich tool you used for muxing, and if possible a longer sample that has some other frames where you could see slowdowns visually :), also try to use VBV and see if that fixes your problems on the PSP (im gonna test on my PSP as soon as i have updated it with the latest M33 firm, didn't used it for a long time now)

But yeah i suspect that this decreasing FPS problem is more a Cyberlink Decoder in combination with Splitter problem than a X264 hardware problem, but i wan't to know wich settings causeing this decreasing fps behaveiour with Cyberlinks Decoder and certain X264 streams :)

shon3i

24th January 2008, 11:04

No no the problem isn't the 20fps bug its much much worse then that, the Framerate is decreasing constantly after about 5 seconds of playback with Cyberlinks Decoder,Yes i was talking and mean about same problem, but i use word "20 fps bug". Framerate is vary, but i realy don't know maybe some bug in elecard. This is happens only when i use two pass encoding.

tetsuo55

5th February 2008, 09:47

Dark Shikari

5th February 2008, 09:48

tetsuo55

5th February 2008, 10:15

Running unix command "strings" on the file will display the x264 header with all encoding options used.

That wont work in windows directly, do i need to add it as a switch to a x264.exe or mkvgui.exe??

professor_desty_nova

5th February 2008, 10:24

Thanks to MPC HC i have now 100% dxva decoding from some files, other files do not work, it really does not matter what the resolution is, does anyone know of a tool that can analyze the mkv files and tell me what encoding options where used or something? so i can at least find out what went wrong?

Have you tried AVInaptic? (search the forums for it :) )

Here is an example of the output it gives:

[ About H.264 encoding ]

User data: x264
User data: core 56 svn-680
User data: H.264/MPEG-4 AVC codec
User data: Copyleft 2005
User data: http://www.videolan.org/x264.html
User data: cabac=1
User data: ref=3
User data: deblock=1:0:0
User data: analyse=0x1:0x111
User data: me=hex
User data: subme=4
User data: brdo=0
User data: mixed_ref=0
User data: me_range=16
User data: chroma_me=1
User data: trellis=0
User data: 8x8dct=0
User data: cqm=0
User data: deadzone=21,11
User data: chroma_qp_offset=0
User data: threads=1
User data: nr=0
User data: decimate=1
User data: mbaff=0
User data: bframes=3
User data: b_pyramid=0
User data: b_adapt=1
User data: b_bias=0
User data: direct=3
User data: wpredb=1
User data: bime=0
User data: keyint=250
User data: keyint_min=25
User data: scenecut=40
User data: rc=abr
User data: bitrate=268167020
User data: ratetol=1.0
User data: rceq='blurCplx^(1-qComp)'
User data: qcomp=0.60
User data: qpmin=10
User data: qpmax=51
User data: qpstep=4
User data: ip_ratio=1.40
User data: pb_ratio=1.30
SPS id: 0
Profile: Main@L5.1
Num ref frames: 4
Chroma format idc: YUV 4:2:0
PPS id: 0 (SPS: 0)
Entropy coding type: CABAC
Weighted prediction: No
Weighted bipred idc: B slices - implicit weighted prediction
8x8dct: No

audyovydeo

5th February 2008, 10:38

That wont work in windows directly, do i need to add it as a switch to a x264.exe or mkvgui.exe??

You could also instal Cygwin, and make Windows more bearable.
Much more useful interface than Vista, believe me ;-)

cheers
audyovydeo

tetsuo55

5th February 2008, 10:49

thanks, can someone explain why file 1 does not work with dxva. and file 2 does
file 1(does NOT work with DXVA)
[ About H.264 encoding ]

User data: x264
User data: core 56 svn-677
User data: H.264/MPEG-4 AVC codec
User data: Copyleft 2005
User data: http://www.videolan.org/x264.html
User data: cabac=1
User data: ref=5
User data: deblock=1:0:0
User data: analyse=0x3:0x113
User data: me=umh
User data: subme=7
User data: brdo=1
User data: mixed_ref=1
User data: me_range=16
User data: chroma_me=1
User data: trellis=1
User data: 8x8dct=1
User data: cqm=0
User data: deadzone=21,11
User data: chroma_qp_offset=0
User data: threads=6
User data: nr=0
User data: decimate=1
User data: mbaff=0
User data: bframes=3
User data: b_pyramid=1
User data: b_adapt=1
User data: b_bias=0
User data: direct=1
User data: wpredb=1
User data: bime=1
User data: keyint=250
User data: keyint_min=25
User data: scenecut=40(pre)
User data: rc=2pass
User data: bitrate=5970
User data: ratetol=1.0
User data: rceq='blurCplx^(1-qComp)'
User data: qcomp=0.60
User data: qpmin=10
User data: qpmax=51
User data: qpstep=4
User data: cplxblur=20.0
User data: qblur=0.5
User data: ip_ratio=1.40
User data: pb_ratio=1.30
SPS id: 0
Profile: High@L4.1
Num ref frames: 8
Chroma format idc: YUV 4:2:0
PPS id: 0 (SPS: 0)
Entropy coding type: CABAC
Weighted prediction: No
Weighted bipred idc: B slices - implicit weighted prediction
8x8dct: Yes

file 2 (works with dxva)
[ About H.264 encoding ]

User data: x264
User data: core 56 svn-681
User data: H.264/MPEG-4 AVC codec
User data: Copyleft 2005
User data: http://www.videolan.org/x264.html
User data: cabac=1
User data: ref=5
User data: deblock=1:-3:-3
User data: analyse=0x3:0x133
User data: me=umh
User data: fpel_cmp=sad
User data: subme=6
User data: me-prepass=0
User data: brdo=1
User data: mixed_ref=1
User data: me_range=16
User data: chroma_me=1
User data: trellis=1
User data: 8x8dct=1
User data: cqm=2
User data: deadzone=10,10
User data: chroma_qp_offset=0
User data: threads=3
User data: nr=0
User data: decimate=0
User data: mbaff=0
User data: bframes=3
User data: b_pyramid=1
User data: b_adapt=1
User data: b_bias=0
User data: direct=1
User data: wpredb=1
User data: bime=1
User data: keyint=250
User data: keyint_min=25
User data: scenecut=40(pre)
User data: rc=2pass
User data: bitrate=5621
User data: ratetol=1.0
User data: rceq='blurCplx^(1-qComp)'
User data: qcomp=0.60
User data: qpmin=10
User data: qpmax=51
User data: qpstep=4
User data: cplxblur=20.0
User data: qblur=0.5
User data: ip_ratio=1.40
User data: pb_ratio=1.30
User data: aq=1:0.7:15.0
SPS id: 0
Profile: High@L5.1
Num ref frames: 8
Chroma format idc: YUV 4:2:0
PPS id: 0 (SPS: 0)
Entropy coding type: CABAC
Weighted prediction: No
Weighted bipred idc: B slices - implicit weighted prediction
8x8dct: Yes
Custom intra4X4 luma:
6 7 10 16
7 7 11 17
10 11 12 20
12 13 20 16
Custom intra4X4 chromau:
16 16 16 16
16 16 16 16
16 16 16 16
16 16 16 16
Custom inter4X4 luma:
10 13 28 41
13 14 32 84
28 32 41 111
41 46 111 16
Custom inter4X4 chromau:
16 16 16 16
16 16 16 16
16 16 16 16
16 16 16 16
Custom intra8X8 luma:
9 9 10 10 11 16 21 29
9 9 10 10 11 16 21 29
10 10 10 10 11 16 22 31
10 10 10 11 11 17 23 33
11 11 11 11 11 19 25 36
12 12 13 13 14 20 27 40
15 15 16 16 21 27 31 45
20 20 21 22 36 40 45 16
Custom inter8X8 luma:
12 13 15 18 20 70 163 255
13 13 16 18 20 72 170 255
15 16 17 19 21 81 190 255
18 18 19 21 23 96 228 255
20 20 21 23 25 120 255 255
33 34 36 39 45 32 255 255
64 66 71 80 164 255 255 255
151 155 169 192 255 255 255 10

audyovydeo

5th February 2008, 10:58

thanks, can someone explain why file 1 does not work with dxva. and file 2 does

mmmh, one is Level 4.1 , two is 5.1.
If you encode two @4.1, what gives ?

cheers
a/v

CruNcher

5th February 2008, 10:59

resolution?
also look @ the build's could be mvrange or most probably num_ref_frames problem which i supose
core 56 svn-677
core 56 svn-681

tetsuo55

5th February 2008, 10:59

Yeah, i use a decoder that ignores the level, so in this case thats not the problem (besides the level5.1 file is the one that actually works)

tetsuo55

5th February 2008, 11:00

resolution?

sorry, both files are the same
[ Video track ]

Codec ID: V_MPEG4/ISO/AVC
Resolution: 1280 x 720
Frame aspect ratio: 16:9 = 1.777777
Pixel aspect ratio: 1:1 = 1
Display aspect ratio: 16:9 = 1.777777
Framerate: 23.975986 fps

CruNcher

5th February 2008, 11:06

unlikely that it's a num_ref_frames problem then so only wrong mvrange is left, but for software decoder this should be no problem hardware are very likely to fail playing back this stream and i don't see how it could be fixed or workarround to make it working :( and the last option then i think would be reencoding unless something else ist the problem which i might don't see yet. What's the Device (chip) on which you try to playback the Stream?. But i also don't know how a wrong mvrange should pretend the stream from being played back @ all it's not saved in the bitstream so no way possible for the Device to know how it was encoded before playing it back and only then errors should become visible. To my knowledge so far only wrong SAR, wrong num_ref_frames, wrong level_idc could pretend Hardware playback completly (black Screen) under certain circumstances.

tetsuo55

5th February 2008, 11:20

i am using MPC HC as the decoder

Hardware is : ATI HD2400pro, cat 7.12, reg entries for full hd applied

decoding style used is: bitstream, no FGT

CruNcher

5th February 2008, 11:25

Hmm did you tried also Cyberlinks Decoder in Hardware mode do you get the same results with it?
hmm also i realized now that the threads are different and i could think that a slice decoding problem might also couse problems i saw that with MPC HC Decoder and Apples Slice Encoded streams happening they get borked (most of the times only 1 part of the slice is played back), but im not sure how this old X264 rev worked and if there where any bugs in that regard :( hmm could you repeat the same encoding with the same exact settings on a new SVN build, hopefully it will playback then. But trying first with Cyberlinks Decoder is generaly a good idea, because MPC HC DXVA Decoder is still buggy as mentioned above (Quicktime Problem).

tetsuo55

5th February 2008, 11:28

EDIT: cyberlink gives me the same results

CruNcher

5th February 2008, 11:37

Ok then i would ask you even if it sounds silly to use Trahalds newest h264info on the file 1 bitstream and change it's num_ref_frames to 7 :P and try to playback it again.

tetsuo55

5th February 2008, 12:53

Ok then i would ask you even if it sounds silly to use Trahalds newest h264info on the file 1 bitstream and change it's num_ref_frames to 7 :P and try to playback it again.

IT WORKED. the stream has been fixed!!

wierd, simply remuxing the original stream fixes it too

CruNcher

5th February 2008, 13:58

yep also my experience with some streams just remux them or rebuild them (without any of the options changed) and suddenly they work, it's a strange world (full of bugs) ;)

nautilus7

5th February 2008, 14:21

[ About H.264 encoding ]

User data: x264
User data: core 56 svn-677
User data: H.264/MPEG-4 AVC codec
User data: Copyleft 2005
User data: http://www.videolan.org/x264.html
User data: cabac=1
User data: ref=5
User data: deblock=1:0:0
User data: analyse=0x3:0x113
User data: me=umh
User data: subme=7
User data: brdo=1
User data: mixed_ref=1
User data: me_range=16
User data: chroma_me=1
User data: trellis=1
User data: 8x8dct=1
User data: cqm=0
User data: deadzone=21,11
User data: chroma_qp_offset=0
User data: threads=6
User data: nr=0
User data: decimate=1
User data: mbaff=0
User data: bframes=3
User data: b_pyramid=1
User data: b_adapt=1
User data: b_bias=0
User data: direct=1
User data: wpredb=1
User data: bime=1
User data: keyint=250
User data: keyint_min=25
User data: scenecut=40(pre)
User data: rc=2pass
User data: bitrate=5970
User data: ratetol=1.0
User data: rceq='blurCplx^(1-qComp)'
User data: qcomp=0.60
User data: qpmin=10
User data: qpmax=51
User data: qpstep=4
User data: cplxblur=20.0
User data: qblur=0.5
User data: ip_ratio=1.40
User data: pb_ratio=1.30
SPS id: 0
Profile: High@L4.1
Num ref frames: 8
Chroma format idc: YUV 4:2:0
PPS id: 0 (SPS: 0)
Entropy coding type: CABAC
Weighted prediction: No
Weighted bipred idc: B slices - implicit weighted prediction
8x8dct: Yes

Can you explain me how to set avinaptic to show these info? I tried 2 .mkv (x264) files, but didn't get these info (encoding parameters).

tetsuo55

5th February 2008, 14:27

jamos

5th February 2008, 14:41

I'm seeing the following settings for the PS3 profile:

--level 4.1 --ref 3 --mixed-refs --bframes 3 --b-pyramid

It includes >2 b-frames, adaptive b-frames, and b-frame pyramids, all of which have been noted for their potential to break DXVA. Unless someone has already tested them @ 1080p + num_ref_frames < 5?

I know that if the num_ref_frames < 5 even with the above options it will play back fine on a PS3 or my computer in 1080p.

CruNcher

5th February 2008, 17:29

i just used: file > open

and the version is: avinaptic-20071118-full-fixed

-------------------

Well i checked all my files, they all fall within the ref frames limit.

I am going to try and remux them all to new mkv's, then if i find any streams that still do not work i will try the h264info 7 ref frames and level 4 trick. I'll post results later

great tetsuo55 awaiting your report :)

@jamos
yes i don't know how the PS3 works but maybe it's useing the same way the xbx360 does and has 2 specific decoder functions 1 for customer content (the dashboard AVC/VC-1 decoder) and 1 for comercial content (HD-DVD Decoder) seeing a little into all this AVCHD and the different types of content even signaled in the .EVO format makes me belive that since HD-DVD and Blu-Ray customer content get's strictly cuted of from commercial content and almost every device detects that, might be thought as a way to protect the Hypervisor and HDCP from being exploited in the early days ;).

nautilus7

5th February 2008, 17:53

Same here. Then i suppose it has to do with the file.

UsedUser

5th February 2008, 23:06

Running unix command "strings" on the file will display the x264 header with all encoding options used.
Though I prefer the ease of AVInaptic, particularly because it tells you right out the num_ref_frames, there is also SysInternals strings (http://technet.microsoft.com/en-us/sysinternals/bb897439.aspx) for Windows. Does essentially the same thing.

I know that if the num_ref_frames < 5 even with the above options it will play back fine on a PS3 or my computer in 1080p.
A little late to the game with that one. :)

It is now down to one feature, as long as L4.1 compliance is followed, that may disrupt DXVA: b-pyramid.

tetsuo55

5th February 2008, 23:53

Setting ref frames to 7 and changing the idc to 4 made this file playable, but its choppy and crashes the pc

Original data, my guess is the 10 ref frames are killing this one
[ Video track ]

Codec ID: V_MPEG4/ISO/AVC
Resolution: 1280 x 720
Frame aspect ratio: 16:9 = 1.777777
Pixel aspect ratio: 1:1 = 1
Display aspect ratio: 16:9 = 1.777777
Framerate: 23.976024 fps

[ About H.264 encoding ]

User data: x264
User data: core 56 svn-682C
User data: H.264/MPEG-4 AVC codec
User data: Copyleft 2005
User data: http://www.videolan.org/x264.html
User data: cabac=1
User data: ref=7
User data: deblock=1:0:0
User data: analyse=0x3:0x133
User data: me=umh
User data: fpel_cmp=sad
User data: subme=7
User data: me-prepass=0
User data: brdo=0
User data: mixed_ref=1
User data: me_range=16
User data: chroma_me=1
User data: trellis=1
User data: 8x8dct=1
User data: cqm=0
User data: deadzone=21,11
User data: chroma_qp_offset=0
User data: threads=6
User data: nr=0
User data: decimate=1
User data: mbaff=0
User data: bframes=3
User data: b_pyramid=1
User data: b_adapt=1
User data: b_bias=0
User data: direct=1
User data: wpredb=1
User data: bime=1
User data: keyint=240
User data: keyint_min=24
User data: scenecut=40(pre)
User data: rc=2pass
User data: bitrate=5521
User data: ratetol=1.0
User data: rceq='blurCplx^(1-qComp)'
User data: qcomp=0.60
User data: qpmin=10
User data: qpmax=51
User data: qpstep=4
User data: cplxblur=20.0
User data: qblur=0.5
User data: ip_ratio=1.40
User data: pb_ratio=1.30
SPS id: 0
Profile: High@L4.1
Num ref frames: 10
Chroma format idc: YUV 4:2:0
PPS id: 0 (SPS: 0)
Entropy coding type: CABAC
Weighted prediction: No
Weighted bipred idc: B slices - implicit weighted prediction
8x8dct: Yes

CruNcher

6th February 2008, 00:24

yep for that one it's better to reencode or just watch it with a Software Decoder but be aware changing num_ref_frames will also make those problems visible in Software Decoding so leave it in that case where it is :)

tetsuo55

6th February 2008, 11:08

Okay here is another file

Remuxing >> still no dxva
Changing idc to 4 and 7 ref frames with h264 info >> still no dxva

Original file info:

[ Video track ]

Codec ID: V_MPEG4/ISO/AVC
Resolution: 1280 x 536
Frame aspect ratio: 160:67 = 2.388059
Pixel aspect ratio: 1:1 = 1
Display aspect ratio: 160:67 = 2.388059
Framerate: 23.976043 fps

[ About H.264 encoding ]

User data: x264
User data: core 57 svn-709C
User data: H.264/MPEG-4 AVC codec
User data: Copyleft 2005
User data: http://www.videolan.org/x264.html
User data: cabac=1
User data: ref=5
User data: deblock=1:-3:-3
User data: analyse=0x3:0x133
User data: me=umh
User data: fpel_cmp=sad
User data: subme=6
User data: me-prepass=0
User data: brdo=1
User data: mixed_ref=1
User data: me_range=16
User data: chroma_me=1
User data: trellis=0
User data: 8x8dct=1
User data: cqm=2
User data: deadzone=10,10
User data: chroma_qp_offset=0
User data: threads=3
User data: nr=0
User data: decimate=1
User data: mbaff=0
User data: bframes=3
User data: b_pyramid=1
User data: b_adapt=1
User data: b_bias=0
User data: direct=1
User data: wpredb=1
User data: bime=1
User data: keyint=250
User data: keyint_min=25
User data: scenecut=40(pre)
User data: rc=2pass
User data: bitrate=6011
User data: ratetol=1.0
User data: rceq='blurCplx^(1-qComp)'
User data: qcomp=0.60
User data: qpmin=10
User data: qpmax=51
User data: qpstep=4
User data: cplxblur=20.0
User data: qblur=0.5
User data: ip_ratio=1.40
User data: pb_ratio=1.30
User data: aq=1:0.7:15.0
SPS id: 0
Profile: High@L5.1
Num ref frames: 8
Chroma format idc: YUV 4:2:0
PPS id: 0 (SPS: 0)
Entropy coding type: CABAC
Weighted prediction: No
Weighted bipred idc: B slices - implicit weighted prediction
8x8dct: Yes

CruNcher

6th February 2008, 11:16

Resolution isn't mod16 that's gonna fail on most devices it has a reason why HDTV is transmited in 1088 ;) and cores like Nvidia upscale it to that if they get 1080 tough for custom resolutions this might not work correctly also on ATIs core. You could try to use the Size feature in h264info to change the height to a mod16 resolution maybe it works then :). Also X264 should have warned you when encoding this that it isn't mod16 and could couse problems.

tetsuo55

6th February 2008, 14:53

KoD

7th February 2008, 09:59

KoD

7th February 2008, 10:07

changing it to 1280x544 failed, avinaptic says its a mod32 height, that should be okay right?
im trying to change the ref frames to 7 on this height edited sample

-------------

EDIT:

ref frames 7 didnt help either, so unless 544 is still a wrong height then there has to be something else wrong with this file

If you take a clay statue and attach a label "Made of gold", do you think the statue suddenly turned into a gold statue ?

How about making the statue out of gold from the beginning, which in your case means reencoding the video stream with parameters that hardware chips can handle. These parameters have already been posted before.

tetsuo55

7th February 2008, 10:31

If you take a clay statue and attach a label "Made of gold", do you think the statue suddenly turned into a gold statue ?

How about making the statue out of gold from the beginning, which in your case means reencoding the video stream with parameters that hardware chips can handle. These parameters have already been posted before.

The point here is to find out why 90-100% compliant files do not get DXVA acceleration, most of the files i am testing here conform to all the DXVA specs but do not get accelerated, i'm simply trying to find out why. By changing certain things with h264info the problem can either be solved or the real issue found. This might even lead to another incompatible feature being found, even if it doesnt, the guide to fixing existing encodes can be updated with more fixes.

CruNcher

7th February 2008, 10:35

Yep take that stream aside now tetsuo55 and go on we must suspect for now that the resolution is the problem, waste not to much time on 1 sample, keep on.

KoD

7th February 2008, 10:52

The point here is to find out why 90-100% compliant files do not get DXVA acceleration, most of the files i am testing here conform to all the DXVA specs but do not get accelerated, i'm simply trying to find out why. By changing certain things with h264info the problem can either be solved or the real issue found. This might even lead to another incompatible feature being found, even if it doesnt, the guide to fixing existing encodes can be updated with more fixes.

Ok, I get your point. But you need to get mine, too. Simply changing the label is not going to make the content the chips receive any different than before changing it. Saying in the label the frame is now 1280x544 does not change the fact the chip receives a 1280 x 536 frame to decode. Saying in the label the stream uses only 7 reference fames does not change the fact the chip receives a stream which has more than 7 reference frames in certain spots. If the chip did not like it before, it's not going to like it now either despite what your advertisement (label) said.

CruNcher

7th February 2008, 11:03

Kod that's wrong what you say some Players wan't to know first what the Bitstream says and if it the Parser of the Player doesn't like the info it get's from the Bitstream it will not even start playing it back (even if it could with some visual problems). And check your PC you allways double post ;)

tetsuo55

7th February 2008, 15:00

yeah some players block on headers, it was the resolution after all, as soon as i fixed the resolution the file worked :)

however the resolution i tried initially was incorrect

tetsuo55

7th February 2008, 17:59

foxyshadis

8th February 2008, 07:20

Resize in or out a tiny bit. I don't care if it's under a 5% AR error, which is most peoples' threshold. Some can't even tell with 10% or 20%, you know because they watch uncorrected anamorphic. :p You can also mirror out the first/last line or two.

Will it work with a mod-8 but non-mod-16 resolution? Add a little mirroring to the chroma without affecting the luma.

CruNcher

8th February 2008, 09:48

Okay i have my results:

Non working files fail for one of 3 reasons:

1. too many ref frames
2. non-mod16 resolution
3. container problems

There are also 3 solutions to get the file accelerated

1. change ref frames to 7 with h264info, however most of the time this will cause corrupt frames, better to re-encode
2. Change the resolution to a mod16 resolution with h264info, sometimes this causes a colored line beneath the image, no other problems
3. Remux the streams with the latest version of the container-muxer

As you can see from my results, any file can be forced to be decoded by hardware, its only the h264 header the decoder looks at not the actual stream.

now the qustion remains, many video's are not mod16 when the black bars are fully cropped, what is the best way to both keep mod16 but also to not have a wrong size black bar that interfers with the encoding process?

Non working files fail for one of 5 reasons:

1. too many ref frames
2. non-mod16 resolution
3. container problems
4. wrong Sar (only allowed are 1:1/4:3/5:4/16:9)
5. wrong Level (5.1 will fail most of the times better use for most HD content 4.1 SD content 3.x)

There are also 5 solutions to get the file accelerated (decoded)

1. change ref frames to 7 with h264info, however most of the time this will cause corrupt frames, better to re-encode
2. Change the resolution to a mod16 resolution with h264info, sometimes this causes a colored (or gray) line beneath the image, no other problems
3. Remux the streams with the latest version of the container-muxer
4. Change the Sar with h264info
5. Change the level_idc with h264info

microchip8

8th February 2008, 14:54

Hi,

Maybe a bit off topic, but does anyone knows the vbv_maxrate and vbv_bufsize for compliant SD streams (@L3.1) so they will be playable on stand-alone HW players?

Dark Shikari

9th February 2008, 12:02

shon3i

9th February 2008, 14:09

I have same dilemma, but it seems MeGUI SA-HD-DVD profiles work correctly with hardware players.

I compare two streams:

x264 SA-HD-DVD profile:

http://img206.imageshack.us/img206/7206/x264fl2.jpg

Elecard BluRay HD AVC profile:

http://img352.imageshack.us/img352/7180/elecardrr1.jpg

EDIT: But Elecard HDDVD AVC profile have VBV at 15098880

CruNcher

10th February 2008, 01:13

@Dark Shikari
a funny thing is for HD-DVD those buffer data seem to be confidential and only known by those who read the NDAed Specs for it and they aren't allowed to make them public, tough i think they gonna be revealed soon now that HD-DVD is about to virtualy die :D

highjds

10th February 2008, 04:50

Help me T..T

--------------------------------------------------------------------------------

Hi !!

I wishes that we should understand although my English is awkward.

I'm living in South-Korea and use the megui currently.

I do ripping for collection and store.

I read DXVA encoding article some time ago.
(x264 + more than 4 ref frames = no DXVA or 20fps bug (ati avivo, nvidia purevideo)

Change the option in the megui is difficult to me.
I want to turn off the option not to be display in the information for a 'me-prepass = 0'.
And, We are marked by qcomp=1.00 after encoding.

Will I get DXVA Profile's file though I am sorry?

I want the profile of the option like below.
Your aid is urgent me. Please!!!

My E-mail : highjds@naver.com

[ About H.264 encoding ]

User data: x264
User data: core 56 svn-681
User data: H.264/MPEG-4 AVC codec
User data: Copyleft 2005
User data: http://www.videolan.org/x264.html
User data: cabac=1
User data: ref=5
User data: deblock=1:-3:-3
User data: analyse=0x3:0x133
User data: me=umh
User data: fpel_cmp=sad
User data: subme=6
User data: me-prepass=0
User data: brdo=1
User data: mixed_ref=1
User data: me_range=16
User data: chroma_me=1
User data: trellis=1
User data: 8x8dct=1
User data: cqm=2
User data: deadzone=10,10
User data: chroma_qp_offset=0
User data: threads=3
User data: nr=0
User data: decimate=0
User data: mbaff=0
User data: bframes=3
User data: b_pyramid=1
User data: b_adapt=1
User data: b_bias=0
User data: direct=1
User data: wpredb=1
User data: bime=1
User data: keyint=250
User data: keyint_min=25
User data: scenecut=40(pre)
User data: rc=2pass
User data: bitrate=5621
User data: ratetol=1.0
User data: rceq='blurCplx^(1-qComp)'
User data: qcomp=0.60
User data: qpmin=10
User data: qpmax=51
User data: qpstep=4
User data: cplxblur=20.0
User data: qblur=0.5
User data: ip_ratio=1.40
User data: pb_ratio=1.30
User data: aq=1:0.7:15.0
SPS id: 0
Profile: High@L5.1
Num ref frames: 8
Chroma format idc: YUV 4:2:0
PPS id: 0 (SPS: 0)
Entropy coding type: CABAC
Weighted prediction: No
Weighted bipred idc: B slices - implicit weighted prediction
8x8dct: Yes
Custom intra4X4 luma:
6 7 10 16
7 7 11 17
10 11 12 20
12 13 20 16
Custom intra4X4 chromau:
16 16 16 16
16 16 16 16
16 16 16 16
16 16 16 16
Custom inter4X4 luma:
10 13 28 41
13 14 32 84
28 32 41 111
41 46 111 16
Custom inter4X4 chromau:
16 16 16 16
16 16 16 16
16 16 16 16
16 16 16 16
Custom intra8X8 luma:
9 9 10 10 11 16 21 29
9 9 10 10 11 16 21 29
10 10 10 10 11 16 22 31
10 10 10 11 11 17 23 33
11 11 11 11 11 19 25 36
12 12 13 13 14 20 27 40
15 15 16 16 21 27 31 45
20 20 21 22 36 40 45 16
Custom inter8X8 luma:
12 13 15 18 20 70 163 255
13 13 16 18 20 72 170 255
15 16 17 19 21 81 190 255
18 18 19 21 23 96 228 255
20 20 21 23 25 120 255 255
33 34 36 39 45 32 255 255
64 66 71 80 164 255 255 255
151 155 169 192 255 255 255 10

tetsuo55

10th February 2008, 14:57

Has anyone tested non standard mod16 width's??

Something like 1600x720?

So to create a 100% compatible file:

-use the latest svn revision of x264
-use a SAR of 1:1/4:3/5:4/16:9
-For resolutions higher than 720x576
--mod16 width X mod16 height X ref frames <= 8355840
-For resolutions equal or lower than 720x576
--mod16 width X mod16 height X ref frames <= 4561920

other settings do not seem to matter

UsedUser

11th February 2008, 03:04

im trying to change the ref frames to 7 on this height edited sample

The point here is to find out why 90-100% compliant files do not get DXVA acceleration, most of the files i am testing here conform to all the DXVA specs but do not get accelerated, i'm simply trying to find out why. By changing certain things with h264info the problem can either be solved or the real issue found. This might even lead to another incompatible feature being found, even if it doesnt, the guide to fixing existing encodes can be updated with more fixes.

Ok, I get your point. But you need to get mine, too. Simply changing the label is not going to make the content the chips receive any different than before changing it. Saying in the label the frame is now 1280x544 does not change the fact the chip receives a 1280 x 536 frame to decode. Saying in the label the stream uses only 7 reference fames does not change the fact the chip receives a stream which has more than 7 reference frames in certain spots. If the chip did not like it before, it's not going to like it now either despite what your advertisement (label) said.
While there is value in determining what in a stream's header makes a particular decoder refuse to decode the stream, it is important to note that figuring that out, in some situations, may be fruitless.

What I mean to say is, changing the num_ref_frames by editing the header doesn't actually change the DPB required by the stream, so (as KoD pointed out), it doesn't ultimately help anything. While you may discover that the decoder is checking the stream header for num_ref_frames, it is doing so for a reason, because even if you get the decoder to successfully decode the stream, you get errors because it is, in actuality, out of spec with L4.1. The actual num_ref_frames for a stream cannot be changed by simply editing the header.

On the other hand, --level is not often specified when using x264, and as a result, the encoder defaults to labeling the stream L5.1 (presumably because it is safe to say any stream under L5.1 will also comply with L5.1). So, you get streams that comply with L4.1 in DPB size and other parameters, but are labeled L5.1. Editing the header to change the level_idc label to L4.1 is all that is required to get the decoder to decode successfully without errors.

Overall, you may expose what parameters the decoder is checking for, but it doesn't change the fact that level_idc is editable, and it is on you to ensure the stream complies with the label you give it, while num_ref_frames is not editable. DPB size is a hard requirement.

tetsuo55

11th February 2008, 10:00

snip

I'm sorry but you are wrong, except for those clips i have that have ref frames that are way out of bounds, all my previously non working files work now. (although some have a line of artifacts below the rendered image, but this does not always appear, and its basically a dark grey line)

My testing reveals that decoders only check the packet header, and then let the videocard decode whatever is inside if it passes the required checks. after that it becomes obvious that only a too high number of ref frames causes any real problems with the playback (artifacts, stuttering, 20fps)

CruNcher

11th February 2008, 16:32

I'm sorry but you are wrong, except for those clips i have that have ref frames that are way out of bounds, all my previously non working files work now. (although some have a line of artifacts below the rendered image, but this does not always appear, and its basically a dark grey line)

My testing reveals that decoders only check the packet header, and then let the videocard decode whatever is inside if it passes the required checks. after that it becomes obvious that only a too high number of ref frames causes any real problems with the playback (artifacts, stuttering, 20fps)

Tough the Dark Grey line is because that file wasn't mod16 encoded and you forced it to be mod16 ;)
And i allready made clear that changing this num_ref_frames for what tetsuo55 describes as "out of bounds" encoded streams will couse visual problems in most hardware decoders and even in software you gonna see the same problems then changing the num_ref_frames, but this was just thougt as a workaround for acceptable Visual error rates (and maybe hardware decoder that can handle it) and if one can't live with this he could still retranscode it (wich is of course the prefered method to handle such out of spec streams) :)

tetsuo55

11th February 2008, 17:53

Indeed, the best solution is to re-encode, especially with a new AQ patched SVN build ;)

By the way, does anyone know a solution to this related DXVA problem? its a problem with remuxing MPEG2 streams: http://forum.doom9.org/showthread.php?t=134615

(i think MKV and haali splitter might still have a lot of DXVA incompatibility issues)

UsedUser

12th February 2008, 08:01

My testing reveals that decoders only check the packet header, and then let the videocard decode whatever is inside if it passes the required checks. after that it becomes obvious that only a too high number of ref frames causes any real problems with the playback (artifacts, stuttering, 20fps)
That's exactly what I said. You can get the decoder to decode the stream, but it's still out of spec, so you get errors (artifacts, stuttering, 20fps, etc). Which is in contrast to tightening the IDC label to inform the decoder the stream is actually in spec.

So, if you don't get a properly decoded stream, again, it's essentially fruitless. Sure you can get DXVA, but how is that superior to software decoding if it's fraught with errors? Perhaps some are minor, but at least for me, the goal here was to get DXVA for an intact stream.

tetsuo55

18th February 2008, 20:30

On this topic, what is the actual buffer size and max bitrate required for hardware 4.1 support?

I'm seeing vastly conflicting information everywhere; the H.264 standard says the L4.1 CPB size is 62500kbits, while the MeGUI profiles have both 9000 and 14475, and max bitrate seems to vary wildly between 25000 and 50000 (!?).

What are the actual correct numbers?

this is indeed very interessting info

Could someone encode some test samples??

20 seconds video or something

1 with a CPB size of 62500kbits, other settings same as we use for DXVA compatibility
2 with a CPB size of 14475kbits, other settings same as we use for DXVA compatibility
3 with a CPB size of 9000kbits, other settings same as we use for DXVA compatibility
4. bitrate of 50000, other settings same as we use for DXVA compatibility

if 4 doesn't work try 25000, if that does we could up it until the limit is found

What i know about blu-ray/HDDVD benchmarks 50000 is the max for these disc's standard. some discs have already been released which are well over the 40000, it would be interesting to find the real upper limit, keep going up if 50000 works

-------------------

Again, its clear now that as long as you keep SAR. ref frame limit and mod16 x264 creates a DXVA compatible file, the only thing thats not completely clear is that if pyramids does or doesn't break compatibily on standalones and consoles(ps3/xbox360)

It would be nice to see an option in x264 or frontends that auto-selects the maximum number of ref frames based on the resolution with a -hardware or -dxva switch

akupenguin

18th February 2008, 22:18

You have to determine max bitrate before you can experiment with CPB. Because if you disagree with the decoder about what speed the CPB is filling, then you'll disagree about its fullness. But you don't need to know CPB to test bitrate, assuming your sample is long enough to overflow any reasonable CPB if bitrate is too high.

shon3i

18th February 2008, 23:39

It would be nice to see an option in x264 or frontends that auto-selects the maximum number of ref frames based on the resolution with a -hardware or -dxva switch

Or automaticly make decision based on resolution and framerate. I don't see point to somebody now encode with high level than should.

CruNcher

24th February 2008, 19:32

Mod please sticky this and rename it to something like (Known Hardware accelleration problems with X264)

ggab

25th February 2008, 08:29

and could anybody make a litle sumary post? (collecting the facts about you should care about doing your own DXVA enable's encodes)

thnks

tetsuo55

25th February 2008, 18:55

and could anybody make a litle sumary post? (collecting the facts about you should care about doing your own DXVA enable's encodes)

thnks

I updated the first post.

However i still think that x264 or the frontends should auto calculate the correct settings now that we know all the facts (besides max bitrate and CPB)

CruNcher

25th February 2008, 23:11

Also everyone should be aware that X264s VBV is not 100% standard complaint yet so it could fail in alot of situations so even if you take care there's no guarante that it works 100% with every device in every situation im afraid.

tetsuo55

26th February 2008, 13:17

what VBV? and what seems to be the problem with it?

CruNcher

26th February 2008, 16:04

it's the Video Buffer Verifier it's there to control to heavy bitrate spikes and hold everything constant so Hardware Decoders have no problems to decode a stream (complexity) and it's clearly in the Spec how a stream has to look like in terms of bitrate complexity for every level (some devices have their own VBV also it's called CPB i think Coded Picture Buffer specs, HD-DVD and Blu-Ray)

UsedUser

2nd March 2008, 22:09

I have a little time to execute some test cases, but I'm not very knowledgeable about CPB. I've picked up from CruNcher that VBV is synonymous with CPB. I'm not sure, though, if we're talking about max bitrate or VBV max bitrate, or if they should correspond.

Are these what I should be testing? What am I looking for (breaking DXVA (software decoding), stuttering, picture corruption)?

Baseline:

--pass 2 --stats ".stats" --level 4.1 --bframes 3 --weightb --direct auto --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct

Plus these additional settings:

Establishing max bitrate:
1. --bitrate 62500 --vbv-maxrate 62500
2. --bitrate 50000 --vbv-maxrate 50000
3. --bitrate 25000 --vbv-maxrate 25000
4. [lower or higher values to nail down max bitrate]

Establishing max VBV size (let [maxrate] = the max bitrate determined above):
1. --bitrate [maxrate] --vbv-maxrate [maxrate] --vbv-bufsize [maxrate]
2. --bitrate [maxrate] --vbv-maxrate [maxrate] --vbv-bufsize 25000
3. --bitrate [maxrate] --vbv-maxrate [maxrate] --vbv-bufsize 14475
4. --bitrate [maxrate] --vbv-maxrate [maxrate] --vbv-bufsize 9000

akupenguin

2nd March 2008, 23:37

Establishing max bitrate:
1. --bitrate 62500 --vbv-maxrate 62500

You have to specify some bufsize, but you don't know the right value yet. So pick something small, like 5000.

Establishing max VBV size (let [maxrate] = the max bitrate determined above):
1. --bitrate [maxrate] --vbv-maxrate [maxrate] --vbv-bufsize [maxrate]

There's no reason bufsize couldn't exceed maxrate, that just means it's >1 second.

UsedUser

3rd March 2008, 06:43

You have to specify some bufsize, but you don't know the right value yet. So pick something small, like 5000.
To be clear, it works without specifying a bufsize, it simply gives the following warning:

x264 [warning]: VBV maxrate specified, but no bufsize.

I'm just wondering if there is a default that was used that is suitable for this test, or do I need to re-encode the files?

There's no reason bufsize couldn't exceed maxrate, that just means it's >1 second.
OK, I will crank up the bufsize past the maxrate, once that is found.

So, what am I looking for? How do I know when I've found the max bitrate, and how do I know when I've found the max bufsize?

If "smooth playback" is the criterion, then my preliminary tests indicate the max bitrate is somewhere around 40000.

akupenguin

3rd March 2008, 07:26

To be clear, it works without specifying a bufsize, it simply gives the following warning:

x264 [warning]: VBV maxrate specified, but no bufsize.

That means it didn't do anything. VBV is simply meaningless if you don't specify a bufsize. What default could there possibly be?
Of course you also have to check that it uses near your specified bitrate (checking average is enough). This isn't a given at 62mbit.

So, what am I looking for? How do I know when I've found the max bitrate, and how do I know when I've found the max bufsize?
Smooth playback. But to know that it's choppy due to VBV rather than decoding power, set all the other options to minimize decoding cost. Mainly that means CAVLC and no partitions.

Now, it could be that the device doesn't have any strict VBV maxrate, and only says it does to limit decoding complexity. But if that's the case then you're screwed: there would be no consistent number which you'll be safe if you stay below, there's only a very fuzzy limit depending on content and other options.

UsedUser

4th March 2008, 09:46

When I encode with --bitrate 200000, I still only get ~65000 in the output.

Thus far, I get smooth playback on every stream, no matter how big or small I set combinations of the bitrate, VBV bitrate, or VBV bufsize. I stopped testing at --bitrate 200000 --vbv-bufsize 200000 --vbv-maxrate 200000, but since I'm only getting ~65000 kb/s, are the other settings even valid?

One note:

If you specify any VBV bufsize, the value used in the encoding must be a minimum of 10% of the VBV bitrate, correct? This is why I asked about a default for the bufsize: When I tried to set bufsize low, i.e., 5000, it was always bumped up to 10% of the bitrate (i.e., with bitrate 90000, x264 [warning]: VBV buffer size too small, using 9009 kbit).

So what do I need to do? Find a very complex scene (i.e., flock of birds from Planet Earth ep. 1) that will require a higher bitrate, or is it meaningless to test beyond 62500-65000?

"C:\Program Files\MeGUI\tools\x264\x264.exe" --b
itrate 200000 --level 4.1 --bframes 3 --no-b-adapt --direct auto --no-cabac --su
bme 1 --analyse none --vbv-bufsize 200000 --vbv-maxrate 200000 --me dia --thread
s auto --thread-input --sar 1:1 --progress --no-psnr --no-ssim --output "D:\Vide
o\[2007-02-04] Superbowl XLI\Prince - Superbowl Halftime Show (HD OTA) 1080p L4.
1 max200000 buf200000.mp4" "D:\Video\[2007-02-04] Superbowl XLI\Prince - Superbo
wl Halftime Show (HD OTA) 1080p.avs"
avis [info]: 1920x1080 @ 29.97 fps (1001 frames)
x264 [info]: using SAR=1/1
x264 [warning]: VBV bitrate (200000) > level limit (50000)
x264 [warning]: VBV buffer (200000) > level limit (62500)
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSE3 3DNow!
mp4 [info]: initial delay 1001 (scale 30000)
x264 [info]: slice I:11 Avg QP:10.39 size:25588900:00
x264 [info]: slice P:720 Avg QP:10.44 size:296301
x264 [info]: slice B:270 Avg QP:11.08 size:219575
x264 [info]: mb I I16..4: 26.2% 0.0% 73.8%
x264 [info]: mb P I16..4: 43.1% 0.0% 0.0% P16..4: 56.3% 0.0% 0.0% 0.0% 0
.0% skip: 0.6%
x264 [info]: mb B I16..4: 10.5% 0.0% 0.0% B16..8: 68.2% 0.0% 0.0% direct:
16.1% skip: 5.2%
x264 [info]: direct mvs spatial:70.0% temporal:30.0%
x264 [info]: kb/s:65972.9

encoded 1001 frames, 7.95 fps, 65973.23 kb/s

"C:\Program Files\MeGUI\tools\x264\x264.exe" --b
itrate 66000 --level 4.1 --bframes 3 --no-b-adapt --direct auto --no-cabac --sub
me 1 --analyse none --vbv-bufsize 5000 --vbv-maxrate 66000 --me dia --threads au
to --thread-input --sar 1:1 --progress --no-psnr --no-ssim --output "D:\Video\[2
007-02-04] Superbowl XLI\Prince - Superbowl Halftime Show (HD OTA) 1080p L4.1 ma
x66000 buf05000.mp4" "D:\Video\[2007-02-04] Superbowl XLI\Prince - Superbowl Hal
ftime Show (HD OTA) 1080p.avs"
avis [info]: 1920x1080 @ 29.97 fps (1001 frames)
x264 [info]: using SAR=1/1
x264 [warning]: VBV bitrate (66000) > level limit (50000)
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSE3 3DNow!
x264 [warning]: VBV buffer size too small, using 6606 kbit
mp4 [info]: initial delay 1001 (scale 30000)
x264 [info]: slice I:11 Avg QP:11.49 size:22608100:00
x264 [info]: slice P:720 Avg QP:11.03 size:269783
x264 [info]: slice B:270 Avg QP:12.00 size:187602
x264 [info]: mb I I16..4: 28.7% 0.0% 71.3%
x264 [info]: mb P I16..4: 43.2% 0.0% 0.0% P16..4: 56.2% 0.0% 0.0% 0.0% 0
.0% skip: 0.6%
x264 [info]: mb B I16..4: 10.5% 0.0% 0.0% B16..8: 67.3% 0.0% 0.0% direct:
16.8% skip: 5.4%
x264 [info]: direct mvs spatial:68.5% temporal:31.5%
x264 [info]: kb/s:59253.4

encoded 1001 frames, 8.05 fps, 59253.71 kb/s

Dark Shikari

4th March 2008, 09:56

When I encode with --bitrate 200000, I still only get ~65000 in the output. Set --qpmin 0.

Moondust

4th March 2008, 22:10

When using HA there is some kind of macroblocking/dithering/corruption on a large scale (almost every scene). It also flickers in those areas where the picture is corrupted. It's not watchable though since it's not a smooth picture. Does any of you know what this is and how I can fix it?

I am using AC3Filter, DirectSound, ATI display driver v7.11, VMR9 renderless (only one working with HA) and the Cyberlink H264 decoder.

UsedUser

5th March 2008, 02:33

UsedUser

5th March 2008, 02:40

Set --qpmin 0.
Did the trick, thanks.

Update: It appears 80Mb is the practical limit for bitrate. Just past 80Mb stuttering begins, and gets worse as the bitrate gets higher.

Now I'll go to work on the VBV bufsize.

This stream plays back smoothly:

"C:\Program Files\MeGUI\tools\x264\x264.exe" --b
itrate 81000 --qpmin 0 --level 4.1 --bframes 3 --no-b-adapt --direct auto --no-c
abac --subme 1 --analyse none --vbv-bufsize 5000 --vbv-maxrate 81000 --me dia --
threads auto --thread-input --sar 1:1 --progress --no-psnr --no-ssim --output "D
:\Video\[2007-02-04] Superbowl XLI\Prince - Superbowl Halftime Show (HD OTA) 108
0p L4.1 max81000 buf05000 qpmin0.mp4" "D:\Video\[2007-02-04] Superbowl XLI\Princ
e - Superbowl Halftime Show (HD OTA) 1080p.avs"
avis [info]: 1920x1080 @ 29.97 fps (1001 frames)
x264 [info]: using SAR=1/1
x264 [warning]: VBV bitrate (81000) > level limit (50000)
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSE3 3DNow!
x264 [warning]: VBV buffer size too small, using 8108 kbit
mp4 [info]: initial delay 1001 (scale 30000)
x264 [info]: slice I:11 Avg QP: 9.16 size:32411500:00
x264 [info]: slice P:720 Avg QP: 8.02 size:364740
x264 [info]: slice B:270 Avg QP: 9.74 size:236751
x264 [info]: mb I I16..4: 31.7% 0.0% 68.3%
x264 [info]: mb P I16..4: 42.4% 0.0% 0.0% P16..4: 57.0% 0.0% 0.0% 0.0% 0
.0% skip: 0.6%
x264 [info]: mb B I16..4: 9.9% 0.0% 0.0% B16..8: 69.0% 0.0% 0.0% direct:
15.9% skip: 5.3%
x264 [info]: direct mvs spatial:70.0% temporal:30.0%
x264 [info]: kb/s:79066.0

encoded 1001 frames, 7.51 fps, 79066.53 kb/s

This stream stutters slightly on playback:

"C:\Program Files\MeGUI\tools\x264\x264.exe" --b
itrate 82000 --qpmin 0 --level 4.1 --bframes 3 --no-b-adapt --direct auto --no-c
abac --subme 1 --analyse none --vbv-bufsize 5000 --vbv-maxrate 82000 --me dia --
threads auto --thread-input --sar 1:1 --progress --no-psnr --no-ssim --output "D
:\Video\[2007-02-04] Superbowl XLI\Prince - Superbowl Halftime Show (HD OTA) 108
0p L4.1 max82000 buf05000 qpmin0.mp4" "D:\Video\[2007-02-04] Superbowl XLI\Princ
e - Superbowl Halftime Show (HD OTA) 1080p.avs"
avis [info]: 1920x1080 @ 29.97 fps (1001 frames)
x264 [info]: using SAR=1/1
x264 [warning]: VBV bitrate (82000) > level limit (50000)
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSE3 3DNow!
x264 [warning]: VBV buffer size too small, using 8208 kbit
mp4 [info]: initial delay 1001 (scale 30000)
x264 [info]: slice I:11 Avg QP: 9.40 size:32648300:00
x264 [info]: slice P:720 Avg QP: 7.92 size:368847
x264 [info]: slice B:270 Avg QP: 9.62 size:240689
x264 [info]: mb I I16..4: 32.5% 0.0% 67.5%
x264 [info]: mb P I16..4: 42.4% 0.0% 0.0% P16..4: 57.0% 0.0% 0.0% 0.0% 0
.0% skip: 0.6%
x264 [info]: mb B I16..4: 9.8% 0.0% 0.0% B16..8: 69.1% 0.0% 0.0% direct:
15.8% skip: 5.3%
x264 [info]: direct mvs spatial:70.7% temporal:29.3%
x264 [info]: kb/s:80035.1

encoded 1001 frames, 8.12 fps, 80035.65 kb/s

CruNcher

5th March 2008, 04:07

how about with cabac hehe :D
and what happens if you use i frames only so --keyint 1 and no b-frames

did you also made sure that the file you playback from is either in memory or fully defraged?

UsedUser

5th March 2008, 10:00

how about with cabac hehe :D
and what happens if you use i frames only so --keyint 1 and no b-frames
Those will have to be tests for another time. My patience has run out for now.

did you also made sure that the file you playback from is either in memory or fully defraged?
Umm, no.

Results with NVIDIA 8800GT + Cyberlink H264 decoder using DXVA:

VBV max bitrate: 80000-82000 kb/s
VBV max bufsize: 80000-162000 kb

Once i found 80-82mb as a reliable max bitrate, I tested VBV bufsize up to 200% of VBV max bitrate, then quit.

To reliably play back a file smoothly, VBV max bitrate = 80000 and VBV bufsize = 80000.

To intermittently play back a file smoothly, VBV max bitrate up to 80000, VBV bufsize up to 162000.

When I say intermittently, if I looped a 30-sec clip, sometimes it played smoothly, sometimes it stuttered.

Perhaps (or maybe even likely) this has more to do with Cruncher's questions about defragging and loading a clip into memory. Frankly, I just don't care to test the limits that much. As far as I went, for kicks, I encoded a clip at VBV max bitrate/bufsize = 200mb. It plays at about half speed.

If the H.264 spec states L4.1 limits VBV max bitrate = 50000 and VBV bufsize = 62500, then I've been able to show that DXVA works lovely beyond those values. Beyond that, it's really just getting ridiculous.

But, it's also important to keep in mind that this is with very low encoding complexity, per aku's recommendations.

I tried encoding a couple clips with the PS3 profile that is best for L4.1 compatibility. At VBV max bitrate/bufsize = 80000, the decoder chokes and I get about 1 frame every 10 seconds. With VBV max bitrate = 50000 and VBV bufsize = 62500, I get very choppy playback. With b-pyramid disabled, I get some stuttering, but at least it plays back in real time.

What the practical VBV bitrate/bufsize limits are for the PS3 profile, I haven't yet tested. Given that I've seen reports of some HD DVD / BD discs going beyond 40mb, I'm assuming they're largely substituting bitrate for encoding complexity.

CruNcher

5th March 2008, 14:32

jep crazy how far Nvidias solution goes i think they made it even intermediate Proof for future AVC Intra Production workflows that's why i asked if you could try with --keyint 1 :) in that case 80 mbit would be the lower range and somewhere @ 120 mbit the medium and then it goes higher for very professional quality use :)

Moondust

5th March 2008, 22:31

Those would be the tell-tale signs of exceeding L4.1. Have you checked the stream to see that it complies? If so, is the level_idc declared as High@L4.1?
Yes, it's High@L4.1. All recent L4.1 compliant scene encodes show this corruption. I don´t know where to look. Registry settings, drivers, codecs? I hope anyone can point me in the right direction.

CruNcher

5th March 2008, 23:03

upload a sample

UsedUser

6th March 2008, 00:27

Yes, it's High@L4.1. All recent L4.1 compliant scene encodes show this corruption. I don´t know where to look. Registry settings, drivers, codecs? I hope anyone can point me in the right direction.
You may try upgrading your driver; there have been good reports about 8.2 for HTPC usage. Also, I would always recommend applying the standard reg tweaks (http://home.comcast.net/~exdeus/ati-hd2x00/) for DXVA.

Uploading a sample would allow us to verify it is L4.1 compliant, but troubleshooting a specific issue is better left in the AVS Forum thread (http://www.avsforum.com/avs-vb/showthread.php?p=13302808#post13302808) where you've posted. If you've followed the guidance there, specifically on the driver version, Cyberlink decoder version, and reg settings, then that's really the best advice there is.

tetsuo55

6th March 2008, 17:20

So can i conclude that the following does no longer apply to create compliant files?

--vbv-maxrate 25000

I can remove this setting from the first post right?

However there could still be playback problems on devices like xbox, 360 and psp

I added an extreme setting, anyone willing to try it, i would test a 10 or 20 second clip.

--level 4.1 --ref * --mixed-refs --bframes 3 --b-rdo --bime --weightb --direct auto --subme 7 --trellis 1 --8x8dct --TESA --merange 24 --no-fast-pskip --partitions al--b-pyramid

i wonder if this will still work with DXVA, and if the quality is improvement is actually worth the slower encoding speed

To get the most out of these extreme settings a patched build should be tested (another good test to see if the patches break DXVA)

rack04

6th March 2008, 17:35

Has any MeGUI video profile been updated to provide a DXVA compliant file? FYI, I don't see a PS3 only PD-PS3-XBOX360.

tetsuo55

6th March 2008, 17:53

I don't use megui so i don't know, you safest bet is manual settings, the one's in the first post will lead to dxva compatible files.

Sharktooth

6th March 2008, 18:09

i set up 4 profiles (ill publish them later in the auto-update... waiting for DXVA compliancy confirmation):

DXVA-HD-HQ: --level 4.1 --ref 4 --mixed-refs --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -2,-1 --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh

DXVA-HD-Fast: --level 4.1 --ref 3 --mixed-refs --bframes 3 --b-pyramid --weightb --direct auto --filter -2,-1 --subme 5 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --merange 12

DXVA-SD-HQ: --level 3.1 --ref 8 --mixed-refs --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -2,-1 --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh

DXVA-SD-Fast: --level 3.1 --ref 3 --mixed-refs --bframes 3 --b-pyramid --weightb --direct auto --filter -2,-1 --subme 5 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --merange 12

Please check if there are any parameters that screws DXVA compatibility. All profiles are 2pass.

tetsuo55

6th March 2008, 18:19

i set up 4 profiles (ill publish them later):

DXVA-HD-HQ: --level 4.1 --ref 4 --mixed-refs --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -2,-1 --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh

DXVA-HD-Fast: --level 4.1 --ref 3 --mixed-refs --bframes 3 --b-pyramid --weightb --direct auto --filter -2,-1 --subme 5 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --merange 12

DXVA-SD-HQ: --level 3.1 --ref 8 --mixed-refs --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -2,-1 --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh

DXVA-SA-Fast: --level 3.1 --ref 3 --mixed-refs --bframes 3 --b-pyramid --weightb --direct auto --filter -2,-1 --subme 5 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --merange 12

Please check if there are any parameters that screws DXVA compatibility. All profiles are 2pass.

Those look safe to me, but ref3 in the last one, is it real worth it?

Sharktooth

6th March 2008, 18:21

both "Fast" profiles have --ref 3.
i could lower it to 1 though...

tetsuo55

6th March 2008, 18:24

what i mean is, the encoding time is only marginally faster from what i understand, when lowering the number of ref frames.

the higher ref frames could lead to a better image, with only a tiny bit slower encode times, or i am completely wrong here?

Sharktooth

6th March 2008, 18:25

ehrr... 16 refs is damn slow... and more than 5 refs is usually useless (unless the source is toons/anime)

tetsuo55

6th March 2008, 18:31

ehrr... 16 refs is damn slow... and more than 5 refs is usually useless (unless the source is toons/anime)

Okay would be nice if we had a quality scale.

How much extra quality/compression does 16 refs offer over 15, and is that quality improvement linear or not? so would the same improvemt apply for going from 1 ref to 2 refs?

If there is hardly any improvement we might be able to reduce the options list to a more basic HD and SD profile that just works for everything (but retains quality within a 5% margin )

Sharktooth

6th March 2008, 18:33

it's not linear, it's more like a descending curve. most gain comes going from 1 to 2... until about 3 refs the gain is good. on 4 and 5 there's a small gain... over 5 refs the gain is negligible (unless encoding toons/anime).

rack04

6th March 2008, 18:33

Sharktooth

6th March 2008, 18:38

you mean the DXVA-HQ profiles? then yes, more or less.
the Fast profiles are more comparable to HQ-Fast.

rack04

6th March 2008, 18:41

you mean the DXVA-HQ profiles? then yes, more or less.
the Fast profiles are more comparable to HQ-Fast.

Yes, DXVA-HQ. Thanks for these profiles. Can't wait to test.

Sharktooth

6th March 2008, 18:43

so, if the DXVA profiles are ok, i'll do some other changes to non-DXVA profiles and will put the package on the megui auto-update.

EDIT: Profiles are up. enjoy.

shon3i

6th March 2008, 19:03

--b-pyramid is not safe option, can easly brake compatability.

-level 3.2 aslo can be used on SD material such as 1024x576 or 853x480

-level 4.0 is safer option for HD

Moondust

6th March 2008, 19:04

You may try upgrading your driver; there have been good reports about 8.2 for HTPC usage. Also, I would always recommend applying the standard reg tweaks (http://home.comcast.net/~exdeus/ati-hd2x00/) for DXVA.
Already did that, no effect.

Uploading a sample would allow us to verify it is L4.1 compliant, but troubleshooting a specific issue is better left in the AVS Forum thread (http://www.avsforum.com/avs-vb/showthread.php?p=13302808#post13302808) where you've posted. If you've followed the guidance there, specifically on the driver version, Cyberlink decoder version, and reg settings, then that's really the best advice there is.
I tried about 10 recent 1080p scene encodes and they all show the same corruption pattern. I am unable to upload the sample files, but you can all find them on usenet (sample is included in all scene encodes). Nothing special about those encodes. Only thing I haven't thought of is upgrading the Cyberlink decoder. I am using Powerdvd 7.3319a. ATM my HTPC is broken (won't start, probably mainboard, have to send it back), but as soon as my htpc is up and running I will try that. Thanks for your response, CruNcher as well. :-)

Sharktooth

6th March 2008, 19:18

--b-pyramid is not safe option, can easly brake compatability.

-level 3.2 aslo can be used on SD material such as 1024x576 or 853x480

-level 4.0 is safer option for HD
i read in this thread --b-pyramid is safe.
also 1024x576 is not SD. SD is 704 or 720 * 480 or 576. Levels 3.1 and 4.1 are reported to be compatible (still on this thread and on avsforum).
look at the first post.

tetsuo55

6th March 2008, 20:28

--b-pyramid is not safe option, can easly brake compatability.

-level 3.2 aslo can be used on SD material such as 1024x576 or 853x480

-level 4.0 is safer option for HD

the idc_level does nothing, its just that some players check it, so it has to be set

According to the testers and x264 programmers here b-pyramids works on everything with the updated builds

UsedUser

7th March 2008, 09:58

-level 4.0 is safer option for HD
HD DVD / BD specs support L4.1, and it has been tested compatible with DXVA for both ATI and NVIDIA cards, as well as the PS3 and others. L4.1 makes sense.

According to the testers and x264 programmers here b-pyramids works on everything with the updated builds

That's not entirely true. I still see corruption, as of build 736-2 (Jarrod's patched build), on my NVIDIA 8800GT (G92 chip). Holding all other settings the same, removing --b-pyramid eliminates the corruption. Same clips play fine on an ATI HD2600 with or without b-pyramid.

UsedUser

7th March 2008, 09:59

so, if the DXVA profiles are ok, i'll do some other changes to non-DXVA profiles and will put the package on the megui auto-update.

EDIT: Profiles are up. enjoy.
Just wanted to confirm that those profiles jive with my tests, less the issue with --b-pyramid.

ACrowley

7th March 2008, 12:34

Ive absolutly no Problems with B Pyramid.

I use 5 Ref Frames for 1080p and Level 4.1 , no VBV Max Limit
Works perfect with DXVA on my Ati HD3870. With Cyberlink and with MPC VideoDecoder

tetsuo55

7th March 2008, 14:01

HD DVD / BD specs support L4.1, and it has been tested compatible with DXVA for both ATI and NVIDIA cards, as well as the PS3 and others. L4.1 makes sense.

That's not entirely true. I still see corruption, as of build 736-2 (Jarrod's patched build), on my NVIDIA 8800GT (G92 chip). Holding all other settings the same, removing --b-pyramid eliminates the corruption. Same clips play fine on an ATI HD2600 with or without b-pyramid.

that would be a bug then, as b-pyramids was fixed and working on everything even psp, i guess a new bug was introduced?

tetsuo55

7th March 2008, 14:02

Ive absolutly no Problems with B Pyramid.

I use 5 Ref Frames for 1080p and Level 4.1 , no VBV Max Limit
Works perfect with DXVA on my Ati HD3870. With Cyberlink and with MPC VideoDecoder

Are you sure dxva is enabled? 5 ref frames with 1920*1080 definately should not work

ACrowley

8th March 2008, 09:42

Are you sure dxva is enabled? 5 ref frames with 1920*1080 definately should not work

...its cropped

1920x800 :)

UsedUser

8th March 2008, 10:15

Ive absolutly no Problems with B Pyramid. ... Works perfect with DXVA on my Ati HD3870. With Cyberlink and with MPC VideoDecoder
Indeed, I don't have issues with my ATI HD2600, either. Just the Nvidia card.

UsedUser

8th March 2008, 10:16

that would be a bug then, as b-pyramids was fixed and working on everything even psp, i guess a new bug was introduced?
What build are you referring to when it was fixed? It hasn't been fixed since the start of this thread. I've tested builds 709C, 717M, 717M + dpb-dxva patch, 717M + dpb-dxva + experimental patches, 721, 736-2.

All had issues with b-pyramids on my 8800GT. The only time I didn't have issues were with the patches that didn't use brefs.

With b-pyramid, this is what I see. Though these were created with aku's all-bref experimental patch, this is what it looks like whenever I have b-pyramid enabled:

Blocking: [1] 1080p 2 Ref 2 Bfr No B-Pyramid No B-Adapt svn-717M-ref_dpb-dxva_pyramid_experiment_all-bref
http://s63.photobucket.com/albums/h145/exdeus/x264/th_1080p2Ref2BfrNoB-PyramidNoB-Adaptsv.jpg (http://i63.photobucket.com/albums/h145/exdeus/x264/1080p2Ref2BfrNoB-PyramidNoB-Adaptsv.jpg)

Blocking: [2] 1080p 2 Ref 2 Bfr No B-Pyramid No B-Adapt svn-717M-ref_dpb-dxva_pyramid_experiment_all-bref
http://s63.photobucket.com/albums/h145/exdeus/x264/th_1080p2Ref2BfrNoB-PyramidNoB-Adap-1.jpg (http://i63.photobucket.com/albums/h145/exdeus/x264/1080p2Ref2BfrNoB-PyramidNoB-Adap-1.jpg)

I stated it repeatedly:

http://forum.doom9.org/showthread.php?p=1089523#post1089523
http://forum.doom9.org/showthread.php?p=1089517#post1089517
http://forum.doom9.org/showthread.php?p=1089574#post1089574 (with screenshots)
http://forum.doom9.org/showthread.php?p=1089816#post1089816

CruNcher

8th March 2008, 11:25

UsedUser

9th March 2008, 01:41

@ UsedUser
i have no corruption witk Akus streams but you have those and i also have the 8800 GT please upload this stream (only the scene) that couses problems on your 8800 GT and i have a look.
Please use one of the newest builds for that from Jarod www.x264.nl

200 frame sample. The first 100 frames are full of blocking/corruption, while the last 100 frames look ok. Encoded with build 748.

http://home.comcast.net/~exdeus/Prince - Superbowl Halftime Show (HD OTA) 1080p 200f 4 Ref 3 Bfr b748.mp4

CruNcher

9th March 2008, 08:35

Dxva is enabled (Cyberlink Decoder VMR9 Windowed via Media Player Classic Home Cinema) 0 corruption im sorry, but something seems to be wrong really with either your system or card, could be also some different compatibility problem with your Hardware setup that might be couseing brake ups transfering this big amount of Video Data to the Cards Core, tough Akus samples are not really a big amount of Data either so it seems more like a Hardware defect or real compatibility problem (Overclocking,Memory defect,Chipset Incompatibility problem, add other typical IT problems here), but this really seems to be on your side and not a fault of X264s created Bitstream i hope others with 8800GT can also show you that :(
Also directly playing in Cyberlinks Player no corruption (tough im not sure there DXVA was enabled but 0 cpu usage indicated it)

So other DXVA (ATI and Nvidia) users please test AKUs samples and this one by UsedUser and tell us your experience, tough see my post about Akus samples and change the Level of them accordingly :)
It seems X264 is pretty much (Desktop) Hardware stable by now (except VBV/CPB side of things) if this is the last really corruption issue that's being reported and should show as a false report now :)

Tough nobody seems to post here anymore (corruption) problems so it seems the Goal is reached (allready since some builds back) :)

Sharktooth

9th March 2008, 15:59

UsedUser, update your videocard drivers.

shon3i

9th March 2008, 17:21

Well seem that b-pyramid work well with 4ref frames but i am again little worried because Soninc Cinevision, Elecard, Mainconcept, Ateme and other encoders not prefer b-pyramid when is compatability on first place. What should quailty we do can expect from b-pyramid anyway.

CruNcher

9th March 2008, 18:38

Questions im asking myself why does Professional stuff don't use it for HD-DVD and Blu-Ray (do they have the same problems with b-pyramids that X264 had???) and also why do they use a chroma quant offset of 1 rather then 0 that X264 uses ???

Sulik

9th March 2008, 19:20

A few (rare) titles use reference B-frames. The problem is that it makes it much less efficient for FF/FR playback (can't just skip B-frames anymore)
I would think that the chroma quant offset > 0 is chosen purely from a RD point of view.

Sagittaire

9th March 2008, 20:01

use 3 bframes + pyramid bframe change the threshold limit for reference frame.

- 4 ref and 3 bref with 1/2/3 bframes
- 3 ref and 2 bref with 3 pyramidal bframes

Professional source are often really grainy/noisy source and with these master high bframe value are simply useless.
With really clean source (like anime) there are not big difference between 2 bframes and 3 pyramidal bframes.

CruNcher

9th March 2008, 20:36

@Sagittaire
Did you do any test with latest X264 and Darks AQ yet in terms of Grain/Noise preservation my latest test show some amazing results in those regards and this starts allready @ very low bitrates :) transparency seems to be much faster reached now and so the Grain Layer also with it :)
Look @ this here http://mirror05.x264.nl/CruNcher/force.php?file=./rmd-1500-aq.mp4

ohropax

12th March 2008, 13:07

Sharktooth

12th March 2008, 14:09

that's a plain bug.
b-pyramid is not bound to L5.

nurbs

12th March 2008, 16:42

@ohropax:
b-pyramid works fine on the ps3 (since firmware 1.80 iirc)

gav1577

12th March 2008, 18:01

@ohropax:
b-pyramid works fine on the ps3 (since firmware 1.80 iirc)

Hi nurbs so is bprymid safe to use in a bluray profile if so will 3 bref
be compatible or will 2 bref required. i refer to bluray ps3 compatibility ? :)

nurbs

12th March 2008, 18:25

I don't know if b-pyramid can be used in bluray encodes. My statement was about the overall AVC playback restrictions on PS3.

gav1577

12th March 2008, 18:35

I don't know if b-pyramid can be used in bluray encodes. My statement was about the overall AVC playback restrictions on PS3.

Ok thanks nurbs. Can anyone answer my question ? :)

tetsuo55

13th March 2008, 12:09

@tetsuo55

Hi,

in the first posting you recommend using b-pyramids contrary to the referenced thread. I have been fiddling with Elecard Converter Studio and found out that enabling b-pyramids triggers a step up from from L4.1 to L5. I think this indicates that your decision is wrong and we should omit p-pyramids. This would accomodate PS3 users as well, see http://www.digital-digest.com/articles/PS3_H.264_Conversion_Guide_page4.html.

Just 2ct from someone uninformed trying to put bits and pieces together,
Marcus

See Sharktooth and nurbs replies.

Please create a short sample video with the correct settings as displayed on the first page with the latest x264 svn builds and test it yourself, it should work, if it doesn't please post it here with settings so we can troubleshoot the problem

Also you can try creating a sample with elecard and change the level back to 4.1 and test that

Ok thanks nurbs. Can anyone answer my question ? :)

I remember reading that some Blu-ray discs use b-pyramids, however this messes with the fast-forward and fast-return function of the disc

gav1577

13th March 2008, 15:29

I remember reading that some Blu-ray discs use b-pyramids, however this messes with the fast-forward and fast-return function of the disc

Ok thanks tetsuo55

Moondust

19th March 2008, 22:07

While the H264 decoder from Cyberlink's Powerdvd showed a lot of corruption during playback in my setup, the new MPC-HC (version 1.1.0.0) works perfectly with hardware decoding. I am using the new internal H264 decoder in combination with VMR9 (renderless). You will have to check the right source and transform filter in order to be able to use it. Also make sure you turn VMR9 mixer mode off, since it causes choppy playback. Also DirectVobSub cannot be used. You will have to use the internal subtitles driver in MPC-HC if you want to display subtitles.

tetsuo55

20th March 2008, 16:01

i will contintue the issue found with mixed_ref=1 one here

Original post:
http://forum.doom9.org/showpost.php?p=1113640&postcount=507

it would seem that mixed_ref=1 breaks hardware compatibility, we should test this on DXVA too, if it doesnt work we will have found an option that breaks DXVA, the next question would be accidental or by design?

CruNcher

20th March 2008, 18:26

hmm which X264 build did he use and does he have a sample of the file tough he says it doesn't work on the PS3 doesn't mean it doesn't have to work on Nvidia and Ati Decoders.

TheShadowRunner

20th March 2008, 20:36

well guys, i have a small finding to share.
I had this 720p file encoded at level5.1 which didn't play with dxva (black screen)
I unmuxed it, converted to 720p level4.1, and at the time of muxing it back, i made a mistake and chose the extracted, unchanged 720p file level 5.1.
And guess what the remuxed file works with DXVA AND level5.1..
I used mkvmerge 2.2 to remux. The file had been originally muxed with 2.0...
Strange or what?
Later,

TSR

Moondust

21st March 2008, 00:23

@TheShadowRunner
MPC-HC v1.1.0.0 can play 720p files with High@L5.1 using DXVA.

TheShadowRunner

27th March 2008, 03:46

UsedUser

27th March 2008, 04:46

ohropax

28th March 2008, 12:54

Hi Moondust, the weird thing is that my above finding worked for Cyberlink 264 decoder!!
The ONLY difference between working file and not working file is that they have been muxed with different versions of mkvmerge. Go figure.
See you,

TSR

Are you using MPC-HC? I do and have experienced something similar when encoding with ffmpeg + libx264. If i choose MKV as output container, the file cannot be played with DXVA MPC-HC. If i however choose MP4, it can. The video stream should be identical in these cases. I took a look at the issue with avinaptic an I guess that it has something todo with how the video stream is marked up in the MKV container:

The MKV files that actually work do have a framerate (or something similar) set in the containers video stream description (the stream itself has the information as well afaik). But in the case of non-working MKV, the framerate is missing in the containers video stream description (the stream itself still has it of course i assume). So this seems to be either a bug in the MKV creation program or a bug in the way MPC-HC handles containers stream attributes.

my 2ct
Marcus

TheShadowRunner

28th March 2008, 13:35

But in the case of non-working MKV, the framerate is missing in the containers video stream description (the stream itself still has it of course i assume).

Hey Marcus, I think you nailed it. That must be it, for certain files that is.
In any case, it seems solved with mkvmerge 2.2.0.
Did you try to remux with this one and check?
And no, i don't use MPC, Zoom Player here ^^;
See you,

TSR

tetsuo55

28th March 2008, 15:01

I have used mixed_ref=1 throughout testing and it has not caused an issue. No problem with mixed refs for DXVA.

dou you have the ability to test on a PS3, or could you upload a small sample encoded with those settings so we can post that in the ps3 thread.

On that topic we REALY need some small tests files.

480p, 576p, 720p, 1080p. Maxed out settings within DXVA spec, 5-10 seconds playtime or something? Ofcourse it should be a transcode of a PD video.

ohropax

30th March 2008, 07:06

Did you try to remux with this one and check?

I have put it onto my TODO list, will post results for different versions of mkvmerge muxed streams as well as for ffmpeg muxed streams. For ffmpeg i will post results for newly encoded streams as well as for remuxes to see whether it makes any difference.

bye,
Marcus

qyqgpower

30th March 2008, 08:24

I've got some problems with vbv settings.
I encoded a 1080p clip with 2pass @ 6000kb/s, the result average bitrate is correct. But when I playing through the file, huge bitrate spikes(over 197mb/s) are appeared in some intended noise scenes.

So I decide to encode again, with vbv settings from Blu-ray Profile:--vbv-bufsize 30000 --vbv-maxrate 38000
result bitrate is less than target: 5983.6
and still very high bitrate is present in those scenes, over 50mb/s

Is there something wrong with vbv control?

CruNcher

30th March 2008, 12:17

x264s VBV isn't fully compliant yet was this a build with AQ and if yes which version did you used, also try a vbv 2pass patched build, that should be better in your case.

qyqgpower

30th March 2008, 14:51

yes I'm using 798 patched from MeGUI's autoupdate.

where could I obtain a vbv 2pass patched build? and why such a patch wasn't in SVN?

wait a minute, is this build already patched with vbv 2pass v6?

I will try Mythcreator's x264.798.modified.experimental.exe in the patches thread.

juGGaKNot

15th April 2008, 09:16

Hello.

I have some problems with megui and DXVA-HD-HQ profile

My footage is at 1920x1088 with crop (0,4,-0,-4) @ 24 FPS

Auto-encode does not work :

http://i286.photobucket.com/albums/ll105/juGGaKNot4cs/ERROR.jpg

Also if i use pre-render it does not work :

http://i286.photobucket.com/albums/ll105/juGGaKNot4cs/5ERROR.jpg

Only way it works is RAWAVC then mp4box and FAAC commandline :

http://i286.photobucket.com/albums/ll105/juGGaKNot4cs/Works.jpg

Any tips ?

LE : used 720P for this trial, will do 1920x1088 with crop (0,4,-0,-4) @ 24 FPS now.

juGGaKNot

15th April 2008, 10:36

IT WORKS!

kmplayer was the problem, MPC works FINE!

1920x1088 render at 23.967 FPS from vegas

avisource("videp.avi")
crop(0,4,-0,-4)
spline36resize(1920,1080)
Converttoyv12()
ColorMatrix()

x264
RAWAVC format ( so i can add the sound via MP4BOX )
DXVA-HD-HQ

Job commandline: "D:\Megui\tools\x264\x264.exe" --pass 1 --bitrate 10000 --stats "D:\Megui\video.stats" --level 4.1 --bframes 3 --b-pyramid --direct auto --filter -2,-1 --subme 1 --analyse none --me dia --threads auto --thread-input --sar 1:1 --progress --no-psnr --no-ssim --output NUL "D:\Megui\video.avs"

so now i should have 1080P video that the video card decodes hardware no?

Also : what matrix should i use ?

FLAT ( DXVA-HD-HQ default ) or this one :

Custom Quantizer Matrix "eqm_avc_hr.cfg".

INTRA4X4_LUMA =
6, 9,13,19,
9,14,20,27,
13,20,28,35,
19,27,35,42

INTRA4X4_CHROMAU =
6,10,15,20,
10,16,21,27,
15,21,28,33,
20,27,33,42

INTRA4X4_CHROMAV =
6,10,15,20,
10,16,21,27,
15,21,28,33,
20,27,33,42

INTER4X4_LUMA =
8,11,15,20,
11,16,21,27,
15,21,28,35,
20,27,35,42

INTER4X4_CHROMAU =
8,11,16,21,
11,17,22,27,
16,22,28,35,
21,27,35,42

INTER4X4_CHROMAV =
8,11,16,21,
11,17,22,27,
16,22,28,35,
21,27,35,42

INTRA8X8_LUMA =
6, 7, 8,10,12,14,16,18,
7, 9,11,13,15,16,18,20,
8,11,14,16,17,19,21,22,
10,13,16,18,20,22,24,26,
12,15,17,20,23,25,28,30,
14,16,19,22,25,29,34,38,
16,18,21,24,28,34,46,52,
18,20,22,26,30,38,52,72

INTER8X8_LUMA =
8, 9,10,12,14,16,19,21,
9,11,13,15,17,19,21,23,
10,13,16,18,20,22,23,25,
12,15,18,21,23,24,26,32,
14,17,20,23,25,27,33,40,
16,19,22,24,27,34,41,52,
19,21,23,26,33,41,53,64,
21,23,25,32,40,52,64,80

This one is made by Sharktooth in 08'

PS : pre-render doesn't work, can i skip it and stil get the hardware decoding ?

Also Sharktooth if u can give me an answer about the matrix .. since its yours :)

Cheers.

juGGaKNot.

audyovydeo

15th April 2008, 10:53

--subme 1 --analyse none --me dia

I assume you're only using these settings to waste less time on your test encode, you don't use them in your final encode ?

cheers
audyovydeo

juGGaKNot

15th April 2008, 12:01

I will remove whatever takes from the video quality.

anything else ?

Now i render MKV and mux with mkvtoolnix

avisource("1080P24P.avi")
crop(0,0,-0,-0)
spline36resize(1920,1080)
Converttoyv12()
ColorMatrix()

Matrix by sharktooth ( see attachment or post : http://forum.doom9.org/showpost.php?p=1125831&postcount=293 )

and default DXVA-HD-HQ profile !

will post a sample by tonight!

PS : how do i find out if my video works with the HARDWARE decoding that my XFX 8500 offers ?

LATER EDIT :

The output frame rate is 24.000 FPS, 1920x1080 24P means 24.000 FPS no ?

UPDATE :

http://files.filefront.com/1080P24Paudiomkv/;10013225;/fileinfo.html

Its done, does it work ? please try and post.

Cheers.

juGGaKNot.

Sharktooth

15th April 2008, 13:50

Do Not Use Megui 0.3.0.0!!!
How many times i have to say that?!??!?!!?!?!?
It's completely unstable... and it is in development. That version is even outdated!
Get megui ONLY from the official website:
http://www.sf.net/projects/megui

juGGaKNot

15th April 2008, 13:58

Do Not Use Megui 0.3.0.0!!!
How many times i have to say that?!??!?!!?!?!?
Get megui ONLY from the official website! That is http://www.sf.net/projects/megui

My bad :|

so install 0.2.6 and update all files or de-select the two first updates and the tree at the bottom ?

will render again

now 23.976 FPS and not 24.

Sharktooth

15th April 2008, 14:00

update ALL files!

juGGaKNot

15th April 2008, 14:06

update ALL files!

Deleted all OLD files!

Installed megui stable 0.2.6.1046

now updating all ( core & data up to date )

so 0.2.6.1046 STABLE !

juGGaKNot

15th April 2008, 14:53

Video done

http://files.filefront.com/final+rendermkv/;10014728;/fileinfo.html

bitrate 10000, at 20000 my x2 4000 laggs with mpc

DVVA-HD-HQ with sharktooth matrix

render mkv, mux with mkvtoolnix ( .wav audio file )

Does it work on your PC ? what quality ? is it 1080P and hardware decoding used ?

General #0
Complete name : D:\New Folder\final render.mkv
Format : Matroska
File size : 16.3 MiB
PlayTime : 11s 750ms
Bit rate : 11.6 Mbps
Encoded date : UTC 2008-04-15 10:08:15
Writing application : mkvmerge v2.2.0 ('Turn It On Again') built on Mar 4 2008 12:58:26
Writing library : libebml v0.7.7 + libmatroska v0.8.1

Video #0
Codec : AVC
Codec/Family : AVC
Codec/Info : Advanced Video Codec
Codec profile : High@L4.1
Codec settings, CABAC : Yes
PlayTime : 11s 708ms
Nominal bit rate : 10000 Kbps
Width : 1920 pixels
Height : 1080 pixels
Display Aspect ratio : 16/9
Frame rate : 23.976 fps
Chroma : 4:2:0
Interlacement : Progressive
Writing library : x264 - core 59 r819M 0414d78
Encoding settings : cabac=1 / ref=4 / deblock=1:-2:-1 / analyse=0x3:0x113 / me=umh / subme=6 / me-prepass=0 / brdo=1 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=2 / deadzone=21,11 / chroma_qp_offset=0 / threads=3 / nr=0 / decimate=1 / mbaff=0 / bframes=3 / b_pyramid=1 / b_adapt=1 / b_bias=0 / direct=3 / wpredb=1 / bime=1 / keyint=250 / keyint_min=25 / scenecut=40(pre) / rc=2pass / bitrate=10000 / ratetol=1.0 / rceq='blurCplx^(1-qComp)' / qcomp=1.00 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30 / aq=2:1.00
Language : English

Audio #0
Codec : PCM
Codec/Family : PCM
Codec/Info : Linear PCM (Little Endian)
PlayTime : 11s 750ms
Channel(s) : 2 channels
Sampling rate : 44.1 KHz
Resolution : 16 bits

MeGUI Version: 0.2.6.1046
OS used: Microsoft Windows XP Professional Service Pack 2
Framework used: 2.0
------------------------------------------------------

Looking for job processor for job...

Processor found!

------------------------------------------------------

Starting job job1 at 7:59:22 PM

Starting preprocessing of job...

Preprocessing finished!

successfully started encoding

Processing ended at 8:00:24 PM

------------------------------------------------------

Log for job job1

Job commandline: "D:\MeGUI\tools\x264\x264.exe" --pass 1 --bitrate 10000 --stats "D:\MeGUI\video.stats" --level 4.1 --bframes 3 --b-pyramid --direct auto --filter -2,-1 --subme 1 --partitions none --me dia --threads auto --thread-input --sar 1:1 --cqmfile "D:\MeGUI\profiles\Video\eqm_avc_hr.cfg" --progress --no-psnr --no-ssim --output NUL "D:\MeGUI\video.avs"
avis [info]: 1920x1080 @ 23.98 fps (281 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSE3 3DNow!
x264 [info]: slice I:3 Avg QP:18.91 size: 47778
x264 [info]: slice P:193 Avg QP:24.64 size: 61448
x264 [info]: slice B:85 Avg QP:28.62 size: 19175
x264 [info]: mb I I16..4: 79.2% 0.0% 20.8%
x264 [info]: mb P I16..4: 49.1% 0.0% 0.0% P16..4: 41.9% 0.0% 0.0% 0.0% 0.0% skip: 9.0%
x264 [info]: mb B I16..4: 6.2% 0.0% 0.0% B16..8: 26.9% 0.0% 0.0% direct:24.0% skip:42.9%
x264 [info]: final ratefactor: 25.22
x264 [info]: direct mvs spatial:97.6% temporal:2.4%
x264 [info]: kb/s:9305.5

encoded 281 frames, 4.57 fps, 9306.32 kb/s

------------------------------------------------------

Starting postprocessing of job...

Job completed successfully and deletion of intermediate files is activated

Postprocessing finished!

End of log for job1
------------------------------------------------------

Looking for job processor for job...

Processor found!

------------------------------------------------------

Starting job job2 at 8:00:24 PM

Starting preprocessing of job...

Preprocessing finished!

successfully started encoding

Processing ended at 8:04:00 PM

------------------------------------------------------

Log for job job2

Job commandline: "D:\MeGUI\tools\x264\x264.exe" --pass 2 --bitrate 10000 --stats "D:\MeGUI\video.stats" --level 4.1 --ref 4 --mixed-refs --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -2,-1 --subme 6 --trellis 1 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --sar 1:1 --cqmfile "D:\MeGUI\profiles\Video\eqm_avc_hr.cfg" --progress --no-psnr --no-ssim --output "D:\MeGUI\video.mkv" "D:\MeGUI\video.avs"
avis [info]: 1920x1080 @ 23.98 fps (281 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSE3 3DNow!
x264 [info]: slice I:3 Avg QP:18.97 size: 51277
x264 [info]: slice P:193 Avg QP:20.37 size: 68597
x264 [info]: slice B:85 Avg QP:23.31 size: 19102
x264 [info]: mb I I16..4: 46.1% 50.6% 3.3%
x264 [info]: mb P I16..4: 8.9% 27.2% 1.4% P16..4: 36.6% 13.9% 4.9% 0.0% 0.0% skip: 7.0%
x264 [info]: mb B I16..4: 1.0% 1.9% 0.1% B16..8: 28.0% 1.5% 2.1% direct: 2.2% skip:63.1%
x264 [info]: 8x8 transform intra:71.3% inter:85.5%
x264 [info]: direct mvs spatial:94.1% temporal:5.9%
x264 [info]: ref P 74.4% 12.7% 7.3% 5.6%
x264 [info]: ref B 75.9% 16.4% 7.7%
x264 [info]: kb/s:10250.2

encoded 281 frames, 1.32 fps, 10251.08 kb/s
desired video bitrate of this job: 10000 kbit/s - obtained video bitrate (approximate): 10254 kbit/s
------------------------------------------------------

Starting postprocessing of job...

Job completed successfully and deletion of intermediate files is activated

Found intermediate output file 'D:\MeGUI\video.stats', deleting...
Deletion succeeded.

Postprocessing finished!

End of log for job2
------------------------------------------------------

Looking for job processor for job...

Processor found!

------------------------------------------------------

Starting job job3 at 8:04:00 PM

Starting preprocessing of job...

Preprocessing finished!

successfully started encoding

Processing ended at 8:04:46 PM

------------------------------------------------------

Log for job job3

------------------------------------------------------

Starting postprocessing of job...

Job completed successfully and deletion of intermediate files is activated

Postprocessing finished!

End of log for job3

cheers.

juGGaKNot.

ohropax

16th April 2008, 11:33

@juGGaKNot

For me the video is played nicely using DXVA with both PowerDVD and MPC-HC decoders. I am using a NVidia Quadro NVS 140M chip.

Cheers,
Marcus

juGGaKNot

16th April 2008, 14:03

@juGGaKNot

For me the video is played nicely using DXVA with both PowerDVD and MPC-HC decoders. I am using a NVidia Quadro NVS 140M chip.

Cheers,
Marcus

THANKS man !

MPC-HC doesn't work for me, only MPC, tried core AVC 1.6.5 but the same.

Probably codec problems ( have k-lite codec pack and CCCP and KMPlayer installed )

K so DXVA-HD-HQ with sharktoot's matrix is the way to go!

Now : I also want the video to be compatible with standalone BLU-RAY players, what do i have to change to make my DXVA footage BLU-RAY ?

Is 24P the FPS i must use ?

I also have some 48P footage, is it BLU-RAY compatible ? or DXVA compatible ?

Cheers.

juGGaKNot.

LINK DOWN , new link :

http://files.filefront.com/final+rendermkv/;10021753;/fileinfo.html

ericab

9th May 2008, 21:51

juGGaKNot;
off topic, sorry;
what HL:S mod is that footage from ?

tetsuo55

19th May 2008, 17:29

It seems that the Pixel Aspect Ratio is not a problem after all, i have now seen several examples of working DXVA compatible files that have PAR's that should be incompatible

canuckerfan

27th May 2008, 00:53

so what's the general consensus about ref frames greater than 4? is any combination of GPU+CPU able to handle high ref frame material?

UsedUser

27th May 2008, 08:26

so what's the general consensus about ref frames greater than 4? is any combination of GPU+CPU able to handle high ref frame material?

First off, the ref frame limit of 4 only applies to 1080p content. What we're really looking at is compliance with H.264 Profile: High, Level: 4.1. Lower resolutions can handle more ref frames without breaking L4.1 compliance (important for DXVA across platforms). The OP has details.

Secondly, The consoles have L4.1 limitations, but on the PC, it is the Cyberlink decoder that enforces L4.1.

PCs with just about any CPU + NVIDIA 8000 or ATI 2000/3000 GPU can handle more ref frames beyond L4.1 when using the MPC decoder.

tetsuo55

28th May 2008, 10:30

No hardware decoder supports more than 4 ref frames with 1920x1080 content, that includes videocards.

Avenger007

28th May 2008, 17:33

No hardware decoder supports more than 4 ref frames with 1920x1080 content, that includes videocards.
Just curious, why does that include graphics cards? Is it a technical issue that can be rectified with a future revision of GPU architecture or are graphics cards (GPU(s) + memory) somehow just physically incapable of handling more than 4 ref frames for 1920x1080 content or is it a software issue? :confused:

UsedUser

28th May 2008, 21:09

No hardware decoder supports more than 4 ref frames with 1920x1080 content, that includes videocards.
Hmm... I know we've both been along for the full ride of figuring this out, but IIRC, the L5.1 (ref > 4) encodes I made @ 1080p played smoothly with the MPC decoder using DXVA. I'll go back to test those again.

foxyshadis

28th May 2008, 22:23

In decoding, the reference frame count only affects the amount of memory needed to decode. More memory means more frames possible. Video cards as they are now don't allow you to use the card's full memory though.

tetsuo55

29th May 2008, 11:52

They need to enfore the level rules to be certified for Bluray playback.

The only reason we are even discussing this is because some software decoders do not enforce levels, this should actually be a bug that needs to be fixed but in fact we found that "out of level spec" files are sometimes better, the best example being anime.

However most experts will say that more than 5 ref frames is usually pointless, so going down 1 notch for full HD should not matter that much.

29th May 2008, 13:12

They need to enfore the level rules to be certified for Bluray playback.
Really? That doesn't sound reasonable since the same decoder could also be used to play other sources. Why would the Blu-ray certification restrict the decoder to a certain level without allowing it to support higher bitrates and buffer sizes?

Technical reasons like limited on-board memory on low-end graphics cards would be a more understandable explanation.

The only reason we are even discussing this is because some software decoders do not enforce levels, this should actually be a bug that needs to be fixed but in fact we found that "out of level spec" files are sometimes better, the best example being anime.
I don't see any point in enforcing levels in a software decoder unless it has been allocated with a limited amount of memory.

tetsuo55

29th May 2008, 14:28

Well when i say bluray i mean h264 standard.

The reason why you do not want to create out of spec files (and remove all support for them) is basically to keep the videostream compatible with all players.

The playback method has been standerdised in h264, every decoder must show the same image.

This is a better explenation:

For some reason the buffer size has been limited to 12MB, this means that all hardware decoders that want 100% support for their IDC level need to have a 12MB buffer.

I imagine that level 5.1 files will only be able to use 1 or 2 ref frames.

Now a more interesting question is:

Is the 12MB limit an overal limit for all h264 levels or.. is it the maximum for level 4.1. IF its a 4.1 limit and 5.1 supports a bigger limit then all we need is level 5.1 support for the videocards and more ref frames would be possible for pc use (but these would then be level 5.1 files and will not be compatible with 4.1 limited devices anymore)

It's probably best to always stay within the limits of the codec for maximum playback support

29th May 2008, 14:59

Is the 12MB limit an overal limit for all h264 levels or.. is it the maximum for level 4.1.
Only for level 4.1. According to the Wikipedia article (http://en.wikipedia.org/wiki/H.264#Levels), level 5.1 allows 1080p120 with 16 reference frames.

IF its a 4.1 limit and 5.1 supports a bigger limit then all we need is level 5.1 support for the videocards and more ref frames would be possible for pc use (but these would then be level 5.1 files and will not be compatible with 4.1 limited devices anymore)
Exactly.

tetsuo55

29th May 2008, 15:22

Hey someone updated that article

Then the solution would simply be asking all videocard vendors to support level 5.1, still i all for levels. sticking to levels means your file will work no matter where you try to watch it.

UsedUser

29th May 2008, 20:28

The bottom line, so it seems, is that commercial decoders support up to L4.1 because that is the upper limit for the BD / HD DVD specs.

It's clear that the hardware decoders (and commercial software decoders meant to use DXVA, i.e., Cyberlink's) were designed to decode BD / HD DVD content. It may be that they are capable of decoding above L4.1 (from a memory/bandwidth/throughput standpoint), but that they weren't designed for it, so they don't support it. Not a foreign concept in software or hardware design to build in room for future expansion, but limit current functionality to targeted specs.

This is not to say, however, that any of these decoders couldn't support higher than L4.1, as BD / HD DVD only requires that you support at least L4.1. Any individual decoder supporting L5.1 wouldn't break L4.1 compatibility, for that decoder or any other.

Where is it written that a decoder can at most decode L4.1 content in order to sport some sort of BD / HD DVD certification/logo?

valnar

29th May 2008, 20:54

I'm not seeing what the issue is. Just encode to L4.1 specs and you'll be fine for today and in the future. Has anyone done any comparative analysis of how much space you waste using REF 3 vs REF 15? Is it that much? The only reason to use L5 or better is if you need to encode to a higher resolution than 1920x1088 or need more than 30fps at that resolution. If so... then I can understand an argument against it.

Dark Shikari

29th May 2008, 21:19

Is the 12MB limit an overal limit for all h264 levels or.. is it the maximum for level 4.1.Its just a Level 4.1 maximum (and even then, only for specific profiles).

UsedUser

29th May 2008, 21:34

I'm not seeing what the issue is. Just encode to L4.1 specs and you'll be fine for today and in the future.
For anyone paying attention here, I don't think there's an issue getting them to encode to L4.1. It's addressing encodes done by others that's at issue.

For 720p, the constraints are loose enough that problems with encodes are unusual. For 1080p, encodes beyond L4.1 are still common.

It's a matter of determining the specific limitations imposed by the various decoders to figure workarounds, if available.

For example, determining that having a L4.1 encode still requires have the IDC set to L4.1 for the Cyberlink decoder. Or that MKVs muxed with older versions of mkvmerge can cause issues.

lexor

29th May 2008, 21:36

Is the 12MB limit an overal limit for all h264 levels or.. is it the maximum for level 4.1.
It's the overall limit. In context of video cards, 12mb is not related to levels (DXVA solutions don't check the level). Here is how it came to be, graphics cards manufacturers wanted to label their products as HD-DVD/Blu-Ray compliant, so they had to decode 1080p, 12mb is how much space they need to store 4 uncompressed frames (max ref at 1080p). So if your frames are smaller, i.e. 720p or 480p etc you can fit more of them in the 12mb.

This storage space is fixed for all streams regardless of any profiles and settings.

30th May 2008, 05:58

It's the overall limit. In context of video cards, 12mb is not related to levels (DXVA solutions don't check the level).
Sure it is related and some DXVA-compatible decoders (like Cyberlink) do check the level.

Here is how it came to be, graphics cards manufacturers wanted to label their products as HD-DVD/Blu-Ray compliant, so they had to decode 1080p, 12mb is how much space they need to store 4 uncompressed frames (max ref at 1080p).
4 frames is maximum for 1080p at level 4.1.

This storage space is fixed for all streams regardless of any profiles and settings.
...for all level 4.1 streams (like Blu-ray and HD-DVD). Higher levels require larger buffers.

foxyshadis

30th May 2008, 06:26

It would be an interesting exercise for someone to create a tool that selectively re-encodes by keeping track of which frames are referenced but 'stale' (would be missing in L4.1), and re-encode any macroblock referencing one of those frames to one of the good frames instead, using whatever motion search you like, then fixing up fixable references (such as future predicted vectors). You just have to live with some minimal corruption of any frames that reference those blocks, but it beats complete corruption.

UsedUser

30th May 2008, 08:48

It's the overall limit. In context of video cards, 12mb is not related to levels (DXVA solutions don't check the level). ... This storage space is fixed for all streams regardless of any profiles and settings.
That A) doesn't make a whole lot of sense, and B) stands in stark contrast to Dark Shikari's statement just 2 posts prior to yours.

A) If it were an overall limit, and not related to L4.1, why would the hardware designers pick a 4 refs @ 1080p limit? The H.264 levels support specs well beyond those. They picked the limits precisely because they are those of L4.1, to which the BD / HD DVD specs comply. Complying with BD / HD DVD means you support L4.1 specifically.

Higher levels require larger buffers, and video cards have buffers to spare for decoding.

B) Dark Shikari seems to be just the code monkey (with affection) we need to answer such questions.

lexor

31st May 2008, 14:23

A) If it were an overall limit, and not related to L4.1, why would the hardware designers pick a 4 refs @ 1080p limit? The H.264 levels support specs well beyond those. They picked the limits precisely because they are those of L4.1, to which the BD / HD DVD specs comply. Complying with BD / HD DVD means you support L4.1 specifically.

I'll answer you and nm here. Not a contradiction to what I said. DXVA doesn't check levels. Cyberlink's player (in nm's example) only uses DXVA, what other software does is irrelevant to what DXVA does itself. Also MPC doesn't check level of stream, I have level5.1 streams playing with full acceleration in MPC-HC, ref count is what matters, not the level stamp on the stream.

Higher levels require larger buffers,
Which did not enter into consideration of hardware designers who only cared about getting their cards certified for HDDVD/Blu-Ray compatibility.

and video cards have buffers to spare for decoding.
They have more RAM, but the memory for DXVA's use is fixed, it cannot be changed on current cards.

B) Dark Shikari seems to be just the code monkey (with affection) we need to answer such questions.
My statements come from devs of MPC-HC whom I asked the question about ref limits. As good as DS is and for all the awesome work he has done for x264, he's not the one writing DXVA enabled decoder.

MatMaul

31st May 2008, 16:31

They have more RAM, but the memory for DXVA's use is fixed, it cannot be changed on current cards.
it is driver related and we can't bypass that kind of limitation.
Anyway L4.1 is enough to reach high quality with x264, so everybody should use that now.

Dark Shikari

31st May 2008, 17:32

It's the overall limit.

...

This storage space is fixed for all streams regardless of any profiles and settings.Your statements here seem to be almost designed to be horribly confusing ;)

The DPB size is a limit set by the H.264 standard. Any decoder compliant with a given level must have a buffer of at least the DPB size for that level.

The graphics card doesn't magically change the buffer it has available, so when playing lower-level streams, it still has the full buffer, it just doesn't get used. It doesn't get used because, by definition, if the stream is a lower level, it won't use up as much DPB on decoding.

Its very misleading to say "its the overall limit" because that implies that all hardware devices with H.264 playback, regardless of level (iPod? PSP? 8600GT?), have the same buffer size, which is patently false. Saying all L4.1-compliant hardware decoders have at least a certain buffer size is much more accurate.

lexor

31st May 2008, 20:06

Its very misleading to say "its the overall limit" because that implies that all hardware devices with H.264 playback, regardless of level (iPod? PSP? 8600GT?)

The only way it is confusing is if you start a new thread that is not about DXVA, or did someone get DXVA to run on iPod or PSP?

My statement is that 12mb is the overall limit DXVA has available to it and it cannot be changed on current cards. In context of this thread it has one and only interpretation, that all streams get 12mb for the DXVA decoder to work with at all times and it cannot be changed without buying some future card that's not on the market right now.

My statement is neither confusing nor misleading. Wishful thinking of others (mostly those who look at the 512mb or even 1gb of memory their cards have and ask, why can't I use it) notwithstanding.

it is driver related and we can't bypass that kind of limitation.
Anyway L4.1 is enough to reach high quality with x264, so everybody should use that now.
Oh, I didn't say I wanted more, I'm quite happy with the way things are.

31st May 2008, 22:06

The only way it is confusing is if you start a new thread that is not about DXVA, or did someone get DXVA to run on iPod or PSP?
This thread and tetsuo55's question was not just about DXVA.

My statement is neither confusing nor misleading.
Well, I also think it was misleading until you clarified what you were talking about.

tetsuo55

1st June 2008, 10:53

The only way it is confusing is if you start a new thread that is not about DXVA, or did someone get DXVA to run on iPod or PSP?

Let me be clear about this:

This discussion is about ALL devices that support H.264

Yes DXVA compliant encodes do work on ipod and PSP as long as they are encoded at the correct level.

We talk mostly about DXVA because its the easiest target for testing/troubleshooting

Also the only reason MP-HC does not check level is because i explicitly asked Casimir to do so. Instead of checking levels MPC-HC uses a calculation of ref frames to decide wether the file is 4.1 or lower compatible or not. This is a "workaround" for inaccurate encodes with wrong level_IDC settings.

--------------------------------------------------

So we need a definative answer here:

How big a difference is 4 ref frames and 15 ref frames for 1080p?
And at which point do more ref frames have zero to no effect, from using search it seems that going over 5 ref frames has very little effect.

So i fail to see how using 4 ref frames would be a huge problem

1st June 2008, 14:54

How big a difference is 4 ref frames and 15 ref frames for 1080p?
Depends on the source. It's probably not significant for most real life footage, but animated stuff may gain quality with more reference frames (>10 or so).

So i fail to see how using 4 ref frames would be a huge problem
It's not huge unless you already have a lot of encodes with more refs.

UsedUser

5th June 2008, 06:50

So we need a definative answer here:

How big a difference is 4 ref frames and 15 ref frames for 1080p?
And at which point do more ref frames have zero to no effect, from using search it seems that going over 5 ref frames has very little effect.
Depends on the material, of course, so we can't come up with anything definitive.

But, anecdotally, I generally saw a 5th ref frame was used at less than 3% of opportunities. IIRC, the graph for additional ref frames is hyperbolic, limit approaching 0% use.

ref 5: 3%
ref 6: 2%
ref 7: 1.5%

Something like that, I forget. The math isn't right, there.

What happened to the x264 log output that shows the ref frame usage?, e.g.:

x264 [info]: ref P 68.0% 17.8% 6.6% 4.6% 2.9%
x264 [info]: ref B 83.3% 10.7% 2.9% 1.9% 1.2%

foxyshadis

5th June 2008, 16:39

lexor

5th June 2008, 17:12

hmm... that's an interesting point, when you set --ref in x264, is it guaranteed to use all of them? is there a way to check if it did?

tetsuo55

5th June 2008, 17:50

And that's only part of the equation. The more important part is, how much better is a higher reference match than a lower reference? (In aggregate.) So if on average 5% of the frames get 1% better with another reference, you only have a .05% total improvement to the video.

again strenghtening my point..

Ideally the use of 5 or more ref frames should be proven to have less than 20% effect on the total image quality.

If so a max limit of 4 for dxva compatibilty in all cases can be used, this would ensure dxva compatibility on all levels and on all devices (including levels above and below 3 and 4)

Also i wonder if the improvement in anime is really due to the more ref frames or some other reason. if so maybe that other reason could be added to x264 as a patch.

lexor

5th June 2008, 18:09

/EDIT: sorry, wrong thread

Turtleggjp

10th June 2008, 20:50

Has anyone been able to get interlaced video from x264 working with DXVA? My video camera's footage (Canon HF100) seems to be quite unstable at seeking, and I was looking into re-encoding it with x264, but so far I haven't been able to play back the re-encodes correctly. I am able to play back the original clips and get 30i -> 60p de-interlacing using MPC and PowerDVD 8's decoder using my Radeon 3450, but not with anything I have encoded with x264 using the --interlaced option.

I haven't played with x264 for almost 2 years now, so I don't know how far along its support for interlaced video is. I became interested again when I was able to follow the directions in this thread to make some 1080p @ 23.976 clips that do playback accelerated. I am interested in accelerating interlaced video because:

1. My video camera footage is interlaced, and
2. Most of the 1080p video I encode (currently with XviD) is from 1080i broadcasts, and I was interested in seeing how well these would look encoded with x264 and accelerated during playback.

Thanks!

Matt

10th June 2008, 21:31

You'll need a build with x264_hrd_pulldown.04_interlace.diff, like the builds at x264.nl and x264.tk. Then encode with parameters --nal-hrd and --interlaced (or --tff and --bff to specify the correct field order), and specify VBV buffer size and maximum rate.

Related discussion: http://forum.doom9.org/showthread.php?t=137432

Turtleggjp

10th June 2008, 23:26

Thanks! Will give it a try tonight

Turtleggjp

11th June 2008, 18:03

The interlaced video works great now. Now another question.

When I play back a video encoded at 1920x1080 with DXVA (PowerDVD 8), I get a blurry line near the bottom, probably the last 8 lines. Since a mod16 size was mentioned as a requirement, I tried encoding it at 1920x1088 and the blur went away. The only problem is that now it no longer fills my 1920x1080 plasma tv perfectly. Is there a way to encode the video at 1920x1088, but crop the last 8 lines during playback? I see that CoreAVC seems to have this option, but can this also be done either by a setting in the stream, or through some DXVA configuration? Thanks.

Matt

foxyshadis

13th June 2008, 00:36

Update PowerDVD (http://www.cyberlink.com/multi/download/patches_1_ENU.html). Update your video drivers if that doesn't fix it.

P.J

15th June 2008, 12:36

Awesome topic !
Now I can play my mkv files w/ DxVA (8600M GT DDR2 177.41)

For some 720p: IDC Changer 0.3
For 1080p and a few 720p: MeGUI w/ DXVA HQ Profile

But H264info was useless for me.

MPC-HC EVR Custom w/ subtitle, PDVD8 H.264, PDVD8 audio decoder MD3 (doesn't work for DTS :( WHY?), Vista HP x86 w/ Aero
Overall, I don't like MPC-HC's GUI :(

shon3i

29th June 2008, 18:22

Is there any news about nvidia DXVA problem?

P.J

6th July 2008, 12:06

Yes, PV3 which exists in GeForce 9 series. I think it has better post-processing for VC-1/H.264 !

EDIT: Forceware 177.41 supports H.264 720p L5.1.
Now you can play most of H.264 720p files with DxVA.
So you don't need to IDC Changer !

P.J

27th July 2008, 07:09

tetsuo55

3rd August 2008, 19:20

I have updated the first post to be a little more informative.

Also i have rewritten a lot of the information to reflect the current status of hardware compatibility.

What we still need though is:

-Prove that players do or do not all support 50Mbit/s for level 4.1.
-the real-life max bitrate and max CPB have not yet been determined, if you want to help please encode some files and try to find the upper limit.
-Confirmed hardware limits for levels below 3

CruNcher

4th August 2008, 00:02

DONE:
-b-pyramids works on all hardware devices including portable ones since x244 SVN721

Are you sure of that i get heavy problems with PSP (FAT) 720x480 Full SD and b-pyramid for all Encoders ?, i can see with every Encoder strange temporal distortions (it's playable but it doesn't look nice when it happens highering Mhz also doesn't help).

valnar

4th August 2008, 00:14

I agree. I still think encoding without B-pyramids is the way to go, especially for future compatibility too. It doesn't gain you that much.

shon3i

4th August 2008, 07:25

@tetsuo55, how you calculate MAX ref frame limit = 6531840 when MaxDPB for level 3.1 are 6750 so 6750*1024/1.5 = 4608000

Formula for max ref frame is 4608000 / (Height X Width) for level 3.1

tetsuo55

4th August 2008, 09:06

Are you sure of that i get heavy problems with PSP (FAT) 720x480 Full SD and b-pyramid for all Encoders ?, i can see with every Encoder strange temporal distortions (it's playable but it doesn't look nice when it happens highering Mhz also doesn't help).

Now i see what you mean, You are using a resolution that is beyond the capability of the PSP device.
I See that you want to use full resolution videos on your PSP, and in your testing disabling b-pyramids allows you to do so.
To confirm this could you please try a file at 480x272 resolution (PSP screen size, and target for accurate hardware profile) with b-pyramids enabled?

I agree. I still think encoding without B-pyramids is the way to go, especially for future compatibility too. It doesn't gain you that much.
B-Pyramids are 100% standard compliant since x264 has fixed the encoding bug. Also the gains are substantial enough according to the x264 devs

@tetsuo55, how you calculate MAX ref frame limit = 6531840 when MaxDPB for level 3.1 are 6750 so 6750*1024/1.5 = 4608000

Formula for max ref frame is 4608000 / (Height X Width) for level 3.1

You are right, i made a miscalculation.

i updated the formula, thanks!

audyovydeo

4th August 2008, 09:55

tetsuo55

4th August 2008, 10:30

Hello tetsuo and thanks for keeping this thread updated, I think it's one of the most important if we want to maximise the number of compliant streams "out there".

I've just one question regarding your settings : I notice you specify --merange 12, but I don't see how that is a "hard" constraint. I have always used the default of 16. Besides, since it is itself an option of an analysis parameter, I dont see how it should affect profile / level compliance. Am I wrong ?

cheers
audyovydeo

You are not wrong, these presets are old and at the time where made to be balanced in speed.

The only "Restrictions" are max bitrate and max ref frames

When the new MeGui profiles are finalised i will update the presets

lexor

4th August 2008, 13:27

tetsuo55

4th August 2008, 15:54

Well I can tell you that on my psp fat, --b-pyramid produces quite noticeable artifacts on either 480x272 or 720x480. And the later resolution is not "beyond the capability of the PSP device" as you claim, PSP can decode streams of upto 20 Mbps!, I'm sure it can handle a few more pixels at a more common/mild bitrate. Sony just didn't bother to implement the feature (or implement it correctly) in the decoder.

I found the problem, the PSP supports Main@L3.0 and not HIGH@L3.1

Besides that the PSP has a lot of other limitations. Full SD resolution supports seems to be more like a hack than something the PSP was designed to decode. Enabling b-pyramids seems to be hitting some hardware limit with the free settings most people here are using.(probably the added cpu overhead that comes with b-pyramids)

Accurate settings for problem free b-pyarmids playback from memory stick would have a resolution of 320*240 at most, and a very low bitrate to go with that.

It would be interesting to see if the UVD videos used b-pyramids

lexor

4th August 2008, 16:26

tetsuo55

4th August 2008, 16:42

Umm... and? I don't think 3.0 precludes b-pyramid. I'm pretty sure it's just the crappy decoder implementation. MeGUI usually whines like a baby if you pick something that breaks profile, and I can pick b-pyramid just fine.

main3.0 is severely limited when compared to high3.1:

main3.0:MAX DPB=2073600,MAX BITRATE=10MBIT/s(max ref frame at dvd resolution is 5 or 6)
high3.1:MAX DPB=4608000,MAX BITRATE=17.5Mbit/s(max ref frame at dvd resolution is 11 or 13)

Also with main 8×8dct cannot be used

The PSP's official spec lower those settings even more

The official maximum resolution is 368x208, theoretically b-pyramids should only work on this resolution or lower

(if b-pyarmids are indeed broken in the decoder a bug should be reported to sony to have it fixed)

lexor

4th August 2008, 16:47

main3.0 is severely limited when compared to high3.1:

main3.0:MAX DPB=2073600,MAX BITRATE=10MBIT/s(max ref frame at dvd resolution is 5 or 6)
high3.1:MAX DPB=4608000,MAX BITRATE=17.5Mbit/s(max ref frame at dvd resolution is 11 or 13)

Also with main 8×8dct cannot be used

The PSP's official spec lower those settings even more

The official maximum resolution is 368x208, theoretically b-pyramids should only work on this resolution or lower

I'll test that last statement a bit later. As for bitrate, profile may prohibit it, but psp certainly not bound by that bitrate and it needs no vbv buffer restrictions.

tetsuo55

4th August 2008, 16:50

I guess we should thank sony for completely not understanding how to implement levels then hehehe.

Awaiting your result!

Sagekilla

4th August 2008, 17:46

You know the reason why the PSP doesn't obey the bitrate limit (that it can go up to 25 mbps) is because it has a hardware based bitstream decoder, right?

lexor

4th August 2008, 18:13

You know the reason why the PSP doesn't obey the bitrate limit (that it can go up to 25 mbps) is because it has a hardware based bitstream decoder, right?

That's not the reason why it doesn't obey, that's the reason it is capable of supporting higher profiles. The reason it doesn't obey any set profile is because half the programming positions are filled pigeons.

shon3i

4th August 2008, 18:16

main3.0 is severely limited when compared to high3.1:

main3.0:MAX DPB=2073600,MAX BITRATE=10MBIT/s(max ref frame at dvd resolution is 5 or 6)
high3.1:MAX DPB=4608000,MAX BITRATE=17.5Mbit/s(max ref frame at dvd resolution is 11 or 13)

Also with main 8×8dct cannot be used

The PSP's official spec lower those settings even more

The official maximum resolution is 368x208, theoretically b-pyramids should only work on this resolution or lower

(if b-pyarmids are indeed broken in the decoder a bug should be reported to sony to have it fixed)
precisely :)

Level 3.0 Main Profile:

--vbv-bufsize 10000 --vbv-maxrate 10000

Level 3.0 High Profile:

--vbv-bufsize 10000 --vbv-maxrate 12500

Level 3.1 Main Profile:

--vbv-bufsize 14000 --vbv-maxrate 14000

Level 3.1 High Profile:

--vbv-bufsize 14000 --vbv-maxrate 17500

lexor

4th August 2008, 18:34

The official maximum resolution is 368x208, theoretically b-pyramids should only work on this resolution or lower

Nope, no b-pyramid support even at that resolution. Admit it, this has nothing to do with standards, and everything to do with incompetence.

tetsuo55

4th August 2008, 20:24

Nope, no b-pyramid support even at that resolution. Admit it, this has nothing to do with standards, and everything to do with incompetence.

If i understand correctly you just tested a file right?

In that case PSP decoding is indeed broken :(

Could you upload that sample?

lexor

4th August 2008, 21:25

Why? Any sample will work: use Avisynth to resize to any resolution that PSP supports (there aren't many of such resolutions as PSP has no freehand resize), use MeGUI with Shark's PSP profile (just enable b-pyramid). This isn't a specific video issue, they all exhibit horrid artifacts.

tetsuo55

4th August 2008, 21:43

CruNcher

4th August 2008, 23:11

Hey guys we don't have to argue it's not working on the PSP and so it is, so be kind to each other tough someone should try it on the Slim to see if it's fixed if it indeed is then it seems to be more then a Firmware problem (but i guess it is a Firmware problem by Sony tough it could also have something todo with the Custom Firmware)
So wee need people with different PSPs (Firmware) to identify the problem for sure :), but if it is indeed Sonys problem i guess it wont be easy to make them understand that :P, most probably they dont even care, someone could write them a nice e-mail telling them the problem or just wait for the next Firmware and see if its fixed then.
Imho i guess it isnt even a real Firmware problem but Sony just didn't implement it i even dont remember to have read something about b-pyramid (hirachical b-frames) support in the official UMD Spec @ all.
So to be on the safe interoperable side dont use --b-pyramid when you trying to hit the PSP with your content, or tell Sony about it and hope they gonna care and ever support it, wich i highly doubt :(

Sharktooth

5th August 2008, 16:29

@tetsuo, PSP decoding isnt broken... it has its own specs.

tetsuo55

6th August 2008, 10:51

@tetsuo, PSP decoding isnt broken... it has its own specs.

Yeah, they simply decided to break the standard and not support it. Not entirely strange with the psp's relatively slow cpu and/or memory limitations. Although it would have helped UMD with its limited storage space.

Updated first post

shon3i

6th August 2008, 11:28

@tetsuo55, update aslo this on first post http://forum.doom9.org/showthread.php?p=1166537#post1166537.

tetsuo55

8th August 2008, 14:23

My research has revealed some new interesting things about hardware accelleration.

-I read a lot of DXVA and H264 docs
-I ran a lot of edge-case samples on my ATI HD2600
-I used google a lot

Commercially there is only L4.1 media available(the only exception being L3.0 UMD's)

All standalone players will attempt to play back any stream that meets the L4.1 limits

The only place where levels lower than 4.1 is being used is in digital broadcasting and webcasts.

Pending more verification this means we can completely ignore all levels below 4.1. Except for handheld systems.

The_Rebel

12th August 2008, 16:24

Is there any HW decoders that can handle 5.1 yet?

Sulik

12th August 2008, 19:09

Someone mentioned that the NVidia Cuda 2.0 beta drivers (177.xx) do enable support for level 5.1 encodes, but I haven't tried it myself on my 8800GT (sticking to official drivers).

The_Rebel

12th August 2008, 20:44

Someone mentioned that the NVidia Cuda 2.0 beta drivers (177.xx) do enable support for level 5.1 encodes, but I haven't tried it myself on my 8800GT (sticking to official drivers).

Coolness, now i have a real excuse to get a new GPU.

Ranguvar

13th August 2008, 01:47

EDIT: Never mind... bye bye, Windows.

Dark Shikari

13th August 2008, 02:21

valnar

13th August 2008, 02:59

I know of STBs that only support 4.0.

Which ones? I'll make a point of staying away from them.

The_Rebel

14th August 2008, 00:36

EDIT: Never mind... bye bye, Windows.

ROFL, what happened?

I was really looking forward to your results.

tetsuo55

14th August 2008, 17:54

Major rewrite of the first post.

Old post archived here:

I have completely re-written this post to update things to the current situation

All the hardware limitations are clear at this this point:

To encode a hardware compatible file you need to keep the following limits in mind:

-The height and width of the file need to be mod16
-Every device supports different levels. each level has different limits

I will be focusing on level 3.1(Standard definition) and level 4.1(high definition)

Level 3.1 can be used for all resolutions from 16*16 to 720*576, however at these settings the lower resolution files will not work on portable players expecting lower levels.

Level 3.1 limits are:
MAX bitrate: 17.5 Mbit/s
MAX ref frame limit: 4608000 / (Height X Width) = max number of ref frames, this value can never be higher than "16"

Level 4.1 can be used for any resolution higher than 3.1 with an upper limit of 1920*1088
MAX bitrate: 40.0 Mbit/s (standard defines 50 as the limit, if you're hardware players supports 50 please report it in this thread)
MAX ref frame limit: 8355840 / (Height X Width) = max number of ref frames, this value can never be higher than "16"

If you have a file that was already encoded, but it doesn't work there are 4 options:
1.Try the file in MPC-HC if it supports you videocard
2.Use h264info to change the header to level3.1 or level4.1 and try your regular player
3.Use a software decoder like coreavc
4.Transcode the file to be Hardware level compliant.

Non-working files usually means that it was encoded with an old version of x264, has too many ref-frames for its resolution/level or was muxed with an old version of mkvmerge.

TO DO:
-Prove that players do or do not all support 50Mbit/s for level 4.1.
-the real-life max bitrate and max CPB have not yet been determined, if you want to help please encode some files and try to find the upper limit.
-Confirmed hardware limits for levels below 3
-Update this post with level information for levels below 3

DONE:
-b-pyramids works on all hardware devices including portable ones since x244 SVN721
NOTE: the PSP does not support b-pyramids on a hardware level, do not use it if you want your file to work on a PSP. This was a delibarate choice by Sony.

Below are the pre-sets from the old post for encodingThese are very old i will update them when the new megui profiles are out:

Settings for HD
--level 4.1 --ref 3 --mixed-refs --bframes 3 --b-rdo --bime --weightb --direct auto --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-maxrate 25000 --me umh --merange 12 --b-pyramid

Settings for SD
--level 3.1 --ref 3 --mixed-refs --bframes 3 --b-rdo --bime --weightb --direct auto --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-maxrate 25000 --me umh --merange 12 --b-pyramid

Extreme settings (this will be extremely slow):
--level 4.1 --ref * --mixed-refs --bframes 3 --b-rdo --bime --weightb --direct auto --subme 7 --trellis 1 --8x8dct --TESA --merange 24 --no-fast-pskip --partitions al --b-pyramid

Here are some settings for max DBP size

L4.1
1920x1088: 4 (--ref 4)
1920x864: 5 (--ref 5)
1920x720: 6 (--ref 6)

L4.1
1280x720: 9 (--ref 9)
1280x648: 10 (--ref 10)
1280x588: 11 (--ref 11)
1280x540: 12 (--ref 12)
1280x498: 13 (--ref 13)
1280x462: 14 (--ref 14)
1280x432: 15 (--ref 15)
1280x405: 16 (--ref 16)

L3.1
720x(any): 8 (--ref 8)
720x576: 11 (--ref 11)
720x480: 13 (--ref 13)

Level 3.0 Main Profile:

--vbv-bufsize 10000 --vbv-maxrate 10000

Level 3.0 High Profile:

--vbv-bufsize 10000 --vbv-maxrate 12500

Level 3.1 Main Profile:

--vbv-bufsize 14000 --vbv-maxrate 14000

Level 3.1 High Profile:

--vbv-bufsize 14000 --vbv-maxrate 17500

Original referenced threads:
http://www.avsforum.com/avs-vb/showthread.php?t=972503
http://www.avsforum.com/avs-vb/showthread.php?p=12402455
http://forum.doom9.org/showthread.php?p=1088894

Audionut

15th August 2008, 11:48

STEP 3: Make sure use these commands and never cross the limits, shown here are the highest settings(not marked) or mandatory settings(marked with *):

--VBVMaxBitrate 40000
--KeyframeInterval 24*
level-idc = 4.1*
Profile = High*

When using dgavcdec on "Juno" region B for the missus, I got these results.

Bitrate: 0.031
Bitrate (Avg): 31.760
Bitrate (Max): 44.249

tetsuo55

15th August 2008, 12:14

When using dgavcdec on "Juno" region B for the missus, I got these results.

Bitrate: 0.031
Bitrate (Avg): 31.760
Bitrate (Max): 44.249

Can you post the full encoding settings you used?

Audionut

15th August 2008, 12:35

Can you post the full encoding settings you used?

That was ripped from a store bought blu-ray.

My point being that if studios are selling blu-ray's with bit rates above 40 MB/s, I think it's safe to assume that the we can use those bit rates for our level 4.1 encodings.

shon3i

15th August 2008, 14:29

Well maximum bitrate for high and main profiles @ level 4.1 profile is 50000, and buffer size should be 62500 acording Annex A specification of H264 document. But someone on this forum (i think some of x264 devs) say that using high possible settings not good because is too much.

Sharktooth

15th August 2008, 14:43

That was ripped from a store bought blu-ray.

My point being that if studios are selling blu-ray's with bit rates above 40 MB/s, I think it's safe to assume that the we can use those bit rates for our level 4.1 encodings.
those are out of specs BDs. no guarantee they will play in spec compliant devices.
if studios are idiots we dont need to be idiots like them.

tetsuo55

15th August 2008, 16:50

That was ripped from a store bought blu-ray.

My point being that if studios are selling blu-ray's with bit rates above 40 MB/s, I think it's safe to assume that the we can use those bit rates for our level 4.1 encodings.

The settings i posted are SAFE, guaranteed to work,
Depending on who you talk to thhe spec allows for WAY higher limits than has been posted above. But there are litte changes left and right. Sony uses its own limits, bluray does, hd-dvd and even apple.

Using the settings in the first post makes sure it works on all devices and from all media.

the actual bluray-decoder-on-a-chip is supposed to be able to handle 54mbps, the limit is based on the media playback speeds and FastForward things

Sharktooth

15th August 2008, 16:55

tetsuo55

15th August 2008, 17:12

the OFFICIAL BLU-RAY SPECS say 40mbps for blu-ray DISCS.
that means if someone produce a full spec compliant player it may not able to read more than 40mbps FROM THE DISC, it will stutter or wont play the streams...
specs exist for a reason.

Exactly this is why the settings are limited to 40mbps.

i have heard a lot of reports of Bluray disks going over 40mbps, it seems that "Quality Control" is not a priority over at the blu-ray camp

valnar

15th August 2008, 17:45

Does anyone have any data on how high blue-ray movies go? I'm trying to imagine the scene that would require 40mb. A pan of an explosion then fading to black?

tetsuo55

19th August 2008, 11:17

According to this guy over at avsforums:
http://www.avsforum.com/avs-vb/showthread.php?p=14229004#post14229004

Forceware 177.41 supports H.264 720p L5.1.
Now you can play most of H.264 720p files with DxVA.
So you don't need to IDC Changer !

Can anyone with a Nvidia card confirm?

(To confirm you will need a file with the following: 1920*1080, 6 ref frames, bitrate over 60Mbps)

pandy

19th August 2008, 12:37

Which ones? I'll make a point of staying away from them.

AFAIK STM decoders have some problem due architecture flaws (bottlenecks on external bus and arbiters - h.264 decoder itself is OK)

tetsuo55

19th August 2008, 15:31

Updated the settings.

-Minimal/maximal values are now defined better
-Added "min-keyint 4" because lower values break HD-DVD players and possible others as well

CruNcher

19th August 2008, 18:08

tetsuo55 HD-DVD is officialy dead it shouldn't be taken into account for anything anymore (not if it lowers compression efficiency)

DarkZell666

19th August 2008, 18:12

tetsuo55 HD-DVD is officialy dead it shouldn't be taken into account for anything anymore (not if it lowers compression efficiency)

So you deny the existence of all those people who actually bought a HD-DVD player ? :p I know if I had bought one, I wouldn't just toss it right away, those costed quite a bit ... x_x

But I do get your point, it doesn't need to be marked as mandatory, a friendly warning is enough imho :)

CruNcher

19th August 2008, 18:19

@DarkZell666
Sorry but im not sorry for those earlyadopters like you seem to be, everyone knows how the Game is played especialy those who call themselves earlyadopters so they knew the risks (and that their player might endup in the recycle chain sooner than hoped).
Tough im sorry for those who belived all the Marketing and didn't wait and knew that this was a battle between 2 formats, but the Media informed them quite good about the ongoing format War and that only 1 would survive it, so even Avg Joe was aware of the risks.

Sharktooth

19th August 2008, 18:59

Blu-ray can and will die too. if it won the format war it doesnt mean it will survive (infact it's actually dying). so?
there are devices around, so it's worth taking them into account.

tetsuo55

19th August 2008, 19:01

Although i partially agree.

The settings here should be universal, if it reduces compression by a very small percentage then so be it.

However, further discussion in that thread has revealed that:

-x264 already has this rule applied internally(it never breaks compatibility with default settings)
-the problem appears to be caused by the muxer

Setting removed

marc99

20th August 2008, 06:46

According to this guy over at avsforums:
http://www.avsforum.com/avs-vb/showthread.php?p=14229004#post14229004

Originally Posted by P.J
Forceware 177.41 supports H.264 720p L5.1.
Now you can play most of H.264 720p files with DxVA.
So you don't need to IDC Changer !

Can anyone with a Nvidia card confirm?

(To confirm you will need a file with the following: 1920*1080, 6 ref frames, bitrate over 60Mbps)

Driver change nothing. New version of Cyberlink decoder doesn't have 20fps bug with mislabeled files. New version of Cyberlink decoder doesn't need to change level 5.1 -> 4.1 with IDC Changer or h264info.

Audionut

28th August 2008, 02:13

the OFFICIAL BLU-RAY SPECS say 40mbps for blu-ray DISCS.

So I see. http://www.blu-ray.com/faq/

And yet, the 10 movies I've looked at so far have all had video bitrates in excess of 40MB/s.

I can't recall which one, but it had a bitrate of 50MB/s.

kemuri-_9

28th August 2008, 08:27

that faq does have this stipulation in it:
According to the Blu-ray Disc specification, 1x speed is defined as 36Mbps. However, as BD-ROM movies will require a 54Mbps data transfer rate the minimum speed we're expecting to see is 2x (72Mbps)

so as most players already need 2x for their own standardized bitrates of combined audio&video data, going all the up to 72Mbps overall seems viable as well

Audionut

28th August 2008, 09:15

Section 2.4.

Video bit rate (max) 40.0Mbps

But with, Data transfer rate (video/audio) 54.0Mbps (1.5x), that's allowing 14Mbps for audio and subs etc. 5.1 LPCM is only about 7Mbps.

Guest

2nd September 2008, 17:37

AFAIK STM decoders have some problem due architecture flaws (bottlenecks on external bus and arbiters - h.264 decoder itself is OK) That's FUD. Please provide a test stream and state the chip you are using. I can quickly test it here to prove you wrong. I'm a digital video engineer at STM.

You need to be able to support scurrilous disparagement.

UsedUser

5th September 2008, 01:34

According to this guy over at avsforums:
http://www.avsforum.com/avs-vb/showthread.php?p=14229004#post14229004

Can anyone with a Nvidia card confirm?

(To confirm you will need a file with the following: 1920*1080, 6 ref frames, bitrate over 60Mbps)
I did all my previous testing with the Cyberlink PDVD7 decoder. I will test the new Nvidia drivers with both PDVD7 and PDVD8 decoders to isolate the issue/resolution.

Previously, ref=5 @ 1920x1080 @ any bitrate would break DXVA. Why is a ref=6, 60Mbps stream required to test?

Driver change nothing. New version of Cyberlink decoder doesn't have 20fps bug with mislabeled files. New version of Cyberlink decoder doesn't need to change level 5.1 -> 4.1 with IDC Changer or h264info.
But does the new Nvidia driver work with the old PDVD7 decoder? It could be both the drivers and the decoder had fixes applied.

Question: The new Cyberlink decoder plays actual L5.1 streams, or just L4.1 streams with the IDC flag set to 5.1?

tetsuo55

5th September 2008, 10:36

I did all my previous testing with the Cyberlink PDVD7 decoder. I will test the new Nvidia drivers with both PDVD7 and PDVD8 decoders to isolate the issue/resolution.

Previously, ref=5 @ 1920x1080 @ any bitrate would break DXVA. Why is a ref=6, 60Mbps stream required to test?

But does the new Nvidia driver work with the old PDVD7 decoder? It could be both the drivers and the decoder had fixes applied.

Question: The new Cyberlink decoder plays actual L5.1 streams, or just L4.1 streams with the IDC flag set to 5.1?

I said ref 6 and 60mbits because then we can 100% sure that L5.1 is being decoded (L4.1 should never work with those combined)

The file has to be L5.1 this has nothing ot do with the IDC flag (although it might have to be set to L4.1 to trick cyberlink)

blizzbit

25th September 2008, 10:40

Two questions regarding the first post of this thread. :)

1. I'm assuming 8355840 = mod16_width * mod16_height * 4 = 1920 * 1088 * 4, but why?

STEP 1: Determine the REF frame in DPB limit:

8355840 / (Height X Width) = nREF

Imho
Max Ref = Pixel(YV12) / (mod16_width * mod16_height)

In this case for L4.1: Annex A of the H.264 specification shows the Max DPB in bytes for L4.1 is 12288,0 * 1024. Divided by 1,5 to convert from bytes to pixels (1,5 bytes per pixel in YV12 format) is 8388608 (instead of 8355840). So for resolution 1920 * 1088 max refs is 8388608 / (1920 * 1088) = 4 (rounded down).

For L3.0:
Max Ref = 3037,5 * 1024 / 1,5 / (720 * 576)
Max Ref = 2073600 / (720 * 576) = 5 (rounded down)

So for L3.0 it's 2073600 as described in the first post.

STEP 1: Determine the REF frame in DPB limit:

2073600 / (Height X Width) = nREF

2. In STEP2 for L3.0 encoding the highest possible value for CPB is 10000 and max bitrate is 12500.

STEP 2: Make sure use these commands and never cross the limits, shown here are the highest/lowest settings(not marked) or mandatory settings(marked with *):

--vbv-bufsize 10000 (highest possible value)
--vbv-maxrate 12500 (highest possible value)
[...]

But level limits (CPB/Max BR) for L3.0 are 10000/10000 or 12000/12000 (High Profile).

http://img409.imageshack.us/img409/9297/level3da4.th.jpg (http://img409.imageshack.us/my.php?image=level3da4.jpg)http://img409.imageshack.us/images/thpix.gif (http://g.imageshack.us/thpix.php)

So why 10000/12500 for L3.0@High encoding?

Sulik

25th September 2008, 16:42

NVidia official WHQL drivers 178.13 were just released today. It now appears to fully support 1080p files with more than 4 reference frames.

Inventive Software

25th September 2008, 16:46

This being the start of the Level 5.1 support they promised? :rolleyes:

Sulik

25th September 2008, 16:56

I'm guessing it's more like allowing 'out-of-spec' level 4.1, which is really what the level 5.1 content out there really is.

tetsuo55

27th September 2008, 19:07

Two questions regarding the first post of this thread. :)

1. I'm assuming 8355840 = mod16_width * mod16_height * 4 = 1920 * 1088 * 4, but why?

Imho
Max Ref = Pixel(YV12) / (mod16_width * mod16_height)

In this case for L4.1: Annex A of the H.264 specification shows the Max DPB in bytes for L4.1 is 12288,0 * 1024. Divided by 1,5 to convert from bytes to pixels (1,5 bytes per pixel in YV12 format) is 8388608 (instead of 8355840). So for resolution 1920 * 1088 max refs is 8388608 / (1920 * 1088) = 4 (rounded down).

For L3.0:
Max Ref = 3037,5 * 1024 / 1,5 / (720 * 576)
Max Ref = 2073600 / (720 * 576) = 5 (rounded down)

So for L3.0 it's 2073600 as described in the first post.

2. In STEP2 for L3.0 encoding the highest possible value for CPB is 10000 and max bitrate is 12500.

But level limits (CPB/Max BR) for L3.0 are 10000/10000 or 12000/12000 (High Profile).

http://img409.imageshack.us/img409/9297/level3da4.th.jpg (http://img409.imageshack.us/my.php?image=level3da4.jpg)http://img409.imageshack.us/images/thpix.gif (http://g.imageshack.us/thpix.php)

So why 10000/12500 for L3.0@High encoding?

The number you're using is probably a little more accurate than my guesstimate, it doesn't really matter for compliance calculation though. However i updated the first post to match the number you provided so thanks!.

I'm not sure where your screenshot comes from but i got the info off wikipedia\doom9 experts.
http://en.wikipedia.org/wiki/H264#Levels

blizzbit

27th September 2008, 23:15

The number you're using is probably a little more accurate than my guesstimate, it doesn't really matter for compliance calculation though. However i updated the first post to match the number you provided so thanks!
I like your work in this thread. So thank you! :thanks:

I'm not sure where your screenshot comes from but i got the info off wikipedia\doom9 experts.
http://en.wikipedia.org/wiki/H264#Levels
It's from the ITU-T. H.264: Advanced video coding for generic audiovisual services. Recommendation H.264 (11/07), Table A-1 – Level limits, page 283. Take a look here (http://www.itu.int/rec/T-REC-H.264-200711-I/en). There is a PDF file you can download.

azulazules

30th September 2008, 08:59

Hi! I have trouble to DXVA read SD resolution video on HD2400 pro PCI while I have not problem with full HD resolutions (up to 1920px * 1088px 25hz); using MPC HC from v604 to v811.
The problematic video I created is from one of my DVD.
Here are the parameters and the calculations I have made to make sure it is DXVA and level is setup correctly.

I used x264 core 64 r979
Video resolution is: 720x432 (encoded anamorphic DAR 2.35 in MP4)
FPS: 25hz progressive
ref#: 16
bframes#: 5
bpyramid
High@3.2, CABAC, Trellis2
VBVMaxRate=20000
VBVBufSize=3200
BitRate = 587kb/sec
MVRange = 511

Computed DPB = 16*720*432*1.5 = 7464960 (max 7864320 at High@3.2, if I am right)
Computed #MB = 720*432/256 = 1215 (max 5120 at High@3.2, if I am right)
Computed #MB/sec = 1215*25 = 30375 (max 216000, if I am right)

I thought I understood how to make sure DXVA will work on my card, but it seems I am wrong somewhere.

Do you see anything wrong in the above? :confused:
Nice day!

MatMaul

30th September 2008, 12:02

it has been said a million times : ref > 11 doesn't work...

blizzbit

30th September 2008, 12:25

Hi azulazules,

Do you see anything wrong in the above? :confused:
Yep, take a look here (http://www.avsforum.com/avs-vb/showthread.php?t=972503) and here (http://www.avsforum.com/avs-vb/showthread.php?p=12704376#post12704376) (resolution: max num_ref_frames).

Everybody should be encoding to L3.1 with L3.1 set in the stream for SD (576p, 480p, or less).

Keep in mind that, despite the resolution, it is still generally recommended to only use between 1-5 reference frames, usually centering on 3.

The max reference frames can be broken down as follows. The number of reference frames is the max at the given resolution, so if your resolution is between the resolutions given, use the lower number of reference frames (i.e., 1920x816 is between 1920x720 and 1920x864, so you can have a max of 5 reference frames). B-frames count towards one reference frame, which means when encoding with x264, --ref needs to be set to one less than each value (i.e., if max num_ref_frames = 4, then --ref 3 should be used).

Max decoded picture buffer size (MaxDPB) for High@L3.1 is 6750 * 1024 bytes.
Pixel(YV12) = DPB(bytes) / 1,5

Pixel(YV12) / (mod16_width * mod16_height) = Max Ref

Max Ref =

6750 * 1024 / 1,5 / (720 * 432)
= 4608000 / 311040
= 14 (rounded down)

And don't forget this value has to be reduced for b-frames and b-pyramids (see above: 'resolution: max num_ref_frames').

Have a nice day, too! :)

azulazules

30th September 2008, 23:50

@MatMaul & @blizzbit thanks for your time and help!

I decided to dig based on your inputs and linked references to help me understand. All, sorry if the following investigation was done already.

X264 v979 encoded 500 frames at 1280x400@23.976hz Main@4.0 bframe=6, bpyramid to find out:
– with ref#=11: Cyberlink (10% CPU) & MPC Decoder (11% CPU) both did DXVA
– with ref#=12: Cyberlink (10% CPU) did DXVA & MPCHC Decoder (35% CPU) fell back to software ffdshow
– with ref#=16: Cyberlink (10% CPU) did DXVA & MPCHC Decoder (40% CPU) fell back to software ffdshow
using MPC HC v746 each time to render the video.

Maybe Cyberlink did only GPU assisted decoding instead of bitstream, I don't know. But it seems that:
– (assisted?) DXVA is possible with ref# up to 16 with Cyberlink
– bitstream DXVA is possible with ref# up to 11 with MPC HC Decoder

Calculations done:
maxRef# = 12288*1024/(1280*400*1.5) = 16
With 12288kB the size of the DPB for a h264 Main@4.0 compliant decoder (source wiki x264).

X264 (fast) command line I used:
--ref ?? --aq-strength 0.88 --crf 16 --no-chroma-me --me dia --subme 1 --partitions none --trellis 0 --direct auto --bframes 6 --weightb --b-bias 0 --b-pyramid --b-adapt 2 --min-keyint 48 --keyint 480 --no-cabac --progress --no-psnr --no-ssim --level 4

So, I tend to think MPC HC bitstream DXVA is limited to 11 ref and Cyberlink seems capable of a good GPU assisted decoding up to ref#=16 --at least on ATi HD2400Pro.

Then, tried 720x432 @ 23.976, Main@4.0 and:
- Cyberlink did DXVA (10% CPU again)
- MPC HC bitstream decoder fell back to ffdshow software (25% CPU)

And finally, I was able to decode my 720x432 @ 25hz High@3.2 video with DXVA thanks to Cyberlink.
Basic settings used: ref#16, bframes#6, bpyramid!, trellis#2, partitions all but p4x4 with dct, mixedref.

Interesting... :) ...but at the end I guess I will stick to suggested ref#=11 anyway as I like MPC HC DXVA decode better than Cyberlink's (PDVDv7).

Nevertheless, I guess I will ask the MPC HC thread if the limit of ref#11 is due to bitstream decoding technology limitation or miscalculation of the max ref# in MPC HC.

qyqgpower

1st October 2008, 04:27

I've got troubles with SD DXVA on Radeon, the same clip can be decoded flawlessly on NVIDIA card. HD-DXVA is fine with both card.
Tested GPU is
Radeon 4850 with catalyst 8.8 & 8.9: serious random blocky pictures, both MPCHC Internal and Cyberlink Decoder
GeForce 9600GT with 178.13: flawlessly

the x264 setting is pretty hold back for SD-DXVA in my opinion.
--crf 20 --level 3.1 --keyint 240 --min-keyint 24 --ref 5 --bframes 6 --b-adapt 2 --b-rdo --bime --weightb --direct auto --subme 7 --trellis 2 --psy-rd 0:0 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 14000 --vbv-maxrate 14000 --me tesa --merange 32 --threads 3 --thread-input --progress --no-psnr --no-ssim --sar 32:27

even with SD-DXVA profile provided with MeGUI auto-update, I got no luck with a successful SD-DXVA decoding with 4850.
Here is a sample clip: http://www.mediafire.com/?gtnzwjzunyt

Have I missed anything with SD-DXVA encoding?

qyqgpower

1st October 2008, 05:51

I forgot to mention one more situation:
If the SD clip is encoded as interlaced, it can be played flawlessly with Cyberlink Decoder in DXVA mode on Radeon 4850.

--crf 20 --keyint 300 --min-keyint 30 --ref 5 --mixed-refs --bframes 6 --b-adapt 2 --b-pyramid --b-rdo --bime --weightb --subme 7 --trellis 2 --psy-rd 0:0 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 10000 --vbv-maxrate 17500 --me umh --merange 32 --threads 3 --thread-input --progress --no-psnr --no-ssim --interlaced --sar 32:27 --nal-hrd

As you can see, I didn't even specify --level and used --b-pyramid. While it works for interlaced clip, the settings in previous post is totally broken on 4850. So this issue is a bit strange now.

azulazules

2nd October 2008, 10:47

@qyqgpower:
First post you set your 720x480@23.976fps video encode Level to High@3.1 and your settings are OK to me compared to High@3.1 spec'. Second post you do not set Level (and encode interlaced) and I guess High@5.1 is registered by x264 then (you may want to double check that).

Maybe you can try to set the level of your first progressive encode to High@4.1 (four dot one) as this could enable hardware assisted video decoding with Cyberling h264 decoder in PDVDv7 in MPC HC.
I had the same experience as you're having and making sure the level is High@4.1 for SD solved the issue for me (using Cyberlink decoder with MPC HC).

qyqgpower

2nd October 2008, 11:29

Thank you for the reply.
x264 have changed the behavior since r915 when --level is not set . The file encoded with second setting is marked as High@L3.2
The main reason for SD-DXVA is : It's annoying to switch between decoders every time for different kind of files (for example, Interlaced ? Cyberlink(DXVA deinterlcer/IVTC) : CoreAVC)

I'll try your suggestion now.

tetsuo55

2nd October 2008, 12:36

the 11 ref frame limit has several reasons.

Driver limits, hardware limits, decoder implementation limits.

The 16ref frames files should work even with b-pyramids if the encoder correctly encodes the file and the decoder correctly handles the stream.

We need programmers to help create "perfect" decoding specs for MPC-HC in bitstream mode, AND we need help adding assisted decoding. After than everything should be ported back upstream to ffmpeg if and where possible..

qyqgpower

2nd October 2008, 13:44

--level 4.1 for SD-DXVA failed too.
I even tried my HD-DXVA setting with SD material, nothing is changed from displaying totally random (on several rare cases, no blocking was shown during entire playback) blocky pictures.
At the same time, 9600GT is fine with all these test cases.

azulazules

2nd October 2008, 14:17

@qyqgpower:
Do you have AGP Radeon 4850 card --if only it exists? => too low bandwidth AGP causes problem with ATi DXVA I read once somewhere.

Also, will you give these (low on purpose) x264 settings a try for an additional test on your progressive 720x480@23.976fps video?
--ref 12 --crf 16 --no-chroma-me --me dia --subme 1 --partitions none --trellis 0 --direct auto --bframes 6 --weightb --b-bias 0 --b-pyramid --b-adapt 2 --min-keyint 24 --keyint 240 --no-cabac --progress --no-psnr --no-ssim --level 4 --vbv-maxrate 14000 --vbv-buf 3200 --mvrange 511

qyqgpower

2nd October 2008, 15:18

No, I'm using PCI-E 4850.
the above setting still produces same blocky pictures, so I think there must something wrong with AMD's driver or my whole system is screwed up ;)

Sagekilla

2nd October 2008, 15:27

@Matmul: I don't see why that would be true. The number of references frames you can use relates to the size of your frames. Max refs for 1920x1080p = 4 refs, for 1280x720p = 9 refs, for 1280x544p = 11 refs. Once you go to an even lower resolution, like 848x480, you can use 16 refs since it would take up, more or less, the same space in the DPB as 1920x1080 w/ 4 refs or any of the other combinations.

The kicker? I've used DXVA with 16 refs on SD video. No issues.

Also, everyone please keep in mind that issue of having to use less refs in the presence of B's does not exist anymore. It was fixed in an old patch a while ago that automatically reduced the number of b-refs so you wouldn't have to decrease --ref to compensate.

azulazules

2nd October 2008, 15:29

:( Oh...
Now I leave this link to you just in case of it could help: http://home.comcast.net/~exdeus/ati-hd2x00/
If so, let us know.

Edit: back to my home, I was able to test your video is MPC HC Video Decoder bitstream DXVA and Cyberlink PDVD7 DXVA just fine (no blocking). :confused:

Turtleggjp

12th October 2008, 07:48

Is there any danger using more than 3 B frames with hardware acceleration? So far I have tested clips like this (--bframes 5) on a Radeon 3450 and a GeForce 8500GT and have had no trouble. However, I should have a Popcorn Hour A-110 on the way, and I hope that it won't have any trouble either. If so, I'll need to redo a bunch of my HDTV show encodes, and adjust my settings for all the ones I still have to do. Thanks!

Matt

Quark.Fusion

12th October 2008, 12:21

Can someone explain to me how number of b-frames can be limited by hardware if they already supported? Do they need any additional memory or affect other frames?

Turtleggjp

14th October 2008, 15:31

I wouldn't think it would matter, since all you need in memory is the frame before and the frame after the B group. The number of frames in between shouldn't matter. However, I think DVD MPEG2 video is limited to 2 B frames, and I thuoght I read that Blu Ray AVC video was limited to 3 B frames. Although I don't really care about making my videos Blu Ray compatible, I do want the Popcorn Hour A-110 to be able to play them. I was hoping to hear from someone that has one if they are able to play x264 encodes with more than 3 B frames.

laserfan

14th October 2008, 16:27

Although I don't really care about making my videos Blu Ray compatible, I do want the Popcorn Hour A-110 to be able to play them. I was hoping to hear from someone that has one if they are able to play x264 encodes with more than 3 B frames.But maybe it's a crap shoot i.e. "you might get lucky" with >3 B frames, but why risk it?

I'm not on the inside with Sigma Designs (inside the PCH), but if their chipset is designed to be Blu-ray compatible then I would surely want to stick to 3 B frames myself.

Ranguvar

14th October 2008, 20:15

@Quark.Fusion: Companies dealing with video are, in general, collections of idiots.

@laserfun: Huh? "You might get lucky"? The number of b-frames allowed should be fixed across each device of the same model, and it does help to have more... Why would Sigma (logically) want to keep 3 b-fames max, instead of going all-out? I'm sure Joe consumer would be happier with more, even if it just means he can play more of his who-knows-where-they-came-from videos. Even if there's stuttering, it seems to make more sense to at least try to play everything, even if it doesn't work out so well. Of course, companies are idiots...

Turtleggjp

14th October 2008, 21:07

But maybe it's a crap shoot i.e. "you might get lucky" with >3 B frames, but why risk it?

I'm doing it because in my tests, using 5 B frames did offer a good savings on space. I would like to use this if possible.

I'm not on the inside with Sigma Designs (inside the PCH), but if their chipset is designed to be Blu-ray compatible then I would surely want to stick to 3 B frames myself.

According to the Popcorn Hour's website, it supports AVC High Profile @ Level 4.1. It does not say Blu Ray. As far as know, there is no specific limit on number of B frames for level 4.1, other than the maximum of 16 for the AVC standard. Am I wrong?

Quark.Fusion

14th October 2008, 23:24

As Dark Shikari says:There is no max number of B-frames in any H.264 profile (except obviously Baseline). x264's limit of 16 is simply arbitrary for technical reasons.

laserfan

15th October 2008, 02:28

I'm doing it because in my tests, using 5 B frames did offer a good savings on space. I would like to use this if possible.

According to the Popcorn Hour's website, it supports AVC High Profile @ Level 4.1. It does not say Blu Ray. As far as know, there is no specific limit on number of B frames for level 4.1, other than the maximum of 16 for the AVC standard. Am I wrong?I have a PCH A100 and from what I can gather from the PCH forum site, whenever anyone complains about files that don't play, B-frames >3 are cited as one possible reason.

You might want to surf that forum, or join-and-post there about 5 B-frames.

Sagekilla

15th October 2008, 06:03

Ergh, how unfortunate.. Popcorn Hour looks -extremely- tempting but I wouldn't bother re-encoding my movies with 6 B's from the original Blu-ray again.

Turtleggjp

15th October 2008, 15:13

Exactly my point, except for me it's not only Blu Rays but TV shows I have captured. This means that until I know for sure (when I get the PCH, probably not until early next month) I'll be holding on to my original .ts recordings so I can re-encode from the source if needed. That's about 13GB per week. I think I can manage that.

laserfan

15th October 2008, 17:43

Well, don't shoot me if I'm wrong, but it did appear to me that this was an issue with the PCH.

I never download videos off the internet--that seems to be where most of the complaints are coming from on that forum (where anything goes it seems wrt video origins)... :scared:

UsedUser

15th October 2008, 23:06

Can someone explain to me how number of b-frames can be limited by hardware if they already supported? Do they need any additional memory or affect other frames?
B-frames require references, and hardware has ref / DPB size limits.

Mr VacBob

16th October 2008, 00:13

That limits B pyramid depth, not B-frames, and x264 only supports one-level-deep B-pyramid.

Sagekilla

16th October 2008, 05:37

Would using deeper levels of B-Pyramid help any?

UsedUser

17th October 2008, 00:18

professor_desty_nova

17th October 2008, 08:08

Yeah, ya got me there. I was thinking of how enabling B-pyramid used to increase DPB size beyond the value specified by --ref. Now that we have that fix, B-pyramid doesn't cause DPB size to exceed the --ref value, and it doesn't have anything to do with the number of B-frames used, anyway.

Acording to the thread B-pyramids breaking DPB limits discussion (http://forum.doom9.org/showthread.php?t=140223), it seems there are ocasions where b-pyramids still break the DPB limit. Since I don't remember seeing a fix for it in the git since this discussion, if you want a 100% compliant AVC stream don't use b-pyramids for now.

UsedUser

17th October 2008, 23:10

Acording to the thread B-pyramids breaking DPB limits discussion (http://forum.doom9.org/showthread.php?t=140223), it seems there are ocasions where b-pyramids still break the DPB limit. Since I don't remember seeing a fix for it in the git since this discussion, if you want a 100% compliant AVC stream don't use b-pyramids for now.
I believe that's a little different.

--ref used to specify an absolute number of references for any frame; now it specifies DPB size.

The problem is that with --ref=x, B-pyramid currently requires DPB=x+1.

The result isn't exceeding the DPB size, it's a broken reference to a frame that isn't in the DPB.

UsedUser

17th October 2008, 23:35

That limits B pyramid depth, not B-frames, and x264 only supports one-level-deep B-pyramid.

Yeah, ya got me there. I was thinking of how enabling B-pyramid used to increase DPB size beyond the value specified by --ref. Now that we have that fix, B-pyramid doesn't cause DPB size to exceed the --ref value, and it doesn't have anything to do with the number of B-frames used, anyway.
Disregard my concession above. I believe it does limit B-frames. Someone can correct me if I'm wrong.

The number of B-frames is related to DPB size. B-frames require references. You can't have more referenced frames than frames in the DPB. Enabling B-pyramids exacerbates the situation further, by requiring an additional frame in the DPB to satisfy all references.

Back to my original assertion:

Adding more B-frames requires more references. More references may require more frames to be stored in the DPB. DPB is limited on hardware, whether artificially by decoder profile level limits (i.e., L4.1), or by absolute quantity of memory.

MasterNobody

18th October 2008, 00:46

Adding more B-frames requires more references.You are wrong in this statement and that why your conclusion is incorrect.

UsedUser

18th October 2008, 01:35

You are wrong in this statement and that why your conclusion is incorrect.
Ok. Care to explain?

I went back over my DXVA tests and thought it through, and it seems to hold true, but I'm not entirely sure why.

If you've got more B-frames than allowed frames in the DPB (i.e., --ref 4 --bframes 16), are decoded B-frames only allowed to reference other frames within the DPB? The number of B-frames indicates the number of B-frames per... what?

akupenguin

18th October 2008, 11:20

Conventional B-frames don't go into the DPB. They're just decoded, immediately displayed, and discarded. The decoder can do that any number of times in a row without changing state.

asarian

19th October 2008, 14:43

I'm not sure if this is the right place to ask, but will x264 support CUDA (Compute Unified Device Architecture) in the future? Right now, re-encoding a 1080p VC-1 stream can easily take > 20 hours on my quad-core (with some hefty settings). It sure would be nice if this could be done 7x times faster (to follow nVidia's claim) using, say, a GeForce GTX 280.

The idea of using a GPU is good anyway, right?

Sagekilla

19th October 2008, 19:16

So theoretically, we could have a more or less motionless scene that has one keyframe followed by hundreds of B's? Like IBB(1000)P or something, and the decoder would be fine with this?

Shinigami-Sama

19th October 2008, 22:05

asarian

20th October 2008, 04:39

discussed to death
:search:

That's the problem, isn't it? :) Much "YAY! Wouldn't it be nice if we had it!" or "Its in the works for x264", but nothing concrete, let alone examples on how to use it on a command-line.

Sagekilla

20th October 2008, 05:11

I'm sorry, what are you trying to say? there is no GPU acceleration for x264, everything available is easy to find using --longhelp and there's no real future for GPU based encoding for x264 at this time. It's simply not feasible right now, and it's already been tried.

Go ahead, do some searching and you'll find Dark Shikari already attempted to (and even Avail Media, I believe) port something as simple as the SAD function to the GPU, and it performed miserably compared to the CPU version because of how difficult it is to optimize for a GPU.

Yes, the idea of using a GPU is good for encoding. You basically have a massively parallel processor to work with, but it's so difficult to code for that no one is pursuing it. Plus, the commercial implementations that do exist absolutely suck both speed and quality wise. x264 is easily as fast and better quality than the commercial apps, so there's no point in trying them (they're all baseline I believe)

asarian

20th October 2008, 06:20

Turtleggjp

21st October 2008, 02:09

Conventional B-frames don't go into the DPB. They're just decoded, immediately displayed, and discarded. The decoder can do that any number of times in a row without changing state.

This makes the most sense to me, but then what about when you enable b-pyramid? Doesn't that mean that now B frames can also be referenced, meaning they would need to be kept in the DPB?

Sagekilla

21st October 2008, 02:28

The ones that do get referenced, yes, would be put into the DPB. Not all B's are referenced though.

P.J

22nd October 2008, 19:10

Is there any way to play incompatible files with DxVA?
Even tsMuxeR doesn't work. It just gives me lots of artifacts xD (5.1 -> 4.1)

Sulik

23rd October 2008, 02:40

The biggest problem with B-pyramid & DXVA is that MPC-HC does not support it (it ignores explicit reordering of re-ordered B-frames).

P.J

23rd October 2008, 18:08

what about cyberlink ?

tetsuo55

23rd October 2008, 19:57

The biggest problem with B-pyramid & DXVA is that MPC-HC does not support it (it ignores explicit reordering of re-ordered B-frames).

Do you have any technical reference to support this claim?

I agree that the DXVA implementation has some problems, but that should not be one of them (besides b-pyramids decoding breaks on consoles and some dedicated players too)

tofans

27th October 2008, 12:52

27th October 2008, 13:26

I have a few problems regarding interlaced DV encoded to x264 and playback using a GPU deinterlacer.
It seems that the GPU decoder doesn't recognize the input as being interlaced, because there is no deinterlacing applied to the image.
If I encode the same videostream using an old mainconcept encoder using the field-based or MBAFF setting, the GPU deinterlaces the video just nicely.
Is there any x264 option, that I am missing here? I tried all combinations of the "--tff" "--bff" "--interlaced" "--nal-hrd" options, but none of them seems to do the trick.
Do you have an x264 build that includes the nal-hrd patch? Note that you also need to set the VBV buffer size and maximum bitrate parameters (for example --vbv-bufsize 30000 --vbv-maxrate 30000 --nal-hrd --tff) because otherwise nal-hrd is disabled and it won't write any additional information to the stream.

tofans

27th October 2008, 17:08

Yes, I am pretty sure that the build includes the nal-hrd patch, otherwise "--longhelp" wouldn't offer such an option, right?
Thanks for your explanation, I included these options in my command line, but my first test indicate that the output video is still not deinterlaced by the GPU.
Is there any way to verify that certain flags are set in the videostream?

27th October 2008, 18:01

Yes, I am pretty sure that the build includes the nal-hrd patch, otherwise "--longhelp" wouldn't offer such an option, right?
Yes.

Thanks for your explanation, I included these options in my command line, but my first test indicate that the output video is still not deinterlaced by the GPU.
Is there any way to verify that certain flags are set in the videostream?
One way is to use h264_parse from the MPEG4IP project. It is a command-line tool that parses raw H.264 streams. Search the output for pict_struct, which is 3 for TFF and 4 for BFF.

If you can't find a Windows build of h264_parse, upload a sample clip and I'll take a look at it (I have MPEG4IP tools on Linux, so I can't help you with Windows executables).

tofans

27th October 2008, 18:51

First of all, a big "thank you" for your support!
I uploaded a sample clip onto http://drop.io/x264sample

This is the command line I used:
--crf 23.0 --level 4.1 --ref 3 --mixed-refs --bframes 3 --weightb --filter -1:-1 --subme 2 --trellis 1 --vbv-bufsize 30000
--vbv-maxrate 30000 --merange 12 --threads auto --thread-input --progress --no-psnr --no-ssim --output "output" "input" --nal-hrd --bff

I found a win32 build of h264_parse, but only found this entry regarding pic_struct:
pic_struct_present_flag: 1

27th October 2008, 19:18

--crf 23.0 --level 4.1 --ref 3 --mixed-refs --bframes 3 --weightb --filter -1:-1 --subme 2 --trellis 1 --vbv-bufsize 30000
--vbv-maxrate 30000 --merange 12 --threads auto --thread-input --progress --no-psnr --no-ssim --output "output" "input" --nal-hrd --bff
Your --nal-hrd and --bff options are at a wrong position. Move them before "input":
--crf 23.0 --level 4.1 --ref 3 --mixed-refs --bframes 3 --weightb --filter -1:-1 --subme 2 --trellis 1 --vbv-bufsize 30000
--vbv-maxrate 30000 --merange 12 --threads auto --thread-input --progress --no-psnr --no-ssim --nal-hrd --bff --output "output" "input"

Edit: well, that probably isn't a problem though. My version of h264_parse reports that everything should be fine with your sample. There are SEIs with pict_struct=4.

Next step would be to compare the SEI data of these x264 encodes to that of Mainconcept MBAFF, which you said was deinterlaced properly.

tofans

27th October 2008, 21:56

28th October 2008, 07:37

Sorry, my bad, Mainconcept and MBAFF is a also a no go.
Only field-based interlaced coding does the trick, which is sadly not available in x264.
So is this a general problem with the GPU decoder and MBAFF in gerneal, or is it just a flag that doesn't get passed to the renderer?
I don't know much about DXVA, but I think the problem is either in the DXVA filter or the driver-side implementation. Have you tried both CyberLink's filter and the one in MPC HC?

EDIT: I have uploaded a sample clip (same location as previously) of BBCHD with MBAFF interlacing which is getting perfectly deinterlacerd by the GPU. Maybe you can spot the differences between my encodes and the BBCHD stream.
An obvious difference is that the BBCHD clip is TFF while your clip was BFF. Maybe the decoder always expects MBAFF to be TFF, or simply doesn't understand that pict_struct=4 means BFF interlaced. Could you try if this x264-encoded TFF sample (http://www.cs.helsinki.fi/u/mikkila/video/hdvtest/test-x264-1080i25-nalhrd.mkv) gets deinterlaced?

G_M_C

28th October 2008, 09:30

Is there any way to play incompatible files with DxVA?
Even tsMuxeR doesn't work. It just gives me lots of artifacts xD (5.1 -> 4.1)

Just a though: Why dont you simply go back to the source, and re-do your encode while adhering to the 4.1 specs ? You do have the source right ?

Cause that's the only way of getting it to play on DXVA ...

PS: B-pyramids seem to be tricky though, which is somehow strange. B-pyramids can be used on BD-compatible streams, my stand-alone Pana BD30 accepts them with no problems. Why some DXVA / GPU's won't ... I dont know.

tofans

28th October 2008, 10:41

Could you try if this x264-encoded TFF sample (http://www.cs.helsinki.fi/u/mikkila/video/hdvtest/test-x264-1080i25-nalhrd.mkv) gets deinterlaced?
Thanks for the sample.
No, sadly it doesn't. I tried it both, the internal MPC DXVA decoder and the Cyberlink decoder. I also tried "DGAVCIndexNV" but there is no deinterlacing applied, even if I specifically select "use PureVideo deinterlacer".
So I guess there must be some weird flag present in the BBCHD stream, which triggers the deinterlacing fuction of DXVA, but which is not present in the x264 encodes. :confused:

28th October 2008, 12:38

So I guess there must be some weird flag present in the BBCHD stream, which triggers the deinterlacing fuction of DXVA, but which is not present in the x264 encodes. :confused:
Perhaps. We would need to ask advice from someone who knows the specs better (or how your DXVA decoder implementation works). I couldn't spot any relevant differences in the interlacing/field order signals of these streams.

30th October 2008, 09:40

Ok, neuron2 explains the problem in this thread: http://forum.doom9.org/showthread.php?t=142427
...or at least that could be one factor.

max2k2

28th February 2009, 04:32

I did not found it in the initial post of this thread, but heard some where that you should disable a macroblock size if 4*4 for P-Frames under x264 if you like to encode DXVA-compatible. Is this true?

I plan to use a aac with 80kbs Adabtive Bitrate in mp4 for my encode. Coulde this audioformat introduce any troubels for DXVA SAP`s?

UsedUser

28th February 2009, 09:07

you should disable a macroblock size if 4*4 for P-Frames under x264 if you like to encode DXVA-compatible. Is this true?
Yes. Can't quote a source atm, but it originates with game console compatibility, and extends generally to DXVA.

I plan to use a aac with 80kbs Adabtive Bitrate in mp4 for my encode. Coulde this audioformat introduce any troubels for DXVA SAP`s?
I haven't seen any DXVA issues related to audio streams. The video codec doesn't get the stream until after demux. Your stream splitter sends video to the video decoder, and audio to the audio decoder.

looney

3rd June 2009, 00:45

It's the maximum decoded picture buffer that determines the limit.
1920x1080x4 = 8294400
1280x720x9 = 8294400

So 900p would have a limit of
8294400/(1600*900) = 5.76 reference frames

Why does this happen? Because hardware decoders are only going to add as much cache into the chip as necessary, otherwise you'll be wasting transistor / increasing die space. Software decoders can just allocate as much memory as they feel like since you already have hundreds of megs of ram.

I think it's nothing to do with GPU's on-chip cache beause GPUs dont have that much cache on die nor it's needed when they have plenty of too fast memory for plain 2d+t enhancement. Believe all buggy lies in dsp to be equipped with enough cheap ram and 8M was probably something they came in 2002/3 when they developing h264 as cheap enough solution for consumer electronics in 5year timeframe.

Yeah, thing is it would be very easy and cheap to implement an (not even high speed is necessary) external 32 MB of RAM with a few leads to the main chip. With that, you can easily fit up to 15 (you'd need an extra 1.7 MB for the 16th one) reference frames for 1080p content.

I think something is wrong with that math. Cause more monolithic space cant be fragmented with same size frags that you end up in something smaller than a multiplier of frags number when used on X times smaller space (16,18fps) Anyway i think they firs reinvent the latform in another revision before they simply add up more memory allocation to L4.1. Like that will ever happen. Cant they just add new sublevel L4.2-L4.3 that has that new improved buffer and lot of new CE for sale in next 5 years.

tetsuo55

3rd June 2009, 07:30

I think it's nothing to do with GPU's on-chip cache beause GPUs dont have that much cache on die nor it's needed when they have plenty of too fast memory for plain 2d+t enhancement. Believe all buggy lies in dsp to be equipped with enough cheap ram and 8M was probably something they came in 2002/3 when they developing h264 as cheap enough solution for consumer electronics in 5year timeframe.

I think something is wrong with that math. Cause more monolithic space cant be fragmented with same size frags that you end up in something smaller than a multiplier of frags number when used on X times smaller space (16,18fps) Anyway i think they firs reinvent the latform in another revision before they simply add up more memory allocation to L4.1. Like that will ever happen. Cant they just add new sublevel L4.2-L4.3 that has that new improved buffer and lot of new CE for sale in next 5 years.The cache is just a number they decide on (although there are guidelines to how big it should be)

Theoretically an GPU could have a cache as large as its onboard RAM.
Nvidia recently decided to upsize the cache to L5.1(it's a driver limitation, not a hardware one). This means that any stream will work as long as it never goes over 17 (depending on what encoding settings you used 16 ref frames will often not work)