Media Player Classic Home Cinema (MPC-HC) - DXVA!

[Gus.]

Is it at all possible to add a choice of Output Colorspaces, such as RGB32, YUY2, YV12, NV12, etc. to the player or decoder?

Thank You!

[Aleksoid1978]

yes, me too
rev 715 x86

For me crash too ... if WMR9 select, after i change to EVR - all fine.

Vista x64

[saint-francis]

Can anyone clue me in as to why all of my 6 channel audio tracks only play the front 2 main channels with MPC HC? PDVD plays them fine BTW. This is using the MPC HC internal everything.

[sneaker_ger]

Can anyone clue me in as to why all of my 6 channel audio tracks only play the front 2 main channels with MPC HC? PDVD plays them fine BTW. This is using the MPC HC internal everything.

Did you set the numbers of speakers in the filter settings right? Go to options->internal filters and then double click on AC3 (or DTS or AAC) under transform filters.

[sneaker_ger]

I'm getting blinking subtitles using the internal matroska splitter on mkvs with MPEG4/ISO/ASP video streams. No problems when using vfw compatibility mode or haali's media splitter though. It does not matter if I'm using internal subtitle filter or external VSFilter.
sample (http://netload.in/datei762c832b8740d4882e0f5199f66996ee/isovsvfw.zip.htm)

[saint-francis]

Did you set the numbers of speakers in the filter settings right? Go to options->internal filters and then double click on AC3 (or DTS or AAC) under transform filters.

Thanks! It's amazing that I have been using this player for years and never knew about that. It's because I just recently started using MPC HC without ffdshow now that I'm on a 64 bit os.

[Shakey_Jake33]

This isn't a bug in MPC-HC as such, just wanted to share something I noticed today. Some of you will know that Nvidia GPU's on laptops have a feature called Powermizer, which will dynamically downclock when idle. It's a great feature, but it really confuses EVR Custom Presenter. When full screen, my GPU will run at full 400MHz. When Windowed, it will downclock to 275MHz over time, and then 169MHz. This is fine, that's plenty for video... but this sequence of downclocking seems to confuse EVR Custom Presenter and it will drop loads of frames. I can close the player and start the video again in 169MHz mode and it will play fine, so it's clearly the sequence of the changing clock speed that screws something up in EVR, rather than the clock speed itself.

This does not happen in normal EVR or Haali Renderer, so I've had to revert back to 32-bit player/codecs so I can use Haali until he makes a 64-bit version. A shame because I like EVR Custom Presenter, but this behaviour makes it unsuitable for laptops with Nvidia GPU's and Powermizer enabled.

[mariner]

Is it at all possible to add a choice of Output Colorspaces, such as RGB32, YUY2, YV12, NV12, etc. to the player or decoder?

Thank You!

Thar would be great. Especially NV12 for ATI cards.

[XibaD]

Hi!

Can someone answer to my post? I don't understand quite clearly why DXVA can't be used in Windows XP x64 if Vista x64 is capable :)

Hi!

Is it possible to achieve DXVA with Windows XP x64 (not Vista x64). Because any option I set, MPC Video Decoder says "Not using DXVA".

[Shakey_Jake33]

^DXVA definately does work in Windows XP x64 because I use that OS myself. But it doesn't accelerate all files, only those which fit a certain specification. I don't know much about it because I don't need DXVA, but it does work.

[SpAwN_gUy]

maybe this is the wrong place to post.... but ..

can anyone fix internal matroska splitter, so it would respect "deafult tarck" for subtitles..
well, haali's has nice behaviour.. so if there are two(that's just to explain.. may be one) muxed in subtitles.. if for both streams "default" flag is set to no.. so when the mkv is played.. all muxed in subtitles are NOT shown...

(i.e. i have RusAC3 and EngAC3 and RusSUBs.. muxed in mkv.. for RusSUBs default=no.. so when i play the file.. i get Russina AC3... with NO subtitles..)

thanks.

[alexins]

