[FFmpeg-devel] [RFC] Questions and suggestions regarding AVSEEK_FORCE?

[Tomas Härdin]

On Wed, 2010-03-24 at 19:22 +0100, Michael Niedermayer wrote:
> On Wed, Mar 24, 2010 at 06:43:50PM +0100, Tomas H?rdin wrote:
> > On Wed, 2010-03-24 at 13:52 +0100, Michael Niedermayer wrote:
> > > On Wed, Mar 24, 2010 at 10:05:50AM +0100, Tomas H?rdin wrote:
> > > > A simpler solution would be to simply have url_fseek() always discard
> > > > data when seeking forward (skipping) in nonseekable media, since it's
> > > > not possible to seek anyway (best effort). I tried that, and it made it
> > > > possible to play and seek forwards in mov and dv files from nonseekable
> > > > HTTP and opening the peculiar mov files mentioned in the first
> > > > paragraph.
> > > 
> > > iam ok with trying this but this has a high chance of uncovering bugs
> > > (things seeking forward (maybe to the end of the file) and then expecting
> > >   to be able to seek back)
> > > 
> > 
> > Well, one could easily prevent it for SEEK_END. That could be a good
> > application for requiring AVSEEK_FORCE. That is of course not an option
> > for protocols which can't ever seek back, such as pipe, compared to
> > protocols for which seeking back is merely an inconvenience, such as
> > nonseekable HTTP streams (reopen + linear read). A flag in URLContext
> > such as is_reopenable could serve as a final "defence" for such cases.
> > 
> > I suspect a number of test cases would be needed. Something that reads
> > the input files via a pipe. I'm not sure how to go about making that
> > though, since I haven't looked into the test system.
> > 
> > For anyone interested, I've attached a small proof-of-concept patch that
> > makes .mov files work on stdin in ffplay. Even fast-forwarding works. DV
> > has some kind of problem with pipes though (seems to come out of
> > alignment), but works fine when fed from a nonseekable HTTP stream. AVI
> > files work in both cases.
> > 
> > /Tomas
> 
> >  aviobuf.c |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 8f7408aa00c5d45b8224ac3da13463a5974df313  skipping_stream_seek.patch
> 
> ok if tested

I've been testing this for a few days, and the only case I have been
able to find where it behaves strangely is when skipping in DV on a
pipe, as mentioned earlier. Digging a bit in the DV demuxer it seems it
always comes exactly 12928 B out of alignment for a DV25 file, which
obviously results in broken output. However, since the same file
delivered via nonseekable HTTP is skippable this leads me to believe
there is some problem with the pipe protocol.

The following were the results when playing various containers from
stdin in ffplay:

Worked fine (plays, skippable): MOV (assuming the moov tag is before the
mdat tag, of course) and various flavors of MPEG.

The following play, but are unskippable for various reasons: DV, AVI,
OGG, FLV, MPEG-TS, MXF (probably depends on how it was muxed)

MKV sometimes works, but is never skippable.

I suspect that most of these would work much better if fed by
nonseekable HTTP rather than a pipe.

Finally, the normal regression tests all pass without a problem.

/Tomas