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

[Collins, Andrew]

Hi Michael,

Thank you for the reply. You are correct, the problem is on Windows. For info we use ffmpeg on Windows, Linux and Mac, this particular situation is with Windows and the problem is as you guessed.

I completely agree with your thoughts on it being a bad idea to make a generalisation when opening the output for protocols where it is not possible to read-write and another approach may be to look at a change in file.c. However, this does also bring the question that even if file.c were modified for special behaviour FFMPEG is still asking at a logical level to always open the file for write (only), rather than requesting it be opened for read-write.

Surely, considering your comments it might be better to have an option to say open for read-write - this is the request from the user and is therefore true and not "lying" and then check at the open stage whether the protocol would allow read-write rather than fudging file.c.  

I'll give it some thought and see if I can put together a code-change.

As I said, we're seeing the need for this now with the newly implemented chunked MOV/MP4 file support which is excellent. It means we can read the files while they are being transcoded in our case to be able to play the files while they are being transcoded. 

Regards,

Andy


Andrew Collins
Senior Manager, Content Workflow Solutions of Europe (CWSoE)
Tel: 01256 483351
 
Professional Solutions Europe, a division of Sony Europe Limited.
A company registered in England and Wales. Registered office: The Heights, Brooklands, Weybridge, Surrey. KT13 0XW. Registered company number 2422874


-----Original Message-----
From: Michael Niedermayer [mailto:michaelni at gmx.at] 
Sent: 18 January 2012 20:41
To: FFmpeg development discussions and patches; Collins, Andrew
Subject: Re: [FFmpeg-devel] Allow output files as read-write

* PGP Signed by an unknown key

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

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

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope

* Unknown Key
* 0x040B0FAB

************************************************************************
The information contained in this message or any of its attachments may be confidential and is intended for the exclusive use of the addressee(s).  Any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited without the express permission of the sender.  The views expressed in this email are those of the individual and not necessarily those of Sony or Sony affiliated companies.  Sony email is for business use only.

This email and any response may be monitored by Sony to be in compliance with Sony's global policies and standards