Media Player Classic Home Cinema (MPC-HC) - DXVA! [Archive] - Page 160

73ChargerFan

24th May 2009, 21:23

It's not that simple, refresh rate occilates slightly and is never exactly 60hz, also depending on what the computer is doing in the background timings can drift even more.
Okay, I get it. The graphics hardware/driver determines vsynch, not the TV. I thought it was the other way around. I "get it" that the gpu/cpu may get "busy" and a delay occurs.

Try resetting the renderer settings to optimal defaults, and use bilinear instead of bicubic resizer. Also CAT9.5 fixes a lot of problems like these
Will try. Every version of Catalyst "fixes" a lot of problems, but creates others. :mad:

Oh, and I started work on the wiki. :D

73ChargerFan

24th May 2009, 21:34

Guys a quick questions....what should give me better performance when running full Bluray rips using MPC-HC with ffdshow for video and audio (TrueHD) plus some Avisynth... an E8500 at 4.2Ghz or a quad core processor running a bit slower?Extra cores won't help, but both should work fine.

Also, do you think having 4GB would be better than 2GB under Vista 64 for this program?
Vista works better with 4GB than 2GB, and you can get screaming deals on high end DDR800, like I paid $50 after rebates for 8GB.

ADude

24th May 2009, 22:39

When playing a video using EVR CP, Enable VSync, Accurate Vsync and Alternative VSync along with Wait for flushes. Maximize your player window, press Ctrl and J; at the left, you'll see a label named "Refresh rate" which should report some changing number, like 60.01234 Hz. Look at it for a minute and see if remains stable while the video plays.

" 0.00 Hz " regardless of the changes I make. ;)

ADude

24th May 2009, 22:41

All manufacturers use a slightly different approach making it difficult to find a way that works for everyone, the current code is the best way we could get it.

Okay, so no one other than Beliyaal understands the options enough to answer this part of my question?:
I tried the new sync display. With "Vsync" unchecked in the Renderer settings, other settings will change the graph. There is no documentation on the graph, but perhaps it is just showing what the code would do if it is turned on ? I am assuming that unchecking "Vsync" in the Renderer settings turns off all of MPC-HC's Vsync code and allows the graphic card drivers to do the sync in whatever manner they have been set to do - is that correct ? There are different graph results with the 4 different combinations of "Vsync" and "Alternate Vsync" checked, for example.

tetsuo55

24th May 2009, 22:57

Can't be worse than random values.The point is, as soon as you miss the XX nanosecond windows the tearing point will move into view, simply demanding a value will not help. The tear will be visable and will move up/down slightly. Without actually locking on to the real vsync the tear will remain visable.

Guys a quick questions....what should give me better performance when running full Bluray rips using MPC-HC with ffdshow for video and audio (TrueHD) plus some Avisynth... an E8500 at 4.2Ghz or a quad core processor running a bit slower?
Also, do you think having 4GB would be better than 2GB under Vista 64 for this program?
Thanks 3 ghz C2D is more than enough to play back 40mb/s dual stream bluray content, and the more ram the better.

Okay, I get it. The graphics hardware/driver determines vsynch, not the TV. I thought it was the other way around. I "get it" that the gpu/cpu may get "busy" and a delay occurs.It has always been the video encoder that tells the display what to do, the display just does what it's told.Will try. Every version of Catalyst "fixes" a lot of problems, but creates others. :mad:I red performance is down on some games, but that should be caused by a bugfix enabling a feature that simply did nothing before.
(2posts)

I ran some tests and this might help you and STaRGaZeR

-First make sure you have the newest driver for ATI that means 9.5
-Now in the settings enable "Vsync on unless application specifies"
-In MPC-HC, reset renderer settings to optimal defaults
-In MPC-HC output settings make sure you select bilinear instead of the bicubic resizer

With these settings i always get accurate detection and smooth tearing free playback.

carnage_pl

24th May 2009, 23:11

Maybe first post should be updated to add links to wiki and other new features because searching something in 400 pages may be difficult

alexins

24th May 2009, 23:49

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

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

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

(1121-1125)
Cosmetic-fix in Slovak translation;
Added : Sweedish translation;
Cosmetic changes in Sweedish & Hungarian translation;
Fixed : overflow in "Subtitle delay";
Fixed : True HD decoder broken in rev 1108.

