Garbled audio after seek about omxplayer HOT 12 CLOSED

Yes, I see it. I start the audio/video/clocks differently in xbmc, and that doesn't misbehave, so I'll try porting that scheme back to omxplayer.

from omxplayer.

Let me know if there is anything I can do to help.

from omxplayer.

The merge with xbmc's code has been problematic and was shelved a while back. (Playback stalled after seeking).
Had another go last night and got past that issue. The garbled audio issue did seem improved,
but passthrough was broken. Hopefully will be able to fix that soon.

from omxplayer.

Great, thanks for the update.

from omxplayer.

Can you try now after updating?

from omxplayer.

I don't notice a difference. Does the trailer seek OK for you?

from omxplayer.

It was fine at some point yesterday. It's not now...

from omxplayer.

Okay, try now. I'd lost the clock stopping code when flushing.

from omxplayer.

That fixes it, thanks!
Is there a reason for this change?

if(pts != DVD_NOPTS_VALUE)
-    m_av_clock->OMXMediaTime(pts);
+    m_av_clock->OMXMediaTime(0.0);

It makes subtitles reset to 0, which isn't a big deal, but not as nice as having the clock do one hop.

from omxplayer.

xbmc now uses OMXMediaTime(0.0) to mean clock not yet started.
Any user of OMXMediaTime should test for 0.0 and treat that as no information.
So subs should do nothing if OMXMediaTime()==0.0.

What's the issue ?
Is it if there is a sub that should display at pts=0 then it appears briefly when seeking? (which should be easy to suppress). Everything then recovers just after that.

Or is there something else going wrong?

from omxplayer.

I see. I'll figure out what to do with subtitles. I guess there are a few places in omxplayer.cpp where this should be taken into account as well, for instance, seeking twice within a short time span causes 0 to be used as the base time.

from omxplayer.

Was this issue ever resolved (seeking twice causes 0 as base time)?

from omxplayer.