MediaPortal Audio renderer - better video playback quality (1 Viewer)

[tourettes]

I recently played a Planet Earth episode with no problems, the dropped frames are from starting the file. Here is the data:

Looks really nice. Also you seem to have really good HW when it comes to the A/V clock drifting since only few corrections were made.

The second file however is a Band of Brothers episode which shows more dropped files then showed one which makes really bad playback, no pleasure to watch. I have included the same data for this file:

Really horrible indeed. Do you get the same results if you just change the audio renderer to default directsound one? It could be something in EVR presenter as well.

 

[red5goahead]

btw. could you describe a bit more that audio / video haste? Does video look odd or audio sound odd? Or is it just a lip sync that drifts abit?

No . sorry after 9 minutes the video hastes but for about 300-400 ms not more. aftet 9 minutes with previous versions was more than 3,4 seconds- the video is perfect no stuttering. the audio not. sometimes there are some clicks.
(the num adj in info in about 350-400)
attach the log for 30000 value. no test at 0 and 10000.

 

[Henkie Flits]

Just tried it Tourettes, same problem:

 

[tourettes]

Just tried it Tourettes, same problem:

Please check if it happens as well with the latest binary from: https://forum.team-mediaportal.com/...nter-dshowhelper-community-development-81148/

If yes, then please post a message in that thread if not then we need to continue it here. In any case Owlsroost need to check that specific file.

 

[red5goahead]

The test with value 0 for DevicePeriod is better. Same play and yet another improve to desynch issue.
Attach the log

 

[tourettes]

attach the log for 30000 value.

I thin the NULL buffer is drivers reaction to our request for zero bytes sized buffer. I'll check if that happens on my dev PC as well (zero bytes requested, hopefully yes so I can debug it easier).

Those could (or actually should) be heard as clicks / jumps / pops etc. since there will be a small amount of audio data that is going not to be rendered when such happens.

15-07-2010 17:48:52.517 [f34]DoRenderSampleWasapi Output buffer is NULL - numFramesAvailable: 0
15-07-2010 17:48:52.966 [f34]DoRenderSampleWasapi Output buffer is NULL - numFramesAvailable: 0
15-07-2010 17:48:53.052 [f34]DoRenderSampleWasapi Output buffer is NULL - numFramesAvailable: 0
15-07-2010 17:48:53.139 [f34]DoRenderSampleWasapi Output buffer is NULL - numFramesAvailable: 0

This is also source for click / po(o)p noise that you will hear. It just tells that CPU was not able to fill the buffers as quickly as driver / HW eats the data. Mainly the smaller the latency / buffer size the more timi critical the whole buffer filling will be (so less other processes, video decoding etc. should be happening).

15-07-2010 17:52:08.096 [f34]Buffer underflow detected!

 

[red5goahead]

attach the log for 30000 value.

I thin the NULL buffer is drivers reaction to our request for zero bytes sized buffer. I'll check if that happens on my dev PC as well (zero bytes requested, hopefully yes so I can debug it easier).

Those could (or actually should) be heard as clicks / jumps / pops etc. since there will be a small amount of audio data that is going not to be rendered when such happens.

15-07-2010 17:48:52.517 [f34]DoRenderSampleWasapi Output buffer is NULL - numFramesAvailable: 0
15-07-2010 17:48:52.966 [f34]DoRenderSampleWasapi Output buffer is NULL - numFramesAvailable: 0
15-07-2010 17:48:53.052 [f34]DoRenderSampleWasapi Output buffer is NULL - numFramesAvailable: 0
15-07-2010 17:48:53.139 [f34]DoRenderSampleWasapi Output buffer is NULL - numFramesAvailable: 0

This is also source for click / po(o)p noise that you will hear. It just tells that CPU was not able to fill the buffers as quickly as driver / HW eats the data. Mainly the smaller the latency / buffer size the more timi critical the whole buffer filling will be (so less other processes, video decoding etc. should be happening).

15-07-2010 17:52:08.096 [f34]Buffer underflow detected!

Sure , more event triggered by the exception traced to "DoRenderSampleWasapi Output buffer is NULL - numFramesAvailable: 0 message" and more desynch we have. The best result in 8 1/2 minutes the messages was 50.
In the case I test with 100 ms the messages was 15-20 in 20 seconds. and the desynch was very huge.

 

[tourettes]

Sure , more event triggered by the exception traced to "DoRenderSampleWasapi Output buffer is NULL - numFramesAvailable: 0 message" and more desynch we have. The best result in 8 1/2 minutes the messages was 50.
In the case I test with 100 ms the messages was 15-20 in 20 seconds. and the desynch was very huge.

I have currently one theory that looks like a plausible cause, before I have written some code for that as a test... could you check if slowing down the CPU speed (as low as you can so that it wont interfere the video decoding) changes anything. Looks like the CPU you have could be "too fast" and we need a bit more intelligence into the code. Atleast I hope it is that... 30C+ in room with the dev PC doesn't feel that good...

 

[tourettes]

(the num adj in info in about 350-400)

This shouldn't happen on 1:1, 1:2 or 1:3 etc. material. It simple shows that either the HW clocks are drifting really quickly (which I doubt) or the bias value is calculated wrongly. I'll add some more precision to the EVR presenter logging to cover this a bit more. Althou it shouldn't still cause any more drifting... only the audio quality will be a bit worser (onty when such adjustment is happening since audio is resampled for a brief moment).

SetBias: 1.0000000238

 

[red5goahead]

Sure , more event triggered by the exception traced to "DoRenderSampleWasapi Output buffer is NULL - numFramesAvailable: 0 message" and more desynch we have. The best result in 8 1/2 minutes the messages was 50.
In the case I test with 100 ms the messages was 15-20 in 20 seconds. and the desynch was very huge.

I have currently one theory that looks like a plausible cause, before I have written some code for that as a test... could you check if slowing down the CPU speed (as low as you can so that it wont interfere the video decoding) changes anything. Looks like the CPU you have could be "too fast" and we need a bit more intelligence into the code. Atleast I hope it is that... 30C+ in room with the dev PC doesn't feel that good...

I don't think so . I've a E4400 normaly run at 2.0 GHZ but now run at 2.4 I'll try to restore the normal fsb (200 Mhz instead 240)

(the num adj in info in about 350-400)

This shouldn't happen on 1:1, 1:2 or 1:3 etc. material. It simple shows that either the HW clocks are drifting really quickly (which I doubt) or the bias value is calculated wrongly. I'll add some more precision to the EVR presenter logging to cover this a bit more. Althou it shouldn't still cause any more drifting... only the audio quality will be a bit worser (onty when such adjustment is happening since audio is resampled for a brief moment).

SetBias: 1.0000000238

Remember the montor refresh is reported wrong . 75,000 Hz. instead 75.090 for reclock