[MPlayer-cvslog] r31201 - trunk/stream/cache2.c

[Reimar Döffinger]

On Mon, May 24, 2010 at 03:59:39PM +0000, Carl Eugen Hoyos wrote:
> Ivan Kalvachev <ikalvachev <at> gmail.com> writes:
> 
> > Reimar, while you are working on cache2.c I'd like to make a feature request.
> > 
> > Could you try to find some workaround for the known problem with eof
> > handling.
> 
> Don't you think it is more annoying that seeking fails for some samples with
> -demuxer lavf (but works with -demuxer mpegts and ffplay)?
> mplayer scans the whole file (which is 8GB in my case and takes some time) and
> quits then, no matter if forward- or backward seeking was requested.
> 
> Short sample (25MB, it allows one 10 second forward seek with ffplay and
> -demuxer mpegts) uploaded to incoming/demuxerlavfseek.ts

ffplay only works because it seeks by bytes and not by time.
Try ffplay -ss 20 and you'll see the same behaviour.
The problem is that the TS demuxer selects 6120 as pcr_pid, which
means it tries to use the timestamps of that one for seeking,
however that one does not have even one single timestamp, only
6110 contains timestamps.
I have no idea what is wrong there or how to solve it, but
maybe you can make a FFmpeg bug report with that...