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

[Michael Niedermayer]

On Tue, Mar 30, 2010 at 10:02:39AM +0200, Tomas H?rdin wrote:
> 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.

any idea what it could be?
also did you check that none of the url_fseeks in dv* fail?

anyway, as said the patch should be ok

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates
-------------- 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/20100330/1dd1e316/attachment.pgp>