[Ffmpeg-devel] [PATCH] asf seek back at end of file after rewriting header

[Reimar Döffinger]

Hello,
On Sun, Apr 15, 2007 at 01:46:11PM -0400, Rich Felker wrote:
> On Sun, Apr 15, 2007 at 07:17:11PM +0200, Baptiste Coudurier wrote:
> > Reimar D?ffinger wrote:
> > > Hello,
> > > On Sun, Apr 15, 2007 at 06:18:06PM +0200, Baptiste Coudurier wrote:
> > >> Reimar D?ffinger wrote:
> > >>> On Sat, Apr 14, 2007 at 04:13:15AM +0200, Baptiste Coudurier wrote:
> > >>> [...]
> > >>>> url_fsize does seek.
> > >>> Actually that is not completely correct, it tries
> > >>> size = s->seek(s->opaque, 0, AVSEEK_SIZE);
> > >>> first.
> > >>> Even thought that function is called seek, there is no need for this
> > >>> operation to seek, and it can be implemented for all kinds of urls,
> > >>> whether they are pipes or whatever.
> > >> Use f/stat to find file size instead of seek ? Is there any other
> > >> solution ? In hope there is no portability problems.

Is missed the "Is there any other solution". For writing files (which was the problem
here), yes, of course there is. Just keep track of the maximum file
position you wrote to. And for reading both http and ftp offer (although
optional) ways to get the file size. If speed ever really is a concern
for it, these values can also be cached.

> > > stat only work normal files, what is the point of avoiding the seek with
> > > those??
> > 
> > Yes, there is no point of using f/stat for normal files, that's why
> > url_fsize does seek for normal files.
> 
> The problem is that seek also works for http and custom stream types,
> resulting in horrible performance and abusive behavior. It would be
> better to determine the size another way if possible and if not, treat
> the size as unknown. Maybe this is already done by AVSEEK_SIZE..?

That depends on the "URL handler". My point was that if there is any
problem with url_fsize it can and should be fixed in the URL handler
instead of having ugly hacks just to avoid using url_fsize.

Greetings,
Reimar Doeffinger