MP1 EVR Presenter/dshowhelper community development (14 Viewers)
- Thread starter Owlsroost
- Start date
- August 4, 2007
- 861
- 99
- Home Country
-
Spain
- Moderator
- #632
No more crashes here, so forget it about this.
@pnyberg, no problem with 1.1.2. I'm using 1.1.2.
- May 14, 2008
- 3,558
- 434
- Home Country
-
Germany
AW: Re: AW: MP1 EVR Presenter/dshowhelper community development
What about detecting live tv and then disabling bias > 1?
Didn't check source code yet - but I would assume that on your PC the both DLL versions will provide refresh rate information that is between 49.995 and 50.005. Te verify this start playback ten times with both DLL and provide the results.
Yes it will be problematic, but most likely the refresh rate is not exact 50 Hz anyway in any PC so there is always a margin of error in the broadcaster and playback rates (this is why TsReader does have small buffer before the live point).
I'm more worried about the newly introduced bias difference for 1:1 matches on audio renderer side. It will cause constantly resampled audio - making the audio quality a bit worse. EVR presenter should have some clamping to keep the almost 1.0 bias rates as 1.0. Anyone have idea what would be an optimal value for this? At least it must be less than the 23.976 vs. 24 difference
What about detecting live tv and then disabling bias > 1?
Re: AW: Re: AW: MP1 EVR Presenter/dshowhelper community development
Constant resampling should be always avoided if possible. There is much more fine grained resampling based speed correction also available in the audio renderer that is ment to take care the minor drifting of HW clocks. It should be used instead. Basicly it does the resampling only on needed basis, when v-sync is drifting too far away from the wanted position.
Constant resampling should be always avoided if possible. There is much more fine grained resampling based speed correction also available in the audio renderer that is ment to take care the minor drifting of HW clocks. It should be used instead. Basicly it does the resampling only on needed basis, when v-sync is drifting too far away from the wanted position.
- Thread starter
- #635
- Thread starter
- #636
Re: AW: MP1 EVR Presenter/dshowhelper community development
Hi Tourettes,
The refresh rate estimator was changed to a version of arion_p's 'linear regression' code back at SVN 26897 (1st Dec 2010).
Because this is much more accurate and reliable than my old method I removed the 'find best match to allowed refresh rates' code. That code couldn't differentiate between, for example, 23.976Hz and 24.000Hz, so it reported a compromise refresh rate of 23.988Hz for both.
If reporting 'accurate' measured rates to the audio renderer code is causing a problem, I could add back the 'find best match to allowed refresh rates' code - any thoughts ?
(Actually, the new refresh rate estimator is probably accurate enough to differentiate between 23.976Hz and 24.000Hz - a 0.1% difference, so the 'best match' code might work better than it used to).
Tony
Didn't check source code yet - but I would assume that on your PC the both DLL versions will provide refresh rate information that is between 49.995 and 50.005. Te verify this start playback ten times with both DLL and provide the results.
Yes it will be problematic, but most likely the refresh rate is not exact 50 Hz anyway in any PC so there is always a margin of error in the broadcaster and playback rates (this is why TsReader does have small buffer before the live point).
I'm more worried about the newly introduced bias difference for 1:1 matches on audio renderer side. It will cause constantly resampled audio - making the audio quality a bit worse. EVR presenter should have some clamping to keep the almost 1.0 bias rates as 1.0. Anyone have idea what would be an optimal value for this? At least it must be less than the 23.976 vs. 24 difference
Hi Tourettes,
The refresh rate estimator was changed to a version of arion_p's 'linear regression' code back at SVN 26897 (1st Dec 2010).
Because this is much more accurate and reliable than my old method I removed the 'find best match to allowed refresh rates' code. That code couldn't differentiate between, for example, 23.976Hz and 24.000Hz, so it reported a compromise refresh rate of 23.988Hz for both.
If reporting 'accurate' measured rates to the audio renderer code is causing a problem, I could add back the 'find best match to allowed refresh rates' code - any thoughts ?
(Actually, the new refresh rate estimator is probably accurate enough to differentiate between 23.976Hz and 24.000Hz - a 0.1% difference, so the 'best match' code might work better than it used to).
Tony
Hi there,
I had tried both 56 and 57. Both gave me lip sync issues after a period of time.
I will try and do some more testing this weekend and post logs.
My setup is ATI 5670, onboard sound, single seat, running 1.2.0.
Thanks,
J.
I had tried both 56 and 57. Both gave me lip sync issues after a period of time.
I will try and do some more testing this weekend and post logs.
My setup is ATI 5670, onboard sound, single seat, running 1.2.0.
Thanks,
J.
- Thread starter
- #638
Re: AW: MP1 EVR Presenter/dshowhelper community development
Yes, from audio quality point of view it would be better to "lie" the real refresh rate to audio renderer when it is close enough (needs to be studied a bit) to the media file's fps. Maybe something like 0.01 or 0.05 would be enough close.
Yes, from audio quality point of view it would be better to "lie" the real refresh rate to audio renderer when it is close enough (needs to be studied a bit) to the media file's fps. Maybe something like 0.01 or 0.05 would be enough close.
Re: AW: MP1 EVR Presenter/dshowhelper community development
The 1:1 rate I put in earlier is set at 1% (i.e. it will use that mode if the bias is between 0.99 and 1.01). I based this on a sensible correction rate of 2% and the allowable drift value of 22ms. That code has been there for quite a few versions so it's unlikely to be it.
The problem could be related to the code I've added which will allow midstream bias adjustment - it only activates if bias is changed while the stream is already playing (or at least it should only be active at that time). I'll take a look when I get home.
BTW I've got the accurate estimator on my build so I'm fairly sure it doesn't affect anything.
The 1:1 rate I put in earlier is set at 1% (i.e. it will use that mode if the bias is between 0.99 and 1.01). I based this on a sensible correction rate of 2% and the allowable drift value of 22ms. That code has been there for quite a few versions so it's unlikely to be it.
The problem could be related to the code I've added which will allow midstream bias adjustment - it only activates if bias is changed while the stream is already playing (or at least it should only be active at that time). I'll take a look when I get home.
BTW I've got the accurate estimator on my build so I'm fairly sure it doesn't affect anything.