Media Player Classic HomeCinema (x86), svn 717 (http://www.xvidvideo.ru/content/view/129/1/)
Media Player Classic HomeCinema (x64), svn 717 (http://www.xvidvideo.ru/content/view/130/1/)

Supported languages: CN, CZ, DE, ES, FR, HU, IT, KR, PL, RU, SK, TR, UA

Changes log (http://www.xvidvideo.ru/content/view/7/17/)

[clsid]

maybe this is the wrong place to post.... but ..

can anyone fix internal matroska splitter, so it would respect "deafult tarck" for subtitles..
well, haali's has nice behaviour.. so if there are two(that's just to explain.. may be one) muxed in subtitles.. if for both streams "default" flag is set to no.. so when the mkv is played.. all muxed in subtitles are NOT shown...

(i.e. i have RusAC3 and EngAC3 and RusSUBs.. muxed in mkv.. for RusSUBs default=no.. so when i play the file.. i get Russina AC3... with NO subtitles..)

thanks.
Since there is a good working alternative (Haali), improving the internal Matroska splitter of MPC is very low priority. Fixing bugs and improving stability is far more important at this moment.

[STaRGaZeR]

Since there is a good working alternative (Haali), improving the internal Matroska splitter of MPC is very low priority. Fixing bugs and improving stability is far more important at this moment.

Too bad there isn't an Haali x64 version yet, x64 users have to use the internal one.

[cca]

Rumor has it that the 64bit version of haali splitter will be released when the 64bit version of CoreAVC is released.

[clsid]

You can also just use the x86 version of MPC.

But fact remains that the lack of those unimportant Matroska features is really insignificant compared to other issues.

[alexins]

Media Player Classic HomeCinema (x64), svn 718 (http://www.xvidvideo.ru/content/view/132/1/)
Media Player Classic HomeCinema (x86), svn 718 (http://www.xvidvideo.ru/content/view/131/1/)

Supported languages: CN, CZ, DE, ES, FR, HU, IT, KR, PL, RU, SK, TR, UA

Changes: Disable the internal Matroska and Ogg splitters by default (= operate in low-merit mode). Currently Haali Media Splitter is far superior for these formats.

Changes log (http://www.xvidvideo.ru/content/view/7/17/)

[ooferomen]

has anyone got a chance to look into the MPC video decoder issue with the band of brothers hd dvd yet? :thanks:

[STaRGaZeR]

You can also just use the x86 version of MPC.

But fact remains that the lack of those unimportant Matroska features is really insignificant compared to other issues.

Haali splitter is one of the 2 or 3 reasons I use the x86 version instead of the x64 one.

Well the fact is that these features are not important if you use some super basic video+audio MKV. Anything more complex (even adding a simple hidden by default subtitle stream) = fail. But I agree other things have priority, and Haali is already there for us.

[XibaD]

^DXVA definately does work in Windows XP x64 because I use that OS myself. But it doesn't accelerate all files, only those which fit a certain specification. I don't know much about it because I don't need DXVA, but it does work.

I haven't found any yet... What you are saying? Is accelerated under Windows XP x64 or is it not? I don't understand quite well... :)

[tetsuo55]

I have been talking with a freind, and been reading a lot of DXVA documentation.

1. i have posted a plug-and-play commitable change to the level detection code, the freind helped me get it into actual c++ code. Its based on the ieee standards of SD and HD. The code now defines anything with a width of 1024 and higher as HD. This is correct according to all the documentation i have seen. i do not test for height as cropping makes the height an unreliable test.

2.after read a lot of documentation it seems like DXVA doesn't care about levels at all, this means that as soon as we find the correct commands we can have 16 ref frame SD files hardware decoded as level4.1, in other words the broken files would work, but it would still be a hack of sorts.

Below is the code, it needs to be commited to:
mpc-hc/trunk/src/filters/transform/mpcvideodec/FfmpegContext.c


int FFH264CheckCompatibility(int nWidth, int nHeight, struct AVCodecContext* pAVCtx, BYTE* pBuffer, UINT nSize)
{
H264Context* pContext = (H264Context*) pAVCtx->priv_data;
SPS* cur_sps;
PPS* cur_pps;

if (pBuffer != NULL)
av_h264_decode_frame (pAVCtx, pBuffer, nSize);

cur_sps = pContext->sps_buffers[0];
cur_pps = pContext->pps_buffers[0];

if (cur_sps != NULL)
{
// Check max num reference frame according to the level
#define MAX_DPB_41 8355840 // value for level 4.1 (that be HD for the uninitiated)
#define MAX_DPB_31 4608000 // value for level 3.1 (that be SD for the uninitiated)

if (cur_sps->ref_frame_count*nWidth*nHeight) > (MAX_DPB_41))
//width*height*ref_frame_count higher than max dpb is bad
return 2; // Too much ref frames
//got to check if this might in fact be SD. We assume anything with a width lower than 1024 is SD,
if(nWidth < 1024)
{
if (cur_sps->ref_frame_count*nWidth*nHeight) > (MAX_DPB_31))
// width*height*ref_frame_count higher than max dpb is bad
return 2;
}
}
//if control reaches this, we're inside DPB limits
return 0;
}


PS For those wondering this completely filters out the acciedental playback of 16 ref frame files unless they are valid which means they would need a very low resolution like 320x240

[MatMaul]

@tetsuo55 : actual implementations of DXVA support level 4.1 just fine for both SD and HD resolution so the actual code is OK.

the 11 refs restriction is a known bug and not a DXVA limitation

[STaRGaZeR]

What about a test version with tetsuo55's code?

[ADude]

Since there is a good working alternative (Haali), improving the internal Matroska splitter of MPC is very low priority. Fixing bugs and improving stability is far more important at this moment.

The Haali Splitter does not always work right for MPEG1 content, as I have posted twice in this thread... is there a way to contact the developer about that ?

[Mercury_22]

Since there is a good working alternative (Haali), improving the internal Matroska splitter of MPC is very low priority. Fixing bugs and improving stability is far more important at this moment.

Isn't this a bug ? :confused:

If this is the way we should think, one can also say there are better / "good working" alternatives for all MPC-HC internal (Transform) Fiters / decoders not only for internal Splitters so "improving the internal" (Transform) Fiters / decoders should also be "very low priority" !!! :( :confused:

In my opinion the internal Splitters (ogg, ts, ... also, not just Matroska) ARE THE ONE MAKING THE DIFFERENCE FOR MPC-HC, since the only "real" alternative it's Haali's (or none for 64-bit version), and for internal (Transform) Fiters / decoders are MANY MORE other "good working alternative" !!!

So i think fixing / improving the internal SPLITTERS (TS, OGG, Matroska, ... ) should be TOP PRIORITY !

But that's just me ! :D

P.S. The Haali Splitter does not always work right for MPEG1 content, as I have posted twice in this thread... is there a way to contact the developer about that ?
I can confirm that and not just for MPEG1 content !!! :(:helpful::thanks:

[tetsuo55]

@tetsuo55 : actual implementations of DXVA support level 4.1 just fine for both SD and HD resolution so the actual code is OK.

the 11 refs restriction is a known bug and not a DXVA limitation

The current code blocks a lot of valid files. And allows a lot of broken files.
-Files with more than 16 ref frames are very valid, this has been proven in the past.
-The current code allows SD files with too many ref frames to be decoded in DXVA model which causes crashes or green screens, some SD files have an upper limit of 8 or less ref frames

My code allows ALL valid files and blocks ALL invalid files completely accurately.
-It is based on the h264, DXVA, HD rules and guidelines.
-It is based on realworld tests in the past
-All the files that the current code is trying to block are still blocked with my code, but now in an accurate way.

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

The bug you're talking about has nothing to do with the blocking code, i'm very close to finding the cause.

Here is my theory in short:

DXVA does not talk about levels, the software is completely responsible for making sure the decoder sets the correct mode. When the software does not provide the needed information the decoder guesses the level. The problem is that nvidia and ati guess differently

[clsid]

The Haali Splitter does not always work right for MPEG1 content, as I have posted twice in this thread... is there a way to contact the developer about that ?Are you talking about MPEG1 inside Matroska container? Or the MPEG-PS splitter (which you should not enable) of Haali? There is a topic about Haali Media Splitter on this forum, you can report bugs there.

In my opinion the internal Splitters (ogg, ts, ... also, not just Matroska) ARE THE ONE MAKING THE DIFFERENCE FOR MPC-HC, since the only "real" alternative it's Haali's (or none for 64-bit version), and for internal (Transform) Fiters / decoders are MANY MORE other "good working alternative" !!!
So i think fixing / improving the internal SPLITTERS (TS, OGG, Matroska, ... ) should be TOP PRIORITY !The lack of a x64 version of Haali Media Splitter should only be a temporary problem. I strongly disagree with your opinion. As long a there are good (and free) alternatives for non-essential functionality (the internal filters), improving other functionality is far more important. Just to name a few: DXVA, EVR issues, and some stability issues. Once those issues have been addressed, the internal splitters can be improved. Supporting Theora in Ogg is the most important. Hidden/disabled streams in Matroska is not very important as you can also just manually select the desired streams.

And since Casimir's ToDo list is already several meters long, it doesn't help if everyone constantly keeps bitching about the same issues. It ain't gonna magically fix things quicker.

[STaRGaZeR]

Just complile a test version, I'd be pleased to test it ;)

[tetsuo55]

Just complile a test version, I'd be pleased to test it ;)

Yeah i am going to need your help later too, as you seem to have many borderline test cases.

So could someone please at least build a test-version with my code?


---

Casimir, How much ms lag does the Anti-Tearing code introduce?

[Mercury_22]

Are you talking about MPEG1 inside Matroska container? Or the MPEG-PS splitter (which you should not enable) of Haali? There is a topic about Haali Media Splitter on this forum, you can report bugs there.

The lack of a x64 version of Haali Media Splitter should only be a temporary problem. I strongly disagree with your opinion. As long a there are good (and free) alternatives for non-essential functionality (the internal filters), improving other functionality is far more important. Just to name a few: DXVA, EVR issues, and some stability issues. Once those issues have been addressed, the internal splitters can be improved. Supporting Theora in Ogg is the most important. Hidden/disabled streams in Matroska is not very important as you can also just manually select the desired streams.

And since Casimir's ToDo list is already several meters long, it doesn't help if everyone constantly keeps bitching about the same issues. It ain't gonna magically fix things quicker.

Ok I agree : let's NOT "keep bitching about the same issues." :)
I was just thinking that being able to play all those type of files (without external help / filters ) it's an "essential functionality" and for the moment it's more important than improving the quality. :stupid:

I just have one question for you about MPEG-PS splitter (which you should not enable) of Haali since enabling Haali's MPEG-PS splitter it's the only thing that allows me to play EVO files, what do you use for evo file ? :helpful:

[MatMaul]

Files with more than 16 ref frames are very valid, this has been proven in the past.
??? more than 16 refs is not compliant with the h264 standard, if you find a sample like this ask for a refund :P
-The current code allows SD files with too many ref frames to be decoded in DXVA model which causes crashes or green screens, some SD files have an upper limit of 8 or less ref frames
I'm waiting for a proof of that (samples please :) )
If you check the log I had nearly exactly the same code (rev 517) but some people complain here because some of their files didn't play anymore.

The bug you're talking about has nothing to do with the blocking code, i'm very close to finding the cause.

Here is my theory in short:

DXVA does not talk about levels, the software is completely responsible for making sure the decoder sets the correct mode. When the software does not provide the needed information the decoder guesses the level. The problem is that nvidia and ati guess differently
no. Casimir already knows what is the bug and it is not that : the algorithm which manage the release of the decoded pictures is not very good so with more than 10-11 refs the buffers are full and it hangs up.

[tetsuo55]

oops i meant more than 11 ref frames but less than 17 :P

The old code was not exactly the same as mine. Lets just test my code with a test-build before changing anything on the SVN.

Which file is the basis for the bug casimir is working on?

Since no-one seems to be stepping up to the plate i will try to encode a couple of 5 second test files later. Only borderline tests though. We need a group of guaranteed accurately encoded test files anyway

[clsid]

I was just thinking that being able to play all those type of files (without external help / filters ) it's an "essential functionality" and for the moment it's more important than improving the quality.Why is it such a big problem to use external filters? You also need external filters for formats that MPC-HC doesn't support by itself. More people care more about fully working DXVA than those Matroska features. This topic is the living proof of that. And if you read discussions/reviews of MPC on various sites, than the majority of complaints that users have are about stability.
You seem to care only about your own user experience. While I care about the user experience of the average user.

I just have one question for you about since enabling Haali's MPEG-PS splitter it's the only thing that allows me to play EVO files, what do you use for evo file ? :helpful:I don't play EVO files. The internal MPEG-PS/TS/PVA source filter is supposed to support EVO now I think, but I dunno if those changes are completed yet.

[Mercury_22]

Why is it such a big problem to use external filters? You also need external filters for formats that MPC-HC doesn't support by itself. More people care more about fully working DXVA than those Matroska features. This topic is the living proof of that. And if you read discussions/reviews of MPC on various sites, than the majority of complaints that users have are about stability.
You seem to care only about your own user experience. While I care about the user experience of the average user.
I don't play EVO files. The internal MPEG-PS/TS/PVA source filter is supposed to support EVO now I think, but I dunno if those changes are completed yet.

Look above it wasn't me that started this it just happens that I agree with all this, and I'm not refering only to Matroska splitter.
But like I've said before Ok I agree : let's NOT "keep bitching about the same issues."
Anyway thanks for the info on EVO but internal MPEG-PS/TS/PVA source filter it's still not working for evo and also for some ts . :thanks: :stupid:

[Casimir666]

I have been talking with a freind, and been reading a lot of DXVA documentation.

1. i have posted a plug-and-play commitable change to the level detection code, the freind helped me get it into actual c++ code. Its based on the ieee standards of SD and HD. The code now defines anything with a width of 1024 and higher as HD. This is correct according to all the documentation i have seen. i do not test for height as cropping makes the height an unreliable test.

2.after read a lot of documentation it seems like DXVA doesn't care about levels at all, this means that as soon as we find the correct commands we can have 16 ref frame SD files hardware decoded as level4.1, in other words the broken files would work, but it would still be a hack of sorts.

Below is the code, it needs to be commited to:
mpc-hc/trunk/src/filters/transform/mpcvideodec/FfmpegContext.c


int FFH264CheckCompatibility(int nWidth, int nHeight, struct AVCodecContext* pAVCtx, BYTE* pBuffer, UINT nSize)
{
H264Context* pContext = (H264Context*) pAVCtx->priv_data;
SPS* cur_sps;
PPS* cur_pps;

if (pBuffer != NULL)
av_h264_decode_frame (pAVCtx, pBuffer, nSize);

cur_sps = pContext->sps_buffers[0];
cur_pps = pContext->pps_buffers[0];

if (cur_sps != NULL)
{
// Check max num reference frame according to the level
#define MAX_DPB_41 8355840 // value for level 4.1 (that be HD for the uninitiated)
#define MAX_DPB_31 4608000 // value for level 3.1 (that be SD for the uninitiated)

if (cur_sps->ref_frame_count*nWidth*nHeight) > (MAX_DPB_41))
//width*height*ref_frame_count higher than max dpb is bad
return 2; // Too much ref frames
//got to check if this might in fact be SD. We assume anything with a width lower than 1024 is SD,
if(nWidth < 1024)
{
if (cur_sps->ref_frame_count*nWidth*nHeight) > (MAX_DPB_31))
// width*height*ref_frame_count higher than max dpb is bad
return 2;
}
}
//if control reaches this, we're inside DPB limits
return 0;
}


PS For those wondering this completely filters out the acciedental playback of 16 ref frame files unless they are valid which means they would need a very low resolution like 320x240

Release 1.1.174 with tetsuo55 code :
http://www.zshare.net/download/16631247cc8efe85/

Please let me know if this modification should be commited or not.

[Tery]

I really like, being able to choose which Screen to use when playing full screen, but sometimesI play video fullscreen on computer screen sometimes not, and it is really anoying to modify preferences each times.

Would it be possible to add command key, in preferences to be able to configure two keys (or more if people have more than two screen), to play full screen on screen 1 or 2 .... ?
Like F11 play full screen on screen1, and F12 play full screen on screen2.

Or something like two left click, play full screen on screen1 and two right click play it on screen2 ? (and two middle click play it on screen3 .... :D)

Thanks for your great work, keep going :)

Tery.

[rica]

Why is it such a big problem to use external filters? You also need external filters for formats that MPC-HC doesn't support by itself. More people care more about fully working DXVA than those Matroska features. This topic is the living proof of that. And if you read discussions/reviews of MPC on various sites, than the majority of complaints that users have are about stability.
You seem to care only about your own user experience. While I care about the user experience of the average user.


Hundred percent i agree; what i've been looking for ages a DX based player which i can easily select the filters i desire. (I've been normally using GraphEdit as my default player just for this reason.)
Subtitle DXVA feature is a bonus as well :)

