LAV Filters - DirectShow Media Splitter and Decoders

[Midzuki]

Hmmm, maybe LAV Video should just use the same technique as the DivX H264 Decoder 8.2.0.26 ---

--- instead of a checkbox, a drop-down list.

[dead_screem]

Aha. The option DOES appear to work but LAV is using the "wrong" stream aspect.

the video stream info from media info from your file

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Muxing mode : Header stripping
Codec ID : V_MPEG4/ISO/AVC
Duration : 10s 0ms
Bit rate : 2 075 Kbps
Nominal bit rate : 2 200 Kbps
Width : 1 024 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Original display aspect ratio : 1.422
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.113
Stream size : 2.47 MiB (90%)
Writing library : x264 core 107 r1745 4785e8e
Encoding settings : cabac=1 / ref=4 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=4 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=abr / mbtree=1 / bitrate=2200 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Default : Yes
Forced : No

Notice it has "Display aspect ratio" and "Original display aspect ratio" LAV Video is using the "Original display aspect ratio" from the stream instead of "Display aspect ratio" like it should.

My files (MPEG-2 and H.264) don't have a "Original display aspect ratio" field. but just a normal "Display aspect ratio" field only, so LAV Video must be thinking my files have no AR in the stream. And just fyi, 1 file I have is 720x480 with 16:9 aspect in the MPEG container but 2.35:1 "Display aspect ratio" in the MPEG-2 stream. I have another H.264 which has something weird as the aspect in the TS container like 15:11 but 4:3 as the "Display aspect ratio" in the stream. neither have a "Original display aspect ratio" field in the stream.

the "Original display aspect ratio" field in my limited experience, I almost never see set. And the few times I have seen it, its always been set to 1:1 like it is here. and the real aspect is at "Display aspect ratio"

[magic144]

Well, I'm no expert, I'll have to leave it to nev (or some other informed personage) to comment further.

[nevcairiel]

Originally Posted by dead_screem

Notice it has "Display aspect ratio" and "Original display aspect ratio" LAV Video is using the "Original display aspect ratio" from the stream instead of "Display aspect ratio" like it should.

My files (MPEG-2 and H.264) don't have a "Original display aspect ratio" field. but just a normal "Display aspect ratio" field only, so LAV Video must be thinking my files have no AR in the stream. And just fyi, 1 file I have is 720x480 with 16:9 aspect in the MPEG container but 2.35:1 "Display aspect ratio" in the MPEG-2 stream. I have another H.264 which has something weird as the aspect in the TS container like 15:11 but 4:3 as the "Display aspect ratio" in the stream. neither have a "Original display aspect ratio" field in the stream.

the "Original display aspect ratio" field in my limited experience, I almost never see set. And the few times I have seen it, its always been set to 1:1 like it is here. and the real aspect is at "Display aspect ratio"

Blame MediaInfo for confusing display of information.
If both fields are listed by MediaInfo, then "Display Aspect Ratio" is the Container AR, and "Original display aspect ratio" is the Bitstream AR. LAV Video does the right thing to use the Original display aspect ratio if you have Stream AR enabled. The Bitstream only ever contains one value, not two (or maybe zero)

If only one field is listed, your bet is as good as mine which field MediaInfo read there.
For the record, MPEG containers (ts/mpg) do NOT have a container AR, so any AR you see there is from the stream itself.

LAV Video does (mostly) the right thing. There is one known small glitch with the CUVID decoder when there is no stream AR at all, it assumes the resolution matches the AR. If you have a sample that has the correct AR with software decoding but wrong with CUVID, then give me a sample so i can fix it.

In my experience, Stream AR is only useful with MPEG TS files, for MKV or other containers with their own AR fields, alot of people neglect writing the proper AR into the Bitstream fields.
I've been pondering adding an option to LAV Splitter to overwrite the Bitstream AR with the Container AR for such formats (like Haali does), for one to help decoders that have no option to turn Bitstream AR off, and additionally to avoid having to flip that switch all the time.

