Re: AW: Late dynamic refreshrate changer or fps detection without mediainfo
I think there is no such available. And adding such should be done as a callback.
It is safer to put whole thread function inside a "try". In future if someone adds new code he/she might forgot the "try" for the new code.
TV's usually handle both 23.976 and 24. Those both are required since for example Blu-rays can be having both fps. 29.97 and 30 is next such pair that would fail Why limit the 1 Hz as difference? (Math.Abs(fps - newfps) > 1 <-- does such, not wth 0.1). Basicly you would be making an assumption that if the 1st and 2nd queries produce close enough match the 1st one was correct (while it can be as much wrong as with greater than 1 hz difference). Just remove the 1 Hz check and the result are better
OK i'll try to make my code better. Some questions before i can start:
1.) i wasn't able to find something like IsGraphReady or another way to determine if the graph is started and playing? Can someone help with an idea?
I think there is no such available. And adding such should be done as a callback.
2.) should i put a try and catch around the whole stuff in the thread functions? Or only while calling external stuff?
It is safer to put whole thread function inside a "try". In future if someone adds new code he/she might forgot the "try" for the new code.
What is the problem here? Are there tv's which can display 24.000Hz and 23.976Hz? I thought all TVs can only display 24hz - so the nearest one would be 24hz and 25hz and i check for a difference smaller than 0.1.What happens if the 1st detection is 24.000Hz and the 2nd 23.976Hz? Wont we end up in the wrong refresh rate? Also I would prefer that dshowhelper side would be able to provide more exact estimates / guesses about the fps since the code on C# side is really ugly
TV's usually handle both 23.976 and 24. Those both are required since for example Blu-rays can be having both fps. 29.97 and 30 is next such pair that would fail Why limit the 1 Hz as difference? (Math.Abs(fps - newfps) > 1 <-- does such, not wth 0.1). Basicly you would be making an assumption that if the 1st and 2nd queries produce close enough match the 1st one was correct (while it can be as much wrong as with greater than 1 hz difference). Just remove the 1 Hz check and the result are better