2 similar encodes, only 1 works on hardware decoder

[tetsuo55]

While testing the limits of the DXVA decoder capabilities i ran into these 2 samples:

Sample files BAD and OK.

http://www.sendspace.com/file/hcoi0u

http://www.sendspace.com/file/nvd45j


They are almost identical except for the bframes and pixel aspect ratio. Do any of the experts here have any idea why the BAD file would not work on the hardware decoder?

[Sagekilla]

Reference frames could be the problem off the top of my head. I'll take a look closely at the encoding settings when I get the chance to and tell you exactly what.

[tetsuo55]

Reference frames could be the problem off the top of my head. I'll take a look closely at the encoding settings when I get the chance to and tell you exactly what.

Both have the same number of ref frames, 16

[Sagekilla]

Hm, that's odd. What hardware decoder are you targetting?

[tetsuo55]

It should work on everything that supports L3.1 and up. But specifically DXVA videocards

[Sharktooth]

16 bframes on DXVA? nope... post your commandline.

[Sagekilla]

You sure about this? Those were level 5.1 encodes, and while you CAN use a resolution of 704x400 with 16 refs, I somehow doubt they're both completely compatible.

[Sharktooth]

it all depends on the DPB size and obviously on the video card (decoder chip capabilities) and DXVA software implementation (decoder).

[tetsuo55]

If you open the file with something like avinaptic. You will see that the points you both mention are identical for both files.

16 ref frames definately does work on DXVA, but due to bugs in the decoders it doesn't work for everyone yet.

This file does not work:

[ Relevant data ]

Resolution: 704 x 400
Width: multiple of 32
Height: multiple of 16

[ Video track ]

Codec ID: V_MPEG4/ISO/AVC
Resolution: 704 x 400
Frame aspect ratio: 44:25 = 1.76 (~16:9)
Pixel aspect ratio: 1:1 = 1
Display aspect ratio: 44:25 = 1.76 (~16:9)
Framerate: 23.976024 fps

[ About H.264 encoding ]

User data: x264
User data: core 59 r819M 0414d78
User data: H.264/MPEG-4 AVC codec
User data: Copyleft 2003-2008
User data: http://www.videolan.org/x264.html
User data: cabac=1
User data: ref=16
User data: deblock=1:1:1
User data: analyse=0x3:0x113
User data: me=umh
User data: subme=7
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=2
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=16
User data: b_pyramid=1
User data: b_adapt=1
User data: b_bias=0
User data: direct=3
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=816
User data: ratetol=1.0
User data: rceq='blurCplx^(1-qComp)'
User data: qcomp=1.00
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=2:1.00
SPS id: 0
Profile: High@L5.1
Num ref frames: 16
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


This file works perfectly fine:

[ Relevant data ]

Resolution: 704 x 400
Width: multiple of 32
Height: multiple of 16

[ Video track ]

Codec ID: V_MPEG4/ISO/AVC
Resolution: 704 x 400
Frame aspect ratio: 44:25 = 1.76 (~16:9)
Pixel aspect ratio: 711:704 = 1.009943
Display aspect ratio: 711:400 = 1.7775 (~16:9)
Framerate: 23.976024 fps

[ About H.264 encoding ]

User data: x264
User data: core 58 svn-736M
User data: H.264/MPEG-4 AVC codec
User data: Copyleft 2003-2008
User data: http://www.videolan.org/x264.html
User data: cabac=1
User data: ref=16
User data: deblock=1:0:0
User data: analyse=0x3:0x133
User data: me=umh
User data: subme=7
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=2
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=660
User data: ratetol=1.0
User data: rceq='blurCplx^(1-qComp)'
User data: qcomp=1.00
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.5:13.0
SPS id: 0
Profile: High@L5.1
Num ref frames: 16
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

[Sharktooth]

not all decoders.
the cyberlink one wont ever support 16 b-frames. the only one that support them on the paper but still doesnt work is the MPC-HC one.
and however im still not sure it will work.

[audyovydeo]

The card & the driver also play a role.
With the hundreds versions of nvidia forceware, plus everyone modding the infs, I bet there isn't a single identical combination of OS+card+forceware+player on the planet, as of right now.
And we're looking at differences in video files ?

cheers
a/v

[talen9]

The first one (the one not working) was encoded with a "maximum consecutive b-frames" setting of 16, the working one has only 3 max. consec. b-frames ... this is where the two samples differ most, if you look only at the report.

[Sharktooth]

oh... then 16Bs doesnt work.
it's as simple as that.

[tetsuo55]

Thats what i though too. so i encoded some samples with 16bframes(but not pyramids) and that file worked perfectly fine

[Sharktooth]

have you set --no-b-adapt in the commandline? that will force to use the number of bframe you set, otherwise the encoder will decide everytime how many bframes, between 0 and what you set, will be used between each I/P.

[tetsuo55]

have you set --no-b-adapt in the commandline? that will force to use the number of bframe you set, otherwise the encoder will decide everytime how many bframes, between 0 and what you set, will be used between each I/P.

No i didn't, thanks for pointing that out. I will have to retest with that setting. (the non working file has b-adapt enabled though)

[Sagekilla]

--b-pyramid can be a problem if you're not using the patch that automatically uses 1 less ref for B's -- So if you had 9 refs, it would set 8 for B-frames. Still, that SHOULDN'T be a problem.

[nurbs]

IIRC you also have to use "scenecut -1" (or something like that, I can't remember the exact switch) if you want the maximum number of b-frames.

[tetsuo55]

--b-pyramid can be a problem if you're not using the patch that automatically uses 1 less ref for B's -- So if you had 9 refs, it would set 8 for B-frames. Still, that SHOULDN'T be a problem.

That was patch was commited in rev 721, both files where encoded with much later versions.

Personally i also think its the b-frames that are causing the problems, however i have no idea how or why

IIRC you also have to use "scenecut -1" (or something like that, I can't remember the exact switch) if you want the maximum number of b-frames.

Thanks i will add that too

[Dark Shikari]

--b-pyramid can be a problem if you're not using the patch that automatically uses 1 less ref for B's -- So if you had 9 refs, it would set 8 for B-frames. Still, that SHOULDN'T be a problem.Patch? Its been in official x264 for nearly a year now.