Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > New and alternative a/v containers

Reply
 
Thread Tools Search this Thread Display Modes
Old 13th March 2012, 05:40   #9841  |  Link
Midzuki
Unavailable
 
Midzuki's Avatar
 
Join Date: Mar 2009
Location: offline
Posts: 1,408
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.
Midzuki is offline   Reply With Quote
Old 13th March 2012, 05:55   #9842  |  Link
dead_screem
Registered User
 
Join Date: Jan 2005
Posts: 105
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"

Last edited by dead_screem; 13th March 2012 at 06:01.
dead_screem is offline   Reply With Quote
Old 13th March 2012, 06:02   #9843  |  Link
magic144
Registered User
 
Join Date: May 2005
Posts: 380
Well, I'm no expert, I'll have to leave it to nev (or some other informed personage) to comment further.
magic144 is offline   Reply With Quote
Old 13th March 2012, 07:16   #9844  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 8,989
Quote:
Originally Posted by dead_screem View Post
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.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders

Last edited by nevcairiel; 13th March 2012 at 07:29.
nevcairiel is offline   Reply With Quote
Old 13th March 2012, 08:02   #9845  |  Link
dead_screem
Registered User
 
Join Date: Jan 2005
Posts: 105
Quote:
Originally Posted by nevcairiel View Post
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.
dead_screem is offline   Reply With Quote
Old 13th March 2012, 08:04   #9846  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 8,989
Quote:
Originally Posted by dead_screem View Post
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)
__________________
LAV Filters - open source ffmpeg based media splitter and decoders

Last edited by nevcairiel; 13th March 2012 at 08:11.
nevcairiel is offline   Reply With Quote
Old 13th March 2012, 08:12   #9847  |  Link
dead_screem
Registered User
 
Join Date: Jan 2005
Posts: 105
Quote:
Originally Posted by nevcairiel View Post
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.

Last edited by dead_screem; 13th March 2012 at 08:21.
dead_screem is offline   Reply With Quote
Old 13th March 2012, 09:28   #9848  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 8,989
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
__________________
LAV Filters - open source ffmpeg based media splitter and decoders

Last edited by nevcairiel; 13th March 2012 at 10:36.
nevcairiel is offline   Reply With Quote
Old 13th March 2012, 10:37   #9849  |  Link
BetaBoy
CoreCodec Founder
 
BetaBoy's Avatar
 
Join Date: Oct 2001
Location: San Francisco
Posts: 1,421
Quote:
Originally Posted by CruNcher View Post
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.
__________________
Dan "BetaBoy" Marlin
Ubiquitous Multimedia Technologies and Developer Tools

http://corecodec.com
BetaBoy is offline   Reply With Quote
Old 13th March 2012, 10:43   #9850  |  Link
SeeMoreDigital
Life looks better in HD
 
SeeMoreDigital's Avatar
 
Join Date: Jun 2003
Location: Notts, UK
Posts: 11,216
Quote:
Originally Posted by nevcairiel View Post
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.
__________________
| I've been testing hardware media playback devices and software A/V encoders and decoders since 2001 | My Network Layout & A/V Gear |
SeeMoreDigital is offline   Reply With Quote
Old 13th March 2012, 10:57   #9851  |  Link
DragonQ
Registered User
 
Join Date: Mar 2007
Posts: 917
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.
__________________
HTPC Hardware: Intel Celeron G530; nVidia GT 430; OCZ Vertex 2 (120 GB)
HTPC Software: Windows 7; MediaPortal 1.16.0; Kodi 17.3; LAV Filters (CUVID); MadVR
DragonQ is offline   Reply With Quote
Old 13th March 2012, 11:36   #9852  |  Link
Mercury_22
Registered User
 
Join Date: Dec 2007
Posts: 1,123
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"
Code:
[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
__________________
Windows 10 x64 CU, HD7790 Crimson 17.6.2, HDMI Full RGB 4:4:4

Last edited by Mercury_22; 13th March 2012 at 11:41.
Mercury_22 is offline   Reply With Quote
Old 13th March 2012, 11:53   #9853  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 8,989
Quote:
Originally Posted by Mercury_22 View Post
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.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 13th March 2012, 14:46   #9854  |  Link
mindbomb
Registered User
 
Join Date: Aug 2010
Posts: 578
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?
mindbomb is offline   Reply With Quote
Old 13th March 2012, 15:19   #9855  |  Link
CruNcher
Registered User
 
CruNcher's Avatar
 
Join Date: Apr 2002
Location: Germany
Posts: 4,950
Quote:
Originally Posted by BetaBoy View Post
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
__________________
all my compares are riddles so please try to decipher them yourselves :)

It is about Time

Join the Revolution NOW before it is to Late !

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

Last edited by CruNcher; 13th March 2012 at 15:25.
CruNcher is offline   Reply With Quote
Old 13th March 2012, 18:19   #9856  |  Link
RBG
Registered User
 
Join Date: Oct 2011
Posts: 108
Has anybody tested new nvidia driver 296.10, is mpeg-4 asp still broken?
RBG is offline   Reply With Quote
Old 13th March 2012, 18:27   #9857  |  Link
hoboX10
Registered User
 
hoboX10's Avatar
 
Join Date: Jul 2008
Location: Texas
Posts: 50
Quote:
Originally Posted by RBG View Post
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.
hoboX10 is offline   Reply With Quote
Old 13th March 2012, 18:56   #9858  |  Link
sagematt
Registered User
 
Join Date: Jan 2012
Posts: 3
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?
sagematt is offline   Reply With Quote
Old 13th March 2012, 19:00   #9859  |  Link
RBG
Registered User
 
Join Date: Oct 2011
Posts: 108
Quote:
Originally Posted by hoboX10 View Post
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?
RBG is offline   Reply With Quote
Old 13th March 2012, 19:23   #9860  |  Link
SeeMoreDigital
Life looks better in HD
 
SeeMoreDigital's Avatar
 
Join Date: Jun 2003
Location: Notts, UK
Posts: 11,216
Quote:
Originally Posted by RBG View Post
Has anybody tested new nvidia driver 296.10, is mpeg-4 asp still broken?
Really... When placed in which container?
__________________
| I've been testing hardware media playback devices and software A/V encoders and decoders since 2001 | My Network Layout & A/V Gear |
SeeMoreDigital is offline   Reply With Quote
Reply

Tags
decoders, directshow, filters, splitter

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 04:50.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2017, vBulletin Solutions Inc.