[dead_screem]

Originally Posted by nevcairiel

Blame MediaInfo for confusing display of information.
If both fields are listed by MediaInfo, then "Display Aspect Ratio" is the Container AR, and "Original display aspect ratio" is the Bitstream AR. LAV Video does the right thing to use the Original display aspect ratio if you have Stream AR enabled. The Bitstream only ever contains one value, not two (or maybe zero)

If only one field is listed, your bet is as good as mine which field MediaInfo read there.
For the record, MPEG containers (ts/mpg) do NOT have a container AR, so any AR you see there is from the stream itself.

LAV Video does (mostly) the right thing. There is one known small glitch with the CUVID decoder when there is no stream AR at all, it assumes the resolution matches the AR. If you have a sample that has the correct AR with software decoding but wrong with CUVID, then give me a sample so i can fix it.

In my experience, Stream AR is only useful with MPEG TS files, for MKV or other containers with their own AR fields, alot of people neglect writing the proper AR into the Bitstream fields.
I've been pondering adding an option to LAV Splitter to overwrite the Bitstream AR with the Container AR for such formats (like Haali does), for one to help decoders that have no option to turn Bitstream AR off, and additionally to avoid having to flip that switch all the time.

http://www.4shared.com/video/NLQL0ENA/HALCALI.html
here is a MPEG-2 file, container AR is 16:9 (which is correct) stream AR is 2.35:1, which is wrong in this example but LAV Video never uses it no matter if the option is checked or unchecked. I can't seem to find any of my MPEG-2 files where the stream is right and container is wrong(I know I have some, but I have lots and lots, too many to sort through) I also can't find a H.264 TS that had this problem except the one I mentioned previously, which is a sample someone posted to this thread already, so you should already have it "538000Mhz.ts", container AR is 15:11 and stream AR is 4:3 and 4:3 never gets used by LAV, either with AR option checked or unchecked. I can reup that ts if you dont have it anymore.

[nevcairiel]

Originally Posted by dead_screem

http://www.4shared.com/video/NLQL0ENA/HALCALI.html
here is a MPEG-2 file, container AR is 16:9 (which is correct) stream AR is 2.35:1, which is wrong in this example but LAV Video never uses it no matter if the option is checked or unchecked. I can't seem to find any of my MPEG-2 files where the stream is right and container is wrong(I know I have some, but I have lots and lots, too many to sort through) I also can't find a H.264 TS that had this problem except the one I mentioned previously, which is a sample someone posted to this thread already, so you should already have it "538000Mhz.ts", container AR is 15:11 and stream AR is 4:3 and 4:3 never gets used by LAV, either with AR option checked or unchecked. I can reup that ts if you dont have it anymore.

TS and MPG files do NOT have a Container AR. Its just not possible, they have no header to encode such things into.
I don't know how MediaInfo determines that value, but its clearly invalid. Don't trust MediaInfo unconditionally. The AR of that file is 16:9, and its clearly stated like that in the MPEG-2 Headers (the video stream headers, not the container)

[dead_screem]

Originally Posted by nevcairiel

TS and MPG files do NOT have a Container AR. Its just not possible, they have no header to encode such things into.

my mistake then. by all means educate me. the mpg i posted is 720x480 and correct aspect should be 16:9, which LAV splitter gets right. And turning the aspect ratio on/off and its always 16:9. Media info says the stream AR is 2.35:1.

MPC-HC's own decoder (libmpeg2) has a Use stream AR option, with it off it gets 16:9 (passed from the splitter, LAV and MPC-HC own TS splitter is the same) but with it on it gets 2.35:1 like what media info says. But LAV Video still gets 16:9 from stream AR. what is going on then?

edit
http://www.4shared.com/file/1RSRE8i1/538000Mhz.html
I cant find any of my h264 ts that had problems, but whatever. here is the other file I mentioned, LAV says 15:11 but mediainfo says 4:3... 4:3 is what it should be... but of course 15:11 (1.36) and 4:3 (1.33) are close enough that pepole wouldnt notice.