[Kado]

I want to translate MPC HC to Portuguese, how can I do it? I it's a text based file it would be nice!:)

[clsid]

Download "mplayerc.rc" from the SVN repository. It is text based. Translate that and send it to Casimir.

[Casimir666]

Can somebody try this release of VSFilter with Haali Renderer and told me if it solve the freeze problem in mpc :

http://www.zshare.net/download/16633220b12de839/

@Kado
Someone is already working on the Portuguese translation, but thanks for your proposition :-)

[alexins]

Release 1.1.174 with tetsuo55 code :
http://www.zshare.net/download/16631247cc8efe85/

Please let me know if this modification should be commited or not.

Checked on files different formats, problems were not.

[Kado]

@clsid
:thanks:

@Casimir
Is the translation "European Portuguese" or "Brazilian Portuguese"? Because they are not the same.

[rica]

Checked on files different formats, problems were not.

I was hoping to give good news but sorry;
VC1 problems with nvidia cards is still going on.
MPC-HC never accepts any other external decoder for VC1 except WM Video decoder DMO.
No problems have been living in h264 though.

[STaRGaZeR]

I was hoping to give good news but sorry;
VC1 problems with nvidia cards is still going on.
MPC-HC never accepts any other external decoder except WM Video decoder DMO.
No problems have been living in h264 though.

