[other] Problems with dropping frames with EVR (1 Viewer)

[tourettes]

Re: AW: Re: AW: Problems with dropping frames with EVR

For shure it is used.

Function: MPEVRCustomPresenter:resentSample

  place2 = GetCurrentTimestamp();
  CHECK_HR(hr = MyGetService(
    pBuffer, 
    MR_BUFFER_SERVICE, 
    __uuidof(IDirect3DSurface9), 
    (void**)&pSurface),
    "failed: MyGetService");
  place2 = GetCurrentTimestamp()-place2;

The place 2 variables are from my testing how long it takes. And it takes between 0.3s up to 15ms on my system. I'm not shure why this result is not cached. But there are more strange places where my measurement shows strange ms consumption.

My bad, I didnt search from the whole project inside dshowhelper. I had a look and it is the way how samples are asked from EVR queue (MSDN -> Uncompressed Video Buffers (Windows)).

Dunno why it is so slow on some cases, but its not our code that causes it to be slow (unless ome MP thread is blocking the CPU...). I'll check how slow it is on my dev pc.

Regarding plugins:
@tourettes:
Isn't it possible to run all plugins under LOW / IDLE system priority in general?

No, as plugins can create own threads, with any priority level they want. Or plugins can use the MP main thread as well to do what ever they want. It's up to plugin developers to write code that is sane.

 

[tourettes]

Re: AW: Re: AW: Problems with dropping frames with EVR

For shure it is used.

Function: MPEVRCustomPresenter:resentSample

  place2 = GetCurrentTimestamp();
  CHECK_HR(hr = MyGetService(
    pBuffer, 
    MR_BUFFER_SERVICE, 
    __uuidof(IDirect3DSurface9), 
    (void**)&pSurface),
    "failed: MyGetService");
  place2 = GetCurrentTimestamp()-place2;

The place 2 variables are from my testing how long it takes. And it takes between 0.3s up to 15ms on my system. I'm not shure why this result is not cached. But there are more strange places where my measurement shows strange ms consumption.

My bad, I didnt search from the whole project inside dshowhelper. I had a look and it is the way how samples are asked from EVR queue (MSDN -> Uncompressed Video Buffers (Windows)).

Dunno why it is so slow on some cases, but its not our code that causes it to be slow (unless ome MP thread is blocking the CPU...). I'll check how slow it is on my dev pc.

Cannot reproduce any high latency in that code part. Most of the time the delay is really minimal, and max values I did see are well under 0.1 ms. Something is most likely hogging the CPU (dont ask me what ).

13-02-2010 15:07:31.482 [1694]PresentSample() place2: 0.0049 ms
13-02-2010 15:07:31.498 [1694]PresentSample() place2: 0.0045 ms
13-02-2010 15:07:31.519 [1694]PresentSample() place2: 0.0065 ms
13-02-2010 15:07:31.537 [1694]PresentSample() place2: 0.0046 ms
13-02-2010 15:07:31.559 [1694]PresentSample() place2: 0.0064 ms
13-02-2010 15:07:31.577 [1694]PresentSample() place2: 0.0049 ms
13-02-2010 15:07:31.599 [1694]PresentSample() place2: 0.0060 ms
13-02-2010 15:07:31.619 [1694]PresentSample() place2: 0.0060 ms
13-02-2010 15:07:31.639 [1694]PresentSample() place2: 0.0066 ms
13-02-2010 15:07:31.659 [1694]PresentSample() place2: 0.0062 ms

 

[OnkelChris]

AW: Problems with dropping frames with EVR

puh... I have some weird problem... After recognizing, that SAT.1 is recognized at 25fps (other channels are running at 50fps), I did some longterm tests... My systems is running for several hours. Now and then I take a look if everything is smooth. It's not the microstutters which where in older SVN's, but it's noticeable evry few seconds (it's random, not the same time between the "stutters")... If I then open the graph, the red line is (very) choppy and the whole line moving up or down in the graph...

This occurs on SAT.1 which is playing at 25fps. (Is this normal, that SAT.1 is 25fps or should it be like the others at 50fps?). My TV is 50Hz. I am using the dll #2, which is in the current SVN.

(In 9 of 10 times it helps, when I press pause and then 1 second later play again. but it seems to return)

I will do the same on a 50fps channel. Will report back later... (I know that liveTV is something different then playing back a record)

 

[tourettes]

Re: AW: Problems with dropping frames with EVR

puh... I have some weird problem... After recognizing, that SAT.1 is recognized at 25fps (other channels are running at 50fps), I did some longterm tests... My systems is running for several hours. Now and then I take a look if everything is smooth. It's not the microstutters which where in older SVN's, but it's noticeable evry few seconds (it's random, not the same time between the "stutters")... If I then open the graph, the red line is (very) choppy and the whole line moving up or down in the graph...

This occurs on SAT.1 which is playing at 25fps. (Is this normal, that SAT.1 is 25fps or should it be like the others at 50fps?). My TV is 50Hz. I am using the dll #2, which is in the current SVN.

(In 9 of 10 times it helps, when I press pause and then 1 second later play again. but it seems to return)

I will do the same on a 50fps channel. Will report back later... (I know that liveTV is something different then playing back a record)

What decoder you are using? MS one has some deinterlacing issues (that shows with stuttering) with few HD broadcasts.

 

[OnkelChris]

AW: Problems with dropping frames with EVR

ah sry... forgot to say, that I only have SD TV... (DVB-T)

Indeed, I changed from MPC to MS Decoder, because MS uses my graphicscard on LiveTV... But I will do the same tests with the MPC the next days. The only thing which confuses me, is that only SAT.1 seems to be recognized as 25fps channel.

 

[grubi]

AW: Problems with dropping frames with EVR

OnkelChris:

I also encountered some stutter problems which seems to be codec related.
I was running MSCodec with ffdshow audio codec.
After switching everything to MS codecs, problems seems to be gone (hopefully), beside the problem I now have with blocky picture on HD (which seems to be Catalyst releated).

 

[disaster123]

AW: Problems with dropping frames with EVR

tourettes
thanks for testing this - in my case it is about 0.01ms sometimes for 10 min but then suddently it accours that it takes up to 16ms for 1 minute or so. I'll try to find out why. DO you have an idea how this could happen? I mean this thread runs as TIME_CRITICAL priority - how can this happen?

Is there any chance to get my new scheduler dll into a wieder testing range?

 

[tourettes]

Re: AW: Problems with dropping frames with EVR

@tourettes
thanks for testing this - in my case it is about 0.01ms sometimes for 10 min but then suddently it accours that it takes up to 16ms for 1 minute or so. I'll try to find out why. DO you have an idea how this could happen? I mean this thread runs as TIME_CRITICAL priority - how can this happen?

No clue really. It's MS code after all, so we dont have any visibility what happens there. It could be something that is holding a lock on DirectX resources (texture / surface in MP rendering loop?) that would block the DX.

Is there any chance to get my new scheduler dll into a wieder testing range?

I would recommend a separate thread to be opened for that purpose, after the next SVN build (or RC1 which ever comes first) is out to have good base as comparision.

 

[mylle]

tourettes

What codecs do you recommend?

 

[tourettes]

What codecs do you recommend?

Here MS H.264 decoder works pretty nicely (if you exclude those few broadcaster samples that drives it nuts ). Unfortunately it is hard to say what is good since HW and used video material has huge effect on the results. So only good advice is to test them all and pick the one that gives the least trouble in your setup & environment.