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

[Tomas Härdin]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: skipping_stream_seek.patch
Type: text/x-patch
Size: 619 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100324/40d10af1/attachment.bin>