This new code is only the H.264 detection formula, it does not affect VC-1 files. If you're trying to load Cyberlink's VC-1 decoder, it doesn't work for me too. I think this is a problem of the filter itself, not of MPC-HC, it can only be used inside PDVD, pretty much like Nero 8 filters only working inside Nero Showtime.

I've tested every H.264 file I have and all of them play like with the official revs. The only problematic samples are the ones I've already submmited here and to Casimir, but they're not related with this new code. Obviously Sample 3 is fixed, but it was in the official revs too since the introduction of the 11+ ref limitation. Looks like we need to enconde specific files to do a real test of the edges of the formula.

[rica]

Sorry i posted before reading the code.

[gngn]

Release 1.1.174 with tetsuo55 code :
http://www.zshare.net/download/16631247cc8efe85/

Please let me know if this modification should be commited or not.

with this release MPC-HC will try to decode more (i have a few files that even the "oficial" release will try to decode in DXVA-mode resulting in freezing playback after a few seconds) of the problematic files on my Nvidia in DXVA-mode resulting in broken playback. DXVA-mode does work for all those files (i have correct playback for a few seconds until video freezes, but sound will continue) , but something goes then wrong.

MPC-HC playes following files in software-mode, the version with tetsuo55 code in DXVA, but my Nvidia cant handle them in DXVA:

