<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><br>
Out of curiosity - could that zero offset be estimated?<br>
<br>
I ask because at some point I would like to test adding a couple of<br>
additional a/v sync adjustments - and clearly the greater the accuracy<br>
the better.<br>
<br>
The first adjustment is to account for FFmpeg hardware deinterlacers<br>
(currently only VAAPI VVP - but may add NVDEC soon) that do a little<br>
buffering. As they are processed after a/v sync, we will need to pass<br>
back an offset - probably on the next pass.<br>
<br>
The second is to handle a/v sync adjustments that are<br>
required/reported by displays via the EDID. I recently added some EDID<br>
parsing to our code and it only requires a few extra lines to parse<br>
out the sync adjustments required when displaying with interlaced and<br>
progressive modelines.<br><br></blockquote><div> </div><div>I was able to do a little more testing today and figured out how to nicely parse the log playback,timestamp data into a comma-delimited file to enable me to look more closely at some real data. </div><div><br></div><div>First, I found that a 0.4 gain and 0.9 filter as I initially proposed does work well. I think you were actually right to leave it there. I didn't notice increased frame drops or other issues under these settings.</div><div><br></div><div>Initially, I was more inclined to highly dampen the control output to minimize responding to noise but the filtering takes care of that well enough even with a higher gain.  As an example, here (<a href="https://imgur.com/EcKuA8J">https://imgur.com/EcKuA8J</a>) is a plot showing some data I collected when viewing a progressive channel and an interlaced channel successively at the gain=0.4 & filter=0.9 settings.  It is the deinterlacing that adds much jitter to the measured sync. </div><div><br></div><div>The jitter and measurement are also more centered around zero than in my initial simulation (I incorrectly assumed jitter would manifest mostly as lag).  As a result, there is no corresponding zero offset in the control under the real conditions that needs to be compensated.</div><div><br></div><div>I would be interested to see some of the raw data reported by the EDID as well as whatever ffmpeg returns with the processed frames.  Is the buffering you speak of the reason that the sync measurement becomes is so much noisier when deinterlacing is in use?  </div><div><br></div><div>Regards,</div><div>Tim</div><div><br></div><div><br></div><div><br></div><div><br></div></div></div>