1080i material not deinterlacing under 1.0.1.0 (1 Viewer)

[Andrew H]

Thanks -- so the fact that I got the same error message even without any tsreader.ax file available in the folder is because the handshake or 'call' is unsuccessful, regardless of the underlying reason. OK.

Another observation: when you FIRST tune a 1080i channel or open a file to view, the video is like in slow motion for a couple o' seconds and then begins playing at a more 'regular' rate. Sorta like the poster above stated fps get slower whenever you have an overlay on the screen with your video. And, you had mentioned the developers were attempting to fix EVR + ATi... I also read where folks are complaining about the scroll speeds being greatly effected -- I too noticed the scroll speed is driven by the selected target framerate. I don't recall the two having been related before this -- could all these issues be related?

 

[tourettes]

I also read where folks are complaining about the scroll speeds being greatly effected -- I too noticed the scroll speed is driven by the selected target framerate. I don't recall the two having been related before this -- could all these issues be related?

It has always been like that. When video is played the GUI rendering speed is always locked to the video playback fps.

 

[Andrew H]

Several of us have posted our GPU models and we've attempted to utilize the MP 1.0 TsReader.ax without success. Have you made any progress on resolving/defining, or understanding this issue? I went through the changelogs and could not identify the report which drove this "update" to the tsreader that you are talking about... as an end-user there was no 'announcement' of any changes to the way rendering has bene performed. Do you have a link/post you'd like to share?

After reading about PureVideo HD, there have been several versions/revisions each realizing increased capability/offloading of CPU processing over to the GPU. I decided to see if a beefier video card would help -- ordered a GeForce 9500 GT 512MB 128-bit GDDR3 and will install it this weekend.

I must ask: have you received any positive feedback from the ATi/Vista users that you modified this for? Did the re-write make ATi users any better, because it seems it's made a bunch of users (on this post) all the worse Any way to query the PC and have a branch for this in the code so that both ATi and NVidia users can co-exist?

 

[tourettes]

Several of us have posted our GPU models and we've attempted to utilize the MP 1.0 TsReader.ax without success. Have you made any progress on resolving/defining, or understanding this issue? I went through the changelogs and could not identify the report which drove this "update" to the tsreader that you are talking about... as an end-user there was no 'announcement' of any changes to the way rendering has bene performed. Do you have a link/post you'd like to share?

Current understanding is that GPU performance requirement is just gone upwards a little bit. So older generation HW will struggle with 1080i material (deinterlace on 1920x1080 resolution is pretty GPU taxing alone).

After reading about PureVideo HD, there have been several versions/revisions each realizing increased capability/offloading of CPU processing over to the GPU. I decided to see if a beefier video card would help -- ordered a GeForce 9500 GT 512MB 128-bit GDDR3 and will install it this weekend.

Most likely the purevideo / HW decoding processing power doesn't have any difference on the issue. The change is not done on the way how video is decoded but instead how the decoded frames are displayed, so the additional processing power is related to fillrate / GPU processing power with textures.

Previously the video frames were rendered directly to the display surface (which is wrong way to do it, but faster as it requires less GPU operations per frame) instead of the texture that could be properly mixed with the rest of MP GUI engine textures.

I must ask: have you received any positive feedback from the ATi/Vista users that you modified this for? Did the re-write make ATi users any better, because it seems it's made a bunch of users (on this post) all the worse Any way to query the PC and have a branch for this in the code so that both ATi and NVidia users can co-exist?

Flickering has reduced (or even cured on many cases) for ATI + Vista users. Having multiple code paths is a big no as it will cause more surface for errors (especially when the surface -> texture change wasn't only few code lines), cause additional work for maintenance etc. So it wont happen that we have different rendering paths with ATI & Nvidia.

 

[Mr Hipp]

In order to further look into this we need a new sample file. A file without errors otherwise it makes no sense to continue.

Regards

Mr Hipp

 

[kiwijunglist]

Im back to MP1.0 Final now, ill record a very short .ts clip for 1080i h264 tv and see if when i record with 1.0 final if it still has errors.

 

[Andrew H]

After reading about PureVideo HD, there have been several versions/revisions each realizing increased capability/offloading of CPU processing over to the GPU. I decided to see if a beefier video card would help -- ordered a GeForce 9500 GT 512MB 128-bit GDDR3 and will install it this weekend.

Most likely the purevideo / HW decoding processing power doesn't have any difference on the issue. The change is not done on the way how video is decoded but instead how the decoded frames are displayed, so the additional processing power is related to fillrate / GPU processing power with textures.

Previously the video frames were rendered directly to the display surface (which is wrong way to do it, but faster as it requires less GPU operations per frame) instead of the texture that could be properly mixed with the rest of MP GUI engine textures.

Got the N9500GT installed and it makes QUITE a difference! Although I don't have an exact way to compare my old 7050PV to it, I'm getting really close to 60fps VMR9 according to <Shift><1> One thing also is my mobo is PCI-e/16 ver1.0 not ver 2.0 which may have some effect. I'll write more later...

 

[bellzz]

Reset

I just want to take a step back again because it seems that this discussion has brought many interesting issues to the surface.
Andrew, it seems that in your last post, a better GPU has solved or at least helped the problem. Why? Mediocre onboard GPU could handle it and now they cannot. What specifically has changed?
Why when I make the specifc change from Automatic deinterlacing to BOB in CCC does it fix the problem? I'm not saying that that IS the problem, it is probably an effect of something else being different that is causing all these other variants of the same problem.
But to go back further, has anyone else verified that the problem was not present in SVN 1.23 and showed itself in 2.15? Eventhough I have been running at 60fps since setting CCC to BOB, it seems other people are still having problems. If others can determine if the issue was introduced at this SVN then maybe the people in the know can focus their efforts there.
Currently I'm having an issue with the Netflix Plugin when the external window opens and would rather have deinterlacing set to auto instead of defined as BOB. So a real resolution would still be nice.
Bellzz

 

[tourettes]

Got the N9500GT installed and it makes QUITE a difference! Although I don't have an exact way to compare my old 7050PV to it, I'm getting really close to 60fps VMR9 according to <Shift><1> One thing also is my mobo is PCI-e/16 ver1.0 not ver 2.0 which may have some effect. I'll write more later...

If <shift>1 shows only some minor variance FPS rate then there is no need to worry about it. Only the FPS calculation code is a little bit broken (taking average during some specific time and the displayed frames count could be not fitting exactly into that, so it will vary always). In .1.1.0 there will be much more accurate FPS rate displayed (only for EVR as I'm lazy and don't use VMR9 myself). This is based on the EVR renderer's internal statistics.

 

[tourettes]

I just want to take a step back again because it seems that this discussion has brought many interesting issues to the surface.
Andrew, it seems that in your last post, a better GPU has solved or at least helped the problem. Why? Mediocre onboard GPU could handle it and now they cannot. What specifically has changed?

That one has been already explained in this thread. Basicly changing the video frame rendering to happen thru a texture instead rendering it directly...

Why when I make the specifc change from Automatic deinterlacing to BOB in CCC does it fix the problem? I'm not saying that that IS the problem, it is probably an effect of something else being different that is causing all these other variants of the same problem.

ATI's automatic uses most likely pixel or vector adaptive deinterlace. Those two are much more GPU power hungry than the BOB (which is pretty basic deinterlace).