Audio sync problems when screen set to 24 Hz (2 Viewers)

[CHli]

This has been an amazing reading thanks Scythe42 and tourettes !

Also thank you for having this discussion in the public forum... (I hate the fact that I don't have access to developer private forum since there is so much to learn)

 

[Jeditrav]

Also thank you for having this discussion in the public forum... (I hate the fact that I don't have access to developer private forum since there is so much to learn)

Agreed!

 

[risu]

I don't mean to sound harsh, but I hate the fact that mantis links really often to private dev forums anyway. It's like telling look around here if you have this issue.. ..oh but you can't, you ain't good enough

It doesn't really give people the feeling they are dealing with really open software when decisions and software issues are partly discussed in the cabinets. I get the point why it's there in the first place, but I'd hope when dealing with software bugs in particular, discussion would be on open forums.

I do like the recent move on giving opportunity for community to supply patches and new features more easily. It's really big improvement and great idea. As you can see, people really want to help if they can, but it's much harder when some stuff is hidden and shown only for few.

 

[tourettes]

I don't mean to sound harsh, but I hate the fact that mantis links really often to private dev forums anyway. It's like telling look around here if you have this issue.. ..oh but you can't, you ain't good enough

It doesn't really give people the feeling they are dealing with really open software when decisions and software issues are partly discussed in the cabinets. I get the point why it's there in the first place, but I'd hope when dealing with software bugs in particular, discussion would be on open forums.

We have had few times discussion about the issue and possibility to open team internal forums. It is a double edged sword with it's good and bad sides.

In my opinion:

• Currently forums (and lot of technical threads as well) contain lot of personal discussion that has never been intended for the public (family etc.). It would be an impossible task to filter all that content out from the current threads. And having the technical discussion at two places (old treads would have to be kept closed and only new ones would be public) would harden the development.
• Lot of "noise" would slip into the development discussion threads. Are we there yet? Are we there yet... I want to have that feature... Such would hinder the development and at least I get pissed off when people are constantly asking or demanding something. After all I get such demands already at work, so no need to spoil a hobby with such (The scene from Shrek is pretty good in describing the feeling...) The patch submission sub forum is already containing a lot of such "noise" and when cleaning up such triggers pissed of PMs send to me it doesn't motivate much.

As a good side it could draw more developers as the progress would be much more visible but I think the costs are just too high.

I do like the recent move on giving opportunity for community to supply patches and new features more easily. It's really big improvement and great idea. As you can see, people really want to help if they can, but it's much harder when some stuff is hidden and shown only for few.

Yes, it has shown pretty good signs, althou not as good as I (and probably) others would had hoped. Patch submissions are mainly focusing on the new features. If we would have been receiving as many bug fixes as we been receiving the new feature patches we would have been already been able to release 1.1.0 And that would have helped us to steer the focus into MPII direction much quicker.

So, people please start thinking the bugs in Mantis before providing patches for new features (it is not any harder as you need to understand the old system for the new features, unless you want to be creating new bugs ).

Getting a bit off topic, please start a new thread if this is wanted to discuss more.

 

[Rayures]

Actually everyone should test the DLL, just to make sure we aren't breaking something with it.

Using the dll on a Win7 x64; MP1.1B1; HD3200 & refresh rate changer -system. So far... (17minutes in the dark knight) perfect sync @24hz. No other strange behavior found so far.

 

[Seeco]

How do I go about to incorporate the .dll file in my MP install, and where can I find it? Oh and one more thing - will there still be a need for using Reclock after this? I use 24Hz for 23.976fps, 50Hz for 25fps and 60Hz for 30fps. Is Reclock still needed to fix the 23.976->24Hz thing?

 

[tourettes]

How do I go about to incorporate the .dll file in my MP install, and where can I find it? o test the DLL you need to

1) Shut MP down
2) make a backup of the dshowhelper.dll file in MP's installation folder
3) copy the new file over the dshowhelper.dll in MP's installation folder
4) start MP

DLL itself was in some of the posts. Personally I would wait few days until the final patch is ready and then take part in the public testing thread.

Oh and one more thing - will there still be a need for using Reclock after this? I use 24Hz for 23.976fps, 50Hz for 25fps and 60Hz for 30fps. Is Reclock still needed to fix the 23.976->24Hz thing?

ReClock is still needed with those non-matching refresh rate & fps combos. I'm currently investigating few tricks that could be used to replace the ReClock with the small refresh rate & fps mixes. It wont definitely be part of the patched EVR presenter that is going to be tested in public. Only time will tell if it ever sees the daylight, but currently I'm pretty optimistic

 

[Scythe42]

Submittable patch version is ready on the weekend. Currently too much to do at work. I need to finish my final tests if it's better to drop a frame after it's 3/4 of the display time late or when it's already later the full display time of the frame.

The first one drops a little to much frames for my taste. The later seems to work better when there is already another frame in the queue. But when frames are provided late by the mixer I can't really tell the difference because there is usually a larger visible judder anyway and constant late frames until I decide they are too late now.

Wait as long as possible is the correct strategy. But what's too long?

Help! I can't decide here.

 

[tourettes]

Submittable patch version is ready on the weekend. Currently too much to do at work. I need to finish my final tests if it's better to drop a frame after it's 3/4 of the display time late or when it's already later the full display time of the frame.

Not sure, but I would assume that if frame is late as much that the v-sync margin has already gone then presenting it will be moved to the next frame (and there would be a jump in future by one frame presentation time). And that could cause the next frame to be late with higher probability. So, if frame is late from its display time it might be a good idea to drop it always.

We should try to find the real reason why mixer provides the frames late. Basicly it shouldn't happen at all if the CPU is not too busy and our presentation code is ok.

The first one drops a little to much frames for my taste. The later seems to work better when there is already another frame in the queue. But when frames are provided late by the mixer I can't really tell the difference because there is usually a larger visible judder anyway and constant late frames until I decide they are too late now.

Is the dropping happening on 23.976 fps at 24 Hz? Or with 1:1 refresh and fps?

Could you send me a private post with that patch as an attachement? That way I could already starting the internal testing and deploying the public test would be much faster. I might also be able to pick up possible bugs as I'm running on a different HW than you.

 

[Scythe42]

Could you send me a private post with that patch as an attachement? That way I could already starting the internal testing and deploying the public test would be much faster. I might also be able to pick up possible bugs as I'm running on a different HW than you.

I'm probably too confused at the moment with all the timings, limits and stuff I tried and everything is ok.

I clean up my patch and remove some recent experiments with the drifting timer (0.2ms inaccuracy on my machine per frame) and add proper comments as well as detailed bug description for the root cause. Will be ready Saturday. Need to watch my new Blu-Rays first

I'll send it first to you for peer review because you have different hardware and know the code better than I do. After all it's my first patch for MP. This should speed up things before we go to public testing of the complete patch. With a base component we need to be more careful as this now changes more than the quick fix I posted last week.

Everything now depends on a file's fps and there are no hardcoded ms values anymore related to the issue. I still have some experimental stuff in it. But you'll see.

Once submitted I try to find out why samples are coming late from the mixer depending on how a file is encoded. Probably filter related but I'm not sure here. I also check why rewind doesn't show any frames regardless of the material on my machine (same with the unpatched DLL). Probably that I've broken this feature for installations where it worked. But because it never worked for me I can't find out.