GrofLuigi

25th May 2009, 01:01

(About the bug: not displaying forced subtitles)

That's too bad, i don't have or use those file either. Well you can at least update that bug report with your problem.

I discovered it was the driver (Intel Mobile Chipset; for XP; Revision: Production Version 14.38.3.5047) not displaying the subtitles. (I don't know what will I do next, I'm not reverting to older versions) :mad:

But I still think it is a bug (incorrect behavior) that forced subtitles are not enabled by default in MPC.

GL

ADude

25th May 2009, 02:14

I ran some tests and this might help you and STaRGaZeR

-First make sure you have the newest driver for ATI that means 9.5
-Now in the settings enable "Vsync on unless application specifies"
-In MPC-HC, reset renderer settings to optimal defaults
-In MPC-HC output settings make sure you select bilinear instead of the bicubic resizer

With these settings i always get accurate detection and smooth tearing free playback.

So, given your response, it seems clear that no one other than Beliyaal actually knows what his options really do (since you didn't answer the question the second time either).

To put it another way - in the Renderer Settings, does unchecking "Vsync" - a) turn off the Beliyaal code ? b) turn off all MPC-HC code relating to Vsync c) send a message to the GPU to not sync vertical at all (i.e. "application specifying") ? d) something else ?

----

Reading this thread, I get the impression that a) people took Beliyaal's word that "the existing vsync code in EVR CP was bad" and b) that his code was an improvement.

I had no tearing in all versions of MPC-HC from the first one all the way through 1043. The only tearing I have ever seen in MPC-HC was after the Beliyaal merge.

Please understand that I would be happy to be convinced that all the new code was great. But, lossey digital video is a delicate balance of many factors and what might look logical at first glance, might end up disturbing something else in the chain. I would rather have the ATI and Nvidia engineers handle as much of the coding as possible.

STaRGaZeR

25th May 2009, 03:13

The point is, as soon as you miss the XX nanosecond windows the tearing point will move into view, simply demanding a value will not help. The tear will be visable and will move up/down slightly. Without actually locking on to the real vsync the tear will remain visable.

Tearing is really a non-issue with Aero enabled. I suggested this as a temporary solution, that would be better than having the refresh rate and SL values way off like they're now most of the time. However madVR detects the frame rate perfectly fine and for long periods of time. Beliyaal in my case is 120,0000XX without PowerStrip, just to let you know. Maybe you can ask madshi about his algorithm, it works really well and since madVR 0.10 nobody has reported bad refresh rate detection AFAIK.

tetsuo55

25th May 2009, 07:55

(About the bug: not displaying forced subtitles)

I discovered it was the driver (Intel Mobile Chipset; for XP; Revision: Production Version 14.38.3.5047) not displaying the subtitles. (I don't know what will I do next, I'm not reverting to older versions) :mad:

But I still think it is a bug (incorrect behavior) that forced subtitles are not enabled by default in MPC.

GLCaused by the driver, that's just wierd, but everything related to subtitles with dvd's is wierd.
So, given your response, it seems clear that no one other than Beliyaal actually knows what his options really do (since you didn't answer the question the second time either).

To put it another way - in the Renderer Settings, does unchecking "Vsync" - a) turn off the Beliyaal code ? b) turn off all MPC-HC code relating to Vsync c) send a message to the GPU to not sync vertical at all (i.e. "application specifying") ? d) something else ?

----

Reading this thread, I get the impression that a) people took Beliyaal's word that "the existing vsync code in EVR CP was bad" and b) that his code was an improvement.

I had no tearing in all versions of MPC-HC from the first one all the way through 1043. The only tearing I have ever seen in MPC-HC was after the Beliyaal merge.

Please understand that I would be happy to be convinced that all the new code was great. But, lossey digital video is a delicate balance of many factors and what might look logical at first glance, might end up disturbing something else in the chain. I would rather have the ATI and Nvidia engineers handle as much of the coding as possible.
Well Beliyaal did write a post containing information about all the new features:
http://forum.doom9.org/showthread.php?p=1281093#post1281093

