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

Michael Niedermayer michaelni
Wed Mar 24 19:22:41 CET 2010


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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100324/450fb56e/attachment.pgp>



More information about the ffmpeg-devel mailing list