[a11599]

Ok. Made further tests. My original deinterlace PR on top of a8d22f68c77e3a68f7d530df9a807282d78cb0ef (2011-08-01 23:56:57) shows the symptoms described here. The patch on top of 2740c15ef86414e1ef465692d7e6522dc3cf6d57 (DXVA renderer, 2011-07-28 19:06:19) however does not show the symptoms, playback is perfect even with vector-adaptive deinterlacing.

So it really must be something between.

[Hitcher]

Care to share 'My original deinterlace PR on top of a8d22f68c77e3a68f7d530df9a807282d78cb0ef (2011-08-01 23:56:57)' so I can confirm?

Thanks.

[WhiningKhan]

@WhiningKhan, @Voyager-xbmc, seems you both applied the patch on top of current master, correct?
It's fine, I just want to make sure I understand correctly.

Yes, master from (I think) September 12.

[a11599]

Care to share 'My original deinterlace PR on top of a8d22f68c77e3a68f7d530df9a807282d78cb0ef (2011-08-01 23:56:57)' so I can confirm?

Thanks.

Ofcourse.

Bad (a8d22f68c77e3a68f7d530df9a807282d78cb0ef): http://subvoice.hu/xbmc/XBMC-deinterlace...d22f68.exe
Good (2740c15ef86414e1ef465692d7e6522dc3cf6d57): http://subvoice.hu/xbmc/XBMC-deinterlace...40c15e.exe

[Voyager]

Ok. Made further tests. My original deinterlace PR on top of a8d22f68c77e3a68f7d530df9a807282d78cb0ef (2011-08-01 23:56:57) shows the symptoms described here. The patch on top of 2740c15ef86414e1ef465692d7e6522dc3cf6d57 (DXVA renderer, 2011-07-28 19:06:19) however does not show the symptoms, playback is perfect even with vector-adaptive deinterlacing.

So it really must be something between.

Could it be the frame time smoother? An open question, since this changes happened right in the middle of that, and taking into account that Bob presentation renders 2 frames it could be that the smoother is forcing a wait before flip that is too long. I'm not sure about this, but I noticed that, at least, frame time smoother "falsifies" the fps value you see on the OSD (pressing "o"). This is because it calculates the current time as a multiple of the number of frames x the average time (projected) per frame. From that, an elapsed "second" is calculated during which a number of frames are counted.

[CrystalP]

a11599, yes the threading and time smoother are good candidates.

It's easy to test if the problem appeared with the threading: define "TARGET_VISTAPLUS" in the xbmc project on the current master branch.
That will revert to a threading implementation that was put in place on July 20 and turned off on July 31. Since things were good for playback on July 27/28, reactivating the previous threading should help figure out if threading is the culprit.
That's not a good long term fix, as that build will die on XP.

[Voyager]

I just reverse-merged d7c14268d663b067cc2f51102bdb72e48170658e and got a huge improvement. Still not perfect on ION, but much more in line with what I remember from a11599/isidrogar's initial patches. I suggest we do a bit more testing with this and get to the bottom of why this is happening. If this is the case, then somehow we may need to turn off frame smoother for video playback (or at least for PresentBob?)

Edit: the commit is dated July 20, but was merged on 29th.

[Hack_kid]

I fixed the issue by reverting this commit from aug 24

67a7dd0604218be1b3b82bea8a3575a89d25dc41

[Hack_kid]

Actually didn't work choppy playback still there

[Hitcher]

I just reverse-merged d7c14268d663b067cc2f51102bdb72e48170658e and got a huge improvement. Still not perfect on ION, but much more in line with what I remember from a11599/isidrogar's initial patches. I suggest we do a bit more testing with this and get to the bottom of why this is happening. If this is the case, then somehow we may need to turn off frame smoother for video playback (or at least for PresentBob?)

Edit: the commit is dated July 20, but was merged on 29th.

Sounds promising, can you share it?

[CrystalP]

Voyager-xbmc, I am not an expert but it seems to me that the time smoother is only used to time the GUI (animations, windows appearing/disappearing, etc.)
So it seems the issue is with AddTimeStamp() or GetNextFrameTime(), not with the use of a timestamp calculated differently.

That can be verified in a few steps, instead of completely reverting the commit d7c14268d663b067cc2f51102bdb72e48170658e.
For example, from current master, replace

Code:

frameTime = frameTimer->GetNextFrameTime(currentTime);

with

Code:

frameTimer->GetNextFrameTime(currentTime);
frameTime = XbmcThreads::SystemClockMillis();

Any perf difference? Then remove the line

Code:

frameTimer->GetNextFrameTime(currentTime);

Any difference? And finally remove the

Code:

if (flip)
  frameTimer->AddTimeStamp(currentTime);

note: all that in xbmc/utils/TimeUtils.cpp, function UpdateFrameTime(bool flip)

[Voyager]

@CrystalP: you're right, I can't find direct relationship. Probably just coincidental.
For those who want to test: http://www.megaupload.com/?d=YL8GFJZB
This build is same as master + YUV render target patch + revert of timesmooter.

[CrystalP]

@voyager-xbmc, I was thinking that maybe the time smoother calculations take too much time or somehow disturb the normal thread scheduling.

And after checking more carefully, it does have a small possibility to affect rendering via the frame limiter (CApplication::Render(), line 1991) but that code path doesn't seem active during normal video playback.
I'm not at a suitable computer to validate his.

[Voyager]

@CrystalP: I guess you're right on the smoother. It must have had a small side effect on threading or cpu load. I abandoned that investigation though, and tried your other suggestion, with the TARGET_VISTAPLUS to use the "better" threading method, and bingo!

Now I really think that's the one. Not a single frame drop anymore...
Test build here: http://www.megaupload.com/?d=NXMWZQ85
(I'm sorry it includes a few other commits from pull requests : libdvdid, mkv videos with dts fix, av delay, resume stacked movies, add unknown movies, manually add movies)

Feedback appreciated.

[xxrzdxx]

I also would like to confirm that Voyager's test build has resulted in zero dropped frames in my setup.