<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">I've pushed an update to use 0.4 and 0.9.<br>
<br>
I'm not seeing any issues with regular video playback on intel<br>
(vaapi/software), nvidia (nvdec,vdpau,software) and Pi4.<br>
<br>
There are some issues - and I'll caveat these by saying I'm not sure<br>
whether they result from the recent avsync changes, from the long<br>
standing avsync2 code or other changes I've made recently.<br>
<br>
Firstly - playback of audio only files seems a little broken.<br>
Particularly MHEG/DVB radio and seeking. This may be related to a<br>
small fix I added for MHEG only streams - I need to check.<br>
<br>
Secondly - video only streams sometimes struggle to settle down at the<br>
start of playback - though I'm starting to wonder whether this is<br>
purely a Raspberry Pi issue.<br>
<br>
Thirdly - there is some very strange behaviour on OSX under certain<br>
conditions. Sometimes the video continually speeds up and slows down.<br>
Piotr reported this the other day and I can reproduce on my (very) old<br>
macbook. For me I only see it when using the inbuilt display and<br>
certain interlaced videos using double rate deinterlacing. If I<br>
connect to an external display, everything is fine. Due to the<br>
limitations of the macbook, I can't test heavily before I max it out -<br>
and frames are dropped naturally.<br>
<br>
The oddity with OSX internal displays is that they do not have a fixed<br>
refresh rate. Furthermore, vsync always falls back to busy wait - as<br>
there is no DRM. So the rendering code will not block in the same way<br>
when displaying a frame. I presume it will rate limit any refresh<br>
rates to the overall max for the display (presumably 60Hz) - but<br>
otherwise it doesn't appear to wait for OpenGL vsync (but it isn't<br>
tearing). I can't get my Christmas limited brain power around what<br>
might be happening. I should add that CPU load is low and OSX has no<br>
OpenGL performance monitors - so cannot check the GPU.<br>
<br>
Anyone have any ideas?<br>
<br>
Regards<br>
Mark<br><br></blockquote><div>Thank you Mark.  </div><div><br></div><div>In the second and third cases you mention above, does the timestamp data provide any clues as to what is occuring?  </div><div><br></div><div>To provide better visibility of what is going on, I have been patching mythplayer lib to also emit the lastfix value with the timestamp data when I wish to troubleshoot.  I also hacked together this simple bash script (attached) to parse the data into a comma delimited text file for easier viewing of the data in a spreadsheet program.  </div><div><br></div><div>I have been thinking about implementing a simple adaptive filtering / control algorithm which would dynamically adjust the filtering coefficient between an upper and lower bound based on the standard deviation of the sync calculated over a shifting window of frames.  I believe the comments from Mark S earlier in this thread also essentially propose an adaptive filter approach but I need spend some time examining.  On the flip side, I am hesitant to add complexity if not needed / really valuable.</div><div><br></div><div>If you send me some frontend log data with timestamps, I'd be happy to look over in order to see if the data suggests these are control problems or caused by something else.</div><div><br></div><div>Tim  </div><div><br></div><div><br></div></div></div>