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

[tourettes]

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

Hopefully that drifting is caused by the inaccuracy of the current query performance counter code (I'll provide the fixed GetCurrentTimestamp() method as soon as I have done my own testing...).

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.

Yep, testing on the different hardware might show some issues (hopefully not). But it is a good to test those before going into public test mode.

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.

There are few known oddities that could be need to taken care:

1) our TsReader is not able to report the fps rate of the played file (old EVR code is assuming every thing is 40.000 ms per frame if no rate is provided). This might break NTSC videos... Fixing f the TsReader is on the way, but I'm not sure if we can push that change into 1.1.0 (depends how busy djblu and gemx are )

2) Some other files might as well sometimes report no frame duration / fps. I guess we need to build some detection to workaround the possible issues.

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

codec might be responsible for sending the frame too late. maybe we could adjust that by having for example 40 ms (adjusted based on the source content) "buffer" for the arriving frames. Not sure if it works in practice, but at least it should be possible in theory.

Probably that I've broken this feature for installations where it worked. But because it never worked for me I can't find out.

I'll test that.

 

[Scythe42]

1) our TsReader is not able to report the fps rate of the played file (old EVR code is assuming every thing is 40.000 ms per frame if no rate is provided).

This is the only constant I left in as it is a workaround. If fps information cannot be detected, use 40ms. Therefore it should be safe to use m_rtTimePerFrame as a base for everything. I don't have ts files to test though and all my files provide frame rate information.

codec might be responsible for sending the frame too late. maybe we could adjust that by having for example 40 ms (adjusted based on the source content) "buffer" for the arriving frames. Not sure if it works in practice, but at least it should be possible in theory.

I thought about this is well like buffering the first second of playback. Probably a value that could adjust itself during playback if too many frames are received late from the mixer. Mixer quality control notifications didn't have any impact in my tests on this. Probably because the filters/codecs don't support notifications themself or don't send them out to the mixer. But not something I'd see happening for 1.1.0 as they are more important issues that need to taken care of to get at least an RC out. I'm a big supporter of stability before new features unless the feature are really enhancing the user experience or a simply overdue compared to other solutions.

 

[tourettes]

1) our TsReader is not able to report the fps rate of the played file (old EVR code is assuming every thing is 40.000 ms per frame if no rate is provided).

This is the only constant I left in as it is a workaround. If fps information cannot be detected, use 40ms. Therefore it should be safe to use m_rtTimePerFrame as a base for everything. I don't have ts files to test though and all my files provide frame rate information.

I guess we need to ask our users to suply a NTSC based .ts file. I would assume that it will yield some issues when m_rtTimePerFrame (40.000 ms default) doesn't match the real frame time.

 

[Scythe42]

I guess we need to ask our users to suply a NTSC based .ts file. I would assume that it will yield some issues when m_rtTimePerFrame (40.000 ms default) doesn't match the real frame time.

40ms would be for 25 non interlaced frames (aka PAL) which is the current default I kept. NTSC would be 33.36ms for 29.97 non interlaced frames.

I suggest we leave as it is in the current release (no fps info = 40ms) until this is fixed in the ts reader. BTW: why does MP come with an own ts reader. Shouldn't the be splitter responsible for handling transport stream files?

I don't have an TS files to test with that don't report fps. So I can't really help out here in regards to the ts reader.

 

[tourettes]

I suggest we leave as it is in the current release (no fps info = 40ms) until this is fixed in the ts reader. BTW: why does MP come with an own ts reader. Shouldn't the be splitter responsible for handling transport stream files?

We need multiple features that other splitters don't provide. For example DVB subtitles, teletext subtitles, streaming over network etc. Also channel changes during timeshifting buffer aren't handled that well with existing source filters. But in hosrt we just need to have own source filter to be able to provide all the needed functionality.

 

[Scythe42]

The patch is now complete and waits for first peer review by tourettes

The patch adjust the following to include proper frame dropping:

• More precise integer arithmetic for GetCurrentTimeStamp() and code adjustments to 100ns units like DirectShow to avoid < 1ms drifts.
  
• Frames are dropped when *pNextSampleTime < -m_rtTimePerFrame in CheckForScheduledSample(), so the next one can be presented during the vblank.
  
• Compensation in CheckForScheduledSample() for DVD menus where the timestamp of the frame on menu stills is always the same or only updates when an audio loop starts over. I could only test with the MS DVD Navigator, therefore it might not work with others correctly.
  
• Magic Numbers were removed as far as possible and are now connected to the file's fps.
  
• timeSetEvent will schedule a thread up to the presentation time or the frame duration whatever is smaller minus 10% of frame duration to compensate for not 100% reliable timeSetEvent under Windows < Win 7. XP being the worst here. Probably some fine tuning is needed here in the future by tracking the accuracy of timeSetEvent during playback. Next update should the patch get accepted.
  
• Adjusting source code formatting to be the same throughout the whole code and minor cleanup

So far except for bugs in filters, DVD navigator or MP itself I can play files very smooth. 23.976fps at 24Hz result in a frame dropped close to the theoretical 41,66 ms

Late scheduled samples are often caused by how a file was encoded and if one or more frames require a lot of CPU power (you won't see that in the task manager). Any file I remuxed from DVD or Blu-Ray runs without any dropped frames in a 1:1 frame rate setup unless an external event on the HTPC delays things every now and then. With DVDs interruptions in the IO stream causes a few judders now and then. But I keep everything on a larger Raid 6 array anyway.

If audio is off it stays off the same amout all the time (probably because of the processing chain), so you can easily compensate. For downloaded HD content it may vary though as they are often encoded very differently and codecs can't deliver all frames on time even on a Core i7 under Win 7 when out of a sudden way more computing power is needed for just a single frame. Windows can't adjust that quickly with it's current architecture I guess. Also we are not on a real time OS here, so some issues will always be there. x264 files are more likely to be affected than Xvid, which may point to a codec issue with that specific file's encoding. I general MPC latest SVN works very good, followed by CoreAVC and ffdshow always sucks on any file (even SD content...), because it's not fully multi-threaded I guess.

I'm looking into buffering pre-rendered frames to compensate for this to keep playback as smooth as possible. On my machine it's usually an out of sudden 200-300 ms thing. So probably buffering a full second could work. Need to think about this more first how to make this smooth. But this will not be a thing for 1.1.0 because I don't have that much time and like to take a look at why rewind is broken with everything except the internal DVD Player and TS reader.

Depending how much tourettes finds in the code that isn't OK or doesn't work on his machine the full patch should be ready for public testing soon. Because we are touching a core component here it's very likely that more than one iteration of adjustments to the EVR presenter is needed (especially to compensate for other issues) before the 1.1.0 release.

 

[tourettes]

Wouldn't want to be picky but...

close to the theoretical 41,66 ms

I thought your code was more accurate and would drop a frame only when needed, approx once per 41,66 s

 

[CHli]

Well it's seems that swiss timing is not that accurate anymore

 

[Scythe42]

Seconds, Milliseconds, Nanoseconds. I obvious lost track. Time to stop for today

 

[Seeco]

Sounds like there's great progression here, looking forward to trying the patch. I just wanted to ask another side question. When using Win 7 with latest MP beta, latest SAF version and Reclock as renderer, should I or should I not use V-Sync in Reclock? I have never fully grasped what V-sync does (or the logic behind the adjustment of it in Reclock) but I think it might be related to what's being discussed in this thread, right?