• AnyStream is having some DRM issues currently, Netflix is not available in HD for the time being.
    Situations like this will always happen with AnyStream: streaming providers are continuously improving their countermeasures while we try to catch up, it's an ongoing cat-and-mouse game. Please be patient and don't flood our support or forum with requests, we are working on it 24/7 to get it resolved. Thank you.

ReClock 1.8.7.9

James

Redfox Development Team
Staff member
Thread Starter
Joined
Oct 22, 2005
Messages
21,791
Likes
3,768
A debug build of the Reclockhelper.dll sneaked in. I'll make a new setup.
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
 
Yeah confirming 1.8.7.9 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,

TSR
 
Yeah confirming 1.8.7.9 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.
Just use the builit-in estimator. The DShow estimator should be replaced by something better, based on MediaInfo.dll.
 
Yeah confirming 1.8.7.9 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,

TSR
Did the "info" debug message box from 1.8.7.8 show the correct path / filename in such a situation?
 
Just use the builit-in estimator. The DShow estimator should be replaced by something better, based on MediaInfo.dll.

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.

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

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 1.8.7.7. (but same on 1.8.7.9).
Should I test with 1.8.7.8 with debug message box?
 
Yes. Or posting a logfile might help, too.

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

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

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

Attachments

  • reclock_log.zip
    6 KB · Views: 8
Alright. So with Reclock's built-in estimator disabled and Haali auto-enabling a subtitle stream:

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

Here's what 1.8.7.9 gives (logfile attached)
(no video stream found)
Sorry, no idea what could be wrong.
 
Sorry, no idea what could be wrong.

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)
 
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!
 

Attachments

  • reclock_log.zip
    175.7 KB · Views: 2
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!

Maybe media portal (or any other external refresh changer) doesn't send the WM_DISPLAYCHANGE message (doubtful, unless it is using powerstrip underneath)?
 
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.
 
Maybe media portal (or any other external refresh changer) doesn't send the WM_DISPLAYCHANGE message (doubtful, unless it is using powerstrip underneath)?

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.
 
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.

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

Code:
//------------------------------------------------------------------------------
// 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;

	OSVERSIONINFO l_ov;

	l_ov.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);
	if (::GetVersionEx(&l_ov))
		m_ntKernel = (l_ov.dwPlatformId == VER_PLATFORM_WIN32_NT);
	else
		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
									
									break;
								}
								else
									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
	CoInitialize(NULL);

	__try
	{
		l_detectedFrameRate = doIt( lpCmdLine );
	}
	__except( EXCEPTION_EXECUTE_HANDLER )
	{
		l_detectedFrameRate = -2.0;
	}


#endif
	// 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);
	MessageBox(NULL, l_msg, "Info", MB_ICONERROR|MB_SETFOREGROUND|MB_TASKMODAL|MB_SERVICE_NOTIFICATION);
#endif
	
	return *l_result;
}
 
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!

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.
 
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.
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.
 
Back
Top