> > My thought was to: > > 1/ make sure timestretch only works when it is 'safe', > i.e. the audio is not being decoded extranally.
this is important otherwise we will need to implement e.g. an AC3 transcode to support timestretch with AC3 spidf out. cant test this yet but shouldnt be that hard. I dont know how many instances like this there are but this could be incorporated into audio out classes. > > 2/ adjust the actual timestretch down to 90% depending on > how close to edge of the ringbuffer we are. So if we > start out at 150% we slow down in increments of 5% as > we get closer and closer to real-time. And if we jump > forward we lower the playback speed to 90%-95% if we > turn out to have jumped too close to the end, then > resume normal play when there is some space in front > of us. seems to me that this is too complex. instant reversion to x1 I would think is adequate. I have noticed the slower I go approaching the end point the less reliable the end detection is (old method). have just implemented my new method but is untested at the moment. > > What were you thinking of? the fix for this ticket only. I have a simpler algo in mind which minimizes DB access but still gets us close to the end reliably changing back to x1.0 your 2/ would be nice though. jumping forward to near the end should be ok as this will be caught on the next getframe which is where I put the trap for end nearness. cheers mark _______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
