[FFmpeg-devel] [PATCH] fix matroska decoder for streamed input

[Reimar Döffinger]

On Sat, Jun 05, 2010 at 04:42:00PM -0400, David Conrad wrote:
> On Jun 5, 2010, at 12:56 PM, Reimar D?ffinger wrote:
> 
> > On Sat, Jun 05, 2010 at 12:29:31PM -0400, David Conrad wrote:
> >> On Jun 5, 2010, at 12:24 PM, Reimar D?ffinger wrote:
> >>> the matroska demuxer will attempt seeking when reading the seekhead stuff.
> >>> This completely messes up playing from stdin - well, at least within
> >>> MPlayer.
> >>> I since this is a non-essential part, IMO it should be skipped for
> >>> the url_is_streamed case, as in below patch.
> >>> Objections to applying it?
> >> 
> >> Doesn't this break reading cues over http?
> > 
> > Yes, however
> > a) with high-latency connections that's a good thing
> > b) I'd consider broken seeking better than completely non-working
> > playback when e.g. the server does not accept range requests.
> 
> Reading cues that are at the end of files over http will probably be somewhat common with webm, and we still need a different way to know when not to seek than just whether it's streamed or not, or else the first attempt to seek in a piped file will result in the same behaviour.

Well, libavformat is not going to seek on its own for no good reason, so that
should be the application's problem.

> > However, is there any reason why we can't read those seekheads when we
> > actually want to seek, at least for the streamed case?
> 
> This would work too. 

I guess it would be a nice-to-have to be more flexible about this, e.g.
reading the index at once for on-disk streams (so the application could
use the index for other purposes), on-demand loading for slow seeking
(http with range support), seeking by resetting (http without ranges)
and lastly making sure that only forward seeks are ever done (pipes).
However, that's not for today, considering that is is_streamed currently
is indeed supposed to mean "seeking is unusable", how about the patch
as a first solution?