[FFmpeg-cvslog] ffplay: fix updating external clock after seeking

[Reimar Döffinger]

On 29 Nov 2012, at 03:25, git at videolan.org (Marton Balint) wrote:
> ffmpeg | branch: master | Marton Balint <cus at passwd.hu> | Fri Nov 23 00:23:11 2012 +0100| [2efd01a32f0cc7849794f7a866fddf3991b5f5ce] | committer: Marton Balint
> 
> ffplay: fix updating external clock after seeking
> 
> Now it should work for the timestamp based and the byte based case as well.
> Also only update the external clock if the seeking was successful.
> 
> Signed-off-by: Marton Balint <cus at passwd.hu>
> 
>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=2efd01a32f0cc7849794f7a866fddf3991b5f5ce
> ---
> 
> ffplay.c |    7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/ffplay.c b/ffplay.c
> index c5ad70f..a3bda0e 100644
> --- a/ffplay.c
> +++ b/ffplay.c
> @@ -2669,8 +2669,13 @@ static int read_thread(void *arg)
>                     packet_queue_flush(&is->videoq);
>                     packet_queue_put(&is->videoq, &flush_pkt);
>                 }
> +                if (is->seek_flags & AVSEEK_FLAG_BYTE) {
> +                   //FIXME: use a cleaner way to signal obsolete external clock...
> +                   update_external_clock_pts(is, (double)AV_NOPTS_VALUE);
> +                } else {
> +                   update_external_clock_pts(is, seek_target / (double)AV_TIME_BASE);

I wonder if it wouldn't be better to always use the first case.
Even if the seek was successful that does not mean we arrived anywhere close to the target (and IMHO the patch to avoid seeking before the start just hides one very common case of this without fixing the problem).
No, I don't think it's important, it just seems to be a potential failure point.