[nevcairiel]

MPEG-2 video is a bit special because its header information has the information in some odd ways, and ffmpeg has quite a few workarounds to rather match real-world files instead of strict specs. Its possible that libmpeg2 just strictly follows the spec and therefor ends up with a wrong AR.
Unless you can find a file that actually shows wrong behavior, there isn't anything to do for me.

Note that this depends on which codec is used, so H264 and MPEG-2 might be completely different beasts.

Edit:
The second file specifiys a aspect ratio index of "2", which according to the H264 spec is a SAR of 12:11*, which translates to a PAR of 15:11 on your videos resolution. Working as intended.
Like i said, don't take MediaInfo as an authoritative source for everything. It may be interpreting or mis-representing data.

* This particular AR seems to be meant for 4:3 PAL signals with horizontal overscan, at least according to the spec, which would explain why its being stretched to a slightly bit wider then 4:3

[BetaBoy]

Originally Posted by CruNcher

CoreAVC DXVA, Lav Video DXVA and Potplayer DXVA fail with these x264 streams (same visual problem mostly gray blocking on specific frames, ref frames related, the more surprising would be that Arcsoft and Cyberlink found a way to compensate it without losing DXVA, or they use quicksync natively and Intels Driver MSDK fixes it) Cyberlink DXVA and Arcsofts DXVA implementation handle them on Intel without problems and fully accelerated

All of them Playback without issues with Cyberlinks and Arcsofts DXVA Decoder as well as Quicksync

http://www.mediafire.com/?scdzhe8e1gaxygh (gray blocking whole frames)
http://www.mediafire.com/?ucq118nxpnc4of7 (colored blocking part of frame then whole frames)
http://www.mediafire.com/?ykd7185z7j9db21 (practically every frame)
http://www.mediafire.com/?rld8gnlh52f03ud <- is a different decoding issue not ref frame related (Quicksync and Lav Video DXVA problem) plays flawless with Potplayer DXVA and CoreAVC DXVA
http://www.mediafire.com/?xr7ynkl2fg59g1c <- this is crazy it's a nvcuvenc h.264 transcode of the same mpeg-2 bitstream that brings the dxva2 native mpeg-2 down :P and it crashes also coincidence maybe though way to strange for one or this stream not important in which form triggers a bug in the MPC-HC render core but only with your DXVA2 Native
http://www.mediafire.com/?sdqa98x8ig6msng <- fails with a green screen though arcsoft (black screen) and cyberlink (only decodes half of the stream) also have problems coreavc dxva plays it potplayer crashes in ntdll :P quicksync works
http://www.mediafire.com/?bji8i63j93skh2a <- sharing these Decoding problems on Blu-Ray Encodes with CoreAVC and Potplayers DXVA (Arcsoft and Cyberlink work)
http://www.mediafire.com/?wtku126e9k13z61 <- another blu-ray test in native m2ts same issue as above in .mkv

resolution, version and settings of different x264 streams showing the same decoding problem with DXVA decoding on both decoder

1280x720

x264 core 88 r1471 1144615

cabac=1 / ref=16 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=10 / psy=0 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=0 / threads=1 / sliced_threads=0 / nr=0 / decimate=1 / mbaff=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=1 / wpredb=1 / wpredp=2 / keyint=350 / keyint_min=15 / scenecut=40 / intra_refresh=0 / rc_lookahead=250 / rc=2pass / mbtree=1 / bitrate=10000 / ratetol=10.0 / qcomp=0.00 / qpmin=6 / qpmax=51 / qpstep=6 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00



1280x720

x264 core 98 r1629 2e81ce1


cabac=1 / ref=9 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=esa / subme=10 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=16 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=abr / mbtree=1 / bitrate=15000 / ratetol=2.0 / qcomp=0.60 / qpmin=10 / qpmax=40 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00


720x352

x264 core 104 r1713M c276662

cabac=1 / ref=16 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=23.3 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00


1280x720

x264 core 112 r1834+3 ef18685