Basically disabling "everything" in the renderer settings should match the old behaviour(not completely though, many things under the hood where changed). the old "lock back buffers" feature can be enabled with "wait for flush"

Disabling eveything except vsync should give you what you want (GPU deciding everything on it's own)

The manual Beliyaal wrote says "reset to defaults first, then to optimal defaults" so that would have to be added to the steps in my last post.

Tearing is really a non-issue with Aero enabled. I suggested this as a temporary solution, that would be better than having the refresh rate and SL values way off like they're now most of the time. However madVR detects the frame rate perfectly fine and for long periods of time. Beliyaal in my case is 120,0000XX without PowerStrip, just to let you know. Maybe you can ask madshi about his algorithm, it works really well and since madVR 0.10 nobody has reported bad refresh rate detection AFAIK.I've asked Beliyaal to talk to madshi(who is willing to point us in the right direction)

You could also try the "reset to defaults first, then to optimal defaults" to see if that fixes the detection.

@ADude, STaRGaZeR: If i'm not mistaken pre-beliyaal merge MPC did not have a refresh rate detection system, it just showed what windows reported.

tetsuo55

25th May 2009, 08:11

I just ran some test's on my system.

-Reset to default renderer settings
-Disable everything that has been selected
-EVR-CP
-Vsync enabled unless application specifies in catalyst options

Detected refresh rate will be 0 and behaviour matches pre- merge builds

(And i actually get tearing free, and almost jitterfree playback)

@Beliyaal, could you add a "reset to pre-beliyaal merge behaviour" setting? )which disables everything in the renderer settings view
We can remove it once the refresh rate detection works for everyone

mark0077

25th May 2009, 17:43

well i agree
but it actually works:
press and hold alt and press space -> works
press alt, release alt and press space -> window menu

Hi,

I retested this keyboard shortcut and it does appear to be a bug.... or at least a bad idea to have this shortcut in there. To reproduce

1) Open video file in mpc-hc from something like xbmc or media browser with the following options
EVR-CP Selected
D3D Full Screen Mode
D3D Full Screen GUI Support
2) Press and hold ALT, then press Space.

You will see the menu popping up. in the middle of the screen, not a good thing. Can someone at least add another shortcut that performs the same function as ALT + SPACE, that isn't a windows shortcut. Might be nice to leave the old shortcut there also for those people that use it.

St Devious

25th May 2009, 17:53

tetsuo55

25th May 2009, 18:50

i cannot reproduce what you experience on 6 different systems.

Please post full pc specs, do you run a virusscanner and antispyware?

Leak

25th May 2009, 19:43

Can someone at least add another shortcut that performs the same function as ALT + SPACE, that isn't a windows shortcut. Might be nice to leave the old shortcut there also for those people that use it.
Go to "Options > Player > Keys > DVD Menu Activate" and just choose a different key than space. Problem solved.

mark0077

25th May 2009, 19:45

Go to "Options > Player > Keys > DVD Menu Activate" and just choose a different key than space. Problem solved.

Thanks... I appreciate that, but for every bug or problem there is, the final solution can't be to perform a workaround. If it is in fact a clash of shortcuts, the shortcuts should be at least matched against windows known shortcuts.

ADude

25th May 2009, 20:14

Well Beliyaal did write a post containing information about all the new features:
http://forum.doom9.org/showthread.php?p=1281093#post1281093

Basically disabling "everything" in the renderer settings should match the old behaviour(not completely though, many things under the hood where changed). the old "lock back buffers" feature can be enabled with "wait for flush"

Disabling eveything except vsync should give you what you want (GPU deciding everything on it's own).

I did read all that before posting.

The descriptions are not quite specific enough.

For example, it says:
VSync
Can be used to disable VSync. This is not recommended normally as disabling VSync will remove many stuttering and threading fixes. Should only used for debugging purposes.

As I mentioned before, this is ambiguous, does it mean: a) turn off the Beliyaal code ? b) turn off all MPC-HC code relating to Vsync c) send a message to the GPU to not sync vertical at all (i.e. "application specifying") ? d) something else ?

Note that with "Vsync" unchecked in the Renderer settings, other settings will change the graph.

tetsuo55

25th May 2009, 20:24

I did read all that before posting.

