Discussion in 'ReClock' started by James, Feb 19, 2012.

  1. James

    James Redfox Development Team Staff Member

  2. SamuriHL

    SamuriHL Retired Moderator

    2 versions in one day. Nice! :D
  3. leeperry

    leeperry Well-Known Member

    fixed, thanks!

    I'm still hoping for slower playback speeds than "refresh rate/20" but I guess you've got something against CRT users yoannletroll.gif
  4. theshadowrunner

    theshadowrunner Well-Known Member

    Yeah confirming is working OK.
    About the Haali (or is it Reclock's?) bug:
    If you have Haali set to auto-enable a substream, ReClock's Directshow estimator becomes nonfunctional.

    How to reproduce:
    1. on Haali's side, set it to auto-enable a substream (for exemple auto-enable english subs when audio is japanese).
    [Options > Languages > "Audio and Subtitle languages" > write "jpn,eng" without quotes in the text field)]
    2. on ReClock's side, just disable the built-in estimator.

    -> Result: When playing a MKV with jpn audio and eng subs, ReClock reports "no video stream found" forever.

    Interestingly, if Haali doesn't auto-enable a substream, ReClock's directshow estimator works just fine.

    James, do you reckon this is an issue on ReClock side or Haali side?
    If Haali, I shall report to Corecodec/Haali, but I'm unsure atm.
    So please if you have a couple minutes for testing, let me know.
    See you,

  5. James

    James Redfox Development Team Staff Member

    Just use the builit-in estimator. The DShow estimator should be replaced by something better, based on MediaInfo.dll.
  6. James

    James Redfox Development Team Staff Member

    Did the "info" debug message box from show the correct path / filename in such a situation?
  7. theshadowrunner

    theshadowrunner Well-Known Member

    I do use both estimators. It's just that the Directshow one is instant whereas the built-in one takes a couple seconds.
    It's not a couple seconds that is problematic, it's switching resolutions while using madVR. In rare cases switching resolution will hang when using built-in estimator + madVR.

    Oh I didn't test this at all.
    This haali-auto-enable-sub + Reclock dshow estimator = no video stream thing is old, I've been testing it on (but same on
    Should I test with with debug message box?
  8. James

    James Redfox Development Team Staff Member

    Yes. Or posting a logfile might help, too.
  9. theshadowrunner

    theshadowrunner Well-Known Member

    Alright. So with Reclock's built-in estimator disabled and Haali auto-enabling a subtitle stream:

    Here's what gives (debug message box):
    F:\test.mkv = -2.000000 -2.000000 -1073741824

    Here's what gives (logfile attached)
    (no video stream found)

    Attached Files:

  10. James

    James Redfox Development Team Staff Member

    Sorry, no idea what could be wrong.
  11. theshadowrunner

    theshadowrunner Well-Known Member

    No worries. So I guess it's a Haali issue.
    (which would tend to be corroborated by this fact: if Haali doesn't auto-enable a subtitle stream, ReClock's directshow estimator works just fine)
  12. zachs78

    zachs78 Member

    EDIT: Moved. Wrong thread sorry.
    Last edited: Feb 22, 2012
  13. vpupkin

    vpupkin Member

    ReClock unable to determine actual refresh rate

    I have this really strange issue with ReClock unable to recognize actual screen refresh rate. It's very reproducible on my machine. Here are the steps (I use the latest Mediaportal with automatic refresh rate changer and Reclock as a renderer):

    - Initial set up: 23.976hz refresh rate
    1. Start playback of video with 23.976 fps (say, Video23.avi)
    - Mediaportal detects that fps match refresh rate, so no change in refresh
    - Reclock detects 23.976 fps and refresh, and locks in
    - Everything is fine
    2. Now, stop playback and start video with 25 fps (say, Video25.avi)
    - Mediaportal detects that fps does NOT match refresh rate, and switches screen to 60hz (as my TV doesn't support 50hz)
    - Reclock detects 25 fps and 60hz refresh, and doesn't lock in
    - Everything is OK (well, as expected)
    2. Now, stop playback and start video with 23.976 fps again (even the same Video23.avi)
    - Mediaportal detects that fps does NOT match refresh rate, and switches screen back to 23.976hz (this is confirmed by e.g. PowerStrip)
    - Reclock detects 23.976 fps but still 60hz refresh (!?), and speeds up to 24fps
    - Everything is certainly not OK (I can see dropped frames every ~40sec, as expected for 24 vs 23.976 mismatch)

    Sometimes in step 3 I see ReClock detecting 0hz, but mostly it's stuck at 60hz. I tried different combinations of DDR / D3D, and GDI/pStrip on/off, with no changes in behavior.

    I looked at the log file (attached for scenario above), and I can see that CReClock destructor is called after the first playback (@23.976), with instance recreation on the second play. But after the second one (@60hz), destructor is not called, and it seems that the same instance is being reused for playback #3 (which doesn't work).

    Let me know if you need any additional information - Thanks!

    Attached Files:

  14. James

    James Redfox Development Team Staff Member

    Maybe media portal (or any other external refresh changer) doesn't send the WM_DISPLAYCHANGE message (doubtful, unless it is using powerstrip underneath)?
  15. theshadowrunner

    theshadowrunner Well-Known Member

    James, a last question on the subject.
    Before I report the Directshow-estimator-broken-when-Haali-auto-enables-a-subtitle-stream issue to Corecodec/Haali, could you tell me what information is mandatory for the dshow estimator to work properly?
    Thank you.
  16. vpupkin

    vpupkin Member

    No, PowerStrip is not involved, MediaPortal in my setup uses standard windows methods of setting up refresh rates (i.e. my ATI adapter has a refresh rate of 23, which in reality is 23.976, and MePo is simply setting up refresh rate to 23). As I mentioned, I verified with PowerStrip that actual refresh rate is fine; it's just that ReClock is not picking it up.

    And remember, the second time (switch from 23.976hz to 60hz) refresh rate change and ReClock picking it up correctly work just fine.
  17. James

    James Redfox Development Team Staff Member

    That's what it does (and it can be easily changed to use mediainfo instead by a volunteer):

    // File: ReClockHelper.cpp
    #define ATLTRYALLOC(x) x;
    #include <streams.h>
    #include <math.h>
    #include <qedit.h>
    #include <windows.h>
    #include <atlbase.h>
    bool isNt( void )
    	bool m_ntKernel;
    	l_ov.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);
    	if (::GetVersionEx(&l_ov))
    		m_ntKernel = (l_ov.dwPlatformId == VER_PLATFORM_WIN32_NT);
    		m_ntKernel = false;
    	return m_ntKernel;
    double doIt( LPSTR lpCmdLine )
    	double l_detectedFrameRate = -2.0; // no stream found
    	CComPtr<IMediaDet> l_mediaDet;
    	if (SUCCEEDED (l_mediaDet.CoCreateInstance(__uuidof(MediaDet))))
    		WCHAR l_fileNameWide[1024+1];
    		if( MultiByteToWideChar(isNt() ? CP_UTF8:CP_ACP, 0, lpCmdLine, -1, l_fileNameWide, 1024) )
    		if (SUCCEEDED (l_mediaDet->put_Filename(l_fileNameWide)))
    			long l_streamCount = 0;
    			if (SUCCEEDED (l_mediaDet->get_OutputStreams(&l_streamCount)))
    				for (int i=0; i<l_streamCount; i++) 
    					if (SUCCEEDED (l_mediaDet->put_CurrentStream(i)))
    						GUID l_guid;
    						if (SUCCEEDED (l_mediaDet->get_StreamType (&l_guid)))
    							if (l_guid == MEDIATYPE_Video)
    								HRESULT hr = l_mediaDet->get_FrameRate(&l_detectedFrameRate);
    								if (SUCCEEDED (hr))
    									if (l_detectedFrameRate <= 0.5)
    										l_detectedFrameRate = -1.0; // stream found, but no framerate found
    									l_detectedFrameRate = -1.0; // stream found, but no framerate found
    	return l_detectedFrameRate;
    int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd)
    	double l_detectedFrameRate = -2.0; // no stream found
    #if 1
    		l_detectedFrameRate = doIt( lpCmdLine );
    		l_detectedFrameRate = -2.0;
    	// not pretty ...
    	float l_frameRate = (float)l_detectedFrameRate;
    	int *l_result = (int*)(&l_frameRate);
    #ifdef _DEBUG
    	char l_msg[2048+1];
    	sprintf(l_msg, "%s = %f %f %d", lpCmdLine, l_detectedFrameRate, l_frameRate, *l_result);
    	return *l_result;
  18. theshadowrunner

    theshadowrunner Well-Known Member

    Thanks a bunch James, if the code doesn't help, I don't know what will ;)
  19. vpupkin

    vpupkin Member

    I digged a bit more, and it turns out that external change to refresh rate here is coincidental - the actual issue seems to be with bitstream (AC3) vs PCM. So the example above (which doesn't work properly) the first file has PCM audio (after which everything works), but the second file has AC3 audio which I bitstream to my receiver. And after the second file things stop to work in step 3 (as described above).

    If, however, I pick a file with PCM audio (and still 25fps) in step 2, then everything works fine in step 3, and video refresh rate is detected properly

    With the analysis of the log file, it still seems to me that something is not cleaned up properly after a playback with bitstreamed audio. I have tried it with different files / combinations of audio / fps, and it is consistent with this hypothesis.

    Can you please take a look? Thanks.
  20. James

    James Redfox Development Team Staff Member

    I believe this happens, if "Disable media speed correction with bitstream" is checked.
    Seems like a bug in ReClock to me. :eek:
    Temporary workaround: Uncheck this option.