Weightp 2 corrupts image on PS3

[SquallMX]

Hi there, I'm having an image corruption problem when playing my BDrip using the PS3:

http://www.imagechile.net/img/DSCF00441792.jpg

This is the first time I use Weightp, is this the cause of the problem?

I'm using x264 ver 1342 by techouse on Windows 7 Ultimate 64-bit.

My settings are:
"C:\Program Files (x86)\megui\tools\x264\x264.exe" --profile high --level 4 --pass 2 --bitrate 3500 --stats "D:\Temp\DVDTemp\TLH\TLH.stats" --thread-input --deblock -2:-1 --keyint 48 --min-keyint 4 --b-adapt 2 --direct auto --ref 4 --qpmax 44 --ipratio 1.1 --pbratio 1.2 --vbv-bufsize 24000 --vbv-maxrate 15000 --rc-lookahead 48 --aq-strength 0.8 --me umh --partitions p8x8,b8x8,i4x4,i8x8 --psy-rd 0.80:0 --ssim --bframes 3 --mvrange 511 --aud --nal-hrd --sar 1:1 --weightp 2 --output "D:\Temp\DVDTemp\TLH\TLH.mkv" "D:\Temp\DVDTemp\TLH\TLH.avs"

:thanks:

Update: same thing happens with Total Media Theater 3:

http://www.imagechile.net/img/CI102823261356.jpg

[Dark Shikari]

Have you checked a compliant decoder like libavcodec to see if the problem is in the stream? For that matter, can you post something actually useful, like the stream itself, as opposed to useless screenshots?

I've had multiple people test on the PS3 and none have reported problems as of yet.

[SquallMX]

Have you checked a compliant decoder like libavcodec to see if the problem is in the stream? For that matter, can you post something actually useful, like the stream itself, as opposed to useless screenshots?

I've had multiple people test on the PS3 and none have reported problems as of yet.

Hi, MPC-HC (DXVA) plays the file fine, DGIndexNV (Ver 2, Beta 2) have the same problems, sample:

http://rapidshare.com/files/310828190/Test.demuxed.264

Thanks for your time.

[Dark Shikari]

Hi, MPC-HC (DXVA) plays the file fine, DGIndexNV (Ver 2, Beta 2) have the same problems, sample:Interesting: this means that it's a software problem, not a real decoder issue, since DGIndexNV and DXVA should be using exactly the same actual hardware decoder.

Maybe neuron2 should have a look at this?

[Dark Shikari]

Something seems horrifically weird about that stream. The first P-frame in the stream has more than one reference frame. How did you create it the stream? Give full details about settings, and if possible, can you create it without splitting it in the middle?

Can you also try using an unpatched x264 rather than one with (potentially buggy) patches?

[SquallMX]

Something seems horrifically weird about that stream. The first P-frame in the stream has more than one reference frame. How did you create it the stream? Give full details about settings, and if possible, can you create it without splitting it in the middle?

Can you also try using an unpatched x264 rather than one with (potentially buggy) patches?

Hi, the movie is "The Last House on the Left (2009)", source is Blu-ray Region A, ripped using AnyDVD 6.6.0.3, DGIndexNV Beta 2 used as frame server for Avisynth 2.5.8, encoded using MeGUI (I know... current build is outdated), x264 version 1342 from techouse patched with "x264_win_zone_parse_fix_06.diff" and "x264_hrd_pd_interlace.16_r1301.diff ".

I encoded the full movie, the sample was extracted using DGIndexNV, I tried to make a bigger sample but i was unable to go before the first frame of the sample (DGIndex stopped responding).

Data from Avinaptic:

[ Relevant data ]

Resolution: VERY HIGH (1280 x 720)
Width: multiple of 32 (GOOD)
Height: multiple of 16 (GOOD)
Average DRF quality: MEDIUM (25.204829)
Standard deviation quality: HIGH (1.044169)
Std. dev. weighted mean: HIGH (1.041773)