The descriptions are not quite specific enough.

For example, it says:

As I mentioned before, this is ambiguous, does it mean: a) turn off the Beliyaal code ? b) turn off all MPC-HC code relating to Vsync c) send a message to the GPU to not sync vertical at all (i.e. "application specifying") ? d) something else ?

Note that with "Vsync" unchecked in the Renderer settings, other settings will change the graph.
I see your point, i cannot anwer it per option but i can answer your 2nd question

1. turn off the Beliyaal code: this is not possible, the changes go too deep
2. turn off all MPC-HC code relating to Vsync: Disable all Vsync settings and all gpu settings
3. send a message to the GPU to not sync vertical at all (i.e. "application specifying"):I don't think MPC-HC ever tells the videocard to not do Vsync, only how to do it when it is enabled/available

My guess would be that disabling Vsync disables the signal to the videocard to enable vsync specifically for MPC-HC

blarg

25th May 2009, 21:09

I see your point, i cannot anwer it per option but i can answer your 2nd question

1. turn off the Beliyaal code: this is not possible, the changes go too deep

Any chance that you can go back to 1043 and start over? Beliyaal's code breaks more things than it fixes. If it's not possible, god, I wish someone would do a fork with 1043 as a base.

tetsuo55

25th May 2009, 21:17

Any chance that you can go back to 1043 and start over? Beliyaal's code breaks more things than it fixes. If it's not possible, god, I wish someone would do a fork with 1043 as a base.Please provide exact regression issues you have found.

As i stated before disabling everything in the rendering settings give you the old behaviour.

The new code actually fixed about 20-25% of all open bugs on the tracker. (and at least another 10-15% that has yet to be confirmed)

St Devious

25th May 2009, 21:32

MPC HC has been hell for me lately. can't seek in any file, it just hangs. tried avi and mkv.

it is decoding everything with its own filters. Using DXVA with GTS 250 185.66 drivers. Intel Q9450, 4 GB RAM, 640 GB HDD.

Also it takes a long time to save its settings, once you click ok on the options box and exit out from there. Tried 1080-1120 builds , all the same problem.

EDIT: Just tried a previous 1018 build, everything's fine again. So something is definitely wrong with the latest builds.

i cannot reproduce what you experience on 6 different systems.

Please post full pc specs, do you run a virusscanner and antispyware?

Running Avira Anti Virus, Vista SP1 x64 all updates applied. Only other codecs installed is ffdshow.

as i said 1018 build runs perfectly with the files that 1080-1120 have problem with on the same system. So it has to something with the latest builds.

tetsuo55

25th May 2009, 21:41

Running Avira Anti Virus, Vista SP1 x64 all updates applied. Only other codecs installed is ffdshow.

as i said 1018 build runs perfectly with the files that 1080-1120 have problem with on the same system. So it has to something with the latest builds.

Please test between 1018 and 1080 to find out exactly between which version you start having problems

ADude

25th May 2009, 22:00

Please provide exact regression issues you have found.

As i stated before disabling everything in the rendering settings give you the old behaviour.

The new code actually fixed about 20-25% of all open bugs on the tracker. (and at least another 10-15% that has yet to be confirmed)

I think that at the same time he was rewriting the vsync, Beliyaal also fixed some bugs, particular with the audio, in his separate version, that cause some people who experienced those bugs to ask for his version to be merged with the main version.

A few of the recent comments made me realize that what we need is a way for the user to be able to select different syncing methods. Currently, we have the same thing with renderers. The user can select VMR7 or EVR or Haali or whatever he thinks is best for his setup.

