Video in top left corner

[Graham]

I'm guessing that we no longer see this as a DXVA thing and any tests that I do won't help.

Let me know if I have got it wrong and if there is any test I can do to help.

[sub]

I'm guessing that we no longer see this as a DXVA thing and any tests that I do won't help.

The problem in the start of this thread was definitely related to DXVA. Later in this thread we got on to another topic related to EVR.

[johnsonx42]

yes, sorry, that was partly my bad... I basically said I wouldn't care about VMR9 not working right if EVR would work with the negative aspect ratio numbers, and off we went. If you can use EVR though, the new patch works great and eliminates any need for VMR9 (for me anyway).

[pBS]

loving it! thanx for that rant... evr patch works great! [plus i second that being able to see current aspect in osd]

and hey, it *is* a workaround for the original posting...
i was never a real fan of vmr9...till it worked well...[fse]

and the osd being off is much less of a pain than fse mode for sure..
[i think i'll just adjust skin to have no background for bottom info,probably won't notice it much even]
seems to me the bottom info was off center on another combo as well...will see if i can catch it..
thanx

[sub]

Yes, I see what you mean about the OSD, but I consider that pretty minor against the major benefit. Anyone who doesn't use the negative ratios won't see any change, and half the people who do probably won't even notice.

Much later on, when you're polishing for perfection you could probably fix the OSD size/position issue by applying a fudge-factor to the OSD rendering based on the selected aspect ratio mode. Perhaps something like an on-the-fly adjustment to the UI zoom setting? Maybe even include the fudge-factor in the aspect ratio definition in config.xml, so that it's up to us to fix it as we see fit rather than you having to include code to calculate it.

Unfortunately the OSD graph is already shown as absolutely wide as the API will let me get it, so its not a case of just showing a slightly wider OSD.

[speising]

yes, EVR works, but of course it doesn't solve the original problem that we can only have a correct picture *or* hardware acceleration - at least on XP...

[johnsonx42]

Unfortunately the OSD graph is already shown as absolutely wide as the API will let me get it, so its not a case of just showing a slightly wider OSD.

so be it then, the upside far outweighs the downside.

[johnsonx42]

yes, EVR works, but of course it doesn't solve the original problem that we can only have a correct picture *or* hardware acceleration - at least on XP...

this is easy for me to say, having already moved on to Windows 7, but I think at this point in time support for Windows XP ought to be somewhat limited. XP is a 20th century codebase with a few 21st century band-aids, bits of duct tape and baling wire. In many ways Vista was a valid excuse to cling to XP, but with Windows 7 the arguement is getting pretty thin. That all said, I don't make the rules around here, sub does.

[pBS]

i do notice that all sd material defaults to 'fill' no matter what it was previously just set to...
hd works ok from a quick test..
and no resume on vid library shows... a definite must add..worked flawlessly before..
status shows funky stuff, and xml info is sporadic...seems like it doesn't like something in the xml's..
i'll have to get an example together..

anyways, even without accel, it's only 40% cpu on evr mpeg2 and 30% for h264... which is fine as long as it plays smoothly..
you'll still get the most important part of dxva, hardware deinterlacing...

but yea, i'd still rather use xp and vmr9 if possible...[even if has to be fse mode]

[pBS]

on a happier note, i'm playing a channel on gbpvr livetv, and same channel on npvr with it's timeshifting...and get this, it's in sync!
so the delay w/timeshifting in new version is exactly same as delay in livetv in pvrx2...[and it's live![ish]]

so the new timehift engine really rocks! you hit that one out of the park...
and .ts can be viewed while in progress from another machine without any tweaking, so can kinda have client mode now, just no control over host..
so client mode shouldn't be too hard to implement... or at least performance should be as good as local..[no more wasted bytes and bandwidth for clients! yeah!]
hd should be able with lowly .g nets now...