Video
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L5.1
Format settings, CABAC : Yes
Format settings, ReFrames : 13
Codec ID : V_MPEG4/ISO/AVC
Duration : 24mn 10s
Nominal bit rate : 954 Kbps
Width : 704 pixels
Height : 480 pixels
Display aspect ratio : 16/9
Frame rate : 23.976 fps
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.118
Title : Episode02: Ana
Writing library : x264 - core 55 svn-663C
Encoding settings : cabac=1 / ref=10 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=7 / brdo=1 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=2 / deadzone=15,6 / chroma_qp_offset=0 / threads=3 / nr=0 / decimate=0 / mbaff=0 / bframes=3 / b_pyramid=1 / b_adapt=1 / b_bias=0 / direct=0 / wpredb=1 / bime=1 / keyint=250 / keyint_min=25 / scenecut=40(pre) / rc=2pass / bitrate=954 / 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:1.1:15.0


Video
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L5.1
Format settings, CABAC : Yes
Format settings, ReFrames : 12
Codec ID : V_MPEG4/ISO/AVC
Duration : 24mn 23s
Nominal bit rate : 1167 Kbps
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 16/9
Frame rate : 23.976 fps
Standard : NTSC
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.141
Title : sola 14 (OVA)
Writing library : x264 - core 56 svn-680
Encoding settings : cabac=1 / ref=9 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=6 / 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=3 / b_pyramid=1 / b_adapt=1 / b_bias=0 / direct=3 / wpredb=1 / bime=1 / keyint=240 / keyint_min=24 / scenecut=36(pre) / rc=2pass / bitrate=1167 / ratetol=3.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
Language : Japanese

[betaking]

Originally Posted by Casimir666
Release 1.1.174 with tetsuo55 code :
http://www.zshare.net/download/16631247cc8efe85/

Please let me know if this modification should be commited or not.
I can not download. who can up it to rapidshare.com! thanks!

[neoufo51]

Originally Posted by Casimir666
Release 1.1.174 with tetsuo55 code :
http://www.zshare.net/download/16631247cc8efe85/

Please let me know if this modification should be commited or not.
I can not download. who can up it to rapidshare.com! thanks!
http://rapidshare.com/files/135430352/mplayerc_1.1.174.0.rar.html

[betaking]

http://rapidshare.com/files/135430352/mplayerc_1.1.174.0.rar.html
:) thanks!

[marc99]

Release 1.1.174 with tetsuo55 code :
http://www.zshare.net/download/16631247cc8efe85/

Please let me know if this modification should be commited or not.

Not all my files with low resolution and 16 ref frames decoded properly with DXVA (stop after a few frames). Limitation 11+ is better. I suggest tetsuo55 code and 13+ ref. frames limitation (official 3.1 level max for 720x480 and probably less).