cabac=1 / ref=16 / deblock=1:1:1 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / fade_compensate=0.30 / psy_rd=0.40:0.10 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-3 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / fgo=5 / bframes=5 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=18.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=1:0.60


1280x720

x264 core 114 r1913+431 3ad9c33

cabac=1 / ref=16 / deblock=1:1:1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / fade_compensate=0.80 / psy_rd=0.40:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / fgo=5 / bframes=16 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=72 / rc=crf / mbtree=1 / crf=19.0 / qcomp=0.72 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:0.80


640x480

x264 core 115 r1947 b5a8ad7

cabac=1 / ref=16 / deblock=1:0:0 / analyse=0x3:0x133 / me=tesa / subme=10 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=16 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=16.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00

640x480

x264 core 115 r2008 4c552d8

cabac=1 / ref=16 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=0.80:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=16 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=300 / keyint_min=12 / scenecut=40 / intra_refresh=0 / rc_lookahead=30 / rc=crf / mbtree=1 / crf=23.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=2:0.40





comparable ref frame sei settings but no decoding issues (most probably decision wasn't as aggressive, working inefficient @ that time)

640x480

x264 core 50 svn-557M

cabac=1 / ref=16 / deblock=1:1:1 / analyse=0x3:0x133 / me=umh / subme=6 / brdo=1 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / chroma_qp_offset=0 / slices=2 / nr=0 / decimate=1 / bframes=3 / b_pyramid=1 / b_adapt=1 / b_bias=0 / direct=0 / wpredb=1 / bime=1 / keyint=250 / keyint_min=25 / scenecut=40 / rc=2pass / bitrate=1885 / ratetol=1.0 / rceq='blurCplx^(1-qComp)' / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30


720x360

x264 core 57 svn-712M

cabac=1 / ref=16 / deblock=1:0:0 / analyse=0x3:0x133 / me=esa / subme=7 / brdo=1 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=0 / threads=3 / nr=0 / decimate=0 / mbaff=0 / bframes=16 / 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=2000 / ratetol=1.0 / rceq='blurCplx^(1-qComp)' / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:0.3:0.0

1280x720

x264 core 61 r920M 8c8acae

cabac=1 / ref=16 / deblock=1:1:1 / analyse=0x3:0x133 / me=tesa / subme=7 / brdo=1 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=0 / threads=3 / nr=0 / decimate=1 / mbaff=0 / bframes=16 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / bime=1 / keyint=300 / keyint_min=25 / scenecut=40(pre) / rc=crf / crf=19.0 / rceq='blurCplx^(1-qComp)' / qcomp=1.00 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / pb_ratio=1.30 / aq=2:1.00


1920x1080

x264 core 67 r1120M 8544346

cabac=1 / ref=8 / deblock=1:1:-3 / analyse=0x3:0x2 / me=umh / subme=9 / psy_rd=0.8:0.0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-2 / threads=6 / nr=0 / decimate=1 / mbaff=0 / bframes=3 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=1 / wpredb=1 / keyint=250 / keyint_min=25 / scenecut=40 / rc=2pass / bitrate=6115 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00


720x1280

x264 core 98 r1649 c54c47d

cabac=1 / ref=8 / deblock=1:-3:-3 / analyse=0x3:0x113 / me=umh / subme=6 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=0 / b_bias=0 / direct=1 / weightb=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=3999 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00

1280x720

x264 core 107 r1745 4785e8e

cabac=1 / ref=9 / deblock=1:0:0 / analyse=0x3:0x13 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=9 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=130 / rc=crf / mbtree=1 / crf=19.5 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=1:0.60

PS: Nev could you test all these samples on your current Intel Driver i used 2639 for testing DXVA2 playback and confirm or deconfirm the issues thx

All the clips play fine with CoreAVC 3.1, however the 720p-cuda.mkv has the errors encoded into the stream itself.

[SeeMoreDigital]

Originally Posted by nevcairiel

I don't know how MediaInfo determines that value, but its clearly invalid. Don't trust MediaInfo unconditionally. The AR of that file is 16:9, and its clearly stated like that in the MPEG-2 Headers (the video stream headers, not the container)

MediaInfo probably took the AR information from the "Sequence Display Extension"... on this occasion.

[DragonQ]

FWIW, when I first installed MediaPortal and got it playing TV from my tuner card, I had to enable "Use stream aspect ratio" in LAV to get the 1440x1080 HD channels to correctly display as 16:9. When it was unticked, they'd playback at square aspect ratio (4:3). That was a long time ago though (late November IIRC) so I have no idea if that's still the case.

[Mercury_22]

Nev can you please help with a compatibility issue with TrueHD:
I'm trying to play my "The Fifth Element" (remastered) BD with "dslibbluray" but when the main movie starts the playback it's very "choppy" and I'm getting this error in "dslibbluray"

[truehd @ 0003d5a0] mlpparse: Parity check failed.
[truehd @ 0003d5a0] Lossless check failed - expected f3, calculated b7.

But if I use FFD the playback it's smooth with no error in dslibbluray
Also when using native I can't play the mpeg2 parts in the same BD but with CB and SW it's working

It will be nice if you could take a look cause I don't want to go back to FFD

P.S. more here http://forum.doom9.org/showthread.ph...37#post1564937

EDIT: WOW you're fast

EDIT 2 forgot to mention MPC-HC with native it's playing fine the same files

[nevcairiel]

Originally Posted by Mercury_22

It will be nice if you could take a look cause I don't want to go back to FFD

That filter is pre-alpha, if you use it and it doesn't work, its not my fault, complain to the author.
I will not waste my time with it.

[mindbomb]

so, if i use the mpc hc "save image" function while using lav video forced to output rgb32, the resulting png will be from the rgb?

[CruNcher]

Originally Posted by BetaBoy

All the clips play fine with CoreAVC 3.1, however the 720p-cuda.mkv has the errors encoded into the stream itself.

jup that's known the stream is buggy even as the Mpeg-2 version , still it's the x264 benchmark stream, this stream is crazy as i said with Nev DXVA2 as both this transcode and the original Mpeg-2 this H.264 was transcoded from crash it or Intels Driver, good news Dan for CoreAVC 3.1 (also getting all the ref frames problems under control like Arcsoft and Cyberlink did) especially for the stream that even Arcsoft and Cyberlink fail on though CoreAVC 3.0.1 already plays it without problems on Intel

[RBG]

Has anybody tested new nvidia driver 296.10, is mpeg-4 asp still broken?

[hoboX10]

Originally Posted by RBG

Has anybody tested new nvidia driver 296.10, is mpeg-4 asp still broken?

ASP? Do you mean AVC? I made a post about 2 pages back that got completely ignored, I assume because it's already a known issue, about me getting a bluescreen whenever I play back H264 video with NVIDIA CUVID on with the latest 295 drivers. I'm assuming you are talking about the same problem and meant mpeg4-avc.

[sagematt]

LAV Filters no longer detects that my CPU supports QuickSync (Core i7-2630QM, H67), this is on version 0.49, it says "Not Available" at all times. On LAV Filters 0.46 it works just fine. I tried using 0.49 with IntelQuickSyncDecoder.dll from 0.46, but it still won't detect/enable QuickSync. Any ideas?

[RBG]

Originally Posted by hoboX10

ASP? Do you mean AVC? I made a post about 2 pages back that got completely ignored, I assume because it's already a known issue, about me getting a bluescreen whenever I play back H264 video with NVIDIA CUVID on with the latest 295 drivers. I'm assuming you are talking about the same problem and meant mpeg4-avc.

No I mean exactly MPEG-4 ASP, some driver versions work with it just fine some not.

By the way, what is wrong with h.264, what hardware do you have?

[SeeMoreDigital]

Originally Posted by RBG

Has anybody tested new nvidia driver 296.10, is mpeg-4 asp still broken?

Really... When placed in which container?