[ 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
Stream size: 2,981,228,735 bytes
Play duration: 01:53:38 (6817.769073 s)
Bitrate: 3498.186814 kbps
Qf: 0.158315

[ Audio track nr. 1 ]

Codec ID: A_DTS
Channels (container): 6
Sample rate: 48000 Hz
Stream size: 654,512,128 bytes
Bitrate (container): 767.999962 kbps

[ Audio track nr. 2 ]

Codec ID: A_DTS
Channels (container): 6
Sample rate: 48000 Hz
Stream size: 654,510,080 bytes
Bitrate (container): 767.997559 kbps

[ About H.264 encoding ]

User data: x264
User data: core 79 r1342M e8501ef
User data: H.264/MPEG-4 AVC codec
User data: Copyleft 2003-2009
User data: http://www.videolan.org/x264.html
User data: cabac=1
User data: ref=4
User data: deblock=1:-2:-1
User data: analyse=0x3:0x113
User data: me=umh
User data: subme=7
User data: psy=1
User data: psy_rd=0.8:0.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=-2
User data: threads=3
User data: nr=0
User data: decimate=1
User data: mbaff=0
User data: constrained_intra=0
User data: bframes=3
User data: b_pyramid=0
User data: b_adapt=2
User data: b_bias=0
User data: direct=3
User data: wpredb=1
User data: wpredp=2
User data: keyint=48
User data: keyint_min=4
User data: scenecut=40
User data: rc_lookahead=48
User data: rc=2pass
User data: mbtree=1
User data: bitrate=3500
User data: ratetol=1.0
User data: qcomp=0.60
User data: qpmin=10
User data: qpmax=44
User data: qpstep=4
User data: cplxblur=20.0
User data: qblur=0.5
User data: vbv_maxrate=15000
User data: vbv_bufsize=24000
User data: ip_ratio=1.10
User data: aq=1:0.80
SPS id: 0
Profile: High@L4
Num ref frames: 4
Aspect ratio: Square pixels
Chroma format idc: YUV 4:2:0
PPS id: 0 (SPS: 0)
Entropy coding type: CABAC
Weighted prediction: P slices - explicit weighted prediction
Weighted bipred idc: B slices - implicit weighted prediction
8x8dct: Yes
Number of frames: 163463
Drop/delay frames: 0
Corrupted frames: 0

P-slices: 57101 ( 34.932 %) #################
B-slices: 102442 ( 62.670 %) ##############################
I-slices: 3920 ( 2.398 %) #
SP-slices: 0 ( 0.000 %)
SI-slices: 0 ( 0.000 %)

[ DRF analysis ]

Average DRF: 25.204829
Standard deviation: 1.044169
Max DRF: 31

DRF<19: 0 ( 0.000 %)
DRF=19: 7 ( 0.004 %)
DRF=20: 493 ( 0.302 %)
DRF=21: 1378 ( 0.843 %) #
DRF=22: 1468 ( 0.898 %) #
DRF=23: 4562 ( 2.791 %) ##
DRF=24: 20910 ( 12.792 %) #########
DRF=25: 69406 ( 42.460 %) ##############################
DRF=26: 54900 ( 33.586 %) ########################
DRF=27: 9987 ( 6.110 %) ####
DRF=28: 345 ( 0.211 %)
DRF=29: 6 ( 0.004 %)
DRF=30: 0 ( 0.000 %)
DRF=31: 1 ( 0.001 %)
DRF>31: 0 ( 0.000 %)

P-slices average DRF: 25.246020
P-slices std. deviation: 1.026094
P-slices max DRF: 31

B-slices average DRF: 25.197926
B-slices std. deviation: 1.051284
B-slices max DRF: 29

I-slices average DRF: 24.785204
I-slices std. deviation: 1.021596
I-slices max DRF: 28

Can you point me to the vanilla build of x264 of your preference? I will try again with that build.

:helpful:

[Dark Shikari]

I need the following:

1. A source sample, which, when encoded with x264 using your settings, generates the problem. The smaller the source sample, the better.

2. The exact settings used on both first and second passes.

Without these things, I cannot investigate.

[SquallMX]

I need the following:

1. A source sample, which, when encoded with x264 using your settings, generates the problem. The smaller the source sample, the better.

2. The exact settings used on both first and second passes.

Without these things, I cannot investigate.

First Pass:
"C:\Program Files (x86)\megui\tools\x264\x264.exe" --profile high --level 4 --pass 1 --bitrate 3500 --stats "D:\Temp\DVDTemp\TLH\TLH.stats" --thread-input --deblock -2:-1 --keyint 48 --min-keyint 4 --b-adapt 2 --direct auto --ref 4 --qpmax 44 --ipratio 1.1 --pbratio 1.2 --vbv-bufsize 24000 --vbv-maxrate 15000 --rc-lookahead 48 --aq-strength 0.8 --me umh --partitions p8x8,b8x8,i4x4,i8x8 --psy-rd 0.80:0 --ssim --bframes 3 --mvrange 511 --aud --nal-hrd --sar 1:1 --weightp 2 --output NUL "D:\Temp\DVDTemp\TLH\TLH.avs"

Second Pass:
"C:\Program Files (x86)\megui\tools\x264\x264.exe" --profile high --level 4 --pass 2 --bitrate 3500 --stats "D:\Temp\DVDTemp\TLH\TLH.stats" --thread-input --deblock -2:-1 --keyint 48 --min-keyint 4 --b-adapt 2 --direct auto --ref 4 --qpmax 44 --ipratio 1.1 --pbratio 1.2 --vbv-bufsize 24000 --vbv-maxrate 15000 --rc-lookahead 48 --aq-strength 0.8 --me umh --partitions p8x8,b8x8,i4x4,i8x8 --psy-rd 0.80:0 --ssim --bframes 3 --mvrange 511 --aud --nal-hrd --sar 1:1 --weightp 2 --output "D:\Temp\DVDTemp\TLH\TLH.mkv" "D:\Temp\DVDTemp\TLH\TLH.avs"

I will try to upload a source sample as soon as posible :thanks:

EDIT: Tested short sample, problem persist, uploading now.

[SquallMX]

Done, RAR with sample, output mkv, Avisynth script, DGIndex and x264:

http://rapidshare.com/files/310852058/TLH.rar

Problem persist, but i found something, if I play the output MKV on DGIndex before the corrupted scene (from start) the problem disappears, if i go directly to the scene the problem reappears.

:helpful:

[Dark Shikari]

Problem persist, but i found something, if I play the output MKV on DGIndex before the corrupted scene (from start) the problem disappears, if i go directly to the scene the problem reappears.And... it's [probably] a bug in DGIndex!

The problem is that DGIndex is seeking to an I-frame, not an IDR-frame. You can't seek to I-frames because the following P-frames can still reference frames before the I-frame. The clip you posted originally didn't start at an IDR frame, and was thus invalid.

[SquallMX]

And... it's [probably] a bug in DGIndex!

The problem is that DGIndex is seeking to an I-frame, not an IDR-frame. You can't seek to I-frames because the following P-frames can still reference frames before the I-frame. The clip you posted originally didn't start at an IDR frame, and was thus invalid.

Looks like the PS3/Total Media Theater do the same, when I go directly to that scene (using chapter selection) corruption happens, but if I watch the movie normally everything is OK.

So, this is a bug on the Decoder side, the generated x264 stream is legal according to the H264 standard?

Thanks for your help!

[Dark Shikari]

Looks like the PS3/Total Media Theater do the same, when I go directly to that scene (using chapter selection) corruption happens, but if I watch the movie normally everything is OK.

So, this is a bug on the Decoder side, the generated x264 stream is legal according to the H264 standard?

Thanks for your help!It actually seems like a bug in the splitter's side, not the decoder. The splitter is telling the decoder it can seek to a place that it actually can't.

To fix this, use --min-keyint=1; that will prevent the encoder from using non-IDR I-frames.

[Dark Shikari]

Actually, there's another possibility:

18:13 < kierank> it could be the muxer being crap though
18:13 < kierank> by setting the 2 seekable flags in the TS packet

If the muxer is telling the PS3 that the frame is seekable, it may believe the muxer (even when it isn't true). That would be a muxer bug.

What muxer did you use?

[SquallMX]

I used tsMuxeR 1.10.6.

Thanks for your help.

[lexor]

I suppose what you could try is mux the video into mp4 (using mp4box),and see if the corruption persists. At least we could rule out video itself as the source of the issue, if it works.