Similarly, I think there should be a way to select sync method, either "Beliyaal's Vsync" or "Original Vsync" (or is that "Gabest's Vsync) or "GPU Vsync".

tetsuo55

25th May 2009, 22:05

I think that at the same time he was rewriting the vsync, Beliyaal also fixed some bugs, particular with the audio, in his separate version, that cause some people who experienced those bugs to ask for his version to be merged with the main version.there where no more showstopping regressions reported, so beliyaal and casimir merged to SVN.

A few of the recent comments made me realize that what we need is a way for the user to be able to select different syncing methods. Currently, we have the same thing with renderers. The user can select VMR7 or EVR or Haali or whatever he thinks is best for his setup.There is no reason to have different Vsync codepath's, the existing one should simply work. Beliyaal has explained parts of it to me. I'm confident we can get it working for everyone (at least as bad as the pre-existing code)

Similarly, I think there should be a way to select sync method, either "Beliyaal's Vsync" or "Original Vsync" (or is that "Gabest's Vsync) or "GPU Vsync".
Yeah i posted that earlier, disable everything should be equal to original vsync.

Still for Beliyaal to be able to fix these problems we need screenshots of the CTRL+J screenshots during problematic scenes with gpu control enabled

Mixer73

25th May 2009, 23:13

Any chance that you can go back to 1043 and start over? Beliyaal's code breaks more things than it fixes. If it's not possible, god, I wish someone would do a fork with 1043 as a base.

Sock puppet - go away. Tell us who you really are.

giom

26th May 2009, 01:11

10 bit RGB
This enables 10 bit processing in the whole pipeline after the YUV transform. Backbuffer, temporary buffers and video frames are always in 10 bit. To enable 10 bit for the display buffer D3D fullscreen mode and Vista or later is required.

Video drivers have been known to be buggy with the 10 bit pipeline. For example: Deinterlacing crashes the player and 16-235 levels isn't availeble on ATI drivers.

I finally get my decoder outputing A2R10G10B10 to the screen.

The decoder is connected to the EVR in RGB32 but is in fact outputing A2R10G10B10 samples.

[Decoder](A2R10G10B10/RGB32)->[EVR]

Formats : Surface A2R10G10B10 Backbuffer A2R10G10B10 Display A2R10G10B10
...
Mixer output : RGB32

So I send A2R10G10B10 samples in a RG32 Media subtype.

Is this a bug in ATI drivers, in EVR or in MPC HC ?

I need to do more test to see if it removes banding.

Progressive and interlaced working.

[0..255] and [16..235] working (maybe [16..235] ignored by ATI drivers).

Bug (Only on 7) :

"Disable desktop composition/off", when you close MPC HC, the desktop is dark, as if you have dropped down brightness. Maybe the driver doesn't restore gamma exiting A2R10G10B10 fullscreen mode. Need ctrl+alt+del, cancel to get it back.
"Disable desktop composition/on", when you close MPC HC, the desktop is black. Need restart Windows.

System 1:
Vista 32
ATI X1650 XT (Catalyst 9.3)
MPC HC 1120

System 2:
Win 7 RC 64
MPC HC 1111
ATI X1650 XT (7 RC drivers)

Display:
TV LCD DAEWOO LCD42FHD
DVI->HDMI (Analog RGB)

From X1650 XT specs (http://shop.ati.com/product.asp?sku=3225111) :

16 bit per channel floating point HDR and 10 bit per channel DVI output
Spatial/temporal dithering enables 10-bit color quality on 8-bit and 6-bit displays

malados

26th May 2009, 06:34

I have one question about the DXVA decode and display.

When the DisplayNextFrame() function is called, it will search one nPicIndex to GetDeliveryBuffer and m_pAMVideoAccelerator->DisplayFrame to display the frame.
After display, the flag bUsed will set to 0 if this frame will not be reference by another frame.
So, the Index may be using for next decode buffer immediately.
The "decoded" frame will be updated on screen immediately caused by the same buffer index "nPicIndex" as previous display frame.
What is the problem? Does someone have any idea?

chros

26th May 2009, 09:37

Am I right, that the GM45 graphic chip is not supported under WinXP 32bit? (driver version 14.38.3.5047)
I'm experimenting with a Lenovo 3000 N500 laptop, but DXVA isn't working ...

Thanks

tetsuo55

26th May 2009, 09:38

Am I right, that the GM45 graphic chip is not supported under WinXP 32bit? (driver version 14.38.3.5047)
I'm experimenting with a Lenovo 3000 N500 laptop, but DXVA isn't working ...

ThanksWhat does DXVAChecker say?

chros

26th May 2009, 09:50

What does DXVAChecker say?

Mobile Intel(R) 4 Series Express Chipset Family
ModeMPEG2_A: DXVA1, IMC3, 720x480 / 1280x720 / 1920x1080
ModeMPEG2_B: DXVA1, IMC3, 720x480 / 1280x720 / 1920x1080
ModeMPEG2_C: DXVA1, IMC3, 720x480 / 1280x720 / 1920x1080
ModeMPEG2_D: DXVA1, IMC3, 720x480 / 1280x720 / 1920x1080
ModeMPEG2_MoComp: DXVA2, IMC3, 720x480 / 1280x720 / 1920x1080
ModeMPEG2_IDCT: DXVA2, IMC3, 720x480 / 1280x720 / 1920x1080
ModeWMV9_MoComp: DXVA1/2, IMC3, 720x480 / 1280x720 / 1920x1080
ModeWMV9_IDCT: DXVA1/2, IMC3, 720x480 / 1280x720 / 1920x1080
ModeVC1_MoComp: DXVA1/2, IMC3, 720x480 / 1280x720 / 1920x1080
ModeVC1_IDCT: DXVA1/2, IMC3, 720x480 / 1280x720 / 1920x1080

Casshern

26th May 2009, 09:55

Greetings Casimir and Beliyaal.

More vsync problems playing 1920x1080@60P H264/AAC .mp4 clips. Are these also related to the transparency problem mentioned in your post?

1. If waiting for flush is enabled, frame rate is halved.
2. ver. 1120 has problem handling it while it plays well in ver. 1043.

Tested on Gigabyte GF9400 MB with triple buffering enabled, Vista 32.
Many thanks and best regards.
Judging from your stats you have 60hz refreshrate which equals to a refresh frame time of approx. 16 ms. Your wait for GPU Flush is awfully close with 14ms - so whenever you card takes longer, the effects you describe could happen. Maybe your card is to slow. But the exact workings and interplay of frame rate, refresh rate, wait for GPU is only known to beliyaal. You can try to keep the "Flush GPU at Vsync" and disable the "Wait for GPU" flush and see if that helps.

My case (lowly 2600 AGP) is almost the reverse, i get low frame rates if the material easy to decode (720p mkvs or black vc1 frames). 1920x 1080 from bds works pretty good!

tetsuo55

26th May 2009, 09:55

Mobile Intel(R) 4 Series Express Chipset Family
ModeMPEG2_A: DXVA1, IMC3, 720x480 / 1280x720 / 1920x1080
ModeMPEG2_B: DXVA1, IMC3, 720x480 / 1280x720 / 1920x1080
ModeMPEG2_C: DXVA1, IMC3, 720x480 / 1280x720 / 1920x1080
ModeMPEG2_D: DXVA1, IMC3, 720x480 / 1280x720 / 1920x1080
ModeMPEG2_MoComp: DXVA2, IMC3, 720x480 / 1280x720 / 1920x1080
ModeMPEG2_IDCT: DXVA2, IMC3, 720x480 / 1280x720 / 1920x1080
ModeWMV9_MoComp: DXVA1/2, IMC3, 720x480 / 1280x720 / 1920x1080
ModeWMV9_IDCT: DXVA1/2, IMC3, 720x480 / 1280x720 / 1920x1080
ModeVC1_MoComp: DXVA1/2, IMC3, 720x480 / 1280x720 / 1920x1080
ModeVC1_IDCT: DXVA1/2, IMC3, 720x480 / 1280x720 / 1920x1080

No h264 support, you'll have to complain to Intel.

Casshern

26th May 2009, 09:58

I disagree, for me its the opposite. The beliyaal versions work much better than the old versions - which showed total corruption and jumping frames with vmr9 rl and DXVA.

Also if you disable all VSYNC options and just enable "Flush GPU at vsync" (and disable the other GPU options) it should almost behave like before.

Any chance that you can go back to 1043 and start over? Beliyaal's code breaks more things than it fixes. If it's not possible, god, I wish someone would do a fork with 1043 as a base.

Casshern

26th May 2009, 10:02

Great work. Dolby True HD works now. Also the switching between audio tracks works much better now - no more static.
The last serious BD audio bug is that the mono lpcm tracks are note decoded properly - see almost all criterion releases (e.g. wages of fear, 400 blows etc.)

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

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

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

(1121-1125)
Cosmetic-fix in Slovak translation;
Added : Sweedish translation;
Cosmetic changes in Sweedish & Hungarian translation;
Fixed : overflow in "Subtitle delay";
Fixed : True HD decoder broken in rev 1108.

tetsuo55

26th May 2009, 10:05

Leak

26th May 2009, 10:08

Sock puppet - go away. Tell us who you really are.
ITYM "go fork yourself"... :p

chiyuwang

26th May 2009, 10:44

I saw that there is a solution file in filters folder, and try to compile it. But the output are all library files. I want to compile stand alone filters with .ax extension name. What am I supposed to do? Where I can find useful information? Thank you.

Mixer73

26th May 2009, 10:46

ITYM "go fork yourself"... :p

Yes, exactly what I thought.

*clapclap* to all the hardworking devs here, especially Beliyaal for tackling the hard nuts to crack... You know when you crack nuts there's gonna be bits of shell around, but that's part of the process.

Any gutless wonder that wants to create a shadow account just to pine and whine can bite my shiny metal ass.

Rille

26th May 2009, 16:42

I disagree, for me its the opposite. The beliyaal versions work much better than the old versions - which showed total corruption and jumping frames with vmr9 rl and DXVA.

Same here. After beliyaals fixes i finally have smooth tearingfree playback. I can only speak for ATI/Vista/EVR though.

Steveo08

26th May 2009, 18:50

i found a problem with the alternative vsync that i am always having ghost lines during playback a movie.

if i disable alternative vsync i do not get ghost lines. but on the other side alternative vsync gives me the best value at jitter.

so perhaps there is a solution for that?

ADude

26th May 2009, 19:52

Same here. After beliyaals fixes i finally have smooth tearingfree playback. I can only speak for ATI/Vista/EVR though.

Are you using DXVA ?

PS In regards to the "sock puppet" - a) it is not me, and b) if you read the thread, there are a lot of posts by new members (two in the last 24 hours). Why is it so inconceivable that someone read the thread for months and only "de-lurked" to post that one comment ?

There is an irrational emotion that "people who volunteer their time are free from any responsibility for quality work." and so "any criticism of the work of volunteers is automatically invalid, as well as being automatically mean-spirited". These emotions work to make open source software poorer in quality than commercial software, because people become hesitant to bring up problems when they are attacked as viciously as "blarg" has been.

Rille

26th May 2009, 20:25

Are you using DXVA ?

Works fine both with DXVA and without. I have two computers, one with HD3200 IGP and one with HD4850.

I should mention that i'm using reclock as well to speed up to 25fps. My TV's will not handle 24/48 without converting to 60hz. If i set to 60hz and disable reclock i get 3:2 judder but no tearing.

blarg

26th May 2009, 22:44

Yes, exactly what I thought.

*clapclap* to all the hardworking devs here, especially Beliyaal for tackling the hard nuts to crack... You know when you crack nuts there's gonna be bits of shell around, but that's part of the process.

Any gutless wonder that wants to create a shadow account just to pine and whine can bite my shiny metal ass.

Watch out, folks. We have a real life Sherlock Holmes. It's almost as if he made a total guess, thought he was right, and then patted himself on the back. I mean it's not like people have said "...since the merge, [insert problem]" or its equivalent many times in this thread or anything.

I'm totally gonna change my username to ADudeJr to make it more obvious I'm the same person.

mark0077

26th May 2009, 23:42

Beliyaal, I reproduced a problem i reported many threads back again now.

Started playing some vc-1 content this time and for some reason I got no audio and the renderer is gone crazy. Screenshot below. This is a simple 24hz documentary and you can see its playing at weird speeds. Seems to be hovering around the 38-40fps mark now. Can you think what might be going wrong in the renderer as this is probably the 10th time I have reproduced this on my machine under various operating systems, this time Windows 7 RC 64bit with GTX 295.

I know restarting the video will resolve but would be great if you could have a think what might make the renderer stay so consistenly off the 24fps mark. Looking back at the player now its still hovering around 40fps, sometimes 42-43 but nowhere near 24.

http://img29.imageshack.us/img29/4905/wtfues.th.jpg (http://img29.imageshack.us/my.php?image=wtfues.jpg)