[FFmpeg-devel] Allow output files as read-write

[Reimar Döffinger]

On Wed, Jan 18, 2012 at 09:41:23PM +0100, Michael Niedermayer wrote:
> On Wed, Jan 18, 2012 at 08:51:03PM +0100, Reimar Döffinger wrote:
> > On Wed, Jan 18, 2012 at 12:28:56PM +0000, Collins, Andrew wrote:
> > > We would like to ask if it is possible to change the parameter on line
> > > 4166 and 3331 from AVIO_FLAG_WRITE to AVIO_FLAG_READ_WRITE to prevent
> > > the file lock. Obviously a more clever suggestion would be to have this
> > > as one of the command options. 
> > [...]
> > > While it is not desirable to do this in all cases with your new
> > > excellent implementation of fragmented MP4 files it means we can now
> > > read a growing file at the same time it is being generated - good for
> > > live inputs. With the file-lock on that is not possible. We've tested
> > > this internally and the simple change makes all the difference.
> > 
> > I think we are missing some critical information here.
> > What do you mean by file-lock? Are you using Windows (the only
> > OS I know of that locks file without anyone asking for it and no
> > good reason at all really)?
> > Regardless of that, opening a file for write-only or read-write
> > shouldn't make a difference for file-locking, that seems like
> > really nonsensical behaviour.
> > And "lying" to the file layer about what access is needed is a rather
> > bad idea, since we may have or add protocols that cannot support
> > read-write, and FFmpeg would then not be able to use them as output.
> > If my assumptions about you running Windows are correct,
> 
> > you should
> > probably just add a few calls to libavformat/file.c that tells it
> > to not pointlessly lock the file.
> 
> note though, we are certainly interrested in also having these calls
> in main ffmpeg git

Yes, I meant including sending a patch.
Of course I am not sure this behaviour isn't due to some broken
MinGW libc replacement or such.
While it should be possible to just test in configure for _sopen
and use that, the description sounds to me like MinGW or whatever
are already using it, just in a broken way (probably duplication the
open flags into the share flags which makes no sense, for compatibility
with Unix/Linux it should set all share flags always).